Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

18.04.1986 - 

User werden oft mit falschen Versprechungen geködert (Teil 2):

Nicht jedes RDBMS ist wirklich relational

Die Frage nach der Relationalität eines Datenbanksystems stellt inzwischen für viele Käufer eine entscheidende Überlegung dar: Fast jeder DB-Anbieter erhebt heute den Anspruch. über ein solches Produkt zu verfügen: nur wenige erkenne, wie weit entfernt sie indes von ihrem Ziel sind.

Kaum ein System, das heute von sich behauptet, von relational zu sein, erfüllt diese Anforderung wirklich. Der vorgeschlagene ANSI-Standard entspricht nicht von dem relationalen Modell, daher gewährleistet die Übereinstimmung eines DBMS mit dem ANSI-Standard keine Garantie relationaler Fähigkeiten. Obwohl der Standard modifiziert werden kann, sind die Anbieter bereits jetzt gut beraten, ihre Produkte über den Standard hinaus zu planen, um die DBMS-Bedürfnisse des Käufers von zu unterstützen.

In ihren Anzeigen und Handbüchern haben manche Anbieter den Begriff "minimal relational" durch "Vollständig relational" ersetzt, daher müssen strengere Bewertungskriterien angesetzt werden. Die in diesem Beitrag aufgeführten zwölf Regeln stellen einen Bestimmungstest dar, ob ein Produkt dem erhobenen Anspruch, vollständig relational zu sein, tatsächlich entspricht.

Im folgenden wird ein Stufenschema zur Messung der Übereinstimmung mit dem relationalen Modell dargestellt.

Ein wirklich relationales DBMS sollte mit den folgenden 12 Regeln übereinstimmen:

1. Informationsregel

2. Regel des garantierten Zugriffs

3. Systematische Behandlung von Nullwerten

4. Aktiver Oneline-Katalog auf der Grundlage des relationalen Modells

5. Regel der umfassenden Datenuntersprache

6. Regel zum Update von Abbildungen

7. Einfügen, Update und Löschen auf hoher Ebene

8. Physikalische Datenunabhängigkeit

9. Logische Datenunabhängigkeit

10. Integritätsunabhängigkeit

11. Verteilungsunabhängigkeit

12. Regel "Keine Unterversionen"

Diese Regeln beruhen auf der bereits zitierten Basisregel:

Für jedes System, das den Anspruch erhebt, ein relationales Datenbankmanagementsystem zu sein oder als solches angeboten wird, gilt: Dieses System muß in der Lage sein; Datenbanken vollständig mit Hilfe seiner relationalen Fähigkeiten zu verwalten.

Diese Regel muß gelten, ob das System nun irgendwelche nonrelationalen Fähigkeiten zur Behandlung von Daten unterstützt oder nicht. Jedes DBMS, das der Basisregel nicht entspricht, ist nicht als relationales DBMS einzustufen.

Allein die Übereinstimmung mit der Basisregel ist aber noch nicht ausreichend. Wenn nämlich die Informationsregel, die Regel über den garantierten Zugriff, die Regel zu systematischen Nullen und die Katalogregel nicht unterstützt werden, kann es möglich sein, daß eine Wahrung der Integrität nicht mehr gegeben ist.

Ein System, das diesen vier Regeln entspricht, unterstützt einen signifikant höheren Standard der Datenbankverwaltung und Kontrolle als frühere DBMS. Anwender sollten sich vergegenwärtigen, daß aller Voraussicht nach sowohl erfahrene als auch unerfahrene Benutzer mit einem relationalen Datenbanksystem arbeiten werden. Das Produkt muß also beiden dienen können.

Personen mit angemessener Autorisierung können aufgrund von Regel 1 und 4 (Informations- und Katalogregel) leicht mit Hilfe eines Terminals herausfinden, welche Informationen in einer Datenbank gespeichert sind. Es gibt Datenbankverwalter, die nicht in der Lage sind, zu bestimmen, ob eine bestimmte Information in ihrer Datenbank aufgezeichnet ist.

Regel 3 fordert systematische Unterstützung von unbekannter und nicht anwendbarer Information mit Hilfe von Nullwerten, die vom Datentyp unabhängig sind. Sie soll den Benutzern helfen, unnötige und möglicherweise kostenintensive Fehler zu vermeiden. Für den Anwender ist die Behandlung von Nullen besonders wichtig, wenn Mengenfunktionen wie Gesamtsumme und Durchschnitt angewandt werden. Über eine gute Nullwertbehandlung verfügt beispielsweise das Datenbankmanagementsystem "Orade". Der Benutzer kann hier spezifizieren, ob die Mengenfunktion Nullwerte ignorieren oder ein Null-Ergebnis ermitteln soll, wenn irgendein Nullwert vorliegt.

Im allgemeinen umkreist die Kontroverse immer noch das Problem der fehlenden und nicht anwendbaren Information in Datenbanken. Es scheint, daß angesichts der Komplexität der Nullbehandlung oft die Tatsache übersehen wird, wie kompliziert die Verarbeitung von fehlender und nicht anwendbarer Information schon in sich selbst ist. Das Problem wird nicht dadurch gelöst, daß auf programmiererspezifische Defaultwerte zurückgegriffen wird.

Regel 5 (Regel der umfassenden Datenuntersprache) ist aus mehreren Gründen wichtig. Erstens gestattet sie Programmierern eine interaktive Fehlerbeseitigung in den Datenbankstatements, Zweitens besagt sie, daß zur Definition von Relationen, die aus der Datenbank ableitbar sind, ein einziges Tool benutzt werden kann. Die Regel 6 (Update von Abbildungen) ist notwendig, um die logische Datenunabhängigkeit zu unterstützen.

Regel 7 erfordert beim Einfügen, Update und Löschen einen gleichzeitigen Zugriff auf "multiple records" und kann zu einer entscheidenden Kostenminderung bei der Kommunikation innerhalb einer verteilten Datenbank beitragen. Beinhaltet das System einen guten Optimierer, dann kann diese Regel auch zu erheblichen Einsparungen in CPU- und l/O-Zeit führen, egal ob die Datenbank verteilt ist oder nicht.

Wird die Unabhängigkeit (Regeln 8 bis 10 nicht unterstützt, so kann der Aufwand an Zeit und Geld leicht ins uferlose wachsen. Entwicklung und Wartung von Anwenderprogrammen und Terminalaktivitäten werden teurer sein. Es besteht sogar die Möglichkeit, daß Manager angesichts der zu erwartenden Kosten für die Programminstandhaltung nicht gewillt sind, die Veränderung bestimmter Geschäftspolitiken in Betracht zu ziehen.

Regel 12 (keine Unterversionen) ist beim Schutz der Integrität relationaler Datenbanken entscheidend. Zu viele Fälle sind bekannt, in denen Datenbankverwalter mit nonrelationalen DBMS bei der Kontrolle ihrer Datenbanken versagt haben, folglich waren sie nicht in der Lage, einen Integritätszustand aufrechtzuerhalten.

Viele Anwender ziehen keine klare Grenze zwischen dem Bereichskonzept und dem Attributkonzept einer Relation oder Spalte in einer Tabelle. Andere, oft die Anbieter selbst, lehnen das Bereichskonzept als "akademisch" ab . Die Antwort darauf lautet: Auch die Atombombe war akademisch!

Das Bereichskonzept ist in Wahrheit sehr wichtig, praktisch und einfach. Ein Bereich besteht aus dem gesamten Set legaler Werte, die in einer Spalte auftreten können. Die Spalte bezieht ihre Werte aus dem Bereich. Jede Spalte einer relationalen Datenbank hat genau einen Bereich, aber jede beliebige Zahl von Spalten kann sich einen Bereich teilen. Bereiche sollten aus mehreren Gründen unterstützt werden.

In einer Finanzdatenbank können zum Beispiel um den Bereich der US-Währung herum etwa 50 unterschiedliche Spalten definiert sein. Warum sollte diese Währungsdefinition 50mal wiederholt werden? In Datenbanken, die von nonrelationalen Systemen unterstützt werden, sind häufig inkonsistente Werttypdeklarationen für Felder zu beobachten, die eigentlich als zum gleichen Typ gehörig konzipiert waren.

Von einem DBMS kann nicht erwartet werden, daß alle zugelassenen Werte in einem Bereich gespeichert sind, außer wenn es sich nur um sehr wenige handelt. Es ist jedoch sehr vernüftig und wertvoll, darauf zu bestehen, daß ein DBMS bestimmte Werte speichert:

- Eine Beschreibung des Werttyps im Bereich für jeden einzelnen Bereich. Diese Information trifft auf die gesamte Datenbank zu und sollte im Katalog aufgezeichnet sein.

- Für jede Spalte den Namen des Bereiches, aus dem diese Spalte ihre Werte bezieht. Dieser Bereichsname ist ein Verweis auf die globale Definition.

Natürlich kann die Bereichsbeschreibung auch Aufnahmebegrenzungen enthalten. So läßt sich zum Beispiel spezifizieren, daß Zahlen, die in einem solchen Verzeichnis aufgeführt sind, nicht nur als "integer", sondern auch als "nicht negativ" definiert sein müssen.

Individuelle Spalten können zusätzliche Aufnahmebeschränkungen enthalten, wo diese semantisch zu rechtfertigen sind. In diesem Beispiel kann die Anzahl der sehr teuren Teile aus dem Verzeichnis auf ein bestimmtes, spezifisches Maximum begrenzt sein.

Teilen sich mehrere Spalten einen Bereich, liegt ein anderer Vorteil des Bereichskonzeptes darin, daß die Deklaration der Beschreibung von legalen Werten weitgehend oder sogar vollständig als Faktor entfällt. Sind zum Beispiel 50 verschiedene Spalten zur US-Währung definiert, so ist die Datenbank viel einfacher zu handhaben und zu ändern, wenn vermieden wird, für die US-Währung 50 verschiedene Deklarationen zu liefern.

Vor dem Erscheinen des relationalen Konzepts mußten die Anwender getrennte Deklarationen machen. Viele der 50 Spezifikationen in dem Beispiel würden sich folglich als miteinander inkompatibel erweisen. Eine Abwicklung der Deklaration, die diese Fehler verhütet, erreicht RDB von Digital Equipment, das über ein Konzept "globaler Felddefinition" verfügt. Aber RDB unterstützt Bereichseinschränkungen bei bestimmten Operationen nicht, zum Beispiel beim Zusammenfügen.

Ein weiterer Vorteil der Unterstützung des Bereichskonzeptes liegt darin, daß relationale Operationen wie Zusammenfügen und Trennen, die einen Wertevergleich zwischen verschiedenen Spalten beinhalten, durch das System eingeschränkt werden können. Ein DBMS kann den Vergleich von Datenbankwerten nur dann erlauben, wenn sie aus dem gleichen Bereich stammen und daher vom semantischen Standpunkt aus vergleichbar sind.

Eine derartige Einschränkung verhindert Fehler, die durch interaktives Arbeiten am Terminal, beispielsweise bei der Auswahl von Spalten in Operationen wie "Zusammenfügen" entstehen. Die falschen Antworten, die mittels dieser Fehler ermittelt werden, decken nur selten die Fehler selbst auf; in der Zwischenzeit können auf der Grundlage dieser falschen Antworten riskante Geschäftsentscheidungen getroffen werden.

Es ist aus verschiedenen Gründen wichtig, in einem Kommando die Fähigkeit zu unterstützen, das System die üblichen Vergleichseinschränkungen ignorieren zu lassen.

Das Bereichskonzept sollte nicht mit dem Hardware-unterstützten Datentyp vermischt werden, auch wenn es darauf beschränkt ist, Datentypen zuzuweisen. Gegeben sei eine Beispieldatenbank, die Lieferanten, Teile und Projekte auflistet. Es wird angenommen, daß die Hardware-unterstützten Datentypen der Seriennummern von Lieferanten und der von Teilen identisch sind: Jeder Typ besteht aus Ketten von 12 Zeichen bei festgelegter Länge. Das System muß diese beiden Datentypen immer noch unterscheiden halten und sich daran "erinnern", welche Spalten in dem einen und welche in dem anderen definiert sind.

Kommt eine Anfrage, alle Records die X3 als Lieferantenseriennummer enthalten, zu löschen oder zu archivieren, so kann das System eine derartige Transaktion korrekt abhandeln, wenn es diese Unterscheidungen treffen kann. Das System wird keinen Record, der X3 als Teileseriennummer enthält, löschen oder archivieren, und ebensowenig einen, der nicht X3 als Lieferatenseriennummer enthält.

Ein solcher Datentyp wird heute oft als Anwendungsdatentyp bezeichnet. Pascal unterstützt dieses Konzept, aber nur sehr wenige der gebräuchlichen Sprachen unterstützen dieses Konzept, Pascal ist hier die rühmliche Ausnahme. Die Pascal-Unterstützung schließt natürlich nicht Auswahlen, Vereinigungen, Zusammenfügen und Trennungen ein.

Das Bereichskonzept bildet die Grundlage dafür, daß das DBMS alle sinnvollen Auswahlen, Vereinigungen, Zusammenschlüsse und Trennungen kennt. Der Bereich läßt daher die Datenbank sinnvoll integriert sein, und zwar ohne die Verteilbarkeit zu beeinträchtigen.

Codasyl-Links und IMS-Links sollen dem gegenübergestellt werden. Sie repräsentieren zwar das Konzept von Codasyl und IMS, aber sie weisen gleichzeitig mehrere unvorteilhafte Einschränkungen auf. So wird die Verteilung einer Datenbank aufgrund der Einschränkungen und Komplexität verhindert, die ihre Datenstrukturen in Entscheidungen einbringen, wie die Daten entfaltet werden sollen.

Ein weiterer schwerwiegender Nachteil der Links besteht darin, daß es sich lediglich um Pfade handelt. Um zum Beispiel ein Ergebnis wie Zusammenfügen zu erreichen, müssen diese Pfade vom Anwendungsprogramm überschritten werden. Es scheint überflüssig, weitere Schwierigkeiten mit diesem Konzept anzuführen.

Viele relationale DBMS und Sprachen, SQL eingeschlossen, unterstützen das Konzept der Primär- und Fremdschlüssel nicht. Es ist nur schwer vorstellbar, wie diese Produkte die Regel des garantierten Zugriffs oder des Updates von Abbildungen unterstützen können, ohne dem System bewußt zu machen, welche Spalten den Primärschlüssel jeder Banktabelle bilden.

Weiterhin erscheint es kaum plausibel, daß diese Produkte die Regeln der Bezugsintegrität oder des Updates von Abbildungen unterstützen könnten, ohne klare Unterstützung von sowohl Primär- als auch Fremdschlüsseln zu bieten. In SQL sollte zum Beispiel das Kommando, "Create Table" erweitert werden, um dem Anwender die Bestimmung zu gestatten, welche Spalte oder Spalten den Primärschlüssel und welche den Fremdschlüssel bilden. Zusätzlich sollte es in SQL ein neues Kommando "Create Domain" geben.

Abbildung 1 stellt die Übereinstimmung von DB2 (IBM), IDMS/R (Cullinet Software, Inc.) und Datacom/DB (Applied Data Research, Inc.) mit dem 12 Regeln dar. Diese Beispiele wurden aufgrund ihrer großen Unterschiede ausgewählt. Diese Wert repräsentieren Übereinstimmungszählungen mit jeder Regel (Wert 1 für "ja", Wert 0 für "teilweise" oder "nein").

Die Informationsregel ist so grundlegend bedeutsam für den relationalen Ansatz, daß die Übereinstimmung eines Systems mit dieser Regel einen viel höheren Wert als 1 erhalten müßte. Es wäre nicht übertrieben, mit Faktor 10 zu gewichten. Dennoch sollte die Zuweisung verschiedener Punkte für verschiedene Eigenschaften ebenso vermieden werden wie Teilwerte zur teilweisen Unterstützung einer Eigenschaft: es ist zu einfach, in dieser Angelegenheit subjektiv zu sein.

DB2 schneidet in der Übereinstimmungsauswertung recht gut ab. Nur wenige andere DBMS erreichen bei den 12 Regeln höhere Werte, war auch einige andere gleich gut anschneiden. Sowohl IDMS/R als auch Datacom/DB lassen zu, daß Information in der Reihenfolge von Records im Speicher und in Wiederholung von Gruppen repräsentiert wird - so verletzen sie direkt die Informationsregel. Information kann im Fall von IDMS/R auch in Verbindungsgliedern zwischen Recordtypen dargestellt sein.