Vorlesung Datenbanken I 3. Datenbank-Modellierung - Technologie ...
Vorlesung Datenbanken I 3. Datenbank-Modellierung - Technologie ...
Vorlesung Datenbanken I 3. Datenbank-Modellierung - Technologie ...
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Prof. Dr. rer.nat.habil. Bernhard Thalheim<br />
Information Systems Engineering<br />
Institute of Computer Science and Applied Mathematics<br />
Christian-Albrechts-University Kiel<br />
Olshausenstr. 40<br />
D - 24098 Kiel<br />
<br />
<strong>Vorlesung</strong> <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong><br />
SS 2007<br />
3 <strong>Datenbank</strong>-<strong>Modellierung</strong> (Spezifikation von <strong><strong>Datenbank</strong>en</strong>)<br />
<strong>3.</strong>1 Das Entity-Relationship-Modell<br />
Viele OOA-Modelle sind falsch, weil sie zu komplex sind. Einfachheit, Kürze, Klarheit!<br />
Paradigmen<br />
formale Sprache \ Theorie Abstraktion Entwurf<br />
erfinden<br />
•<br />
verwirklichen<br />
•<br />
benutzen • •<br />
Es sind verschiedene Modelle möglich. Jedes Modell ist durch eine Menge von inhärenten Bedingungen<br />
gekennzeichnet.<br />
Begriffsgerüst ist nicht eindeutig verwendbar. Modelle dienen zur Kommunikation.<br />
Jeder benutzte Typ hat neben<br />
Konstruktor, Selektoren (für Retrieval) und Updatefunktionen, Korrektheitskriterien, default-<br />
Regeln auch<br />
eine Benutzerrepräsentation und eine physische Repräsentation.<br />
Günstig ist eine graphische Repräsentation.<br />
Unterstützung durch Werkzeuge<br />
Graphiken können auch durch Anschauung fehlleiten.<br />
Gesichtspunkte betont, einige in den Hintergrund<br />
<strong>3.</strong>1.1 Das erweiterte Entity-Relationship-Modell (informal)<br />
1. Seiendenklasse: Entity-Typ (Rechteck)<br />
2. Beziehungsklasse: Relationship-Typ (Raute)<br />
<strong>3.</strong> Attribut Komplexe Attribute<br />
4. Rolle als unärer Relationship-Typ (gekennzeichnet über Marke zur Auszeichnung der Rolle)<br />
5. Aggregation über verschiedene Konstruktoren:<br />
• Vereinigung<br />
E ... E’ new<br />
• Aggregation durch Beziehungsklasse, aufgefaßt als Seiendenklasse<br />
∧<br />
E ←− ∨ −→ E’ new<br />
• Verallgemeinerung als Gruppenbildung (Clusterbildung) (über eine IsA-Beziehung mit
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 2<br />
• Spezialisierung als Partition mit Spezialisierungsbedingung (Partitionsbedingung) (Jedes<br />
Seiende aus E muß auch in (genau) einem E i sein) (genau eins: uniqueness constraint in<br />
NIAM) (E i -Aussonderung, E - Verallgemeinerung)<br />
E ⊆ E 1 ∪ ... ∪ E n<br />
• Abstraktion durch Unitbildung (Klassenbildung)<br />
6. Schlüsseldarstellung für einen Schlüssel<br />
7. Integritätsbedingungen<br />
8. Regeln<br />
• Viele-Eins-Bedingung (Jedes Seiende aus E steht mit höchstens einem Seiendem aus E ′<br />
in Beziehung) ∧<br />
E ←−<br />
(.,1) ∨ −→ E’<br />
Zeichnung !! (Raum-<strong>Vorlesung</strong>)<br />
• Seinsbedingung (Existenzbeziehung) (jedes Seiende aus E steht mit mindestens einem<br />
Seiendem∧<br />
aus E ′ in Beziehung)<br />
E ←−<br />
(1,.) ∨ −→ E’<br />
Zeichnung !! (Raum-<strong>Vorlesung</strong>)<br />
• Verweisbedingung (Jedes Seiende aus E, das in einer Beziehung aus B vorkommt, ist<br />
auch Seiendes aus E ′′ )<br />
E”<br />
∧<br />
↑<br />
IsA<br />
∨<br />
E<br />
↓<br />
←−<br />
B∧<br />
∨ −→ E’<br />
φ(t 1 , ..., t n ) steht für oder<br />
• Gesamtheitsregel in Zusammenhang mit einer Querysprache<br />
• Verneinungsregel - negation as failure oder closed-world-assumption<br />
• Sichtregel als Ableitungsregel<br />
definiert z.B. über logische Formeln oder and-or-Graphen<br />
✲<br />
✯<br />
als<br />
Empfänger<br />
gedeutete<br />
Stellen<br />
9. Formale Handlungen als dargestellt über Petri-Netze<br />
eingehende<br />
Sender<br />
als Erstellung<br />
gedeutete<br />
und Übertragung von<br />
Mitteilungen<br />
Stellen:<br />
Mitteilung<br />
Mitteilungen<br />
ermittelt<br />
gedeutete Transition<br />
Information<br />
Auslösung<br />
von<br />
anschließenden<br />
Handlungen<br />
✲<br />
... and<br />
❥<br />
✯<br />
Transition<br />
...
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 3<br />
• Information<br />
• Mitteilung<br />
• Verstehen<br />
Warum Relationship-Typen über Relationship-Typen:<br />
Universitätsbeispiel:<br />
1. Entity-Typ Person<br />
2. Aussonderungsbeziehung Student, Professor IsA Person<br />
<strong>3.</strong> Beziehungen Betreuer<br />
4. Partitionsbedingung Projektmitarbeiter<br />
5. Kardinalitätsbedingungen<br />
6. Darstellung von dynamischen Bedingungen und Handlungen<br />
7. Sichten über dem Schema mit Darstellung der abgeleiteten Attribut-, Entity- und Relationship-<br />
Typen<br />
Darauf aufbauend kann man auch weitere Bedingungen definieren.<br />
sowie weitere abgeleitete Typen: z.B. vorausgesetzte Fächer (falls Vorauss nur die direkte Beziehung<br />
darstellt)<br />
Spezielle Modellbedingungen des ER-Modells<br />
1. Entity-Typ mit mindestens einem Attribut (Komponente)<br />
2. Jedes Attribut mindestens einmal verwendet<br />
<strong>3.</strong> Attribut-Typen sind entweder Basisattribut-Typen oder aufgebaut über Attribut-Typen<br />
4. Basis-Attribut-Typen haben einen Datentyp<br />
5. Schlüssel gehören nur zu den Attributen des (Entity-)Typen<br />
6. Jeder Relationship-Typ hat mindestens eine Komponente (Entity-Typ, Attribut-Typ oder Relationship-<br />
Typ)<br />
7. Typstruktur ist streng hierarchisch<br />
8. Schlüssel gehört zu Entity-Typen (mindestens einer)<br />
9. Schlüssel hat mindestens eine Komponente<br />
10. Komponenten eines Schlüssels eines Typen sind Komponenten des Typs<br />
11. Mengenbasierte Definition<br />
möglich ist auch eine pointerbasierte Definition von Relationship-Typen oder auch von Entity-<br />
Typen<br />
12. Spezielle Behandlung rekursiver Typen<br />
Damit sind ausgeschlossen:<br />
1. Schwache Entity-Typen<br />
2. Nicht-hierarchische Typen
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 4<br />
Name(First,Fam,{Title})<br />
Person<br />
Adr(Zip,Town,Street(Name,Nr))<br />
❃<br />
❑<br />
■<br />
Person’s number<br />
Supervisor<br />
Since<br />
StudNr<br />
✙<br />
Student<br />
❖<br />
✠<br />
■<br />
Major<br />
Minor<br />
Department<br />
✸<br />
Phones{Phone}<br />
Director<br />
✛<br />
DName<br />
In<br />
✲<br />
❃<br />
❥<br />
Professor<br />
✻<br />
Primary<br />
Investigator<br />
Speciality<br />
Member<br />
Result<br />
Time(Day,Hour)<br />
Enroll ✲ Lecture Has<br />
⊕<br />
✾<br />
✰<br />
❄<br />
Semester<br />
Year Season<br />
Nr<br />
Room<br />
Building<br />
✻<br />
Course<br />
✻<br />
CNu<br />
CName<br />
❄<br />
Project<br />
Prerequis<br />
Begin<br />
Num<br />
End<br />
PName<br />
Abbildung 1: HERM-Diagram of the University Database
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 5<br />
Student<br />
✻<br />
✶<br />
✯<br />
Professor<br />
Belegt<br />
<strong>Vorlesung</strong><br />
IC<br />
☛<br />
✾<br />
✰<br />
<br />
Voraussetzung<br />
Semester<br />
Raum<br />
Kurs<br />
✛<br />
‘Belegt’ als selbständige Beziehung<br />
Belegt[Professor,Kurs,Semester] ⊆ <strong>Vorlesung</strong>[Professor,Kurs,Semester]<br />
❄<br />
✛<br />
Student<br />
✻<br />
✯<br />
Professor<br />
Belegt<br />
✲<br />
<strong>Vorlesung</strong><br />
✾<br />
Semester<br />
✰<br />
❄<br />
Raum<br />
Kurs<br />
‘Belegt’ als Beziehung über ‘<strong>Vorlesung</strong>’<br />
✛<br />
✛<br />
Voraussetzung<br />
<strong>3.</strong>1.2 Das erweiterte ER-Modell (formal)<br />
Basis-Datentypen BT mit Elementen DT (D) = (domain(D), Ops(D), P red(D)<br />
Datenschema DD = (U, D, dom)<br />
endliche Menge U von atomaren Attributen,<br />
Mengen von Werten D := ∪ A∈U domain(dom(A)),<br />
und Assoziationsschema zum Namensraum dom : U → BT<br />
Genestetes (geschachteltes) (komplexes) Attribut<br />
neue Namensmenge NA und Menge von Konstruktoren<br />
1. λ ∈ UN<br />
2. U ⊆ UN<br />
<strong>3.</strong> Falls X ∈ UN dann l : X ∈ UN für l ∈ L<br />
4. Für verschiedene X 1 , ..., X n ∈ UN und X ∈ NA ist X(X 1 , ..., X n ) ein (Tupel-)Attribut UN<br />
5. Falls X ′ ∈ UN und X ∈ NA dann X{X ′ } ist ein (Mengen-)Attribut UN<br />
6. Keine weiteren Elemente in UN<br />
weitere Konstruktoren: Multimenge, Liste, ...
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 6<br />
<strong>3.</strong> Für l : X ∈ UN : Dom(l : X) = Dom(X).<br />
4. Für X(X 1 , ..., X n ) ∈ UN : Dom(X) = Dom(X 1 ) × ... × Dom(X n ) .<br />
5. Für X{X ′ } ∈ UN : Dom(X{X ′ }) = P ow(Dom(X)) .<br />
Beispiele von komplexeren Attributen sind<br />
Name (Vornamen,<br />
Familienname :: varstring30, [Geburtsname :: varstring30,]<br />
[Titel:{AkademischeTitel :: varstring10 } ∪ ·<br />
FamilienTitel :: varstring10])<br />
Kontakt (Tel({dienstl :: varnumbersequence20 }, privat :: varnumbersequence20),<br />
email :: emailType, ...)<br />
Geburtsdatum :: date .<br />
Name<br />
❄<br />
( ... )<br />
Attribute können in einer verkürzten Notation verwendet werden, wenn dies eindeutig im Schema<br />
bleibt. Das Attribut Kontakt ist z.B. dann auch ohne seine Bestandteile verwendbar.<br />
Attribute sind hierarchisch strukturiert wie - im Falle des Namens einer Person - der Baum in Bild<br />
?? zeigt. Diese hierarchische Struktur ermöglicht auch Elemente auszuzeichnen, z.B. mit der Eigen-<br />
✾<br />
Vornamen<br />
❄<br />
< ... ><br />
❄<br />
( ... )<br />
✮<br />
<br />
Vorname Benutzung<br />
❄<br />
string1<br />
❄<br />
varstring15<br />
✠<br />
Familienname<br />
❄<br />
varstring30<br />
3<br />
[ ... ]<br />
❄<br />
Geburtsname<br />
❄<br />
varstring30<br />
✾<br />
{ ... }<br />
❄<br />
AkademischeTitel<br />
❄<br />
varstring10<br />
3 [ ... ]<br />
❄<br />
Titel<br />
❄·<br />
∪<br />
3<br />
Familientitel<br />
❄<br />
varstring10<br />
Abbildung 2: Semi-strukturiertes Attribut Name<br />
schaft Element eines Schlüssels zu sein. So kann z.B. zum Schlüssel das Teilattribut<br />
Name (Vornamen, Familienname, [Geburtsname ])<br />
hinzugenommen werden, wobei wir als Abkürzungsregel benutzen, daß mit dem Nennen eines Bezeichners<br />
auch der damit verbundene Teilbaum mit übernommen wird, z.B. für Vornamen auch die<br />
gesamte Teilstruktur Vornamen .<br />
Tupel über X ⊆ UN und DD = (U, D, dom) ist eine Funktion<br />
t : X −→ D DD mit t(A) ∈ Dom(A) für A ∈ X<br />
Menge aller Tupel über X für DD: DDD<br />
X<br />
Schlüsselkonzept analog zur Definition der Attribute<br />
Entitytyp E ist ein Paar (attr(E), id(E))<br />
E ist Entitytyp-Name,<br />
attr(E) ist Attributmenge und<br />
id(E) ist nichtleere verallgemeinerte Teilmenge von attr(E) (Schlüssel oder Identifikator).<br />
Entityklasse - Menge E C von Tupeln über attr(E) mit der Schlüsseleigenschaft<br />
für verschiedene Tupel τ, τ ′ from E C gilt τ id(E) ≠ τ ′ id(E)<br />
Ein Entity-Typ besteht aus einer nichtleeren Folge von Attributen und einer Menge von statischen
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 7<br />
wird. Zum Beispiel ist ein Person-Typ spezifiziert durch<br />
Person = (Name, Adresse, Kontakt, GebDatum, PersNr : StudNr ∪ ·<br />
MitarNr, ..., ∅)<br />
mit einer Folge von Attributen. Markierungen sind als solche ausgewiesen.<br />
Ein Entity-Typ wird durch ein Rechteck graphisch repräsentiert.<br />
Eine Entity-Klasse besteht aus einer Menge von Objekten vom Entity-Typ, die die statischen<br />
Integritätsbedingungen des Entity-Typen erfüllt.<br />
Zum Beispiel ist das folgende Objekt mit dem Identifikator β<br />
β: ((, Thalheim, {Prof., Dr.rer.nat.habil., Dipl.-Math.}),<br />
BTU Cottbus, (({ +49 431 880 4472, +49 431 8894072}, +49 431 824054),<br />
thalheim@informatik.tu-cottbus.de), 10.<strong>3.</strong>52, 637861)<br />
vom Entity-Typ Person, wobei mit ‘z’ der Zusatzname und mit ‘r’ der Rufname bezeichnet wird.<br />
Für Typen {R 1 , ..., R k } : “ Kategorie ” oder Cluster C = R 1 + R 2 + ... + R k<br />
eventuell (insbesondere für Identifizierung) mit Marken<br />
Eine disjunkte Vereinigung von bereits konstruierten Typen wird als Cluster-Typ bezeichnet. Ein<br />
Cluster-Typ wird mit einem ⊕ -Zeichen graphisch repräsentiert.<br />
Beispiele sind durch folgende Typen gegeben:<br />
JuristischePerson = Person ∪ ·<br />
Betrieb ∪ ·<br />
Vereinigung<br />
Gruppe = Senat ∪ ·<br />
Arbeitsgruppe ∪ ·<br />
Vereinigung,<br />
die den Typ JuristischePerson bzw. Gruppe als disjunkte Vereinigung von anderen Typen einführen.<br />
Cluster-Typen können weitere Attribute besitzen. In diesem Fall wird der Cluster-Typ durch eine<br />
Raute mit den Attributen repräsentiert.<br />
Objekte von Cluster-Typen sind analog zu den Objekten anderer Typen durch entsprechende Zuordnung<br />
zu den Element-Typen eingeführt. So können z.B. die Objekte β, LIM, CottbusNet e.V.<br />
juristische Personen sein.<br />
Entity-Typen = Relationship-Typen 0. Ordnung<br />
R 1 , .., R l - Relationship-Typen der Ordnung < i<br />
Relationship-Typ i. Ordnung :<br />
R = (compon(R), attr(R))<br />
Element der Menge R C R = (R 1 , ..., R n , {B 1 , ..., B k }) für Zeitpunkt t und die Mengen R t 1 , ..., Rt n<br />
definiert als Element von<br />
R t 1 × ... × Rt n × Dom(B 1 ) × ... × Dom(B k )<br />
Ein Relationship-Typ (erster Ordnung) besteht aus einer nicht-leeren Folge von Entity-Typen, einer<br />
Menge von Attributen und einer Menge von statischen Integritätsbedingungen. Eine Menge von<br />
der Struktur des Relationship-Typen ist eine gültige Menge, wenn sie den statischen Integritätsbedingungen<br />
genügt. Elemente können markiert sein.<br />
Ein Beispiel sind die Relationship-Typen<br />
InGruppe = (Person, Gruppe, { Zeit(Von [,Bis]), Funktion }, ∅ )<br />
DirektVoraussetz = (setztVoraus: Kurs, vorausges : Kurs, ∅, ∅ )<br />
Professor = (Person, { Berufungsgebiet }, ∅ ) .<br />
Ein Relationship-Typ wird mit einer Raute graphisch repräsentiert. Wir erlauben auch optionale<br />
Komponenten von Relationship-Typen, solange eine Identifikation über die obligatorischen Elemente<br />
definiert ist.<br />
Ein Objekt eines Relationship-Typs ist ein Tupel, das zu den jeweiligen Elementen auf die entsprechenden<br />
Objekte der Klasse der Elemente durch Angabe von identifizierenden Werten (Identifikator<br />
bzw. Primärschlüssel bzw. anderer Schlüssel) verweist und Werte für die Attribute des Relationship-<br />
Typs besitzt.<br />
Eine Relationship-Klasse besteht aus Objekten des Relationship-Typs, die den statischen Integritätsbedingungen<br />
genügen.
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 8<br />
Senator5β: ( 637861, Senat, (2000), Vorsitzender)<br />
VorausDBIVHaupt: (DBIV, DBI) .<br />
Achtung: Man kann auch mit anderen Einschränkungen für das Modell kann man z.B. Pointersemantik<br />
benutzen. Weiterhin könner verschiedene Einschränkungen fallengelassen werden:<br />
• abgeleitete Attribute<br />
• leere Attributmengen für Entitytypen; Identifizierung über Relationshiptypen<br />
• nicht-hierarchische Struktur<br />
Ein Relationship-Typ i-ter Ordnung besteht aus einer nicht-leeren Folge von Entity- und Relationship-<br />
Typen einer Ordnung von maximal (i-1), wobei ein Typ (i-1)-ter Ordnung sein muß, einer Menge von<br />
Attributen und einer Menge von statischen Integritätsbedingungen. Eine Menge von der Struktur des<br />
Relationship-Typen ist eine gültige Menge, wenn sie den statischen Integritätsbedingungen genügt.<br />
Eine Identifikation kann sowohl aus den Elementen bestehen als auch aus den Attributen.<br />
IsA-Typen:<br />
hier wurde partielle, nicht disjunkte Darstellung über Teiltypen bevorzugt, denkbar sind jedoch verschiedene<br />
Typen:<br />
1. partiell, nicht disjunkt;<br />
dieser Fall wird als der typische Fall angenommen (keine weiteren semantischen Informationen)<br />
Im HERM darstellbar über unäre Teiltypen.<br />
Person ⊇ Professor ∪ Mitarbeiter ∪ Student<br />
E ⊇ E 1 ∪ ... ∪ E n<br />
2. partiell, disjunkt<br />
die Teiltypen erfüllen eine Exklusionsbeschränkung<br />
Person ⊇ Professor ∪ Student<br />
E = E 1 ∪ ... ∪ E n<br />
<strong>3.</strong> total, nicht disjunkt<br />
E = E 1 ∪ ... ∪ E n<br />
Projektmitarbeiter = Professor ∪ Mitarbeiter ∪ Student<br />
4. total, disjunkt<br />
E = E 1 ∪ ... ∪ E n<br />
Studenten = StudImVordiplom ∪ StudImHauptstudium ∪ Diplomand<br />
Weiterhin kann auch für die Spezialisierung mit Partitionsbedingung eine analoge Strukturierung<br />
betrachtet werden (wird auch in den meisten Büchern ‘vergessen’):<br />
1. partiell, nicht disjunkt<br />
E ⊆ E 1 ∪ ... ∪ E n<br />
Teilnehmer ⊆ Vortragender ∪ Organisator ∪ NormalerTeilnehmer<br />
2. partiell, disjunkt<br />
E ⊆ E 1 ∪ ... ∪ E n<br />
Literatur ⊆ Buch ∪ Preprint ∪ Zeitschrift<br />
<strong>3.</strong> total siehe oben Generalisierung = Spezialisierung<br />
E = E 1 ∪ ... ∪ E n<br />
Gewöhnlich wird in der Literatur nur versimplifizierend die IsA-Beziehung als strukturelle Beziehung<br />
betrachtet. Richtig ist aber die IsA-Beziehung im vollen Typeninhalt zu betrachten:<br />
Typ = Struktur + Operationen + Semantik<br />
In diesem Fall wird die Richtung der Vererbung bekanntgegeben.<br />
Damit dann besser modellierbar:
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 9<br />
• Operationen des Teiltyps sind operationale Spezialisierung der Operationen des Supertyps (wenn<br />
im supertyp definiert)<br />
• Semantik des Teiltyps (eingeschränkt auf im Supertyp darstellbares) folgt aus Semantik des<br />
Supertyps<br />
<strong>3.</strong>1.3 Generalisierung versus Spezialisierung<br />
Ein Cluster-Typ erlaubt die explizite Darstellung einer Generalisierung. Ein unärer Relationship-Typ<br />
stellt dagegen eine Spezialisierung dar, wenn der Relationship-Typ bzw. Entity-Typ als sein Element<br />
diesen identifiziert. Rollen werden oft durch einen generischen Typ mit der Bezeichnung IsA dargestellt.<br />
Da die relationalen Schemata auch ohne diesen Typ auskommen, bevorzugen wir die Darstellung<br />
als Rolle mit unären Relationship-Typen oder ggf. auch mehrstelligen Relationship-Typen,<br />
falls die Rolle durch eine Beziehung zu anderen Typen ausgezeichnet ist. Damit sind wir in der Lage,<br />
zwischen Generalisierung und Spezialisierung zu unterscheiden.<br />
<strong>3.</strong>1.4 ER-Schemata<br />
Wie im relationalen Modell betrachten wir<br />
Entity-, Relationship- und Cluster-Typen, die mit der obigen Notation eingeführt werden<br />
Schemata S, deren Typen vollständig zurückführbar aus Basis-Datentypen sind, d.h. jeder Typ ist<br />
entweder ein Basis-Datentyp oder ein Typ, der durch Anwendung der Konstruktoren aus Typen<br />
des Schemas entsteht<br />
Integritätbedingungen, die wir im nächsten Teilkapitel einführen<br />
Ein <strong>Datenbank</strong>-Schema ER besteht aus einer Menge von Typen {T i = (U Ti , Σ Ti )} und<br />
globalen statischen Integritätsbedingungen Σ ER .<br />
Ein etwas komplexeres Beispiel ist das Beispiel in Bild ??. Eine Lehrveranstaltung, z.B. eine<br />
<strong>Vorlesung</strong>, wird durch einen Lehrstuhl angeboten. Dieses Angebot kann angenommen werden. Dann<br />
wird die Lehrveranstaltung geplant. Wird sie auch gehalten, dann werden die aktuellen Daten in der<br />
Klasse zum Typ GehalteneLehrveranst gespeichert. Der Typus und die Raumzuordnung können sich<br />
vom Vorschlag zum Plan und für den Raum vom Plan zu den gehaltenen Lehrveranstaltungen ändern.<br />
Ein Vorschlag für eine Lehrveranstaltung wird durch Berechtigte eingetragen. Eine Person ist für die<br />
Lehrveranstaltung verantwortlich. Eine Lehrveranstaltung kann für mehrere Studiengänge angeboten<br />
werden.<br />
Kurs Semester Professor ✲<br />
✯<br />
❦<br />
✻<br />
✒<br />
Dozent<br />
Person<br />
✶<br />
eingetragen<br />
Verantwortlicher4LV<br />
Studiengang<br />
{}<br />
✛ angebotene Wunsch<br />
<strong>Vorlesung</strong><br />
Zeit(Vorschlag,<br />
Vorschlag ✻ Nebenbeding)<br />
✲<br />
✯<br />
✻<br />
Raum<br />
Typus<br />
✰<br />
✛<br />
geplante ✛<br />
Lehrveranst<br />
Zeitrahmen<br />
gehaltene<br />
Lehrveranst<br />
Abbildung 3: HERM Diagramm zu unserem Hauptbeispiel
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 10<br />
der Objekte seiner Komponenten. So können z.B. Objekte vom Typ geplanteLehrveranstaltung in Bild<br />
?? auch nur auf Objekte verweisen, die Kurs, Semester, Professor bezeichnen, wenn wir voraussetzen,<br />
daß ein Schlüssel des Typs angebotene<strong>Vorlesung</strong> aus Kurs, Semester, Professor besteht.<br />
Ein Objekt vom Typ<br />
angebotene<strong>Vorlesung</strong> = (Kurs, Semester, Studiengänge,<br />
Professor, eingetragen, Verantwortlicher4LV, Raumwunsch, Typus, { Zeit }, ∅) ist z.B.<br />
<strong>Vorlesung</strong>DBIVSS02: (DBIV, SS2002, { Informatik, IMT },<br />
637861, KK, 637861, SR1, <strong>Vorlesung</strong>/Übung/Praktikum 2+2+2, Mo. 1.DS) .<br />
Rollen, die exklusiv bzw. hierarchisch sind, lassen sich auch anstelle einer HERM-Rautenstruktur<br />
durch hierarchische Strukturen abbilden, wie in Bild ?? dargestellt. Welche Darstellungsform gewählt<br />
wird, hängt vom erforderlichen Detaillierungsgrad ab. Sollen Attribute mit dargestellt werden, wird<br />
das hierarchische ER-Modell sehr schnell zu unübersichtlich. In den ersten Abstraktionsschichten<br />
stellt es aber eine gute Alternative zum HERM-Diagramm zum.<br />
Person<br />
Student<br />
Diplomand<br />
Diplomand<br />
✲<br />
Student<br />
✲<br />
Person<br />
Universitätsmitarbeiter<br />
Professor<br />
Projektmitarbeiter<br />
Projektmitarbeiter<br />
✻<br />
✲Universitäts-✛<br />
mitarbeiter<br />
Professor<br />
Abbildung 4: Hierarchisches ER-Diagramm versus HERM Diagramm<br />
<strong>3.</strong>1.5 Aggregation<br />
Wir können die Konstruktion von Relationship-Typen zu einer allgemeinen Aggregationskonstruktion<br />
erweitern, indem wir weitere Konstruktoren zulassen:<br />
• Vereinigung,<br />
• Mengenbildung,<br />
• Aggregation durch Beziehungsklasse und<br />
• Abstraktion durch Komponentenbildung.<br />
Klassen werden mit der hochgestellten Annotation ‘C’ und dem Typnamen bezeichnet. Z.B. sind<br />
Person C und InGruppe C Klassen entsprechenden Typs.<br />
<strong>3.</strong>1.6 Klassenseparierte Schemata versus objektentfaltete Schemata<br />
Wir merken an, daß wir über zwei unterschiedliche Methoden zur Darstellung, Repräsentation, Verarbeitung<br />
und Speicherung von Objekten verfügen:<br />
Klassen-Separation: Die Menge aller Objekte wird durch ein ER-Schema dargestellt. Jedes Objekt<br />
wird genau einer Klasse zugeordnet und in beliebig vielen anderen Klassen auf der Grundlage<br />
des ER-Schemas verwendet. Die Verwendung kann über einen Surrogat-Schlüssel, eine Markierung<br />
oder Werte zum ausgewählten Schlüssel des Objektes erfolgen.<br />
Wir nennen diese Form der Behandlung von Objektmengen klassen-separierte Darstellung.<br />
Ein Objekt ist dann mit dem erweiterten ER-Modell als Schneeflocke mit einer Wurzel darstellbar.
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 11<br />
ergeben. Ein Teilgraph besitzt evt. ein Wurzel-Objekt, d.h. es gibt ein Objekt, das rekursiv auf<br />
alle anderen Objekte des Teilgraphen verweist. Besitzt jeder dieser Teilgraphen ein Wurzelobjekt,<br />
dann heißt U Objekt-Gesellschaft.<br />
Damit ist in Objekt-Gesellschaften jedes Objekt ein volles Objekt mit allen Eigenschaften.<br />
Ein Beispiel für eine Objekt-Entfaltung zum Schema in Bild ?? ist folgendes XML-Dokument:<br />
<br />
<br />
<br />
Montag<br />
Mittwoch<br />
<br />
<br />
Normalvorlesung 2+2+2
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 12<br />
<strong>3.</strong>2 Integritätsbedingungen<br />
<strong>3.</strong>2.1 Statische Integritätsbedingugngen<br />
Die Semantikspezifikationssprache umfaßt Schlüssel und Integritätsbedingungen, wie funktionale Abhängigkeiten,<br />
Exklusions- und Inklusionsabhängigkeiten, mehrwertige Abhängigkeiten, Viele-Eins-Bedingungen,<br />
Seinsbedingungen (Existenzbeziehung), Verweisbedingungen, Teiltypenbedingungen und Regeln, wie<br />
z.B. die Gesamtheitsregel, die Verneinungsregel und die Sichtregeln, sowie vor allem Komplexitätsbedingungen<br />
(Kardinalitätbedingungen) zur Spezifikation der Beziehung zwischen einem Relationship-<br />
Typen und seinen Komponenten.<br />
Statische Integritätsbedingungen werden als Formeln der hierarchischen Prädikatenlogik allgemein<br />
dargestellt. Wir verwenden jedoch die üblichen Kurzdarstellungen.<br />
Wir gehen davon aus, daß statische Integritätsbedingungen einer Interpretation mit einer “Normallogik”<br />
unterliegen. Mitunter wird auch im Entwurf eine Integritätsbedingung mit einer schwachen,<br />
deontischen Interpretation benutzt, bei der ihre Gültigkeit für die meisten Objekte einer <strong>Datenbank</strong><br />
oder einer Klasse gefordert wird. Mitunter wird auch eine strikte Form der Interpretation genutzt, bei<br />
der z.B. obere bzw. untere Schranken für Kardinalitätsbeschränkungen auch durch entsprechende Objektmengen<br />
genau erfüllt sein müssen.<br />
Arten von Abhängigkeiten des Er-Modelles<br />
• Trennung von Gesichtspunkten<br />
Separation von Aspekten<br />
mehrwertige Abhängigkeiten, hierarchische Abhängigkeiten, Verbundabhängigkeiten<br />
• Trennung von Spezialisierungen<br />
Exklusionsabhängigkeiten, Zerlegungsabhängigkeiten, Vereinigungsabhängigkeiten<br />
• Darstellung des Datenzusammenhangs<br />
Inklusionsabhängigkeiten (Elementarfakten bedingen einander)<br />
Existenzabhängigkeiten<br />
Wertebereichsbeschränkungen<br />
tupelgenerierende Abhängigkeiten (auffaltende Zusammenhänge)<br />
gleichungsgenerierende Abhängigkeiten (Zusammenfließen von Daten)<br />
• Numerische Einschränkungen<br />
Kardinalitätsbeschränkungen, absolute und relative Kombinatorik<br />
Die unterschiedlichen Abhängigkeiten sind relevant auf unterschiedlichen Abstraktionsniveaus.<br />
Partielle Identifikatiohängigkeihängigkeihängigkeit<br />
relative Unab-<br />
Existenzab-<br />
Redundanzab-<br />
Konzeptionelle<br />
Ebene<br />
funktionale,<br />
gleichungsgenerierende<br />
mehrwertige,<br />
hierarchische,<br />
Verbundabhängigkeit,<br />
null-werte-frei,<br />
Vereingungsabhängigkeit,<br />
numerische,<br />
Inklusionsabhängigkeit,<br />
Exklusionsabhängigkeit<br />
Exklusionsabhängigkeit,<br />
tupelgenerierende,<br />
horizontale<br />
Dekomposition<br />
Kardinalitätsabhängigkeit<br />
Implementationsebenqueness,<br />
Schlüssel, uni-<br />
Dekomposition, no null, stored referentielle Inte-<br />
trigger, stored procedu-<br />
procedures, grität, Surrogate,<br />
check<br />
res, trigger trigger<br />
Kapseln<br />
Benutzersicht Identifikation Struktur ! no null elementare Fakten<br />
Wir verwenden im weiteren folgende Klassen von Integritätsbedingungen:
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 13<br />
Typ mehr als einen Schlüssel. Deshalb verwenden wir von vornherein Schlüsselmengen. Der<br />
Primärschlüssel eines Entity-Typs wird direkt angegeben und kann in der Schlüsselmenge weggelassen<br />
werden.<br />
Wir nehmen z.B. für das Diagramm in Bild ?? folgende Schlüssel an:<br />
Key(Person) = { { PersNr }, { Name, Geburtsdatum } }<br />
Relationship-Typen haben ggf. auch eigene Attribute, die auch Bestandteile eines Schlüssels<br />
sind.<br />
Zum Beispiel nehmen wir für das obige Beispiel an, daß die Zeit essentiell für InGruppe ist,<br />
d.h.<br />
Key(InGruppe) = {{ Person, Gruppe, Zeit }} oder<br />
Key’(InGruppe) = {{ Person, Gruppe, Zeit, Funktion }}<br />
Weiterhin kann z.B. gelten<br />
Key(<strong>Vorlesung</strong>) = { {Kurs, Semester}, {Semester, Raum, Zeit}, {Semester, Dozent, Zeit} }<br />
Schlüssel folgen der Komponentenkonstruktion und können auch für einen Teil gelten, z.B.<br />
Name(Vornamen, FamName).<br />
Mindestens ein Schlüssel wird über die Komponente an den Relationship-Typen ‘vererbt’.<br />
Funktionale Abhängigkeiten sind eine wichtige Gruppe von Abhängigkeiten. Eine funktionale Abhängigkeit<br />
R : X → Y ist für einen Typ R und Teilmengen X, Y seiner Elemente<br />
definiert. Sie gilt in einer Klasse R C , falls die Gleichheit von Objekten o, o ′ aus R C über X die<br />
Gleichheit über Y für o, o ′ impliziert.<br />
Funktionale Beziehungen von Attributgruppen in unserem Beispiel sind<br />
geplanteLV : {Semester, Zeitrahmen, Raum} → {{Studiengang}, Professor, Kurs}<br />
geplanteLV : {Professor, Semester, Zeitrahmen} → {Kurs, Raum}<br />
angeboteneLV: {Semester, Kurs} → {Professor} .<br />
Kardinalitätsbeschränkungen werden als kombinatorische Beschränkungen in der (min,max)-Notation<br />
und der Partizipations-Semantik als Paar von Kardinalitäten verwendet. Damit unterscheidet<br />
sich unsere Notation von der Lookup-Semantik, die z.B. UML verwendet. Die letztere<br />
kann jedoch in einer n..m-Notation ebenso mitgeführt werden. Wir betrachten hierzu ein vereinfachtes<br />
Diagramm in Bild ??.<br />
(gehaltene) ✛<br />
<strong>Vorlesung</strong> (1,n)<br />
setztVoraus ✻<br />
(0,2)<br />
✻vorausgesetzt<br />
(3,4)<br />
<strong>3.</strong>.4 0..2<br />
Voraussetzung<br />
0..2<br />
legtab ✲<br />
(0,n)<br />
Resultat<br />
(0,n)<br />
❄<br />
Student<br />
Ablageform<br />
Abbildung 5: Kardinalitätsbeschränkungen im <strong>Vorlesung</strong>sbeispiel<br />
Eine Kardinalitätsbeschränkung card(R, R i ) = (n, m) gilt in einer Klasse R C , falls<br />
jedes Objekt o i von Ri<br />
C in R C mindestens n-mal und höchstens m-mal vorkommt.<br />
Eine Kardinalitätsbeschränkung in der Lookup-Notation look(R, R i ) = (n, m) gilt in<br />
einer Klasse R C mit k Elementen, falls zu jeder Kombination von Objekten o j von Rj<br />
C (j ≠<br />
i, 1 ≤ j ≤ k) mindestens n und höchstens m entsprechende Objekte o i aus Ri C in der Klasse<br />
R C vorkommen.<br />
Im Fall binärer Relationship-Typen kann man damit einem Objekt o von R i mindestens n und<br />
höchstens m Objekte aus Rj<br />
C zuordnen, d.h. das Objekt sieht vermittels R C höchstens m und<br />
mindestens n Objekte aus der anderen Klasse.
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 14<br />
card(Voraussetzung, setztVoraus) = (0,2)<br />
look(Voraussetzung, setztVoraus) = <strong>3.</strong>.4<br />
card(Voraussetzung, vorausgesetzt) = (3,4)<br />
look(Voraussetzung, vorausgesetzt) = 0..2<br />
gilt. Damit haben wir äquivalente Formen.<br />
Für n-äre Relationship-Typen ohne eigene Attribute ist die Lookup-Notation look(R, R i ) =<br />
n..m äquivalent zur verallgemeinerten Kardinalitätsabhängigkeit card(R, R \ R i ) = (n, m) .<br />
In unserem Beispiel gilt z.B. die Einschränkung, daß erst dann ein Eintrag in die Klasse legtab<br />
geführt wird, wenn der Student eine <strong>Vorlesung</strong> erfolgreich abgelegt hat.<br />
Die Lookup-Bedingung look(legtab, Ablageform) = 0..2 stellt dar, daß nur Prüfung und<br />
Schein bzw. Schein und Praktikum bzw. Prüfung und Praktikum absolviert werden müssen.<br />
Diese Bedingung ist äquivalent zu<br />
card(legtab, Student <strong>Vorlesung</strong>) = (0,2).<br />
Eine Kardinalitätsbeschränkung card(R, R i ) = (0, 1) ist äquivalent zur funktionalen Abhängigkeit<br />
R : {R i } → R .<br />
Eine Lookup-Kardinalitätsbeschränkung look(R, R i ) = 0..1 ist äquivalent zur funktionalen<br />
Abhängigkeit R : R \ {R i } → R .<br />
Weiterhin können wir z.B. fordern, daß nur solche <strong>Vorlesung</strong>en als gehalten gelten, die auch<br />
zu studentischer Beteiligung geführt haben. Dies wird durch card(legtab, <strong>Vorlesung</strong>) = (1,n)<br />
dargestellt.<br />
Eine strengere Bedingung ist, daß dies auch für das Semester gelten muß. Dann können wir<br />
spezifizieren<br />
look(legtab, Student) = 1..n bzw. card(legtab, <strong>Vorlesung</strong> Semester) = (1,n).<br />
Für Relationship-Typen mit eigenen Attributen ist die Lookup-Notation in verschiedenen Formen<br />
definiert.<br />
(DBIV,SS2002,β)<br />
◦<br />
◦ ◦ ◦<br />
◦<br />
◦ Schein<br />
(DBI,WS2002,β)<br />
(Compiler,SS2002,PB)<br />
(Informatik III,WS2002,BvB)<br />
(Informatik III,WS2003,β)<br />
◦ ◦ ◦<br />
◦<br />
◦<br />
◦<br />
◦<br />
◦<br />
Prüfung<br />
◦ Praktikum<br />
Antje Bärbel Cornell Doris Emil Fjodor<br />
Abbildung 6: Beziehungen der Objekte im <strong>Vorlesung</strong>sbeispiel<br />
Wir betrachten in diesem Beispiel in Bild ?? eine kleine Klasse mit 14 Objekten. Z.B. hat Bärbel<br />
sowohl die (Informatik III,WS2002,BvB) als auch (DBIV,SS2002,β) mit Prüfung und Schein<br />
abgelegt, Emil dagegen nur Scheine in (Informatik III,WS2002,BvB) und (DBI,WS2002,β).<br />
Kardinalitätsbeschränkungen sind mitunter nicht erfüllbar in nicht-leeren, endlichen Klassen.<br />
Ein Beispiel einer solchen nicht-erfüllbaren Menge von Integritätsbedingungen ist das Paar<br />
card(Voraussetzung, setztVoraus) = (0,2)<br />
card(Voraussetzung, vorausgesetzt) = (3,4) .<br />
Dagegen ist<br />
card(Voraussetzung, setztVoraus) = (0,3)<br />
card(Voraussetzung, vorausgesetzt) = (3,4)<br />
erfüllbar und impliziert<br />
card(Voraussetzung, setztVoraus) = (3,3)<br />
card(Voraussetzung, vorausgesetzt) = (3,3) .
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 15<br />
Eine mehrwertige Abhängigkeit X → Y |Z wird für einen Typ R = (U R , Σ R ), mit<br />
Teilmengen X, Y ⊆ U R und Z = U R \(Y ∪X) definiert und gilt in einer Klasse Relation R C<br />
über R (dargestellt durch R C |= X → Y |Z ), falls für alle o, o ′ ∈ R C , die den gleichen<br />
Wert für die X-Elemente von R haben, ein Objekt o ′′ in R C existiert, das aus der Faltung von<br />
o und o ′ hervorgehen kann, d.h. formal<br />
für alle o, o ′ ∈ R C mit o = X o ′ existiert ein Objekt o ′′ ∈ R C mit o ′′ = X∪Y o und o ′′ = X∪Z o ′ .<br />
Eine nützliche, allgemein bekannte Eigenschaft von mehrwertigen Abhängigkeiten ist die Dekompositionseigenschaft.<br />
Es gilt R C |= X → Y |Z genau dann, wenn sich R C nach X ∪ Y und<br />
X ∪ Z vertikal dekomponieren läßt, d.h. formal R C = R C [X ∪ Y ] ✶ R C [X ∪ Z] .<br />
Weniger bekannt ist dagegen, daß die Gültigkeit der mehrwertigen Abhängigkeit zu einem neuen<br />
äquivalenten Schema führt, bei dem der Typ R durch die dekomponierten Typen wie in Bild<br />
?? ersetzt wird.<br />
Y ✛ XY ✲ X ✛ XZ ✲<br />
Z<br />
Abbildung 7: Die Zerlegung von R in zwei Relationship-Typen<br />
<strong>3.</strong>2.2 Weitere relationale Integritätsbedingungen<br />
Wertebereichsabhängigkeiten können im erweiterten ER-Modell verwendet werden. So gilt in unserem<br />
Beispiel<br />
Semester.Bezeichnung<br />
∈ {W S, SS} × {x/x+1|x ∈ 80..99, 00, 01, 02, ..., 17} .<br />
Andere wichtige Klassen von Abhängigkeiten sind Exklusions- und Inklusionsabhängigkeiten.<br />
<strong>3.</strong>2.3 Typen mit gemau einem minimalen Schlüssel<br />
Menge der Extremalattribute für gegebene Menge Σ von funktionalen Abhängigkeiten und Komponenten<br />
R eines Typs T :<br />
extr(R, Σ) := {B ∈ R | Σ ̸|= R \ {B} −→ {B}}<br />
Corollary 1 Folgende Aussagen sind äquivalent:<br />
• T besitzt genau einen Schlüssel.<br />
• extr(R, Σ) ist ein Schlüssel von T .<br />
• Σ |= extr(R, Σ) −→ R.<br />
<strong>3.</strong>2.4 Rahmen zur Spezifikation von Integritätsbedingungen<br />
Integritätsbedingungen werden in der Literatur noch immer leichtfertig nur in einfacher Form bzw.<br />
Rohform spezifiziert. Eine Spezifikation der Integritätsbedingungen muß umfassen:<br />
Integritätsbedingung in Rohform: Angabe der Integritätsbedingung als logische Formel<br />
Lokalisierung der Integritätsbedingung im Kontext des Systemens, d.h.<br />
durch Angabe der Schema-Umgebung einer Integritätsbedingung (Schema-Frame-Problem)<br />
und<br />
durch Angabe der betroffenen <strong>Datenbank</strong>objekte, die neben den betroffenen Objekten kontrolliert<br />
werden müssen (DB-Frame-Problem)<br />
Gültigkeit der Integritätsbedingungen je nach Phase der Anwendung, mindestens für die folgen-
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 16<br />
Archivierung der Datenbestände<br />
Ausführungsmodi zur Kontrolle der Integritätsbedingungen je nach Operation<br />
Ausführungszeit der Kontrolle z.B. verzögert, sofort ggf. auch mit Aussetzen unter bestimmten<br />
Bedingungen<br />
Anwendungsmonitoring der Kontrolle der Integritätsbedingungen z.B. auf Objektniveau oder<br />
auf Anweisungsniveau<br />
Umformung (term rewriting) der Operationen<br />
Behandlung für den Fall des Nichtgeltens der Integritätsbedingung je nach <strong>Datenbank</strong>ereignis:<br />
Zurückweisen der verursachenden Anweisung<br />
Propagierung der Integritätsbedingung<br />
Nutzung von (temporären) Zusatzwerten zur Kennzeichnung der Situation<br />
Rangordnung der Integritätsbedingung unter den Klassen von Integritätsbedingungen zur Ableitung<br />
der Kontrollreihenfolge<br />
Daneben können wir Default-Rahmen angeben:<br />
1. harte Integritätsbedingung ohne das Zulassen von Ausnahmen<br />
2. volle Schema- und DB-Umgebung<br />
<strong>3.</strong> keine Unterscheidung von Phasen<br />
4. sofortige Kontrolle bei <strong>Datenbank</strong>ereignissen ohne Ergänzung der Operationen<br />
5. gleichwertige Klassen von Integritätsbedingungen<br />
Insbesondere nutzen wir die folgenden Rahmen und Erzwingungsmodi:<br />
1. Spezifikation von Existenzabhängigkeiten<br />
Durch die Komplexitäten sind bereits Abhängigkeiten dargestellt worden, die von den generischen<br />
Operationen insert, delete, update eingehalten werden müssen. Ist für eine Komplexität<br />
comp(R, R ′ ) = (a, b) a ≥ 1, dann ist jedes insert in R ′ durch ein insert in R zu unterstützen.<br />
Jedes delete in R ′ kann ein delete in R nach sich ziehen. Alle derartigen Komplexitäten werden<br />
zusammengestellt und in den folgenden Schritten angewandt.<br />
Man kann für jeden Typen eine insert-, delete- und eine update-Umgebung mit folgendem Algorithmus<br />
konstruieren.<br />
(a) Env I (R) := Env D (R) := Env U (R) := {R} für jeden Entity- und Relationshiptypen.<br />
(b) Man generiere die Umgebungend erster Ordnung wie folgt.<br />
i. Gilt comp(R, R ′ ) = (a, b) für a ≥ 1 dann sei Env I (R) := Env I (R ′ ) ∪ Env I (R),<br />
Env U (R) := Env U (R ′ ) ∪ Env U (R) und Env D (R ′ ) := Env D (R) ∪ Env D (R).<br />
ii. Für jeden Relationshiptypen R ′ , in dem R eine Komponente bildet: Env I (R ′ ) :=<br />
Env I (R) ∪ Env I (R ′ ), Env U (R ′ ) := Env U (R) ∪ Env U (R ′ ) und Env D (R) :=<br />
Env D (R) ∪ Env D (R ′ ).<br />
iii. Für jede Exklusionsabhängigkeit R ‖ R ′ gilt Env I (R ′ ) := Env D (R) ∪ Env I (R)<br />
und Env U (R ′ ) := Env U (R) ∪ Env U (R).<br />
iv. Weitere Abhängigkeiten werden analog behandelt.<br />
(c) Man wiederhole diesen Schritt bis keine der Mengen verändert wird:<br />
i. Gilt comp(R ′′ , R ′ ) = (a, b) für a ≥ 1 und R ′′ ∈ Env I (R ′ ) dann sei Env I (R) :=<br />
Env I (R ′ ) ∪ Env I (R). Gilt comp(R ′′ , R ′ ) = (a, b) für a ≥ 1 und R ′′ ∈ Env U (R ′ )
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 17<br />
ii. Für jeden Relationshiptypen R ′′ mit R ′′ ∈ Env I (R ′ ), in dem R eine Komponente<br />
bildet, sei Env I (R ′ ) := Env I (R) ∪ Env I (R ′ ). Für jeden Relationshiptypen R ′′ mit<br />
R ′′ ∈ Env U (R ′ ), in dem R eine Komponente bildet, sei Env U (R ′ ) := Env U (R) ∪<br />
Env U (R ′ ). Für jeden Relationshiptypen R ′′ mit R ′′ ∈ Env D (R ′ ), in dem R eine<br />
Komponente bildet, sei Env D (R) := Env D (R) ∪ Env D (R ′ ).<br />
iii. Für jede Exklusionsabhängigkeit R ‖ R ′′ mit R ′′ ∈ Env I (R ′ ) gilt Env I (R ′ ) :=<br />
Env D (R)∪Env I (R). Für jede Exklusionsabhängigkeit R ‖ R ′′ mit R ′′ ∈ Env U (R ′ )<br />
gilt Env U (R ′ ) := Env U (R) ∪ Env U (R).<br />
iv. Weitere Abhängigkeiten werden analog behandelt.<br />
Diese Umgebungen sind maximale Umgebungen. Sie werden durch Eigenschaften der Anwendung<br />
eingeschränkt.<br />
Durch die Hierarchien sind entsprechende Existenzabhängigkeiten gegeben. Die Generalisierung<br />
(z.B. eine Person-de-jure ist eine Firma oder eine Person) führt zu einer Existenzabhängigkeit<br />
des Supertypen von Subtypen, die unbedingt gepflegt werden muß (d.h. werden die Daten<br />
einer Firma entfernt, dann werden diese auch für die Persona-de-jure entfernt). Die Spezialisierung<br />
führt zu einer Existenzabhängigkeit des Subtypen (in unserem Falle Teiltypen (Relationshiptypen<br />
definiert über dem Supertypen)) vom Supertypen.<br />
2. Erzwingungsregeln für insert- Operationen<br />
Man kann für insert-Operationen verschiedene Optionen bestrachten:<br />
• Abhängigkeit: Eine Einfügung ist nur erlaubt, wenn alle korrespondierenden Objekte bereits<br />
existieren.<br />
• Automatismus: Eine Einfügung ist stets erlaubt. Wenn entsprechende Objekte nicht existieren,<br />
dann werden sie ebenfalls eingefügt.<br />
• Nullwertebehandlung: Eine Einfügung ist stets erlaubt. Existieren die entsprechenden Objekte<br />
nicht, dann werden für das neue Objekt Nullwerte benutzt.<br />
• default-Werte: Eine Einfügung ist stets erlaubt. Existieren die entsprechenden Objekte<br />
nicht, dann werden für das neue Objekt default-Werte benutzt.<br />
• Zusätzliche Einfügebedingungen: Ein Einfügen ist nur dann erlaubt, wenn eine zusätzliche<br />
Bedingung gilt.<br />
• Keine Einschränkung: Das Einfügen unterliegt keiner Beschränkung.<br />
Die letzten beiden Möglichkeiten betreffen alle Typen außerhalb von Env I (R). Die ersten vier<br />
Möglichkeiten sind für Env I (R) bei der Spezifikation der Anwendung zu nutzen.<br />
<strong>3.</strong> Erzwingungsregeln für delete-Operationen<br />
Man kann für delete-Operationen verschiedene Optionen bestrachten:<br />
• Beschränkung: Ein Streichen ist nur erlaubt, wenn kein anderes Objekt davon betroffen<br />
ist.<br />
• Kaskadierung: Ein Streichen zieht das Streichen anderer Objekte nach sich.<br />
• Bedingte Kaskadierung: Ein Streichen zieht das Streichen anderer Objekte nach sich, die<br />
nur aufgrund des zu streichenden Objektes noch existieren.<br />
• Nullwertebehandlung: Beim Streichen werden Objekte, in die das Objekt eingeht auf<br />
einen Nullwert gesetzt.<br />
• default-Werte: Beim Streichen werden Objekte, in die das Objekt eingeht auf einen Nullwert<br />
gesetzt.<br />
• Zusätzliche Streichungsbedingungen: Das Streichen ist nur unter bestimmten Bedingungen<br />
erlaubt.<br />
• Keine Einschränkung: Das Streichen unterliegt keiner Beschränkung.
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 18<br />
4. Erzwingungsregeln für update-Operationen<br />
• Beschränkung: Ein update ist nur erlaubt, wenn kein anderes Objekt davon betroffen ist<br />
(z.B. auch über Sekundärschlüsseln, die nicht in Beziehungen verwandt werden).<br />
• Automatismus: Ein update ist stets erlaubt, solange Integritätsbedingungen des Typs nicht<br />
verletzt werden.<br />
• Kaskadierung: Ein update löst weitere Operationen aus.<br />
• Nullwertebehandlung: Konflikte werden durch Nullwerte gelöst.<br />
• default-Werte: Zur Konfliktbereinigung werden default-Werte benutzt.<br />
• Zusätzliche update-Bedingungen: Ein update ist nur unter zusätzlichen Bedingungen möglich.<br />
• Keine Einschränkung.<br />
Eine update-Operation ist nicht das Gleiche wie eine delete;insert-Folge.<br />
SQL2 läßt in der Vollversion Kaskadierung, Nullwertebehandlung, Default-Werte und Beschränkung<br />
(ist default) zu.<br />
Die Erzwingung kann auch aufgrund von Regel-Trigger-Systemen spezifiziert werden. Dann ist<br />
jedoch das Resultat bei automatischer Erzwingung falsch. Der GCS-Zugang von Schewe/Thalheim<br />
ist ein sicherer automatischer Zugang. Er ist allerdings für die Betrachtungen hier zu komplex.<br />
Erzwingungsregeln<br />
✙<br />
Unbedingte<br />
Erzwingung<br />
❄<br />
Keine<br />
Erzwingung<br />
❥<br />
Bedingte<br />
Erzwingung<br />
Kaskadierung<br />
Abhängigkeit<br />
✙ ❄ ❥<br />
Nullwertebehandlung<br />
default-<br />
Werte<br />
❄<br />
an Existenz<br />
gebunden;<br />
Rollback<br />
Abbildung 8: Mögliche Erzwingungsregeln für generische Operationen<br />
❥<br />
mit zusätzlichen<br />
Einfügebedingungen<br />
;<br />
Prädikat<br />
Die Integritätsbedingungen sind in SQL-92 in unterschiedlichen Modi und Matching unterstützt,<br />
wobei deren Zusammenwirken nicht erklärt ist.
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 19<br />
<strong>3.</strong>3 Übersetzung in relationale und andere Modelle<br />
<strong>3.</strong><strong>3.</strong>1 Übersetzung von ER-Konstrukten in relationale Konstrukte<br />
Mehrschrittverfahren wobei Semantik und Funktionalität mit übertragen werden muß<br />
Schlüssel und funktionale Abhängigkeiten in Schlüssel, funktionale und mehrwertige Abhängigkeiten<br />
implizite Komponenten in Inklusionsabhängigkeiten<br />
Exklusionsabhängigkeiten in Exklusionsabhängigkeiten<br />
Kardinalitätsbedingungen in funktionale, Inklusions- und No-null-Abhängigkeiten<br />
1. Herstellen der ersten Normalform (Tupelattribute durch Verkettungsregel, Mengenattribute entweder<br />
über Wiederholung in Tupeln oder durch eigene Relation); Neuberechnung der Schlüssel<br />
(bei Mengenattributen, die bislang im Schlüssel vorkamen, wird dann eine mehrwertige Abhängigkeit<br />
generiert und der Schlüssel verändert sich stark)<br />
2. Flache Entity-Typen werden in Relationenschema überführt<br />
<strong>3.</strong> Schwache flache Entity-Typen werden in Relationenschema übersetzt, wobei die Attributmenge<br />
um die Schlüssel der identifizierenden Schemas erweitert werden.<br />
4. Hierarchien von Typen sind in einem der folgenden Zugänge überführbar<br />
• event-nonseparation: Student, Professor, Person<br />
• event-separation: Student, Professor, AnderePerson<br />
• union: Person = Student + Professor + AnderePerson<br />
• weak universal relation: Person<br />
5. Relationship-Typen werden entsprechend ihrer Ordnung überführt<br />
• Binäre 1:1-Relationship-Typen :<br />
Mehrere Optionen:<br />
• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite; d.h.<br />
bei (1,1):(0,1)-Typen in ersten Typ) des Primärschl¨ssels des anderen Typen, sowie der<br />
Attribute des Relationship-Typen (Einfügen eines Fremdschlüssels)<br />
• Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten<br />
und Attributen des Relationship-Typen<br />
• Zusammenfügen der beiden Relationenschemas unter Beifügung der entsprechenden<br />
Relationship-Typ-Attribute<br />
falls Attribute keine Nullwerte enthalten dürfen, dann nur bei (1,1):(1,1)-Typen<br />
• N-äre 1:...-Relationship-Typen (n > 2):<br />
Mehrere Optionen:<br />
• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite; d.h.<br />
bei (1,1):(0,1)...-Typen in ersten Typ) des Primärschl¨ssels des anderen Typen, sowie<br />
der Attribute des Relationship-Typen (Einfügen eines Fremdschlüssels)<br />
• Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten<br />
und Attributen des Relationship-Typen<br />
• Zusammenfügen der beiden Relationenschemas unter Beifügung der entsprechenden<br />
Relationship-Typ-Attribute<br />
falls Attribute keine Nullwerte enthalten dürfen, dann nur bei (1,1):(1,1)-Typen<br />
• Binäre 1:n-Relationship-Typen :<br />
Mehrere Optionen:<br />
• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite; d.h.<br />
bei (1,1):(0,1)-Typen in ersten Typ) des Primärschl¨ssels des anderen Typen, sowie der
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 20<br />
• N-äre 1:n...-Relationship-Typen (n > 2):<br />
Mehrere Optionen:<br />
• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite; d.h.<br />
bei (1,1):(0,1)...-Typen in ersten Typ) des Primärschl¨ssels des anderen Typen, sowie<br />
der Attribute des Relationship-Typen (Einfügen eines Fremdschlüssels)<br />
• Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten<br />
und Attributen des Relationship-Typen<br />
• n:m -Relationship-Typen<br />
Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten und<br />
Attributen des Relationship-Typen<br />
• Rekursive Relationship-Typen<br />
wier normale Relationship-Typen aber unter Beibehaltung der Rollennamen<br />
• Is-A-Relationship-Typen<br />
• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite; d.h.<br />
bei (1,1):(0,1)-Typen in ersten Typ) des Primärschl¨ssels des anderen Typen, sowie der<br />
Attribute des Relationship-Typen (Einfügen eines Fremdschlüssels)<br />
• Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten<br />
und Attributen des Relationship-Typen<br />
• Zusammenfügen der beiden Relationenschemas unter Beifügung der entsprechenden<br />
Relationship-Typ-Attribute<br />
falls Attribute keine Nullwerte enthalten dürfen, dann nur bei (1,1):(1,1)-Typen<br />
• Cluster<br />
Mehrere Optionen:<br />
• Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten<br />
und Attributen des Relationship-Typen unter Einbeziehung der Rollennamen<br />
• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite) des<br />
Primärschl¨ssels des anderen Typen (Einfügen eines Fremdschlüssels) unter Beibehaltung<br />
der Rollennamen<br />
<strong>3.</strong><strong>3.</strong>2 Spezifika der Struktur-Übersetzung von HERM-Schemata<br />
Beobachtung 1.<br />
Es können komplexe Attribute auch eine harmonisierte Übersetzung anderer komplexer Attribute<br />
erfordern.<br />
Beispiel:<br />
Name(Vornamen(...), Familienname, [Geburtsname] ,...)<br />
Adresse(PlzBezirk ◦ Zustellamt, Ort, ...)<br />
erfordert Harmonisierung der Übertragung beider Attribute, da diese über Primärschlüssel gekoppelt<br />
sind<br />
Beobachtung 2.<br />
Die bisherigen Übersetzungsregeln sind nur Interpretationsregeln, die induktiv über dem Schemaaufbau<br />
definiert sind und nicht die Möglichkeiten von SQL92 und SQL:1999 unterstützen.<br />
Ein compilierender Zugang wird i.a. besser sein.<br />
Übersetzungsregeln in SQL:1999 nach S. Schoradt:<br />
1. Datensammelnde Regeln<br />
Für die Transformation eines Typen werden Informationen benötigt, die am Typen direkt an-
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 21<br />
zur Tranformation der Typen zusammengetragen. Dies können z. B. die Notwendigkeit der<br />
Erstellung eines Surrogatschlüssels zu einer Entitytypen oder das Hinzufügen von Integritätsbedingungen<br />
zu einem Typen sein.<br />
(a) Erstellen von Surrogatschlüsseln<br />
Das Erstellen von Surrogatschlüsseln ermöglicht es Objekte, die in der konzeptionellen<br />
Sicht nur auf sehr komplexe Art zu identifizieren sind, in einem DBMS zu verwalten.<br />
Hierzu wird zu dem Objekt ein atomares Attribut hinzugefügt, das als neuer Schlüssel für<br />
das Objekt fungiert. Die existierende Schlüsselbeziehung wird weiterhin mitgeführt und<br />
gepflegt, dient aber nicht mehr der Identifikation der Instanzen des Objektes. Der Surrogatschlüssel<br />
zu einem Objekt sollte vom DBMS gepflegt werden, so das die darüberliegende<br />
Applikation diese technische Veränderung des Schemas nicht beachten muss.<br />
Dies kann durch Mittel des DBMS zum generieren eindeutiger Objektschlüssel geschehen<br />
oder aber durch die Erzeugung eines Schlüssels in einem Trigger zum Objekt.<br />
Durch diese Regel wird zu jeder Entity-Typen oder Relationship-Typen, die Komponente<br />
einer Relation oder eines Clusters ist, ein Surrogatschlüssel angelegt. Mittels diesem<br />
wird im Weiteren die Implementation der Relation und die Pflege der damit verbundenen<br />
Integritätsbedingungen realisiert.<br />
(b) Optimierung der Schemastruktur<br />
Bei der Übersetzung von Schemata kann es notwendig sein das Schema strukturell zu<br />
verändern, um ein optimales Ergebnis zu erzielen. Eine häufig genutzte Optimierungsvariante<br />
ist das Auflösen von Relationen mit der Kardinalitätsbeschränkung (1, 1) oder<br />
(0,1).<br />
(c) Integritätsbedingungen<br />
Oftmals sind Integritätsbedingungen indirekt im konzeptionellen Schema kodiert. Um diese<br />
bei der Transformation zu beachten, müssen sie zur Menge der Integritätsbedingungen<br />
eines Typen hinzugefügt werden.<br />
Diese Regeln weisen zum Einen die Komponenten einer Relation als Schlüssel aus, falls<br />
noch nicht geschehen und vergeben für alle Relationen deren Kardinalität nicht spezifiziert<br />
ist die Kardinalitätsbeschränkung (0,n).<br />
2. Elementare Transformationen<br />
An dieser Stelle sollen für die einzelnen Schemaelemente elementare Übersetzungsregeln angegeben<br />
werden. Diese Wandeln einen Typen in eine SQL Anweisung oder einen Anweisungsteil<br />
um.<br />
Die Transformationen, die in diesen Regeln verwandt werden, stammen grösstenteils aus [Tha00]<br />
und wurden an die Möglichkeiten von SQL:1999 und den entworfenen Übersetzungsprozess<br />
angepasst.<br />
(a) Regeln für Domaintypen<br />
Jeder Domaintyp im Schemagraph repräsentiert eine Domäne aus dem HER Schema.<br />
Diese sind durch die Menge aller erlaubten Elemente beschrieben und müssen durch die<br />
Transformation auf die vorhandenen SQL Datentypen abgebildet werden.<br />
SQL:1999 kennt Datentypen der Kategorien:<br />
• Zeichendaten<br />
• numerische Daten<br />
• Wahrheitswerte<br />
• Datumswerte<br />
Die richtige Transformation der Domains in SQL Datentypen wird durch die Kombination<br />
von Transformationsregel und Bewertungsfunktion erreicht.<br />
(b) Regeln zur Behandlung von Attributtypen<br />
Bei den AttributTypen hängt die Anwendung einer Regel von ihrem Konstruktor und den
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 22<br />
• einführen von Blattattributen, z. B. wird ein Tupelattribut Name(vname,nname) in die<br />
Attribute Name.vname und Name.vname transformiert<br />
• erstellen eines eigenen Subschemas<br />
• als komplexes Attribut belassen<br />
In SQL:1999 ergibt sich weiterhin die Möglichkeit komplexe Attribute in komplexe Datentypen<br />
zu transformieren.<br />
Diese Option wurde soweit möglich verfolgt, um die Möglichkeiten von SQL:1999 auszunutzen.<br />
Bei der Transformation von Tupeltypen, kann als Implementation ein ROW Typ verwandt<br />
werden.<br />
Mengentypen werden rekursiv, anhand ihrer Struktur, transformiert. Es existieren mehrere<br />
Möglichkeiten Mengen in einer <strong>Datenbank</strong> zu repräsentieren, hier soll dies durch das<br />
Erstellen einer Tabelle zu jeder Menge geschehen. Zur Transformation eines mengenwertigen<br />
Attributs muss zuerst der Inhalt der Menge transformiert werden und danach das<br />
Attribut in eine Tabelle und eine Referenz in die Mengentabelle transformiert werden.<br />
(c) Transformation der Entity-Typen<br />
Die Transformation eines Entity-Typen kann erfolgen wenn alle enthaltenen Attribut-<br />
Typen transformiert wurden.<br />
(d) Transformation von Relationship-Typen<br />
Die Transformation eines Relationship-Typen kann erfolgen wenn alle Attribute und alle<br />
enthaltenen Objekte transformiert wurden.<br />
Hierzu müssen die enthaltenen Relationen und Entityen in Fremdschlüsselbeziehungen<br />
umgewandelt werden. Die enthaltenen Attribute werden analog zur Transformation eines<br />
Entity-Typen behandelt.<br />
(e) Transformation von Cluster-Typen<br />
Ein Cluster-Typ wird transformiert nachdem alle enthaltenen Relationen bzw. Entityen<br />
transformiert wurden.<br />
Der Cluster C = R1 + R2 + . . . + Rn wird in eine Referenz auf die Surrogatschlüssel der<br />
enthaltenen Relationen transformiert, ohne aber mittels einer Fremdschlüsselbeziehung<br />
abgesichert zu werden.<br />
<strong>3.</strong><strong>3.</strong>3 Spezifika der Semantik-Übersetzung von HERM-Schemata<br />
Beobachtung <strong>3.</strong><br />
Weder SQL’92 noch SQL:1999 erlauben eine vollständige direkte Übertragung von Integritätbedingungen.<br />
Es können Integritätsbedingungen auf unterschiedliche Art übertragen werden:<br />
• Restrukturierung des Schemas bis eine vollständige Übertragung unterstützt wird.<br />
• Deklarative Spezifikation der Integritätsbedingungen.<br />
• Prozedurale Spezifikation der Integritätsbedingungen.<br />
• Abbildung der Integritätsbedingungen in eine Wirtssprache<br />
• Zusätzliche integritätsbedingungssichernde Maßnahmen<br />
• Sicherstellung durch Benutzungsschnittstellen<br />
• Sicherstellung durch Ausnahmebehandlung<br />
• Generierung und Benutzung von sicheren integritätspflegenden Funktionen anstelle der<br />
nicht invarianten Funktionen
IMMEDIATE<br />
fordert die Kontrolle einer Integritätsbedingung für jede Anweisung, mit der diese<br />
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 23<br />
MATCH-Bedingungen.<br />
SQL-92 erlaubt unterschiedliche MATCH-Bedingungen:<br />
• einfach als nicht spezifiziertes “default” und Anwendung auf alle Tupel t über Attributliste X<br />
mit t[X]!, d.h. über Teilmenge {t ∈ R C | ∀A ∈ X : t(A) ≠ NULL} ,<br />
d.h. z.B. für R[X] ⊆ S[Y ], X = A 1 ...A k , und Y = B 1 ...B k wird die Bedingung<br />
∀t ∈ R C ( (∃i (1≤i≤k) t(A i ) = NULL) ∨ ∃s ∈ S C (t[X] = s[Y ]))<br />
• FULL wird angewandt auf alle Tupel, die nicht das NULL-Tupel sind, wobei dann Nullwerte<br />
nicht erlaubt sind,<br />
d.h. z.B. für R[X] ⊆ S[Y ], X = A 1 ...A k , und Y = B 1 ...B k wird die Bedingung<br />
∀t ∈ R C ( ∀i (1≤i≤k) (t(A i ) = NULL) ∨<br />
(∀i (1≤i≤k) (t(A i ) ≠ NULL) ∧ ∃s ∈ S C (t[X] = s[Y ])))<br />
• PARTIAL wird angewandt auf alle Tupel t, deren X-Wert nicht das NULL-Tupel ist, wobei in<br />
der Kontrollmenge eine Gleichheit bis auf Nullwerte in t[X] besteht,<br />
d.h. z.B. für R[X] ⊆ S[Y ], X = A 1 ...A k , und Y = B 1 ...B k wird die Bedingung<br />
∀t ∈ R C ( ∀i (1≤i≤k) (t(A i ) = NULL) ∨<br />
∃s ∈ S C (∀i (1≤i≤k) (t(A i ) = NULL ∨ t(A i ) = s(B i ))))<br />
wobei diese Bedingung äquivalent ist zu<br />
∀t ∈ R C (∃s ∈ S C (∀i (1≤i≤k) (t(A i ) = NULL ∨ t(A i ) = s(B i )))) .<br />
FULL kann auch direkt ausgedrückt werden durch:<br />
CHECK (<br />
(A1 IS NULL AND ... AND Ak IS NULL)<br />
OR<br />
( A1 IS NOT NULL AND ... AND Ak IS NOT NULL<br />
AND A1,...,Ak<br />
IN SELECT B1 ... Bk FROM S ))<br />
PARTIAL ist auch darstellbar durch eine Fallunterscheidung je nach vorkommenden Nullwert im<br />
referenzierendem Tupel:<br />
CHECK (<br />
(A1 IS NULL AND ... AND Ak IS NULL)<br />
OR<br />
( A1 NULL AND A2 IS NOT NULL ... AND AK IS NOT NULL<br />
AND A2,...,Ak<br />
IN SELECT B2 ... Bk FROM S )<br />
OR ... OR<br />
( A1 IS NOT NULL ... AND A(k-1) IS NOT NULL AND AK IS NULL<br />
AND A1,...,A(k-1)<br />
IN SELECT B1 ... B(k-1) FROM S )<br />
OR ... OR<br />
( A1 IS NULL AND ... A(k-1) IS NULL AND AK IS NOT NULL<br />
AND Ak<br />
IN SELECT Bk FROM S )<br />
)<br />
Ausführungsmodi.<br />
SQL-92 hat bereits Asuführungsmodi eingeführt:<br />
DEFERRED erlaubt das Aufschieben eine Kontrolle der Integritätsbedingungen bis zum Ende einer<br />
Transaktion.
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 24<br />
INITIALLY IMMEDIATE NOT DEFERABLE ist die default-Bedingung für Integritätsbedingungen.<br />
Diese Bedingung kann auch durch NOT DEFERABLE INITIALLY IMMEDIATE deklariert<br />
werden.<br />
INITIALLY DEFERRED NOT DEFERABLE Diese Bedingung kann auch durch NOT DEFERABLE<br />
INITIALLY DEFERRED deklariert werden.<br />
INITIALLY DEFERRED DEFERABLE Diese Bedingung kann auch durch DEFERABLE INITIALLY<br />
DEFERRED deklariert werden.<br />
INITIALLY IMMEDIATE DEFERABLE sollte stets für alle Bedingungen deklariert werden, die<br />
mit Transaktionen ggf. verletzt werden können. Diese Bedingung kann auch durch DEFERABLE<br />
INITIALLY IMMEDIATE deklariert werden.<br />
Der Ausführungsmodus kann umgesetzt werden mit<br />
bzw.<br />
bzw.<br />
bzw.<br />
SET CONSTRAINTS name list IMMEDIATE<br />
SET CONSTRAINTS name list DEFERRED<br />
SET CONSTRAINTS ALL IMMEDIATE<br />
SET CONSTRAINTS ALL DEFERRED<br />
Deklarative Spezifikation mit CHECK-Bedingungen.<br />
CHECK-Bedingungen werden definiert<br />
• auf Attributniveau zu den Werten dieses Attributes,<br />
• auf Tabellenniveau für jedes einzelne Tupel der Relation, wobei hier auch subselect erlaubt sind<br />
und<br />
• über den Umweg der Defintion mit Assertions.<br />
Deklarative Spezifikation mit ASSERTION.<br />
ASSERTION ist eine Schema-Bedingung. Sie ist jedoch relativ selten realisiert. Oracle erlaubt<br />
z.B. nicht die Spezifikation.<br />
CREATE ASSERTION Institut<br />
CHECK (Bedingung);<br />
Sie wird immer dann aktiviert, wenn die Klassen zu den verwendeten Tabellen modifiziert werden.<br />
CREATE TABLE Fakultaet (<br />
...<br />
Nummer FakNr PRIMARY KEY,<br />
.. );<br />
CREATE ASSERTION AssignFakultaet<br />
CHECK (NOT EXISTS (<br />
SELECT *<br />
FROM Institut<br />
WHERE FakNr IS NULL)<br />
);<br />
CREATE ASSERTION AnzahlInstZuFak
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 25<br />
Die erste der beiden Assertionen wird kontrolliert bei jder Veränderung zu Institut. Die zweite<br />
wird kontrolliert bei jeder Veränderung sowohl von Institut als auch von Fakultaet.<br />
Prozedurale Spezifikation mit Triggern.<br />
Trigger sind mit den Event-Condition-Action-Paradigma entworfen (kurz ECA). Damit gewähren<br />
Trigger anderen Möglichkeiten als die anderen SQL-Konstrukte.<br />
So kann z.B. mit Oracle folgender Trigger spezifiziert werden.<br />
CREATE OR REPLACE TRIGGER TriggInstitutFakult<br />
AFTER INSERT ON Institut<br />
FOR EACH ROW<br />
WHEN (new.Fakultaet NOT IN<br />
(SELECT Nummer FROM Fakulataet))<br />
BEGIN<br />
INSERT INTO Fakultaet (Nummer)<br />
VALUES (:new.Fakultaet);<br />
END;<br />
.<br />
run<br />
Folgende Besonderheiten sollten beachtet werden:<br />
• OR REPLACE kann auch nicht spezifiziert werden. Sollte jedoch bereits ein Trigger existieren,<br />
dann ist dies ein Fehler.<br />
• AFTER kann auch ersetzt werden durch BEFORE .<br />
• Wird der Trigger für eine Sicht spezifiziert, dann kann auch anstelle von AFTER der Ersatz<br />
durch INSTEAD OF benutzt werden. Damit kann auch eine Sicht modifiziert werden.<br />
• Anstelle von INSERT kann auch DELETE oder UPDATE OF verwendet<br />
werden.<br />
• FOR EACH ROW kann man auch weglassen. In diesem Fall wird der Trigger nur einmal für<br />
jede Modifikationsmenge zur Relation angewandt.<br />
• Die Variablen new und old repräsentieren den Zustand nach bzw. vor Anwendung der<br />
Modifikationsoperation. Bei Verwendung der Variablen in Anfragen ist der Doppelpunkt erfoderlich<br />
( :new.Fakulataet ).<br />
• Die Aktionen sind Anweisungen des Systemes. Mitunter sind sie verschieden in verschiedenen<br />
Systemen.<br />
• Durch den Punkt wird die Triggerdefinition abgelegt mit einem run .<br />
• Oracle erlaubt keine Veränderung einer Relation, deren Trigger feuert, sowie auch von assoziierten<br />
Relationen (z.B. über Fremdschlüssel).<br />
Trigger in Sybase<br />
Eine Integritätsbedingung als Sybase-Trigger in unserem Beispiel wird z.B. wie folgt beschrieben<br />
create trigger tI_eingeschriebenIn on eingeschriebenIn for INSERT as<br />
begin<br />
declare<br />
@numrows int,<br />
@nullcnt int,<br />
@validcnt int,<br />
@errno int,
create trigger tD_EingeschriebenIn<br />
after DELETE<br />
on EingeschriebenIn<br />
for each row<br />
declare numrows INTEGER;<br />
begin<br />
/* ON CHILD DELETE RESTRICT */<br />
select count(*) into numrows from Student<br />
where<br />
:old.MatrNr = Student.MatrNr;<br />
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 26<br />
update(MatrNr)<br />
begin<br />
select @nullcnt = 0<br />
select @validcnt = count(*)<br />
from inserted,Student<br />
where<br />
inserted.MatrNr = Student.MatrNr<br />
if @validcnt + @nullcnt != @numrows<br />
begin<br />
select @errno = 30002,<br />
@errmsg = ’Cannot INSERT eingeschriebenIn because Student does not<br />
goto error<br />
end<br />
end<br />
return<br />
error:<br />
raiserror @errno @errmsg<br />
rollback transaction<br />
end<br />
go<br />
Trigger in Oracle<br />
Analog wird ein Trigger mit Oracle deklariert, mit dem ein Update in anderen Relationen erzwungen<br />
wird:<br />
create trigger tI_eingeschriebenIn<br />
after INSERT<br />
on EingeschriebenIn<br />
for each row<br />
declare numrows INTEGER;<br />
begin<br />
/* ON CHILD INSERT CASCADE */<br />
insert into Student (MatrNr)<br />
select MatrNr<br />
from EingeschriebenIn<br />
where<br />
not exists (<br />
select * from Student<br />
where<br />
:new.MatrNr = Student.MatrNr<br />
);<br />
end;<br />
/
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 27<br />
-20010,<br />
’Cannot DELETE EingeschriebenIn because Student exists.’<br />
);<br />
end if;<br />
end;<br />
/<br />
create trigger tU_EingeschreibenIn<br />
after UPDATE<br />
on EingeschriebenIn<br />
for each row<br />
declare numrows INTEGER;<br />
begin<br />
/* ON CHILD UPDATE RESTRICT */<br />
select count(*) into numrows<br />
from StarkerTyp<br />
where<br />
:new.MatrNr = Student.MatrNr;<br />
if (<br />
numrows = 0<br />
)<br />
then<br />
raise_application_error(<br />
-20007,<br />
’Cannot UPDATE EingeschriebenIn because Student does not exist.’<br />
);<br />
end if;<br />
end;<br />
/<br />
create trigger tD_Student<br />
after DELETE<br />
on Student<br />
for each row<br />
declare numrows INTEGER;<br />
begin<br />
/* ON PARENT DELETE RESTRICT */<br />
select count(*) into numrows<br />
from einfachabhangig<br />
where<br />
EingeschriebenIn.MatrNr = :old.key;<br />
if (numrows > 0)<br />
then<br />
raise_application_error(<br />
-20001,<br />
’Cannot DELETE Student because EingeschriebenIn exists.’<br />
);<br />
end if;<br />
end;<br />
/<br />
/* Student ON PARENT UPDATE CASCADE */<br />
/* Student ON CHILD DELETE RESTRICT */
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 28<br />
Trigger in PostgreSQL<br />
Trigger könne in PostgreSQL durch Funktionen realisiert werden, die die neue RECORD Variable<br />
nutzen:<br />
• Es wird die Funktion deklariert.<br />
• Der Trigger benutzt die Funktion.<br />
Funktionendefinition:<br />
CREATE FUNCTION trigger_insert_update_relName()<br />
RETURNS opaque<br />
AS<br />
’BEGIN<br />
IF ...<br />
THEN RAISE EXCEPTION ’’Mitteilung an alle’’;<br />
END IF;<br />
RETURN new;<br />
END;’<br />
LANGUAGE ’plpgsql’;<br />
Damit kann nun der Trigger spezifiziert werden:<br />
CREATE TRIGGER tr_relName<br />
BEFORE INSERT OR UPDATE<br />
ON relName<br />
FROR EACH ROW<br />
EXECUTE PROCEDURE<br />
trigger_insert_update_relName()<br />
;<br />
Zusammenfassende Übersicht.<br />
Art SQL-92 SQL-99<br />
Entry Level Intermediate Level Full Level<br />
Primary immer sofort immer sofort<br />
key, domain<br />
constraints<br />
Unique NOT NULL, immer<br />
constraints sofort<br />
Referential MATCH wird nicht MATCH wird nicht<br />
constraints unterstützt<br />
unterstützt<br />
Check- ohne subquery ohne subquery<br />
Bedingungen<br />
Assertions nicht unterstützt nicht unterstützt<br />
<strong>3.</strong><strong>3.</strong>4 Allgemeine Grundlagen der Erzwingung von Integritätsbedingungen<br />
In SQL 99 bestehen mehrere Möglichkeiten Integritätsbedingungen auszudrücken und zu erzwingen.<br />
Diese sind<br />
• Tabellenbedingungen, wie PRIMARY KEY, UNIQUE oder CHECK Beschränkungen<br />
• Ausnahmen (Assertion), die einen unerwünschten Zustand in der <strong>Datenbank</strong> verhindern<br />
• Trigger, die ermöglichen auf <strong>Datenbank</strong>operationen zu reagieren
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 29<br />
Komplexere Bedingungen können mittels Ausnahmen (Assertions) oder Trigger beschrieben werden.<br />
Bei einer Ausnahme, wird ein erwünschter <strong>Datenbank</strong>zustand beschrieben, und es wird von der<br />
<strong>Datenbank</strong> nach jeder datenverändernden Aktion garantiert, das dieser noch erfüllt wird. Wird der<br />
Zustand nicht erfüllt, so wird die Aktion abgelehnt. Durch Trigger kann nach einer datenverändernden<br />
Aktion individuell reagiert werden.<br />
Schlüsselbedingungen: Die Behandlung von HER Schlüsselbedingungen kann auf zwei Arten erfolgen.<br />
Zum einen durch eine statische UNIQUE Bedingung über den Schlüsselfeldern der<br />
erstellten Tabelle oder aber durch eine Ausnahmebehandlung mittels ASSERTION.<br />
Die Auswahl des geeigneten Mittels hängt von der Komplexität des Schlüssels ab. Schlüssel<br />
im HER Ansatz werden als generalisierte Untermengen [Tha91, S. 7] der Attributmenge eines<br />
Entity-Typs beschrieben. Diese können nur auf die Schlüsselbedingungen in SQL abgebildet<br />
werden, wenn die Untermenge nur aus atomaren Attributen des Entity-Typen besteht.<br />
Ist diese Bedingung für den Schlüssel nicht erfüllt, so muss dieser in eine ASSERTION transformiert<br />
werden.<br />
Stehen keine Ausnahmen zur Verfügung, kann ebenfalls ein Trigger, der bei Verletzung der noch<br />
zu definierenden Schlüsselbedingung key condition ein Rollback der letzten <strong>Datenbank</strong>aktion<br />
auslöst, verwandt werden. Solch ein Trigger müsste zu allen des Objekt E betreffenden Tabellen<br />
in der <strong>Datenbank</strong> erstellt werden.<br />
Aus diesem Grunde stellt eine Ausnahme die vorzuziehende Alternative dar.<br />
Um die Schlüsselbedingung zu garantieren darf es keine zwei verschiedenen Datensätze in E<br />
geben, bei denen alle atomaren Schlüsselattribute und die aus den mengenwertigen Schlüsselattributen<br />
ableitbaren Mengen gleich sind. Da Mengen in SQL nicht auf kanonische Weise<br />
vergleichbar sind, wird der Zusammenhang M 1 = M 2 ⇔ M 1 ∪ M 2 \ M 1 ∩ M 2 = ∅ für den<br />
Vergleich zweier Mengen verwandt. Dieser lässt sich mittels UNION, INTERSECTION und<br />
EXCEPT in SQL ausdrücken. Anhand dieser Betrachtungen wurde die Abfrage key condition<br />
abgeleitet:<br />
SELECT COUNT(_) FROM E e1, E e2<br />
WHERE e1.s1 = e2.s1 AND . . . AND e1.sk = e2.sk<br />
AND NOT EXISTS<br />
(<br />
(<br />
( SELECT i1 FROM set m1 WHERE set id = e1.k1.m1 )<br />
UNION<br />
( SELECT i1 FROM set m1 WHERE set id = e2.k1.m1 )<br />
) EXCEPT (<br />
( SELECT i1 FROM set m1 WHERE set id = e1.k1.m1 )<br />
INTERSECT<br />
( SELECT i1 FROM set m1 WHERE set id = e2.k1.m1 )<br />
)<br />
)<br />
. . .<br />
AND NOT EXISTS<br />
(<br />
(<br />
( SELECT il FROM set ml WHERE set id = e1.kl.ml )<br />
UNION<br />
( SELECT il FROM set ml WHERE set id = e2.kl.ml )<br />
)<br />
EXCEPT
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 30<br />
)<br />
)<br />
AND e1. E id e2. E id<br />
Wertebereichsbeschränkungen sollen den Wertebereich direkt spezifizieren. Diese können entweder<br />
durch einen extra spezifizierten Wertebereich dargestellt werden (die bessere Variante)<br />
oder durch eine Bedingung in der Tabellendefinition.<br />
CREATE TABLE Institut (<br />
...<br />
Fakultaet<br />
.. );<br />
char(1) NOT NULL<br />
CHECK VALUE IN (’1’, ’2’, ’3’, ’4’),<br />
Besser ist die Definition eines Wertebereiches<br />
CREATE DOMAIN FakNr CHAR(1) CHECK VALUE IN (’1’, ’2’, ’3’, ’4’);<br />
und die Benutzung dieses Wertebereiches mit<br />
CREATE TABLE Institut (<br />
...<br />
Fakultaet<br />
.. );<br />
FakNr NOT NULL,<br />
Hierarchiebedingungen: Oft werden Hierarchien abgebildet im Vereinigungszugang. So kann z.B.<br />
due Hierarchie Person, Professor in einen Typ abgebildet werden:<br />
CREATE TABLE Person (<br />
Name char[40] Primary Key,<br />
Gebdatum date Primary Key,<br />
Geburtsort char[20],<br />
Adresse<br />
char[60]<br />
Spezialisierung varchar[50] CHECK ((InIName IS NULL<br />
AND Spezialisierung IS NULL)<br />
OR (InIName IS NOT NULL<br />
AND Spezialisierung IS NOT NULL))<br />
InIName char[15] CHECK ((InIName IS NULL<br />
AND Spezialisierung IS NULL)<br />
OR (InIName IS NOT NULL<br />
AND Spezialisierung IS NOT NULL))<br />
);<br />
Kardinalitätsbedingungen: Die Transformation der Kardinalitätsbeschränkungen, benötigt einige<br />
Vorbetrachtungen, die es uns im späteren ermöglichen einigen Problemen bei der Behandlung<br />
dieser zu umgehen.<br />
Kardinalitätsbeschränkungen beschreiben die Beziehungen zwischen Relationen und ihren Komponenten<br />
in einem HER Schema.<br />
Bei der Betrachtung einer Menge von Kardinalitätsbeschränkungen ist schnell ersichtlich, das<br />
bei schlechtem Design Konstellationen entstehen können, die nach der Transformation auf eine<br />
<strong>Datenbank</strong> in dieser unerwartete Effekte erzeugen können, z.B. zu unerfüllbaren <strong>Datenbank</strong>-
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 31<br />
Tests auf Nichterfüllbarkeit und der Möglichkeiten zur Korrektur der Kardinalitätsbeschränkungen<br />
eines Schemas kann die Menge der Kardinalitätsbeschränkungen soweit möglich in einen<br />
konsistenten Zustand gebracht werden, so das die Transformation auf das <strong>Datenbank</strong>niveau<br />
keine unerwarteten Effekte erzeugt.<br />
Die Transformation der Kardinalitätsbeschränkung kann analog zu den Schlüsselbeschränkungen<br />
in einen Trigger oder eine Ausnahme erfolgen. Es ist aber auch unter speziellen Bedingungen<br />
möglich, Kardinalitätsbedingungen durch eine Transformation des Ergebnissschemas<br />
auszudrücken. So kann bei Kardinalitätsbedingungen der Form comp(R, R i ) = (n, 1) , mit<br />
n ∈ {0, 1} auf einer binären Relation R, die Relation R aufgelöst werden und in die Relation<br />
R i hineingezogen werden. Das bewirkt das alle Attribute aus R zu Attributen von R i werden.<br />
Gilt n = 0 wird der Spaltendefinition noch eine NULL Definition hinzugefügt.<br />
Handelt es sich nicht um eine Kardinalitätsbeschränkung der obigen Art, so ist die Transformation<br />
in einen Trigger der Ausnahme vorzuziehen, da individuell auf die Verletzung der Bedingung<br />
reagiert werden kann.<br />
Zu jeder Kardinalitätsbeschränkung ist die zu triggernden Aktionen bei Veränderung oder Löschen<br />
des referenzierten Datensatzes als Transformationsparameter zu beachten. Die Transformation<br />
der Kardinalitätsbeschränkung comp(R, R i ) = (m, n) führt zu einer Veränderung der Relation<br />
und zu mehreren Triggern. Für die Kardinalitätsbedingung sind die Aktionen<br />
• Einfügen von Elementen in Ri<br />
• Verändern der Identifikationsspalte (hier des Surrogatschlüssels) von Ri. Dieser Fall sollte<br />
nicht auftreten, ist aber aus Stabilitätsgründen trotzdem zu behandeln.<br />
• Einfügen von Elementen in R. Es können hier die Beschränkungen von 26 überschritten<br />
werden.<br />
• Verändern der Ri Spalte von R. Hier sind die unteren und oberen Grenzen der Kardinalitätsbedingungen<br />
zu überprüfen.<br />
• Löschen von Elementen von R. Hier ist die untere Grenze der Bedingung zu prüfen. zu<br />
überwachen.<br />
Werden durch eine dieser Aktionen die Bedingungen verletzt, so wird die auslösende Aktion<br />
zurückgenommen.<br />
Hierbei ist im Zusammenhang mit dem Hintergrund der Datenpflege zu beachten das bestimmte<br />
Integritätsbedingungen erst nach dem Ende einer Transaktion gepflegt werden dürfen, da sonst<br />
ihre Erfüllung praktisch ünmöglich ist. Dies ist z. B. bei Kardinalitätsbeschränkungen der Form<br />
comp(R, E) = (1, n) der Fall. Beim Einfügen eines Datensatzes in E muss auch ein Eintrag in<br />
der Relation R erfolgen. Dies kann praktisch durch eine Transaktion geschehen, in der erst der<br />
Datensatz in E angelegt wird und daraufhin der Datensatz in R.<br />
Für die Transformation einer Kardinalitätsbeschränkung werden auch Trigger erzeugt, durch<br />
die die Einhaltung der Kardinalitätsbedingung comp(R, R i ) = (m, n) erreicht wird. Sie verhindern<br />
jede datenverändernde Aktion (Insert, Update oder Delete), durch die die Kardinalitätsbedingung<br />
verletzt werden könnte. Da die Kardinalitätsbedingung per Definition in der leeren<br />
<strong>Datenbank</strong> erfüllt ist, so ist sie es auch in jeden Folgezustand.<br />
Wir können Kardinalitaätsbedingungen in zwei Klassen von Integritätsbedingungen aufspleißen:<br />
1. Unäre tupelgenerierende Bedingungen<br />
LHS ⊑ minimal multiplicity RHS bzw. card(RHS, LHS) = (a, .)<br />
• Insertion in LHS: Kaskadierend in RHS oder Verbot für LHS (wenn IC ungültig,<br />
RESTRICT (als harte Bedingung: wird sofort vor allen anderen kontrolliert) oder<br />
NO ACTION (als weiche Bedingung: wird nach allen anderen IC kontrolliert)) oder<br />
Benutzung von Ersatzwerten (DEFAULT oder NULL)[wobei diese Optionen nur in
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 32<br />
• Delete in RHS: CASCADE in LHS oder RESTRICT (in SQL-92: Default-Regel;<br />
wenn nicht deklarierts) bzw. NO ACTION in RHS oder SET DEFAULT bzw. SET<br />
NULL in LHS oder bewußte Verletzung (SKIP)<br />
• Delete in LHS: keine Auswirkungen<br />
• Update in LHS: CASCADE in RHS oder RESTRICT bzw. NO ACTION in LHS<br />
oder SET DEFAULT bzw. SET NULL in RHS [wobei diese Optionen nur in Ausnahmefällen<br />
sinnvoll sind] oder bewußte Verletzung (SKIP)<br />
Default-Strategie für fast alle Systeme: REJECT<br />
• Update in RHS: CASCADE in LHS oder RESTRICT bzw. NO ACTION in RHS<br />
oder SET DEFAULT bzw. SET NULL in LHS oder bewußte Verletzung (SKIP)<br />
Erzwingungsmodus als Hexatupel (i LHS , λ, λ, d RHS , u LHS , u RHS )<br />
ausreichend ist bereits Quadrupel (i LHS , d RHS , u LHS , u RHS )<br />
z.B. card(EingeschriebenIn, Student) = (1, .) erfordert (i Stud =C,λ,λ,d Eing =R,u Stud =R,u Eing =R<br />
bzw. (i Stud =C,d Eing =R,u Stud =R,u Eing =R)<br />
Realisierung:<br />
• RESTRICT für Insert und Update bei card(RHS, LHS) = (1, .) bei EingeschriebenIn<br />
:<br />
ALTER TABLE Student ADD CONSTRAINT<br />
CHECK(EXISTS(SELECT * FROM EingeschriebenIn<br />
WHERE EingeschriebenIn.StudMatrNr = MatrNr));<br />
Alternativ kann auch bei einigen Systemen die RESTRICT-Regel direkt den Attributen<br />
zugeordnet werden:<br />
CREATE TABLE EingeschriebenIn (<br />
StudMatrNr char[7] CHECK(<br />
StudMatrNr IN (SELECT MatrNr FROM Student)<br />
),<br />
...<br />
Bis date CHECK ( Von < Bis )<br />
PRIMARY KEY (SName, StudMatrNr)<br />
);<br />
Die Möglichkeit wird z.Z. nur rudimentär unterstützt. Z.B. Oracle erlaubt keine Subqueries<br />
in Bedingungen. Die CHECK-Bedingung ist weniger restriktiv, da eine Veränderung<br />
in Student nicht auf EingeschriebenIn durchgegeben wird! Sie wird nur<br />
kontrolliert, wenn das entsprechende Attribut sich in EingeschriebenIn ändert<br />
(d.h. bei Update und Insert).<br />
Analog für RESTRICT für Insert und Update bei card(RHS, LHS) = (3, .)<br />
ALTER TABLE Student ADD CONSTRAINT<br />
CHECK(EXISTS(<br />
SELECT * FROM EingeschriebenIn E1,<br />
WHERE E1.StudMatrNr = MatrNr<br />
AND EXISTS(<br />
SELECT * FROM EingeschriebenIn E2<br />
WHERE MatrNr = E2.StudMatrNr<br />
AND E1.SName E2.SName<br />
AND EXISTS(<br />
SELECT * FROM EingeschriebenIn E3<br />
WHERE E<strong>3.</strong>StudMatrNr = MatrNr<br />
AND E1.SName E<strong>3.</strong>SName<br />
AND E2.SName E<strong>3.</strong>SName))));<br />
• Modi für Delete und Update für Komponentenabhängigkeiten R[S] ⊆ S
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 33<br />
REFERENCES Student(MatrNr)<br />
ON DELETE CASCADE<br />
ON UPDATE RESTRICT,<br />
...<br />
Bis date CHECK ( Von < Bis )<br />
PRIMARY KEY (SName, StudMatrNr)<br />
);<br />
ALTER TABLE Student ADD CONSTRAINT<br />
CHECK(EXISTS(SELECT * FROM EingeschriebenIn<br />
WHERE EingeschriebenIn.StudMatrNr = MatrNr));<br />
Damit erhalten wir die folgende Auflösung für den Fall R 1 [X] ⊑ (1,.) R 2 [Y ] für den Fall,<br />
daß Y ein Schlüssel von R 2 ist:<br />
CASCADE RESTRICT NO ACTION NULL/DEFAULT<br />
insert R1<br />
delete R1 – – – –<br />
update R1<br />
insert R2 – – – –<br />
delete R2 foreign key foreign key foreign key foreign key<br />
update R2 foreign key foreign key foreign key foreign key<br />
Im allgemeinen Fall erhalten wir die folgende Auflösung für den Fall R 1 [X] ⊑ (a,.) R 2 [Y ]<br />
:<br />
CASCADE RESTRICT NO ACTION NULL/DEFAULT<br />
insert R1 stored procedure CHECK CHECK DEFER-<br />
RED<br />
delete R1 – – – –<br />
update R1 trigger CHECK CHECK DEFER-<br />
RED<br />
insert R2 – – – –<br />
delete R2<br />
update R2<br />
2. Numerische Beschränkungen card(RHS, LHS) = (0, b)<br />
• Insertion in LHS: kein Effekt<br />
• Insertion in RHS: CASCADE in RHS (Bereinigung (DELETE von Konkurrenten)) oder RE-<br />
STRICT bzw. NO ACTION in RHS oder bewußte Verletzung (SKIP)<br />
• Delete in LHS: keine Auswirkungen (bzw. positive Auswirkungen)<br />
• Delete in RHS: keine Auswirkungen<br />
• Update in LHS: CASCADE in RHS oder RESTRICT bzw. NO ACTION in LHS oder bewußte<br />
Verletzung (SKIP)<br />
• Update in RHS: CASCADE in RHS (Bereinigung (DELETE von Konkurrenten)) oder RE-<br />
STRICT bzw. NO ACTION in RHS oder bewußte Verletzung (SKIP)<br />
Erzwingungsmodus als Hexatupel (λ, i RHS , λ, λ, u LHS , u RHS )<br />
ausreichend ist bereits Tripel (i RHS , u LHS , u RHS )<br />
z.B. card(EingeschriebenIn, Student) = (0, 3) erfordert (i Eing =R,u Student =C,u Eing =R)<br />
.<br />
Spezielle numerische Beschränkungen sind funktionale Abhängigkeiten. Diese können<br />
wie card(RHS, LHS) = (0, 1)-Abhängigkeiten behandelt werden.<br />
• Primärschlüsselabhängigkeiten werden sowohl im Entry als auch Intermediate Level<br />
von SQL’92 sofort erzwungen. Es wird die “Entity-Integrität” gefordert (keine<br />
Nullwerte in diesen Attributen), d.h. es wird gefordert ∀t ∈ R C (t[K]!).<br />
• Sekundarschlüsselabhängigkeiten erlauben einen variablen Erzwingungsmodus: im-
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 34<br />
• SQL-99 fordert bei UNIQUE-Bedingungen den Vergleich nur bei gleichzeitig<br />
voll definierten Teiltupeln:<br />
∀t∀t ′ (t[X]! ∧ t ′ [X]! → t[X] ≠ t ′ [X]).<br />
• ORACLE erzwingt UNIQUE nur für vollständig definierte Teiltupel, d.h.<br />
∀t∀t ′ (t[X] = NULL ∨ t ′ [X] = NULL ∨<br />
((∃A ∈X (t[A]! ∨ t[A]!)) → t[X] ≠ t ′ [X]).<br />
• DB2, Informix, Sybase, MS SQL, Ingres, Sybase Anywhere definieren dagegen<br />
∀t∀t ′ (t[X] ≠ t ′ [X]) .<br />
Realisierung:<br />
• RESTRICT für Insert und Update bei card(RHS, LHS) = (0, 2) in der Relation<br />
EingeschriebenIn :<br />
ALTER TABLE EingeschriebenIn ADD CONSTRAINT<br />
CHECK(NOT EXISTS(<br />
SELECT * FROM EingeschriebenIn E1,<br />
WHERE EXISTS(<br />
SELECT * FROM EingeschriebenIn E2<br />
WHERE E1.StudMatrNr = E2.StudMatrNr<br />
AND E1.SName E2.SName<br />
AND EXISTS(<br />
SELECT * FROM EingeschriebenIn E3<br />
WHERE E<strong>3.</strong>StudMatrNr = E2.StudMatrNr<br />
AND E1.SName E<strong>3.</strong>SName<br />
AND E2.SName E<strong>3.</strong>SName))));<br />
Analog mit Schachtelung der Tiefe b + 1 für card(RHS, LHS) = (0, b).<br />
Besser ist in diesem Fall sogar die Einführung eines Surrogat-Schlüssels für die Relation<br />
EingeschriebenIn, weil bei komplexeren Schlüsseln die Bedingungen E1.SName E<strong>3.</strong>SNa<br />
dann um den gesamten Schlüssel von EingeschriebenIn erweitert werden müssen.<br />
Relationale Integritätsbedingungen: Relationale Integritätsbedingungen werden auf der Basis der<br />
relationalen Algebra formuliert.<br />
Unter der Menge der möglichen relationalen Integritätsbedingungen sind zwei Klassen besonders<br />
zu beachten, da sie in der <strong>Modellierung</strong>spraxis recht häufig benötigt werden:<br />
Inklusionsbeziehungen: Durch Inklusionsbeziehungen werden statische Beziehungen zwischen<br />
Objekten in der <strong>Datenbank</strong> beschrieben. Ihre Transformation kann, wie in den vorherigen<br />
Fällen, in Trigger oder Ausnahmen erfolgen. Da die beiden Transformationen ineinander<br />
überführbar sind, wird hier im folgenden nur die Transformation in eine Ausnahme<br />
betrachtet.<br />
CREATE ASSERTION R inc S<br />
CHECK (<br />
NOT EXISTS (<br />
SELECT * FROM R<br />
WHERE NOT EXISTS (<br />
SELECT S id<br />
FROM S<br />
WHERE S.Y1 = R.X1, . . . , S.Yk = R.Xk<br />
)<br />
)<br />
)<br />
Bei mehreren Inklusionsabhängigkeiten zwischen R und S muss der Name der Ausnahme
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 35<br />
CREATE TABLE EingeschriebenIn (<br />
StudMatrNr char[7] CHECK(<br />
StudMatrNr IN (SELECT MatrNr FROM Student)<br />
),<br />
...<br />
Bis date CHECK ( Von < Bis )<br />
PRIMARY KEY (SName, StudMatrNr)<br />
);<br />
Exklusionsbeziehungen: Die Exklusionsbeziehungen werden analog zu den Inklusionsbeziehungen<br />
in eine Ausnahme transformiert. Hierzu ist zu prüfen, das es kein Element in R<br />
gibt, zu dem ein passendes Element in S existiert. Dies wird durch den SQL Ausdruck<br />
CREATE ASSERTION R_exclus_S<br />
CHECK (<br />
NOT EXISTS (<br />
SELECT * FROM R<br />
WHERE EXISTS (<br />
SELECT S id<br />
FROM S<br />
WHERE S.Y1 = R.X1, . . . , S.Yk = R.Xk<br />
)<br />
)<br />
)<br />
comp(R, R i ) = (m, n)<br />
CREATE TRIGGER comp_R_i_R_insert<br />
AFTER INSERT ON R_i<br />
REFERENCING NEW TABLE inserted<br />
WHEN ( ( SELECT COUNT(*) FROM R, inserted<br />
WHERE R.R i = inserted.R_i_id ) < m ) OR<br />
( SELECT COUNT(*) FROM R, inserted<br />
WHERE R.R_i = inserted. R_i_id ) > n ) )<br />
ROLLBACK TRANSACTION<br />
CREATE TRIGGER comp_R_i_R_update<br />
AFTER UPDATE OF R_i id ON R_i<br />
REFERENCING NEW TABLE inserted<br />
REFERENCING OLD TABLE deleted<br />
WHEN ( ( SELECT COUNT(*) FROM R, deleted<br />
WHERE R.R_i = inserted.R_i_id ) < m ) OR<br />
( SELECT COUNT(*) FROM R, inserted<br />
WHERE R.R_i = inserted. R_i_id ) > n ) )<br />
ROLLBACK TRANSACTION<br />
CREATE TRIGGER comp R_R_i_insert<br />
AFTER INSERT ON R<br />
REFERENCING NEW TABLE inserted<br />
WHEN ( ( SELECT COUNT(*) FROM R_i, inserted<br />
WHERE inserted.R_i = R_i. R_i_id ) < m ) OR<br />
( SELECT COUNT(*) FROM R, inserted<br />
WHERE inserted.R_i = R_i. R_i_id ) > n ) )<br />
ROLLBACK TRANSACTION<br />
CREATE TRIGGER comp_R_R_i_update
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 36<br />
WHERE deleted.R_i = R_i.R_i_id ) < m ) OR<br />
( SELECT COUNT(*) FROM R_i, inserted<br />
WHERE inserted.R_i = R_i. R_i_id ) > n ) )<br />
ROLLBACK TRANSACTION<br />
CREATE TRIGGER comp_R_R_i_delete<br />
AFTER DELETE ON R<br />
REFERENCING OLD TABLE deleted<br />
WHEN ( ( SELECT COUNT(*) FROM R_i, deleted<br />
WHERE deleted.R_i = R_i.R_i_id ) < m ) )<br />
ROLLBACK TRANSACTION<br />
<strong>3.</strong><strong>3.</strong>5 Übersetzung in Netzwerk- und hierarchische Modelle<br />
Netzwerkmodell<br />
Zwei Konstrukte: Recordtyp, Settyp<br />
stark implmentationsabhängig trotz Codasyl-Standards<br />
Recordtyp : Name, Menge von Attributen mit ihren Wertebereichen<br />
Attribute<br />
• einfache Attribute<br />
• mengenwertige Attribute: Vektor<br />
• zusammengesetzte mengenwertige Attribute: Wiederholgruppe<br />
Settyp : beschreibt 1-m-Beziehung zwischen Recordtypen<br />
Records, die mit mehreren anderen Records in Beziehung stehen: Owner<br />
die in Beziehung gesetzten: Member<br />
hat eigenen Namen und keine Attribute<br />
Settypen können auch mehrere Membertypen haben, meist wird jedoch Zweistelligkeit der Beziehung<br />
hervorgehoben und nur jeweils ein Membertyp zugelassen; damit dann graphische Repräsentation<br />
durch Bachman-Diagramme<br />
Settyp ist kein Mengentyp !! Codasyl empfiehlt Liste !!<br />
Professor<br />
hält<br />
✲<br />
<strong>Vorlesung</strong><br />
Ein Pfeil wird von A nach B gezeichnet, wenn eine partielle Funktion von B C nach A C existiert.<br />
entgegen der Pfeilrichtung<br />
Settyp (Member-Records eines Sets) wird kann auf folgende Art und Weise implementiert:<br />
• entweder first/last: neuer Record stets als erstes/letztes Mitglied einer Set-Occurrence<br />
eingefügt<br />
• oder next/prior: Einfügen jeweils vor bzw. nach laufendem Pointer (z.B. letzte Anfrag)<br />
• oder System Default: wird durch System übernommen<br />
• oder Sortiert: nach Werten vorgegebener Attribute
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 37<br />
erlaubt ist jedoch zusätzlich:<br />
ein Record kann mehrfach Owner-Record verschiedener Settypen sein<br />
ein Record kann gleichzeitig Member-Record verschiedener Settypen sein<br />
es können gleichzeitig mehrere Settypen zwischen gleichen Paaren von Recordtypen gebildet werden<br />
Abfederung der Inflexibilität durch:<br />
Set-Insertion-Option Einfügen eines neuen Member-Records vom Typ R<br />
• Automatisch: falls R Membertyp in Settyp S, dann neuer Record auch in S eingefügt<br />
• Manual: Einfügen in S ist Programmierersache<br />
Set-Retention-Option Member-Record vom Typ R in S löschen<br />
• Optional: Record kann ohne Mitgliedschaft in Set-Occurrence in DB existieren<br />
• Mandatory: Record muß in eine Occurrence eingebunden sein<br />
• Fixed: Record R muß in S verbleiben<br />
Da im obigen Schema <strong>Vorlesung</strong> kein Attribut haben darf:<br />
• entweder Hinzunahme der <strong>Vorlesung</strong>sattribute zum Professor<br />
• oder<br />
Übersetzung von ER-Schemata in Netzwerkdiagramme<br />
Verschiedene Strukturen müssen aufgelöst werden:<br />
• Relationship-Typen höherer Ordnung (> 1) bzw. Arität (> 2)<br />
• Relationship-Typen mit eigenen Attributen<br />
• rekursive Relationship-Typen<br />
• IsA-Relationship-Typen<br />
• z.T. 1-1-Beziehungen<br />
• Cluster<br />
Folgende Strukturen können im wesnetlichen erhalten bleiben:<br />
• Entity-Typen mit genesteten Attributen<br />
• attributlose, binäre 1:n Relationshiptypen<br />
Übersetzung der Problemfälle<br />
• 1-1-Beziehungen ohne Attribute: entweder Zusammenfassen zu einem Typ oder Bildung eines<br />
Settyps für einen der beiden Typen<br />
• m-n-Beziehungen bzw. nicht-binaäre Beziehungen: Einführen mehrerer Settypen und eines<br />
Membertyps (Kett-Typ) mit Set-Beziehungen zwischen diesem und dem Ownertypen<br />
Attribute werden dem Kett-Typen zugeordnet<br />
• IsA-Beziehungen: wie 1-1-Beziehungen in umgekehrter Richtung<br />
Unterscheidung total/partiell geht verloren; muß über DML gelöst werden<br />
• Rekursive Typen: Duplizierung des Recordtyps mit Umbenennung oder Einbeziehung eines<br />
Dummy-Member-Typs
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 38<br />
Person<br />
IsA<br />
IsA<br />
❄<br />
Professor<br />
✠<br />
Student<br />
✠ betreut<br />
hält<br />
❘<br />
<strong>Vorlesung</strong><br />
besucht wird-besucht<br />
❘<br />
✠<br />
Stud-Vorles<br />
<strong>Vorlesung</strong><br />
<strong>Vorlesung</strong><br />
<strong>Vorlesung</strong><br />
setzt<br />
voraus IsA<br />
❄ ❄<br />
Dummy<br />
wird vorausgesetzt<br />
von IsA<br />
✻<br />
❄<br />
Vorausges<br />
<strong>Vorlesung</strong><br />
✻ wird vorausgesetzt<br />
von<br />
✻<br />
IsA<br />
Vorausges<br />
<strong>Vorlesung</strong><br />
Optimierung der Übersetzung durch entsprechende ER-Normalisierung<br />
Ersetzung der genesteten Strukturen durch flache:<br />
Mengennestung wird durch Einführung eines neuen Kett-Typs aufgehoben mit entsprechender Set-<br />
Typen-Einführung<br />
Tupelnestung wird verflacht<br />
Integritätsbedingungen sind Programmiereraufgabe bis auf:<br />
Domain-Bedingungen: mit CHECK-Klausel<br />
Intrarecord-Bedingung: duplicates are not allowed for < Attribut ><br />
ist aber keine Schlüsselbedingung<br />
Interrecord-Bedingung: gleichbenannte Attribute können über CHECK getestet werden (damit referentielle<br />
Integrität möglich)<br />
Hierarchisches Modell<br />
alle Daten durch Baumstrukturen dargestellt<br />
<strong>Datenbank</strong> durch Wald strukturiert<br />
Beziehungen sind 1:1 oder 1:n<br />
Wurzel ist nicht optional
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 39<br />
<strong>3.</strong>4 Normalisierung<br />
<strong>3.</strong>4.1 Gründe zur Normalisierung<br />
Probleme der <strong>Modellierung</strong>.<br />
Die <strong>Datenbank</strong>spezifikation ist gezeichnet von<br />
<strong>Modellierung</strong>sbeschränkungen durch die<br />
gewählte Spezifikationssprache, in der ggf. die Anwendung nur mit komplexen Spezifikationen<br />
und verwickelten Schemata unterstützt wird,<br />
gewählte Spezifikationsmethodik, die ggf. zu falschen Spezifikationsurteilen führt, den Kontext<br />
der <strong>Modellierung</strong> und die gewählte Referenzmodellierung<br />
unterlegte Spezifikationstheorie mit Modalität, Gewißheit und Schärfe der <strong>Modellierung</strong>surteile,<br />
sowie die Urteilsart und<br />
Wahl des Ausschnittes der Realität, der modelliert wird<br />
Implementationsbeschränkungen z.B. aufgrund der Verarbeitung im DBMS. Typische Beschränkungen<br />
sind:<br />
Beschränkungen des SQL-Dialektes<br />
Beschränkungen der Integritätspflege z.B. durch Zulassung von wenigen Integritätsbedingungen<br />
wie<br />
Wertebereichsbeschränkungen<br />
Schlüsselbeschränkungen und<br />
referentielle Integritätsbedingungen<br />
Beschränkungen des DBMS insbesondere Speicherverwaltung und Transaktionsverarbeitung<br />
Verhalten von semantisch sinnvollen Einheiten, das (nicht) berücksichtigt wird und durch Dekomposition<br />
ggf. erschwert wird.<br />
Optimierungserfordernisse.<br />
Probleme bei der Optimierung von <strong>Datenbank</strong>anwendungen sind:<br />
(A) Redundanzprobleme durch schwierige oder ggf. auch Nichtunterstützung kontrollierter Redundanz<br />
(B) Informationsblockierung aufgrund der Informationskapazität des Schemas<br />
Insert-Anomalie durch rigide Erzwingung von einfügebeschränkenden Integritätsbedingungen<br />
(C) Informationsverluste von DB-Modifikation z.B.<br />
Delete-Anomalie: Es werden Teil-Informationen in Objekten, die eine eigenständige Bedeutung<br />
haben vernichtet<br />
(D) Evolutionsempfindlichkeit und Instabilität bei Veränderungen (Evolutionsresistenz bzw. Evolutionsrobustheit<br />
erfordert eine vollständig andere Architektur von Schemata. Dazu existiert bis<br />
auf die TIS@CAU-Ansätze kein Lösungsvorschlag.)<br />
(E) Unterschiedliche Abstraktionen in partieller Koexistenz z.B. auch Sichten<br />
(F)Performanzprobleme durch Spezifika der Anwendung, durch falsche Strukturierung (ggf. auch<br />
bei Wahl der falschen Normalisierung), komplexe oder verwobene Datenstrukturen.
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 40<br />
Update-Anomalie, bei der eine Einobjektoperation zu einer Bulkoperation wird, z.B. ein<br />
table scan erfordert, damit die Architektur von DBMS schon aufgrund der beschränkt<br />
vorhandenen Ressourcen im Puffer- und Cache-Bereich grausam überfordert<br />
Anfragefehlverhalten aufgrund von der Berechnungskomplexität priorisierter Anfragen<br />
Wird aufgehoben durch Zusammenführung von Strukturen (Denormalisierung):<br />
Vorteile der Denormalisierung:<br />
Erhöhung der Berechnungsgeschwindigkeit im Retrieval<br />
Blockierung der Separation semantisch sinnvoller Einheiten und damit Vermeidung von<br />
zusätzlichen Verbunden und Reduktion von Fremdschlüsseln<br />
Vorausberechnung und Mitführung abhängiger Daten mit redundanten Attributen und<br />
abgeleitete Daten<br />
Reduktion von notwendigen Indizes<br />
Reduktion der Anzahl von Tabellen<br />
Einführung von Surrogatattributen zur Vereinfachung der Identifikation und von Fremdschlüsseln<br />
Nachteile der Denormalisierung<br />
Update slow down und DBMS-internes slow down<br />
hohe Abhängikeit von der Anwendung und Inflexibilität bei Evolution<br />
hohe Redundanz ohne einfache Pflegemechanismen<br />
(G) Schwierige Pflege und Modifizierbarkeit von Daten<br />
Ansatz zur Messung der Qualität von Schemata.<br />
Gegeben sei eine Menge M aller möglichen Typen einer Anwendung. Diese Menge kann von einer<br />
minimalen Menge erzeugt werden. Es können nun Teilmengen von M betrachtet werden.<br />
Vollständige Teilmengen erlauben die Ableitung aller anderen Typen in M.<br />
Korrekte Teilmengen besitzen keine Typen, die mit anderen Typen im Widerspruch stehen.<br />
Unter den vollständigen und korrekten Teilmengen F ULL(P(M)) können wir die optimalen Schemata<br />
OP T IMAL(P(M)) herausschälen. Es kann nun das gefundene Schema S dagegen bewertet<br />
werden. Dazu werden die minimalen Abstände gemessen:<br />
NumbOfConcept(S) − NumbOfErr(S, S ′ )<br />
correctness OP T (S) = max S ′ ∈OP T IMAL(P(M))<br />
Concept(S ′ )<br />
NumbOfConcept(S) − NumbOfDifferences(S, S ′ )<br />
completeness OP T (S) = max S ′ ∈OP T IMAL(P(M))<br />
Concept(S ′ )<br />
Diese beiden Maße können kombiniert werden zu:<br />
mit<br />
SQ = (β2 + 1.0) × completeness OP T (S) × correctness OP T (S)<br />
β 2 × completeness OP T (S) + correctness OP T (S)<br />
β = 1: Korrektheit und Vollständigkeit gleichwertig<br />
β = 0: nur Korrektheit bewertet<br />
β = ∞: nur Vollständigkeit bewertet<br />
Diese Maße stehen in Korrelation zu Maßen aus dem Information Retrieval<br />
Präzision zum Messen der Korrektheit (F: gefunden; R: relevant)
• verlustfrei: gleiche Daten repräsentiert<br />
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 41<br />
Recall zum Messen der Vollständigkeit<br />
Fallout zum Messen der Inkorrekheit einer Funktion<br />
<strong>3.</strong>4.2 Allgemeines Herangehen<br />
|F(q, D 1 )) ∩ R Q S 1 ,S 2<br />
(q, D 1 )|<br />
|R Q S 1 ,S 2<br />
(q, D 1 )|<br />
|F(q, D 1 )) \ R Q S 1 ,S 2<br />
(q, D 1 )|<br />
|ALL \ R Q S 1 ,S 2<br />
(q, D 1 )|<br />
Zerlegung der <strong>Datenbank</strong>anwendung in Komponenten.<br />
Dieser Ansatz stellt eine Eigenentwicklung der TIS@CAU-Gruppe dar, basiert auf dem Herausschälen<br />
von Komponenten und einer Entwicklung einer Kollaborationsarchitektur zwischen den Komponenten.<br />
Herausfinden von verbotenen Teilstrukturen.<br />
2. Normalform Teilschlüssel implizieren nicht Nicht-Schlüsselattribute<br />
<strong>3.</strong> Normalform jedes Nicht-Schlüssel-Attribut darf nur direkt von einem Schlüssel abhängen (kein<br />
transitiver Schluß)<br />
Boyce-Codd-Normalform jede nicht-triviale funktionale Abhängigkeit ist eine Schlüsselabhängigkeit<br />
4. Normalform jede geltende mehrwertige Abhängigkeit ist ableitbar aus den geltenden Schlüsselabhängigkeiten<br />
5. Normalform jede geltende Verbundabhängigkeit ist ableitbar aus den geltenden Schlüsselabhängigkeiten<br />
Einfüge-, Lösch- und Update-Anomalien treten genau dann nicht auf, wenn nur funktionale Abhängigkeiten<br />
gelten und Schema in BCNF ist<br />
Separation von verschiedenen Gesichtspunkten.<br />
Schema <strong>Datenbank</strong> Anfragen Anfrageergebnisse<br />
zeitunabhängige Beschreibung<br />
zeitabhängige Beschreibung<br />
Entwurf durch Modularisierung und Separation von Aspekten<br />
Redundanzarmut und günstiges Verhalten (z.B. keine Anomalien (insert, delete, update erfordern<br />
Nacharbeit)) durch Verbot von Teilstrukturen und Trennung von Gesichtspunkten<br />
R = (R 1 , ..., R m , Σ 0 ) , R i = (U i , Σ i ), Σ = ⋃ m<br />
i=1 Σ i ∪ Σ 0 verbotene Teilstrukturen<br />
durch Normalisierung<br />
als adäquate Dekomposition T und Wiederherstellungsoperation f<br />
T (R i , Σ i ) = (R i,1 , ..., R i,k , Σ T i )<br />
R j i = (U i,j, Σ i,j )<br />
2 Eigenschaften
Boyce-Codd-Normalform verboten ist folgende Eigenschaft in Σ i :<br />
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 42<br />
• Unabhängige Pflege der Teilstrukturen<br />
Damit erhalten wir 4 Teilaufgaben:<br />
1. Semantische Eigenschaften = syntaktische Eigenschaften<br />
2. Beweis der obigen =<br />
<strong>3.</strong> Algorithmen zur Gewinnung<br />
4. geringe Kosten<br />
Formalisierung von Heuristiken<br />
Separation Einheitliches Verhalten Ableit. von Gesichtspunkten<br />
Aufgabe 1 : Aufgabe 1:<br />
( keine verbotenen Teilstrukturen) (semantische Forderungen)<br />
- 3NF - Verbundpfade eindeut. - sichere Sichteninstanzunterstütz.<br />
- BCNF -sichere Sichtenanfrageunterst.<br />
- 4NF<br />
- 5NF (syntaktische Forderungen) - für FD’s : join support<br />
- referent. NF - γ-azyklisch (X 1 , ..., X n ) ∈ Σ +<br />
- unique-key NF - α-azyklisch ∪F i ) + ⊇ F<br />
Beziehungen<br />
- BCNF & Verbundunterstützung sind compatibel (Dekomp.)<br />
- 3NF und sichere Verbundunterstützung sind compatibel (Synthese)<br />
γ-azyklisch gdw. Verbundpfade sind wesentlich eindeutig<br />
Optimierung zur Entwurfszeit<br />
Aufgabe 4: Syntaktische Eigenschaften garantieren geringe Kosten<br />
Speicherung Anfragen update<br />
-Normalformen γ-Azykliz. ohne Referenzen<br />
- Verbundbäume monoton 1 Schlüssel<br />
- Projektion über Überdeck. BCNF<br />
von Verbunden<br />
α-Azykliz.<br />
- Existenz von<br />
monotonen Verbundbäumen<br />
<strong>3.</strong>4.3 FD-basierte Normalformen für das relationale Modell<br />
Üblicher Zugang:<br />
T ist definiert durch eine Verbundabhängigkeit und Projektion und f ist der entsprechende Verbund<br />
möglich ist ebenso: Horizontale Dekompositionsabhängigkeit, Partition und Vereinigung<br />
Verbotene Teilstrukturen definiert durch verschiedene Normalformen :<br />
3NF verboten ist folgende Eigenschaft in Σ i :<br />
Z → {A} ∈ Σ + i , A ∉ Z, A Nichtschlüsselattribut (d.h. in keinem Schlüssel von R i), Z →<br />
U i ∉ Σ + i<br />
Nachteil: entscheidbar in NP
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 43<br />
4NF verboten ist folgende Eigenschaft in Σ i :<br />
Z →→ X ∈ Σ + i , X ⊈ Z, Z → U i ∉ Σ + i<br />
Strenge Project-Join-NF verboten ist folgende Eigenschaft in Σ i :<br />
(Y 1 , ..., Y k ) ∈ Σ + i<br />
, {X → U i ∈ Σ + i } ̸|= (Y 1, ..., Y k )<br />
5NF verboten ist folgende Eigenschaft in Σ i :<br />
(Y 1 , ..., Y k ) ∈ Σ + i<br />
, ∃j : Y j → U i ∉ Σ + i<br />
Project-Join-NF verboten ist folgende Eigenschaft in Σ i :<br />
(Y 1 , ..., Y k ) ∈ Σ + i<br />
, {X → U i ∈ Σ + i } ̸|= (Y 1, ..., Y k )<br />
Überstrenge Project-Join-NF verboten ist folgende Eigenschaft in Σ i :<br />
(Y 1 , ..., Y k ) ∈ Σ + i<br />
, ∀X → U i ∈ Σ + i<br />
: {X → U i } ̸|= (Y 1 , ..., Y k )<br />
InklusionsNF verboten ist folgende Eigenschaft in Σ i :<br />
R i [X] ⊆ R j [Y ] ∈ Σ + und Y → U j ∉ Σ +<br />
Referentielle Normalform<br />
genau ein Schlüssel verboten ist folgende Eigenschaft in Σ i :<br />
es existieren zwei verschiedene mininale Schlüssel<br />
Vorteil: entscheidbar in P<br />
Domain-Schlüssel-Abhängigkeit (DKNF) verboten ist die folgende Teilstruktur für die Menge Σ i,K<br />
der Schlüssel- und Domainabhängigkeiten von Σ + i<br />
:<br />
α ∈ Σ + i<br />
, nichttrivial und Σ i,K ̸|= α<br />
Achtung: Verschiedene Bücher verwenden davon abweichende Notationen.<br />
Afunktionale und min-max-Abhängigkeiten<br />
afunktionale Abhängigkeit: R t |= X −→‖ Y falls für alle ν ∈ R t existiert µ ∈ R t mit ν = X µ und<br />
ν ≠ Y µ<br />
zur horizontalen Dekomposition von Relationen<br />
R t = R t 1 ∪ Rt 2 mit<br />
• ∅ = R t 1 ∩ Rt 2<br />
• R t 1 |= X → Y<br />
• R2 t |= X −→‖ Y<br />
min-max-Abhängigkeiten geben Wiederholfaktor an und gleichzeitig Begrenzung für Redundanz<br />
Nichtnull-Abhängigkeiten<br />
Ableitbarkeit von Aspekten<br />
Semantische Forderungen der relationalen Praxis
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 44<br />
Sichere Unterstützung von Sichten wenn =<br />
Sichtenanfrage-Unterstützung ∀Q ∈ Query(V, R)∃P ∈ Query(U, R) : Q(V t ) = P (R t )<br />
Charakterisierung der semantischen Forderungen<br />
Sichtenbehandlung Sichtenanfrage-Unterstützung gdw. Unterstützung von Sichten<br />
im positiven Fall sogar effizient<br />
sichere Unterstützung von Sichten gdw. ( ⋃ F i ) + ⊇ F und (U 1 , ..., U m ) ∈ Σ +<br />
Unique-Key Hat ein Relationenschema genau einen minimalen Schlüssel, dann ist es genau<br />
dann in BCNF, wenn es in 3NF ist.<br />
DKNF - Anomalien Ein Relationenschema hat genau dann keine Insert und Delete anomalien,<br />
wenn es in DKNF ist.<br />
NF-Beziehungen Überstrenge PJNF ⇒ strenge PJNF<br />
strenge PJNF ⇒ PJNF<br />
PJNF ⇒ 4NF<br />
4NF ⇒ BCNF<br />
BCNF ⇒ 3NF<br />
||dom(A)|| ≥ 2 : DKNF ⇒ 4NF<br />
Alle domain-Abhängigkeiten lassen mindestens k Werte zu für k = max.-Komponenten-<br />
Anzahl in JD von Σ, die eine Überdeckung der Dekomposition darstellen. Dann DKNF<br />
⇒ PJNF<br />
Eigenschaften von Integritätsbedingungen:<br />
Entscheidbarkeit der Implikationseigenschaft<br />
• entscheidbar für tupelerzeugende und gleichungserzeugende Abhängigkeiten<br />
• nicht entscheidbar für eingebettete JD’s<br />
• nicht entscheidbar für eingebettete MVD’s<br />
• nicht entscheidbar FD’s und ID’s<br />
Axiomatisierbarkeit von Klassen von Integritätsbedingungen<br />
• axiomatisierbar FD’s ∪ MVD’s<br />
• nicht axiomatisierbar für FD’s und Inklusionsabh.<br />
• axiomatisierbar für tupel- und gleichungserzeugende Abhängigkeiten<br />
• nicht axiomatisierbar für JD’s<br />
Komplexität des Implikationsproblemes<br />
• 3NF ist NP-complete<br />
• ‘Ist A Schlüsselattribut’ ist NP-vollständig<br />
• BCNF ist polynomial<br />
• Ein-Schlüssel-Problem ist polynomial<br />
{A ∈ U i |U i \ {A} ∉ Σ i } −→ U i ∈ Σ i<br />
Algorithmen Normalisierung in 2 verschiedenen Herangehensweisen<br />
Analyse allgemeines Herangehen: wenn Schema nicht redundanzfrei, dann zerlege das Schema<br />
in 2 (oder mehrere) Teilschemata<br />
Beispiel:
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 45<br />
R 1,1 = ({SSN, Stadt, Alter, Sex}, {SSN → Stadt, SSN → Alter, SSN → Sex})<br />
R 1,2 = ({Stadt, Land}, {Stadt → Land})<br />
R 2 = ({Land, Staat}, {Land → Staat})<br />
Nachteile: Erhaltung der IC’s ist meist schwierig zu kontrollieren<br />
Weiteres Beispiel:<br />
Ort, Bundesland, Ministerpräsident, Einwohneranzahl<br />
Regierung: Bundesland<br />
Städte: Ort, Bundesland, Einwohneranzahl<br />
Hintergrund: Dekomposition nach Blattabhängigkeiten<br />
Synthese allgemeines Herangehen: Generierung einer minimalen Überdeckung aller IC’s und<br />
Synthese nach dieser minimalen Überdeckung von Schemata<br />
Beispiel:<br />
R wie oben<br />
minimale Überdeckung aller Abhängigkeiten : {SSN → Stadt, Stadt → Land, Land →<br />
Staat, SSN → Alter, SSN → Sex})<br />
Gruppenbildung: {SSN, Stadt, Alter, Sex} , {Stadt, Land}, {Land, Staat}<br />
Hinzufügen eines Schlüsselschemas<br />
R 1 = ({SSN, Stadt, Alter, Sex}, {SSN → Stadt, SSN → Alter, SSN → Sex})<br />
R 2 = ({Stadt, Land}, {Stadt → Land})<br />
R 3 = ({Land, Staat}, {Land → Staat})<br />
3NF-Algorithmus<br />
Input: Menge von funktionalen Abhängigkeiten für einen Typ<br />
Output: ein normalisiertes Schema<br />
Bestimmung einer kanonischen Überdeckung einer Menge von funktionalen Abhängigkeiten<br />
Σ c heist kanonische Uberdeckung von ΣF, wenn die folgenden drei Kriterien erfüllt<br />
sind:<br />
• Σ + c = Σ + c<br />
• . In Σ c existieren keine FDs , die überflüßige Attribute enthalten. D.h. es muß<br />
folgendes gelten:<br />
• ∀A ∈ X ∧ X → Y ∈ Σ c : Σ c \ {X → Y } ∪ {X \ {A} → Y } ̸|= Σ c<br />
• ∀B ∈ Y ∧ X → Y ∈ Σ c : Σ c \ {X → Y } ∪ {X → Y \ {B}} ̸|= Σ c<br />
• Jede linke Seite einer funktionalen Abhängigkeit in Σ c ist einzigartig. Dies kann<br />
durch sukzessive Anwendung der Vereinigungsregel auf FDs der Art X → Y, X →<br />
Y ′ erzielt werden, so dass die beiden FDs durch X → Y ∪ Y ′ ersetzt werden.<br />
Berechnung der kanonischen Überdeckung<br />
• Führe fur jede FD X → Y ∈ Σ c die Linksreduktion durch, d.h.:<br />
Überprüfe fur alle A , ob A überflüssig in X → Y ist, d.h. ob A ∈ X + Sigma c<br />
, X \<br />
{A} gilt. Falls dies der Fall ist, ersetze X \ {A} → Y .<br />
• Führe für jede (verbliebene) FD die Rechtsreduktion durch.<br />
Überprüfe fur alle B, ob B überflüssig ist, d.h. ob<br />
∀B ∈ Y ∧ X → Y ∈ Σ c : Σ c \ {X → Y } ∪ {X → Y \ {B}} |= Σ c gilt.<br />
Falls dies der Fall ist, ist B auf der rechten Seite überflüssig und kann eliminiert<br />
werden.<br />
• Entferne die FDs der Form X → ∅, die im 2. Schritt möglicherweise entstanden<br />
sind.<br />
• Fasse mittels der Vereinigungsregel FDs der Form X → Y 1 ... X → Y m zu<br />
X → Y 1 ∪ Y m .<br />
Konstruktion einer Dekomposition bestehend aus 2 (ggf. leeren) Teilen<br />
• Für jede funktionale Abhängigkeit von Σ c wird ein Schema angelegt.<br />
• Ist kein X mit X → Y m zu X → Y 1 ∪ Y m ∈ Σ c ein Schlüssel von R, dann wird
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 46<br />
Eigenschaft des Algorithmus: (SSA)<br />
Proposition 1 Es werden alle Abhängigkeiten erhalten.<br />
Proposition 2 Das Resultat ist ein Schema, in dem alle Relationenschemata in dritter<br />
Normalform sind.<br />
Überblick über Normalisierungsalgorithmen<br />
Author Strategie NF IC Relships Komplex.<br />
Bernstein Synthese 3NF FD CR polyn.<br />
Fagin Analyse 4NF FD+MVD LD exp.<br />
Biskup/D/B Synthese 3NF FD LD+CR polyn.<br />
Ullman Analyse 4NF FD+MVD LD exp.<br />
Tsou/Fischer Analyse 4NF FD+MVD LD polyn.<br />
Zaniolo/Melkanoff Analyse 3NF FD+MVD LD+CR expon.<br />
LD = lossless decomposition ; CR = constraint representation<br />
Theorem 1 Die Zerlegung π X∪Y (R C ) und π X∪Z (R C ) ist verlustlos für disjunkte Mengen<br />
X, Y, Z falls π X∪Y ∪Z (R C ) = π X∪Y (R C ) ✶ π X∪Y (R C ) gilt.<br />
Proposition 3 Gilt die funktionale Abhängigkeit X → Y in R C , dann ist die Zerlegung π X∪Y \X (R C )<br />
und π X∪U\(X∪Y ) (R C ) verlustlos.<br />
∀(U, F )∃(X 1 , ..., X m ) : (U, F ) unterstützt (X i , F i ) mit Verbund für Anfragen und alle (X i , F i )<br />
sind in BCNF<br />
∀(U, F )∃(X 1 , ..., X m ) : (U, F ) unterstützt sicher (X i , F i ) mit Verbund für Anfragen und alle<br />
(X i , F i ) sind in 3NF<br />
Leider werden BCNF nicht durch einen Synthesealgorithmus erzeugt. Es existiert jedoch die<br />
Beobachtung 4.<br />
Ursache von Nicht-BCNF-fähigen Schemata: Überladung von Attributen (Makowsky)<br />
Behebung: Aufspleißen des Attributes<br />
Ort, PLZ, Straße<br />
{ Ort, Straße } → {P LZ}<br />
{P LZ} → {Ort}<br />
Überladenes Attribut, das zerlegt werden kann<br />
PLZ Ortsbereich, PLZ Zustellbezirk<br />
{ Ort, Straße } → {P LZ Zustellbezirk}<br />
{P LZ Ortsbereich} ↔ {Ort}<br />
Speicherkosten Ein Schema S ist in xNF gdw. jede Dekomposition T von S hat für jede DB S t<br />
komplexere Darstellung, d.h.<br />
size(S t ) ≤ size(T (S t ))<br />
Update-Kosten ∀R ∀X ⊆ U i (X → U i ∈ Σ + )∀(R1 t , ..., Rt m) ∀{t} ∈ SAT (R i )<br />
{t}, Ri+1 t , ..., Rt m) ∈ SAT (R)<br />
gdw. R i referenziert nicht, hat genau einen Schlüssel und ist in BCNF<br />
(R t 1 , ..., Rt i−1 , Rt i ∪<br />
Konsistenz von Schemata Verbundabhängigkeit heißt m-zyklisch, wenn äquivalent zu einer Menge<br />
von Verbundabhängigkeiten mit höchstens m Komponenten jeweils.<br />
2-zyklisch = azyklisch
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 47<br />
Regel 2: falls Y i ⊆ Y j , i ≠ j : (Y 1 , ..., Y m ) ⇒ (Y 1 , .., Y i−1 , Y i+1 , ..., Y m )<br />
(Y 1 , ..., Y m ) ⇒ ∗ λ gdw. azyklisch<br />
Schema R heißt k-konsistent, wenn für beliebige j 1 , ..., j k ∈ {1, ..., m} und i ∈ {j 1 , ..., j k }<br />
gilt: (R j1 ✶ ... ✶ R jk )[R i ] = R i<br />
R ist konsistent, wenn m-konsistent<br />
R ist k-konsistent gdw. (U 1 , ..., U m ) k-zyklisch ist<br />
ein Schema ist paarweise konsistent, genau dann wenn für alle i,j R i [U i ∩ U j ] ⊆ R j [U i ∩ U j ]<br />
Hypergraphen<br />
zur Darstellung der Join-Verbindung von Attributen in Schemata<br />
damit kann für Attribute auch eindeutiges Verständnis von Gesichtspunkten ausgedrückt werden<br />
Universalrelationen-Annahme (universal relation schema assumption) : Jedes Attribut ist bzgl. seiner<br />
Bedeutung eindeutig unabhängig vom Schema definiert.<br />
Wenn erfüllt, dann kann gesamte <strong>Datenbank</strong> als eine Universalrelation (evt. aufgefüllt mit Nullwerten<br />
- schwache Universalrelation) aufgefaßt werden.<br />
Basiszusammenhang-Annahme (basic connection assumption): Jede Attributteilmenge X ⊆ U<br />
hat genau eine Bedeutung im Schema.<br />
damit Anfragebedeutung durch Attributmenge eindeutig bestimmt<br />
Ein-Geschmack-Annahme (unique flavour assumption): für jeden Benutzer und jede Attributmenge<br />
in einem relationalen Ausdruck und jede <strong>Datenbank</strong> R t ist jedem Tupel unabhängig von der<br />
Art seiner Erzeugung eine Bedeutung zugeordnet<br />
Arten von Zyklen in Hypergraphen<br />
Pfade im Hypergraphen deuten auf die Komplexität der Berechnung von Anfragen hin<br />
je einfacher der Pfad ist, umso einfacher wird die Berücksichtigung von Nebenbedingungen<br />
purer Zyklus Folge Y 1 , ..., Y k mit Y i ∩Y i+1modk ≠ ∅ 1 ≤ i ≤ k und Y i ∩Y j ∩Y l = ∅ für verschiedene<br />
i,j,l<br />
für Attribute gibt es mindestens zwei verschiedene verbindende Pfade<br />
z.B. ({A, B}, {B, C}, {C, D}, {D, E}, {E, A})<br />
damit zwischen A, C zwei verbindende Pfade, die auch verschiedene Zusammenhänge formalisieren<br />
können<br />
γ-Zyklus Y 1 , Y 2 Y 3 mit Y 1 ∩ Y 2 ∩ Y 3 ≠ ∅ , (Y 1 ∩ Y 2 ) \ Y 3 ≠ ∅ , (Y 2 ∩ Y 3 ) \ Y 1 ≠ ∅<br />
dann existieren für Attribute in (Y 2 ∩ Y 3 ) \ Y 1 ≠ ∅ und (Y 1 ∩ Y 2 ) \ Y 3 ≠ ∅ wieder 2 verbindende<br />
Pfade<br />
Beispiel: ({A, C, H}, {B, C, K}, {A, B, C, L})<br />
zwei verschiedene Pfade zwischen A, B, die evt. verschiedene Zusammenhänge formalisieren<br />
Damit ist Schema<br />
γ-azyklisch falls weder purer noch γ-Zyklus existiert<br />
α-azyklisch wenn obiger Reduktionsalgorithmus von Graham λ liefert<br />
Ein Schema ist gd. γ-azyklisch, wenn Join monoton ist, bzw. wenn verlustlose Projektionen (join und<br />
project sind vertauschbar) existieren bzw. gdw. eindeutige Verbindungen existieren .<br />
d.h. Verbundabhängigkeit des Schemas impliziert alle eingebetteten Verbundabhängigkeiten
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 48<br />
C<br />
✻<br />
A<br />
✛<br />
R<br />
✲<br />
B<br />
A<br />
✛<br />
R2<br />
Abbildung 9: Ein Beispielschema<br />
R2 ✲<br />
C<br />
✛<br />
R3<br />
C<br />
✛<br />
❄<br />
R1 ✲<br />
Schema 2<br />
B<br />
❄<br />
A<br />
✛ R1 ✲<br />
Schema 3<br />
❄<br />
B<br />
C<br />
C<br />
✛<br />
✛<br />
R1 ✲ A ✛ R2 ✲<br />
Schema 1’<br />
R1 ✲ A ✛ R2 ✲<br />
Schema 1<br />
C<br />
C<br />
Abbildung 10: Die Zerlegung des Beispielschemas<br />
Klassische Dekompositionstheorie ergibt bereits eine Reihe von Schemazerlegungen, z.B. das Schema<br />
in Bild ?? kann in eines der Schemata in Bild ?? zerlegt werden.<br />
Die Zerlegung hängt von der Gültigkeit von Integritätsbedingungen ab. Der Fall ‘funktionale<br />
Abhängigkeiten’ ist in der folgenden Tabelle dargestellt.<br />
Funktionale Abhängigkeiten Schema nach Dekomposition<br />
{A} → {B} Schema 1<br />
{A} → {B} → {C} Schema 1’<br />
{A} → {B, C} Schema 1<br />
{A} ↔ {B} → {C} Schema 1, Schema 1’<br />
{A} ↔ {B, C} Schema 2<br />
{A} ↔ {B} ↔ {C} Schema 3<br />
{A} → {B} ← {C} Schema 3<br />
{A, B} → {C}<br />
kein neues Schema<br />
{A} ↔ {B} Schema 1, Schema 1’<br />
Eine analoge Tabelle läßt sich auch für mehrwertige Abhängigkeit angeben.<br />
Vorsicht vor anderen Zerlegungen der Proponenten des binären Entity-Relationship-Modelles.<br />
<strong>3.</strong>4.4 ER-Entwurfstheorie<br />
Verschiedene Gründe für die Normalisierung:<br />
+ Speicherminimierung: Redundante Daten erfordern zusätzlichen Speicherplatz.<br />
+ Minimierung des Risikos inkonsistenter <strong><strong>Datenbank</strong>en</strong>: Die Kontrolle der Konsistenz von<br />
<strong><strong>Datenbank</strong>en</strong> erfordert zusätzliche Operationen. Da damit die Integritätspflege die Performanz<br />
eines Systemes negativ beeinflußt, sollte die Konsistenzpflege minimiert werden.<br />
+ Anomalien: Sind in einer <strong>Datenbank</strong> Werte redundant gespeichert, dann ist bei jeder Operation<br />
über solchen Werten entweder diese Operation auch auf redundante Werte angewandt werden<br />
oder eine extra Spezifikation der Integritätspflege vorgenommen werden.
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 49<br />
Traditionelle Normalisierungstheorie<br />
Lokale Normalisierung: Jede Relation separat.<br />
Eingeschränkte IC-Zielmenge: Es werden i.a. nur Schlüsselbedingungen unterstützt.<br />
Besser:<br />
Globale Normalisierung mit eingeschränkten Zielen (Lokalisierung der zu normalisierenden Teile,<br />
...).<br />
Einfache IC-Mengen: Abbildung von (S, Σ) auf (S ′ , Σ ′ ) mit Σ ′ ⊆ GoodConstraints.<br />
Beispiel bereits in Ansätzen in der relationalen Theorie: DK/NF (domain-key-NF), domain dependencies,<br />
key dependencies<br />
Normalisierungszugänge sind meist auf die Struktur einer <strong>Datenbank</strong> ausgerichtet und berücksichtigen<br />
kaum, ob semantisch sinnvolle Einheiten zerlegt werden oder sogar die Performanz dadurch sinkt.<br />
Damit wird nicht die akurate <strong>Modellierung</strong> bewertet, sondern eher die strukturelle Korrektheit. Deshalb<br />
wird hier auf Normalisierung nicht in vollem Umfange Wert gelegt. Wir unterscheiden zwischen<br />
relationaler, hierarchischer und Netzwerk-Normalisierung. Da auch bei der <strong>Modellierung</strong> bereits<br />
die Art der Plattform mit berücksichtigt werden kann, sollte man in diesem Schritt auch die Art der<br />
Normalisierung mit berücksichtigen. Im weiteren wird die relationale Normalisierung bevorzugt.<br />
Ziel ist ein Schema, das sich in ein Normalform-Schema des logischen Zielmodelles übersetzen läßt<br />
ohne daß eine zusätzliche Normalformbetrachtung erforderlich wird. Im Vorgriff definieren wir deshalb<br />
eine HERM-Normalform relationaler Schemata. Darauf aufbauend wird eine Normalform für<br />
HERM-Schemata definiert.<br />
Für ein relationales Schema R = (R, F, I) mit der Attributmenge R, den funktionalen Abhängigkeiten<br />
F und den Inklusionsabhängigkeiten I wird anhand der Inklusionsbeziehungen ein Graph mit<br />
den Knoten R definiert. Für jeden Typ R werden die ID’s R[X 1 ] ⊆ S 1 [Y 1 ], ..., R[X n ] ⊆ S n [Y n ]<br />
zusammengestellt (verlassende ID’s). Z R = ∪ n i=1 X i<br />
Relationshiptyp 0-ter Ordnung: Typ, der keine unpaaren verlassenden ID’s hat (d.h. T [Z] ⊆ R[X] ⇒<br />
R[X] ⊆ T [Z]).<br />
Relationshiptyp i-ter Ordnung: Im Graphen gelten folgende Eigenschaften:<br />
1. Keine unpaaren verlassenden ID’s.<br />
2. Mindestens ein Typ S j ist (i − 1)-ter Ordnung. Die maximale Ordnung der Typen S j ist<br />
i − 1.<br />
<strong>3.</strong> Alle linken Seiten der verlassenden ID’s sind paarweise disjunkt.<br />
4. Alle linken Seiten Z R bilden eine Schlüssel von R.<br />
Schwacher Typ i-ter Ordnung: Folgende Bedingungen gelten:<br />
1. n ≥ 1<br />
2. Für jeden minimalen Schlüssel W von R existiert eine Zerlegung W 1 , W 2 so daß W 1 ∩<br />
X i = ∅ oder W 1 ∩ X i = X i gilt und W 2 ∩ Z = ∅.<br />
Ein relationales Schema ist in HERM-Normalform, falls<br />
1. die ID-Menge azyklisch und nicht redundant ist,<br />
2. alle ID’s schlüsselbasiert sind (d.h. R[X] ⊆ S[Y ] ⇒ Y Teil eines Schlüssels von S oder selbst
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 50<br />
4. R zerlegt werden kann in Relationshiptypen entsprechender Ordnung bzw. schwache Typen<br />
entsprechender Ordnung.<br />
Ein HERM-Schema ist in Normalform, wenn jeder Typ in BCNF ist, alle Inklusionsabhängigkeiten<br />
schlüsselbasiert sind und wenn Relationshiptypen durch ihre Komponenten identifizierbar sind.<br />
Es gilt: Ein HERM-Schema ist in ein relationales Schema in HERM-Normalform genau dann<br />
durch einfache Transformation ohne Einbettung transformierbar, wenn es in HERM-Normalform<br />
ist.<br />
(d.h.: Jedem Typen wird ein relationaler Typ zugeordnet. Komponenten in Relationshiptypen werden<br />
durch einen minimalen Schlüssel mit entsprechenden Erweiterungen des Namen dargestellt.)<br />
Analog kann eine Transformation mit Einbettung über comp(R, R ′ ) = (1, 1) definiert werden. Es sei<br />
V = R \ Z.<br />
Relationshiptyp 0-ter Ordnung mit Fremdschlüsseln Es gibt nur solche unpaare verlassende ID’s<br />
R[X] ⊆ S[Y ] mit X ∩ K = ∅ für einen Schlüssel K von R.<br />
Relationshiptyp i-ter Ordnung mit Fremdschlüsseln wie oben<br />
Schwacher Typ i-ter Ordnung mit Fremdschlüsseln<br />
2. wie oben<br />
1. wie oben<br />
<strong>3.</strong> mindestens eine verlassende ID R[X] ⊆ S[Y ], wobei X ein Teil eines minimalen Schlüssels<br />
ist.<br />
Ein relationales Schema ist in schwacher HERM-Normalform, falls<br />
1. die ID-Menge azyklisch und nicht redundant ist,<br />
2. alle ID’s schlüsselbasiert sind (d.h. R[X] ⊆ S[Y ] ⇒ Y Teil eines Schlüssels von S oder selbst<br />
Schlüssel von S ist),<br />
<strong>3.</strong> alle Typen in BCNF bzgl. F ∪ I sind und<br />
4. R zerlegt werden kann in Relationshiptypen mit Fremdschlüsseln entsprechender Ordnung bzw.<br />
schwache Typen mit Fremdschlüsseln entsprechender Ordnung.<br />
Beispiel:<br />
Institut = (Name, Gebäude)<br />
Angestellter = (Name, ArbeitetIn.Institut.Name, Gehalt)<br />
Angestellter[ArbeitetIn.Institut.Name] ⊆ Institut[Name]<br />
Dieses relationale Schema kann nach obigen Regeln zur Überführung in ein HERM-Schema überführt<br />
werden. Wir erhalten die Typen<br />
Institut’ = ( { Name, Gebäude }, { Name } )<br />
Angestellter’ = ( { Name, Gehalt }, { Name } ) .<br />
Das relationale Schema Angestellter enthält einen Fremdschlüssel. Außerdem gilt die Inklusionsabhängigkeit.<br />
Bei Einführung eines Relationshiptypen<br />
ArbeitetIn = ( Angestellter’, Institut’, ∅ )<br />
mit den Komplexitätsbeschränkungen<br />
comp(ArbeitetIn, Angestellter ≽ (0,1) , comp(ArbeitetIn, Angestellter) ≽ (1,n) ,<br />
die sich aus der Schlüsselabhängigkeit von Angestellter undder Inklusionsabhängigkeit ableiten. Das<br />
HERM-Diagramm ist in Bild ?? dargestellt. Die Einlagerung kann mitunter besser sein aus operationalen<br />
Gesichtspunkten.
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 51<br />
Name<br />
Gehalt<br />
Name<br />
Gebäude<br />
Angestellter’ ✛<br />
(1,1)<br />
ArbeitetIn<br />
✲<br />
Institut’<br />
Abbildung 11: Beispiel für ein HERM-Schema, das in eine schwache HERM-NF überführt wird<br />
* Festlegen des für den Benutzer noch tolerierbaren veränderten Schemas;<br />
Hat ein anderes Schema ein besseres operationales Verhalten, ist aber für den Benutzer nicht<br />
ausreichend einsichtig, dann kann das Transformationsverfahren als Regelwerk abgelegt werden.<br />
* Automatische Überführung des normalisierten HERM-Schemas in ein normalisiertes relationales<br />
Schema.<br />
Der Benutzer kann im weiteren auf dem HERM-Schema arbeiten und ist nicht auf ein Verständnis<br />
der Normalisierung angewiesen.<br />
Es gibt eine Reihe von Verhaltensproblemen in <strong><strong>Datenbank</strong>en</strong>, die auf schlechte Strukturierung zurückführbar<br />
sind:<br />
Schlüsselbasierte update-Anomalien: Durch eine update-Operation kann eine, die Primär- oder<br />
alle Schlüsselbeziehungen außer Kraft gesetzt werden. Die beiden ersten Fälle werden bei 4NF<br />
bzw. BCNF vermieden.<br />
Schlüsselbasierte insert-Anomalien: Obwohl nach einer insert-Operation alle Schlüsselbeziehungen<br />
gelten, kann eine andere Integritätsbedingung, die vorher galt, nicht mehr gelten. Schemata<br />
in vierter Normalform sind frei von diesen Anomalien.<br />
Schlüsselbasierte delete-Anomalien: Obwohl nach einer delete-Operation alle Schlüsselbeziehungen<br />
gelten, kann eine andere Integritätsbedingung, die vorher galt, nicht mehr gelten. Schemata<br />
in vierter Normalform sind frei von diesen Anomalien.<br />
Nichtdeterministische Operationen: Die Verfeinerung der Operation führt zu einer Operation, die<br />
je nach Fall verschiedene Eingabeinformationen erfordert. Man kann unterscheiden in Identifikationsinformationen<br />
und Objektinformationen, die auf das betroffene Objekt abzielen. Ist ein<br />
Typ in BCNF bzw. in 4NF, dann ist ein solches Verhalten ausgeschlossen für die Verfeinerung<br />
der einfachen Operationen.<br />
Objektbasierte update-Anomalien: Obwohl das Einfügen des modifizierten Objekten wieder zu<br />
einem konsistenten Zustand führt, ist die direkte Modifikation nicht konsistent.<br />
Redundante Informationsmengen: Eine Information kann ohne Benutzung dieser aus bereits in<br />
der <strong>Datenbank</strong> vorhandenen Informationen abgeleitet werden.<br />
<strong>3.</strong>4.5 ER-basierte Behandlung von mehrwertigen Abhängigkeiten<br />
Mehrwertige Abhängigkeiten sind genuine ER-Abhängigkeiten wie wir im weiteren zeigen werden.<br />
Wir betrachten zuerst einige einfache Beispiele:<br />
Name<br />
Gehalt<br />
Name<br />
Gebäude<br />
Angestellter’ ✛<br />
(1,1)<br />
ArbeitetIn<br />
✲<br />
Institut’<br />
Abbildung 12: Beispiel für ein HERM-Schema, das in eine schwache HERM-NF überführt wird
Äquivalenzbeweis: (1) ⇒ (2) ⇒ (3) ⇒ (1)<br />
Z.B. für (1) ⇒ (2) ist Ziel: R C ⊇ R C [X ∪ Y ] ✶ R C [X ∪ Z]<br />
Gegeben seien t 1 ∈ R C [X ∪ Y ] und t 2 ∈ R C [X ∪ Z] mit t 1 = X t 2<br />
⇒ {t 1 } ✶ {t 2 } ⊆ R C wegen R C |= X → Y |Z<br />
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 52<br />
Student ✛<br />
✻<br />
❨<br />
Belegt<br />
✲<br />
Vorles<br />
InDept<br />
Von<br />
❄<br />
Dept<br />
❥<br />
Leiter<br />
Abbildung 13: Ungünstige Zerlegung des komplexen Typen<br />
Student ✛<br />
Belegt<br />
✲<br />
Vorles<br />
✻<br />
InDept<br />
❄<br />
Dept<br />
✛<br />
Leitet<br />
✲<br />
Leiter<br />
Abbildung 14: Bessere Zerlegung des komplexen Typen<br />
{ Name } → { Abteilung, Mitversichert }|{ Projekt, Produkt, Lieferant }<br />
{ Name } → { Mitversichert }|{ Abteilung, Projekt, Produkt, Lieferant }<br />
{ Projekt } → { Name, Abteilung, Mitversichert }|{ Produkt, Lieferant }<br />
{ Produkt } → { Abteilung, Name, Mitversichert, Projekt }|{ Lieferant }<br />
Ein Mitarbeiter determiniert die Abteilung und seine Mitversicherte unabhängig von den Projekten<br />
und benutzten Produkten, sowie deren Lieferanten.<br />
...<br />
In einem Projekt wird mit Produkten von Lieferanten unabhängig von den Mitarbeitern, deren Mitversicherten<br />
und deren Abteilungen gearbeitet.<br />
Ein Produkt wird von einem Lieferanten geliefert, unabhängig wer in welchem Projekt damit arbeitet.<br />
Gegeben: relationales Schema R = (U R , Σ R ), Relation R C über R<br />
Teilmengen X, Y ⊆ U R und Z = U R \ (Y ∪ X)<br />
(1) Klassische Definition: R C |= X → Y |Z<br />
falls für alle t, t ′ ∈ R C mit t = X t ′ ein Element t ′′ ∈ R C<br />
existiert mit t ′′ = X∪Y t und t ′′ = X∪Y t ′<br />
(2) Dekompositionsdefinition: R C |= X → Y |Z<br />
falls R C = R C [X ∪ Y ] ✶ R C [X ∪ Z]<br />
(3) Unabhängigkeitsdefinition: R C |= X → Y |Z<br />
falls (σ X=x (R C ))[Y ] = (σ (X=x)∧(Z=z) (R C ))[Y ]<br />
für alle X-Werte x ∈ R C [X] und alle Z-Werte z ∈ R C [Z]
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 53<br />
Name Abteilung Project Produkt ...<br />
Bodo DB-Adm Migration DB2 ...<br />
Bodo DB-Adm Integration Sybase ...<br />
Bodo DB-Prog Migration DB2 ...<br />
Bodo DB-Prog Integration Sybase ...<br />
Hans DB-Adm Ablösung MS SQL ...<br />
Hans Middlew Ablösung MS SQL ...<br />
Karl DB-Prog Migration DB2 ...<br />
Karl DB-Prog Portal Sybase ...<br />
... ... ... ... ...<br />
• Ableitung von Tupeln aus existierenden:<br />
Name Abteilung Project Produkt ...<br />
Bodo DB-Adm Migration DB2 ...<br />
Bodo DB-Prog Integration Sybase ...<br />
Bodo DB-Adm Integration Sybase ...<br />
• Dekomposition in { Name, Abteilung } und { Name, Project, Produkt,...}<br />
Name Abteilung Name Project Produkt ...<br />
Bodo DB-Adm Bodo Migration DB2 ...<br />
Bodo DB-Prog Bodo Integration Sybase ...<br />
Hans DB-Adm Hans Ablösung MS SQL ...<br />
Hans Middlew Karl Migration DB2 ...<br />
Karl DB-Prog Karl Portal Sybase ...<br />
... ... ... ... ...<br />
Zwei weitere Definitionen sind die folgenden:<br />
(4) Konstruktordefinition: R C |= X → Y |Z<br />
falls für alle x ∈ R C [X] mit (σ X=x (R C ))[Y ∪ Z] = (σ X=x (R C ))[Y ] × (σ X=x (R C ))[Z]<br />
d.h. ν Z (ν Y \X (ν X (R C ))) = ν Y \X (ν Z (ν X (R C )))<br />
(5) Strukturierungsdefinition: R C |= X → Y |Z<br />
R C {X} {Y } {Z}<br />
A 1 ... A k A k+1 ... A m A m+1 ... A n<br />
... ... ... ... ... ... ... ... ...<br />
X = {A 1 , ..., A k }, Y = {A k+1 , ...., A m }, Z = {A m+1 , ..., A n }<br />
als verschachtelte Relation<br />
Weiterführung der Beispiele<br />
• Verschachtelte Relation: (Name, {Abteilung }, { Project, Produkt,...} )<br />
Name { Abteilung } { (Project, Produkt, ...) }<br />
Bodo { DB-Adm, DB-Prog } { (Migration, DB2, ...)<br />
(Integration, Sybase,...) }<br />
Hans { DB-Adm, Middlew } { (Ablösung, MS SQL, ... )}<br />
Karl { DB-Prog } { (Migration, DB2, ...)<br />
(Portal, Sybase, ...) }<br />
... ... ...<br />
Die ER-Behandlung von MVD’s.<br />
Gegeben: relationales Schema R = (U R , Σ R ), Relation R C über R<br />
Teilmengen X, Y ⊆ U R und Z = U R \ (Y ∪ X)
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 54<br />
Y ✛ XY ✲ X ✛ XZ ✲<br />
Z<br />
✛<br />
XY ✲ X ✛ XZ ✲<br />
Das Beispielschema und die behandelte MVD wird dann durch das folgende ER-Diagramm repräsentiert:<br />
Beobachtung 5.<br />
Ein adäquate Behandlung von MVD ist nur mit vollständiger rechter Seite sinnvoll.<br />
Die Axiomatisierung von mehrwertigen Abhängigkeiten in der ER Welt.<br />
Ableitungsregeln in der klassischen relationalen Notation:<br />
Gegeben seien:<br />
X, X ′ , X ′′ , Y, Y ′ , Z, Z ′ , V, W ⊆ U<br />
alle Mengen einer Abhängigkeit bilden Überdeckung von U<br />
Axiom: (1 M ) X → ∅|Z<br />
Regeln<br />
(23 M )<br />
(27 M )<br />
(21 M )<br />
X → X ′ ∪ Y |X ′′ ∪ Z<br />
X ∪ X ′ ∪ X ′′ → Z|Y<br />
X ∪ V → Y |Z , X → Y ∪ Z|V<br />
X → Y |Z ∪ V<br />
(Abschwächung)<br />
(Wurzelreduktion)<br />
X → Y ∪ Y ′ |Z ∪ Z ′ , X → Y ∪ Z|Y ′ ∪ Z ′ (Baumrestrukturierung)<br />
X → Y |Z ∪ Z ′ ∪ Y ′<br />
Theorem 2 (1) (1 M ), (21 M ) und (23 M ) sind vollständig für mehrwertige Abhängigkeiten<br />
(2) (1 M ), (21 M ), (23 M ) und (27 M ) sind korrekt<br />
Ableitungsregeln (Strukturell):<br />
Ableitungsregeln für MVD und FD<br />
X, X ′ , X ′′ , Y, Y ′ , Z, Z ′ , V, W ⊆ U<br />
alle Mengen einer mehrwertigen Abhängigkeit bilden Überdeckung von U<br />
Axiom: (1 F ) X ∪ Y −→ Y (1 M ) X → ∅|Z<br />
X −→ Y<br />
Regeln (21 F )<br />
(FD − MVD − Reduktion)<br />
X → Y<br />
X −→ Y , Y −→ Z<br />
(22 F )<br />
(FD − Transitivität)<br />
X ∪ V ∪ W −→ V ∪ Z<br />
(23 M )<br />
(3 F,M )<br />
(21 M )<br />
X → X ′ ∪ Y |X ′′ ∪ Z<br />
X ∪ X ′ ∪ X ′′ → Z|Y<br />
X ∪ V → Y |Z , X → Y ∪ Z|V<br />
X → Y |Z ∪ V<br />
X ∩ Y<br />
→ Y \ X|X \ Y , X −→ Z<br />
X ∩ Y −→ Y ∩ Z<br />
(MVD − Abschwächung)<br />
(MVD − Wurzelreduktion)<br />
(FD − Rückkopplung)<br />
Theorem 3 (1 F ), (1 M ), (21 F ), (22 F ), (23 M ), (3 F,M ) sind vollständig und korrekt für funktionale<br />
und mehrwertige Abhängigkeiten.
X<br />
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 55<br />
(Abteilung)<br />
DB-Adm<br />
DB-Prog<br />
Middleware<br />
✲ Mitarb. ✛<br />
Bodo<br />
Hans<br />
Karl<br />
(Project, Produkt,...)<br />
(Migration, DB2, ...)<br />
(Integration, Sybase,...)<br />
(Ablösung, MS SQL, ... )<br />
(Portal, Sybase, ...)<br />
Axiom<br />
Wurzelreduktion<br />
X ∪ Z<br />
✲<br />
X<br />
Y (X)<br />
✲ X ∪ V ✛ (X)Z Y ∪ Z(X)<br />
✲ X ✛ (X)V<br />
Y (X)<br />
✲<br />
X<br />
✛ (X)Z ∪ V<br />
Beweis: siehe B. Thalheim - HERM-Buch<br />
→ Y 1 |Y 2 |...|Y m als Verallgemeinerung der mehrwertigen Abhängi-<br />
Hierarchische Abhängigkeit X<br />
keiten<br />
Ableitungsregel:<br />
(27 H )<br />
X → Y ∪ Y ′ |Z ∪ Z ′ , X → Y ∪ Z|Y ′ ∪ Z ′ (Baumentfaltung)<br />
X → Y |Y ′ |Z|Z ′<br />
Abhängigkeitsbasis<br />
Gegeben Menge funktionaler und mehrwertiger Abhängigkeiten Σ<br />
X + = { A ∈ U | Σ |= X −→ {A} }<br />
Dep M (X, Σ) = { Y i | Σ |= X → Y i , Y i ∩ X + = ∅,<br />
̸ ∃Y i ′ ⊂ Y i(Y i ′ ≠ Y i ∧ Σ |= X → Y i ′)<br />
}<br />
Dep M,F (X, Σ) = Dep M (X, Σ) ∪ { X + \ X }<br />
Berechnung über Axiomatisierung mit hierarchischen Abhängigkeiten<br />
analoge Theorie zu Graph-Abhängigkeiten<br />
Erwünscht: Konkurrenzfreie (konfliktfreie) Abhängigkeitsbasis<br />
Ausblick zur Abhängigkeitsbasis<br />
• Es existiert ein O(|R|·|Σ| p )-Algorithmus zur Bestimmung der Abhängigkeitsbasis einer Menge<br />
X ⊆ U.<br />
• Konkurrierende Abhängigkeitsbasis besitzt<br />
• Wurzelschnitt: es existiert für X → Y |Z ∈ Σ ∗ eine spleißende Abhängigkeit<br />
S → T |V ∈ Σ ∗ , d.h. es gilt sowohl X ∩ T ≠ ∅ als auch X ∩ V ≠ ∅ ,<br />
oder<br />
• Schnittanomalie: aus Σ |= X → Z|V, Y<br />
→ Z.<br />
→ Z|W folgt nicht Σ |= (X ∩Y ) →<br />
Baumrestrukturierung<br />
Abschwächung<br />
Y ∪ Y ′ (X)<br />
(X)Y ′ ∪ Z ′<br />
X ′ ∪ Y (X)<br />
✲<br />
X<br />
✛ (X)X ′′ ∪ Z<br />
❄<br />
X<br />
✛ (X)Z ∪ Z ′<br />
Y ∪ Z(X)<br />
✲<br />
❄<br />
X
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 56<br />
Y 2 (X) ...<br />
Y 1 (X)<br />
❄<br />
✲<br />
X ✛<br />
(X)Y m<br />
✲<br />
Y ∪ Y ′ (X)<br />
✛ (X)Z ∪ Z ′<br />
X<br />
✲<br />
Y ∪ Z(X)<br />
✛ (X)Y ′ ∪ Z ′<br />
X<br />
Y (X)<br />
Y ′ (X)<br />
❄<br />
✲<br />
Z(X)...<br />
❄<br />
X ✛<br />
(X)Z ′ ✲<br />
• Konkurrierende Abhängigkeitsbasis führt zu unterschiedlichen<br />
Schema-Varianten je nach Sichtweise<br />
Vereinheitlichung durch Vergröberung oder<br />
Ergänzung der Abhängigkeiten<br />
Reduzierte Abhängigkeitshülle:<br />
Σ ∗ = { X → Y |Z | Σ |= X → Y |Z , X ∩ Y = X ∩ Z = Y ∩ Z = ∅ , Y ≠ ∅ , Z ≠ ∅ }<br />
Sichtweisen durch Abhängigkeitsbasis<br />
Sichtweisen durch Abhängigkeitsbasis<br />
Dekomposition des Relationship-Typen zu einem Teilschema<br />
nur im Fall konkurrenzfreier mehrwertiger Abhängigkeiten<br />
ansonsten Wahl einer Sichtweise<br />
oder Wahl einer Abschwächung<br />
oder wiederholte Betrachtung der Abhängigkeiten<br />
z.B. kann Lieferant ggf. falsch angebunden sein (zu schwach spezifiziert)<br />
Beobachtung 6.<br />
Unterschiedliche Sichtweisen sind ggf. je nach Aspekt der Anwendung interessant und können ggf.<br />
auch konkurrierend benutzt werden.<br />
Beobachtung 7.<br />
Eine kombinierte Sichtweise kann, muß aber nicht existieren.<br />
Beobachtung 8.<br />
• Mehrwertige Abhängigkeiten spezifizieren eine interne Strukturierung.<br />
• Mehrwertige Abhängigkeiten sind axiomatisierbar.<br />
Abhängigkeitsbasis<br />
X<br />
X + \ X<br />
✠<br />
(X)Y 1<br />
✛<br />
(X)Y 2<br />
❪ ...<br />
als Stern-Schema<br />
Unterschiedliche Sichtweisen<br />
über Schalen des Sterns
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 57<br />
Mitarbeitsichtweise<br />
DepBasis(Name,Σ) \{ Name} =<br />
{{ Abteilung }, { Mitversichert }, { Project, Produkt, Lieferant }}<br />
(Project, Produkt, Lieferant)<br />
❄<br />
Abteilung ✲ Name ✛ Mitversichert<br />
Projektsichtweise<br />
DepBasis(Projekt,Σ) \{ Projekt} =<br />
{{ Produkt }, { Lieferant }, { Name, Abteilung, Mitversichert }}<br />
(Name, Abteilung, Mitversichert)<br />
❄<br />
Produkt ✲ Projekt ✛ Lieferant<br />
Kombinierte Sichtweise<br />
DepBasis(Name,Σ) \{ Name} =<br />
{{ Abteilung }, { Mitversichert }, { Project, Produkt, Lieferant }}<br />
DepBasis(Projekt,Σ) \{ Projekt} =<br />
{{ Produkt }, { Lieferant }, { Name, Abteilung, Mitversichert }}<br />
Abteilung<br />
✛<br />
arbeitet ✲ Name ✛ Mitversichert<br />
❄<br />
Produkt ✲ Projekt ✛ Lieferant
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 58<br />
(auch gemeinsam mit funktionalen Abhängigkeiten<br />
nicht aber gemeinsam mit Inklusionsabhängigkeiten<br />
(Verwaschung der Arten))<br />
• Die Abhängigkeitsbasis erlaubt eine vollständige Entfaltung zu stärkster hierarchischer Abhängigkeit.<br />
Die ER-Repräsentation führt zu einem verständlichem Schema.<br />
• Es können konkurrierende Schemata existieren.
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 59<br />
<strong>3.</strong>5 Verhaltensmodellierung<br />
Paradigmen<br />
formale Sprache \ Theorie Abstraktion Entwurf<br />
erfinden<br />
•<br />
verwirklichen • ⋄<br />
benutzen<br />
•<br />
Einheit von statischen Gesichtspunkten (grundlegende Seiende und Beziehungen) und dynamischen<br />
Gesichtspunkten<br />
Veränderungen im Wissen müssen stets zu einer statischen Gesichtspunkten genügenden Aufzählung<br />
führen<br />
somit müssen Handlungen stets statisch abbildbar sein<br />
Seiendes - etwas, das wirklich existiert; kann seine Existenz unabhängig von anderen beginnen und<br />
beenden;<br />
damit formale Handlungen des Existenzbeginns und Ende als grundlegend<br />
Komplexität ⇒ leicht ausführbare Änderung<br />
Einfügen muß allein der Eindeutigkeitsbedingung genügen<br />
Löschen soll nicht Löschen von Werten anderer Seinender nachziehen<br />
Ein Informationssystem besteht aus verschiedenen Teilen. In DBS meist nur struktureller Teil<br />
korrekt modelliert. Es lassen sich verschiedene Sichten auf ein IS unterscheiden:<br />
Vermarktungssicht kein Teil eines Verhaltensmodells im Gegensatz zu den weiteren Teilen<br />
Problemdefinition<br />
Verkaufsdokumente<br />
Vermarktungsplanung<br />
Operationale Sicht Systemausrichtung<br />
Kontextdiagramme<br />
Ereignisdiagramme<br />
Datensicht Datenwörterbuch<br />
ER-Definition<br />
Architektursicht Diagramme der Szenarios<br />
Spezifikation der Szenarios<br />
Zustandsdiagramme<br />
Verhaltenssicht Verhaltensdiagramme<br />
Verhaltensspezifikation<br />
Prozeßsicht Datenflußdiagramme<br />
Steuerflußdiagramme<br />
Prozeßspezifikationen<br />
Darstellungsmethoden<br />
Datenflußdiagramme i.a. als Mehrebenendarstellung für unterschiedliche Abstraktionsebenen<br />
Kontextdiagramme zur Darstellung der Input/Output-Datenströme ohne Aufzeigen der Struktur<br />
Dialogflußdiagramme zur Darstellung des interaktiven Verhaltens<br />
Datenflußmodellierung zur Darstellung der Hauptprozesse;
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 60<br />
Erweiterungen zu Real-Time-Systeme mit einer expliziten <strong>Modellierung</strong> der Steuerung (Steuerprozesse,<br />
Zielprozesse) und des Steuerflußes<br />
Datendefiniton wie bereits oben<br />
Prozeßspezifikation zur <strong>Modellierung</strong> der Datentransformation und Datenverarbeitungspolitik in<br />
verschiedenen Darstellungssprachen<br />
Struktogramme, Programmlogik Verzweigung, Schleifen, Verkettung mit Blockbildung<br />
Strukturierte natürliche Sprache bzw. Pseudocode mit Verben, die imperativ sind, Wörtern,<br />
die durch ein Wörterbuch begrenzt sind, und einigen logischen Konstrukten zur Darstellung<br />
der Entscheidung in Verzweigungen, der Wiederholung, der Gruppierung, sowie der<br />
Input/Output-Darstellung und der Fileverarbeitung<br />
Allgemeine Aufrufe zur Verarbeitung<br />
Suspendierung, Termination, Kommentare<br />
Entscheidungsbäume und -tabellen mit Entscheidungsregeln<br />
Charts und Graphen zur Darstellung der Abhängigkeit<br />
Damit allgemeines Verhaltensmodell:<br />
Motive Ereignisse Szenarios Verhaltensmuster<br />
zu jeweils einem Motiv zu jeweils einem Ereignis zu jeweils einem Szenario<br />
Geschäftsprozeß Handlungen Prozesse<br />
Motivations- Geschäftsprozeß- Aktions- konzeptionelle<br />
schicht schicht schicht Schicht<br />
Installation Petrinetze Interfaces <strong>Modellierung</strong><br />
Pflege über Sichten Constraints von Programmen<br />
Adminstrier. Beziehungen Automatendiagr.<br />
Benutzung Aggregationen Aktionsdiagr.<br />
Operationale Integr. Unabhängigk.<br />
Datenintegrität temp. Sichten<br />
Operationale Sicht Architektursicht Verhaltenssicht<br />
Es fehlt hier im Schema jedoch die Implementationsschicht.<br />
Programme als Verfeinerung der Prozesse.<br />
Operationale Sicht eines Systems als ‘Customersicht’, wie der Benutzer System sehen möchte;<br />
darauf aufbauend, warum der Benutzer eine bestimmte Funktion erwartet<br />
Operationen und Motive (Grund für ein Ereignis und erwartetes Resultat)<br />
7 verschiedene Erwartungen: Installation, Pflege, Administrierung, Benutzeroperationen,<br />
Garantierung der Integrität, Fortführung der Funktionalität (operationale Integrität), Benutzerinterface<br />
Dynamische Integritätsbedingungen, Transitionsbedingungen, Anforderungen über Operationsbedingungen<br />
(externe Faktoren, die System und Operationen begrenzen), Operationsbegrenzungen<br />
(Kapazität, Leistungsparameter, Zuverlässigkeit, Sicherheit, Zeitbegrenzungen,<br />
Interface)<br />
Spezifikation der Operationsumgebung (Zugriff woher), Kosten (die der Benutzer bereit<br />
ist zu zahlen), Lieferintervall (wie lange ist der Benutzer bereit zu warten) und Kapazität<br />
(TA’s/sec, Kommunikationsaufwand, Speicheraufwand,...)<br />
Systemanforderungen deklarative:<br />
Leistungsanforderungen der Benutzer<br />
Zuverlässigkeitsanforderungen der Benutzer für durchgängigen Betrieb (Ein-Prozessor,
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 61<br />
Motivationsschicht<br />
Motive, Ideen,<br />
Aufgaben, Workflow<br />
Operationale Sicht - Geschäftsprozeßschicht<br />
Datensicht<br />
HERM-Diagramme<br />
Geschäftsprozesse<br />
Verhaltensdiagramm<br />
Systemnutzen<br />
Kontextdiagramm<br />
Ereignisdiagramm<br />
Grobentwurf<br />
Grobes<br />
HERM-Schema<br />
Für jedes Ereignis<br />
...<br />
Architektursicht - Aktionsschicht<br />
✮<br />
✙<br />
Handlungen❄<br />
...<br />
Szenariospezifikat.<br />
Szenariodiagramm<br />
Szenariodiagramm<br />
Szenariodiagramm<br />
Szenariospezifikat.<br />
Szenariospezifikat.<br />
Vorentwurf<br />
Skelett-<br />
HERM-Schema<br />
Verhaltenssicht - Konzept. Schicht<br />
✮<br />
✙<br />
Für jeden Prozeß<br />
...<br />
...<br />
Prozesse<br />
❄<br />
Verhaltensspezifikat.<br />
Verhaltensdiagramm<br />
Verhaltensdiagramm<br />
Verhaltensspezifikat.<br />
Verhaltensspezifikat.<br />
Konzeptionelles<br />
Schema<br />
HERM-Schema<br />
Für jedes Programm<br />
...<br />
Implementationsschicht<br />
✮<br />
✙<br />
...<br />
Programme❄<br />
Programmspezifikat.<br />
Programmdarstellung<br />
Programmdarstellung<br />
Programmdarstellung<br />
Programmspezifikat.<br />
Programmspezifikat.<br />
Phys./Log.<br />
Datensicht<br />
DBMS<br />
Data<br />
Dictionary
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 62<br />
Externe Schnittstellen mit Help etc.<br />
Andere Anforderungen<br />
Ereignis - Änderung im System oder Umgebung, die eine Aktivität auslöst oder durch System<br />
auslöst<br />
Externe Ereignisse System reagiert auf externe Ereignisse mit Input (stimulus) und generiert Output<br />
(response);<br />
haben Motiv<br />
Temporale Ereignisse bedingen Systemaktivität (Trigger etc.) aufgrund Auslösungsmechanismus<br />
(Zeit etc.) (interne Motive)<br />
Interne (anormale) Ereignisse , die durch System erkannt werden (interne Organisation zur Herstellung<br />
der Leistung, ...)<br />
Motive und Ereignisse als Benutzersicht des Systems ⇒ 5 Motive<br />
Installationsmotive Installation, Update, Setzen von Systemparametern, Initialisierung von Datenbeständen,<br />
etc.<br />
Berücksichtigung im Installationsdialog<br />
Pflegemotive bei neuen releases, Datenbackup, Recovery ...<br />
Administrative Motive : neuer Benutzer, Systembenutzung (-mißnutzung), Datensicherheit, temporale<br />
Ereignisse hinzufügen<br />
Benutzungsmotive , die zur Notwendigkeit des Systems führen<br />
Integritätspflege<br />
Beziehungen zwischen Ereignissen zur Behandlung der Komplexität der Benutzererwartungen<br />
Entities und Ereignisse Behandlung durch Ereignisdiagramme in Petrinetzdarstellung (Ereignisse<br />
und Sichten) mit Input/Output in Eventknoten<br />
Knoten = Ereignisse ∪ Sichten<br />
Kanten = Ereignisse × Sichten<br />
Sichten × Ereignisse<br />
Output von Ereignissen, Input von Sichten<br />
Output auf requests an<br />
andere Ereignisse<br />
Sichten werden aufgefaßt als Input/Output-Generator<br />
Mehrfachinput kann in ‘and’-Form für Ereignisse aufgefaßt werden<br />
Mehrfachinput an Sichten ist eine ‘or’-Form zum Anstoßen<br />
Unabhängigkeit von Ereignissen zur sauberen <strong>Modellierung</strong><br />
falls Daten zwischen Ereignissen ausgetauscht werden müssen, dann über temporale Sichten<br />
Adminstrative Beziehungen zwischen Ereignissen können über temporale Sichten ebenso<br />
modelliert werden (als shared Zwischenspeicherung)<br />
Aggregationen von Ereignissen zur Darstellung der Auslösung mehrerer Zwischenereignisse<br />
Direktive Beziehungen von Ereignissen zur Darstellung der Auslösung eines Ereignissen<br />
durch Steuerfluß oder Datenfluß eines anderen Ereignisses<br />
Als generellen Überbau: Benutzerschnittstellen werden analog spezifiziert.<br />
Außerdem werden Sichten für die Ereignisse abgeleitet.<br />
<strong>3.</strong>5.1 Sprachen zur Verhaltensmodellierung<br />
Es existieren viele Modelle zur Darstellung der Prozesse und wenige Modelle zur Darstellung der
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 63<br />
Formular-orientierte Sprachen erlauben die <strong>Modellierung</strong> von Folgen von zusammenhängenden<br />
Aktivitäten. Mit Ablaufmodellen kann der Lebenszyklus eines (<strong>Datenbank</strong>-)Objektes dargestellt<br />
werden. In einer Form Definition Component werden die Objekte selbst beschrieben. Mit<br />
der Document Flow Component wird der Datenfluß beschrieben. Die Document Transformation<br />
Component erlaubt die programmiersprachliche Beschreibung der Aktivitäten. Aktivitäten<br />
können selbst zu Gruppen zusammengefaßt werden. Verschiedene parallele Berechnungen sind<br />
möglich.<br />
Fluß-orientierte Sprachen modellieren formale Handlungen als Flüsse von Objekten und Mitteilungen.<br />
Aktivitätengraphen bzw. Vorgangskettendiagramme, Prozeßmodelle und Beschreibungen<br />
von Lebenszyklen erlauben die Beschreibung von komplexem Verhalten.<br />
<strong>3.</strong>5.2 Ereignisorientierte Spezifikation<br />
Wir wählen hier zuerst einen ereignisorientierten Zugang. Der Zusammenhang von Entities und<br />
Ereignissen wird durch Ereignisdiagramme in Petri-Netz-Darstellung (Ereignisse und Sichten) mit<br />
Input/Output in Eventknoten dargestellt. Knoten sind Ereignisse oder Sichten bzw. in einfachen Fällen<br />
Teilschemata. Kanten verlaufen von Ereignissen nach Sichten bzw. von Sichten nach Ereignissen.<br />
Sichten werden aufgefaßt als Input/Output-Generatoren. Ein Mehrfachinput kann in ‘and’-Form für<br />
Ereignisse aufgefaßt werden. Ein Mehrfachinput an Sichten ist eine ‘or’-Form zum Anstoßen. Damit<br />
ergibt sich eine Petri-Netz-Darstellung wie in Bild ??.<br />
als<br />
Sender<br />
gedeutete<br />
Sichten:<br />
Mitteilung<br />
ermittelt<br />
Information<br />
als Erstellung<br />
und Übertragung von<br />
Mitteilungen<br />
gedeutete Transition<br />
als<br />
Empfänger<br />
gedeutete<br />
Sichten<br />
eingehende<br />
Mitteilungen<br />
Auslösung<br />
von<br />
anschließenden<br />
Handlungen<br />
✲<br />
✯<br />
✲<br />
... and<br />
❥<br />
✯<br />
Transition<br />
...<br />
✲<br />
❥<br />
✲<br />
Abbildung 16: Petri-Netz-Darstellung von formalen Handlungen<br />
Verallgemeinerte Petri-Netze zur Spezifikation von Verhalten.<br />
Das Verhalten für Einzelobjekte kann durch eine Lebenszyklusspezifikation mit einem verallgemeinerten<br />
Petri-Netz-Modell (Prädikaten-Transitionsnetz) oder einem Automatengraphen beschrieben<br />
werden:<br />
Menge von Zuständen: S o für jedes Objekt in der <strong>Datenbank</strong>;<br />
Menge von Aktivitäten: T o für jedes Objekt in der <strong>Datenbank</strong>;<br />
Diagramm: D ⊆ S o × T o ∪ T o × S o ;<br />
Vor- und Nachbedingungen zu Aktivitäten: V o (s, t) für (s, t) ∈ S o ×T o als Vorbedingung für eine<br />
Aktivität und N o (t, s) für (t, s) ∈ S o × T o als Nachbedingung für eine Aktivität. Damit kann<br />
eine Darstellung durch eine Hoare-Logik V tN verwendet werden.<br />
Spezifikation eines Lebenszyklus: (S o , T o , F o , V o , N o ) .
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 64<br />
Der Moment eines Lebenszyklus sind alle Eigenschaften des Objektes im Zustand s.<br />
Beispiel: Personen werden Studenten etc.<br />
Exmatrikulation<br />
✲<br />
Absolvent<br />
✒<br />
Person ✲ Immatrikulation ✲ Student<br />
✲<br />
Betreuersuche<br />
✲<br />
Student mit<br />
Betreuer<br />
Belegt<br />
<strong>Vorlesung</strong><br />
✠<br />
❄<br />
Abschluß<br />
Vertrag<br />
❘<br />
Auswahl<br />
Nebenfach<br />
❄<br />
Auswahl des<br />
Themas<br />
❄<br />
Student<br />
mit Resultat<br />
❄<br />
HiWi<br />
❄<br />
Student<br />
mit Nebenfach<br />
❄<br />
Diplomand<br />
Abbildung 17: Lebenszyklus eines Studenten in der <strong>Datenbank</strong><br />
Die Vor- und Nachbedingungen sind nicht in der Zeichnung dargestellt. So gilt z.B., daß für die<br />
Exmatrikulation sämtliche Beziehungen gelöst werden.<br />
Die Vertragsgestaltung erbt das Objekt Student vom Objekt Person. Personen sind über Verträge<br />
Mitarbeiter von Projekten. Bei dieser Vererbung wird auch die Bezeichnung Mitarbeiter überschrieben.<br />
Man kann die und-oder Graphen auch weiter verfeinern. (siehe <strong>Modellierung</strong>skapitel)<br />
Die Sichtbarkeitsregeln folgen der Sichtendefinition.<br />
Außerdem kann der Graph auch zyklisch sein.<br />
Kanten können mehrwertig sein (Z.B. für die Auswahl des Nebenfaches).<br />
Darstellung von gemeinsamen Verhalten mehrerer Objekte.<br />
Unterscheidung in aktive Objekte, aktivierte Objekte und passive Objekte<br />
Entwicklung von Kooperationsverträgen zwischen den Objekten<br />
Prozesse können sich auch gegenseitig<br />
bedingen,<br />
blockieren,<br />
abweisen,<br />
starten<br />
Kopplung.<br />
Verschiedene Arten von Kopplungsmechanismen:<br />
• Interaktionskopplung<br />
rufen dieselben Daten ab; rufen sich gegenseitig auf<br />
dabei verschiedene Kopplungsmechanismen
Ereignisgesteuerte Prozeßketten.<br />
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 65<br />
• Kontrollflußkopplung<br />
• Wanderdatenkopplung<br />
• Parameterkopplung<br />
• keine Kopplung<br />
• Komponentenkopplung<br />
verschiedene Grade<br />
• versteckte Kopplung<br />
• verstreute Kopplung<br />
• spezifizierte Kopplung<br />
• keine Kopplung<br />
• Vererbungskopplung<br />
verschiedene Arten<br />
Kohäsion.<br />
• Änderungskopplung<br />
• Signaturänderungskopplung<br />
• Implementationsänderungskopplung<br />
• Verfeinerungskopplung<br />
• Signaturverfeinerungskopplung<br />
• Implementationsverfeinerungskopplung<br />
• Erweiterungskopplung<br />
• keine Kopplung<br />
(Bindung zwischen den einzelnen kooperierenden Objekten)<br />
verschiedene Arten<br />
• Operationskohäsion<br />
• zufällige Kohäsion<br />
• logische Kohäsion<br />
• temporale Kohäsion<br />
• prozedurale Kohäsion<br />
• Kommunikationskohäsion<br />
• sequentielle Kohäsion<br />
• funktionale kohäsion<br />
• Typkohäsion<br />
• zerlegbare Kohäsion<br />
• mehrschichtige Kohäsion<br />
• nicht delegierte Kohäsion<br />
• verborgene Kohäsion<br />
• Vererbungskohäsion
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 66<br />
• Funktionen (als abgerundete Rechtecke dargestellt)<br />
• Ereignisse (als Sechsecke) [gemeint sind eigentlich Zustände]<br />
• Verknüpfungsoperationen (dargestllt mit Kreisen)<br />
Kanten von Funktion zu Ereignis bzw. Ereignis zu Funktion<br />
wobei Funktionen<br />
• von einem Zustand oder mehreren Zuständen ausgelöst werden und<br />
• ein Zustand einen oder mehrere Zustände erzeugt<br />
Ein Zustand kann<br />
• von einer Funktion oder mehreren Funktionen ausgel¨st werden und<br />
• eine Funktion oder mehrere Funktionen auslösen.<br />
Verknüpfungsoperationen als logische Verknüpfungen<br />
• UND (in der Bedeutung “sowohl als auch”),<br />
• XOR (in der Bedeutung “entweder oder”)<br />
• OR<br />
(nicht für die konzeptionelle <strong>Modellierung</strong> geeignet)<br />
geeignet für Darstellung während der Anforderungsanalyse<br />
Antrag zur<br />
Bearbeitung<br />
liegt vor<br />
✲<br />
XOR<br />
✛<br />
❄<br />
AND<br />
❄<br />
❄<br />
Antrag<br />
prüfen<br />
Nebenbedingungen<br />
prüfen<br />
❄<br />
❄<br />
❄<br />
XOR<br />
❄<br />
❄<br />
XOR<br />
❄<br />
Unterlagen<br />
unvollständig<br />
Unterlagen<br />
vollständig<br />
Nebenbedingungen<br />
erfüllt<br />
Nebenbedingungen<br />
nicht erfüllt<br />
❄<br />
Weitere<br />
Unterlagen<br />
beschaffen<br />
❄<br />
Weitere<br />
Unterlagen<br />
liegen vor<br />
✲<br />
AND<br />
❄<br />
Vertrag<br />
genehmigen<br />
❄<br />
✛<br />
Antrag<br />
genehmigen<br />
❄<br />
Vertrag nicht<br />
genehmigen<br />
❄<br />
Antrag<br />
abgelehnt
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 67<br />
Aufblähung der Spezifikation durch alternierende Darstellung von Funktionen und Zuständen<br />
Blockdiagramme zur Darstellung der Funktionen<br />
Fehlende Abstraktion und damit Forderung nach feingranalarer Darstellung<br />
Fehlende Hierarchien und damit nichtsichtbare Schichtung<br />
Funktionsbäume als Alternative<br />
Fehlende zeitliche Schichtung bei Abhängigkeiten der Ereignisse vom Zeitverlauf<br />
Balkendiagramme (Gantt charts) zur 2D-Darstellung von Ereignis und Zeit(intervall)<br />
Fehlende Integration mit Organisationsstruktur<br />
Rasterdiagramme (Ereignisfolgendiagramme) zur Darstellung der Vorgangsbearbeitung als Tabellendarstellung<br />
von Organisationsstrukturen und Aktionen mit Beziehungsgraphen der Zellen<br />
Überwindung dieser Nachteile durch Anreicherung<br />
Akteur<br />
(Stelle, Rolle)<br />
✲<br />
Funktionerweiterung<br />
✛<br />
✲<br />
Output-Daten<br />
Input-Daten<br />
Hauptproblem: Bruch in den Paradigmen<br />
<strong>3.</strong>5.3 Zustandsbasierte Spezifikation des Verhaltens<br />
Anforderungen an Spezifikation des Verhaltens<br />
Visualisierung des Verhaltens<br />
Verfeinerung und Kompositionalität mit induktivem Aufbau<br />
Rigide Semantik zur eindeutigen Interpretation<br />
Interoperabilität mit anderen Spezifikationen insbesondere zum Austausch<br />
Akzeptanz und breite Verwendung<br />
statecharts (David Harel)<br />
in Verallgemeinerung des deterministischen endlichen Automaten<br />
Zustandübergang<br />
Transition<br />
• zwei Zustände<br />
• auslösendes Ereignis,<br />
• für Transition notwendige Bedingung,<br />
• durch die Transition ausgelöste, meist externe Bedingung<br />
Vor- und Nachteile<br />
+ einfache graphische Notation<br />
+ einfache intuitiv verständliche Semantik<br />
+ theoretisch sauber<br />
- alle Zustände atomar (Verfeinerung ?, Hierarchisierung ?)<br />
- keine Unterstützung der Zerlegung<br />
- Zustandsexplosion
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 68<br />
✛<br />
Transition<br />
✻<br />
H<br />
❄<br />
❘<br />
Zustand<br />
Ereignisse [Bedingungen]<br />
/Aktionen zu Transition<br />
✲<br />
Transition<br />
Abbildung 18:<br />
• enthält Zustandsdiagramm bzw. andere Superzustände<br />
• erlaubt die Vereinfachung mehrfacher Transitionen zu einem Zielzustand durch<br />
• Einführung eines zusammenfassenden Zustandes und Substitution aller Transitionen von<br />
Zuständen zum Zielzustand durch Transition vom Superzustand zum Zielzustand<br />
diese Zusammenfassung entspricht dem XOR<br />
Argumente/Parameter mit zustandsabhängiger Instantiierung<br />
Transition zur Zustandsüberführung<br />
• Repräsentation einer Zustandsänderung eines Objekts<br />
• i.a. getriggert (gefeuert) durch ein Ereignis<br />
Konvention: Ereignisse ohne Trigger (?-Transitionen) feuern sofort<br />
• feuern sofort<br />
• von exakt einem Zustand zu einem anderen (oder sich selbst (self-transition)) können nicht<br />
unterbrochen werden<br />
Wächter (guards)<br />
• logische Bedingung<br />
• guarded transition feuert, wenn dies die Bedingung erlaubt<br />
• i.a. kann nur eine Transition feuern; deshalb sind Wächter paarweise exklusiv<br />
• Ereignisse können auch Wächter besitzen<br />
Ereignisse (events)<br />
• gekoppelt an einen Zeitpunkt<br />
• Zeitlogik i.a. diskret, mit oder ohne Grenzen,
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 69<br />
ein Signal von einem Objekt an ein anderes (delived)<br />
eine Nachricht, empfangen von einem Objekt (check item)<br />
zu einer bestimmten Zeit (nach 10 Sekunden (in einem Zustand), 7.12.2004, 18.45 (Chanukkah)<br />
• Ereignisse können Argumente benutzen (deliver to (receiver:Kunde)<br />
• Ereignisse setzen auf dem Schema auf (über Attributen insb.)<br />
Parallelität von Teil-Statechart<br />
durch gestrichelte Linie gekennzeichnet<br />
Gleichzeitigkeit in Zustandsdiagrammen<br />
ein Objekt kann Verhalten haben, das separierbar ist in unabhängige Komponenten<br />
anzeigen der Separation durch ‘Gabeln (Fork) (Doppelungssemantik) oder gleichzeitigem (konkurrierendem)<br />
Superzustand<br />
History-Funktion<br />
Operationale Semantik von Statecharts.<br />
Execution state of statechart (S, T, V ):<br />
subset states ⊆ S of currently active states s.t.<br />
• root of S is in states<br />
• if s in states and type of s is AND then all children of s are in states<br />
• if s in states and type of s is XOR then exactly one child of s is in states<br />
Execution context of statechart (S, T, V ):<br />
current values of variables defined by val : V → Dom<br />
Configuration of statechart (S, T, V ) : (states, val)<br />
Initial configuration<br />
Evaluation of expression in configuration:<br />
eval(expr, conf) defined inductively<br />
Effect of action on context:<br />
modification of variable values in val<br />
fire(conf) = set of transitions<br />
t = (source, target, [cond]/action) with source(t) in states for which eval(cond, conf) =<br />
true<br />
for transition t:<br />
when t fires:<br />
• a = lca(source(t), target(t))<br />
• src(t) = child of a in subtree of source(t)<br />
• tgt(t) = child of a in subtree of target(t)<br />
• set of left states source ∗ (t):<br />
• src(t) is in source ∗ (t)<br />
• if s in source ∗ (t) then all children of s are in source ∗ (t)<br />
set of entered states target ∗ (t):
Architektursicht der Daten- und Prozeßorganisation<br />
alle Ereignisse werden durch Prozessoren unterlegt<br />
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 70<br />
For a given configuration conf = (states, val) a successor configuration conf ′ = (states ′ , val ′ )<br />
is derived by selecting one transition t from fire(conf) with the effect: states ′ = statessource∗<br />
(t) ∪ target ∗ (t) val ′ captures the effect of action(t) and equals val otherwise<br />
Theorem 4 The operational semantics of a statechart (S, V, T ) is the set of all possible executions<br />
along configurations conf 0 , conf 1 , conf 2 , ... with initial configuration conf 0 and conf i+1 being a<br />
successor configuration of conf i .<br />
Verfeinerung von Statecharts.<br />
Das Zustandsdiagramm in Bild ??<br />
completed<br />
login<br />
✛<br />
login<br />
request<br />
disabled<br />
login<br />
✛<br />
❄<br />
enabled<br />
login<br />
offer<br />
✲<br />
offered<br />
lecture<br />
completed<br />
offer<br />
✛<br />
commit<br />
❄<br />
validated<br />
offer<br />
Abbildung 19: Abstrakter Statechart zur <strong>Vorlesung</strong>splanung<br />
wird durch das Zustandsdiagramm in Bild ?? verfeinert.<br />
Vor- und Nachteile.<br />
Wann sollte man Zustandsdiagramme nutzen? Von Nutzen bei Beschreibung des Verhaltens von<br />
Objekten über mehrere Anwendungfälle hinweg. sowie bei Klassen, deren Verhalten noch nicht<br />
wohlverstanden ist.<br />
Wann sollte man Zustandsdiagramme nicht nutzen? Beschreibung des Verhaltens von mehreren<br />
Objekten, die innerhalb eines Anwendungsfalles auftreten (dann Interaktionsdiagramme)<br />
Beschreibung der Verhaltens mehrerer Anwendungsfälle und mehrerer Objekte (dann Aktivitätendiagramme)<br />
Beschreibung des Verhaltens von kooperierenden Objekten<br />
<strong>3.</strong>5.4 Top-down-Beschreibung<br />
Szenarien, Architektur und Zustände.<br />
Nun <strong>Modellierung</strong> der Erwartungen für jedes Ereignis.<br />
Alle möglichen Szenarios können nicht entworfen werden.<br />
In <strong>Datenbank</strong>systemen werden Szenarios durch Transaktionen (siehe spezielles Kapitel) dargestellt<br />
(evt. mit Teiltransaktionen, aber ohne Wiederholungen, expliziter Parallelität).
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 71<br />
reset<br />
state<br />
✻<br />
❄<br />
disabled<br />
login<br />
✕<br />
❘<br />
completed<br />
login<br />
❄<br />
unknown<br />
user<br />
send name<br />
❄<br />
name<br />
known<br />
send password<br />
❄<br />
known name,<br />
password<br />
✛<br />
✲<br />
renew<br />
login<br />
✻(count ≠ 0)<br />
(count<br />
counter =0) ✲ reject<br />
check<br />
login<br />
✻(false)<br />
login (true) ✲<br />
validated<br />
✻{count:=3}<br />
login<br />
unclear<br />
✛<br />
H<br />
✻<br />
correct<br />
login<br />
enabled login<br />
✻<br />
login<br />
accepted<br />
✲<br />
✛<br />
correct<br />
login<br />
✠<br />
roles, rights<br />
unclear<br />
{ role, right<br />
generation ❄ }<br />
roles, rights<br />
assigned<br />
✛<br />
Abbildung 20: Verfeinerung des Statechart für das Login<br />
Technologische Beschränkungen und Bedingungen der Kommunikationskanäle, der Input/Output-<br />
Geräte, der Prozessoren, der Speicher, der Geschwindigkeit, ...<br />
Spezifikation der Architekturanforderungen Prozessoren, Zuverlässigkeit, Prioritäten, Leistung,<br />
Kapazität, Zeitbeziehungen, Interface, Sicherheit, fail-safety, safety, ...<br />
dokumentiert in Szenario-Spezifikation, Szenariodiagramm<br />
Szenario - Menge von I/O-Datenströmen, Steuerströmen, Verhalten eines Ereignisses<br />
Endliche Automatten als Darstellungsmittel als spezifische Darstellungsform<br />
Zustand eines Informationssystemes<br />
Zustandsüberführungsdiagramme mit I/O-Kanten<br />
Zustandsüberführungstabellen in klassischer Form<br />
Statecharts als State-Transition-Diagramme mit concurrency, Hierarchisierung und Kommunikation<br />
D. Harel, Statecharts: A visual formalism for complex systems. North-Holland, New York,<br />
1987<br />
Aktionsdiagramme in Szenarios oder Struktogramme zur Spezifikation der Programmabläufe in<br />
Szenarios (mit Erweiterung für parallele Handlungen)<br />
Verhaltensmuster (Skripte).<br />
als Programme auf der Grundlage expliziter atomarer Operationen<br />
Verhaltenssicht eines Systemes zur <strong>Modellierung</strong> der Benutzererwartungen und der Prozesse
2. Für jede Klasse bestimmen:<br />
was tut oder wei diese Klasse ?<br />
welche anderen Klassen benötigen diese Fähigkeiten ?<br />
stimmt die Rolle (Anbieter / Kunde) der Klasse ? (z.B. phys. Geräte sind typischerweise Anbieter)<br />
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 72<br />
Prozeßbeschränkungen technologische Beschränkungen, Beschränkungen der Technik, Beschränkungen<br />
der Kommunikation<br />
Verhaltensanforderungen Prozeßanforderungen, Prioritäten, Leistungsanforderungen, Zeit,<br />
fail-safety, safety, negotiale Anforderungen (was sollte keinesfalls passieren), ...<br />
Verhalten als Basisaktivitäten des Systems; komplexes Verhalten als Teilsysteme;<br />
Definition von Verhalten über Programme über Aktivitäten<br />
Benennung von Verhalten z.B. input, output, verify, activate, calculate, terminate, logische<br />
Ableitung<br />
Erweiterungen Luxus am Anfang<br />
Flexible Systeme<br />
Kontrolle der Erwartungen, Einbettungen<br />
Aktionsdiagramme definieren Verhaltensmuster<br />
Systemerweiterungen inkrementelle<br />
CRC Cards.<br />
CRC = Class - Responsibility - Collaboration<br />
innerhalb einer Geschäftsprozeschicht: keine Interface-Spez.<br />
Operationen: prinzipielle Verantwortlichkeiten einer Klasse<br />
• Verantwortlichkeit<br />
high-level Beschreibung des Zieles der Klasse keine Orientierung auf Daten, Prozesse<br />
Darstellung des Zieles, Motivation<br />
• Kollaboration ( (in Zusammenarbeit mit) Verantwortlichkeiten mit anderen Klassen<br />
Verbindungen mit anderen Klassen<br />
Trick: auf Karteikarten kann nur begrenzte Information.<br />
Günstig für Beschreibung der Schnittstellen der Klassen, insbesondere deren Verhalten, sowie<br />
bei Teamentwicklung. Anwendungsfall durch ein oder mehrere Karten<br />
• Kooperationen zwischen Objekten<br />
Objekt kann Verantwortlichkeit selbst erfüllen vs. benötigt Fähigkeiten anderer Objekte (–¿<br />
Kooperation)<br />
Kooperationen modellieren die Interaktion zwischen Objekten (Daten- und Kontrollflu)<br />
Rolle der Objekte (Anbieter / Kunde) bezüglich der Kooperation wird bestimmt<br />
(abgeschlossene) Teilsysteme können identifiziert werden<br />
Kooperationen finden<br />
1. Für jede Verantwortlichkeit einer Klasse überlegen:<br />
kann die Klasse die Verantwortlichkeit selbst erfüllen ?<br />
falls nicht: welche Informationen /Fähigkeiten werden benötigt und welche andere Klasse stellt<br />
diese bereit ?
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 73<br />
<strong>3.</strong> weitere Beziehungen zwischen den Klassen analysieren<br />
besteht-aus (Aggregation)<br />
Komposition<br />
Behälter-Klassen (z.B. Array, geordnete Menge)<br />
kennt (Assoziation)<br />
Benutzung<br />
“hole Information von” Kooperationen<br />
hängt-ab-von<br />
gibt Hinweise auf Kooperationsketten<br />
<strong>3.</strong>5.5 Abstrakte Zustandsmaschinen<br />
Das <strong>Datenbank</strong>-Schema definiert die Strukturierung der <strong>Datenbank</strong>. Ein Zustand der <strong>Datenbank</strong> kann<br />
durch eine Modifikation partiell geändert werden. Änderungsoperationen T (s 1 , ..., s n ) := t vom<br />
Teiltyp T ′ von T basieren auf Anfragen. Sie sind auf einem Objekt einer Klasse T C definiert, falls<br />
| σ T ′ =(s 1 ,...,s n)(T C ) | ≤ 1 gilt.<br />
Eine Menge U = {T i (s i,1 , ..., s i,ni ) := o i |1 ≤ i ≤ m} von objekt-basierten Änderungsoperationen<br />
ist konsistent, falls aus T i (s i,1 , ..., s i,ni ) = T j (s j,1 , ..., s j,nj ) für 1 ≤ i < j ≤ m die Gleichheit<br />
o i = o j folgt.<br />
Das Resultat der Ausführung einer konsistenten Menge U von Änderungsoperationen führt zu<br />
einer Zustandsänderung der <strong>Datenbank</strong> ER C zu ER C + U<br />
{<br />
(ER C Update(Ti , s<br />
+ U)(o) =<br />
i,1 , ..., s i,ni , o i ) falls T i (s i,1 , ..., s i,ni ) := o i ∈ U<br />
ER C (o)<br />
andernfalls<br />
für Objekte o of ER C .<br />
Ein parametrisiertes Programm r(x 1 , ..., x n ) = P der Stelligkeit n besteht aus einem Programmnamen<br />
r, einer Transitionsregel P und einer Menge {x 1 , ..., x n } von freien Variablen von P .<br />
Eine <strong>Datenbank</strong> ER C ist ein Modell von φ (kurz bezeichnet als ER C |= φ ) falls [[φ]] ERC<br />
ζ<br />
= true<br />
für alle Variablenbelegungen ζ für die freien Variablen von φ.<br />
Eine Workflow-Maschine W = (ER, ER C 0<br />
, P, Σ) basiert auf einem <strong>Datenbank</strong>-Schema ER,<br />
einer initialen <strong>Datenbank</strong> ER C 0<br />
, einer Menge von parametrisierten Programmen und einem ausgezeichneten<br />
Programm, das Hauptprogramm genannt wird, sowie den dynamischen Integritätsbedingungen.<br />
Eine Transitionsregel P führt zu einer Menge U von Änderungsoperationen in einem Zustand<br />
ER C , falls dieser konsistent ist. Sie verändert den Zustand der <strong>Datenbank</strong> mit einer Variablenbelegung<br />
ζ zu yields(P, ER C , ζ, U).<br />
Die Semantik einer Transitionsregel wird durch einen Kalkül mit Regeln der Form<br />
Voraussetzung 1 , ..., Voraussetzung n<br />
Folgerung<br />
Bedingung<br />
definiert.<br />
Wir verzichten hier auf die vollständige Angabe der Semantik und verweisen auf die Literatur. Als<br />
Beispiel führen wir die folgenden Regeln an, ohne auf den Beweis dieser Regeln einzugehen:<br />
yields(P, ER C , ζ, U) , yields(Q, ER C , ζ, V)<br />
yields(DO P PAR Q, ER C , ζ, U ∪ V)<br />
U ∪ V<br />
konsistent<br />
Die Konsistenzbedingung kann weggelassen werden, wenn man die Theorie der partiell-geordneten<br />
Durchläufe für ASM anwendet. Wir wollen jedoch hier nicht im Detail auf die Theorie eingehen.<br />
yields(P, ER C , ζ[x ↦→ a], U)<br />
yields(LET x = t IN P DO P , ER C , ζ, U)<br />
wobei<br />
a = [[t]] ERC<br />
ζ<br />
∀ a ∈ I : yields(P, ER C , ζ[x ↦→ a], U a )<br />
yields(FOR ALL x WITH φ DO P , ER C , ζ, ⋃ a∈I U wobei I = range(x, φ, ER C , ζ)<br />
a)<br />
Der Wertebereich range(x, φ, ER C , ζ)) ist definiert durch die Menge {o ∈ ER C | [[φ]] ERC =
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 74<br />
yields(CHOOSE x WITH φ DO P , ER C , ζ, ∅)<br />
falls<br />
range(x, φ, ER C , ζ) = ∅<br />
yields(P, ER C , ζ, U) , yields(Q, ER C + U, ζ, V)<br />
yields(DO P ; Q , ER C , ζ, U ⊕ V)<br />
falls U konsistent ist<br />
yields(P, ER C , ζ, U)<br />
yields(DO P ; Q , ER C , ζ, U)<br />
falls U inkonsistent ist<br />
yields(SKIP , ER C , ζ, ∅)<br />
yields(f(s 1 , ..., s n ) = t , ER C , ζ, (Update(l, v))<br />
wobei<br />
l = f([[s 1 ]] ERC<br />
ζ , ..., [[s n ]] ERC<br />
ζ ) und v = [[t] ERC<br />
ζ<br />
yields(P, ER C , ζ, U)<br />
yields(IF φ THENP ELSE Q , ER C , ζ, U)<br />
falls<br />
[[φ]] ERC<br />
ζ<br />
= true<br />
yields(Q, ER C , ζ, V)<br />
yields(IF φ THENP ELSE Q , ER C , ζ, V)<br />
falls<br />
[[φ]] ERC<br />
ζ<br />
= false<br />
yields(P t 1,...,t n<br />
x 1 ,...,x n<br />
, ER C , ζ, U)<br />
yields(r(t 1 , ..., t N ) , ER C , ζ, U)<br />
mit<br />
r(t 1 , ..., t n ) = P<br />
Die angegebene Workflow-Maschine erlaubt eine allgemeine Spezifikation des Verhaltens des <strong>Datenbank</strong>systems.<br />
Mit dieser Grundlage können wir eine pragmatischere Spezifikationssprache im weiteren<br />
verwenden.<br />
<strong>3.</strong>5.6 Dynamische Integritätsbedingungen<br />
Dynamische Integritätsbedingungen werden in der Literatur meist aufgrund ihrer Kompliziertheit<br />
weggelassen. Sie sind jedoch für die <strong>Datenbank</strong>-Entwicklung nicht minder wichtig. Deshalb führen<br />
wir auch einige Klassen explizit ein.<br />
Wir betrachten dazu temporale Klassen vom Typ R:<br />
Jedem potentiellen Objekt o von dom(R) kann eine Lebenszeit l R (o) ⊆ IN in der <strong>Datenbank</strong> zugeordnet<br />
werden. Damit können wir<br />
• temporale Klassen (R C , l R ) und<br />
• ihre Schnappschüsse S(i, R C , l R ) = {o ∈ dom(R)|i ∈ l R (o)}<br />
einführen.<br />
Gegeben seien eine Formel α über R, eine temporale Klasse (R C , l R ) über R, und Schnappschüsse<br />
S(0, R C , l R ), ...,S(i, R C , l R ), ... S(maxT, R C , l R ).<br />
Wir können nun eine Erfüllbarkeit von Formeln analog zur Modallogik definieren.<br />
Ein Zeitrahmen ZR besteht aus einem Paar (T S, W ) von Intervallen von IN und einer binären Relation<br />
W über T S. Wir bezeichnen mit maxT S den maximalen Zeitpunkt von T S und mit minT S den<br />
minimalen Zeitpunkt. Der einfachste Zeitrahmen ist das Intervall T S = [0, maxT S] betrachtet. Die<br />
binäre Relation W stellt eine Erreichbarkeit von Intervallen untereinander her. Wir sind damit in der<br />
Lage, Zeiträume zu betrachten und ggf. auch voneinander zu separieren.<br />
• Die Gültigkeit von α in einem Schnappschuß S(i, R C , l R ) ist induktiv wie für statische Integritätsbedingungen<br />
definiert und wird mit (R C , l R , i) |= α notiert.<br />
• Die Formel α is notwendig gültig in (R C , l R ), zu einem Zeitpunkt i ∈ I, I ∈ T S und für einen<br />
Zeitrahmen ZR falls (R C , l R , i ′ ) |= α für alle Intervalle I, I ′ mit (I, I ′ ) ∈ W und alle<br />
Zeitpunkte i ′ ∈ I ∪ I ′ .<br />
Wir notieren dies mit (R C , l R , i, ZR) |= ✷α bzw. (R C , l R , I, ZR) |= ✷α<br />
Die Formel ist gültig in jedem Zeitpunkt des Intervalls I, dem i angehört, und in jedem Zeitpunkt,<br />
der durch W aus I erreicht werden kann. In der Modallogik wird zwischen der Gültigkeit
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 75<br />
• Eine Formel α ist notwendig gültig in (R C , l R ) und ZR ab I 1 bis zu I 2 für I 1 , I 2 ∈ T S<br />
falls (R C , l R , i) |= α für alle Intervalle I ′ mit (I 1 , I ′ ) ∈ W bzw. (I ′ , I 2 ) ∈ W und<br />
i ∈ I 1 ∪ I 2 ∪ I ′ .<br />
Wir bezeichnen die zeitweilige volle Gültigkeit mit (R C , l R , [I 1 , I 2 ], ZR) |= ✷α .<br />
Wir können damit die Gültigkeit zwischen Phasen definieren.<br />
• Die Formel α ist gültig in (R C , l R ) und ZR falls (R C , l R , i) |= α für jeden Zeitpunkt i<br />
jedes Intervalls I des Zeitrahmens (bezeichnet mit (R C , l R , ZR) |= α ).<br />
In diesem Fall ist α eine statische Integritätsbedingung, falls ⋃ I∈T S<br />
I = [minT S, maxT S].<br />
• Die Formel α ist möglich gültig in (R C , l R ) und ZR falls für ein i ∈ ⋃ I∈T S I (RC , l R , i) |=<br />
α (bezeichnet mit (R C , l R , ZR) |= ✸α ).<br />
Besitzt ein Zeitrahmen ZR Unterbrechungen, dann wird für die Formel α keine Forderung erhoben.<br />
Ein Zeitrahmen wird für die Implementationsschicht direkt durch Phasen repräsentiert. Damit<br />
kann die Gültigkeit von Formeln und die Zulässigkeit von Prozessen zu gewissen Zeitpunkten direkt<br />
modelliert werden.<br />
Wir können damit auch unterschiedliche Klassen von dynamischen Integritätsbedingungen einführen.<br />
Dafür werden der Zeitrahmen ZR Schritt = ( { {i} |i ∈ IN } , { ({i}, {(i + 1)}) |i ∈ IN }) und<br />
ZR Punkt = ( { {i} |i ∈ IN } , ∅) , sowie ZR Voll = ( IN , IN × IN) eingeführt.<br />
Transitionsbedingung: Eine Formel α heißt Transitionsbedingung, falls α notwendig gültig in allen<br />
Intervalle von ZR Schritt ist.<br />
Wir notieren Transitionsbedingungen auch durch α −→ next α .<br />
Allgemeine Vor- und Nachbedingung: Ein Paar von Formeln α und β heißt Vor- und Nachbedingungen<br />
falls aus (R C , l R , i, ZR Punkt ) |= ✷α die Gültigkeit von (R C , l R , i+1, ZR Punkt ) |= ✷β<br />
folgt.<br />
Wir notieren allgemeine Vor- und Nachbedingungen auch durch α −→ next β .<br />
Wird der Zeitrahmen durch die Anwendung eines Prozesses P oder Programmes P definiert,<br />
dann schreiben wir α −→ P β .<br />
Temporale Formeln sind mit (R C , l R , i, ZR Voll ) |= ✷β bzw. (R C , l R , i, ZR Voll ) |= ✸β im Sinne<br />
der Modallogik notwendig oder möglich gültig.<br />
In analoger Form können damit auch allgemeine Gültigkeiten temporaler Formeln eingeführt werden:<br />
∀ f : immer (in der Zukunft)<br />
∀ p : immer (in der Vergangenheit)<br />
∃ f : einmal (in der Zukunft)<br />
∃ p : einmal (in der Vergangenheit).<br />
U(α, β) :<br />
α ist gültig bis β gültig wird.<br />
Weiche (deontische) Integritätsbedingungen werden für ZR Schrit eingeführt:<br />
Obligation: Eine Obligation Oα ist durch die Gültigkeit von (R C , l R , 1, ZR Schritt ) |= ✷α definiert.<br />
Erlaubnis: Eine Erlaubnis P α ist durch die Gültigkeit von (R C , l R , 1, ZR Schritt ) |= ✸α definiert.<br />
Verbot: Ein Verbot F α ist durch die Gültigkeit von (R C , l R , 1, ZR Schritt ) |= ✷¬α definiert.<br />
Wir können daraus direkt einige Ableitungsregeln ableiten:
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 76<br />
KD3 : P α ↔ ¬O¬α<br />
KD4 : F α ↔ ¬P α<br />
Die Erlaubnis ist dual zur Obligation.<br />
Verboten heißt “nicht erlaubt”.<br />
Weitere allgemeingültige Formeln der deontischen Logik sind z.B.:<br />
• Oα ↔ ¬P ¬α<br />
• O(α ∧ β) ↔ Oα ∧ Oβ<br />
• ¬(Oα ∧ O¬α)<br />
• P (α ∨ β) ↔ P α ∨ P β<br />
• (Oα ∨ Oβ) → O(α ∨ β)<br />
• Oα → O(α ∨ β)<br />
• P (α ∧ β) → P α ∧ P β<br />
• F α → F (α ∧ β)<br />
• (Oα ∧ P β) → P (α ∧ β)<br />
• (Oα ∧ O(α → β)) → Oβ<br />
• (P α ∧ O(α → β)) → P β<br />
• (F β ∧ O(α → β)) → F α<br />
• F β ∧ F r ∧ O(α → (β ∨ γ)) → F α<br />
• ¬(O(α ∨ β) ∧ F α ∧ F β)<br />
• (Oα ∧ O((α ∧ β) → γ)) → O(β → γ)<br />
• O(¬α → α) → Oα<br />
• Oβ → O(α → β)<br />
• F α → O(α → β)<br />
• O¬α → O(α → β)<br />
• ¬α → (α → Oβ)<br />
• ¬O(α ∧ ¬α)<br />
• (Oα ∧ O(α → β) ∧ (¬α → O¬β) ∧ ¬α) ↔ false<br />
• α → β / Oα → Oβ<br />
Wir werden uns jedoch im weiteren auf Transitionsbedingungen und Vor- und Nachbedingungen<br />
konzentrieren, sowie auf weiche Integritätsbedingungen der deontischen Logik.<br />
<strong>3.</strong>5.7 Verhaltensoptimierung
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 77<br />
<strong>3.</strong>6 Schrittweise <strong>Modellierung</strong> an einem Beispiel<br />
Angaben<br />
zur Reise<br />
Reisedaten<br />
Reiseablaufdaten<br />
Kostenüberweisung<br />
Finanzdaten<br />
Kostenabrechnungsdaten<br />
Reisekostenanerkennung<br />
Abbildung 21: Die Grobstruktur der Anwendung<br />
Storyschritt<br />
Vertreter<br />
✻<br />
❄<br />
❄<br />
Akteur<br />
✛<br />
Rolle<br />
✲<br />
Sicht<br />
Abbildung 22: Das Akteurmodell für die Geschäftsprozeßschicht
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 78<br />
Verbuchung<br />
✻<br />
(1,1)<br />
Überweisung<br />
Genehmigung<br />
Abrechnung<br />
abgerechnet durch<br />
(1,n) (1,1)<br />
Antragsteller ✛ beantragt ✲<br />
❄<br />
(1,n)<br />
Dienstreise<br />
Genehmigung<br />
Reiseverlauf<br />
Abbildung 23: Grobdarstellung der Struktur der Anwendung<br />
Abrechnungssicht<br />
Beantragungssicht<br />
Sicht für allgemeine Verbuchung<br />
Abbildung 24: Sichtenskizze für unsere Anwendung<br />
Beantragung ✲ Ausfüllen ✲ Befürwortung ✲ Genehmigung<br />
❄<br />
Abrechnung<br />
❄<br />
Verbuchung ✲ Genehmigung<br />
der Abrechnung<br />
✲<br />
Kontrolle der<br />
Abrechnung,<br />
Berechnung<br />
der Kostensätze<br />
✲<br />
Genehmigung der<br />
Verbuchung<br />
❄<br />
Verrechnung ✲ Zuordnung zum<br />
Abrechnungsmodus<br />
✯<br />
✲<br />
❥<br />
Überweisung<br />
Kassenbereitstellung<br />
Rückforderung
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 79<br />
Antragsteller Vorges. des Antragst. Dekan<br />
Beantragung ✲ Ausfüllen ✲ Befürwortung ✲ Genehmigung<br />
❄ Antragsteller<br />
Abrechnung<br />
❄<br />
Dekan<br />
Verbuchung ✲ Genehmigung<br />
der Abrechnung<br />
✲<br />
Sachbearb. X<br />
Kontrolle der<br />
Abrechnung,<br />
Berechnung<br />
der Kostensätze<br />
✲<br />
Sachbearb. Y<br />
Genehmigung der<br />
Verbuchung<br />
❄<br />
Sachbearb. X<br />
Verrechnung ✲ Zuordnung zum<br />
Abrechnungsmodus<br />
✯<br />
✲<br />
❥<br />
Sachbearb. X<br />
Überweisung<br />
Kassenbereitstellung Kassiererin<br />
RückforderungSachbearb. X<br />
Abbildung 26: Themen und Akteuren für Behandlung des Dienstreiseantrages (Normalverfahren)<br />
Akteur<br />
✛<br />
Rolle<br />
✲ Dialogschritte ✛<br />
zugeordnete<br />
✲Sichtenelemente<br />
✻<br />
✻<br />
❄ Vertreter ❄<br />
❄<br />
Rechte<br />
berechnet<br />
durch<br />
Abbildung<br />
❄<br />
Handlungsschritte ✛<br />
In<br />
❄<br />
✲ Skelettelement<br />
Abbildung 27: Das Akteurmodell für die Aktionsschicht<br />
Beantragungssicht Genehmigungssicht 1 Genehmigungssicht 2<br />
Beantragung ✲ Ausfüllen ✲ Befürwortung ✲ Genehmigung<br />
❄Abrechnungssicht<br />
Abrechnung<br />
❄<br />
Genehmigungssicht 3<br />
Verbuchung ✲ Genehmigung<br />
der Abrechnung<br />
✲<br />
Verbuchungssicht 1<br />
Kontrolle der<br />
Abrechnung,<br />
Berechnung<br />
der Kostensätze<br />
✲<br />
Genehmigungssicht 4<br />
Genehmigung der<br />
Verbuchung<br />
❄<br />
Verrechnungssicht 1 Verrechnungssicht 2<br />
✯ Überweisung<br />
Verrechnung ✲ Zuordnung zum ✲<br />
Verrechnungssicht 3<br />
Kassenbereitstellung<br />
Abrechnungsmodus
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 80<br />
Antragsteller<br />
≈ (1, 10)<br />
200 (1, n)<br />
500 ✛<br />
2000<br />
≈ (1, 2)<br />
(1, 30)<br />
Reise<br />
beantragt<br />
❄<br />
1000<br />
5000<br />
30000<br />
≈ (1, 1)<br />
(0, 1)<br />
✛<br />
wird<br />
abgerechnet<br />
(Vorschlag)<br />
(1, 50)<br />
❄<br />
Verbuchung 100<br />
200<br />
300<br />
Abbildung 29: Erster Entwurf für die Beantragungssicht<br />
System Historie Optionen Fenster<br />
Antragstellerdaten Reisedaten Verbuchungsdaten<br />
Name<br />
Vorname<br />
Institut<br />
Lehrstuhl<br />
Wohnort<br />
Dienstort<br />
Datum<br />
Unterschrift<br />
Vergüt.-stufe<br />
Reisek.-stufe<br />
f 1(name,vorname)<br />
f 2 (name,vorname)<br />
Abbildung 30: Dialogobjekt zur Darstellung von Antragstellerdaten für Lehrstuhlanträge<br />
System Historie Optionen Fenster<br />
Antragstellerdaten Reisedaten Verbuchungsdaten<br />
Name<br />
Vorname<br />
Institut<br />
Lehrstuhl<br />
Ziel<br />
Dauer - von<br />
Dauer - bis<br />
Zweck<br />
Weitere<br />
Teilnehmer<br />
Zus.hang zu<br />
Privatreise<br />
Beförd.-mittel<br />
Poliz. Kennz.<br />
bei Privat PkW
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 81<br />
Auto<br />
0<br />
30<br />
3000<br />
≈ (1,1)<br />
(1,2)<br />
≈ (1,1)<br />
(0,4)<br />
≈ (1,200)<br />
(1,n)<br />
✻<br />
Benutzt<br />
≈ (1,1)<br />
(0,4)<br />
Wohnort<br />
✻ Privatzweck<br />
Dienstort<br />
AHatV<br />
PolKZ<br />
Art<br />
1<br />
3<br />
4<br />
≈ (1,1)<br />
(1,4)<br />
≈ (1,10)<br />
(1,n)<br />
Ort<br />
zugeordnet<br />
zu<br />
Von Bis Zweck<br />
beantragt<br />
Land<br />
Reisekostenstufe<br />
≈ (1,2)<br />
(1,30)<br />
✛≈ (0,1)<br />
(0,2)<br />
AntrDatum<br />
0<br />
1000<br />
∞<br />
✛<br />
≈ (1,1)<br />
(1,3)<br />
✲<br />
≈ (20,80)<br />
(0,n)<br />
Name<br />
≈ (10,40)<br />
(0,n)<br />
✻<br />
Kostenstelle<br />
Beförderungsmittel<br />
Verbuchung<br />
100<br />
200<br />
300<br />
Titel<br />
<br />
Mögliche<br />
Reise<br />
20<br />
90 ✛<br />
150<br />
≈ (1,1)<br />
(1,2)<br />
Vorschuß(Höhe,Auszahlart)<br />
≈ (0,n)<br />
(0,n)<br />
✲<br />
In<br />
❄<br />
Vergütungsgruppe<br />
Name Vorname<br />
❄ ✢<br />
Antragsteller<br />
200<br />
500 ✛<br />
2000<br />
Reiseziele<br />
Art<br />
1<br />
3<br />
8<br />
≈ (2,5)<br />
(0,n)<br />
✲<br />
Fakultät<br />
Nr<br />
1<br />
5<br />
5<br />
Abbildung 32: Beantragung einer Dienstreise mit Verbuchung über den Lehrstuhl<br />
Auto<br />
0<br />
30<br />
3000<br />
≈ (1,1)<br />
(1,2)<br />
≈ (1,1)<br />
(0,4)<br />
≈ (1,200)<br />
(1,n)<br />
✻<br />
Benutzt<br />
≈ (1,1)<br />
(0,4)<br />
Wohnort<br />
✻ Privatzweck<br />
Dienstort<br />
AHatV<br />
PolKZ<br />
Art<br />
1<br />
3<br />
4<br />
≈ (1,1)<br />
(1,4)<br />
≈ (1,10)<br />
(1,n)<br />
Ort<br />
zugeordnet<br />
zu<br />
Von Bis Zweck<br />
beantragt<br />
Lehrstuhl<br />
❄<br />
Vergütungsgruppe<br />
Name Vorname<br />
❄ ✢<br />
Antragsteller<br />
200<br />
500 ✛<br />
2000<br />
Reiseziele<br />
Land<br />
Reisekostenstufe<br />
≈ (1,2)<br />
(1,30)<br />
✛≈ (0,1)<br />
(0,2)<br />
AntrDatum<br />
0<br />
1000<br />
∞<br />
✛<br />
≈ (1,1)<br />
(1,3)<br />
✲<br />
≈ (20,80)<br />
(0,n)<br />
Name<br />
Lehrstuhl<br />
≈ (10,40)<br />
(0,n)<br />
✻<br />
Kostenstelle<br />
Beförderungsmittel<br />
Verbuchung<br />
100<br />
200<br />
300<br />
Titel<br />
20<br />
90 ✛<br />
150<br />
≈ (1,1)<br />
(1,2)<br />
Vorschuß(Höhe,Auszahlart)<br />
≈ (0,n)<br />
(0,n)<br />
✲<br />
In<br />
<br />
Mögliche<br />
Beförderungsmittel<br />
Art<br />
1<br />
3<br />
8<br />
≈ (2,5)<br />
(0,n)<br />
✲<br />
Fakultät<br />
Nr<br />
1<br />
5<br />
5
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 82<br />
Auto<br />
0<br />
30<br />
3000<br />
≈ (1,1)<br />
(1,2)<br />
≈ (1,1)<br />
(0,4)<br />
≈ (1,200)<br />
(1,n)<br />
✻<br />
Benutzt<br />
≈ (1,1)<br />
(0,4)<br />
Wohnort<br />
✻ Privatzweck<br />
Dienstort<br />
AHatV<br />
PolKZ<br />
Art<br />
1<br />
3<br />
4<br />
≈ (1,1)<br />
(1,4)<br />
≈ (1,10)<br />
(1,n)<br />
Ort<br />
zugeordnet<br />
zu<br />
Von Bis Zweck<br />
beantragt<br />
❄<br />
Vergütungsgruppe<br />
Name Vorname<br />
❄ ✢<br />
Antragsteller<br />
200<br />
500 ✛<br />
2000<br />
Reiseziele<br />
Land<br />
Reisekostenstufe<br />
≈ (1,2)<br />
(1,30)<br />
✛<br />
AntrDatum<br />
0<br />
1000<br />
∞<br />
✛<br />
≈ (1,1)<br />
(1,3)<br />
✲<br />
≈ (20,80)<br />
(0,n)<br />
Name<br />
Verbuchung<br />
Lehrstuhl<br />
20<br />
90 ✛<br />
150<br />
≈ (1,1)<br />
(1,2)<br />
Kostenstelle<br />
≈ (0,1)<br />
(0,2)<br />
≈ (0,n)<br />
(0,n)<br />
✲<br />
In<br />
Vorschuß<br />
(Höhe,Auszahlart)<br />
Art<br />
1<br />
3<br />
8<br />
≈ (2,5)<br />
(0,n)<br />
✲<br />
Fakultät<br />
≈ (10,40)<br />
(0,n)<br />
✻<br />
Nr<br />
<br />
Mögliche<br />
Beförderungsmittel<br />
Beförderungsmittel<br />
100<br />
200<br />
300<br />
Titel<br />
1<br />
5<br />
5<br />
Abbildung 34: Beantragung einer Dienstreise mit Verbuchung über die Fakultät<br />
DekanBestät<br />
✲ LehrstGenehm<br />
DekGenehm<br />
Person ✛ Antragsteller✛<br />
beantragt ✛<br />
2<br />
❄<br />
LVerbuch<br />
❄<br />
LBefürw<br />
✻<br />
✻<br />
✻<br />
❄<br />
❄<br />
❄<br />
ArbeitetAn<br />
Reise<br />
LehrstFonds<br />
✯<br />
FVerbuch<br />
leitet<br />
✲<br />
❄<br />
Lehrstuhl<br />
✛<br />
LHatFond<br />
✻<br />
DekanVonF<br />
FakVonL<br />
✲<br />
✲<br />
Fakultät<br />
✛<br />
FakHatFond<br />
✲<br />
❄<br />
FakFonds
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 83<br />
Beantragungssicht<br />
Genehmigungssicht1<br />
Genehmigungssicht2<br />
Abrechnungssicht<br />
Genehmigungssicht3<br />
Verbuchungssicht1<br />
Genehmigungssicht4<br />
...<br />
Verrechnungssicht1<br />
Verrechnungssicht4<br />
❘ ❄ ✠<br />
Zentrale<br />
Beantragungssicht<br />
❘ ❄ ✠<br />
Zentrale<br />
Verbuchungssicht<br />
3 ❯<br />
❄<br />
Integriertes <strong>Datenbank</strong>schema zum Dienstreiseantrag<br />
❘ ❄ ✠<br />
Zentrale<br />
Verrechnungssicht<br />
✙<br />
Abbildung 36: Sichtenintegration in unserer Anwendung<br />
Benutzersichten<br />
zur Vereinfachung<br />
des Zugriffs<br />
Beantragungssicht<br />
Genehmigungssicht1<br />
Genehmigungssicht2<br />
...<br />
Sicherheitssichten<br />
zur Kontrolle<br />
des Zugriffs<br />
❄ ❄ ❄<br />
Zugriffsbeschr.<br />
Beantragungssicht<br />
Zugriffsbeschr.<br />
Genehmigungssicht1<br />
Zugriffsbeschr.<br />
Genehmigungssicht2<br />
...<br />
Zentrale<br />
Sichten<br />
zur Darstellung<br />
der Unabhängigkeit<br />
❘ ❄ ✠<br />
Zentrale<br />
Beantragungssicht<br />
...<br />
Integriertes<br />
Schema<br />
zur Darstellung<br />
der Speicherung<br />
3<br />
Integriertes <strong>Datenbank</strong>schema zum Dienstreiseantrag<br />
Abbildung 37: Ausschnitt aus der Sichtenarchitektur mit Sicherheitssichten
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 84<br />
V 1<br />
V 2<br />
Reisen{(Ort, Land, Zweck, Von, Bis) }<br />
Reisezeitraum (Von, Bis)<br />
Reisende{ (Name, Vorname) }<br />
Dienstreisender<br />
Dienstreisen<br />
Name Vorname<br />
Ort Land Zweck<br />
✛<br />
V 3<br />
Von<br />
führt<br />
durch<br />
Bis<br />
✲<br />
Dienstreisender<br />
Dienstreise<br />
Name Vorname Ort Land Zweck<br />
Abbildung 38: Zwei verschiedene Sichten auf eine Dienstreise und eine integrierte Sicht
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 85<br />
Auto<br />
Vergütungsgruppe<br />
✻<br />
✻<br />
Benutzt<br />
AHatV<br />
DekanBestät<br />
✲ LehrstGenehm<br />
DekGenehm<br />
❄<br />
❥<br />
Person ✛ Antragsteller<br />
✛<br />
beantragt<br />
✛<br />
2<br />
❄<br />
LVerbuch<br />
❄<br />
LBefürw<br />
✻<br />
✻<br />
✻<br />
leitet<br />
✲<br />
ArbeitetAn<br />
❄<br />
Lehrstuhl<br />
✻<br />
✛<br />
❄<br />
Mögliche<br />
Reise<br />
LHatFond<br />
✯<br />
❘<br />
❫<br />
❄<br />
LehrstFonds<br />
Reiseziele<br />
Beförderungsmittel<br />
❄<br />
FVerbuch<br />
DekanVonF<br />
FakVonL<br />
✲<br />
✲<br />
Fakultät<br />
✛<br />
FakHatFond<br />
✲<br />
❄<br />
FakFonds<br />
Abbildung 39: Integration der Beantragungs- und Genehmigungssichten bei Verbuchung über den<br />
Lehrstuhl bzw. die Fakultät<br />
Hauptmenü<br />
✲ Beantragungsmenü<br />
3 ...<br />
❥ ...<br />
✯<br />
✿<br />
✲<br />
3<br />
❥<br />
Antragsteller<br />
Reisedaten<br />
Verbuchungsvorschlag<br />
Befürwortung<br />
Genehmigung<br />
Abbildung 40: Die Organisation der Menüs für die Beantragung
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 86<br />
HERM und OLAP bzw. data warehouses<br />
Person<br />
OtherData<br />
Person<br />
Postal<br />
Person<br />
POBox<br />
<br />
✶<br />
❄<br />
Person<br />
Basic<br />
Data<br />
✻<br />
✮<br />
✐<br />
Person<br />
EmailURL<br />
Person<br />
SMTP<br />
Person<br />
PhoneFax<br />
Abbildung 41: HERM Representation of the Star Type Person<br />
CUBE A: PARTICIPANTS PER LECTURE AND DAY<br />
CUBE B: USAGE OF ROOMS PER DAY<br />
Lectures<br />
✛<br />
HeldOn<br />
✲<br />
Day<br />
Room<br />
✛<br />
Usage<br />
✲<br />
Day<br />
#Participants<br />
#TotalUsage<br />
Room#<br />
SCHEDULING SCHEMA ON UNIVERSITY AND EVENING LECTURES<br />
University<br />
Lecture<br />
✛<br />
Room<br />
✻<br />
Room#<br />
University<br />
Lectures<br />
✛<br />
HeldOn<br />
#Participants<br />
✲<br />
Working<br />
Day<br />
✻<br />
✲<br />
IsA Room ✛ ❄<br />
IsA<br />
General<br />
Purpose<br />
Room<br />
✻<br />
Room#<br />
Title<br />
IsA ✲ Day ✛<br />
Organized<br />
On<br />
✲<br />
Evening<br />
Lectures<br />
#Participants<br />
Abbildung 42: Scheduling Views on Lectures Given in a University
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 87<br />
Code<br />
Description<br />
Dimension<br />
Type<br />
✻<br />
Dimension<br />
OfType<br />
[Reason]<br />
FromDate<br />
ThruDate<br />
[Quantity]<br />
Brand<br />
Name<br />
Product<br />
Type<br />
Product<br />
Quality<br />
UOM<br />
UnitOf<br />
Measure<br />
2<br />
Product<br />
Obsolesence<br />
Product<br />
Substitute<br />
Consists<br />
Of<br />
Identification<br />
Type<br />
Item<br />
Variant<br />
✮<br />
Party<br />
Address<br />
✛<br />
✲<br />
■<br />
❦<br />
2<br />
✛<br />
may be<br />
converted in<br />
Conversion<br />
Factor<br />
AReplacementNeededFor<br />
SuperceededBy<br />
[Comment]<br />
[Instruction]<br />
[Comment]<br />
[QuantityUsed]<br />
ThruDate<br />
FromDate<br />
❥ ❥ ❘<br />
✲<br />
✲<br />
By UsedAs<br />
Additional Identifier<br />
(ManifacturerID |<br />
StockKeepingUnit |<br />
UniversalProductCode<br />
(American UPCA | European UPCE) |<br />
IntStandBookNumb ISBN))<br />
Id TypeCode Description<br />
PhysicalInventoryDate<br />
Quantity<br />
Reason<br />
[Comment]<br />
Dimension<br />
❑<br />
Converted<br />
❘<br />
✻<br />
✻<br />
Inventory<br />
Item ⊕<br />
❄<br />
Container<br />
⊕<br />
Product ✙<br />
Characteristic<br />
❄<br />
Product<br />
✲<br />
Color<br />
✻<br />
✻<br />
Code<br />
Description<br />
❘ Product<br />
Characterized<br />
WorkIn<br />
Progress<br />
Container<br />
Type<br />
Other<br />
Characteristic<br />
✕<br />
Base<br />
Product<br />
Price<br />
Discount<br />
Component<br />
PriceSequenceNum<br />
Specified<br />
For<br />
Surcharge<br />
Component<br />
MadeUpOf<br />
ProdCode Name [Comment]<br />
[IntroductionDate]<br />
[SalesDiscontinuationDate]<br />
[SupportDiscontinuationDate] [ManufSuggestRetailPrice]<br />
UsedIn<br />
WarehousedAt<br />
Id<br />
Organization<br />
Raw<br />
Material<br />
Additional<br />
✾<br />
❂<br />
Item<br />
✛ Item ✛<br />
Finished<br />
Good<br />
Identification<br />
Item<br />
Shrinkage ✲<br />
Overages<br />
[ReorderQuantity]<br />
[ReorderLevel]<br />
PhysicalOccurenceOf<br />
StorageFor<br />
SerialNumber<br />
QuantityOnHand<br />
Id<br />
✻<br />
ID<br />
[ThruQuantity]<br />
Service<br />
FromQuantity<br />
❄<br />
Quantity<br />
Price<br />
Component<br />
Break Type<br />
✻ ✕ ❃<br />
Discount<br />
Level<br />
❯<br />
❫ Product<br />
Component<br />
Price<br />
✗<br />
Code<br />
✠<br />
✛<br />
✻<br />
Priced<br />
By<br />
Prod<br />
Category<br />
Class<br />
❄<br />
Product<br />
Category<br />
Used To<br />
Define<br />
[ThruDate]<br />
[Price]<br />
FromDate<br />
[Percent]<br />
[Comment]<br />
[Comment]<br />
AvailableTruDate<br />
❘<br />
✌<br />
Product<br />
Supplier<br />
FromDate<br />
FromDate<br />
Description<br />
✛<br />
Costed<br />
By<br />
Producer<br />
Of<br />
[ThruDate]<br />
[Comment]<br />
PrimaryFlag<br />
[ThruDate]<br />
Code<br />
CompTypeCode<br />
Description<br />
Purchaser<br />
Of<br />
Location<br />
UsedToDefine<br />
Estimated<br />
Product<br />
Cost<br />
Market<br />
Interest<br />
❄<br />
Party<br />
Type<br />
✿<br />
Product<br />
Supplier<br />
✲ RatingType<br />
❘<br />
✒<br />
OptionalComponent<br />
DependentOn<br />
Supplier<br />
Cost<br />
RatingTypeCode<br />
❫<br />
✲<br />
Name<br />
FromDate<br />
Comment<br />
Description<br />
PartyTypeCode<br />
Party<br />
Type<br />
Description<br />
GeoAreaCode<br />
Geographic<br />
Boundary<br />
Name<br />
FromDate<br />
[ThruDate]<br />
PrefTypeCode<br />
Product<br />
Supplier<br />
Preference<br />
Description<br />
Description<br />
[TaxIdNum]<br />
UsedTo<br />
Define<br />
[ThruDate]<br />
From<br />
Id<br />
Code<br />
Description<br />
Abbildung 43: Pattern for Products
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 88<br />
Das <strong>Vorlesung</strong>sbeispiel:<br />
• volle ID-Entfaltung<br />
• rigides Nullwerte-Management<br />
• Separation von Schemadefintion und Integritätsbedingungen<br />
• minimale Indexunterstützung (nur Schl¨ssel (Primär- und Fremd-))<br />
• minimale Menge von Wertebereichen<br />
• vollständige Verflachung<br />
• Auflösung aller Cluster-Typen<br />
• Event-Nonseparation mit Surrogat-Auflösung<br />
• Einbettung von (0,1)-*-Beziehungen<br />
• Namensgenerierung mit Präfixerweiterung und vorgegebener Präfixmenge, Trennung durch<br />
als Delimiter<br />
-- Database Section<br />
-- ________________<br />
create database DB1_<strong>Vorlesung</strong>sbeipiel;<br />
-- DBSpace Section<br />
-- _______________<br />
-- Table Section<br />
-- _____________<br />
create table Studiengang (<br />
ID_Stu char(10) not null,<br />
SName char(1) not null,<br />
Betreuer char(1) not null,<br />
Pruefungsamt char(6) not null,<br />
ID_Ins char(10) not null,<br />
primary key (ID_Stu));<br />
create table Kurs (<br />
ID_Kur char(10) not null,<br />
KursNr char(7) not null,<br />
Bezeichnung char(20) not null,<br />
primary key (ID_Kur));<br />
create table Raum (<br />
ID_Rau char(10) not null,<br />
Gebaeude char(4) not null,<br />
Raumnr numeric(5) not null,<br />
primary key (ID_Rau));
create table eingeschrieben in (<br />
E_S_ID_Stu char(10) not null,<br />
ID_Stu char(10) not null,<br />
von date not null,<br />
bis date not null,<br />
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 89<br />
Telefon numeric(4) not null,<br />
IName char(1) not null,<br />
Sprecher char(15) not null,<br />
Fakultaet char(1) not null,<br />
primary key (ID_Ins));<br />
create table Semester (<br />
ID_Sem char(10) not null,<br />
Jahreszeit char(2) not null,<br />
Jahr numeric(4) not null,<br />
primary key (ID_Sem));<br />
create table Projekt (<br />
ID_Pro char(10) not null,<br />
Projektnr char(8) not null,<br />
Beschreibung varchar(90) not null,<br />
Bezeichnung char(20) not null,<br />
primary key (ID_Pro));<br />
create table Student (<br />
ID_Stu char(10) not null,<br />
ID_Per char(10) not null,<br />
MatrNr char(7) not null,<br />
primary key (ID_Stu),<br />
unique (ID_Per));<br />
create table Professor (<br />
ID_Pro char(10) not null,<br />
ID_Per char(10) not null,<br />
Spezialisierung char(1) not null,<br />
primary key (ID_Pro),<br />
unique (ID_Per));<br />
create table Person (<br />
ID_Per char(10) not null,<br />
Geburtsort char(15) not null,<br />
Adresse char(40) not null,<br />
Personenname char(25) not null,<br />
Geburtsdatum date not null,<br />
primary key (ID_Per));<br />
create table Betreuer (<br />
ID_Pro char(10) not null,<br />
ID_Stu char(10) not null,<br />
von date not null,<br />
bis date,<br />
Thema varchar(30) not null,<br />
primary key (ID_Pro, ID_Stu));
alter table Student add constraint FKPer_Stu<br />
foreign key (ID_Per)<br />
references Person;<br />
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 90<br />
ID_Stu char(10) not null,<br />
ID_Vor char(10) not null,<br />
Resultat char(10) not null,<br />
Note char(2),<br />
primary key (ID_Vor, ID_Stu));<br />
create table Projektmitarbeiter (<br />
ID_Pro char(10) not null,<br />
ID_Stu char(10) not null,<br />
P_P_ID_Pro char(10) not null,<br />
primary key (ID_Pro),<br />
unique (ID_Stu),<br />
unique (P_P_ID_Pro));<br />
create table <strong>Vorlesung</strong> (<br />
ID_Vor char(10) not null,<br />
Wochentag char(2) not null,<br />
Block char(2) not null,<br />
Nummer char(9) not null,<br />
ID_Pro char(10) not null,<br />
ID_Sem char(10) not null,<br />
ID_Rau char(10) not null,<br />
ID_Kur char(10) not null,<br />
primary key (ID_Vor));<br />
create table In (<br />
ID_Pro char(10) not null,<br />
Seit char(1) not null,<br />
ID_Ins char(10) not null,<br />
primary key (ID_Pro));<br />
create table wirkt mit (<br />
W_P_ID_Pro char(10) not null,<br />
ID_Pro char(10) not null,<br />
bis date not null,<br />
Kontraktnr char(6) not null,<br />
von date not null,<br />
primary key (ID_Pro, W_P_ID_Pro));<br />
-- Constraints Section<br />
-- ___________________<br />
alter table Studiengang add constraint FKverantwortlich fuer<br />
foreign key (ID_Ins)<br />
references Institut;<br />
--alter table Student add constraint<br />
-- check(exists(select * from eingeschrieben in<br />
-- where eingeschrieben in.E_S_ID_Stu = ID_Stu));
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 91<br />
-- where In.ID_Pro = ID_Pro));<br />
alter table Professor add constraint FKPer_Pro<br />
foreign key (ID_Per)<br />
references Person;<br />
alter table Betreuer add constraint FKBet_Stu<br />
foreign key (ID_Stu)<br />
references Student;<br />
alter table Betreuer add constraint FKBet_Pro<br />
foreign key (ID_Pro)<br />
references Professor;<br />
alter table eingeschrieben in add constraint FKein_Stu_1<br />
foreign key (ID_Stu)<br />
references Studiengang;<br />
alter table eingeschrieben in add constraint FKein_Stu<br />
foreign key (E_S_ID_Stu)<br />
references Student;<br />
alter table hoert add constraint FKhoer_Vor<br />
foreign key (ID_Vor)<br />
references <strong>Vorlesung</strong>;<br />
alter table hoert add constraint FKhoer_Stu<br />
foreign key (ID_Stu)<br />
references Student;<br />
alter table Projektmitarbeiter add constraint FKStu_Pro<br />
foreign key (ID_Stu)<br />
references Student;<br />
alter table Projektmitarbeiter add constraint FKPro_Pro<br />
foreign key (P_P_ID_Pro)<br />
references Professor;<br />
alter table <strong>Vorlesung</strong> add constraint FKliest<br />
foreign key (ID_Pro)<br />
references Professor;<br />
alter table <strong>Vorlesung</strong> add constraint FKim<br />
foreign key (ID_Sem)<br />
references Semester;<br />
alter table <strong>Vorlesung</strong> add constraint FKveranstaltet<br />
foreign key (ID_Rau)<br />
references Raum;<br />
alter table <strong>Vorlesung</strong> add constraint FKzu<br />
foreign key (ID_Kur)<br />
references Kurs;
create unique index IDBetreuer<br />
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 92<br />
alter table In add constraint FKIn_Ins<br />
foreign key (ID_Ins)<br />
references Institut;<br />
alter table wirkt mit add constraint FKwir_Pro_1<br />
foreign key (ID_Pro)<br />
references Projektmitarbeiter;<br />
alter table wirkt mit add constraint FKwir_Pro<br />
foreign key (W_P_ID_Pro)<br />
references Projekt;<br />
-- Index Section<br />
-- _____________<br />
create unique index ID<br />
on Studiengang (ID_Stu);<br />
create index FKverantwortlich fuer<br />
on Studiengang (ID_Ins);<br />
create unique index ID<br />
on Kurs (ID_Kur);<br />
create unique index ID<br />
on Raum (ID_Rau);<br />
create unique index ID<br />
on Institut (ID_Ins);<br />
create unique index ID<br />
on Semester (ID_Sem);<br />
create unique index ID<br />
on Projekt (ID_Pro);<br />
create unique index ID<br />
on Student (ID_Stu);<br />
create unique index FKPer_Stu<br />
on Student (ID_Per);<br />
create unique index ID<br />
on Professor (ID_Pro);<br />
create unique index FKPer_Pro<br />
on Professor (ID_Per);<br />
create unique index ID<br />
on Person (ID_Per);
create unique index IDwirkt mit<br />
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 93<br />
on Betreuer (ID_Stu);<br />
create index FKBet_Pro<br />
on Betreuer (ID_Pro);<br />
create unique index IDeingeschrieben in<br />
on eingeschrieben in (ID_Stu, E_S_ID_Stu);<br />
create index FKein_Stu_1<br />
on eingeschrieben in (ID_Stu);<br />
create index FKein_Stu<br />
on eingeschrieben in (E_S_ID_Stu);<br />
create unique index IDhoert<br />
on hoert (ID_Vor, ID_Stu);<br />
create index FKhoer_Vor<br />
on hoert (ID_Vor);<br />
create index FKhoer_Stu<br />
on hoert (ID_Stu);<br />
create unique index ID<br />
on Projektmitarbeiter (ID_Pro);<br />
create unique index FKStu_Pro<br />
on Projektmitarbeiter (ID_Stu);<br />
create unique index FKPro_Pro<br />
on Projektmitarbeiter (P_P_ID_Pro);<br />
create unique index ID<br />
on <strong>Vorlesung</strong> (ID_Vor);<br />
create index FKliest<br />
on <strong>Vorlesung</strong> (ID_Pro);<br />
create index FKim<br />
on <strong>Vorlesung</strong> (ID_Sem);<br />
create index FKveranstaltet<br />
on <strong>Vorlesung</strong> (ID_Rau);<br />
create index FKzu<br />
on <strong>Vorlesung</strong> (ID_Kur);<br />
create unique index FKIn_Pro<br />
on In (ID_Pro);<br />
create index FKIn_Ins<br />
on In (ID_Ins);
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 94<br />
on wirkt mit (ID_Pro);<br />
create index FKwir_Pro<br />
on wirkt mit (W_P_ID_Pro);
CAU Kiel, IfI, ISE β SS 2007 <strong><strong>Datenbank</strong>en</strong> I <strong>3.</strong> <strong>Datenbank</strong>-<strong>Modellierung</strong> 95<br />
Literaturhinweis<br />
Bernhard Thalheim: Entity-Relationship Modeling, Foundations of Database Technology. Springer,<br />
2000. ISBN 3-540-65470-4<br />
An die Teilnehmer der Veranstaltung wird der Verkauf des Buches zu einem ermäßigten Preis (80% bzw. weniger)<br />
durch das Sekretariat TIS organisiert. Bitte sprechen Sie persönlich bei Frau Kruse vor.<br />
Die folgenden Bücher sind als Ergänzung des Stoffes dieses Kapitels geeignet:<br />
Joachim Biskup: Grundlagen von Informationssystemen, Vieweg, 1995 1<br />
Das Skriptum zu <strong>Vorlesung</strong>en zu diesem Buch ist abgelegt unter:<br />
http://www.is.informatik.uni-kiel.de/∼thalheim/vorlesungen/biskup/Biskup.pdf<br />
Alfons Kemper, André Eickler: <strong>Datenbank</strong>systeme - Eine Einführung, 5. Auflage. Oldenbourg 2003<br />
Die Skripte zur <strong>Vorlesung</strong> sind abgelegt unter:<br />
http://www.is.informatik.uni-kiel.de/∼thalheim/vorlesungen/kemper/kapitel1.pdf — kapitel 1<strong>3.</strong>pdf<br />
Weitere Literaturquellen zu diesem Kapitel der <strong>Vorlesung</strong> sind:<br />
• Ramesh Elmasri, Sham B. Navathe: Fundamentals of Database Systems (4nd Edition), Benjamin/Cummings,<br />
Redwood City etc., 2004 (auch in Deutsch)<br />
• Jeffrey D. Ullman, Jennifer Widom: A First Course in Database Systems. Prentice-Hall 1997<br />
• Carlo Batini, Stefano Ceri, Shamkant Navathe: Conceptual Database Design - An Entity-Relationship<br />
Approach, Addison-Wesley, 1991<br />
• Toby J. Teorey: Database Modeling & Design, Morgan Kaufmann, 1998<br />
• Robert J. Muller: Database Design for Smarties - Using UML for Data Modeling, Morgan<br />
Kaufmann, 1999<br />
• David Harel, Michal Politi: Modeling Reactive Systems - the Statemate Approach, McGraw<br />
Hill, 1998<br />
• Frank Leymann, Dieter Roller: Production Workflow - Concepts and Techniques, Prentice Hall,<br />
1999