Search

Da angestrebt werden solite, die Ubersetzung von einem semantischen zu einem logischen Schema weitgehend zu automatisieren, waren fur beide, semantisches und logisches Datenmodell, strenge Formalisierungen sehr erwunscht. Nun existiert auf der logischen Ebene mit dem relationalen Datenmodell bereits ein solches Modell. Es ware also zu uberlegen, ob man das relationale Modell nicht einfach so erweitert, das es sich fur die Zwecke eines semantischen Datenmodells eignet. Gelange dies, so verfugte man insbesondere uber ein elegantes und automatisierbares Mittel fur den Entwurf relationaler Datenbanken.

In den einfuhrenden Betrachtungen dieses Buches hatten wir motiviert, dafi Datenbanken in einer vernetzten Welt ein wesentliches Mittel der Kooperation darstellen. Gemeinsam genutzte Datenbestande sollten fur die Kopplung der kooperierenden Nutzer sorgen. Je nach Kopplung stellen sich die Gemeinsamkeiten unterschiedlich dar, was Struktur und Umfang der Datenbasen angeht. Man sagt auch, das die kooperierenden Nutzer unterschiedliche Sichten auf die Datenbasen haben. Wir wollen im folgenden zunachst an Beispielen herausarbeiten, welche Probleme sich hierbei stellen.

Bei der Definition von Datentypen haben wir uns bislang stets auf eine feste Menge vordefinierter, atomarer Typen gestutzt (zur Beschreibung von Zeichen und Zeichenketten, numerischen Werten etc.) und neue Typen unter Verwendung von Typkonstruktoren und bestehenden Typen spezifiziert (einzige Ausnahme: deduktive Modelle). Ergebnis war ein strukturierter ???, und dessen Instanzen (Tupel, Records oder Objekte) waren mithin ebenfalls strukturiert. Diese „tiefe“ Strukturierung ist im Zuge der Einbeziehung fortgeschrittener Anwendungen nicht mehr immer gegeben. Vielmehr mussen Daten gespeichert und wiedergewonnen werden konnen, deren Inhalt sich nicht mehr mit Hilfe einer vorgegebenen Strukturierung deuten last. Die Interpretation hat stattdessen fallweise durch menschliche Beobachter zu erfolgen. Beispiele sind lange Texte, graphische Daten, Bilder, Audioinformation (Tone, Sprache, Musik, etc.) und eventuell sogar Videosequenzen.

Vom Blickwinkel der Machtigkeit aus gesehen zeichnet sich das relationale Datenmodell durch die folgenden Strukturierungsregeln aus: Es konnen Mengen von Datensatzen (Tupeln) gebildet werden (sogenannte Relationen), deren Komponenten jeweils einem als atomar betrachteten Standardtyp (z.B. Nummer, Zeichen(), usw.) angehoren. Bild 4.1 verdeutlicht dies graphisch.

Die logischen und semantischen Schemata, die wir in diesem Buch bisher kennengelernt haben, zeichnen sich eher durch Einfachheit ais durch Praxisnahe aus. Hauptsachlicher Gesichtspunkt war Ubersichtlichkeit, um an ihnen methodische Grundsatze illustrieren zu konnen. Gerade diese Einfachheit ist aber irrefuhrend. In praktischen Anwendungen kann die Zahl der Gegenstandstypen (im E-R-Modell) oder der Objektklassen (im objektorientierten Entwurf) rasch bis in die Grosenordnung von mehreren 100 kommen. Entsprechend wachst die Zahl der Beziehungstypen, Ereignisse, usw. Bei dieser Grosenordnung geht dem Entwerfer rasch der Uberblick verloren: Es fallt ihm schwer, Redundanzen und Widerspruche aufzuspuren und sicherzustellen, das der Entwurf die zu erfassenden Sachverhalte uberhaupt noch korrekt wiedergibt.

Bei aller Machtigkeit von SQL-2 werden naturlich die Einwande aus Kapitel 4 nicht gegenstandslos. Es gibt also genugend Grunde, zu einem anderen Datenmodell zu wechseln. Nun stehen hinter Datenmodellen ja aber auch kommerzielle Produkte und damit Markte, so das die diversen Datenmodelle eben auch in einem wirtschaftlichen Wettbewerb miteinander liegen. Dies gilt vor allem fur das relationale und das objektorientierte Datenmodell. Demgegenuber befassen sich NF2-Modell und deduktives Modell mit sehr speziellen Aspekten, die weniger eine Eigenstandigkeit von Produkten als eine Erganzung anderer Modelle nahelegen.

Das relationale Modell ist gekennzeichnet durch die Forderung nach „Atomizitat“ der Domanen. Das heist, die Domanen lassen sich (aus der Sicht des Datenbanksystems) nicht als Potenzmenge oder kartesisches Produkt aus einfacheren Wertevorraten darstellen. Im NF2-Modell wird bei unveranderter Machtigkeit das relationale Modell nun so erweitert, das als zusatzliche Orthogonalitat „komplexe“ Domanen zugelassen werden. Bild 5.1 zeigt die sich ergebenden Strukturierungsregeln, die das „puristische“ NF2-Modell bei der Bildung von Datentypen vorsieht.1

Der Implementierungs- oder logische Entwurf hat die Ubersetzung des semantischen Schemas in ein logisches Datenbasisschema zum Gegenstand. Das semantische Schema ist dabei durch das verwendete semantische Datenmodell bestimmt, das logische Schema durch die Entscheidung fur ein reales Datenbanksystem und damit dessen Datenmodell.

Wir besprechen als nachstes einen Vertreter semantischer Datenmodelle, der ausschlieslich fur den konzeptuellen Entwurf Anwendung findet, also dann spater im Implementierungsentwurf noch einer Ubersetzung unterworfen werden mus. Damit haben wir zugleich einen Vertreter vor uns, der auf das logische Datenmodell nur noch wenig Rucksicht zu nehmen braucht, oder mit anderen Worten, der es gestattet, den konzeptuellen Entwurf weitgehend unabhangig vom logischen Datenmodell ablaufen zu lassen. Allerdings mus der Gerechtigkeit halber festgehalten werden, das das hier zu besprechende Entity-Relationship-Modell (deutsch: Gegenstands-Beziehungs-Modell, kurz: E-R-Modell) vor knapp 20 Jahren entstand, als relationales und Netzwerkmodell die einzigen bedeutsamen Datenmodelle waren, und das deshalb an die Machtigkeit der semantischen Datenmodelle keine allzu hohen, weit uber diese Datenmodelle hinausgehenden Anspruche gestellt wurden.

Ein Datenmodell legt zwar die prinzipielle Funktionalitat eines Datenbanksystems fest, es sagt aber noch nichts daruber aus, wie sich die Funktionalitat auf eine vorgegebene Anwendung im einzelnen auswirkt oder wie eine Anwendung die Funktionalitat moglichst gut nutzt. Diese Nutzung schlagt sich vor allem im Datenbankschema nieder. Ein wesentlicher Schritt der Einsatz-vorbereitung fur ein Datenbanksystem ist daher der Datenbankentwurf. Der Datenbankentwurf umfast die Abbildung eines Ausschnitts der realen Welt (der sogenannten Miniwelt) auf ein Datenbankschema. Auf einer mit diesem Schema ausgestatteten Datenbasis lassen sich dann Daten in adaquater Weise speichern, wiedergewinnen und manipulieren. Bild 11.1 veranschaulicht diesen Sachverhalt.