Netzwerk-Datenbanksysteme

4. Das Netzwerk-Daten(bank)modell
Zielsetzung des Kapitels:
• Einordnung/Abgrenzung des Netzwerk-Modells, Mächtigkeit des
Modellierungsansatzes
• Was ist eine Netzwerk-Datenbank, wie definiert man das Datenbankschema einer Netzwerk-Datenbank, wie greift man auf die Inhalte
einer Netzwerk-Datenbank zu:
- Datenbankdefinitionssprache (DDL)
- Datenmanipulationssprache (DML)
( - Speicherbeschreibungssprache, Storage Structure Language
(SSL))
• Konkret: Der CODASYL/DBTG-Vorschlag für die Realisierung eines
Netzwerk-Datenbanksystems (Conference on Data Systems
Languages, Database Task Group) als konkrete Diskussionsgrundlage
„Netzwerk-Datenbanksysteme“
∧
=
„CODASYL-Datenbanksysteme“
Datenbanksysteme 1
05.12.2005
141
Historische Entwicklung des Netzwerk-Ansatzes
• Hierarchisches Datenmodell und IMS waren schon (etwas) früher da,
entstanden ab Mitte der 60er Jahre → proprietär und immer (IBM)
geblieben!
• Netzwerk-Datenmodell von vornherein mit dem Ziel entstanden, einen
nichtproprietären Ansatz zu entwickeln
an CODASYL/DBTG waren viele Hersteller / unabhängige Fachleute
beteiligt („entsprechend lange hat´s auch gedauert“)
• Ziel der Task Group (Ende der 60er Jahre):
Spezifikation von DDL und DML
• Erster CODASYL-Report dazu 1971
• Weitere Versionen in der Folge, nächster „stabiler“
Vorschlag 1978 = Grundlage diverser Implementierungen, z.B.:
- UDS („Universelles Datenbanksystem“) (Fujitsu-Siemens)
- IDMS (Cullinet, Computer Associates(CA))
- ...
etc.
Datenbanksysteme 1
05.12.2005
142
Historische Entwicklung (Fortsetzung)
• Normierung (ISO) seit 1987
Vorab: Warum hat der Netzwerk-Datenbankansatz
sich in der Praxis doch nicht so sehr durchgesetzt?
Vergleichsweise komplexe DDL und DML (vor allem), schwer
vollständig zu erlernen und stets im Griff zu behalten (ähnliches
Problem wie bei hierarchisch/IMS)
• Navigierender Zugriff im Vordergrund, primär aus Programmiersprache heraus aufrufbar → (im Gegensatz zu relational) keine
deskriptive Sprache / Möglichkeiten zu Ad-hoc-Anfragen, keine
Mengenorientierung (jedoch spätere „Aufsätze“ entstanden →
UDS/SQL, IDMS/R) → grundsätzlich ebenfalls vergleichbar zu IMSHistorie
• Relationale Systeme haben sich „zu schnell“ entwickelt und verbreitet
(zum Glück!)
• Normkonformität bei Netzwerk-Datenbanksystemen ein Problem,
viele „Spezialitäten“ in einzelnen Systemen
Datenbanksysteme 1
05.12.2005
143
Charakterisierung des Netzwerk-Datenbankansatzes
• Netzwerk-Datenmodell hinsichtlich der Beschreibungsmächtigkeit
näher beim E/R-Modell, als dies beim HDM der Fall ist ⇒ größere
Mächtigkeit im NDM als im HDM
• Konstrukte zur Datenmodellierung:
- Satztypen (record types) ≈ Entity Type
- Spezielle (1:n) Beziehungstypen (set types)
oft auch als CODASYL set
bezeichnet
• Beziehungstypen sind ausschließlich zweistellig und benannt, in
graphischer Darstellung z.B.
Schema
(Beispiel)
einer
Netzwerk-DB
ABTEILUNG
POSITION
besteht_aus
MITARBEITER
setzt_sich_zusammen_aus
set type
⇒ gerichteter Graph (Netzwerk) ggf. sogar zyklenbehaftet
• Netzwerk-DB = Schema + Ausprägungen (occurrences)
set occurrences / record occurrences
• Vater in einem set type wird auch als owner record type bezeichnet,
Sohn als member record type
Datenbanksysteme 1
05.12.2005
144
Set-Typen (set types)
• (Zweistelliger) Beziehungstyp S zwischen Record-Typ R und Record-Typ R´,
R ist Owner-Typ, R´ ist Member-Typ, R ≠ R´ → kein Kurzzyklus
• Graphisch
R
S
sog. BachmanDiagramm
R´
• Semantik: 1:n Beziehungstyp zwischen R und R´ (implizit, d.h. wird z.B. nicht
mit notiert in gr. Darst.)
• Auf der Ausprägungsebene (occurrences):
- Zu jedem Record r (präziser gesagt: Record Occurrence) aus dem
Record-Typ R gehört implizit eine Set Occurrence s aus S; diese darf
auch leer sein (empty set (occurence))
- Jeder Record r´ aus R´ gehört zu maximal einer Set Occurrence s aus S.
Konsequenzen:
• Owner Record zu einem Member Record innerhalb eines Set stets
eindeutig definiert (es gibt einen oder es gibt keinen(!)) → SetAusprägungen sind Bäume!
• Waisenkinder sind grundsätzlich erlaubt (können aber ggf. verboten werden, im Gegensatz zum HDM/IMS)
!
Datenbanksysteme 1
05.12.2005
145
Beispiel für Set-Typen und Set-Ausprägungen
ABTEILUNG
a)
hat
Bachman-Diagramm
(Schema, Set- und Record-Typen)
MITARBEITER
empty set (occ.)
b) 3 Set-Ausprägungen
abt1
mitarb1
mitarb2
abt3
mitarb3
mitarb9
abt2
mitarb4
mitarb10
Set-Ausprägungen zum Owner abt3 ist leer. mitarb9 gehört (aktuell) keiner
Set-Ausprägung an, ist somit Waise
Bemerkung: Ob Waisen tatsächlich erlaubt sein sollen oder nicht, kann
mit Hilfe der DDL bei der Definition des Set-Typs festgelegt werden („IMSSemantik“ kann bei Bedarf also erzwungen werden!)
Datenbanksysteme 1
05.12.2005
146
Ordnung der Member-Sätze innerhalb der Set-Ausprägung
• Es existiert immer eine Ordnung auf den Member-Sätzen einer SetAusprägung: 1. Member-Satz, 2. Member-Satz, ..., letzter MemberSatz
• In dieser Ordnung werden die Member-Sätze auch wiederaufgefunden
(„abgeliefert“) bei DML-Anweisungen à la FIND NEXT Mitarbeiter
WITHIN SET hat
• Ordnung kann Sortierfolge nach Feldwerten sein oder auch
Einfügungsreihenfolge oder dem System überlassen
• Beispiel:
hat
ABTEILUNG
MITARBEITER
• Ausprägungsebene:
(Darstellungsform)
logische Darstellung
ORDER IS
FIRST
LAST
NEXT
PRIOR
SORTED...
SYSTEM-DEFAULT
(Typebene)
abt1
mitarb1
mitarb2
mitarb3
Man beachte die Variantenvielfalt!
... und die Funktionalitäts- und Performance-Auswirkungen!
Sortierung z.B. nach Gehalt, Geburtsdatum o.ä. mit oder ohne Zulässigkeit von Duplikaten
Datenbanksysteme 1
05.12.2005
147
Exkurs: Implementierungsgesichtspunkte
• Die obigen Darstellungen oder Set-Ausprägungen sollen keine
konkreten Implementierungen präjudizieren!
• für die Implementierung von Set-Ausprägungen gibt es
verschiedene Möglichkeiten/Varianten auf der internen Ebene →
Optionen für den DBA („Stellschrauben“)
• 3 Beispiele dazu:
a) Verkettete Implementierung
(MODE IS CHAIN)
Member Record Occurences
„beliebig“ über DB verteilt
abt1
mitarb1
mitarb2
mitarb3
„pointer“ (wie auch immer physisch realisiert)
b) Implementierung mittels Zeigertabelle (MODE IS POINTER-ARRAY)
Member Record Occurences
„beliebig“ über DB verteilt
Datenbanksysteme 1
mitarb1
05.12.2005
abt1
mitarb2
mitarb3
148
c) Implementierung via Memberliste (MODE IS LIST)
Member-Sätze sind
„geclustert“ gespeichert
abt1
mitarb1 mitarb2 mitarb3
. . . ATTACHED TO OWNER
abt1
m1 m2 m3
. . . DETACHED
• Die Auswahl der Implementierungsform ist Aufgabe des
Datenbankadministrators
• Die Auswahl ist rein unter Performance-Gesichtspunkten
vorzunehmen ⇒ kann wesentlichen Einfluss haben
⇒ Unterstützungswerkzeuge (z.B. Expertensystemansatz) sinnvoll,
aber auch nicht trivial zu entwickeln / zu benutzen (WorkloadBeschreibung als Input!)
• Die Implementierungsformen sind nicht
R
Bachmanfrei miteinander verträglich, etwa im Fall
S1
S2
Diagramm
R´
→ „geclustert“ werden kann immer nur nach einem Kriterium / bzgl. eines Set!!
Datenbanksysteme 1
05.12.2005
149
Modellierung von Beziehungen im NDM oder: Vom E/R-Modell zum NDM
I. Nichtrekursive 1:n Beziehungen
E/R-Diagramm
ABTEILUNG
(0,*)
1
(0,1)
n
hat
MITARBEITER
im Netzwerk-Datenmodell
(Bachman-Diagramm)
ABTEILUNG
hat
MITARBEITER
Was macht man,
wenn?
hat
a)
b)
MITARBEITER
„Waisenverbot“ kann mittels
DDL-Klausel bei Set Type
Definition vereinbart werden
ABTEILUNG
nicht per DDL spezifizierbar
(1,1)
(1,*)
hat
Datenbanksysteme 1
05.12.2005
→ muss von Anwendung
überwacht werden!
150
II. Rekursive 1:n Beziehungen
Bsp.: Personalhierarchie
PNR 0599061
PNR 4711
PNR 4321
PNR 8532
PNR 3850
PNR 2111
PNR 007
PNR 6000
PNR 1220
PNR 1312
. . . beliebige Tiefe des Baums!
E/R-Diagramm
Netzwerk-Datenmodell
(Bachman-Diagramm)
Mitarbeiter
Mitarbeiter
hat_als_
hat_als_Chef
Untergebene
(0,1)
(0,*)
Vorgesetzter
nicht erlaubt
ist_Vorgesetzter
Datenbanksysteme 1
05.12.2005
151
Lösung: Beziehungstyp wird abgebildet auf sog. Kett-Record-Typ
(plus 2 Set-Typen)
Bachman-Diagramm
Alternative 1: Kett-Record-Typ ist in beiden down Mitarbeiter
hat_als_
* up
*
Set-Typen Member-Record-Typ
Untergebene
hat_als_Chef
*markiert Vater
in Set-Auspräg.
(1:1)
Ausprägungsebene
* PNR 0599061
down
MA-Kett1
MA-Kett2
**PNR 4711
MA-Kett4
MA-Kett1
(1:n)
1 Kett-RecordOccurrence pro
Untergebenem
(Kante im Baum)
MA-Kett5
**PNR 3850
MA-Kett6
*PNR 4321 *PNR 8532 *PNR 2111
down ist 1:n Beziehungstyp
up
ist 1:1 Beziehungstyp
Datenbanksysteme 1
MA-Kett3
**PNR 6000
MA-Kett7
MA-Kett8
MA-Kett9
*PNR 007
*PNR 1220
*PNR 1312
up
down
up
Konsistenzsicherung seitens der Anwendung(en): !!!
- 1:1 Beziehungstyp → Schwäche des NDB-Ansatzes
- Zyklenfreiheit → Schwäche vieler DB-Ansätze
05.12.2005
152
Alternative 2: Kett-Record-Typ ist in einem Set-Typ Member-Record-Typ
und im anderen Owner-Record-Typ
Bachman-Diagramm
Mitarbeiter
(1:1) down
* up
*
(1:n)
MA-Kett
1 Kett-RecordOccurrence pro
Vorgesetztem
Ausprägungsebene
PNR 0599061
*
*
down
MA-Kett1
up
PNR 4711
PNR 3850
*
*
*
MA-Kett2
*
MA-Kett3
PNR 6000
*
*
down
MA-Kett4
up
PNR 4321
PNR 8532
PNR 2111
down ist 1:1 Beziehungstyp
up
ist 1:n Beziehungstyp
Datenbanksysteme 1
PNR 007
PNR 1220
PNR 1312
Konsistenzsicherung seitens der Anwendung(en): !!!
- 1:1 Beziehungstyp
- Zyklenfreiheit
05.12.2005
153
III. Nichtrekursive n:m Beziehungen
E/R-Diagramm (Bsp.)
Netzwerk-Datenmodell
(Bachman-Diagramm)
LIEFERANT
LIEFERANT
(0,*)
(0,*)
TEIL
TEIL
Ein Teil kann von mehreren
Lieferanten geliefert werden, und
ein Lieferant liefert mehrere Teile
Datenbanksysteme 1
(1:n)
wird_geliefert
liefert
(1:n)
Menge
liefert
05.12.2005
syntaktisch erlaubt,
semantisch falsch
da jede Member-RecordOccurrence nur zu max. 1 SetOccurrence gehören darf (Owner
Record, Occurrence falls
existent, muss eindeutig sein)
154
Lösung: Wiederum Kett-Record-Typ (plus 2 Set-Typen)
LIEFERANT
oder:
LIEFERANT
liefert
liefert_TEIL
Menge
TEIL
wird_geliefert
liefert
wird liefert
liefert_TEIL
TEIL
Bachman-Diagramm
Menge
Ausprägungsebene
L4
L1
L1,T1,20
L1,T2,7
T1
„V-Schema“
L2
L1,T3,9
T2
L2,T1,100
T3
L3
L2,T1,100
liefert
Kett-RecordOccurrence
L3,T4,10
T4
wird_geliefert
T5
• Kett-Record-Occurrences enthalten LNr, TNr, Menge
!
redundant, deshalb nicht gesp.
• 1 Kett-Record-Occurrence pro Lieferung (Beziehungsausprägung)
zwischen Lieferant und Teil)
Datenbanksysteme 1
05.12.2005
155
IV. Rekursive n:m Beziehungen
Beispiel: Stückliste
A
Fertigteil
1
Baugruppe
B
D
z
C
7
1
3
4
5
Einzelteil
2
E
F
„DAG“
gerichteter
azyklischer
Graph
bedeutet: z Exemplare {der Baugruppe x, des Teils X} gehen
in eine Baugruppe y ein
sog. Gozinto-Graph
„Zeparzat Gozinto“ - the part that goes into x
y
E/R-Diagramm
Bachman-Diagramm
Datenbankschema im NDM
TNr
TEIL
Teil
(0,∗)
enthält
(1:n)
(0,∗)
enthält/
ist_enthalten_in
Menge
Datenbanksysteme 1
ist_enthalten_in
(1:n)
Struktur
Kett-Record-Typ
„Waisenkinder“?
05.12.2005
156
Ausprägungsebene
* Teil A
Strukt 1
1
Strukt 2
7
** Teil C
** Teil B
Strukt 4
3
* Teil D
!
Strukt 3
4
Strukt 5
1
Strukt 6
5
* Teil E
Strukt 7
2
* Teil F
• Struktursatz (Kett-Record-Occurrence) pro Pfeil im Gozinto-Graphen (gerichtete
Kante in Stückliste)
• Finden der Teile und Baugruppen der ersten Stufe für Teil A (alles, was direkt
in Teil A eingeht)
- Finden des richtigen Teile-Records (FIND)
- Navigierender Zugriff auf alle Member-Records innerhalb der SetAusprägung von „enthält“ (FIND NEXT WITHIN ...)
- Für jeden gefundenen Member-Record Zugriff auf den Owner-Record
innerhalb der Set-Ausprägung von „ist_enthalten_in“ (FIND OWNER ...)
Datenbanksysteme 1
05.12.2005
157
Mehrstellige Beziehungstypen (k>2)
Projekt
Beispiel: E/R-Diagramm
(0,*)
Menge
liefert
(0,*)
Lieferant
(0,*)
Artikel
Bachman-Diagramm
Projekt
P_l
Kett-Record-Typ
Lieferant
L_l
liefert
Artikel
A_l
Menge
• liefert ist wiederum Kett-Record-Typ
• Bei der Definition der drei Set-Typen (P_l,L_l,A_l) muss jeweils
spezifiziert werden, dass Waisenkinder verboten sind (jede liefertAusprägung muss in drei Set-Ausprägungen Member sein)
Datenbanksysteme 1
05.12.2005
158
Grundsätzliche Eigenschaften der NDM, auch im Vergleich zum HDM
1) Jeder Record-Typ kann Owner oder
Member in beliebig vielen Set-Typen
sein
2) In einem Set-Typ muss OwnerRecord-Typ ≠ Member-Record-Typ
sein (es gibt aber DBVS-Implementierungen, die "=" erlauben)
3) Zwischen einem Owner-Record-Typ
A und einem Member-Record-Typ B
dürfen beliebig viele Set-Typen
existieren
4) Record-Typen müssen nicht unbedingt an Set-Typen beteiligt sein, d.h.
„alleinstehende“ Record-Typen sind
erlaubt
Datenbanksysteme 1
05.12.2005
S1
S2
i
Unterschied zu HDM
S3
S4
S5
A
S6
S7 S8
S9
A
S10
S
A
S1 S2 S3 S4 S5
B
A
159
5)
Der Einstieg in eine Netzwerk-Datenbank ist für einen
beliebigen Record-Typ möglich, d.h. es gibt keine
ausgezeichneten Einstiegspunkte
6)
Wenn ein Record-Typ A Member eines Set-Typs S ist, so
müssen doch nicht alle Record-Ausprägungen s von S sein:
Waisenkinder zulässig
7)
Für die Member-Record-Ausprägungen innerhalb einer SetAusprägung muss stets eine Reihenfolge festgelegt werden
(wobei SYSTEM-DEFAULT erlaubt ist)
Datenbanksysteme 1
05.12.2005
160
Netzwerk-Datenbank =
• Nichtleere Menge von benannten Record-Typen
• Menge von benannten Set-Typen (darf leer sein)
• Menge von Record-Ausprägungen (darf leer sein)
• Menge von Set-Ausprägungen (darf leer sein)
DatenbankSchema
DatenbankInhalt
Charakteristika des Arbeitens mit einer Netzwerk-Datenbank
• Aus Anwendungsprogrammen heraus (eingebettete Datenbankzugriffe (DBVS-Aufrufe)), im Gegensatz zum HDM aber in Form einer
Programmiersprachenerweiterung möglich, d.h. über Präcompiler
oder Compiler-Erweiterung unterstützt
• Satzweiser Zugriff, „one record at a time“
• Direkter Zugriff auf Sätze eines Record-Typs oder navigierender
Zugriff
Datenbanksysteme 1
05.12.2005
161
Beispielschema einer Netzwerk-Datenbank
(CODASYL-Datenbank)
ABT_PROJ
ABT
PROJ
ABT_ANG
ANGEST
ANG_PROM
Rautenschema
PROJ_PROM
PROMIT
n:m →
Kett-Record-Typ (III)
„V-Schema“
PROMIT ist Kett-Record-Typ zur Modellierung der n:m-Beziehung
zwischen Angestellten und Projekten (ein Angestellter kann in mehreren
Projekten mitarbeiten, ein Projekt kann mehrere Angestellte umfassen)
Anforderungen an die Datenmanipulationssprache (DML) eines
Netzwerk-Datenbanksystems
1. Retrieval (Lesender Zugriff auf Records)
a) Direkter Einstieg von außen
„Finde Gehalt und Geburtsdatum des Angestellten Kuno MüllerEiermann“ ⇒ FIND ANY ... Prädikat ...
[Schnell, falls Zugriffspfad für Feld NAME in Record-Typ ANGEST existiert (z.B. B*-Baum oder Hashtabelle); sonst langsam, da seq. Suche]
Datenbanksysteme 1
05.12.2005
162
b) Anfragen unter Bezugnahme auf Sets (Navigation)
b1) Member → Owner
„In welcher Abteilung arbeitet dieser Angestellte?“
⇒ FIND OWNER innerhalb der Set-Ausprägung von ABT_ANG
b2) Owner → Member & Member → Member
„Gibt es in ABT 10 einen Angestellten, der mehr als EUR 5000,verdient?“
1. Direkter Einstieg von außen mit FIND ANY ... Prädikat ... auf ABT 10
2. Finde ersten Member Record in Ausprägung von Set-Typ ABT_ANG
und prüfe auf Gehalt > 5000,- ( FIND FIRST )
*
3. Finde nächsten Member Record ... und prüfe ... ( FIND NEXT )
Alternatives Vorgehen ?
*
lässt sich in CODASYL-DML auch in einem einzigen DML-Befehl ausdrücken,
indem das Prädikat Gehalt > 5000 dem DBVS bei der Suche mitgegeben wird!
Datenbanksysteme 1
05.12.2005
163
2. Update (Einfügen, Ändern, Löschen von Records)
a) Ändern
„Erhöhe das Gehalt des Angestellten Karl Müller-Isserstedt um 10%
1. Direkter Einstieg von außen mit FIND ANY ... Prädikat ... auf den
gesuchten Angestellten
2. Übertragen des bisherigen Gehaltwerts ins Anwendungsprogramm
und multiplizieren mit 1.1
3. Rückschreiben des (neuen) Gehaltswerts in die Datenbank ( MODIFY )
Bemerkungen:
• Was ist, wenn Gehaltswert Reihenfolge der Records in der ABT-ANG
Set-Ausprägung bestimmt (ORDER IS SORTED ..., vgl. Folie 147)
⇒ Record wird innerhalb der Set-Ausprägung vom DBVS automatisch
„umpositioniert“!
• (U.U. kann durch MODIFY sogar automatische Neuzuordnung des
Member Record zu einer anderen Set-Ausprägung (↔ anderem Owner)
erfolgen, falls Zugehörigkeit werteabhängig definiert)
Datenbanksysteme 1
05.12.2005
164
!
„Versetze Angestellten Willi Künstlich von Abteilung ABT 3 in ABT 8“
⇒ explizit veranlasstes Wechseln der Zugehörigkeit zu einer SetAusprägung für einen Angestellten ( DISCONNECT/CONNECT oder
– in einem Schritt – RECONNECT )
b) Löschen
„Lösche den Angestellten Willi Künstlich“
1. Direkter Einstieg von außen mit FIND ANY ... Prädikat ... auf den
gesuchten Angestellten
2. Löschen des ANGEST-Records ( ERASE )
Bemerkungen:
• Zu löschende ANGEST-Record muss gleichzeitig aus allen SetAusprägung, in denen er Member ist, entfernt („ausgekettet“) werden;
geschieht automatisch durch das DBVS; im BSP.: Set-Ausprägung in
ABT-ANG
• In Set-Ausprägungen, in denen er Owner ist, muss unterschieden
werden (je nachdem, wie´s bei der Set-Typ-Definition in der DDL
spezifiziert worden war):
Datenbanksysteme 1
05.12.2005
165
- Member Records sind existentiell abhängig vom Owner Record
→ Member Records werden vom DBVS automatisch mit gelöscht
(⇒ kann ggf. „cascading delete“ auslösen)
- Member Records sind nur optional abhängig:
Bleiben bestehen, gehören der Set-Ausprägung nicht mehr an,
sind fortan Waisenkinder
⇒ was ist beim Beispielschema (Folie 162) angeraten?
c) Einfügen
„Füge Angestellten Max Meier neu in die Datenbank ein“ = STORE
Bemerkungen:
• Wenn der neue Record zu einem Record-Typ gehört, der Owner in
einem Set-Typ (oder: mehreren Set-Typen) ist, wird implizit eine leere
Ausprägung (bzw. werden mehrere leere Set-Ausprägungen) erzeugt
⇒ Set-Ausprägung enthält (zunächst) nur Owner Record, keine
Member
Datenbanksysteme 1
05.12.2005
166
• Interessanter: Neue Record gehört zu einem Record-Typ, der
Member in einem Set-Typ (oder: mehreren Set-Typen) ist:
Es muss festgelegt werden:
- in welche Set-Ausprägung(en) der neue Record einzufügen ist
und das Einfügen muss automatisch durch das DBVS erfolgen
oder explizit durch das Anwendungsprogramm (CONNECT)
- an welche Position(en) innerhalb der Set-Ausprägung(en) die
Einfügung zu erfolgen hat (vgl. Folie 147), die Position kann durch
das DBVS selbst bestimmt werden oder das Anwendungsprogramm hat die Möglichkeit, die Position zu bestimmen (je nach
DDL-Klausel, Folie 147)
Datenbanksysteme 1
05.12.2005
167