Grundbegriffe des Datenbanksystems UDS/SQL

UDS/SQL-Datenbank

In einer UDS/SQL-Datenbank sind große Mengen aufeinander bezogener Daten zusammengefasst. Die Daten werden in der Datenbank so gespeichert, dass sie unabhängig von der Programmierung sind und von verschiedenen Programmen optimal verwendet werden können, trotzdem aber so wenig Redundanzen wie möglich aufweisen. Kontrolliert werden neue Daten zur Datenbank hinzugefügt, existierende Daten wiedergewonnen, geändert oder gelöscht.
Bei UDS/SQL können mehrere Datenbanken zu einem gemeinsam prozessierbaren Multi-DB-System zusammengefasst werden, siehe auch Abschnitt „Datenbankkonfiguration".

Datenbanksystem

Die Gesamtheit aller Programme, die für den Aufbau und die Verwaltung der Datenbestände sowie für die Wiedergewinnung und Sicherung der Daten erforderlich sind, bezeichnet man als Datenbanksystem.

Database Handler (DBH)

Den Zugriff auf die Datenbank steuert die zentrale Komponente von UDS/SQL, der Database Handler (DBH), der eine Datenbank (Mono-DB-Betrieb) oder auch mehrere Datenbanken gemeinsam (Multi-DB-Betrieb) prozessieren kann.
Er wird angeboten in den folgenden beiden Varianten:

• independent DBH

• linked-in DBH

Beim independent DBH steuern die folgenden Module den Datenbankbetrieb:

• UDSSQL

• UDSSUB

• UDSCT bei UDS-D

Jedes Modul läuft als eigene Task ab. Zusammen bilden sie die Taskfamilie des independent DBH.

Die Module haben folgende Aufgaben:

UDSSQL	Mastertask; UDSSQL führt die Kommunikation mit dem Datenbankadministrator und sorgt für das Einleiten, Überwachen und Beenden der Session.
UDSSUB	Servertask (mehrfach ladbar); UDSSUB erhält die Anforderungen der Anwenderprogramme zur Bearbeitung und gibt die Ergebnisse an das jeweilige Anwenderprogramm zurück.
UDSCT	UDS-D-Task; UDSCT übernimmt die Kommunikationsaufgaben, die nötig sind, um DML-Anweisungen von entfernten Anwenderprogrammen zu bearbeiten.

Der linked-in DBH ist kein selbstständiges Programm, sondern wird in das jeweilige Anwenderprogramm eingebunden oder zur Laufzeit nachgeladen und läuft als Teil dieses Programms. Datenbankänderungen können von einem solchen Anwenderprogramm nur dann ausgeführt werden, wenn es als einziges (EXCLUSIVE) mit der Datenbank arbeitet. RETRIEVAL-Zugriff durch mehrere linked-in DBHs ist möglich. Da die Task-Kommunikation, die beim independent DBH erforderlich ist, hier wegfällt, kann besonders bei sequenzieller Verarbeitung eine Laufzeitverbesserung erzielt werden.

Der linked-in DBH ist, ebenso wie der independent DBH, multi-DB-fähig. Der linked-in DBH kann keine SQL-Anweisungen bearbeiten.

Session

Eine Session ist der Zeitraum, in dem ein oder mehrere Anwender mit der (den) Datenbank(en) arbeiten können. Sie beginnt mit dem Laden des DBH (independent oder linked-in) und endet mit der Meldung „NORMAL SYSTEM TERMINATION“. Innerhalb der Session ist die Datenbankkonfiguration durch Parameter festgelegt, die der Datenbankadministrator beim Laden des DBH oder per DAL-Kommando angibt.

Datenbankkonfiguration

Beim Starten der Session legt der Datenbankadministrator mit den Ladeparametern des DBH fest, welche Datenbanken zunächst an der Session teilnehmen. Die Datenbanken einer Session und die Umgebung, in der die Session abläuft, nennt man Datenbankkonfiguration.

Jede Datenbankkonfiguration erhält vom Administrator einen Namen. Die Konfigurationsdaten werden für die Dauer der Session in der Session-Log-File (SLF) hinterlegt, damit bei einem eventuellen Wiederanlauf die aktuelle Datenbankkonfiguration wiederhergestellt werden kann.

Transaktion

Jedes Datenbank-Anwenderprogramm muss beim DBH eine Transaktion eröffnen, wenn es mit einer UDS/SQL-Datenbank kommunizieren will - gleichgültig, ob über den linked-in oder den independent DBH.

Eine Transaktion (TA) ist eine logisch zusammengehörige Folge von DML-Anweisungen, die entweder vollständig oder gar nicht ausgeführt wird. Beispielsweise beginnt eine Transaktion in einem COBOL-DML-Programm mit der DML-Anweisung READY und endet mit FINISH.
Im Mono-DB-Betrieb eröffnen Sie mit jeder READY-Anweisung eine Transaktion und gleichzeitig die Datenbank; das Anwenderprogramm kann nun beliebig oft per DML-Anweisung auf die eröffnete Datenbank zugreifen. Im Multi-DB-Betrieb müssen Sie jede Datenbank mit einer READY-Anweisung eröffnen. Deshalb kann es im Multi-DB-Betrieb innerhalb einer Transaktion mehrere READY-Anweisungen geben, wobei die erste READY-Anweisung die Transaktion eröffnet.
Beendet das COBOL-DML-Anwenderprogramm die Transaktion mit der DML-Anweisung FINISH, so kann es erst dann wieder auf die Datenbank(en) zugreifen, wenn gilt:

• Im Mono-DB-Betrieb hat das Anwenderprogramm mit einem erneuten READY eine neue Transaktion und damit auch die Datenbank eröffnet.

• Im Multi-DB-Betrieb hat das Anwenderprogramm mit einem erneuten READY eine neue Transaktion und damit auch eine Datenbank eröffnet. Mit weiteren READY-Anweisungen innerhalb derselben Transaktion wurden ggf. weitere Datenbanken eröffnet.

Auch ein SQL-Programm kann nur innerhalb von Transaktionen auf UDS/SQL-Datenbanken zugreifen. In SQL-Programmen beginnt eine Transaktion mit der ersten von COMMIT WORK verschiedenen SQL-Anweisung und endet mit der SQL-Anweisung COMMIT WORK.

Vorgang

In einer SQL-Anwendung werden SQL-spezifische Verwaltungsdaten über Transaktionsgrenzen hinweg aufbewahrt.
Eine solche Verwaltungseinheit wird als Vorgang bezeichnet.