Mutter

Kapitel 7
Dr. Brigitte Mathiak
Relationale Entwurfstheorie
Teil 1: Normalisierung
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
2
Lernziele

• Charakterisierung "guter" relationaler Schemata:
- jede Relation entspricht genau einer Objektmenge - eventuell
unter Einbezug von N:1- oder 1:1-Relationships - oder genau
einer Relationship-Menge zwischen Objekten
- Redundanz ist eliminiert, alle Informationen sind repräsentierbar,
und es treten keinerlei "Änderungsanomalien" auf
a) Änderungen können bei Beachtung der Primärschlüssel- und
Fremdschlüsselbedingung keine Inkonsistenzen hervorrufen
b) alle Informationen lassen sich unter Wahrung der Primärschlüsselund Fremdschlüsselbedingung (ohne "Kunstgriffe") einfügen
c) Informationen können einzeln wieder gelöscht werden, ohne die
Primärschlüssel oder Fremdschlüsselbedingung zu verletzen
• Ausnahmen wenn „schlechte“ Schemata sinnvoll sind
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
3
Erste Beispiel: „Schlechtes“ Datenbankschema
ProfVorl
PersNr
2125
2126
Name
Sokrates
Russel
2127
…
Kopernikus
…
Titel
Ethik, Mäeutik, Logik
Erkenntnistheorie,
Wissenschaftstheorie, Bioethik
n.a.
…
Warum ist das eine schlechte Idee?
Jeder für sich mit Zettel und Stift; 5 min
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
4
Zu wenig Struktur
Pro Zelle darf immer nur ein Fakt stehen, sonst können diese
nicht einzeln abgefragt werden.
… sonst können sie nicht einzeln referenziert werden.
… sonst können keine Zusatzinformationen zu den Fakten
gespeichert werden.
… sonst werden Einfüge- und Löschoperationen einzelner Fakten
zu komplexen Stringoperationen.
(Siehe auch die Probleme, die bei Aufgabenblatt 1 entstanden
sind)
Wenn in jeder Zelle nur ein Fakt steht, heißt das
1. Normalform
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
5
Wie komme ich in die Erste Normalform?
Beispiel (falsch):
Eltern
Vater
Mutter
Kinder
Johann
Martha
{Else, Lucie}
Johann
Maria
{Theo, Josef}
Heinz
Martha
{Cleo}
In 1 NF
Datenbanken, SS 12
Eltern
Vater
Mutter
Kind
Johann
Martha
Else
Johann
Martha
Lucie
Johann
Maria
Theo
Johann
Maria
Josef
Heinz
Martha
Cleo
Kapitel 7: Relationale Entwurfstheorie
6
Aber …
… manchmal kann es sinnvoll sein, die Daten doch einfach so zu
speichern. Zum Beispiel:
• Die einzelnen Fakten stehen getrennt gar nicht zur Verfügung
• müssten erst aufwändig getrennt werden
• werden getrennt nicht benötigt (Achtung!!! Könnte sich ändern)
Weiterhin:
Im letzten Kapitel haben wir gesehen, dass es einen Mismatch
zwischen relationalem Datenmodell und objektorientierten
Datenmodell besteht.
Es gibt Datenbanken (objektrelationale), die es erlauben direkt
Objekte und Listen zu speichern und dann auch darauf
zuzugreifen.
Nachteil: Unterobjekte können nicht mehr direkt zugegriffen
werden, es muss über die Oberobjekte navigiert werden.
Das Schema wird komplexer, Anfragen werden schwieriger...
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
7
Exkurs: NF2-Relationen
Non-First Normal-Form-Relationen
Geschachtelte Relationen (Oracle: Nested Tables)
Eltern
Vater
Johann
Johann
Heinz
Datenbanken, SS 12
Mutter
Kinder
KName
KAlter
Martha
Else
5
Maria
Lucie
Theo
3
3
Martha
Josef
Cleo
1
9
Kapitel 7: Relationale Entwurfstheorie
8
Beispiel 2: "Schlechte" Relationenschemata
ProfVorl
PersNr
2125
2125
2125
...
2132
2137
Name
Sokrates
Sokrates
Sokrates
...
Popper
Kant
Datenbanken, SS 12
Rang Raum VorlNr
C4
226
5041
C4
226
5049
C4
226
4052
...
...
...
C3
52
5259
C4
7
4630
Kapitel 7: Relationale Entwurfstheorie
Titel
Ethik
Mäeutik
Logik
...
Der Wiener Kreis
Die 3 Kritiken
SWS
4
2
4
...
2
4
9
Beispiel 2: "Schlechte" Relationenschemata
ProfVorl
PersNr
2125
2125
2125
...
2132
2137
Name
Sokrates
Sokrates
Sokrates
...
Schlick
Kant
Rang Raum VorlNr
C4
226
5041
C4
226
5049
C4
226
4052
...
...
...
C3
52
5259
C4
7
4630
Titel
Ethik
Mäeutik
Logik
...
Der Wiener Kreis
Die 3 Kritiken
SWS
4
2
4
...
2
4
Update-Anomalien
Sokrates zieht um, von Raum 226 in R. 338. Was passiert?
Einfüge-Anomalien
Neue/r Prof ohne Vorlesungen?
Löschanomalien
Letzte Vorlesung einer/s Profs wird gelöscht? Was passiert?
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
10
Beispiel 2: „Bessere" Relationenschemata
Vorlesungen
Professoren
VorlNr
Titel
5001
Grundzüge
4
2137
5041
Ethik
4
2125
5043
Erkenntnistheorie
3
2126
52
5049
Mäeutik
2
2125
309
4052
Logik
4
2125
PersNr
Name
Rang
Raum
2125
Sokrates
C4
226
2126
Russel
C4
232
2127
Kopernikus
C3
310
2133
Popper
C3
2134
Augustinus
C3
SWS gelesen
Von
Sokrates zieht um, von Raum 226 in R. 338. Was passiert?
Neue/r Prof ohne Vorlesungen?
Letzte Vorlesung einer/s Profs wird gelöscht? Was passiert?
Mit den aufgeteilten Relationen treten die Anomalien nicht mehr auf.
Woher kann man wissen wann man aufteilen muss und wie und wann nicht?
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
11
Erste, zweite und dritte Normalform
The key, the whole key and nothing but the key.
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
12
1. Normalform
• Neben der eben gelernten Definition gibt es noch eine andere
Jede Relation braucht einen
Primärschlüssel
• Eine einfache Lösung für dieses Problem ist es in jeder Tabelle
einen Schlüssel künstlich zu erzeugen
• Das greift aber zu kurz
• Wichtig ist, dass es semantisch Sinn macht, die Attribute unter
einem Primärschlüssel zu führen, weil Sie zu einer Sinneinheit
gehören
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
13
2. Normalform
Jedes Attribut hängt vom
ganzen Primärschlüssel ab.
Gegenbeispiel:
PersNr, Name, Gehalt, Dienstwagennr, Kennzeichen, Kilometer
PersNr und Dienstwagennr sind zwar ein legitimer
Primärschlüssel, aber stehen für zwei verschiedene Entitäten
Formal kann man das Problem wieder dadurch lösen, dass ,man
künstliche einspaltige Primärschlüssel erzeugt
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
14
3. Normalform
Attribute müssen direkt vom
Primärschlüssel abhängen
Gegenbeispiel:
PersNr, Name, Gehalt, Dienstwagennr, Kennzeichen, Kilometer
Es entsteht dasselbe Problem wie bei der zweiten Normalform, nur subtiler.
Hier hilft nur scharfes Hingucken und Verstehen, was die Daten bedeuten.
Fragen Sie sich für jedes Attribut:
• Gibt es für einen gegebenen Schlüssel nur eine sinnvolle Möglichkeit für den
Wert des Attributs? (funktionale Abhängigkeit)
• Beschreibt das Attribut dasselbe Objekt wie der Schlüssel?
• Möchten Sie vielleicht in anderem Kontext dieses Attribut referenzieren ohne
den Schlüssel?
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
15
Erste, zweite und dritte Normalform
The key, the whole key and nothing but the key.
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
16
Beispiel
Kind
Sofie
Sofie
Niklas
Niklas
...
…
Vater
Alfons
Alfons
Alfons
Alfons
...
…
Stammbaum
Mutter
Sabine
Sabine
Sabine
Sabine
...
…
Opa
Lothar
Hubert
Lothar
Hubert
Lothar
…
Oma
Linde
Lisa
Linde
Lisa
Martha
…
Was ist das Problem?
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
17
Beispiel
Kind
Sofie
Sofie
Niklas
Niklas
...
…
Vater
Alfons
Alfons
Alfons
Alfons
...
…
Stammbaum
Mutter
Sabine
Sabine
Sabine
Sabine
...
…
Opa
Lothar
Hubert
Lothar
Hubert
Lothar
…
Oma
Linde
Lisa
Linde
Lisa
Martha
…
Problem 1: Keine Spalte ist eindeutig und damit als einfacher
Primärschlüssel geeignet
Problem 2: {Kind, Opa} wäre ein eindeutiger Primärschlüssel,
aber Kind allein bestimmt bereits Vater und Mutter
Problem 3: Ein künstlicher Primärschlüssel hätte dasselbe
Problem
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
18
Beispiel
Kind
Sofie
Sofie
Niklas
Niklas
...
…
Vater
Alfons
Alfons
Alfons
Alfons
...
…
Stammbaum
Mutter
Sabine
Sabine
Sabine
Sabine
...
…
Opa
Lothar
Hubert
Lothar
Hubert
Lothar
…
Oma
Linde
Lisa
Linde
Lisa
Martha
…
Wie kann man die Relation verändern, dass die
Probleme nicht mehr auftreten?
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
19
Zerlegung (Dekomposition) von Relationen
Korrektheitskriterien für die Zerlegung von Relationenschemata:
1. Verlustlosigkeit
-
Die in der ursprünglichen Relationenausprägung Q des Schemas R
enthaltenen Informationen müssen aus den Ausprägungen
Q1, ..., Qn der neuen Relationenschemata R1, .., Rn
rekonstruierbar sein.
2. Abhängigkeitserhaltung
-
Die für R geltenden Anhängigkeiten
müssen auf die Schemata R1, ..., Rn übertragbar sein.
Satz: Jede Relation kann durch verlustlose und
abhängigkeitserhaltende Zerlegung in 3 NF gebracht werden.
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
20
Verlustlose Zerlegung – Die Informationen bleiben erhalten
Vater
Johann
Johann
Heinz
Eltern
Mutter
Martha
Maria
Martha
SELECT Vater, Kind FROM Eltern
Vater
Johann
Johann
Heinz
SELECT Mutter, Kind FROM Eltern
Mutter
Martha
Maria
Martha
Kind
Else
Theo
Cleo
Vater
Johann
Johann
Heinz
Datenbanken, SS 12
Kind
Else
Theo
Cleo
Natural Join
Mutter
Martha
Maria
Martha
Kapitel 7: Relationale Entwurfstheorie
Kind
Else
Theo
Cleo
Kind
Else
Theo
Cleo
21
Abhängigkeiten bleiben erhalten
Jedes Kind hat genau eine Mutter und genau einen Vater
Eltern können jedoch auch mehrere verschiedene Kinder haben
Ein Vater kann mit mehreren verschiedenen Müttern Kinder
haben. Und umgekehrt. Es bestimmt keine Bindung im Sinne
der Relation
Kind
*
*
1
1
Mutter
Vater
*
Kind
1
*
1
Mutter
Vater
Datenbanken, SS 12
Kind
Kapitel 7: Relationale Entwurfstheorie
22
Biertrinker-Beispiel
Biertrinker
Lokal
Gast
Bier
Einstein
Gniffke
Pils
Einstein
Anders
Hefeweizen
Mephisto
Gniffke
Hefeweizen
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
23
Biertrinker-Beispiel: Informationsverlust
Lokal
Einstein
Einstein
Mephisto
Biertrinker
Gast
Gniffke
Anders
Gniffke
SELECT Lokal, Gast FROM Biertrinker
Bier
Pils
Hefeweizen
Hefeweizen
SELECT Gast, Bier FROM Biertrinker
Lokal
Gast
Gast
Bier
Einstein
Gniffke
Gniffke
Pils
Einstein
Anders
Anders
Hefeweizen
Mephisto
Gniffke
Gniffke
Hefeweizen
Lokal
Einstein
Einstein
Einstein
Mephisto
Mephisto
Datenbanken, SS 12
Natural Join
Gast
Bier
Gniffke
Pils
Gniffke
Hefeweizen
Anders
Hefeweizen
Gniffke
Pils
Gniffke
Hefeweizen
Kapitel 7: Relationale Entwurfstheorie
24
Erläuterung des Biertrinker-Beispiels
Es gibt keine festen Abhängigkeiten zwischen den Attributen.
Jeder kann in jedem beliebigen Lokal das Bier bestellen, das er will.
Damit kann diese Relation nicht zerlegt werden ohne
Informationsverlust.
Es können aber auch keine Abhängigkeiten verletzt werden.
Wie bringt man die Biertrinker in 3. Normalform?
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
25
Verlustige Zerlegung – Die Informationen sind weg!
Vater
Johann
Johann
Heinz
Eltern
Mutter
Martha
Maria
Martha
SELECT Vater, Kind FROM Eltern
Vater
Johann
Johann
Heinz
Kind
Else
Theo
Cleo
SELECT Mutter FROM Eltern
Mutter
Martha
Maria
Martha
Kind
Else
Theo
Cleo
Natural Join
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
26
Abhängigkeiten bleiben nicht erhalten
In der neuen Mutterrelation fehlt die Verbindung zum Kind!
*
1
Vater
*
Kind
*
1
Mutter
Kind
1
*
1
Mutter
Vater
Datenbanken, SS 12
Kind
Kapitel 7: Relationale Entwurfstheorie
27
Aber…
… manchmal möchte man doch, dass die Fakten in einer Relation
zusammen stehen.
Warum???
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
28

Data Warehouse (ganz kurz)
Das Data Warehouse dient dem Reporting von
wirtschaftsrelevanten Daten an z.B. das Management.
Ziel: Zu bestimmten Zeitpunkten alle relevanten Daten aus der
Datenbank zu ziehen und dann für statistische Untersuchungen
zur Verfügung zu stellen
Diese Daten werden typischerweise in
nur ganz wenige Relationen
geschrieben (Stichwort Sternschema),
• da sie sich nicht ändern werden
• da man sich so Joins bei den Abfragen
spart
• da man so automatisch statische
Analysen laufen lassen kann
Aus Wikipedia (Stern_Schema)
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
29

Triplifizierung (vereinfacht)
TripleStore
Subjekt
Prädikat
Objekt
Professor
hatPrädikat
hatRaum
Sokrates
istInstanzVon
Professor
Sokrates
hatRaum
226
hatRaum
hatObjektTyp
integer
Sokrates
hältVorlesung
Ethik
Ethik
hatSWS
4
hört
hatSubjektTyp
Mensch
Professor
istEin
Mensch
Student
istEin
Mensch
hört
hatObjektTyp
Vorlesung
Carnap
hört
Ethik
Carnap
istInstanzVon
Student
…
…
…
Vor- und Nachteile?
Es ist alles in einer Tabelle
Es ist alles maximal normalisiert
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
30

Triplifizierung (vereinfacht)
TripleStore
Subjekt
Prädikat
Objekt
Professor
hatPrädikat
hatRaum
Sokrates
istInstanzVon
Professor
Sokrates
hatRaum
226
hatRaum
hatObjektTyp
integer
Sokrates
hältVorlesung
Ethik
Ethik
hatSWS
4
hört
hatSubjektTyp
Mensch
Professor
istEin
Mensch
Student
istEin
Mensch
hört
hatObjektTyp
Carnap
hört
Carnap
istInstanzVon
…
…
TripleStore
Vorlesung
Subjekt
Prädikat
Ethik
Professor
istInstanz
Student
Sokrates
istInstanzVon
…
Sokrates
istInstanz
Objekt
nein
Professor
???
Woher weiß ich, ob die Daten überhaupt stimmen?
Woher weiß ich, was Daten sind und was zur Struktur gehört?
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
31
Triplifizierung (und verwandte Methoden z.B. DOM)

• Wird eingesetzt, wenn die Datenstruktur nicht bekannt ist oder
sich noch ändern kann
• Eindeutiger Vorteil ist die Vernetzbarkeit. Jemand anders kann
seinen eigenen TripleStore einfach ankoppeln und schon hat
man doppelt so viele Daten
• Ein Nachteil ist die Überprüfung von Konsistenz
• Was ist in dem Zusammenhang überhaupt eine Inkonsistenz?
• A istInstanzVon B und B istInstanzVon A (schwierig)
• A istKindVon B und B istKindVon C und C istKindVon A
(schwierig zu berechnen)
• Das Problem ist verwandt mit Logik
• Weiterer Nachteil ist die Navigierbarkeit:
• Beispiel: Gib alle Personen aus (erfordert transitive Hülle)
• Es ist deutlich einfacher, wenn man die Prädikate und Typen
von vornherein festlegt, leider auch weniger flexibel
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
32
Zwischenfazit
Vorteile der Normalisierung
• Es können keine Anomalien auftreten
Nachteil der Normalisierung
• Unter Umständen werden Anfragen langsamer, da mehr Joins
notwendig sind
• Es gibt verschiedene Standardmodelle, die nicht normalisiert
oder sogar übernormalisiert sind
• Vor- und Nachteile sind im Einzelfall abzuwägen
• Im Normalfall (z.B. in der Prüfung) gilt: 3 NF ist am Besten
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
33

Teil 2: Entwurfsmuster
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
34

Lernziel
Komplexe Datentypen wie Listen, Bäume und Graphen in SQL
effizient darstellen
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
35

Motivation
Bei der Umsetzung von UML haben wir bisher nur Assoziation,
Generalisierung und Attribute betrachtet, doch was ist mit
komplexen Datentypen wie:
Listen, Stacks, Heaps, Bäumen, Graphen, Maps, …?
Diese werden nativ nicht von relationalen Datenbanken
unterstützt (mit Ausnahmen, wie etwa XML), können aber
dargestellt werden.
Allerdings haben diese Darstellungen verschiedene Vor- und
Nachteile.
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
36

Listen
TODOs
ID
Titel
next
Darstellung als verkettete Liste:
1
aufräumen
2
Hauptproblem ist die Ineffizienz
2
Zur Uni gehen
3
3
Party
null
der transitiven Hülle
Beispiel: Wie viele TODOs kommen noch nach ‚aufräumen‘`?
Gib mir alle Titel in der Listenreihenfolge aus.
Weiteres Problem ist die Datenintegrität. (next sollte unique sein)
TODOs
Darstellung wie Array:
ID
Titel
Index
Hauptproblem ist die Verwaltung
1
aufräumen
1
von Inserts und Deletes
2
Zur Uni gehen
2
3
Party
3
Beispiel: Lösche ‚aufräumen‘.
Füge ‚Hausaufgaben‘ zwischen ‚Uni‘ und ‚Party‘ ein.
Vorteil: Anfragen gehen meist schnell und unproblematisch.
Im Idealfall kann die Reihenfolge aus den Werten mit ORDER BY
berechnet werden (z.B. aus ID oder einem Timestamp)
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
37
Bäume

simplifiedDOM
ID
type
1
element
DOM:
2
element
Problem ist wieder die
3
element
schlechte Performanz
4
text
von Abfragen wie:
Welchen Text enthält Element x?
Auf welcher Hierarchieebene ist Element x?
Was sind die Vorgänger?
content
parent
next
html
null
null
head
1
3
body
1
null
Test!
3
null
Leider sind diese Art Abfragen äußerst typisch für Operationen mit
XML-Dokumenten.
Dasselbe Problem tritt auf für andere Baumstrukturen, z.B.
Bauteile eines Autos
Auto -> Motor -> Einspritzpumpe -> Kurbelwelle
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
38
Bäume (Forts.) – Pre-post-table

Statt parent und next wird die Pre- und Postorder gespeichert.
Aus Implementing Filesystems by Tree-aware DBMSs.
Alexander Holupirek, and Marc H. Scholl. In Proc. VLDB 2008 PhD Workshop. pp. 1623-1630, 2008.
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
39

Bäume (Forts.) – Pre-post-table
Elternknoten
Nachfolger
Vorgänger
Kindknoten
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
40
Bäume (Forts.) – Pre-post-table

Wenn man noch die Höhe (level) im Baum dazu nimmt, kann man
fast alle sinnvollen Anfragen nativ in effizientem SQL stellen.
Beispiel: Welcher Text steht unter Element x?
SELECT n.content FROM nodes n, nodes x
WHERE x.ID = ‘x‘ AND x.post < n.post AND x.pre> n.pre
AND n.type = text ORDER BY n.post;
Welcher ist der Vaterknoten?
SELECT p.ID FROM nodes p, nodes x
WHERE x.ID = ‘x‘ AND x.post > p.post AND x.pre < p.pre
AND x.level = p.level + 1;
Wie viele Knoten kommen noch nach x?
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
41
Careting (ORDPATH)

Im das Einfügeproblem in den Griff zu bekommen, kann man
Carets benutzen.
Regel 1: Ein Kindknoten verlängert den Code des Elternknoten
Beispiel: 1.5.3.9. ist der Elternknoten von 1.5.3.9.1
Regel 2: Geschwister sind in der korrekten Reihenfolge abgelegt
Beispiel: 1.5.3.9.1 kommt vor 1.5.3.9.3
Regel 3: Gerade Indexzahlen werden für Generationen ignoriert
Beispiel: 1.5.3.9. ist der direkte Elternknoten von 1.5.3.9.2.4.3
Geschwister können so immer dazwischen kopiert werden
Regel 4: Root heißt 1 und alle Knoten enden auf Ungerade
Leider kann man das nicht mehr nativ in SQL abfragen.
Siehe auch [ORDPATHs: insert-friendly XML node labels. A. O'Neil, et al. Proc. ACM
SIGMOD Management of data, pp. 903-908, 2004] wird eingesetzt von SQL Server
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
42

Fazit – Teil 2
Es gibt mehrere Möglichkeiten komplexe Datenstrukturen in
Datenbanken abzubilden.
Wir haben hier Listen und Bäume betrachtet (andere
Datenstrukturen funktionieren ähnlich)
Man hat (vereinfacht gesagt) die Auswahl zwischen schnellen
Anfragen mit Indexzahlen und schnellen Änderungsoperationen
mit Zeigern.
Es kommt also auf die Anwendung an.
Datenbanken, SS 12
Kapitel 7: Relationale Entwurfstheorie
43