9.2. Netzwerk-Datenbanksysteme 9.2.1. Das Netzwerk

- 213 -
9.2. Netzwerk-Datenbanksysteme
- 214 -
Grundstruktur eines Sets:
Lieferant
Entwicklung Anfang der 70er Jahre
im wesentlichen: Erweiterung von COBOL
Record-Typ
um CODASYL - DDL/DML
Record
Teile
liefert
L1
L2
Set-Typ Record-Typ
T2 T4 T5
T 1 T2
Records
owner
record
L2
L1
Database Task Group (DBTG) of
Conference on Data System Languages
T2
9.2.1. Das Netzwerk-Modell (NM)
T4
T5
T1
T2
logische Struktur: Ringliste:
implementierbar über Pointer als “chain linked to next”.
NM ist eingeschränktes ERM mit nur binären
besser: doppelt verkettete Ringliste
besser: jeweils zusätzlicher Link zum Owner
1 : n Beziehungen
set
implementiert als Links (Zeiger)
9.2.2. Zehn Regeln für Sets
1. Set Typ muß durch Namen eindeutig identifizierbar sein.
2. Alle Member Records eines Sets sind vom gleichen Typ.
3. Alle owner Records eines Sets sind vom gleichen Typ.
member
records
- 215 -
- 216 -
4. Typ des Members und Owners eines Sets dürfen nicht gleich sein.
(d.h. keine direkte Rekursion, z.B.: Personalhierarchie)
5. Ein Record kann nicht gleichzeitig Member in zwei Sets vom
gleichen Typ sein.
7. Übersichtliche Darstellung auf Typ Ebene (keine Instanzen) im
Bachmann Diagramm
Record
Lieferant
Set _LT
6. Ein Record kann sowohl Member in einem Set, als auch Owner in
einem anderen Set sein.
zu 5.:
verboten:
T4
Set _LT
Set
Record
L2
T5
T2
Modellierung:
a) E/R-Modell
b) Auflösung von n : m Beziehungen in n : 1 und 1 : m Beziehungen
c) Überführung in Bachmann Diagramm.
d) Netzwerk DB
T1
verboten!
Lösung: Einführung sog. Kett-Records:
erlaubt:
Record (genauer: Kett-Record)
LT
Teile
L1
Set
8. Set darf leer sein.
L3
L2
L1
9. Mitglieder eines Sets sind geordnet (erster, nächster, ..., letzter)
Duplikate im Set möglich.
L1T4
T4
L1T5
T5
L2T2
L1T2
T2
L2T1
T1
KettRecords
10.Set kann in beiden Richtungen durchlaufen werden.
member
owner
owner
member
- 217 -
- 218 -
Ausführliches Beispiel:
NM:
Lieferant
Relational:
Bachmann-Diagramm
Lieferant
liefert
E/R-Diagramm
n
liefert
Preis
Teile
Tragen Sie hier bitte die (vereinfachte) Pointerstruktur für dieses Beispiel ein:
m
Teile
Lieferant
liefert
Teile
(!)
L#
L1
L2
L3
L#
Name
Smith
Jones
Huber
P#
Prio
20
10
30
P1
3.00
L1
P2
2.00
L1
P3
4.00
L2
P1
3.00
L2
P2
4.00
L3
P2
2.00
T_Name
Niete
Bolzen
Schraube
Schraube
L1 Smith 20 London
3.00
2.00
4.00
P1 Niete 1516
Preis
L1
T#
P1
P2
P3
P4
Stadt
London
Paris
München
Nebenbemerkung:
T_Norm
1516
12
141
368
L2 Jones 10 Paris L3 Huber 30 München
3.00
P2 Bolzen 12
4.00
P3 Schraube 141
2.00
P4 Schraube 368
- 219 -
9.2.3. DB auf Basis des NM
• Erreichbarkeit:
Jeder Record der DB muß erreichbar sein, entweder als
Einstiegspunkt (Schlüssel) oder über eine Folge von Sets.
-> Vorsicht beim Löschen eines Records, das sowohl Member als
auch Owner eines anderen Sets ist!
• Retrieval:
Ausgehend vom Einstiegspunkt muß der Benutzer den Zugriffspfad
für jeden Record selbst anlegen.
-> Navigierend durch die DB
• Verarbeitung geschieht record-weise (= tupelweise)
• zum Navigieren ist User-Working-Area (UWA) erforderlich
(Kommunikationsbereich).
- 220 -
Jeder Satz, den das Applikations-Programm aus der Datenbank liest,
wird vom Datenbanksystem im zugehörigen Speicherbereich des UWA
abgelegt und von dort mit Cobol-Anweisungen weiterverarbeitet.
X
Programmierumgebung
X
DB
Prog. Variable
X
Record Template
X
X
X
Aktualitätszeiger
X
User working area (UWA):
Jedes Applikations-Programm enthält einen Kommunikationsbereich
(“user working area”, UWA). Dieser enthält:
• Positionszeiger: drei Arten
• CRT = current of record-type: pro Record-Typ, Verweis auf
den zuletzt zugegriffenen Record dieses Typs
• CRS = current of set type: pro Set-Typ, Verweis auf den
zuletzt zugegriffenen Record dieses Typs
• CRU =current of run unit: Verweis auf den Record, auf den
man zuletzt zugegriffenen hat.
damit ist “Finde nächsten Record in Set S” immer eindeutig lösbar.
• Speicherbereich für jeden angesprochenen Record-Typ
• Status Code Wort (= Ergebnis einer Operation: ok, error, end of set,
etc.)
UWA
9.2.4. Retrieval
1. Suche eines Records:
FIND NEXT <record> { USING <value> }
FIRST
| WITHIN <set> |
PRIOR
ANY
...
OWNER [ WITHIN <set>]
2. Übernahme des Records in UWA:
GET
X
- 221 -
- 222 -
9.2.5. Zusammenfassung
Bsp.:
System
Einstiegspunkt
SNAME
Angestellter
Set_AP
Ang_Pro
Set_PA
Projekt
Query: Name und Nummer der Projekte in denen der Angestellte mit
Nr. N arbeitet.
READ (N)
ANG_NR := N
FIND ANY ANGEST USING ANG_NR
FIND FIRST ANGPRO WITHIN SET_AP
IF STATUS_WORT =’NO_MEMBER’ THEN GOTO ENDE
LOOP:FIND OWNER WITHIN SET_PA
Nachteile des NM:
• Query-Abfragen bedeuten navigieren im Netzwerk. Navigieren =
Ändern von Positionen im UWA; d.h. der Programmierer muß sagen
“wie” man die gesuchten Daten findet (prozeduraler
Programmierstil) , statt “was” gesucht wird (deklarativer
Programmierstil, wie z.B. SQL).
Der Applikations-Programmierer muß folglich das ganze Netzwerk
im Kopf haben!
• Views sind im NM nur sehr eingeschränkt (bis gar nicht) möglich
(Subschema).
• Delete: Problem der Sub-Baum Löschung:
Löschen des Record-Tupels L ⇒ L darf nicht Owner eines Sets ≠ Ø
sein.
Rekursiv fortpflanzendes Delete?
• Im Relationenmodell ist das Ergebnis einer Query wieder eine
Relation:
⇒ Schachtelung ergibt kompakte Querysprache
Im NM ist das Ergebnis einer Query kein Teilnetz, sondern Record
im UWA
⇒ im allgemeinen keine kompakte Schachtelung möglich.
⇒ Queries werden lang und unübersichtlich.
GET PROJEKT
PRINT (...)
FIND NEXT ANGPRO WITHIN SET_AP
IF STATUS_WORT =’NO_NEXT_MEMBER’ THEN GOTO ENDE
GOTO LOOP
ENDE: ...
Vorteile des NM:
• Vorteil gegenüber hierarchischen Datenbanksystemen:
Update-Anomalien über geeignete Kett-Records im Prinzip völlig
vermeidbar
(vgl. Normalisierung). D.h. eine redundanzfreie Speicherung ist
möglich.
Aber: Übersichtlichkeit des Netzwerks?
• Vorteil gegenüber Relationenmodell:
Hohe Performanz (da Pointerverfolgung schneller als Joins mit
Wertevergleich)
Abhilfe im RM: Sekundärindexe, Clustering.