Günstiges Laufzeitverhalten und reduzierter Speicherplatzbedarf:

DB-Erfolg durch Redundanz und Inflexibilität

18.07.1980

NÜRNBERG (je) - Die Güte des logischen Datenbankdesigns ist für die Leistungsfähigkeit einer Datenbank-Implementierung zumindest ebenso ausschlaggebend, wie es systemtechnische Leistungsmerkmale des ausgewählten Datenbanksystems sind. Von dieser Grundthese aus entwickelte Dr. Christoph Meller eine Methode des informationsbedarfsorientierten logischen Datenbankentwurfs. Meller befaßt sich bei der Robert Bosch GmbH, Nürnberg, schwerpunktmäßig mit DB/DC-Anwendungen.

Mellers DB-Designansatz, über den er in Heft 6/1980 der "Angewandten Informatik" ausführlich berichtet, basiert auf Erfahrungen, die er mit dem bei Bosch eingesetzten Siemens-Datenbanksystem UDS (unter KDCS und Asmus) gesammelt hat. Der nachfolgende Beitrag stützt sich auf die in der "Allgemeinen Informatik" gemachten Ausführungen und übernimmt die dort abgebildeten Tabellen und Grafiken.

Der Datenbankentwurf, formuliert Meller, stellt sich als Aufgabe dar, eine logische Datenbankstruktur aufzubauen und diese logische Struktur auf physischen Speichermedien abzubilden.

Das logische Datenbankdesign (Bildung von Datenelementen und Definition von datenbankmäßig realisierten Beziehungen zwischen diesen) wird, so sieht es der Autor, von einem großen Teil der Anwender noch als schlecht strukturierbare Gestaltungsaufgabe angesehen und als solche auch realisiert. In vielen Fällen entsteht ein endgültiger Datenbankentwurf auf dem Wege iterativer Probierverfahren und erreicht nie die Effizienz wie bei Verwendung eines systematischen Entwurfsverfahrens, das von Anfang an sämtliche Anwendungsparameter für die Datenbank einschließt.

Der logische Datenbankentwurf, unterscheidet der Autor, kann so aufgebaut sein, daß sämtliche sinnvollen logischen Beziehungen zwischen zu bildenden Satzarten und logischen Segmenttypen der Datenbank im Entwurf Berücksichtigung finden; er kann sich aber auch darauf beschränken, diejenigen Retrieval- und Update-Funktionen und die dadurch bedingten Satzbeziehungen abzudecken, die sich aus dem konkreten Anwendungsfall heraus als notwendig erweisen. Eine solche informationsbedarfsorientierte Methode des Datenbankdesigns kann für sich die Vorteile eines besseren Laufzeitverhaltens und eines geringeren Speicherplatzbedarfs der physischen Datenbank in Anspruch nehmen. Allerdings setzt ein solcher Ansatz voraus, daß die Anforderungen an die Datenbank exakt und vollständig definiert sind. Er geht zu Lasten der Flexibilität. Diese aber, sagt Meller, kann angesichts des dafür nötigen Aufwands nicht allein als sinnvolle Zielvorstellung beim Datenbankentwurf betrachtet werden.

Meller stellt einen bedarfsorientierten Ansatz des Datenbankdesigns vor, wie er bereits in der Praxis (mit Einschränkungen) erfolgreich angewendet worden ist: Bei der Umstellung auf ein Datenbanksystem Datenprofil und -volumen (qualitativ und quantitativ) zu erfassen, das in veränderter oder nicht veränderten Form in ein integriertes Datenbanksystem übernommen werden soll. Um der beabsichtigten Neugliederung der Datenbasis nicht vorzugreifen, empfiehlt der Autor, sollte diese Datensammlung auf der Ebene von Einzeldaten (Feldern) oder nicht sinnvoll trennbaren Datengruppen (Feldgrappen) vorgenommen werden. Ein Beispiel dafür (aus dem Anwendungsbereich Betriebsdatenerfassung) zeigt Bild 1.

In Bild 1 sind in vereinfachter Form Einzeldaten/Datengruppen aus einem bisher mit konventioneller Dateiverwaltung abgewickelten definierten Aufgabengebiet aufgeführt. Diese Aufstellung lehnt sich meistens - wie auch in diesem Fall - an die Gliederung im Rahmen der bisherigen Dateiorganisation an. Diese Datensammlung ist Ausgangspunkt für die folgende Anwendungsanalyse, die die Ermittlung der geeigneten Datenbankstruktur vorbereitet, und in deren Verlauf sich bestimmte Daten als künftig überflüssig erweisen können oder neu in die Datensammlung aufzunehmen sind.

Als wesentliche Bestimmungsgrößen des logischen Datenbankentwurfs definiert Meller die Hierarchie zwischen den bisher beziehungslos nebeneinander stehenden Einzeldaten (Datengruppen) sowie Festlegungen zur Art logischer Beziehungen zwischen diesen. Zur Strukturierung wird in einer Matrix aus Feldnamen in der Vertikalen und anwendungsbezogenen Zugriffen in der Horizontalen für jedes von einem Datenbankzugriff betroffene Datenfeld eine Kennziffer für eine hierarchische Stufe vergeben.

Eine solche Ziffernvergabe kann sich über mehrere Stufen erstrecken, wodurch der aufsteigenden Reihenfolge der Rangziffern folgend für eine konkrete Datenbankabfrage quasi der logische Weg durch die Datenbank nachgezeichnet werden kann. Wird im Zuge einer Abfrage von einem hierarchisch niedriger stehenden auf ein hierarchisch übergeordnetes Element verwiesen, so erhält das ranghöhere Datenelement eine um den Wert 1 kleinere Kennziffer als das untergeordnete Element mit dem Zusatz "R", der auf eine rückwärts verlaufende Abfragerichtung hinweist.

Bild 2 zeigt einen stark vereinfachten Ausschnitt einer Gegenüberstellung von Datenelementen und Datenbankzugriffen, wie sie oben erläutert wurde. Diese Matrix beschränkt sich auf vier Retrieval-Zugriffe (Spalte 1 bis 4) und zwei Update-Funktionen (Spalten 5 und 6). Am Beispiel der Datenbankabfrage "gefertigte Menge einer Fertigungskostenstelle" erklärt Meller diese Gegenüberstellung.

Oberster Ordnungsbegriff und zugleich Einstiegspunkt in die Datenbank ist im Rahmen dieser Abfrage das Feld Fertigungskostenstelle (fkst) mit der Kennung 1. Von dieser Kostenstelle ausgehend, müssen sämtliche Arbeitsgänge, die in der vorgegebenen Kostenstelle bearbeitet werden, aufgerufen und abgearbeitet werden. Da hier eine 1:n-Beziehung vorliegt, wird dem Feld Arbeitsgangnummer (agnr) und sämtlichen Feldern, die in einer 1:1-Beziehung zu diesem stehen und ebenfalls benötigt werden, die Kennziffer 2 zugeordnet. Für jede Arbeitsgangnummer können wiederum mehrere Fertigmeldungen mit entsprechender Fertigungsmenge (fmenge) vorliegen, die den logischen Weg durch die Datenbank auf eine dritte Ebene (Kennziffer 3) führen. Die Vergabe der Kennung 1 R für die Felder Produktnummer, Kundennummer etc. resultiert aus der Tatsache, daß diese Felder von der Ebene 2 aus angesprochen werden und in einer 1:nRelation zu den Feldern der Stufe 2 stehen.

Als Gegenstück zu der eingangs vollzogenen Zerlegung des Gesamt-Datenbestandes, in der Datenelemente aus übergeordneten herkömmlich aufgebauten Datensätzen herausgelöst wurden, kann nach Auffassung des Autors, die Phase aufgefaßt werden, in der entsprechend den Ergebnissen der Anwendungsanalyse Datenelemente zu logischen Segmenten verknüpft werden. Dies ist ein formaler Prozeß, in dem sämtliche Elemente mit gleicher Kennung zu einer Einheit zusammengezogen werden. Dahinter steht die Absicht, den jeweiligen Informationsbedarf der Datenbank-Benutzer durch möglichst wenige unterschiedliche logische Segmente abzudecken, um zeitaufwendiges Springen zu vermeiden. Die Zusammenfassung zu logischen Segmenten, wie sie sich im erläuterten Beispiel ergibt, ist aus Bild 3 ersichtlich.

Aus Bild 3 resultiert auch eine erste Rangordnung der neu gebildeten Segmenttypen. Überträgt man die Aussagen bezüglich der Über- und Unterordnung aus Bild 2 in eine quadratische 0/1-Matrix mit den Segmentnamen in der Vertikalen und Horizontalen, wobei eine 1 in einem Feld der Zeile X und der Spalte Y eine bestehende Unterordnung des Segments Y unter das Segment X bedeutet (owner-member), so ist die Datenbankdesignphase auf logischer Ebene abgeschlossen (Bild 4).

In Form des üblichen Datenbankdiagramms stellt Meller die für das Beispiel herangezogene Datenbankstruktur vereinfacht wie in Bild 5 dar.

Eine sehr simple Ursache für die Notwendigkeit, den erläuterten Entwurf modifizieren zu müssen, sieht Meller beispielsweise im Tatbestand zu umfangreicher logischer Segmente, der zu einer ungünstigen Ausnutzung des physischen Speicherplatzes führt und eine Aufsplittung eines oder mehrerer Segmente erforderlich macht. Weiterhin können Anforderungen an das Zeitverhalten (Dialogprogramme) eine Überarbeitung des Entwurfs empfehlen.

So ist es möglich, daß sich aus dem dargestellten Verfahren für eine bestimmte Datenbankabfrage ein logischer Weg durch die Datenbank ergibt, der aufgrund einer zu vielgliedrigen Beziehungskette den Anforderungen an das Zeitverhalten nicht mehr gerecht wird. In solchen Fällen ist eine Korrektur des Entwurfs dahingehend notwendig, daß direktere Verkettungen realisiert werden. Von besonderer Bedeutung ist dabei unter anderem die genaue Kenntnis des (zu erwartenden) Mengengerüstes. Ebenso können Umstrukturierungen notwendig werden, wenn der logische Datenbankentwurf n:m-Relationen hervorgebracht hat, die in dieser Form physisch nicht ohne weiteres zu realisieren sind. Nicht zuletzt, unterstreicht Meller, lassen sich Korrekturen eines Datenbankentwurfs, die die Performance verbessern, erzielen, indem man von der Forderung nach maximaler Redundanzfreiheit abrückt.

Es kann, sagt er, nicht übersehen werden, daß im Streben nach maximaler Redundanzfreiheit die Gefahr eines unverhältnismäßig hohen und zeitraubenden Verwaltungsaufwandes liegt. Wenn durch Datenredundanz, bezogen auf wenige Datenelemente, Datenbankzugriffe (zu anderen logischen Segmenten) eingespart werden können, liegt das Zugeständnis begrenzter Datenredundanz nach Meinung des Autors im Interesse von Performance und auch Überschaubarkeit (durch Einschränkung der Anzahl von Satzbeziehungen) des Gesamtsystems.

Es wurde eine Vorgehensweise des informationsbedarfsorientierten logischen Datenbankdesigns vorgestellt, die - so sieht es Meller - in abgewandelter Form für die unterschiedlichsten Anwendungsfälle mit exakt umrissenen Aufgabenbereich einsetzbar ist. Vorteile der aufgezeigten Methode liegen demnach in der Systemoptimierung in bezug auf Speicherplatzbedarf und Antwortzeitverhalten.

Im Zuschnitt des logischen Konzeptes auf eine statisch definierte Anwendung liegen aber auch mögliche Unzugänglichkeiten, räumt Meller ein. Denn da nur die in der Konzeptionsphase definierten Informationsbedürfnisse realisiert werden, kann die der Methode anhaftende unzureichende Flexibilität nachträgliche Überarbeitungen des Datenbankentwurfs erforderlich machen, die gerade durch diese Methode vermieden werden sollten.

Modifikationen der Datenbasis (Ergänzung um weitere Tabellen), wie sie bei Bosch in einem konkreten Fall erforderlich wurden waren ohne ein logisches Entladen und Laden der Datenbasis und ohne sonstigen größeren Aufwand nicht möglich. Eine wesentliche Prämisse der dargestellten Methode, folgert Meller, ist somit der seitens der Benutzer exakt definierte und auch für die Zukunft gültige Informationsbedarf.

Eine weitere Prämisse nämlich die Einschränkung auf nicht zu umfangreiche Datenmodelle, ergibt sich aus der manuellen Vorgehensweise des Verfahrens, die bei sehr umfangreichen Datenmodellen zu unvertretbar hohem Aufwand und zu Unübersichtlichkeit führen würde. Meller resümiert: Bei Erfüllung der genannten Anwendungsprämissen, kann die dargestellte Methode nach den bisherigen Erfahrungen als erfolgreich angesehen werden.