Inhaltsverzeichnis

Vorwort

1. Übersicht über die Begriffswelt

1.1 Relation und Relationship

1.2 Grundlegende Begriffe

1.3 Struktur einer Relation

1.4 Entity Relationship Diagram (ERD)

1.5 Datenstrukturentwurf

1.6 Kommentar: Der Besen ist der beste

2. Objekttypen

2.1 Funktionale Abhängigkeit und Redundanz

2.2 Identbegriffe / Primärschlüssel

2.3 Kommentar: Komplexe Attributtypen

3. Beziehungstypen

3.1 Verweise und Pointer

3.2 Semantik der Beziehungen

3.3 Beziehungsrelationen und Auflösung von m:n-Beziehungen

3.4 Welt-Sichten und Erreichbarkeit

3.5 Kommentar: Die Zerschlagung des gordischenKnotens

4. Das Entity-Relationship-Diagramm (ERD)

4.1 Prinzipien

4.2 Schrittweise Vergröberung

4.3 Ansatz zur Parametrisierung durch alternative Verweise

4.4 Kommentar: Ein Vorschlag zur Standardisierung von Datennamen

5. Relationen und Relationenalgebra

5.1 Relationen

5.2 Normalformen

5.3 Beispiel zur Normalisierung

5.4 Operationen auf Relationen

5.5 Kommentar: »Kumulieren & Panaschieren«

6. Datenstrukturen in Datenbanken und Dateisystemen

6.1 Hierarchie und Defaultwerthierarchie

6.2 Stücklistenstrukturen

6.3 Alternative Verweise

6.4 Rekursive Strukturen

6.5 Vorgänger / Nachfolger

6.6 Gruppenbildung

6.7 Nachbarschaft / Paarbildung

6.8 Parametrisierung

6.9 Ansinnen: Totale Parametrisierung

7. Leistungen eines modernen DBMS

7.1 Zwölf Coddsche Regeln als Maß der »Relationalität«

7.2 Zugriff über beliebige Attribute, aber ...

7.3 Wünschenswerte Eigenschaften eines DBMS

7.4 Verteilte Datenbanken: 13 Datesche Regeln

7.5 Kommentar: Thesaurus als Zauberwort

8. Entwurfsziele: Anzustrebende Produkte & Ergebnisse

8.1 Attributtypen und Data Dictionary

8.2 ERD, Objekttypen und Beziehungstypen

8.3 Regeln zu Integrität, Konsistenzerhaltung und Nichtwertbehandlung

8.4 Datenschutz und Zugriffsberechtigung

8.5 Mengengerüst und Transaktionsraten

8.6 Kommentar: Die Abbildung der Miniwelt: Sichten & Views

9. Ein kleines Beispiel (Chargen)

9.1 Die Struktur von Chargen: Aufgabenstellung

9.2 Split und Union: Lösung

9.3 Kommentar: Alles nach Schema-K.

10. Beziehungskombinatorik

10.1 Der relationale Knoten …

10.2 … und seine Auflösung

10.3 Beispiel: Wein-DB

10.4 Kommentar: Das Entity-Relationship-Diagramm in der Krise

11. Entwurfsprinzipien und Modellbildung

11.1 Besinnung auf das Wesentliche

11.2 Das Denken in Ordnungsbegriffen

11.3 Begriffssicherheit

11.4 Problemlösen nicht als großer Wurf, sondern als iterativer Prozeß

11.5 Kompromiß & Konsistenz

11.6 Individuelle Erfahrungen und typische Entwurfsfehler

11.7 Kommentar: Belohnung der Umständlichkeit

12. Einzelne spezielle Aspekte

12.1 Existenzbedingungen und Erfassungsreihenfolge

12.2 Die Existenz von »variablen Konstanten (TKT)«

12.3 Ereignisse und Gültigkeits-Zeitspannen

12.4 Mehrsprachigkeit und alternative Ausprägungen

12.5 Kommentar: Navigare necesse est.

13. Ein großes Beispiel (Das Prüfwesen der Fa. PSEUDO GmbH & Co.)

13.1 Allgemeine Aufgabenstellung

13.2 Spezielle Aspekte

13.3 Einzelne Lösungsstrukturen

13.4 Eine Gesamtlösung

13.5 Noch eine apokryphe Ergänzung

14. View Manager und »Sicht-Knechte«

14.1 Daten – Methoden – Funktionen

14.2 Objektorientierung

14.3 Aspekte von View Managern

14.4 Abstrakte Datentypen als konventionelle »Sicht-Knechte«

14.5 Kommentar: Werkzeuge ersetzen Denkweisen …

15. Navigation in Datenstrukturen

15.1 Datenbankanfragesprachen

15.2 Navigation als Suchstrategie

15.3 Eindeutigkeit des Zugriffspfades

15.4 Navigationspfade als Petri-Netz

15.5 Kommentar: Unzulänglichkeiten

16. Implementierung einer Datenstruktur

16.1 Das verwendete DBMS und die Definition der Definition

16.2 Definition der Datenstruktur: »Chargen«

16.3 Views (»Layouts«) und Suchanfragen

16.4 Spezielle Aufgabe: Chargenauflösung

16.5 Kommentar: Maßstäbe für die Auswahl eines DBMS

17. Abschließende Überlegungen

17.1 Auflösung des Dogmas

17.2 NF(hoch)2 – geschachtelte Relationen

17.3 Gewaltige Objekte

17.4 Typenhypothesen

17.5 Multimedia-Datenbanken

17.6 Erweiterung des Datenbankentwurfs

17.7 Nachwort: Die Gratwanderung

Literaturverzeichnis

Index

---

Helmut Dreßler: Datenstrukturentwurf Vom Faktenchaos zur Anwenderdatenbank

R. Oldenbourg Verlag München Wien 1995 • 288 Seiten – früher DM/ sFr 98,- öS 765,-

Restauflage nun: € 25,00 bei: Buchbestellung (inkl. Versand und Mwst.)

---

 

Wenn Sie die »rätselhafte« Graphik auf dem Titel erklärt haben möchten – Stichwort: »Beziehungskombinatorik« – dann lassen Sie es sich gefallen: Die Graphik ist dort sogar farbig, und in anderen Werken sucht man diese wichtige Idee, soweit ich weiß, vergebens.

Im folgenden werden einzelne, auch heute noch wichtige Aspekte herausgestellt, etwa an den Stellen des Inhaltsverzeichnisses, wo sie behandelt werden, im Rahmen des hier vorhandenen Platzes:

 

• Im Kapitel-1 werden wesentliche Begriffe des gesamten Buches vorweggenommen, denn die Leserinnen und Leser eines solchen Werkes bringen ganz sicher Vorkenntnisse mit. Sie sollen synchronisiert werden.

 

• Die allermeisten, die über »Relationale Datenbanken« schreiben und reden, verwechseln Relation mit Relationship. Ich schätze, es sind 90 % der Schreiber; dabei haben beide buchstäblich nichts miteinander zu tun, weil sie aus zwei getrennten Begriffswelten stammen: Relationen sind keine Beziehungen, sondern Tabellen, die durch Relationen-Operationen (z.B. »JOIN«) zu neuen Relationen verknüpft werden können. Relationships stammen aus dem ERD und bilden – real mittels Pointer – Beziehungen zwischen »Dateien« (in der anderen Begriffswelt: »Relationen«) ab.

 

• Der »Besen« ist die anschauliche Darstellung (siehe Titelbild!) für Relationships und viel übersichtlicher und anschaulicher als die dummerweise übliche »Pfeil-Doppelpfeil-Darstellung«, bei der man immer erst suchen muß, an welchen Enden wieviele Pfeilspitzen angebracht sind.

 

• Korrekt stellen Entities die »Objekttypen« dar, also Mengen von einzelnen Objekten (Relationen, Dateien, Tabellen), und Relationships sind Mengen von Beziehungen (Zusammenhängen, Pointern, …)

 

• – Solche semantischen m:n-Beziehungen aufzulösen und daraus zwei 1:n-Beziehungen zu machen mit einer »Vermittler-Relation«, ist eine der sehr oft nötigen Konstruktionen. Und wie anschaulich und auf den ersten Blick zu erkennen ist doch das so aufgelöste Konstrukt:

 

• Datennamen sind in der Vergangenheit meistens völlig willkürlich von Programmierern ausgedacht worden und waren niemals nach einheitlicher Systematik konstruiert. Vor allen Dingen »derselbe« Begriff kam im Unternehmen mit unterschiedlichen Namen vor, und derselbe Name betrifft oft verschiedene Rollen des Begriffs. Hier nur angedeutet deshalb mein Vorschlag für Attributnamen in Datenbanken als Zusammensetzung aus: KÜRZEL_INFOTYP_ROLLE_ …_NUMMER_BESTIMMUNG_…

 

• Rekursive Strukturen sind manchmal außerordentlich nützlich, wenn Tabellen einer Entität auf andere Tabellen derselben Entität verweisen. Ihre Möglichkeiten werden erörtert und später bei dem Beispiel »Chargenauflösung« exzessiv verwendet.

 

• Lange vor XML habe ich mit der »Totalen Patametrisierung« einen Vorschlag gemacht, nach dem in einundderselben Datenbank nicht nur die Daten, sondern auch ihre zugehörigen Definitionen abgelegt sind, so daß »eine Datenbank sich selber kennt«, denn die immer wieder nötigen SQL-Formulierungen, wenn gesucht werden muß, bilden doch nur die Struktur ab, die längst schon realisiert worden ist.

 

• »Datenstrukturentwurf« ist eine Aufgabe, also eine komplexe Tätigkeit, aber diese ist bestimmt durch die in ihr geforderten Resultate: Diese »Produkte & Ergebnisse« werden genau beschrieben und hier im Kapitel-8 ausführlich behandelt. Dabei ist »Data Dictionary« ein Wort mit doppelter Bedeutung: DD ist die Attribut-Sammlung für eine Anwenderdatenbank, DDS ist – ganz unabhängig davon – ein System-Werkzeug zur Verwaltung eines DD. Ein solches Data-Dictionary-System übrigens bieten wir (D&W) auf dem Markt an, realisiert ist es mit Microsoft.ACCESS.

 

• Das Beispiel »Chargen-Auflösung« wird im Buch nicht nur entworfen, sondern auch implementiert und getestet. Damit die Geschichte jeder Charge mit »weinähnlicher Flüssigkeit bei der Firma Pansch & Co. auch nach beliebigem Chargensplit und nach beliebigen Chargen-Vereinigungen jederzeit vorwärts und rückwärts, auch bezüglich der enthaltenen Mengen, zu verfolgen ist, braucht es eine ausgeklügelte Datenstruktur mit Selbstbezügen und pfiffigem Algorithmus, dieser wird erst im Kapitel-16 vorgestellt. Hier nur das ERD:

• Das Buchtitelbild bezeichnet eine Dreifachauflösung m:n:p. Diese drei stellen Primärrelationen dar, die aber vielfältig miteinander in Beziehung stehen. Das sehr nützliche Dogma der Normalformen besagt u.a., daß ein Attribut nur gerade mit den Schlüsselbegriffen assoziiert werden darf – sonst gäbe es Redundanzen und in der Praxis auch ungetriggerte Widersprüche –, wenn es nicht genau in einer Relation untergebracht wird, die sich auf alle drei oder zwei der Primärrelationen bezieht. So kann sich eine (hier die vollständige) Beziehungskobinatorik ergeben: …
• … Die drei Beziehungen m:n / n:p / p:m werden durch insgesamt neun 1:n-Beziehungen abgelöst. Und wenn gar vier Primärrelationen existieren, … dann gibt es dafür das außerordentlich anschauliche 10.3 Beispiel: Wein-DB.

 

• Das große Beispiel ist eins, das in seiner Komplexität ganz sicher in keinem DB-Entwurfsbuch vorkommt. An ihm kann sich jemand abarbeiten, der wirklich für die Praxis den Datenstrukturentwurf lernen will. Wenn jemand wissen will, worum es da genau geht – nämlich um das Prüfwesen für Ewige Wahrheiten – kann sich den Beginn des Kapitels-13 reinziehen.

 

• Es gibt kaum ein oder kein IT-Thema, wo so gepfuscht wird wie bei der DB-Zugriffstechnik. Alle Leute, selbst noch heute, formulieren ihre individuellen SQL-Statements, und die Zugriffsalgorithmen (mit Ausmahmebehandlung usw.) werden bestenfalls kopiert. Wirkliche Objektorientierung – also die konsequente Verwendung Abstrakter Datentypen – findet nicht statt. Gar Batch-Verarbeitung und Gruppenwechsel … oh-weh! Ausnahmen soll es geben, aber in verschwindend geringer Anzahl. – Meine Methode der View Manager in 5-Schichten-Architektur ist beschrieben und in PSEUDO-CODE verfügbar. Man muß mich nur fragen.

 

• Der Herr E. F. Codd hat zu seiner Zeit – sie ist entschwunden – propagiert, man könne alle Zugrffe mit Relationenalgebra bewerkstelligen, SQL und Konsorten. Das war deswegen ein Irrtum, weil es oft einen mehrstufigen Entscheidungsprozeß geben muß, innerhalb dessen erst entschieden werden kann, auf welche Zwischendaten nun zugegriffen werden soll, um einen gesamten View zu erzeugen. Also muß oftmals navigiert werden. Wie man das vernünftig planen kann, ist im Navigationsdiagramm beispielhaft als Petri-Netz ausgearbeitet.

 

• Einer der kompliziertesten und kompaktesten Algorithmen, die ich in meinem Leben vollbracht habe, ist der mit der kompletten, allgemeingültigen »Chargenverfolgung«. Und er ist auch die Frucht der Konstruktion (s.o.) mit zwei rekursiven Beziehungen zwischen den Chargen!

 

• Manches von dem, was ich mir vor 1995 vorgestellt habe, ist inzwischen realisiert. Die Objektorientierten Datenbanken lassen in der Praxis immer noch auf sich warten, aber Multimedia ist ein Thema. Nur die NFNF-Datenbanken (non first normal form) sind eventuell kein Thema mehr. Jetzt strebt alles hin zu XML, aber welcher Anteil des Strebens davon Modeerscheinung ist und wieviel tatsächlicher Nutzen – im Sinne »eine Datenbank "kennt" sich selbst« – wird man abwarten müssen.

 

• Die Gratwanderung zwischen dem Chaos in den Niederungen der bloßen Praktiker und dem Formalismus in den Abgründen der reinen Theoretiker hat zu unserem Logo geführt:

Dreßler & Wagner – Beratung

 

• Die Restauflage hat mir, als sich das Buch für DM 98,– nicht mehr von selbst verkaufte, der Oldenbourg-Verlag zur Verfügung gestellt. Man kann es bei mir (inklusive Versand und Mehrwertsteuer) zum halben Preis kaufen.

---

 

 

Kaufen!