PC-Datenbanken lassen sich heute durchaus produktiv im Unternehmen einsetzen. Allerdings sollte man sich vorher sorgfältig überlegen, was man will und wie sie in das organisatorische und technische Umfeld integriert werden sollen.
Ganz allgemein läßt sich heute eine immer weiter wachsende Bedeutung von Datenbanksystemen erkennen, die in folgenden Tatsachen begründet liegen mag:
- Durch die stetig wachsende Flut von (meist schon elektronisch gespeicherten) Informationen wächst der Zwang zu systematischer Erfassung.
- Gleichzeitig eröffnen die immer höheren Rechner- und Plattenleistungen bessere und sogar billigere Speichermöglichkeiten.
- Die zunehmende Verbreitung der Datenmanipulationssprache SQL (Structured Query Language) und ihre Standardisierung bietet einen hohen Investitionsschutz.
- Für SQL-Datenbanksysteme werden typischerweise recht einfache Bedienerschnittstellen zur Abfrage von Datenbankinhalten und zur Erzeugung von Reports angeboten, zum Teil sogar unabhängig vom zugrundeliegenden SQL-System.
Höhere Produktivität mit SQL-Datenbanksystem
Datenbanksysteme werden heute für alle Rechnerklassen angeboten, angefangen vom DOS-PC bis hin zu allen Großrechnern. Sie lösen wegen ihrer höheren Mächtigkeit herkömmliche dateiverarbeitende Systeme mehr und mehr ab; wer heute ein Anwendungspaket zu entwickeln hat, erzielt mit einem SQL-Datenbanksystem eine weitaus höhere Produktivität - und zwar von der Datenmodellierung über die Spezifikation bis hin zur Codierung und zum Test der Programme.
Vor diesem Hintergrund ist auch der Einsatz von PC-Datenbanken zu sehen, der allerdings - verglichen mit Großrechnerdatenbanken - doch neue Probleme aufwirft, die zum Teil andere Systemkonfigurationen erfordern.
Im folgenden sollen zuerst rein lokale, nicht vernetzte PC-Datenbanken untersucht werden, im Anschluß daran werden Client-Server-Lösungen in mehreren Varianten diskutiert Abschließend kommen verteilte Datenbanksysteme und Multi-Server-Systeme zur Sprache.
Ausschließlich lokale PC-Datenbanken zu haben, bedeutet an erster Stelle eine starke Replizierung aller Datenbestände auf alle PCs, und zwar sowohl solcher, die nur organisatorischer Natur sind, wie etwa die Datenbank-Systemsoftware selbst, als auch der Nutzdatenbestände, also der Daten, die in den Datenbanken gehalten werden.
Im letzteren Fall sind natürlich nur die Daten zu replizieren, die von mehreren Rechnern (Benutzern) benötigt werden. Hat die Unternehmung eine Struktur, in der jeder Rechner nur solche Daten benötigt, die er auch selbst verwaltet, so führt diese Realisierung zu keinen replizierten Nutzdaten und ist praktikabel.
Replizierung: sicher, ober teurer
Die Replizierung sämtlicher Betriebssoftware führt nicht nur zu einem weitaus höheren Umstellungsaufwand, zum Beispiel bei einem Versionswechsel, sie bedeutet auch erhöhten Platten- und Hauptspeicherbedarf. Letztendlich führt sie zu deutlich höheren Anschaffungs- und Wartungskosten. Auf der anderen Seite gewährt sie zwar, was Hardware und Betriebssoftware angeht, ein hohes Maß an Ausfallsicherheit, erhöht jedoch gleichzeitig die Gefahr inkonsistenter Nutzerdaten.
Ein erheblicher Kritikpunkt an MS-DOS-basierten Datenbanksystemen sind die mangelhaften Möglichkeiten des Datenschutzes und der Datensicherheit. MS-DOS verfügt weder über eine Benutzerautorisierung noch über ein entsprechendes Dateischutzkonzept. Daher können Datenbank-Dateien von jedem manipuliert werden, der Zugang zu dem Rechner hat. Auch wenn das Datenbanksystem selber Benutzerautorisierung und Zugriffsschutz auf SQL-Ebene (dies ist Bestandteil des Standards) garantiert, kann der physische Zugriff` auf die Daten nicht wirkungsvoll verhindert werden.
Client-Server-Lösungen in einem lokalen Netz
Aus den genannten Gründen haben ausschließlich lokale PC-Datenbanken wenig praktische Relevanz. In zunehmendem Maß finden statt dessen sogenannte Client-Server-Lösungen Verbreitung, die ein günstigeres Betriebs-, Kosten- und Nutzungsbild bieten.
Ein spezieller Rechner fungiert als "Datenbank-Server", manchmal auch wegen der Ausrichtung auf SQL als "SQL-Server" bezeichnet. An diesen Datenbank-Server wenden sich andere PCs über Netzwerkprotokolle, um Datenbankabfragen und -änderungen durchführen zu lassen.
Eine genauere technische Unterscheidung von Client-Server-Lösungen kann man danach vornehmen, ob es sich um homogene oder heterogene Netze handelt. Ein Netz aus einem MS-DOS-Server und vielen MS-DOS-Client ist ein homogenes Netz, während beispielsweise ein Netz aus MS-DOS-Client, einem Unix-Server und einem VMS-Client hochgradig heterogen ist.
Wir wollen im folgenden auch Realisierungen, die einen zentralen Großrechner in ein PC-Netz einbeziehen, als Client-Server-Lösung verstehen.
Alle Clients, die auf den Datenbank-Server Zugriff haben sollen, müssen physisch mit ihm über ein schnelles Lokalnetz verbunden sein. Typischerweise wird heute dazu ein Ethernet oder ein Token-Ring verwendet, die im allgemeinen mit einer Übertragungsgeschwindigkeit von 10 Mbit/s arbeiten.
Viel wichtiger als die hardwaremäßige Verbindung ist aber das Protokoll, über das Client und Server miteinander kommunizieren. Hier gibt es heute eine Reihe unterschiedlicher Standards:
- TCP/IP (herstellerunabhängig)
- Decnet (Digital Equipment)
- OS/2-LAN Manager und NET-BIOS (Microsoft/IBM)
- Novell Netzwerk und ähnliches.
Generell kann man ein herstellerunabhängiges Kommunikationsprotokoll weit besser erweitern: Es ist "offener", weil es die Einbindung von Rechnern anderer Hersteller, auch unter anderen Betriebssystemen ermöglicht.
SQL bietet die besten Möglishkeiten
In allen Bereichen stehen heute SQI.-Datenbanksysteme im Vordergrund. Die wichtigste Ursache dafür dürfte in der weit fortgeschrittenen Standardisierung von SQL liegen, die die Portierung von SQL-Programmen zwischen Datenbanksystemen verschiedener Hersteller erleichtern soll. Die Praxis zeigt allerdings, daß dies trotz der Standardisierung nicht ganz so einfach ist: Die meisten Hersteller haben eigene SQL-Dialekte, eigene Erweiterungen, die über den Standard hinausgehen - außerdem sind einige wichtige Implementierungseigenschaften im Standard nicht exakt festgeschrieben.
Von den Vorteilen der Standardisierung abgesehen, bietet SQL als deklarative Sprache die besten Möglichkeiten, auch komplizierte Abfragen kompakt zu formulieren, und zwar - im Gegensatz zu prozeduralen Sprachen - vollkommen ohne Kenntnis der physischen Speicherung der Daten. Dies stellt natürlich an die Güte von SQL-Systemen eine wesentliche Forderung: Da der Frager nicht spezifiziert, wie die Ergebnisse berechnet werden sollen, muß das Datenbanksystem von sich aus eine optimale Berechnung finden. Deswegen ist für die Beurteilung von SQL-Datenbanksystemen die Qualität der eingesetzten Query-Optimierer von außerordentlicher Bedeutung.
Für die Realisierung von Datenbank-Servern hat SQL einen weiteren entscheidenden Vorteil: Es müssen verhältnismäßig wenig Daten über das Netz transportiert werden Ä einerseits die SQL-Query, im allgemeinen eine Zeichenkette von selten mehr als 2000 Zeichen vom Client zum Server und dann die Datensätze vom Server zum Client.
Da ein Frager meist nur sehr wenige Datensätze sehen oder verarbeiten will und diese Sätze mittels logischer Prädikate genau spezifizieren kann, sind auch nur diese wenigen Datensätze zu transportieren. Diese Eigenschaft führt dazu, daß ein SQL-Server die Netzbelastung in der Regel nur unwesentlich erhöht.
Ganz anders verhält es sich mit der CPU- und E/A-Belastung des Datenbank-Servers selber: Diese wird um so höher, je mehr PCs an den Server angeschlossen sind und je intensiver der Server in Anspruch genommen wird. Leistungsfähigkeit im Multiuser-Betrieb ist daher eine unabdingbare Voraussetzung, die von den Server Betriebssystemen unterschiedlich gut erfüllt wird.
Datenbank-Server auf MS-DOS- und OS/2-Basis
Sowohl Datenbank-Server als auch Client laufen unter MS-DOS beziehungsweise OS/2, das wir als homogen zu MS-DOS betrachten wollen. Selbstverständlich muß der Datenbank-Server hardwaremäßig weitaus besser ausgebaut sein als die Client. In der DOS-Welt sind heute herstellerabhängige Kommunikationsprotokolle am weitesten verbreitet: entweder auf der Basis des OS/2-LAN-Managers und von NET-BIOS-Routinen oder auch rein herstellerorientierte Protokolle, wie etwa Novells Netware.
Mit Hilfe der LAN-Vernetzung ist es möglich, auf einem PC, der selbst über kein Datenbanksystem verfügen muß, die volle Mächtigkeit eines Datenbanksystems zu nutzen. Insbesondere sind sämtliche Datenbank-Daten zentral gespeichert und von allen PCs aus in gleicher Weise zugänglich.
Der Datenbank-Server ist streng zu unterscheiden von einem reinen Fileserver: Bei einem Fileserver läuft das Datenbanksystem auf dem lokalen PC, dessen Plattenzugriffe, zum Beispiel über ein virtuelles Laufwerk, auf eine Serverplatte umgeleitet werden. Der wesentliche Nachteil dieser Lösung besteht darin, daß erheblich mehr Daten über das Netz zu bewegen sind als beim Einsatz eines Datenbank-Servers.
Bezüglich der Leistungsfähigkeit von MS-DOS-Servern sind allerdings Zweifel anzumelden: Einerseits ist die Rechnerleistung doch einigermaßen beschränkt, andererseits sind auch die Anbindung von großen Plattenlaufwerken und der einigermaßen schwierige Hauptspeicherausbau limitierende Faktoren.
Ein weiterer Kritikpunkt an MS-DOS-basierten Datenbank-Servern sind die erwähnten Mängel bezüglich Datenschutz und Datensicherheit. Bei einem Datenbank-Server sind diese Defizite noch gravierender, weil auf ihm gewöhnlich eine weitaus größere Menge von Daten, auch sensiblen Daten, gehalten werden sollen, deren Verlust oder unbefugtes Lesen weitreichende Folgen haben kann.
Auch 0S/2 hat kein Benutzerkonzept
Mit der Einführung von OS/2 sollten viele Nachteile von MS-DOS beseitigt werden: OS/2 ist von Haus aus als Multitasking-Betriebssystem ausgelegt und realisiert parallele Prozesse. Die von MS-DOS her bekannten Einschränkungen der Prozeßgröße sind beseitigt, so daß OS/2 eine bessere Basis für Datenbank-Server bieten sollte.
Zwei wesentliche Nachteile von MS-DOS wurden jedoch nicht beseitigt: Auch OS/2 hat kein Benutzerkonzept mit einem entsprechenden Schutz der Benutzerdateien vor fremdem Zugriff, und konsequenterweise gibt es auch keine Benutzerautorisierung. Damit sind im Prinzip Daten, die unter OS/2 gespeichert sind, jedermann zugänglich; der einzige Schutz besteht in der (aufwendigen) Verschlüsselung von sensiblen Daten. Damit sind entscheidende Nachteile, die schon für DOS-basierte Server angeführt wurden, bestehen geblieben.
Der Vorteil eines Prozeßkonzepts ist für den Anwender des Servers nicht spürbar; er kommt ausschließlich den Entwicklern von Datenbank-Servern zugute.
Der erste Schritt der Integration von PCs in die unternehmensweite Rechnerlandschaft ist typischerweise die Anbindung an einen zentralen Großrechner. Der Funktionsumfang besteht im allgemeinen aus einer Terminalemulation, mit der sich der PC in den Großrechner einloggen kann, und der Möglichkeit zum Filetransfer, so daß Dateien vom PC auf den Host und umgekehrt übertragen werden können.
Server auf der Basis von Großrechner-Kopplungen
Diese Möglichkeiten können dazu genutzt werden, Daten zur Weiterverarbeitung auf dem PC aus einer zentralen Host-Datenbank zu entnehmen, um beispielsweise Serienbriefe an alle Kunden zu drucken. Die Verarbeitung der Daten sollte zweckmäßigerweise online in der Datenbank geschehen, das heißt über ein direktes Einloggen auf dem Großrechner: Dadurch ist erstens garantiert, daß die Daten in der Datenbank stets aktuell sind, andererseits müssen keine komplizierten Ausleihverfahren angewendet werden, wie sie notwendig wären, wenn man Daten vom Großrechner zum PC transferieren, dort ändern und anschließend zurückkopieren würde.
Diese - relativ lose - Form des Datenbankzugriffs ist wenig benutzerfreundlich, müssen die Benutzer doch neben der gewohnten PC-Umgebung noch die Bedienung des Großrechners mit seinen verhältnismäßig unhandlichen Schnittstellen lernen. Zudem können die Datenbank-Daten nicht lokal verändert werden.
Dafür verspricht eine solche Struktur aber wohl die beste Datensicherheit: Der Schutz vor unbefugtem Zugriff und die regelmäßige Datensicherung, die für den Rechenzentrums-Betrieb typisch sind, bieten einen wesentlich höheren Grad an Sicherheit als reine PC-Welten oder auch Unix-Umgebungen.
Ein weiterer Vorteil dieser Variante ist das im allgemeinen sehr gute Mehrbenutzerverhalten - kurze Antwortzeiten bei hohem Durchsatz - für das Großrechner ausgelegt sind, allerdings zu doch sehr hohen Kosten pro Arbeitsplatz.
Alle namhaften Hersteller verwenden heute TCP/IP
Ein typisches Merkmal von Datenbank-Servern auf Unix-Basis ist ihr Kommunikationsprotokoll TCP/IP. Dieses Protokoll stammt aus der Unix-Entwicklung der Berkeley University und kann aufgrund seiner weiten Verbreitung als herstellerunabhängig bezeichnet werden. Alle namhaften Hersteller von Unix-Systemen verwenden heute TCP/IP zur Vernetzung ihrer Systeme und zur Anbindung von Nicht-Unix-Systemen.
TCP/IP ist von Haus aus als heterogenes Protokoll ausgelegt; die Einbindung von MS-DOS, OS/2, VMS, ja sogar Großrechner-Betriebssystemen in ein TCP/IP-Netz ist kein Problem. Damit stehen Server, die über TCP/IP mit ihren Client kommunizieren, für all die genannten Systeme offen.
Durch verschiedene Erweiterungen über TCP/IP hinaus (zum Beispiel das "Network File System" NFS oder die zentrale Benutzerverwaltung "Yellow Pages") bieten TCP/IP-basierte Server-Lösungen auch andere, betriebliche und verwaltungstechnische Vorteile.
Ein offenes Problem auch von TCP/IP-basierten Server-Konfigurationen ist die Unterschiedlichkeit von Zeichensätzen, insbesondere bei der Unterstützung von nationalen Zeichensätzen: Während Unix-Systeme normalerweise im 7-Bit-ASCII-Code arbeiten, verwenden MS-DOS- und OS/2-Systeme den 8-Bit-IBM-PC-Code. Großrechner arbeiten typischerweise mit EBCDIC-Zeichensätzen, denen eine nochmals andere Codierung zugrunde liegt.
Gerade für die zentrale Datenablage in einem Datenbank-Server sind solche unterschiedlichen Codierungen untragbar. Im SQL/2-Standard kann der Benutzer datenbankspezifische Zeichensätze definieren, die im Datenbanksystem verwendet werden, unabhängig vom Zeichensatz des jeweils zugrundeliegenden Betriebssystems. Diese Weiterentwicklung von SQL erscheint für den sinnvollen Einsatz in heterogenen Umgebungen als sehr wichtig.
Hervorragende Wachstumsmöglichkeiten
Ein weiterer Vorteil von Unix-Systemen sind die flexiblen und weitgehenden Ausbaumöglichkeiten: Unix-Systeme können eingesetzt werden vom AT mit 2 MByte Hauptspeicher und einer 40-MByte-Festplatte bis hin zu Großrechnern mit riesigen Hauptspeicher- und Plattenkapazitäten. Damit bieten Unix-Systeme hervorragende Wachstumsmöglichkeiten. Insbesondere sind sie heute so portabel, daß auch ein Herstellerwechsel möglich wird.
Auch von der Datensicherheit her ist ein Unix-Server einem MS-DOS Server überlegen: Unix verfügt über Benutzerautorisierung und darauf basierende Dateischutzmechanismen. Damit können Datenbankdaten wirksam vor unbefugtem Zugriff geschützt werden. Freilich soll hier nicht verschwiegen werden, daß die Datensicherheit zu den meistgenannten Mängeln von Unix gehört und tatsächlich auch verbessert werden könnte.
Auch die Datensicherungsmöglichkeiten sind unter Unix besser: Leistungsfähige Bandgeräte (oder auch optische Platten) sind verfügbar, die Sicherheitskopien der Datenbankinhalte aufnehmen können.
Unix-Systeme bieten durch ihr sehr dynamisches Prozeßkonzept eine ausgezeichnete Basis zur Realisierung eines Servers, auf den von vielen Client aus parallel zugegriffen wird. Auch in einem solchen Fall ergeben sich noch akzeptable Antwortzeiten.
Diese Eigenschaft sorgt für ein gutes Kosten-Nutzen-Verhältnis; denn je mehr Client ein Server bedienen kann, desto niedrigere Kosten je Client entstehen.
Die Vorteile der Verwendung von Unix als Server-Betriebssystem lassen sich folgendermaßen zusammenfassen:
- Unix erlaubt durch den Einsatz von TCP/IP die beste Basis für die Integration aller vorhandenen Systeme, vom Großrechner bis zum PC;
- Unix bietet flexible Ausbaumöglichkeiten (sowohl hardwaremäßig als auch softwaremäßig);
- Unix bietet eine weitaus höhere Datensicherheit als OS/2;
- Unix bietet im Multi-Userbeziehungsweise Multi-Client-Betrieb eine gute Leistung;
- Insgesamt ergibt sich damit ein sehr gutes Kosten-Nutzen-Verhältnis.
Multi-Server-Datenbanken und verteilte Datenbanken
Die Diskussion über die Leistungsfähigkeit von Datenbank-Servern und ihr Antwortzeitverhalten zeigt, daß an einen Server nicht beliebig Client "angehängt" werden können, ohne das Gesamtsystem nachhaltig zu behindern.
Wenn aber die Forderung nach zentralen Datenbeständen aufrecht erhalten werden soll, kann die Leistungsfähigkeit von Datenbank-Servern nur gesteigert werden, indem man mehrere Server einführt, die auf einem verteilten Datenbestand arbeiten.
Das führt zu verteilten Datenbanksystemen, die den Benutzern die Illusion einer zentralen Datenbank vermitteln, die in Wirklichkeit auf mehrere Rechner verteilt ist.
Inwieweit verteilte Datenbanksysteme zukünftig praktische Relevanz erlangen, hängt wohl auch von der weiteren technischen Entwicklung dieser Systeme ab. Denn noch heute bietet außer einigen weniger bekannten Systemen (wie zum Beispiel Empress oder Transbase) keines der am Markt verbreiteten Datenbanksysteme ein uneingeschränktes Transaktionskonzept (einschließlich 2-Phasen-Commit) an.
Außerdem ist der technische Aufwand einer transparenten Verteilung (globale Schemaverwaltung, globale Optimierung, globale Synchronisation etc.) deutlich höher als bei einem nicht-verteilten Datenbanksystem, und zwar nicht nur dann, wenn es sich um echte verteilte Verarbeitung handelt, sondern oftmals auch dann, wenn nur ein Rechner für die Abarbeitung benötigt wird.
Eine andere Variante der Leistungssteigerung verzichtet auf die Forderung des zentralen Datenbestandes, erlaubt also die explizite Verteilung von Daten auf verschiedene Rechner (respektive Datenbanken). Dabei ist die redundanzfreie Datenpartitionierung von der Datenreplizierung, die wichtige oder häufig benötigte Daten auf mehreren Knoten speichert, zu unterscheiden.
Heterogene Multi-Server-Lösungen
In gewachsenen (Daten-)Umgebungen liegt oft - allein schon aus historischen Gründen - Datenpartitionierung und manchmal auch unkontrollierte Datenreplizierung vor, so daß sich die Frage der Integration solcher Datenbestände in ein gemeinsames Verarbeitungsschema stellt. Dies führt zu heterogenen Multi-Server-Lösungen, die sich von verteilten Datenbanksystemen im wesentlichen dadurch unterscheiden, daß der Anwender explizit die Datenbanken (und damit die Knoten) benennen muß. Weil die datenbankübergreifenden Anwendungen eher die Ausnahme sein werden, sind viele Datenbankzugriffe ausschließlich auf eine Datenbank beschränkt und somit von hoher Lokalität, was natürlich Performanzvorteile einbringt.
Möglichst offene, herstellerunabhängige Software
Multi-Server-Datenbanken können umgekehrt auch dazu benützt werden, die Engpässe von Single-Server-Systemen zu beheben, etwa durch explizite und systematische Datenverteilung auf mehrere Rechner, die den Benutzern auch explizit bekannt ist. Als (sehr einfaches) Beispiel sei genannt die Auslagerung der Lagerbuchhaltung aus der umfassenden Finanzbuchhaltung auf einen eigenen Rechner. Damit sind Finanzbuchhaltung und Lagerbuchhaltung weitgehend entkoppelt; allerdings müssen von Zeit zu Zeit, am besten nachts, bestimmte Salden von der Lager- in die Finanzbuchhaltung übertragen werden: Dies ist der Prototyp einer verteilten, auf zwei Knoten schreibenden Transaktion, die entweder auf beiden oder auf keinem der beiden Knoten erfolgreich beendet werden muß, oder in allen anderen Fällen automatisch auf beiden Knoten rückgängig gemacht werden muß.
Der Datenbank-Multiserver kann auch dazu benutzt werden, eine einzelne Datenbank zu spiegeln. Dazu wird keinerlei teure Spezial-Hardware benötigt; sie kann auf SQL-Ebene realisiert werden, indem jedes die Datenbank verändernde Statement im Rahmen einer verteilten Transaktion an beide Datenbanken geschickt und in jeder parallel verarbeitet wird. Mittels des Zwei-Phasen-Commits wird dann sichergestellt, daß beide Datenbanken stets "synchron" verändert werden. Leseoperationen können wahlweise auf einer der beiden Datenbanken abgewickelt werden. Durch eine derartige Spiegelung wird einerseits eine erhöhte Fehlertoleranz erreicht, andererseits kann (bei Leseoperationen) auch eine gewisse Lastverteilung erfolgen.
Dieser kurze Überblick über verschiedene Realisierungen von PC-Datenbanken, insbesondere von Client-Server-Modellen kann keine Antwort auf die Frage geben: "Welche Lösung ist die beste?". Denn die Wahl einer optimalen Architektur hängt ebenso von betrieblichen und organisatorischen Gesichtspunkten ab, wie von den zu erwartenden Anforderungen und der vorhandenen technischen Basis. Wer allerdings die Chance hat, neu zu beginnen, sollte heute auf möglichst offene, herstellerunabhängige Software (und Hardware) achten, um sich künftige Entscheidungen weitestgehend offen zu halten.