Postrelationale Datenbanken

Postrelationale Datenbanken
•
Grenzen relationaler DB-Technologie
– Relationale
R l ti
l DB werden
d iin „Standardbereichen“
St d db i h “ eingesetzt:
i
t t
•
•
•
•
•
Personalwesen,
Buchungs- und Abrechnungswesen,
Produktionsplanung und -steuerung,
Lagerverwaltung,
Finanz- und Investitionsplanung, ...
– Typische Eigenschaften dieser Miniwelten sind:
• Die Datenbanken enthalten viele kleine und einfach strukturierte Objekte.
• Es werden nur einfache Bedingungen an die Daten gestellt, die vom DBMS
überwacht werden müssen.
• Es existieren kurze, einfache Transaktionen, d.h. wenige Objekte werden
zusammenhängend manipuliert.
• Die Datenbank verwaltet meist nur den jeweils aktuellen Zustand der
Anwendungswelt.
• Die Daten werden zentral verwaltet und über zentrale Prozesse den Anwendern
zur Verfügung gestellt und ausgewertet
ausgewertet.
16. Prof. Jasper: Datenbanksysteme
1
Anforderungen an neuere DB-Technologie
•
Konventionelle Datenbanken bereiten Probleme bei komplexeren Miniwelten,
z B
z.
B. bei geographischen Anwendungen im Katasterwesen
Katasterwesen, bei CADCAD
Anwendungen im Ingenieurbereich. Anforderungen sind hier:
– 1
1. Komplexe Objekte
Es werden üblicherweise große Objekte verwaltet, z. B. Bilder, die mehrere MB
Speicherplatz belegen. Darüber hinaus können Objekte (z. B. im CAD-Bereich) eine
komplexe
p
interne Struktur besitzen, die p
partiell manipulierbar
p
sein soll. Die komplexe
p
Struktur kann zwar in relationalen DB nachgebildet werden, dabei werden jedoch die
Bestandteile eines komplexen Objekts über mehrere Relationen verstreut. Das
macht die aufwändige Rekonstruktion des Objekts notwendig, bevor es verarbeitet
werden kann
kann.
– 2. Komplizierte Integritätsbedingungen
Oft existieren in der Anwendungswelt nicht-triviale Konsistenz-/ Integritätsbedingungen, die sich ebenso schwer formulieren wie überprüfen lassen. Z. B. ist bei
der Speicherung von Katasterdaten zu beachten, dass zwischen den Parzellen kein
toter Raum entsteht und dass sich Parzellen nicht überschneiden dürfen.
16. Prof. Jasper: Datenbanksysteme
2
Weitere Anforderungen
– 3. Versionsverwaltung
Alte Zustände von g
gespeicherten
p
Objekten
j
bzw. Versionen oder Alternativen sollen
verwaltet werden und einfach zugreifbar und manipulierbar sein. So soll im
Ingenieurbereich oft zu einer Version die Menge der Varianten mit einer Operation in
einem bestimmten Parameter (z.B. Ausgangsmaterial) verändert werden können.
Od aufbauend
Oder
fb
d auff einer
i
V
Version
i wird
i d ein
i neuer E
Entwurf
t
fd
durchgeführt,
h füh t wobei
b i auff
einen Teil aus der Version von vor 2 Jahren zurückgegriffen werden soll.
– 4
4. Verteilung
In den komplexen Anwendungswelten werden oft sehr leistungsstarke
Arbeitsplatzrechner (z.B. CAD-Workstations) eingesetzt, die komplexe Aufgaben
lokal erledigen. Die benötigten Daten / Objekte sollen dabei transparent und
konsistent auf allen Arbeitsplatzrechnern zur Verfügung stehen, so dass jeder zu
jedem Zeitpunkt mit ihnen arbeiten kann.
– 5. Lange Transaktionen
Der Entwurf von Objekten in den angesprochenen Anwendungswelten kann sehr
lange dauern (Tage bis Wochen). Dabei muss das manipulierte Objekt (oder eine
Version davon) natürlich auch anderen Benutzern zur Verfügung stehen
stehen.
16. Prof. Jasper: Datenbanksysteme
3
Das NF2-Modell
•
Das Non-First Normal Form Modell (NF2-Modell) ist Anfang der 80iger Jahre als
Erweiterung und damit auch als Nachfolger des relationalen Datenmodells definiert
worden. Wesentliches Ziel war die Aufhebung der 1. Normalform, d. h. die Werte eines
Attributs müssen nicht mehr atomar sein. Motivation war im wesentlichen die Verwaltung
komplexer Objekte in DB. Das NF2-Modell soll insbesondere Dokumente des
gut darstellen können, die z.B. bezüglich
g
der folgenden
g
drei Aspekte
p
Bürobereichs g
charakterisiert werden können:
–
–
–
•
Bibliographische Daten (unformatierte Titel, strukturierte Daten wie Erscheinungsdatum,
mengenwertige Angaben wie Autoren)
Deskriptoren
p
((mengenwertig)
g
g)
Dokumententext (unformatiert, Reihenfolgen von Abbildungen, Tabellen, etc.) besteht aus Inhalt
(Kapitel, Abschnitte, Sätze, Worte und Buchstaben; auch Abfragen der Form "Gesucht sind alle
Dokumente bei denen in einem Satz im ersten Kapitel die Worte DB und IR vorkommen) und
Layout (Ein Dokument besteht aus Seiten, auf denen rechteckige Bereiche inhaltliche
Informationen (eine Adresse, eine Anrede, ein Abschnitt in mehreren Spalten, eine Tabelle, eine
Abbildung, ein Bild, etc.) aufnehmen).
Insbesondere die Probleme "Unformatiertheit" und "Mengenwertigkeit"
g
g
treten hierbei auf.
Im NF2-Modell werden diese durch genau eine Erweiterung der Schema-Definitionen
gegenüber dem relationalen Modell gelöst: als Attributwerte sind wiederum (NF2-)
Relationen erlaubt. Die DML wird um zwei Operationen erweitert, die komplexe Objekte
konstruieren und auch wieder auseinandernehmen können.
16. Prof. Jasper: Datenbanksysteme
4
Struktur des NF2-Modells
•
Formal wird wieder von einer Menge von "atomaren" Domänen DOM = {D1,
...Dn}} ausgegangen.
g g g
Ferner g
gibt es eine Menge
g von Namen für Datenbanken,,
Relationen und Attribute, den Bereich Name (wie in Kapitel 2 beim rel. Modell).
•
p
aus NF2-Schema und NF2-Extension.
Eine NF2-DB besteht dementsprechend
•
Die Menge der NF2-Schemata ist wie folgt definiert:
– NF2-Schema = Name x Relationenschema + x IB
– Relationenschema = Name x Attributschema+x Name+
– Attributschemata = ((Name x DOM)) oder Relationenschema
•
Jedes NF2-Schema hat somit einen Namen und eine Menge von Relationenvereinbarungen.
g
Jede Relationenvereinbarung
g hat einen Namen und eine
Menge von Attributbeschreibungen sowie die Menge von Attributnamen, die
den Primärschlüssel definieren. Attributbeschreibungen sind entweder wie im
relationalen Fall Name-Wertebereich-Paare oder aber wiederum Relationenvereinbarungen
vereinbarungen.
16. Prof. Jasper: Datenbanksysteme
5
Beispiel für ein NF2-Schema
•
•
Wir betrachten ein Unternehmen (enterprise), das aus einzelnen Abteilungen
(departments) besteht, die durch eine Nummer (dno) und einen Manager (mgrnr)
beschrieben werden. Jeder Abteilung steht ein bestimmtes Budget (budget) und eine
Menge von Ausrüstungsgegenständen (equip) zur Verfügung.
Von den Abteilungen werden Projekte (projects) durchgeführt, die einen Namen (pname)
und eine Nummer (pno) sowie Mitglieder (members) haben. Mitglieder werden
beschrieben durch Funktion (function) und Nummer (empno). Zu der Ausrüstung wird
Anzahl (qu) und Typ (type) verwaltet.
enterprise = ( departments ( dno: int,
mgnr: int,
projects: ( pno: int,
pname: char(4),
p
( ),
members: ( empno: int,
funcion: char(20),
empno),
pno),
pno)
budget: float,
equip: (
qu: int,
type: char(10),
(qu, type)),
dno)).
16. Prof. Jasper: Datenbanksysteme
6
Beispielsextension zum Beispiel
{DEPARTMENTS}
DNO
{PROJECTS}
MGRNO
PNO
PNAME
BUDGET
{MEMBERS}
{EQUIP}
QU TYPE
EMPNO FUNCTION
314
56194
17
CGA
39582
56019
69011
Leader
Consultant
Secretary
23
HPAR
58912
990011
78218
98902
Staff
Leader
e de
Secretary
Staff
320.000
2
3
1
3278
PC/AT
PC
218
71349
25
LEXI
72227
89211
92100
89921
99025
44512
Staff
Staff
Leader
Consultant
Secretary
Consultant
440.000
2
2
1
1
3278
PC/AT
3179
PC/GA
417
91093
37
NDBS
87710
81193
75913
96001
Secretary
Leader
Staff
Staff
360.000
1
1
1
2
1
1
1
4361
PC/XT
PC/AT
3278
3270
3179
PC/GA
16. Prof. Jasper: Datenbanksysteme
7
DML für NF2
•
Da bei Schemadefinitionen im NF2-Modell das Konstrukt der
relationen wertigen Attribute angeboten wird
relationen-wertigen
wird, muss die
Datenmanipulationssprache (hier Relationenalgebra) wie folgt erweitert
werden:
– Umbenennung(), Vereinigung (), Differenz (-), Projektion () und
kartesisches Produkt ((x)) sowie die davon abgeleiteten
g
Operationen
p
sind
auf Relationen definiert und bleiben deshalb gleich.
– Die Selektionsfunktion (s) wird so erweitert
erweitert, dass Mengen und
Mengenoperatoren in der Funktion  genutzt werden können.
– Zwei
Z i zusätzliche
ät li h O
Operatoren
t
(
(nest
t und
d unnest)
t) werden
d eingeführt.
i
füh t
16. Prof. Jasper: Datenbanksysteme
8
Nest
•
•
Eine Nestung  [(A1, ..., An); A](R) fasst die Attribute A1, ..., An des
Relationenschemas R zu einem neuen Attribut A zusammen
zusammen.
Beispiele:
R
A
B
C
a1
1
a2
a3
a4
a5
b1
b1
b1
b2
b2
c1
1
c1
c2
c2
c2
 [A;A$](R)
A$
A
{a1, a2}
{a3}
{a4, a5}
[(A B) AB$] (R)
 [(A,B);
b1 c1
b1 c2
b2 c2
C
AB$
A
a1
a2
a3
a4
a5
16. Prof. Jasper: Datenbanksysteme
B C
B
b1
c11
b1
c2
b2
9
Unnest
•
Unnest: : NF2-Relation x Attributnamen  NF2-Relation
Bei unnest (R, A) bzw. [A](R) sind zwei Fälle zu unterscheiden:
– A iistt atomar:
t
hier
hi ist
i t nichts
i ht zu „unnesten“
t “
– A ist nicht atomar: in diesem Fall werden die anderen Attribute
entsprechend dupliziert. Beispiel:
R
A
B C
{a1, a2} b1 c1
{a3} b1 c2
{a4, a5} b2 c2
•
[A] (R) A
a11
a2
a3
a4
a5
B C
b1
b1
b1
b2
b2
c11
c1
c2
c2
c2
Nest und Unnest sind nicht invers!
16. Prof. Jasper: Datenbanksysteme
10
SQL für NF2
•
•
•
SQL-Erweiterung für NF2
B i iistt SQL fü
Basis
für 1NF
1NF-Relationen
R l ti
(R
(Relationen
l ti
iin 1
1. N
Normalform).
lf
)
Folgende Erweiterungen in SELECT-, FROM- und WHERE-Klauseln
notwendig
g ((Erweiterungen
g kursiv):
)
SELECT <Bildbereich> FROM <Definitionsbereich> WHERE <Auswahlkriterium>
1NF-Relation
Angabe von Attributen
Qualifizierung auch
oder NF2-Relation
und ihres Levels
durch mengenbezogene
Bedingungen
•
Bem.
In dieser Syntax gegenüber 1NF-SQL verwirrend, da
unter SELECT bei NF2 die Relation ((statt der Attribute)) und unter
FROM
die
Attribute
(statt
der
Relationen)
stehen!
•
Die Beispiele betreffen folgende sechs Relationen (Tab.
(Tab 1 bis 4 stellen
"normale" 1NF-Relationen, Tab. 5 eine auf diesen basierende NF2Relation (siehe auch Abb. 4.1 oben) und Tab. 6 eine 1NFE b i l ti dar).
Ergebnisrelation
d )
16. Prof. Jasper: Datenbanksysteme
11
NF2-Beispiel (SQL)
DEPARTMENTS-INF
PROJECTS-INF
DNO
MGRNO
BUDGET
PNO
PNAME
DNO
314
218
417
56194
71349
91093
320.000
320
000
440.000
360.000
17
23
25
37
CGA
HPAR
LEXI
NDBS
314
314
218
417
Tab. 1
Tab. 2
MEMBERS-INF
EQUIP-INF
DNO
PNO
EMPNO
FUNCTION
314
314
314
314
314
314
314
218
218
218
218
218
218
417
417
417
417
17
17
17
23
23
23
3
23
25
25
25
25
25
25
37
37
37
37
39582
56019
69011
58912
90011
78218
78
8
98902
72227
89211
92100
89921
99025
44512
87710
81193
75913
96001
Leader
Consultant
Secretary
Staff
Leader
Secretary
Staff
Staff
Staff
Leader
Consultant
Secretary
Consultant
Secretary
Leader
Staff
St ff
Staff
Tab. 3
(Jeder Mitarbeiter höchstens in einem Projekt!)
DNO
314
314
314
218
218
218
218
417
417
417
417
417
417
417
QU
2
3
1
2
2
1
1
1
1
1
2
1
1
1
TYPE
3278
PC/AT
PC
3278
PC/AT
3179
PC/GA
4361
PC/XT
PC/AT
3278
3270
3179
PC/GA
Tab. 4
16. Prof. Jasper: Datenbanksysteme
12
NF2-Beispiel (SQL) (Forts.)
{DEPARTMENTS}
DNO
{PROJECTS}
MGRNO
PNO
PNAME
BUDGET
{MEMBERS}
{EQUIP}
QU TYPE
EMPNO FUNCTION
314
56194
17
CGA
39582
56019
69011
Leader
Consultant
Secretary
23
HPAR
58912
90011
78218
98902
Staff
Leader
Secretary
Staff
320 000
320.000
2
3
1
3278
PC/AT
PC
218
71349
25
LEXI
72227
89211
92100
89921
99025
44512
Staff
Staff
L d
Leader
Consultant
Secretary
Consultant
440.000
2
2
1
1
3278
PC/AT
3179
PC/GA
417
91093
37
NDBS
87710
81193
75913
96001
Secretary
Leader
Staff
Staff
360.000
1
1
1
2
1
1
1
4361
PC/XT
PC/AT
3278
3270
3179
PC/GA
16. Prof.
Jasper: Datenbanksysteme
Tab. 5 (Vier top level und neun
atomare
Attribute)
13
Beispiel (Forts.)
•
Bsp. 1 Dieses Beispiel zeigt, wie man alle (deshalb auch keine WHERE-Klausel) Tupel
einer NF2-Relation ((Tabelle 5)) liest und sie dann wieder unverändert in eine NF2Ergebnisrelation abbildet. Es ist also ein eher realitätsfernes Beispiel, das aber die
wesentlichen Elemente der NF2-DML aufzeigt
SELECT x.DNO,
x.MGRNO,
PROJECTS:= (SELECT y.PNO,
y PNAME
y.PNAME,
MEMBERS:=
FROM
x.BUDGET,
EQUIP:=
FROM
(SELECT
z.EMPNO,
z.FUNCTION
O z IN y
y.MEMBERS)
S)
FROM
y IN x.PROJECTS)
(SELECT v.QU,
v.TYPE
FROM v IN x.EQUIP)
x IN DEPARTMENTS.
16. Prof. Jasper: Datenbanksysteme
14
Beispiel (Forts.)
•
•
•
Ausgang: Tab. 1-4 mit 1 NF-Relationen
Ziel:
Aus diesen 1NF-Relationen
1NF Relationen die NF2-Relation
NF2 Relation aus Tab.
Tab 5
erstellen
Lösung: folgender SQL-Ausdruck vergleichbar Bsp. 1
SELECT x.DNO,
DNO
x.MGRNO,
PROJECTS:= (SELECT
FROM
WHERE
x.BUDGET,
BUDGET
EQUIP:=
FROM
(SELECT
FROM
WHERE
x IN DEPARTMENTS-1NF.
y.PNO,
y.PNAME,
MEMBERS:=
(SELECT
z.EMPNO,
z.FUNCTION
FROM z IN MEMBERS-1NF
WHERE
z PNO = y.PNO
z.PNO
y PNO
AND
z.DNO = y.DNO)
y IN PROJECTS-1NF
y.DNO = x.DNO)
v.QU,
v.TYPE
v IN EQUIP-INF
v.DNO = x.DNO)
16. Prof. Jasper: Datenbanksysteme
15
Beispiel (Forts.)
•
•
•
Ausgang:
Zi l
Ziel:
Lösung:
Tab. 5 als NF2-Relation
T b 6 (BUDGET und
Tab.
d EQUIP fehlen)
f hl )
SELECT X. DNO,, X. MGRNO,, Y. PNO,, Y. PNAME,, Z. EMPNO,, Z. FUNCTION
FROM X IN DEPARTMENTS, Y IN X. PROJECTS, Z IN Y. MEMBERS.
Result Table
DNO
MGRNO
PNO
PNAME
EMPNO
FUNCTION
314
314
314
314
314
.
.
218
.
.
417
56194
56194
56194
56194
56194
.
.
71349
.
.
91093
17
17
17
23
23
.
.
25
.
.
37
CGA
CGA
CGA
HPAR
HPAR
.
.
LEXI
.
.
NDBS
39582
56019
69011
58912
90011
.
.
92100
.
.
96001
Leader
Consultant
Secretary
Staff
Leader
.
.
Leader
.
.
Staff
Tab. 6
16. Prof. Jasper: Datenbanksysteme
16
Exkurs: Temporale DB (Versionierung)
•
Zeit in Datenbanken:
– Gespeicherte Daten (und in einem eingeschränkten Sinne auch die Metadaten)
verändern sich somit im Laufe der Zeit,
Zeit sind also Daten,
Daten die einen zeitlichen Aspekt
besitzen.
– Die zeitlichen Aspekte der Daten / Objekte werden oft vernachlässigt. Meist
beinhalten Datenbanken nur Informationen über den aktuell g
gültigen
g Ausschnitt der
realen Welt (Schnappschuss-Semantik). Jedoch muss in vielen Fällen auch
zeitbezogene Information mit verwaltet werden und u.a. für Abfragen nutzbar sein:
• Verträge haben ein Verabschiedungs-(Unterzeichnungs-)datum sowie einen
Gül i k i
Gültigkeitszeitraum
i
(B
(Beginn
i /E
Ende
d meist
i auff di
die S
Stunde
d genau).
)
• Kunden sollen zu einem bestimmten Zeitpunkt mit Waren beliefert werden.
• Einwohnermeldeämter speichern die Ein-/Aus-/Umzugszeitpunkte der Bürger.
• Dokumente können zeitlich versioniert werden ("Fassung vom 10.10.1992").
• Module der Modulverwaltung haben eine Gültigkeit
– Zeitliche Aspekte betreffen jedoch nicht nur die Verwaltung und Abfrage von
S i h
Speicherungsund
d Gülti
Gültigkeitsaussagen,
k it
sondern
d
auch
h di
die K
Konsistenz
i t
von D
Daten
t
und Datenänderungen. Dieses wird insbesondere bei den dynamischen
Integritätsbedingungen (siehe dort) berücksichtigt, die Aussagen über den gesamten
Verlauf von Daten / Objekten einer DB machen.
16. Prof. Jasper: Datenbanksysteme
17
Zeitstrukturen allgemein
A
A.
linear
B.
C.
verzweigt
analog
diskret(Chronon: kleinste Einheit)
unbeschränkt
D.
Zeitpunkt
parallel
beschränkt
>
<
Zeitintervall
16. Prof. Jasper: Datenbanksysteme
einseitig (un)beschränk
>
<
Zeitspanne
t
18
Algebra: Zeitrelationen (nach Allen)
A before B
B after A
A meets B
B met-by
b A
A
B
A
B
A overlaps B
B overlapped-by A
A
A starts B
B started-by
started b A
A
B
A
A during B
B contains
t i A
B
A finishes B
B finished-by
fi i h d b A
A equals
l B
B
A
B
A
B
16. Prof. Jasper: Datenbanksysteme
19
Arten zeitlicher Qualifizierungen
symbolisch
absolut
relativ
numerisch
vor
dem
3 Wochen nach
dem
1.1.1992
1.1.1992
vor
der
3 Wochen nach
der
Party
Party
16. Prof. Jasper: Datenbanksysteme
20
Die temporale Datenbank
•
Folgende Aspekte kennt eine temporale Datenbank:
– Gültigkeitszeitraum
Die Zeit
Zeit, in der eine Aussage (bzw
(bzw. das diese Aussage repräsentierende Tupel) in
der modellierten Welt wahr ist. Diese Zeit kann aus einem oder mehreren
Zeitpunkten / Zeitintervallen bestehen.
– Transaktionszeit
Der Zeitpunkt, an dem eine Aussage in die Datenbank eingefügt wird. Beachte, dass
alle Tupel, die in einer Transaktion in die DB eingefügt werden, den gleichen
Zeitstempel bekommen. Insbesondere entsprechen die Transaktionszeiten der
g von DB-Transaktionen. Da Transaktionszeiten nicht in der Zukunft
Serialisierung
liegen und die Vergangenheit in (temporalen) DB nicht geändert werden kann, kann
auch die Transaktionszeit von Aussagen nicht geändert werden.
– Benutzerdefinierte Zeit
Während Transaktionszeit und Gültigkeitszeitraum einer Aussage in der
Abfragesprache einer temporalen DB unterstützt werden, kann natürlich weiterhin
der Benutzer Attribute mit zeitlicher Domäne (s.o. DATE in ORACLE-SQL)
definieren.
– Gültigkeitsrelation
Eine Relation mit einem vom System verwalteten Gültigkeitszeitraum für alle
gespeicherten Tupel. Wird oft auch als Historienrelation bezeichnet. Der
tupelspezifische Gültigkeitszeitraum wird dabei von der Anwendung definiert.
16. Prof. Jasper: Datenbanksysteme
21
Die temporale Datenbank (Forts.)
– Transaktionszeitrelation
Eine Relation mit einer vom System verwalteten Transaktionszeit für alle Tupel. Der
jeweilige Eintrag der Transaktionszeit wird vom System vorgenommen.
– Bitemporalrelation
Relation, die gleichzeitig Gültigkeitsrelation und Transaktionszeitrelation ist.
– Schnappschuss-Relation
Übliche DB-Relation (d.h. ohne temporale Unterstützung durch das System).
•
Zeit-Operatoren
p
– Für Transaktionszeit und Gültigkeitszeitraum gibt es jeweils einen -Operator. Der
t-Operator liefert für eine Relation und einen Zeitpunkt alle bis zu dem Zeitpunkt
bekannten Einträge in der Relation, der
• g-Operator
g Operator liefert für eine Relation und einen Zeitpunkt alle zu dem Zeitpunkt gültigen
Einträge in der Relation.
•
•
Zeitliche
e t c e homogene
o oge e Relation
e at o / DB
– Eine Relation / DB ist zeitlich homogen, wenn alle Tupel in der Relation / DB den
gleichen Gültigkeitszeitraum haben.
16. Prof. Jasper: Datenbanksysteme
22