Im Zusammenhang mit relationalen Datenbanken ist immer wieder vom SQL-Server die Rede. Worum es bei diesem Konzept geht, und wie eine praktische Konfiguration aussehen könnte, beschreiben Thomas Herrmann und Berthold Mätschke.

Heute übliche PC-Datenbanksysteme wurden ursprünglich als Einplatzsysteme ausgelegt. Hier hat man es mit einem Programm zu tun, das die Benutzerinteraktion steuert und gleichzeitig für die Datenbankzugriffe verantwortlich ist; es muß Indexdateien verwalten und den Zugriff auf die Daten vornehmen.

Mit der Verbreitung der PCs nahm die Forderung nach Datenbanken in Netzwerken zu. Die meisten Anbieter reagierten darauf mit speziellen Netzwerkversionen ihrer Produkte. Hierbei wurde das Datenbankprogramm so erweitert, daß Applikationen dem Programmierer Hilfsmittel zum Zugriffsschutz verfügbar machten.

Diese Datenbanken für PC-Netzwerke arbeiten fast ausschließlich nach dem Fileserver-Prinzip. Hierbei läuft auf jedem der angeschlossenen Rechner das Datenbankprogramm ab, das sämtliche Datenbankfunktionen ausführen muß. Die Zugriffe auf externe Speicher (Festplatte) erfolgen nun jedoch nicht lokal, sondern über das Netzwerk. Im Netzwerkserver werden Vorkehrungen getroffen, die den Zugriffsschutz bei Multiuser-Anwendungen erlauben.

Hierin besteht einer der großen Schwachpunkte des Fileserver-Konzepts für den Einsatz mit Datenbanken: Die Verarbeitung läuft komplett auf der Workstation ab, und alle Dateizugriffe erfolgen über das Netzwerk Als Folge ergibt sich eine hohe Netzwerkbelastung, da zum Beispiel für das Auffinden eines bestimmten Datensatzes der Zugriff auf mehrere Indexdateien und Datendateien nötig sein kann.

Die Anbieter von SQL-Datenbanken sind einen anderen Weg gegangen. Bei diesen Systemen wird von vornherein unterschieden zwischen der Applikation und der Datenbank. Es existiert also nicht mehr ein Datenbankprogramm, das sowohl die Benutzerschnittstelle als auch den Datenbankteil enthält, sondern es erfolgt eine "Arbeitsteilung" in zwei getrennte Programme.

Ein Programmteil, die SQL-Engine, ist für alle Datenbankoperationen zuständig. Davon unabhängig existieren verschiedene Anwendungsprogramme, die mit der SQL-Engine kommunizieren (Abbildung 1). Diese Trennung ist auf den Rechnern, für die die meisten der heute erhältlichen relationalen Datenbanksysteme (zum Beispiel DB2, SQL/DS, Oracle, Ingres, Informix) ursprünglich konzipiert waren (dies sind Systeme unter den Betriebssystemen MVS, CMS, Unix oder VMS) recht einfach durchzuführen: Man läßt die SQL-Engine als Hintergrundprozeß ablaufen und setzt Techniken der Interprozeßkommunikation ein. Dies setzt jedoch voraus, daß das Betriebssystem Multitasking unterstützt.

Bei Portierungen der relationalen Systeme auf Single-User-Betriebssysteme (MS-DOS) half man sich meist durch eine Aufteilung in einen speicherresidenten Teil (SQL-Engine) und einen nachgeladenen Programmteil, der das eigentliche Anwendungsprogramm darstellte. Wie kann dieses Variante in Netzwerken ablaufen und welche Vorteile bringt das?

Durch die strikte Aufteilung in zwei Aufgabenbereiche - SQL-Engine und Anwendungsprogramme - ist es möglich, diese beiden Prozesse auf verschiedenen Rechnern ablaufen zu lassen. An die Stelle der Kommunikation zwischen zwei lokalen Prozessen tritt die Kommunikation über das Netzwerk (Abbildung 2). Da die SQL-Engine sämtliche den Datenbankzugriff betreffende Operationen ausführt, kann die Datenbankanfrage nun lokal auf dem Server erfolgen. Dieser fungiert jetzt als Datenbankserver. Dadurch ergibt sich natürlich eine sehr viel geringere Netzwerkbelastung als bei Einsatz von Fileservern.

Setzt man im Netzwerk ein genormtes Protokoll für die Kommunikation der Prozesse ein (zum Beispiel Decnet oder TCP/IP), so sind sogar unterschiedliche Rechner mit unterschiedlichen Betriebssystemen im Netzwerk verwendbar, die alle auf denselben Datenbankserver zugreifen. Es kann also heterogene Hard und Software zum Einsatz kommen. Ein Sicherheitsaspekt sollte auch nicht außer acht gelassen werden. Da jetzt ein einziges Programm die Datenbank verwaltet, läßt sich auch der Zugriffsschutz an dieser Stelle realisieren, das heißt, er wird lokal im Datenbankserver geregelt. Dadurch entfallen die bei Fileservern üblichen Probleme des gemeinsamen Zugriffs auf Dateien.

Im folgenden soll die konkrete Realisierung einer relationalen Datenbank im Netzwerk vorgestellt werden. Diese Konfiguration beschreibt ein Beispiel, wie es in ähnlicher Art und Weise mit den meisten relationalen DBMS, die über eine SQL-Engine verfügen, denkbar ist. Es kommen dabei folgende Hard- und Softwarekomponenten zum Einsatz:

þRelationales Datenbanksystem

þEthernet-Netzwerk mit TCP/IP für MS-DOS und Xenix

þ80286 und 80386-Rechner unter MS-DOS und SCO-Xenix

þWorkstation mit Ethernet (TCP/ IP) unter Unix

Auf den Datenbankservern (80386-Rechner mit SCO-Xenix/ 386) kommt ein RDBMS-LANserver zum Einsatz beziehungsweise ein komplettes relationales Datenbank-Management-System für Xenix und Unix. Die Workstations arbeiten mit den RDBMS-Anwendungsprogrammen oder mit einem kompletten relationalen Datenbank-Management-System für MS/PC-DOS. Abbildung 3 zeigt einen schematischen Überblick über die Konfiguration.

Es gibt relationale Datenbanksysteme, die es erlauben, auf einem Rechner mehrere Datenbanken parallel zu betreiben (bei Multitasking-Betriebssystemen). Von dieser Möglichkeit wurde allerdings kein Gebrauch gemacht.

Bei dem Anwendungsbeispiel handelt es sich um eine einfache Auftragsabwicklung. Diese Applikation wurde mit dem 4-GL-Entwicklungstool und einem Report-Writer erstellt, die beide Bestandteil des RDBMS sind. Die Verarbeitung der Anwendungsprogramme (Maskenprozessor beziehungsweise Report-Generator) erfolgt auf den Workstations. Der Datenbankkern (SQL-Engine) wird jedoch auf dem gerade angesprochenen Datenbankserver ausgeführt.

Woher weiß das Anwendungsprogramm aber, wo die Daten sind? Für DB-Zugriffe muß ein Benutzer immer eine Zugriffsberechtigung innerhalb der Datenbank besitzen. Ähnlich wie bei Multiuser-Betriebssystemen wird diese Berechtigung durch Logon und Logoff an der Datenbank realisiert. Durch den Befehl CONNECT BREAK/POINT wird ein Logon an der Datenbank als Benutzer-"BREAK" durchgeführt. Soll ein Zugriff auf eine Datenbank erfolgen, die auf einem anderen Rechner liegt, so braucht man diese Datenbank nur beim Logon zu spezifizieren. Der entsprechende Befehl lautet: CONNECT BREAK/POINT@