Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

KarczewskiDatenbanken I1 Historische Datenmodelle Hierarchisches Datenmodell Nur Hierarchien von 1:n-Beziehungen sind abbildbar Netzwerkmodell Netzwerk.

Ähnliche Präsentationen


Präsentation zum Thema: "KarczewskiDatenbanken I1 Historische Datenmodelle Hierarchisches Datenmodell Nur Hierarchien von 1:n-Beziehungen sind abbildbar Netzwerkmodell Netzwerk."—  Präsentation transkript:

1 KarczewskiDatenbanken I1 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

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

3 KarczewskiDatenbanken I3 Hierarchisches Datenmodell (2) Schema des hierarchischen Datenmodells: Beziehungen zwischen den konkreten Daten-Objekten:

4 KarczewskiDatenbanken I4 Hierarchisches Datenmodell (3) Hierarchie über 3 Ebenen:

5 KarczewskiDatenbanken I5 Hierarchisches Datenmodell – m:n-Beziehungen Problem: Realisierung von m:n-Beziehungen Realisierung mit Referenzen ( >)

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

7 KarczewskiDatenbanken I7 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)

8 KarczewskiDatenbanken I8 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 Schulze Virtuelle L_ Kunde Virtuelle Lieferung Maier Virtuelle L_ (gute Performance!)

9 KarczewskiDatenbanken I9 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

10 KarczewskiDatenbanken I10 Netzwerk-Datenmodell Struktur: Gerichteter Graph mit Recordtypen und 1:n-Beziehungen Member-Recordtyp Owner-Recordtyp

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

12 KarczewskiDatenbanken I12 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

13 KarczewskiDatenbanken I Spedition K1 P1Tasse … P3Tasse52008 … P4Vase … P2Vase … Haendler Haendler Haendler Spedition Spedition K Owner, Member, Set

14 KarczewskiDatenbanken I14 Netzwerk-Datenmodell – Architektur UWA Datenbank Arbeitsspeicher Hintergrundspeicher Record-Schablonen Currency-Indicator Programm-Variablen GET PUT

15 KarczewskiDatenbanken I15 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:

16 KarczewskiDatenbanken I16 Netzwerk-Datenmodell – Navigationsbefehle Befehle des Netzwerk-Datenbank-Systems UDS (Siemens) FIND … BY 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).

17 KarczewskiDatenbanken I17 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.

18 KarczewskiDatenbanken I18 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.

19 KarczewskiDatenbanken I19 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.

20 KarczewskiDatenbanken I20 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.

21 KarczewskiDatenbanken I21 Currency Tabelle BefehlCRUCRR-KundeCRR- LieferungCRR- ProduktCRS-erhält_geliefertCRS-wird_geliefert (* A *)11Undef. 1 (* B *)313Undef.33 (* C *) (* B *) (* C *) (* B *) (* C *) Tabellenartige Zusammenfassung aller Currency-Indicator CRR: Current Record of Record-Type CRS: Current Record of Set-Type CRU: Current Record of Run Unit

22 KarczewskiDatenbanken I22 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: K1C1 K2C2 K3 C3 K4C4 K5 C5 K6C6 C7 a)Zeichnen Sie ein ER-Diagramm und ein Netz-Datenmodell zu diesem Sachverhalt auf. b)Zeichnen Sie das hierzu passende konkrete Netzwerk-Datenmodell auf. c)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


Herunterladen ppt "KarczewskiDatenbanken I1 Historische Datenmodelle Hierarchisches Datenmodell Nur Hierarchien von 1:n-Beziehungen sind abbildbar Netzwerkmodell Netzwerk."

Ähnliche Präsentationen


Google-Anzeigen