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 Karczewski Datenbanken I

Hierarchisches Datenmodell (1) Beispiel: (0,*) (0,1) 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 Karczewski Datenbanken I

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

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

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

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

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) Karczewski Datenbanken I

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 Karczewski (gute Performance!) Kunde Maier Schulze Datenbanken I

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 Karczewski Datenbanken I

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

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

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 Karczewski Datenbanken I

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

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

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: Karczewski Datenbanken I

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). Karczewski Datenbanken I

Direktes Finden eines Records K.KNR := ´K2´ (* Belegen der UWA-Variablen *) FIND Kunde BY CALC-KEY GET Kunde (* Speichern des gefundenen Kunden in der UWA *) 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. Karczewski Datenbanken I

Durchlaufen der Records eines Typs P.PNAME := ´Vase´; FIND Produkt BY CALC-KEY; while not eof do (* solange der FIND-Befehl noch Record liefert *) begin GET Produkt; FIND DUPLICATE WITHIN Produkt BY CALC-KEY; end; 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. Karczewski Datenbanken I

Durchlaufen aller Member eines Sets L.KNR := ´K1´; FIND Lieferung WITHIN erhält_geliefert USING L.KNR; (* Anhand des Owners wird der erste Member gefunden *) while not eof do Begin GET L.PNR; FIND DUPLICATE Lieferung WITHIN erhält_geliefert USING L.KNR; End; 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. Karczewski Datenbanken I

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. Karczewski Datenbanken I

CRS-erhält_geliefert Currency Tabelle Tabellenartige Zusammenfassung aller Currency-Indicator Befehl CRU CRR-Kunde CRR- Lieferung CRR- Produkt CRS-erhält_geliefert CRS-wird_geliefert (* A *) 1 Undef. (* B *) 3 (* C *) 9 4 10 5 12 CRR: Current Record of Record-Type CRS: Current Record of Set-Type CRU: Current Record of Run Unit Karczewski Datenbanken I

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 Karczewski Datenbanken I