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.

31.05.1985 - 

Nach Coddschem Modell könnte eigentlich jede Anwendung realisiert werden, aber:

Relationale DB läßt noch manche Wünsche offen

Relationale Datenbanken werden von den Anbietern vielfach als die Lösung aller anstehenden DV-Probleme angepriesen. In der Tat könnte dieses Modell einen Großteil der Schwierigkeiten beseitigen, die sich aus der Statik bestehender Systeme ergeben. Doch das Konzept wurde bisher nur unvollständig realisiert: Die Wahrung der Integritätsregeln ist noch in kaum einem DB-System Implementiert.

Ein voll relationales Datenbanksystem beinhaltet strukturelle Aspekte, Insert-Update-Delete-Regeln (Integritätsregeln), die durch die DBMS-Software abgedeckt werden, und eine mächtige Datenmanipulationssprache (DML) für die relationale Algebra. Hinzu kommt die Unabhängigkeit von der physischen Speicherung.

Die Daten werden in unstrukturierten Tabellen abgelegt (was beispielsweise in einer IMS-DB das Segment ist, ist hier eine Tabelle). Nun dürfen die Daten nicht etwa wie im alten Bandsatz mit multiplen Feldern oder Feldgruppen gespeichert werden, sondern der Tabellenaufbau hat nach bestimmten Regeln zu erfolgen.

Der Datenbankentwurf beziehungsweise das konzeptuelle Schema muß normalisiert sein.

Der Normalisierungsprozeß ist nichts anderes als ein Zerlegungsprozeß, mit dem Ziel, Redundanzen und Anomalien zu eliminieren und die Integritätsregeln eindeutig festzulegen. Anomalien sind Schwierigkeiten, die aufgrund von Datenredundanzen bei Insert, Delete oder Update auftreten können.

Normalisierte Tabellen enthalten keinerlei Strukturinformationen. Beziehungen von Tabellen untereinander werden nur über Daten realisiert. Somit braucht der Benutzer keine Kenntnis über die physische Organisation der Datenbank.

Die Datenmanipulationssprache (DML) ist nichtprozedural. Das bedeutet: Man sagt, was man will, nicht aber wie. Die Software navigiert automatisch durch die DB.

So einfach und klar das Relationen Modell ist (wenn es erst einmal verstanden wurde), kommt man natürlich nicht ohne Schulung der DV-Mitarbeiter und der Endbenutzer aus. Pro Mitarbeiter sollte mindestens eine Woche Schulung und nachfolgend ausreichend Gelegenheit zum Üben veranschlagt werden.

Zwar kann man sich die Syntax der DML, wie zum Beispiel SQL (Structured Query Language), auch im Selbststudium aneignen aber die Gefahr ist groß, syntaktisch richtige Anweisungen zu schreiben, die nicht optimal sind. Die Wirkungen können verheerend sein.

Ein Beispiel aus der "Lernzeit" des Verfassers soll das verdeutlichen: Für eine Abfrage waren fünf Tabellen zu vereinigen (Join). Die Suchmenge sollte durch Angabe von Schlüsseln eingeengt werden. Versehentlich wurde das nicht für alle Tabellen gemacht. Für jeden Record in einer Tabelle, der den Suchkriterien genügte, mußten zwei weitere Tabellen sequentiell abgearbeitet werden. Eine Hochrechnung ergab mehr als eine Milliarde I/Os, obwohl der Datenbestand lediglich 12000 Sätze enthielt. Der Vorgang wurde denn auch nach 30 Minuten und einer durchschnittlichen CPU-Belastung von 85 Prozent auf einer IBM 3083 abgebrochen.

Die Endbenutzerfähigkeit muß aus ähnlichen Gründen stark bezweifelt werden: In einer relationalen DB ist jedes Attribut (Feld) ein Suchkriterium. Wird nach einem Datum gesucht, auf das kein Index gelegt ist, muß der Datenbestand sequentiell durchforstet werden. Nicht auf jedes Attribut kann ein Index gelegt werden (Oracle beispielsweise empfiehlt, nicht mehr als fünf Indizes pro Tabelle). Suchvorgänge nach nicht indizierten Daten sind sequentielle Prozesse.

Zu dem Zeitproblem kommt, daß bei einem nicht korrektem "Join" Daten miteinander in Beziehung gebracht werden, die nicht zusammengehören. In einer programmierten Anwendung wird der Ersteller die Korrektheit der Kommandos testen; ein Endbenutzer wird kaum sein Kommando in einer Testdatenbank überprüfen.

In Informationssystemen, in denen in Transaktionen aus den eingegebenen Suchkriterien dynamisch die Abfrage-Kommandos zusammengestellt werden, sollten die dahinterstehenden Programme mindestens darauf hinweisen, daß der Suchprozeß lange dauern kann oder aber eine Batch-Verarbeitung aktivieren. Es ist unzumutbar, daß ein Bildschirm durch eine Abfrage für längere Zeit blockiert ist.

Eine Entscheidung, ob die Bearbeitung der Abfrage von kurzer oder längerer Dauer sein wird, kann das Programm nur fällen, wenn es Kenntnis von den verwendeten Indizes hat. Die Informationen über die verwendeten Indizes müssen entweder im Anwendungsprogramm fest gespeichert oder auf das DB-System "abgewälzt" werden. Die erste Möglichkeit schränkt die Flexibilität des Systems ein, die zweite wäre auf jeden Fall mit erheblichem Aufwand verbunden.

Wie in anderen DB-Systemen ist auch hier der Datenbankentwurf, das konzeptuelle Schema, von zentraler Bedeutung. Der Entwurf sollte unbedingt normalisiert sein, will man nicht Performance- und Integritätsprobleme in die Anwendung hineinkonstruieren. Ein gut geschulter Datenbankadministrator (DBA) sollte über die Datenbanken wachen.

Die meisten Systeme bieten einen Generator an, mit dem in sehr kurzer Zeit Transaktionen für die Tabellenbearbeitung erstellt werden können. Die Handhabung einer solchen Transaktion ist sehr gewöhnungsbedürftig, da sie total Funktionstastengestützt ist. Auch kann kein Einfluß auf die DML-Kommandos genommen werden; unter Umständen leidet gar die Performance darunter.

Als DML wird sich wahrscheinlich SQL durchsetzen - es ist heute bereits Quasi-Standard. Wie auf anderen Gebieten scheint sich offensichtlich auch hier die Kompatibilität zu IBM-Produkten verkaufsfördernd auszuwirken.

Eigentlich kann mit einer relationalen Datenbank jede Anwendung realisiert werden. Auch ohne Probleme - wenn man die Performance außer acht läßt. Ob es eine Stücklistenauflösung, ein Buchungssystem oder ein Informationssystem ist - mit einer relationalen DB ließe sich jedes Problem leicht lösen. Es müssen keine kaum zu handhabenden Gebilde von logischen Datenbanken erstellt werden (zum Beispiel wie im IMS), da in einer normalisierten DB jede Beziehung aufgebaut werden kann, nämlich über die Daten. Nur wacht heute die Software noch nicht über die Integrität der Daten.

Sind relationale Datenbanken nun als Konkurrenz der bestehenden Systeme zu sehen? Ich bin der Meinung: nein. Bei den derzeit zur Verfügung stehenden Zentraleinheiten und externen Speichern ist eine relationale DB für die meisten Standardanwendungen anderen Systemen unterlegen. Für Informationssysteme, die künftig einen immer stärkeren Anteil an den DV-Anwendungen einnehmen werden, gibt es kaum Konkurrenz.

Der Weg, der von der IBM mit DB2 beschritten wurde - es werden Programme zum Datenextrakt aus IMS-Datenbanken angeboten - zeigt daß auch der Marktführer eine relationale DB lediglich als ein zusätzliches Instrument sieht und nicht als ein Ersatz der bestehenden DB-Produkte.

Auch sind Systeme wie Adabas, mit denen sich Standardanwendungen ohne Performance-Einbußen realisieren lassen, sicherlich noch ein guter Kompromiß.

*Wolf-Dietrich Haneke ist Leiter des Bereichs interne Schulung und Weiterbildung bei der AGS Gesellschaft für Datentechnik GmbH, Geschäfts stelle München.

Vorteile

- Schnelle Implementierung

- keine Überlegungen Über Speicherungsformen erforderlich

- normalisiertes DB-Design kann 1 zu 1 übernommen werden

- dynamisch, leicht anpaßbar, leicht erweiterbar (Hinzufügen von Feldern, Indizes anlegen/löschen, Tabellen anlegen/löschen)

- Daten sind nicht physisch miteinander verbunden

- komprimierte Speicherung

- zentrales Data-Dictionary

- mächtige DML

- Jedes Feld in der Datenbank kann Suchkriterium sein

- fast alle Systeme haben einen Transaktions-Generator

Nachteile

- Integritätsprobleme

- durch Normalisierung zum Teil große Keyredundanz

- Performance

- hoher CPU-Bedarf

- nicht geeignet für Massendatenverarbeitung

- DML nur bedingt für Endbenutzer geeignet

- hohe I/O-Rate durch Normalisierung

- nicht geübter Anwender kann durch unkorrekte Abfragen das System lahmlegen

- wird nach nicht-indizierten Feldern gesucht, ist eine sequentielle Abarbeitung der Datenbank erforderlich (bei Joins multiplizieren sich die I/Os)