Historische Datenmodelle

1. Historische Datenmodelle Hierarchisches Datenmodell Nur Hierarchien von 1:n-Beziehungen sind abbildbar Netzwerkmodell Netzwerk von 1:n-Beziehungen sind abbildbar Sehr stark an Implementierung orientiert => Anwender muss verzeigerte Datenstrukturen kennen Datenbanken I

2. Hierarchisches Datenmodell (1) (0,*) (0,1) Beispiel: Dekor 5 Produkt 5: ist versehen mit Kann gesehen werden als Wiederholungsgruppe: Man könnte auf diese Weise 1:n-Beziehungen sequenziell in Datei speichern Datenbanken I

3. Hierarchisches Datenmodell (2) Schema des hierarchischen Datenmodells: Beziehungen zwischen den konkreten Daten-Objekten: Datenbanken I

4. Hierarchisches Datenmodell (3) Hierarchie über 3 Ebenen: Datenbanken I

5. Hierarchisches Datenmodell – m:n-Beziehungen Problem: Realisierung von m:n-Beziehungen Realisierung mit Referenzen (---------->) Datenbanken I

6. Hierarchisches Datenmodell - mehrstellige Beziehungen Natürlich muss hier wieder mit dem Trick der Virtuellen Lieferung gearbeitet werden Datenbanken I

7. Hierarchisches Datenmodell – weitere Besonderheiten Es gibt nur eine Beziehung zwischen zwei Recordtypen • keine Namensgebung von Beziehungen notwendig Es gibt nur 1:n-Beziehungen • Attribute von Beziehungen wandern in den Kind-Recordtyp der Beziehung (vergleichbar mit der Behandlung von 1:n-Beziehungen beim Übergang vom ER-Modell in das Relationenmodell) Datenbanken I

8. Hierarchisches Datenmodell – DB-Navigation Beim Wurzel-Record-Typ gibt es einen Primärschlüssel, über den zugegriffen wird. Innerhalb jedes Record-Typs gibt es eine sequentielle Ordnung der Records, d. h. sequentielles Durchlaufen / Durchsuchen aller Records des Record-Typs mögl. Allgemeine Ordnung über alle Records der Datenbank, die die Hierarchie abbildet Virtuelle L_240103 Virtuelle Lieferung Virtuelle L_230103 (gute Performance!) Kunde Datenbanken I Maier Schulze

9. Hierarchisches Datenmodell –Navigationsbefehle Zugriff durch Get Unique Eindeutige Selektion eines Records Get Next Durchlaufen der Pfeilkette Get Next within Parent Durchlaufen der Pfeilkette, aber nur die Members des gleichen Owners Datenbanken I

10. Netzwerk-Datenmodell Struktur: Gerichteter Graph mit Recordtypen und 1:n-Beziehungen Member-Recordtyp Owner-Recordtyp Datenbanken I

11. Netzwerk-Datenmodell Wie bei Relationenmodell: Auflösung von m:n-Beziehungen in zwei 1:n-Beziehungen Owner-Recordtypen Member-Recordtyp (Kett-Record-Typ) Datenbanken I

12. Netzwerk-Datenmodell – Owner, Member, Set Record-Typen: • Owner-Record-Typ: Quelle des Pfeils eines Beziehungstyps • Member-Record-Typ: Ziel des Pfeils eines Beziehungstyps • Set-Typ: Beziehungstyp (kein eigenes Objekt, sondern Pfeil zwischen zwei Record-Typen Attribute eines Record-Typs: • werden in die Record-Typen eingetragen • Attributwerte werden in Records eingetragen • Calc-Key ist ein berechneter Attributwert, der bei Owner-Record-Typen zur Identifizierung von Records existieren muss Navigation: • Benutzer einer Netzwerk-Datenbank muss die Owner-/Member-Beziehung kennen • Navigation erfolgt über die Sets, die zwischen Owner und Member exisitieren • Hintergrundspeicher ist langsam und sehr groß • User Working Area ist klein und schnell, enthält temporär Daten aus dem Hintergrund Datenbanken I

13. 5 55 030223 Spedition 5 90 030223 Spedition 6 48 030223 Spedition 2 50 030223 Haendler 2 36 030223 Haendler 3 75 030223 Haendler P1 P3 P2 P4 Tasse Vase Tasse Vase 15 5 7 22 250 500 700 200 11 8 25 18 … … … … 4 10 K1 5 11 6 K2 7 12 8 Owner, Member, Set 3 9 1 2 Datenbanken I

14. Netzwerk-Datenmodell – Architektur GET UWA Datenbank Arbeitsspeicher Hintergrundspeicher PUT Record-Schablonen Currency-Indicator Programm-Variablen Datenbanken I

15. Netzwerk-Datenmodell – Navigationsbefehle Es gibt mehrere „current record of … -Zeiger“ Durch direkten Zugriff auf Record mit Schlüssel und durch Navigieren werden diese Zeiger verändert. FIND-Befehl-Typen: Datenbanken I

16. Netzwerk-Datenmodell – Navigationsbefehle Befehle des Netzwerk-Datenbank-Systems UDS (Siemens) FIND … BY <Name des Schlüssels> FIND NEXT … WITHIN … BY … FIND FIRST/NEXT … WITHIN CURRENT … FIND FIRST/NEXT … WITHIN CURRENT … USING … FIND OWNER … FIND-Befehl positioniert die currency-Indicator, so dass anschließend Record-Schablonen belegt (GET) und veränderte Record-Werte in die Datenbank geschrieben werden können (PUT). Datenbanken I

17. Direktes Finden eines Records K ist eine (die einzige!) Variable in der UWA, die vom selben Typ wie der Record-Typ Kunde ist. CALC-KEY von Kunde ist KNR. Mit der Punktnotation kann man – wie bei Records üblich – jedes einzelne Attribut von K ansprechen. Die Kundennummer der UWA-Variable wird auf ´K2´ gesetzt. Mit dem FIND-Befehl wird der CRU, der CRR-KUNDE, der CRS-erhält_geliefert auf den Kunden-Record gesetzt, der den KNR-Wert ´K2´ hat. Der abschließende GET KUNDE-Befehl speichert den gefundenen Record in der UWA-Variablen zur weiteren Verarbeitung im Programm. Datenbanken I

18. Durchlaufen der Records eines Typs CALC-KEY von Produkt ist PNAME. CALC-KEYs müssen nicht unique sein (wie der Primärschlüssel), sondern sind (z.B. durch Hash-Verfahren) berechnete Schlüssel. Mit dem ersten FIND-Befehl wird das erste Vorkommen einer Vase in der Menge der Produkte gefunden. Die while-Schleife durchläuft alle Produkt-Records (bis zum Ende der Datei der Produkte) und findet innerhalb der Schleife alle weiteren Vorkommen (FIND DUPLICATE …). Zwischen dem GET- und FIND-Befehl in der while-Schleife findet die Verarbeitung des jeweils gefundenen Records im Programm statt. CRU, CRR-Produkt und CRS-wird_geliefert werden bei jedem FIND-Befehl auf den gefundenen Record gesetzt. Datenbanken I

19. Durchlaufen aller Member eines Sets In diesem Programm wird mit dem FIND-Befehl innerhalb der Schleife anhand des CRS wird_geliefert auf Member-Ebene nach allen Produktnummern der Produkte gesucht, die K1 geliefert erhält. CRU, CRR-Lieferung und CRS erhält_geliefert werden bei jedem FIND-Befehl auf den gefundenen Record gesetzt. Datenbanken I

20. Finden des (eindeutigen) Owners zu einem Member-Record K.KNR := K1; FIND Kunde BY CALC-KEY; (* A *) while not fail do begin FIND NEXT Lieferung WITHIN CURRENT erhält_geliefert; (* B *) FIND OWNER OF CURRENT wird_geliefert; (* C *) GET Produkt; end; K1 ist ein Kunde, von dem alle Produktdaten zu seinen Lieferungen gewünscht sind. Anders als bei dem vorigen Beispiel ist es hier notwendig, vom Owner Kunde zu allen Membern im Set erhält_geliefert zu navigieren, um jeweils den Owner im Set wird_geliefert zu erhalten (und ggfs. im Weiteren zu verarbeiten, GET Produkt). In diesem Beispiel wird keine Schleife bis zum Ende eines Files of Records durchlaufen, sondern solange bis es keinen weiteren Member im Set erhält_geliefert mehr gibt (while not fail). Fail bedeutet, dass die weitere Suche zum Fehler führt. Datenbanken I

21. Currency Tabelle Tabellenartige Zusammenfassung aller Currency-Indicator CRR: Current Record of Record-Type CRS: Current Record of Set-Type CRU: Current Record of Run Unit Datenbanken I

22. Aufgabe In Konzerten (K) werden mehrere Componisten (C) gespielt. Ebenso wird ein Componist in verschiedenen Konzerten gespielt. Folgende konkrete Beziehungen herrschen zwischen Konzerten und Komponisten: K1 C1 K2 C2 K3 • C3 K4 C4 K5 • C5 K6 C6 C7 • Zeichnen Sie ein ER-Diagramm und ein Netz-Datenmodell zu diesem Sachverhalt auf. • Zeichnen Sie das hierzu passende konkrete Netzwerk-Datenmodell auf. • Zeichnen Sie eine Currency-Tabelle auf, wenn folgende FIND-Befehle in der genannten Reihenfolge auftreten:FIND K1; FIND K1_C3; FIND K1_C4; FIND C4; FIND K4_C4; FIND K4; FIND K6; FIND K6_C3 Datenbanken I