Vorlesung Datenbanken I 3. Datenbank-Modellierung - Technologie ...

Prof. Dr. rer.nat.habil. Bernhard Thalheim 

Information Systems Engineering 

Institute of Computer Science and Applied Mathematics 

Christian-Albrechts-University Kiel 

Olshausenstr. 40 

D - 24098 Kiel 

 

Vorlesung Datenbanken I 3. Datenbank-Modellierung 

SS 2007 

3 Datenbank-Modellierung (Spezifikation von Datenbanken) 

3.1 Das Entity-Relationship-Modell 

Viele OOA-Modelle sind falsch, weil sie zu komplex sind. Einfachheit, Kürze, Klarheit! 

Paradigmen 

formale Sprache \ Theorie Abstraktion Entwurf 

erfinden 

• 

verwirklichen 

• 

benutzen • • 

Es sind verschiedene Modelle möglich. Jedes Modell ist durch eine Menge von inhärenten Bedingungen 

gekennzeichnet. 

Begriffsgerüst ist nicht eindeutig verwendbar. Modelle dienen zur Kommunikation. 

Jeder benutzte Typ hat neben 

Konstruktor, Selektoren (für Retrieval) und Updatefunktionen, Korrektheitskriterien, default- 

Regeln auch 

eine Benutzerrepräsentation und eine physische Repräsentation. 

Günstig ist eine graphische Repräsentation. 

Unterstützung durch Werkzeuge 

Graphiken können auch durch Anschauung fehlleiten. 

Gesichtspunkte betont, einige in den Hintergrund 

3.1.1 Das erweiterte Entity-Relationship-Modell (informal) 

1. Seiendenklasse: Entity-Typ (Rechteck) 

2. Beziehungsklasse: Relationship-Typ (Raute) 

3. Attribut Komplexe Attribute 

4. Rolle als unärer Relationship-Typ (gekennzeichnet über Marke zur Auszeichnung der Rolle) 

5. Aggregation über verschiedene Konstruktoren: 

• Vereinigung 

E ... E’ new 

• Aggregation durch Beziehungsklasse, aufgefaßt als Seiendenklasse 

∧ 

E ←− ∨ −→ E’ new 

• Verallgemeinerung als Gruppenbildung (Clusterbildung) (über eine IsA-Beziehung mit

CAU Kiel, IfI, ISE β SS 2007 Datenbanken I 3. Datenbank-Modellierung 2 

• Spezialisierung als Partition mit Spezialisierungsbedingung (Partitionsbedingung) (Jedes 

Seiende aus E muß auch in (genau) einem E i sein) (genau eins: uniqueness constraint in 

NIAM) (E i -Aussonderung, E - Verallgemeinerung) 

E ⊆ E 1 ∪ ... ∪ E n 

• Abstraktion durch Unitbildung (Klassenbildung) 

6. Schlüsseldarstellung für einen Schlüssel 

7. Integritätsbedingungen 

8. Regeln 

• Viele-Eins-Bedingung (Jedes Seiende aus E steht mit höchstens einem Seiendem aus E ′ 

in Beziehung) ∧ 

E ←− 

(.,1) ∨ −→ E’ 

Zeichnung !! (Raum-Vorlesung) 

• Seinsbedingung (Existenzbeziehung) (jedes Seiende aus E steht mit mindestens einem 

Seiendem∧ 

aus E ′ in Beziehung) 

E ←− 

(1,.) ∨ −→ E’ 

Zeichnung !! (Raum-Vorlesung) 

• Verweisbedingung (Jedes Seiende aus E, das in einer Beziehung aus B vorkommt, ist 

auch Seiendes aus E ′′ ) 

E” 

∧ 

↑ 

IsA 

∨ 

E 

↓ 

←− 

B∧ 

∨ −→ E’ 

φ(t 1 , ..., t n ) steht für oder 

• Gesamtheitsregel in Zusammenhang mit einer Querysprache 

• Verneinungsregel - negation as failure oder closed-world-assumption 

• Sichtregel als Ableitungsregel 

definiert z.B. über logische Formeln oder and-or-Graphen 

✲ 

✯ 

als 

Empfänger 

gedeutete 

Stellen 

9. Formale Handlungen als dargestellt über Petri-Netze 

eingehende 

Sender 

als Erstellung 

gedeutete 

und Übertragung von 

Mitteilungen 

Stellen: 

Mitteilung 

Mitteilungen 

ermittelt 

gedeutete Transition 

Information 

Auslösung 

von 

anschließenden 

Handlungen 

✲ 

... and 

❥ 

✯ 

Transition 

...


• Information 

• Mitteilung 

• Verstehen 

Warum Relationship-Typen über Relationship-Typen: 

Universitätsbeispiel: 

1. Entity-Typ Person 

2. Aussonderungsbeziehung Student, Professor IsA Person 

3. Beziehungen Betreuer 

4. Partitionsbedingung Projektmitarbeiter 

5. Kardinalitätsbedingungen 

6. Darstellung von dynamischen Bedingungen und Handlungen 

7. Sichten über dem Schema mit Darstellung der abgeleiteten Attribut-, Entity- und Relationship- 

Typen 

Darauf aufbauend kann man auch weitere Bedingungen definieren. 

sowie weitere abgeleitete Typen: z.B. vorausgesetzte Fächer (falls Vorauss nur die direkte Beziehung 

darstellt) 

Spezielle Modellbedingungen des ER-Modells 

1. Entity-Typ mit mindestens einem Attribut (Komponente) 

2. Jedes Attribut mindestens einmal verwendet 

3. Attribut-Typen sind entweder Basisattribut-Typen oder aufgebaut über Attribut-Typen 

4. Basis-Attribut-Typen haben einen Datentyp 

5. Schlüssel gehören nur zu den Attributen des (Entity-)Typen 

6. Jeder Relationship-Typ hat mindestens eine Komponente (Entity-Typ, Attribut-Typ oder Relationship- 

Typ) 

7. Typstruktur ist streng hierarchisch 

8. Schlüssel gehört zu Entity-Typen (mindestens einer) 

9. Schlüssel hat mindestens eine Komponente 

10. Komponenten eines Schlüssels eines Typen sind Komponenten des Typs 

11. Mengenbasierte Definition 

möglich ist auch eine pointerbasierte Definition von Relationship-Typen oder auch von Entity- 

Typen 

12. Spezielle Behandlung rekursiver Typen 

Damit sind ausgeschlossen: 

1. Schwache Entity-Typen 

2. Nicht-hierarchische Typen


Name(First,Fam,{Title}) 

Person 

Adr(Zip,Town,Street(Name,Nr)) 

❃ 

❑ 

■ 

Person’s number 

Supervisor 

Since 

StudNr 

✙ 

Student 

❖ 

✠ 

■ 

Major 

Minor 

Department 

✸ 

Phones{Phone} 

Director 

✛ 

DName 

In 

✲ 

❃ 

❥ 

Professor 

✻ 

Primary 

Investigator 

Speciality 

Member 

Result 

Time(Day,Hour) 

Enroll ✲ Lecture Has 

⊕ 

✾ 

✰ 

❄ 

Semester 

Year Season 

Nr 

Room 

Building 

✻ 

Course 

✻ 

CNu 

CName 

❄ 

Project 

Prerequis 

Begin 

Num 

End 

PName 

Abbildung 1: HERM-Diagram of the University Database


Student 

✻ 

✶ 

✯ 

Professor 

Belegt 

Vorlesung 

IC 

☛ 

✾ 

✰ 

 

Voraussetzung 

Semester 

Raum 

Kurs 

✛ 

‘Belegt’ als selbständige Beziehung 

Belegt[Professor,Kurs,Semester] ⊆ Vorlesung[Professor,Kurs,Semester] 

❄ 

✛ 

Student 

✻ 

✯ 

Professor 

Belegt 

✲ 


✾ 

Semester 

✰ 

❄ 

Raum 

Kurs 

‘Belegt’ als Beziehung über ‘Vorlesung’ 

✛ 

✛ 

Voraussetzung 

3.1.2 Das erweiterte ER-Modell (formal) 

Basis-Datentypen BT mit Elementen DT (D) = (domain(D), Ops(D), P red(D) 

Datenschema DD = (U, D, dom) 

endliche Menge U von atomaren Attributen, 

Mengen von Werten D := ∪ A∈U domain(dom(A)), 

und Assoziationsschema zum Namensraum dom : U → BT 

Genestetes (geschachteltes) (komplexes) Attribut 

neue Namensmenge NA und Menge von Konstruktoren 

1. λ ∈ UN 

2. U ⊆ UN 

3. Falls X ∈ UN dann l : X ∈ UN für l ∈ L 

4. Für verschiedene X 1 , ..., X n ∈ UN und X ∈ NA ist X(X 1 , ..., X n ) ein (Tupel-)Attribut UN 

5. Falls X ′ ∈ UN und X ∈ NA dann X{X ′ } ist ein (Mengen-)Attribut UN 

6. Keine weiteren Elemente in UN 

weitere Konstruktoren: Multimenge, Liste, ...


3. Für l : X ∈ UN : Dom(l : X) = Dom(X). 

4. Für X(X 1 , ..., X n ) ∈ UN : Dom(X) = Dom(X 1 ) × ... × Dom(X n ) . 

5. Für X{X ′ } ∈ UN : Dom(X{X ′ }) = P ow(Dom(X)) . 

Beispiele von komplexeren Attributen sind 

Name (Vornamen, 

Familienname :: varstring30, [Geburtsname :: varstring30,] 

[Titel:{AkademischeTitel :: varstring10 } ∪ · 

FamilienTitel :: varstring10]) 

Kontakt (Tel({dienstl :: varnumbersequence20 }, privat :: varnumbersequence20), 

email :: emailType, ...) 

Geburtsdatum :: date . 

Name 

❄ 

( ... ) 

Attribute können in einer verkürzten Notation verwendet werden, wenn dies eindeutig im Schema 

bleibt. Das Attribut Kontakt ist z.B. dann auch ohne seine Bestandteile verwendbar. 

Attribute sind hierarchisch strukturiert wie - im Falle des Namens einer Person - der Baum in Bild 

?? zeigt. Diese hierarchische Struktur ermöglicht auch Elemente auszuzeichnen, z.B. mit der Eigen- 

✾ 

Vornamen 

❄ 

< ... > 

❄ 

( ... ) 

✮ 

 

Vorname Benutzung 

❄ 

string1 

❄ 

varstring15 

✠ 

Familienname 

❄ 

varstring30 

3 

[ ... ] 

❄ 

Geburtsname 

❄ 

varstring30 

✾ 

{ ... } 

❄ 

AkademischeTitel 

❄ 

varstring10 

3 [ ... ] 

❄ 

Titel 

❄· 

∪ 

3 

Familientitel 

❄ 

varstring10 

Abbildung 2: Semi-strukturiertes Attribut Name 

schaft Element eines Schlüssels zu sein. So kann z.B. zum Schlüssel das Teilattribut 

Name (Vornamen, Familienname, [Geburtsname ]) 

hinzugenommen werden, wobei wir als Abkürzungsregel benutzen, daß mit dem Nennen eines Bezeichners 

auch der damit verbundene Teilbaum mit übernommen wird, z.B. für Vornamen auch die 

gesamte Teilstruktur Vornamen . 

Tupel über X ⊆ UN und DD = (U, D, dom) ist eine Funktion 

t : X −→ D DD mit t(A) ∈ Dom(A) für A ∈ X 

Menge aller Tupel über X für DD: DDD 

X 

Schlüsselkonzept analog zur Definition der Attribute 

Entitytyp E ist ein Paar (attr(E), id(E)) 

E ist Entitytyp-Name, 

attr(E) ist Attributmenge und 

id(E) ist nichtleere verallgemeinerte Teilmenge von attr(E) (Schlüssel oder Identifikator). 

Entityklasse - Menge E C von Tupeln über attr(E) mit der Schlüsseleigenschaft 

für verschiedene Tupel τ, τ ′ from E C gilt τ id(E) ≠ τ ′ id(E) 

Ein Entity-Typ besteht aus einer nichtleeren Folge von Attributen und einer Menge von statischen


wird. Zum Beispiel ist ein Person-Typ spezifiziert durch 

Person = (Name, Adresse, Kontakt, GebDatum, PersNr : StudNr ∪ · 

MitarNr, ..., ∅) 

mit einer Folge von Attributen. Markierungen sind als solche ausgewiesen. 

Ein Entity-Typ wird durch ein Rechteck graphisch repräsentiert. 

Eine Entity-Klasse besteht aus einer Menge von Objekten vom Entity-Typ, die die statischen 

Integritätsbedingungen des Entity-Typen erfüllt. 

Zum Beispiel ist das folgende Objekt mit dem Identifikator β 

β: ((, Thalheim, {Prof., Dr.rer.nat.habil., Dipl.-Math.}), 

BTU Cottbus, (({ +49 431 880 4472, +49 431 8894072}, +49 431 824054), 

thalheim@informatik.tu-cottbus.de), 10.3.52, 637861) 

vom Entity-Typ Person, wobei mit ‘z’ der Zusatzname und mit ‘r’ der Rufname bezeichnet wird. 

Für Typen {R 1 , ..., R k } : “ Kategorie ” oder Cluster C = R 1 + R 2 + ... + R k 

eventuell (insbesondere für Identifizierung) mit Marken 

Eine disjunkte Vereinigung von bereits konstruierten Typen wird als Cluster-Typ bezeichnet. Ein 

Cluster-Typ wird mit einem ⊕ -Zeichen graphisch repräsentiert. 

Beispiele sind durch folgende Typen gegeben: 

JuristischePerson = Person ∪ · 

Betrieb ∪ · 

Vereinigung 

Gruppe = Senat ∪ · 

Arbeitsgruppe ∪ · 

Vereinigung, 

die den Typ JuristischePerson bzw. Gruppe als disjunkte Vereinigung von anderen Typen einführen. 

Cluster-Typen können weitere Attribute besitzen. In diesem Fall wird der Cluster-Typ durch eine 

Raute mit den Attributen repräsentiert. 

Objekte von Cluster-Typen sind analog zu den Objekten anderer Typen durch entsprechende Zuordnung 

zu den Element-Typen eingeführt. So können z.B. die Objekte β, LIM, CottbusNet e.V. 

juristische Personen sein. 

Entity-Typen = Relationship-Typen 0. Ordnung 

R 1 , .., R l - Relationship-Typen der Ordnung < i 

Relationship-Typ i. Ordnung : 

R = (compon(R), attr(R)) 

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 

definiert als Element von 

R t 1 × ... × Rt n × Dom(B 1 ) × ... × Dom(B k ) 

Ein Relationship-Typ (erster Ordnung) besteht aus einer nicht-leeren Folge von Entity-Typen, einer 

Menge von Attributen und einer Menge von statischen Integritätsbedingungen. Eine Menge von 

der Struktur des Relationship-Typen ist eine gültige Menge, wenn sie den statischen Integritätsbedingungen 

genügt. Elemente können markiert sein. 

Ein Beispiel sind die Relationship-Typen 

InGruppe = (Person, Gruppe, { Zeit(Von [,Bis]), Funktion }, ∅ ) 

DirektVoraussetz = (setztVoraus: Kurs, vorausges : Kurs, ∅, ∅ ) 

Professor = (Person, { Berufungsgebiet }, ∅ ) . 

Ein Relationship-Typ wird mit einer Raute graphisch repräsentiert. Wir erlauben auch optionale 

Komponenten von Relationship-Typen, solange eine Identifikation über die obligatorischen Elemente 

definiert ist. 

Ein Objekt eines Relationship-Typs ist ein Tupel, das zu den jeweiligen Elementen auf die entsprechenden 

Objekte der Klasse der Elemente durch Angabe von identifizierenden Werten (Identifikator 

bzw. Primärschlüssel bzw. anderer Schlüssel) verweist und Werte für die Attribute des Relationship- 

Typs besitzt. 

Eine Relationship-Klasse besteht aus Objekten des Relationship-Typs, die den statischen Integritätsbedingungen 

genügen.


Senator5β: ( 637861, Senat, (2000), Vorsitzender) 

VorausDBIVHaupt: (DBIV, DBI) . 

Achtung: Man kann auch mit anderen Einschränkungen für das Modell kann man z.B. Pointersemantik 

benutzen. Weiterhin könner verschiedene Einschränkungen fallengelassen werden: 

• abgeleitete Attribute 

• leere Attributmengen für Entitytypen; Identifizierung über Relationshiptypen 

• nicht-hierarchische Struktur 

Ein Relationship-Typ i-ter Ordnung besteht aus einer nicht-leeren Folge von Entity- und Relationship- 

Typen einer Ordnung von maximal (i-1), wobei ein Typ (i-1)-ter Ordnung sein muß, einer Menge von 

Attributen und einer Menge von statischen Integritätsbedingungen. Eine Menge von der Struktur des 

Relationship-Typen ist eine gültige Menge, wenn sie den statischen Integritätsbedingungen genügt. 

Eine Identifikation kann sowohl aus den Elementen bestehen als auch aus den Attributen. 

IsA-Typen: 

hier wurde partielle, nicht disjunkte Darstellung über Teiltypen bevorzugt, denkbar sind jedoch verschiedene 

Typen: 

1. partiell, nicht disjunkt; 

dieser Fall wird als der typische Fall angenommen (keine weiteren semantischen Informationen) 

Im HERM darstellbar über unäre Teiltypen. 

Person ⊇ Professor ∪ Mitarbeiter ∪ Student 

E ⊇ E 1 ∪ ... ∪ E n 

2. partiell, disjunkt 

die Teiltypen erfüllen eine Exklusionsbeschränkung 

Person ⊇ Professor ∪ Student 

E = E 1 ∪ ... ∪ E n 

3. total, nicht disjunkt 

E = E 1 ∪ ... ∪ E n 

Projektmitarbeiter = Professor ∪ Mitarbeiter ∪ Student 

4. total, disjunkt 

E = E 1 ∪ ... ∪ E n 

Studenten = StudImVordiplom ∪ StudImHauptstudium ∪ Diplomand 

Weiterhin kann auch für die Spezialisierung mit Partitionsbedingung eine analoge Strukturierung 

betrachtet werden (wird auch in den meisten Büchern ‘vergessen’): 

1. partiell, nicht disjunkt 

E ⊆ E 1 ∪ ... ∪ E n 

Teilnehmer ⊆ Vortragender ∪ Organisator ∪ NormalerTeilnehmer 

2. partiell, disjunkt 

E ⊆ E 1 ∪ ... ∪ E n 

Literatur ⊆ Buch ∪ Preprint ∪ Zeitschrift 

3. total siehe oben Generalisierung = Spezialisierung 

E = E 1 ∪ ... ∪ E n 

Gewöhnlich wird in der Literatur nur versimplifizierend die IsA-Beziehung als strukturelle Beziehung 

betrachtet. Richtig ist aber die IsA-Beziehung im vollen Typeninhalt zu betrachten: 

Typ = Struktur + Operationen + Semantik 

In diesem Fall wird die Richtung der Vererbung bekanntgegeben. 

Damit dann besser modellierbar:


• Operationen des Teiltyps sind operationale Spezialisierung der Operationen des Supertyps (wenn 

im supertyp definiert) 

• Semantik des Teiltyps (eingeschränkt auf im Supertyp darstellbares) folgt aus Semantik des 

Supertyps 

3.1.3 Generalisierung versus Spezialisierung 

Ein Cluster-Typ erlaubt die explizite Darstellung einer Generalisierung. Ein unärer Relationship-Typ 

stellt dagegen eine Spezialisierung dar, wenn der Relationship-Typ bzw. Entity-Typ als sein Element 

diesen identifiziert. Rollen werden oft durch einen generischen Typ mit der Bezeichnung IsA dargestellt. 

Da die relationalen Schemata auch ohne diesen Typ auskommen, bevorzugen wir die Darstellung 

als Rolle mit unären Relationship-Typen oder ggf. auch mehrstelligen Relationship-Typen, 

falls die Rolle durch eine Beziehung zu anderen Typen ausgezeichnet ist. Damit sind wir in der Lage, 

zwischen Generalisierung und Spezialisierung zu unterscheiden. 

3.1.4 ER-Schemata 

Wie im relationalen Modell betrachten wir 

Entity-, Relationship- und Cluster-Typen, die mit der obigen Notation eingeführt werden 

Schemata S, deren Typen vollständig zurückführbar aus Basis-Datentypen sind, d.h. jeder Typ ist 

entweder ein Basis-Datentyp oder ein Typ, der durch Anwendung der Konstruktoren aus Typen 

des Schemas entsteht 

Integritätbedingungen, die wir im nächsten Teilkapitel einführen 

Ein Datenbank-Schema ER besteht aus einer Menge von Typen {T i = (U Ti , Σ Ti )} und 

globalen statischen Integritätsbedingungen Σ ER . 

Ein etwas komplexeres Beispiel ist das Beispiel in Bild ??. Eine Lehrveranstaltung, z.B. eine 

Vorlesung, wird durch einen Lehrstuhl angeboten. Dieses Angebot kann angenommen werden. Dann 

wird die Lehrveranstaltung geplant. Wird sie auch gehalten, dann werden die aktuellen Daten in der 

Klasse zum Typ GehalteneLehrveranst gespeichert. Der Typus und die Raumzuordnung können sich 

vom Vorschlag zum Plan und für den Raum vom Plan zu den gehaltenen Lehrveranstaltungen ändern. 

Ein Vorschlag für eine Lehrveranstaltung wird durch Berechtigte eingetragen. Eine Person ist für die 

Lehrveranstaltung verantwortlich. Eine Lehrveranstaltung kann für mehrere Studiengänge angeboten 

werden. 

Kurs Semester Professor ✲ 

✯ 

❦ 

✻ 

✒ 

Dozent 

Person 

✶ 

eingetragen 

Verantwortlicher4LV 

Studiengang 

{} 

✛ angebotene Wunsch 


Zeit(Vorschlag, 

Vorschlag ✻ Nebenbeding) 

✲ 

✯ 

✻ 

Raum 

Typus 

✰ 

✛ 

geplante ✛ 

Lehrveranst 

Zeitrahmen 

gehaltene 

Lehrveranst 

Abbildung 3: HERM Diagramm zu unserem Hauptbeispiel


der Objekte seiner Komponenten. So können z.B. Objekte vom Typ geplanteLehrveranstaltung in Bild 

?? auch nur auf Objekte verweisen, die Kurs, Semester, Professor bezeichnen, wenn wir voraussetzen, 

daß ein Schlüssel des Typs angeboteneVorlesung aus Kurs, Semester, Professor besteht. 

Ein Objekt vom Typ 

angeboteneVorlesung = (Kurs, Semester, Studiengänge, 

Professor, eingetragen, Verantwortlicher4LV, Raumwunsch, Typus, { Zeit }, ∅) ist z.B. 

VorlesungDBIVSS02: (DBIV, SS2002, { Informatik, IMT }, 

637861, KK, 637861, SR1, Vorlesung/Übung/Praktikum 2+2+2, Mo. 1.DS) . 

Rollen, die exklusiv bzw. hierarchisch sind, lassen sich auch anstelle einer HERM-Rautenstruktur 

durch hierarchische Strukturen abbilden, wie in Bild ?? dargestellt. Welche Darstellungsform gewählt 

wird, hängt vom erforderlichen Detaillierungsgrad ab. Sollen Attribute mit dargestellt werden, wird 

das hierarchische ER-Modell sehr schnell zu unübersichtlich. In den ersten Abstraktionsschichten 

stellt es aber eine gute Alternative zum HERM-Diagramm zum. 

Person 

Student 

Diplomand 

Diplomand 

✲ 

Student 

✲ 

Person 

Universitätsmitarbeiter 

Professor 

Projektmitarbeiter 

Projektmitarbeiter 

✻ 

✲Universitäts-✛ 

mitarbeiter 

Professor 

Abbildung 4: Hierarchisches ER-Diagramm versus HERM Diagramm 

3.1.5 Aggregation 

Wir können die Konstruktion von Relationship-Typen zu einer allgemeinen Aggregationskonstruktion 

erweitern, indem wir weitere Konstruktoren zulassen: 

• Vereinigung, 

• Mengenbildung, 

• Aggregation durch Beziehungsklasse und 

• Abstraktion durch Komponentenbildung. 

Klassen werden mit der hochgestellten Annotation ‘C’ und dem Typnamen bezeichnet. Z.B. sind 

Person C und InGruppe C Klassen entsprechenden Typs. 

3.1.6 Klassenseparierte Schemata versus objektentfaltete Schemata 

Wir merken an, daß wir über zwei unterschiedliche Methoden zur Darstellung, Repräsentation, Verarbeitung 

und Speicherung von Objekten verfügen: 

Klassen-Separation: Die Menge aller Objekte wird durch ein ER-Schema dargestellt. Jedes Objekt 

wird genau einer Klasse zugeordnet und in beliebig vielen anderen Klassen auf der Grundlage 

des ER-Schemas verwendet. Die Verwendung kann über einen Surrogat-Schlüssel, eine Markierung 

oder Werte zum ausgewählten Schlüssel des Objektes erfolgen. 

Wir nennen diese Form der Behandlung von Objektmengen klassen-separierte Darstellung. 

Ein Objekt ist dann mit dem erweiterten ER-Modell als Schneeflocke mit einer Wurzel darstellbar.


ergeben. Ein Teilgraph besitzt evt. ein Wurzel-Objekt, d.h. es gibt ein Objekt, das rekursiv auf 

alle anderen Objekte des Teilgraphen verweist. Besitzt jeder dieser Teilgraphen ein Wurzelobjekt, 

dann heißt U Objekt-Gesellschaft. 

Damit ist in Objekt-Gesellschaften jedes Objekt ein volles Objekt mit allen Eigenschaften. 

Ein Beispiel für eine Objekt-Entfaltung zum Schema in Bild ?? ist folgendes XML-Dokument: 

 

 

 

Montag 

Mittwoch 

 

 

Normalvorlesung 2+2+2


3.2 Integritätsbedingungen 

3.2.1 Statische Integritätsbedingugngen 

Die Semantikspezifikationssprache umfaßt Schlüssel und Integritätsbedingungen, wie funktionale Abhängigkeiten, 

Exklusions- und Inklusionsabhängigkeiten, mehrwertige Abhängigkeiten, Viele-Eins-Bedingungen, 

Seinsbedingungen (Existenzbeziehung), Verweisbedingungen, Teiltypenbedingungen und Regeln, wie 

z.B. die Gesamtheitsregel, die Verneinungsregel und die Sichtregeln, sowie vor allem Komplexitätsbedingungen 

(Kardinalitätbedingungen) zur Spezifikation der Beziehung zwischen einem Relationship- 

Typen und seinen Komponenten. 

Statische Integritätsbedingungen werden als Formeln der hierarchischen Prädikatenlogik allgemein 

dargestellt. Wir verwenden jedoch die üblichen Kurzdarstellungen. 

Wir gehen davon aus, daß statische Integritätsbedingungen einer Interpretation mit einer “Normallogik” 

unterliegen. Mitunter wird auch im Entwurf eine Integritätsbedingung mit einer schwachen, 

deontischen Interpretation benutzt, bei der ihre Gültigkeit für die meisten Objekte einer Datenbank 

oder einer Klasse gefordert wird. Mitunter wird auch eine strikte Form der Interpretation genutzt, bei 

der z.B. obere bzw. untere Schranken für Kardinalitätsbeschränkungen auch durch entsprechende Objektmengen 

genau erfüllt sein müssen. 

Arten von Abhängigkeiten des Er-Modelles 

• Trennung von Gesichtspunkten 

Separation von Aspekten 

mehrwertige Abhängigkeiten, hierarchische Abhängigkeiten, Verbundabhängigkeiten 

• Trennung von Spezialisierungen 

Exklusionsabhängigkeiten, Zerlegungsabhängigkeiten, Vereinigungsabhängigkeiten 

• Darstellung des Datenzusammenhangs 

Inklusionsabhängigkeiten (Elementarfakten bedingen einander) 

Existenzabhängigkeiten 

Wertebereichsbeschränkungen 

tupelgenerierende Abhängigkeiten (auffaltende Zusammenhänge) 

gleichungsgenerierende Abhängigkeiten (Zusammenfließen von Daten) 

• Numerische Einschränkungen 

Kardinalitätsbeschränkungen, absolute und relative Kombinatorik 

Die unterschiedlichen Abhängigkeiten sind relevant auf unterschiedlichen Abstraktionsniveaus. 

Partielle Identifikatiohängigkeihängigkeihängigkeit 

relative Unab- 

Existenzab- 

Redundanzab- 

Konzeptionelle 

Ebene 

funktionale, 

gleichungsgenerierende 

mehrwertige, 

hierarchische, 

Verbundabhängigkeit, 

null-werte-frei, 

Vereingungsabhängigkeit, 

numerische, 

Inklusionsabhängigkeit, 

Exklusionsabhängigkeit 

Exklusionsabhängigkeit, 

tupelgenerierende, 

horizontale 

Dekomposition 

Kardinalitätsabhängigkeit 

Implementationsebenqueness, 

Schlüssel, uni- 

Dekomposition, no null, stored referentielle Inte- 

trigger, stored procedu- 

procedures, grität, Surrogate, 

check 

res, trigger trigger 

Kapseln 

Benutzersicht Identifikation Struktur ! no null elementare Fakten 

Wir verwenden im weiteren folgende Klassen von Integritätsbedingungen:


Typ mehr als einen Schlüssel. Deshalb verwenden wir von vornherein Schlüsselmengen. Der 

Primärschlüssel eines Entity-Typs wird direkt angegeben und kann in der Schlüsselmenge weggelassen 

werden. 

Wir nehmen z.B. für das Diagramm in Bild ?? folgende Schlüssel an: 

Key(Person) = { { PersNr }, { Name, Geburtsdatum } } 

Relationship-Typen haben ggf. auch eigene Attribute, die auch Bestandteile eines Schlüssels 

sind. 

Zum Beispiel nehmen wir für das obige Beispiel an, daß die Zeit essentiell für InGruppe ist, 

d.h. 

Key(InGruppe) = {{ Person, Gruppe, Zeit }} oder 

Key’(InGruppe) = {{ Person, Gruppe, Zeit, Funktion }} 

Weiterhin kann z.B. gelten 

Key(Vorlesung) = { {Kurs, Semester}, {Semester, Raum, Zeit}, {Semester, Dozent, Zeit} } 

Schlüssel folgen der Komponentenkonstruktion und können auch für einen Teil gelten, z.B. 

Name(Vornamen, FamName). 

Mindestens ein Schlüssel wird über die Komponente an den Relationship-Typen ‘vererbt’. 

Funktionale Abhängigkeiten sind eine wichtige Gruppe von Abhängigkeiten. Eine funktionale Abhängigkeit 

R : X → Y ist für einen Typ R und Teilmengen X, Y seiner Elemente 

definiert. Sie gilt in einer Klasse R C , falls die Gleichheit von Objekten o, o ′ aus R C über X die 

Gleichheit über Y für o, o ′ impliziert. 

Funktionale Beziehungen von Attributgruppen in unserem Beispiel sind 

geplanteLV : {Semester, Zeitrahmen, Raum} → {{Studiengang}, Professor, Kurs} 

geplanteLV : {Professor, Semester, Zeitrahmen} → {Kurs, Raum} 

angeboteneLV: {Semester, Kurs} → {Professor} . 

Kardinalitätsbeschränkungen werden als kombinatorische Beschränkungen in der (min,max)-Notation 

und der Partizipations-Semantik als Paar von Kardinalitäten verwendet. Damit unterscheidet 

sich unsere Notation von der Lookup-Semantik, die z.B. UML verwendet. Die letztere 

kann jedoch in einer n..m-Notation ebenso mitgeführt werden. Wir betrachten hierzu ein vereinfachtes 

Diagramm in Bild ??. 

(gehaltene) ✛ 

Vorlesung (1,n) 

setztVoraus ✻ 

(0,2) 

✻vorausgesetzt 

(3,4) 

3..4 0..2 

Voraussetzung 

0..2 

legtab ✲ 

(0,n) 

Resultat 

(0,n) 

❄ 

Student 

Ablageform 

Abbildung 5: Kardinalitätsbeschränkungen im Vorlesungsbeispiel 

Eine Kardinalitätsbeschränkung card(R, R i ) = (n, m) gilt in einer Klasse R C , falls 

jedes Objekt o i von Ri 

C in R C mindestens n-mal und höchstens m-mal vorkommt. 

Eine Kardinalitätsbeschränkung in der Lookup-Notation look(R, R i ) = (n, m) gilt in 

einer Klasse R C mit k Elementen, falls zu jeder Kombination von Objekten o j von Rj 

C (j ≠ 

i, 1 ≤ j ≤ k) mindestens n und höchstens m entsprechende Objekte o i aus Ri C in der Klasse 

R C vorkommen. 

Im Fall binärer Relationship-Typen kann man damit einem Objekt o von R i mindestens n und 

höchstens m Objekte aus Rj 

C zuordnen, d.h. das Objekt sieht vermittels R C höchstens m und 

mindestens n Objekte aus der anderen Klasse.


card(Voraussetzung, setztVoraus) = (0,2) 

look(Voraussetzung, setztVoraus) = 3..4 

card(Voraussetzung, vorausgesetzt) = (3,4) 

look(Voraussetzung, vorausgesetzt) = 0..2 

gilt. Damit haben wir äquivalente Formen. 

Für n-äre Relationship-Typen ohne eigene Attribute ist die Lookup-Notation look(R, R i ) = 

n..m äquivalent zur verallgemeinerten Kardinalitätsabhängigkeit card(R, R \ R i ) = (n, m) . 

In unserem Beispiel gilt z.B. die Einschränkung, daß erst dann ein Eintrag in die Klasse legtab 

geführt wird, wenn der Student eine Vorlesung erfolgreich abgelegt hat. 

Die Lookup-Bedingung look(legtab, Ablageform) = 0..2 stellt dar, daß nur Prüfung und 

Schein bzw. Schein und Praktikum bzw. Prüfung und Praktikum absolviert werden müssen. 

Diese Bedingung ist äquivalent zu 

card(legtab, Student Vorlesung) = (0,2). 

Eine Kardinalitätsbeschränkung card(R, R i ) = (0, 1) ist äquivalent zur funktionalen Abhängigkeit 

R : {R i } → R . 

Eine Lookup-Kardinalitätsbeschränkung look(R, R i ) = 0..1 ist äquivalent zur funktionalen 

Abhängigkeit R : R \ {R i } → R . 

Weiterhin können wir z.B. fordern, daß nur solche Vorlesungen als gehalten gelten, die auch 

zu studentischer Beteiligung geführt haben. Dies wird durch card(legtab, Vorlesung) = (1,n) 

dargestellt. 

Eine strengere Bedingung ist, daß dies auch für das Semester gelten muß. Dann können wir 

spezifizieren 

look(legtab, Student) = 1..n bzw. card(legtab, Vorlesung Semester) = (1,n). 

Für Relationship-Typen mit eigenen Attributen ist die Lookup-Notation in verschiedenen Formen 

definiert. 

(DBIV,SS2002,β) 

◦ 

◦ ◦ ◦ 

◦ 

◦ Schein 

(DBI,WS2002,β) 

(Compiler,SS2002,PB) 

(Informatik III,WS2002,BvB) 

(Informatik III,WS2003,β) 

◦ ◦ ◦ 

◦ 

◦ 

◦ 

◦ 

◦ 

Prüfung 

◦ Praktikum 

Antje Bärbel Cornell Doris Emil Fjodor 

Abbildung 6: Beziehungen der Objekte im Vorlesungsbeispiel 

Wir betrachten in diesem Beispiel in Bild ?? eine kleine Klasse mit 14 Objekten. Z.B. hat Bärbel 

sowohl die (Informatik III,WS2002,BvB) als auch (DBIV,SS2002,β) mit Prüfung und Schein 

abgelegt, Emil dagegen nur Scheine in (Informatik III,WS2002,BvB) und (DBI,WS2002,β). 

Kardinalitätsbeschränkungen sind mitunter nicht erfüllbar in nicht-leeren, endlichen Klassen. 

Ein Beispiel einer solchen nicht-erfüllbaren Menge von Integritätsbedingungen ist das Paar 


card(Voraussetzung, vorausgesetzt) = (3,4) . 

Dagegen ist 


card(Voraussetzung, vorausgesetzt) = (3,4) 

erfüllbar und impliziert 


card(Voraussetzung, vorausgesetzt) = (3,3) .


Eine mehrwertige Abhängigkeit X → Y |Z wird für einen Typ R = (U R , Σ R ), mit 

Teilmengen X, Y ⊆ U R und Z = U R \(Y ∪X) definiert und gilt in einer Klasse Relation R C 

über R (dargestellt durch R C |= X → Y |Z ), falls für alle o, o ′ ∈ R C , die den gleichen 

Wert für die X-Elemente von R haben, ein Objekt o ′′ in R C existiert, das aus der Faltung von 

o und o ′ hervorgehen kann, d.h. formal 

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 ′ . 

Eine nützliche, allgemein bekannte Eigenschaft von mehrwertigen Abhängigkeiten ist die Dekompositionseigenschaft. 

Es gilt R C |= X → Y |Z genau dann, wenn sich R C nach X ∪ Y und 

X ∪ Z vertikal dekomponieren läßt, d.h. formal R C = R C [X ∪ Y ] ✶ R C [X ∪ Z] . 

Weniger bekannt ist dagegen, daß die Gültigkeit der mehrwertigen Abhängigkeit zu einem neuen 

äquivalenten Schema führt, bei dem der Typ R durch die dekomponierten Typen wie in Bild 

?? ersetzt wird. 

Y ✛ XY ✲ X ✛ XZ ✲ 

Z 

Abbildung 7: Die Zerlegung von R in zwei Relationship-Typen 

3.2.2 Weitere relationale Integritätsbedingungen 

Wertebereichsabhängigkeiten können im erweiterten ER-Modell verwendet werden. So gilt in unserem 

Beispiel 

Semester.Bezeichnung 

∈ {W S, SS} × {x/x+1|x ∈ 80..99, 00, 01, 02, ..., 17} . 

Andere wichtige Klassen von Abhängigkeiten sind Exklusions- und Inklusionsabhängigkeiten. 

3.2.3 Typen mit gemau einem minimalen Schlüssel 

Menge der Extremalattribute für gegebene Menge Σ von funktionalen Abhängigkeiten und Komponenten 

R eines Typs T : 

extr(R, Σ) := {B ∈ R | Σ ̸|= R \ {B} −→ {B}} 

Corollary 1 Folgende Aussagen sind äquivalent: 

• T besitzt genau einen Schlüssel. 

• extr(R, Σ) ist ein Schlüssel von T . 

• Σ |= extr(R, Σ) −→ R. 

3.2.4 Rahmen zur Spezifikation von Integritätsbedingungen 

Integritätsbedingungen werden in der Literatur noch immer leichtfertig nur in einfacher Form bzw. 

Rohform spezifiziert. Eine Spezifikation der Integritätsbedingungen muß umfassen: 

Integritätsbedingung in Rohform: Angabe der Integritätsbedingung als logische Formel 

Lokalisierung der Integritätsbedingung im Kontext des Systemens, d.h. 

durch Angabe der Schema-Umgebung einer Integritätsbedingung (Schema-Frame-Problem) 

und 

durch Angabe der betroffenen Datenbankobjekte, die neben den betroffenen Objekten kontrolliert 

werden müssen (DB-Frame-Problem) 

Gültigkeit der Integritätsbedingungen je nach Phase der Anwendung, mindestens für die folgen-


Archivierung der Datenbestände 

Ausführungsmodi zur Kontrolle der Integritätsbedingungen je nach Operation 

Ausführungszeit der Kontrolle z.B. verzögert, sofort ggf. auch mit Aussetzen unter bestimmten 

Bedingungen 

Anwendungsmonitoring der Kontrolle der Integritätsbedingungen z.B. auf Objektniveau oder 

auf Anweisungsniveau 

Umformung (term rewriting) der Operationen 

Behandlung für den Fall des Nichtgeltens der Integritätsbedingung je nach Datenbankereignis: 

Zurückweisen der verursachenden Anweisung 

Propagierung der Integritätsbedingung 

Nutzung von (temporären) Zusatzwerten zur Kennzeichnung der Situation 

Rangordnung der Integritätsbedingung unter den Klassen von Integritätsbedingungen zur Ableitung 

der Kontrollreihenfolge 

Daneben können wir Default-Rahmen angeben: 

1. harte Integritätsbedingung ohne das Zulassen von Ausnahmen 

2. volle Schema- und DB-Umgebung 

3. keine Unterscheidung von Phasen 

4. sofortige Kontrolle bei Datenbankereignissen ohne Ergänzung der Operationen 

5. gleichwertige Klassen von Integritätsbedingungen 

Insbesondere nutzen wir die folgenden Rahmen und Erzwingungsmodi: 

1. Spezifikation von Existenzabhängigkeiten 

Durch die Komplexitäten sind bereits Abhängigkeiten dargestellt worden, die von den generischen 

Operationen insert, delete, update eingehalten werden müssen. Ist für eine Komplexität 

comp(R, R ′ ) = (a, b) a ≥ 1, dann ist jedes insert in R ′ durch ein insert in R zu unterstützen. 

Jedes delete in R ′ kann ein delete in R nach sich ziehen. Alle derartigen Komplexitäten werden 

zusammengestellt und in den folgenden Schritten angewandt. 

Man kann für jeden Typen eine insert-, delete- und eine update-Umgebung mit folgendem Algorithmus 

konstruieren. 

(a) Env I (R) := Env D (R) := Env U (R) := {R} für jeden Entity- und Relationshiptypen. 

(b) Man generiere die Umgebungend erster Ordnung wie folgt. 

i. Gilt comp(R, R ′ ) = (a, b) für a ≥ 1 dann sei Env I (R) := Env I (R ′ ) ∪ Env I (R), 

Env U (R) := Env U (R ′ ) ∪ Env U (R) und Env D (R ′ ) := Env D (R) ∪ Env D (R). 

ii. Für jeden Relationshiptypen R ′ , in dem R eine Komponente bildet: Env I (R ′ ) := 

Env I (R) ∪ Env I (R ′ ), Env U (R ′ ) := Env U (R) ∪ Env U (R ′ ) und Env D (R) := 

Env D (R) ∪ Env D (R ′ ). 

iii. Für jede Exklusionsabhängigkeit R ‖ R ′ gilt Env I (R ′ ) := Env D (R) ∪ Env I (R) 

und Env U (R ′ ) := Env U (R) ∪ Env U (R). 

iv. Weitere Abhängigkeiten werden analog behandelt. 

(c) Man wiederhole diesen Schritt bis keine der Mengen verändert wird: 

i. Gilt comp(R ′′ , R ′ ) = (a, b) für a ≥ 1 und R ′′ ∈ Env I (R ′ ) dann sei Env I (R) := 

Env I (R ′ ) ∪ Env I (R). Gilt comp(R ′′ , R ′ ) = (a, b) für a ≥ 1 und R ′′ ∈ Env U (R ′ )


ii. Für jeden Relationshiptypen R ′′ mit R ′′ ∈ Env I (R ′ ), in dem R eine Komponente 

bildet, sei Env I (R ′ ) := Env I (R) ∪ Env I (R ′ ). Für jeden Relationshiptypen R ′′ mit 

R ′′ ∈ Env U (R ′ ), in dem R eine Komponente bildet, sei Env U (R ′ ) := Env U (R) ∪ 

Env U (R ′ ). Für jeden Relationshiptypen R ′′ mit R ′′ ∈ Env D (R ′ ), in dem R eine 

Komponente bildet, sei Env D (R) := Env D (R) ∪ Env D (R ′ ). 

iii. Für jede Exklusionsabhängigkeit R ‖ R ′′ mit R ′′ ∈ Env I (R ′ ) gilt Env I (R ′ ) := 

Env D (R)∪Env I (R). Für jede Exklusionsabhängigkeit R ‖ R ′′ mit R ′′ ∈ Env U (R ′ ) 

gilt Env U (R ′ ) := Env U (R) ∪ Env U (R). 

iv. Weitere Abhängigkeiten werden analog behandelt. 

Diese Umgebungen sind maximale Umgebungen. Sie werden durch Eigenschaften der Anwendung 

eingeschränkt. 

Durch die Hierarchien sind entsprechende Existenzabhängigkeiten gegeben. Die Generalisierung 

(z.B. eine Person-de-jure ist eine Firma oder eine Person) führt zu einer Existenzabhängigkeit 

des Supertypen von Subtypen, die unbedingt gepflegt werden muß (d.h. werden die Daten 

einer Firma entfernt, dann werden diese auch für die Persona-de-jure entfernt). Die Spezialisierung 

führt zu einer Existenzabhängigkeit des Subtypen (in unserem Falle Teiltypen (Relationshiptypen 

definiert über dem Supertypen)) vom Supertypen. 

2. Erzwingungsregeln für insert- Operationen 

Man kann für insert-Operationen verschiedene Optionen bestrachten: 

• Abhängigkeit: Eine Einfügung ist nur erlaubt, wenn alle korrespondierenden Objekte bereits 

existieren. 

• Automatismus: Eine Einfügung ist stets erlaubt. Wenn entsprechende Objekte nicht existieren, 

dann werden sie ebenfalls eingefügt. 

• Nullwertebehandlung: Eine Einfügung ist stets erlaubt. Existieren die entsprechenden Objekte 

nicht, dann werden für das neue Objekt Nullwerte benutzt. 

• default-Werte: Eine Einfügung ist stets erlaubt. Existieren die entsprechenden Objekte 

nicht, dann werden für das neue Objekt default-Werte benutzt. 

• Zusätzliche Einfügebedingungen: Ein Einfügen ist nur dann erlaubt, wenn eine zusätzliche 

Bedingung gilt. 

• Keine Einschränkung: Das Einfügen unterliegt keiner Beschränkung. 

Die letzten beiden Möglichkeiten betreffen alle Typen außerhalb von Env I (R). Die ersten vier 

Möglichkeiten sind für Env I (R) bei der Spezifikation der Anwendung zu nutzen. 

3. Erzwingungsregeln für delete-Operationen 

Man kann für delete-Operationen verschiedene Optionen bestrachten: 

• Beschränkung: Ein Streichen ist nur erlaubt, wenn kein anderes Objekt davon betroffen 

ist. 

• Kaskadierung: Ein Streichen zieht das Streichen anderer Objekte nach sich. 

• Bedingte Kaskadierung: Ein Streichen zieht das Streichen anderer Objekte nach sich, die 

nur aufgrund des zu streichenden Objektes noch existieren. 

• Nullwertebehandlung: Beim Streichen werden Objekte, in die das Objekt eingeht auf 

einen Nullwert gesetzt. 

• default-Werte: Beim Streichen werden Objekte, in die das Objekt eingeht auf einen Nullwert 

gesetzt. 

• Zusätzliche Streichungsbedingungen: Das Streichen ist nur unter bestimmten Bedingungen 

erlaubt. 

• Keine Einschränkung: Das Streichen unterliegt keiner Beschränkung.


4. Erzwingungsregeln für update-Operationen 

• Beschränkung: Ein update ist nur erlaubt, wenn kein anderes Objekt davon betroffen ist 

(z.B. auch über Sekundärschlüsseln, die nicht in Beziehungen verwandt werden). 

• Automatismus: Ein update ist stets erlaubt, solange Integritätsbedingungen des Typs nicht 

verletzt werden. 

• Kaskadierung: Ein update löst weitere Operationen aus. 

• Nullwertebehandlung: Konflikte werden durch Nullwerte gelöst. 

• default-Werte: Zur Konfliktbereinigung werden default-Werte benutzt. 

• Zusätzliche update-Bedingungen: Ein update ist nur unter zusätzlichen Bedingungen möglich. 

• Keine Einschränkung. 

Eine update-Operation ist nicht das Gleiche wie eine delete;insert-Folge. 

SQL2 läßt in der Vollversion Kaskadierung, Nullwertebehandlung, Default-Werte und Beschränkung 

(ist default) zu. 

Die Erzwingung kann auch aufgrund von Regel-Trigger-Systemen spezifiziert werden. Dann ist 

jedoch das Resultat bei automatischer Erzwingung falsch. Der GCS-Zugang von Schewe/Thalheim 

ist ein sicherer automatischer Zugang. Er ist allerdings für die Betrachtungen hier zu komplex. 

Erzwingungsregeln 

✙ 

Unbedingte 

Erzwingung 

❄ 

Keine 

Erzwingung 

❥ 

Bedingte 

Erzwingung 

Kaskadierung 

Abhängigkeit 

✙ ❄ ❥ 

Nullwertebehandlung 

default- 

Werte 

❄ 

an Existenz 

gebunden; 

Rollback 

Abbildung 8: Mögliche Erzwingungsregeln für generische Operationen 

❥ 

mit zusätzlichen 

Einfügebedingungen 

; 

Prädikat 

Die Integritätsbedingungen sind in SQL-92 in unterschiedlichen Modi und Matching unterstützt, 

wobei deren Zusammenwirken nicht erklärt ist.


3.3 Übersetzung in relationale und andere Modelle 

3.3.1 Übersetzung von ER-Konstrukten in relationale Konstrukte 

Mehrschrittverfahren wobei Semantik und Funktionalität mit übertragen werden muß 

Schlüssel und funktionale Abhängigkeiten in Schlüssel, funktionale und mehrwertige Abhängigkeiten 

implizite Komponenten in Inklusionsabhängigkeiten 

Exklusionsabhängigkeiten in Exklusionsabhängigkeiten 

Kardinalitätsbedingungen in funktionale, Inklusions- und No-null-Abhängigkeiten 

1. Herstellen der ersten Normalform (Tupelattribute durch Verkettungsregel, Mengenattribute entweder 

über Wiederholung in Tupeln oder durch eigene Relation); Neuberechnung der Schlüssel 

(bei Mengenattributen, die bislang im Schlüssel vorkamen, wird dann eine mehrwertige Abhängigkeit 

generiert und der Schlüssel verändert sich stark) 

2. Flache Entity-Typen werden in Relationenschema überführt 

3. Schwache flache Entity-Typen werden in Relationenschema übersetzt, wobei die Attributmenge 

um die Schlüssel der identifizierenden Schemas erweitert werden. 

4. Hierarchien von Typen sind in einem der folgenden Zugänge überführbar 

• event-nonseparation: Student, Professor, Person 

• event-separation: Student, Professor, AnderePerson 

• union: Person = Student + Professor + AnderePerson 

• weak universal relation: Person 

5. Relationship-Typen werden entsprechend ihrer Ordnung überführt 

• Binäre 1:1-Relationship-Typen : 

Mehrere Optionen: 

• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite; d.h. 

bei (1,1):(0,1)-Typen in ersten Typ) des Primärschl¨ssels des anderen Typen, sowie der 

Attribute des Relationship-Typen (Einfügen eines Fremdschlüssels) 

• Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten 

und Attributen des Relationship-Typen 

• Zusammenfügen der beiden Relationenschemas unter Beifügung der entsprechenden 

Relationship-Typ-Attribute 

falls Attribute keine Nullwerte enthalten dürfen, dann nur bei (1,1):(1,1)-Typen 

• N-äre 1:...-Relationship-Typen (n > 2): 



bei (1,1):(0,1)...-Typen in ersten Typ) des Primärschl¨ssels des anderen Typen, sowie 

der Attribute des Relationship-Typen (Einfügen eines Fremdschlüssels) 






• Binäre 1:n-Relationship-Typen : 



bei (1,1):(0,1)-Typen in ersten Typ) des Primärschl¨ssels des anderen Typen, sowie der


• N-äre 1:n...-Relationship-Typen (n > 2): 



bei (1,1):(0,1)...-Typen in ersten Typ) des Primärschl¨ssels des anderen Typen, sowie 

der Attribute des Relationship-Typen (Einfügen eines Fremdschlüssels) 



• n:m -Relationship-Typen 

Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten und 

Attributen des Relationship-Typen 

• Rekursive Relationship-Typen 

wier normale Relationship-Typen aber unter Beibehaltung der Rollennamen 

• Is-A-Relationship-Typen 


bei (1,1):(0,1)-Typen in ersten Typ) des Primärschl¨ssels des anderen Typen, sowie der 

Attribute des Relationship-Typen (Einfügen eines Fremdschlüssels) 






• Cluster 



und Attributen des Relationship-Typen unter Einbeziehung der Rollennamen 

• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite) des 

Primärschl¨ssels des anderen Typen (Einfügen eines Fremdschlüssels) unter Beibehaltung 

der Rollennamen 

3.3.2 Spezifika der Struktur-Übersetzung von HERM-Schemata 

Beobachtung 1. 

Es können komplexe Attribute auch eine harmonisierte Übersetzung anderer komplexer Attribute 

erfordern. 

Beispiel: 

Name(Vornamen(...), Familienname, [Geburtsname] ,...) 

Adresse(PlzBezirk ◦ Zustellamt, Ort, ...) 

erfordert Harmonisierung der Übertragung beider Attribute, da diese über Primärschlüssel gekoppelt 

sind 


Die bisherigen Übersetzungsregeln sind nur Interpretationsregeln, die induktiv über dem Schemaaufbau 

definiert sind und nicht die Möglichkeiten von SQL92 und SQL:1999 unterstützen. 

Ein compilierender Zugang wird i.a. besser sein. 

Übersetzungsregeln in SQL:1999 nach S. Schoradt: 

1. Datensammelnde Regeln 

Für die Transformation eines Typen werden Informationen benötigt, die am Typen direkt an-


zur Tranformation der Typen zusammengetragen. Dies können z. B. die Notwendigkeit der 

Erstellung eines Surrogatschlüssels zu einer Entitytypen oder das Hinzufügen von Integritätsbedingungen 

zu einem Typen sein. 

(a) Erstellen von Surrogatschlüsseln 

Das Erstellen von Surrogatschlüsseln ermöglicht es Objekte, die in der konzeptionellen 

Sicht nur auf sehr komplexe Art zu identifizieren sind, in einem DBMS zu verwalten. 

Hierzu wird zu dem Objekt ein atomares Attribut hinzugefügt, das als neuer Schlüssel für 

das Objekt fungiert. Die existierende Schlüsselbeziehung wird weiterhin mitgeführt und 

gepflegt, dient aber nicht mehr der Identifikation der Instanzen des Objektes. Der Surrogatschlüssel 

zu einem Objekt sollte vom DBMS gepflegt werden, so das die darüberliegende 

Applikation diese technische Veränderung des Schemas nicht beachten muss. 

Dies kann durch Mittel des DBMS zum generieren eindeutiger Objektschlüssel geschehen 

oder aber durch die Erzeugung eines Schlüssels in einem Trigger zum Objekt. 

Durch diese Regel wird zu jeder Entity-Typen oder Relationship-Typen, die Komponente 

einer Relation oder eines Clusters ist, ein Surrogatschlüssel angelegt. Mittels diesem 

wird im Weiteren die Implementation der Relation und die Pflege der damit verbundenen 

Integritätsbedingungen realisiert. 

(b) Optimierung der Schemastruktur 

Bei der Übersetzung von Schemata kann es notwendig sein das Schema strukturell zu 

verändern, um ein optimales Ergebnis zu erzielen. Eine häufig genutzte Optimierungsvariante 

ist das Auflösen von Relationen mit der Kardinalitätsbeschränkung (1, 1) oder 

(0,1). 

(c) Integritätsbedingungen 

Oftmals sind Integritätsbedingungen indirekt im konzeptionellen Schema kodiert. Um diese 

bei der Transformation zu beachten, müssen sie zur Menge der Integritätsbedingungen 

eines Typen hinzugefügt werden. 

Diese Regeln weisen zum Einen die Komponenten einer Relation als Schlüssel aus, falls 

noch nicht geschehen und vergeben für alle Relationen deren Kardinalität nicht spezifiziert 

ist die Kardinalitätsbeschränkung (0,n). 

2. Elementare Transformationen 

An dieser Stelle sollen für die einzelnen Schemaelemente elementare Übersetzungsregeln angegeben 

werden. Diese Wandeln einen Typen in eine SQL Anweisung oder einen Anweisungsteil 

um. 

Die Transformationen, die in diesen Regeln verwandt werden, stammen grösstenteils aus [Tha00] 

und wurden an die Möglichkeiten von SQL:1999 und den entworfenen Übersetzungsprozess 

angepasst. 

(a) Regeln für Domaintypen 

Jeder Domaintyp im Schemagraph repräsentiert eine Domäne aus dem HER Schema. 

Diese sind durch die Menge aller erlaubten Elemente beschrieben und müssen durch die 

Transformation auf die vorhandenen SQL Datentypen abgebildet werden. 

SQL:1999 kennt Datentypen der Kategorien: 

• Zeichendaten 

• numerische Daten 

• Wahrheitswerte 

• Datumswerte 

Die richtige Transformation der Domains in SQL Datentypen wird durch die Kombination 

von Transformationsregel und Bewertungsfunktion erreicht. 

(b) Regeln zur Behandlung von Attributtypen 

Bei den AttributTypen hängt die Anwendung einer Regel von ihrem Konstruktor und den


• einführen von Blattattributen, z. B. wird ein Tupelattribut Name(vname,nname) in die 

Attribute Name.vname und Name.vname transformiert 

• erstellen eines eigenen Subschemas 

• als komplexes Attribut belassen 

In SQL:1999 ergibt sich weiterhin die Möglichkeit komplexe Attribute in komplexe Datentypen 

zu transformieren. 

Diese Option wurde soweit möglich verfolgt, um die Möglichkeiten von SQL:1999 auszunutzen. 

Bei der Transformation von Tupeltypen, kann als Implementation ein ROW Typ verwandt 

werden. 

Mengentypen werden rekursiv, anhand ihrer Struktur, transformiert. Es existieren mehrere 

Möglichkeiten Mengen in einer Datenbank zu repräsentieren, hier soll dies durch das 

Erstellen einer Tabelle zu jeder Menge geschehen. Zur Transformation eines mengenwertigen 

Attributs muss zuerst der Inhalt der Menge transformiert werden und danach das 

Attribut in eine Tabelle und eine Referenz in die Mengentabelle transformiert werden. 

(c) Transformation der Entity-Typen 

Die Transformation eines Entity-Typen kann erfolgen wenn alle enthaltenen Attribut- 

Typen transformiert wurden. 

(d) Transformation von Relationship-Typen 

Die Transformation eines Relationship-Typen kann erfolgen wenn alle Attribute und alle 

enthaltenen Objekte transformiert wurden. 

Hierzu müssen die enthaltenen Relationen und Entityen in Fremdschlüsselbeziehungen 

umgewandelt werden. Die enthaltenen Attribute werden analog zur Transformation eines 

Entity-Typen behandelt. 

(e) Transformation von Cluster-Typen 

Ein Cluster-Typ wird transformiert nachdem alle enthaltenen Relationen bzw. Entityen 

transformiert wurden. 

Der Cluster C = R1 + R2 + . . . + Rn wird in eine Referenz auf die Surrogatschlüssel der 

enthaltenen Relationen transformiert, ohne aber mittels einer Fremdschlüsselbeziehung 

abgesichert zu werden. 

3.3.3 Spezifika der Semantik-Übersetzung von HERM-Schemata 

Beobachtung 3. 

Weder SQL’92 noch SQL:1999 erlauben eine vollständige direkte Übertragung von Integritätbedingungen. 

Es können Integritätsbedingungen auf unterschiedliche Art übertragen werden: 

• Restrukturierung des Schemas bis eine vollständige Übertragung unterstützt wird. 

• Deklarative Spezifikation der Integritätsbedingungen. 

• Prozedurale Spezifikation der Integritätsbedingungen. 

• Abbildung der Integritätsbedingungen in eine Wirtssprache 

• Zusätzliche integritätsbedingungssichernde Maßnahmen 

• Sicherstellung durch Benutzungsschnittstellen 

• Sicherstellung durch Ausnahmebehandlung 

• Generierung und Benutzung von sicheren integritätspflegenden Funktionen anstelle der 

nicht invarianten Funktionen

IMMEDIATE 

fordert die Kontrolle einer Integritätsbedingung für jede Anweisung, mit der diese 


MATCH-Bedingungen. 

SQL-92 erlaubt unterschiedliche MATCH-Bedingungen: 

• einfach als nicht spezifiziertes “default” und Anwendung auf alle Tupel t über Attributliste X 

mit t[X]!, d.h. über Teilmenge {t ∈ R C | ∀A ∈ X : t(A) ≠ NULL} , 

d.h. z.B. für R[X] ⊆ S[Y ], X = A 1 ...A k , und Y = B 1 ...B k wird die Bedingung 

∀t ∈ R C ( (∃i (1≤i≤k) t(A i ) = NULL) ∨ ∃s ∈ S C (t[X] = s[Y ])) 

• FULL wird angewandt auf alle Tupel, die nicht das NULL-Tupel sind, wobei dann Nullwerte 

nicht erlaubt sind, 


∀t ∈ R C ( ∀i (1≤i≤k) (t(A i ) = NULL) ∨ 

(∀i (1≤i≤k) (t(A i ) ≠ NULL) ∧ ∃s ∈ S C (t[X] = s[Y ]))) 

• PARTIAL wird angewandt auf alle Tupel t, deren X-Wert nicht das NULL-Tupel ist, wobei in 

der Kontrollmenge eine Gleichheit bis auf Nullwerte in t[X] besteht, 


∀t ∈ R C ( ∀i (1≤i≤k) (t(A i ) = NULL) ∨ 

∃s ∈ S C (∀i (1≤i≤k) (t(A i ) = NULL ∨ t(A i ) = s(B i )))) 

wobei diese Bedingung äquivalent ist zu 

∀t ∈ R C (∃s ∈ S C (∀i (1≤i≤k) (t(A i ) = NULL ∨ t(A i ) = s(B i )))) . 

FULL kann auch direkt ausgedrückt werden durch: 

CHECK ( 

(A1 IS NULL AND ... AND Ak IS NULL) 

OR 

( A1 IS NOT NULL AND ... AND Ak IS NOT NULL 

AND A1,...,Ak 

IN SELECT B1 ... Bk FROM S )) 

PARTIAL ist auch darstellbar durch eine Fallunterscheidung je nach vorkommenden Nullwert im 

referenzierendem Tupel: 

CHECK ( 

(A1 IS NULL AND ... AND Ak IS NULL) 

OR 

( A1 NULL AND A2 IS NOT NULL ... AND AK IS NOT NULL 

AND A2,...,Ak 

IN SELECT B2 ... Bk FROM S ) 

OR ... OR 

( A1 IS NOT NULL ... AND A(k-1) IS NOT NULL AND AK IS NULL 

AND A1,...,A(k-1) 

IN SELECT B1 ... B(k-1) FROM S ) 

OR ... OR 

( A1 IS NULL AND ... A(k-1) IS NULL AND AK IS NOT NULL 

AND Ak 

IN SELECT Bk FROM S ) 

) 

Ausführungsmodi. 

SQL-92 hat bereits Asuführungsmodi eingeführt: 

DEFERRED erlaubt das Aufschieben eine Kontrolle der Integritätsbedingungen bis zum Ende einer 

Transaktion.


INITIALLY IMMEDIATE NOT DEFERABLE ist die default-Bedingung für Integritätsbedingungen. 

Diese Bedingung kann auch durch NOT DEFERABLE INITIALLY IMMEDIATE deklariert 

werden. 

INITIALLY DEFERRED NOT DEFERABLE Diese Bedingung kann auch durch NOT DEFERABLE 

INITIALLY DEFERRED deklariert werden. 

INITIALLY DEFERRED DEFERABLE Diese Bedingung kann auch durch DEFERABLE INITIALLY 

DEFERRED deklariert werden. 

INITIALLY IMMEDIATE DEFERABLE sollte stets für alle Bedingungen deklariert werden, die 

mit Transaktionen ggf. verletzt werden können. Diese Bedingung kann auch durch DEFERABLE 

INITIALLY IMMEDIATE deklariert werden. 

Der Ausführungsmodus kann umgesetzt werden mit 

bzw. 

bzw. 

bzw. 

SET CONSTRAINTS name list IMMEDIATE 

SET CONSTRAINTS name list DEFERRED 

SET CONSTRAINTS ALL IMMEDIATE 

SET CONSTRAINTS ALL DEFERRED 

Deklarative Spezifikation mit CHECK-Bedingungen. 

CHECK-Bedingungen werden definiert 

• auf Attributniveau zu den Werten dieses Attributes, 

• auf Tabellenniveau für jedes einzelne Tupel der Relation, wobei hier auch subselect erlaubt sind 

und 

• über den Umweg der Defintion mit Assertions. 

Deklarative Spezifikation mit ASSERTION. 

ASSERTION ist eine Schema-Bedingung. Sie ist jedoch relativ selten realisiert. Oracle erlaubt 

z.B. nicht die Spezifikation. 

CREATE ASSERTION Institut 

CHECK (Bedingung); 

Sie wird immer dann aktiviert, wenn die Klassen zu den verwendeten Tabellen modifiziert werden. 

CREATE TABLE Fakultaet ( 

... 

Nummer FakNr PRIMARY KEY, 

.. ); 

CREATE ASSERTION AssignFakultaet 

CHECK (NOT EXISTS ( 

SELECT * 

FROM Institut 

WHERE FakNr IS NULL) 

); 

CREATE ASSERTION AnzahlInstZuFak


Die erste der beiden Assertionen wird kontrolliert bei jder Veränderung zu Institut. Die zweite 

wird kontrolliert bei jeder Veränderung sowohl von Institut als auch von Fakultaet. 

Prozedurale Spezifikation mit Triggern. 

Trigger sind mit den Event-Condition-Action-Paradigma entworfen (kurz ECA). Damit gewähren 

Trigger anderen Möglichkeiten als die anderen SQL-Konstrukte. 

So kann z.B. mit Oracle folgender Trigger spezifiziert werden. 

CREATE OR REPLACE TRIGGER TriggInstitutFakult 

AFTER INSERT ON Institut 

FOR EACH ROW 

WHEN (new.Fakultaet NOT IN 

(SELECT Nummer FROM Fakulataet)) 

BEGIN 

INSERT INTO Fakultaet (Nummer) 

VALUES (:new.Fakultaet); 

END; 

. 

run 

Folgende Besonderheiten sollten beachtet werden: 

• OR REPLACE kann auch nicht spezifiziert werden. Sollte jedoch bereits ein Trigger existieren, 

dann ist dies ein Fehler. 

• AFTER kann auch ersetzt werden durch BEFORE . 

• Wird der Trigger für eine Sicht spezifiziert, dann kann auch anstelle von AFTER der Ersatz 

durch INSTEAD OF benutzt werden. Damit kann auch eine Sicht modifiziert werden. 

• Anstelle von INSERT kann auch DELETE oder UPDATE OF verwendet 

werden. 

• FOR EACH ROW kann man auch weglassen. In diesem Fall wird der Trigger nur einmal für 

jede Modifikationsmenge zur Relation angewandt. 

• Die Variablen new und old repräsentieren den Zustand nach bzw. vor Anwendung der 

Modifikationsoperation. Bei Verwendung der Variablen in Anfragen ist der Doppelpunkt erfoderlich 

( :new.Fakulataet ). 

• Die Aktionen sind Anweisungen des Systemes. Mitunter sind sie verschieden in verschiedenen 

Systemen. 

• Durch den Punkt wird die Triggerdefinition abgelegt mit einem run . 

• Oracle erlaubt keine Veränderung einer Relation, deren Trigger feuert, sowie auch von assoziierten 

Relationen (z.B. über Fremdschlüssel). 

Trigger in Sybase 

Eine Integritätsbedingung als Sybase-Trigger in unserem Beispiel wird z.B. wie folgt beschrieben 

create trigger tI_eingeschriebenIn on eingeschriebenIn for INSERT as 

begin 

declare 

@numrows int, 

@nullcnt int, 

@validcnt int, 

@errno int,

create trigger tD_EingeschriebenIn 

after DELETE 

on EingeschriebenIn 

for each row 

declare numrows INTEGER; 

begin 

/* ON CHILD DELETE RESTRICT */ 

select count(*) into numrows from Student 

where 

:old.MatrNr = Student.MatrNr; 


update(MatrNr) 

begin 

select @nullcnt = 0 

select @validcnt = count(*) 

from inserted,Student 

where 

inserted.MatrNr = Student.MatrNr 

if @validcnt + @nullcnt != @numrows 

begin 

select @errno = 30002, 

@errmsg = ’Cannot INSERT eingeschriebenIn because Student does not 

goto error 

end 

end 

return 

error: 

raiserror @errno @errmsg 

rollback transaction 

end 

go 

Trigger in Oracle 

Analog wird ein Trigger mit Oracle deklariert, mit dem ein Update in anderen Relationen erzwungen 

wird: 

create trigger tI_eingeschriebenIn 

after INSERT 


for each row 


begin 

/* ON CHILD INSERT CASCADE */ 

insert into Student (MatrNr) 

select MatrNr 

from EingeschriebenIn 

where 

not exists ( 

select * from Student 

where 

:new.MatrNr = Student.MatrNr 

); 

end; 

/


-20010, 

’Cannot DELETE EingeschriebenIn because Student exists.’ 

); 

end if; 

end; 

/ 

create trigger tU_EingeschreibenIn 

after UPDATE 


for each row 


begin 

/* ON CHILD UPDATE RESTRICT */ 

select count(*) into numrows 

from StarkerTyp 

where 

:new.MatrNr = Student.MatrNr; 

if ( 

numrows = 0 

) 

then 

raise_application_error( 

-20007, 

’Cannot UPDATE EingeschriebenIn because Student does not exist.’ 

); 

end if; 

end; 

/ 

create trigger tD_Student 

after DELETE 

on Student 

for each row 


begin 

/* ON PARENT DELETE RESTRICT */ 

select count(*) into numrows 

from einfachabhangig 

where 

EingeschriebenIn.MatrNr = :old.key; 

if (numrows > 0) 

then 

raise_application_error( 

-20001, 

’Cannot DELETE Student because EingeschriebenIn exists.’ 

); 

end if; 

end; 

/ 

/* Student ON PARENT UPDATE CASCADE */ 

/* Student ON CHILD DELETE RESTRICT */


Trigger in PostgreSQL 

Trigger könne in PostgreSQL durch Funktionen realisiert werden, die die neue RECORD Variable 

nutzen: 

• Es wird die Funktion deklariert. 

• Der Trigger benutzt die Funktion. 

Funktionendefinition: 

CREATE FUNCTION trigger_insert_update_relName() 

RETURNS opaque 

AS 

’BEGIN 

IF ... 

THEN RAISE EXCEPTION ’’Mitteilung an alle’’; 

END IF; 

RETURN new; 

END;’ 

LANGUAGE ’plpgsql’; 

Damit kann nun der Trigger spezifiziert werden: 

CREATE TRIGGER tr_relName 

BEFORE INSERT OR UPDATE 

ON relName 

FROR EACH ROW 

EXECUTE PROCEDURE 

trigger_insert_update_relName() 

; 

Zusammenfassende Übersicht. 

Art SQL-92 SQL-99 

Entry Level Intermediate Level Full Level 

Primary immer sofort immer sofort 

key, domain 

constraints 

Unique NOT NULL, immer 

constraints sofort 

Referential MATCH wird nicht MATCH wird nicht 

constraints unterstützt 

unterstützt 

Check- ohne subquery ohne subquery 

Bedingungen 

Assertions nicht unterstützt nicht unterstützt 

3.3.4 Allgemeine Grundlagen der Erzwingung von Integritätsbedingungen 

In SQL 99 bestehen mehrere Möglichkeiten Integritätsbedingungen auszudrücken und zu erzwingen. 

Diese sind 

• Tabellenbedingungen, wie PRIMARY KEY, UNIQUE oder CHECK Beschränkungen 

• Ausnahmen (Assertion), die einen unerwünschten Zustand in der Datenbank verhindern 

• Trigger, die ermöglichen auf Datenbankoperationen zu reagieren


Komplexere Bedingungen können mittels Ausnahmen (Assertions) oder Trigger beschrieben werden. 

Bei einer Ausnahme, wird ein erwünschter Datenbankzustand beschrieben, und es wird von der 

Datenbank nach jeder datenverändernden Aktion garantiert, das dieser noch erfüllt wird. Wird der 

Zustand nicht erfüllt, so wird die Aktion abgelehnt. Durch Trigger kann nach einer datenverändernden 

Aktion individuell reagiert werden. 

Schlüsselbedingungen: Die Behandlung von HER Schlüsselbedingungen kann auf zwei Arten erfolgen. 

Zum einen durch eine statische UNIQUE Bedingung über den Schlüsselfeldern der 

erstellten Tabelle oder aber durch eine Ausnahmebehandlung mittels ASSERTION. 

Die Auswahl des geeigneten Mittels hängt von der Komplexität des Schlüssels ab. Schlüssel 

im HER Ansatz werden als generalisierte Untermengen [Tha91, S. 7] der Attributmenge eines 

Entity-Typs beschrieben. Diese können nur auf die Schlüsselbedingungen in SQL abgebildet 

werden, wenn die Untermenge nur aus atomaren Attributen des Entity-Typen besteht. 

Ist diese Bedingung für den Schlüssel nicht erfüllt, so muss dieser in eine ASSERTION transformiert 

werden. 

Stehen keine Ausnahmen zur Verfügung, kann ebenfalls ein Trigger, der bei Verletzung der noch 

zu definierenden Schlüsselbedingung key condition ein Rollback der letzten Datenbankaktion 

auslöst, verwandt werden. Solch ein Trigger müsste zu allen des Objekt E betreffenden Tabellen 

in der Datenbank erstellt werden. 

Aus diesem Grunde stellt eine Ausnahme die vorzuziehende Alternative dar. 

Um die Schlüsselbedingung zu garantieren darf es keine zwei verschiedenen Datensätze in E 

geben, bei denen alle atomaren Schlüsselattribute und die aus den mengenwertigen Schlüsselattributen 

ableitbaren Mengen gleich sind. Da Mengen in SQL nicht auf kanonische Weise 

vergleichbar sind, wird der Zusammenhang M 1 = M 2 ⇔ M 1 ∪ M 2 \ M 1 ∩ M 2 = ∅ für den 

Vergleich zweier Mengen verwandt. Dieser lässt sich mittels UNION, INTERSECTION und 

EXCEPT in SQL ausdrücken. Anhand dieser Betrachtungen wurde die Abfrage key condition 

abgeleitet: 

SELECT COUNT(_) FROM E e1, E e2 

WHERE e1.s1 = e2.s1 AND . . . AND e1.sk = e2.sk 

AND NOT EXISTS 

( 

( 

( SELECT i1 FROM set m1 WHERE set id = e1.k1.m1 ) 

UNION 


) EXCEPT ( 


INTERSECT 


) 

) 

. . . 

AND NOT EXISTS 

( 

( 

( SELECT il FROM set ml WHERE set id = e1.kl.ml ) 

UNION 

( SELECT il FROM set ml WHERE set id = e2.kl.ml ) 

) 

EXCEPT


) 

) 

AND e1. E id e2. E id 

Wertebereichsbeschränkungen sollen den Wertebereich direkt spezifizieren. Diese können entweder 

durch einen extra spezifizierten Wertebereich dargestellt werden (die bessere Variante) 

oder durch eine Bedingung in der Tabellendefinition. 

CREATE TABLE Institut ( 

... 

Fakultaet 

.. ); 

char(1) NOT NULL 

CHECK VALUE IN (’1’, ’2’, ’3’, ’4’), 

Besser ist die Definition eines Wertebereiches 

CREATE DOMAIN FakNr CHAR(1) CHECK VALUE IN (’1’, ’2’, ’3’, ’4’); 

und die Benutzung dieses Wertebereiches mit 

CREATE TABLE Institut ( 

... 

Fakultaet 

.. ); 

FakNr NOT NULL, 

Hierarchiebedingungen: Oft werden Hierarchien abgebildet im Vereinigungszugang. So kann z.B. 

due Hierarchie Person, Professor in einen Typ abgebildet werden: 

CREATE TABLE Person ( 

Name char[40] Primary Key, 

Gebdatum date Primary Key, 

Geburtsort char[20], 

Adresse 

char[60] 

Spezialisierung varchar[50] CHECK ((InIName IS NULL 

AND Spezialisierung IS NULL) 

OR (InIName IS NOT NULL 

AND Spezialisierung IS NOT NULL)) 

InIName char[15] CHECK ((InIName IS NULL 

AND Spezialisierung IS NULL) 

OR (InIName IS NOT NULL 

AND Spezialisierung IS NOT NULL)) 

); 

Kardinalitätsbedingungen: Die Transformation der Kardinalitätsbeschränkungen, benötigt einige 

Vorbetrachtungen, die es uns im späteren ermöglichen einigen Problemen bei der Behandlung 

dieser zu umgehen. 

Kardinalitätsbeschränkungen beschreiben die Beziehungen zwischen Relationen und ihren Komponenten 

in einem HER Schema. 

Bei der Betrachtung einer Menge von Kardinalitätsbeschränkungen ist schnell ersichtlich, das 

bei schlechtem Design Konstellationen entstehen können, die nach der Transformation auf eine 

Datenbank in dieser unerwartete Effekte erzeugen können, z.B. zu unerfüllbaren Datenbank-


Tests auf Nichterfüllbarkeit und der Möglichkeiten zur Korrektur der Kardinalitätsbeschränkungen 

eines Schemas kann die Menge der Kardinalitätsbeschränkungen soweit möglich in einen 

konsistenten Zustand gebracht werden, so das die Transformation auf das Datenbankniveau 

keine unerwarteten Effekte erzeugt. 

Die Transformation der Kardinalitätsbeschränkung kann analog zu den Schlüsselbeschränkungen 

in einen Trigger oder eine Ausnahme erfolgen. Es ist aber auch unter speziellen Bedingungen 

möglich, Kardinalitätsbedingungen durch eine Transformation des Ergebnissschemas 

auszudrücken. So kann bei Kardinalitätsbedingungen der Form comp(R, R i ) = (n, 1) , mit 

n ∈ {0, 1} auf einer binären Relation R, die Relation R aufgelöst werden und in die Relation 

R i hineingezogen werden. Das bewirkt das alle Attribute aus R zu Attributen von R i werden. 

Gilt n = 0 wird der Spaltendefinition noch eine NULL Definition hinzugefügt. 

Handelt es sich nicht um eine Kardinalitätsbeschränkung der obigen Art, so ist die Transformation 

in einen Trigger der Ausnahme vorzuziehen, da individuell auf die Verletzung der Bedingung 

reagiert werden kann. 

Zu jeder Kardinalitätsbeschränkung ist die zu triggernden Aktionen bei Veränderung oder Löschen 

des referenzierten Datensatzes als Transformationsparameter zu beachten. Die Transformation 

der Kardinalitätsbeschränkung comp(R, R i ) = (m, n) führt zu einer Veränderung der Relation 

und zu mehreren Triggern. Für die Kardinalitätsbedingung sind die Aktionen 

• Einfügen von Elementen in Ri 

• Verändern der Identifikationsspalte (hier des Surrogatschlüssels) von Ri. Dieser Fall sollte 

nicht auftreten, ist aber aus Stabilitätsgründen trotzdem zu behandeln. 

• Einfügen von Elementen in R. Es können hier die Beschränkungen von 26 überschritten 

werden. 

• Verändern der Ri Spalte von R. Hier sind die unteren und oberen Grenzen der Kardinalitätsbedingungen 

zu überprüfen. 

• Löschen von Elementen von R. Hier ist die untere Grenze der Bedingung zu prüfen. zu 

überwachen. 

Werden durch eine dieser Aktionen die Bedingungen verletzt, so wird die auslösende Aktion 

zurückgenommen. 

Hierbei ist im Zusammenhang mit dem Hintergrund der Datenpflege zu beachten das bestimmte 

Integritätsbedingungen erst nach dem Ende einer Transaktion gepflegt werden dürfen, da sonst 

ihre Erfüllung praktisch ünmöglich ist. Dies ist z. B. bei Kardinalitätsbeschränkungen der Form 

comp(R, E) = (1, n) der Fall. Beim Einfügen eines Datensatzes in E muss auch ein Eintrag in 

der Relation R erfolgen. Dies kann praktisch durch eine Transaktion geschehen, in der erst der 

Datensatz in E angelegt wird und daraufhin der Datensatz in R. 

Für die Transformation einer Kardinalitätsbeschränkung werden auch Trigger erzeugt, durch 

die die Einhaltung der Kardinalitätsbedingung comp(R, R i ) = (m, n) erreicht wird. Sie verhindern 

jede datenverändernde Aktion (Insert, Update oder Delete), durch die die Kardinalitätsbedingung 

verletzt werden könnte. Da die Kardinalitätsbedingung per Definition in der leeren 

Datenbank erfüllt ist, so ist sie es auch in jeden Folgezustand. 

Wir können Kardinalitaätsbedingungen in zwei Klassen von Integritätsbedingungen aufspleißen: 

1. Unäre tupelgenerierende Bedingungen 

LHS ⊑ minimal multiplicity RHS bzw. card(RHS, LHS) = (a, .) 

• Insertion in LHS: Kaskadierend in RHS oder Verbot für LHS (wenn IC ungültig, 

RESTRICT (als harte Bedingung: wird sofort vor allen anderen kontrolliert) oder 

NO ACTION (als weiche Bedingung: wird nach allen anderen IC kontrolliert)) oder 

Benutzung von Ersatzwerten (DEFAULT oder NULL)[wobei diese Optionen nur in


• Delete in RHS: CASCADE in LHS oder RESTRICT (in SQL-92: Default-Regel; 

wenn nicht deklarierts) bzw. NO ACTION in RHS oder SET DEFAULT bzw. SET 

NULL in LHS oder bewußte Verletzung (SKIP) 

• Delete in LHS: keine Auswirkungen 

• Update in LHS: CASCADE in RHS oder RESTRICT bzw. NO ACTION in LHS 

oder SET DEFAULT bzw. SET NULL in RHS [wobei diese Optionen nur in Ausnahmefällen 

sinnvoll sind] oder bewußte Verletzung (SKIP) 

Default-Strategie für fast alle Systeme: REJECT 

• Update in RHS: CASCADE in LHS oder RESTRICT bzw. NO ACTION in RHS 

oder SET DEFAULT bzw. SET NULL in LHS oder bewußte Verletzung (SKIP) 

Erzwingungsmodus als Hexatupel (i LHS , λ, λ, d RHS , u LHS , u RHS ) 

ausreichend ist bereits Quadrupel (i LHS , d RHS , u LHS , u RHS ) 

z.B. card(EingeschriebenIn, Student) = (1, .) erfordert (i Stud =C,λ,λ,d Eing =R,u Stud =R,u Eing =R 

bzw. (i Stud =C,d Eing =R,u Stud =R,u Eing =R) 

Realisierung: 

• RESTRICT für Insert und Update bei card(RHS, LHS) = (1, .) bei EingeschriebenIn 

: 

ALTER TABLE Student ADD CONSTRAINT 

CHECK(EXISTS(SELECT * FROM EingeschriebenIn 

WHERE EingeschriebenIn.StudMatrNr = MatrNr)); 

Alternativ kann auch bei einigen Systemen die RESTRICT-Regel direkt den Attributen 

zugeordnet werden: 

CREATE TABLE EingeschriebenIn ( 

StudMatrNr char[7] CHECK( 

StudMatrNr IN (SELECT MatrNr FROM Student) 

), 

... 

Bis date CHECK ( Von < Bis ) 

PRIMARY KEY (SName, StudMatrNr) 

); 

Die Möglichkeit wird z.Z. nur rudimentär unterstützt. Z.B. Oracle erlaubt keine Subqueries 

in Bedingungen. Die CHECK-Bedingung ist weniger restriktiv, da eine Veränderung 

in Student nicht auf EingeschriebenIn durchgegeben wird! Sie wird nur 

kontrolliert, wenn das entsprechende Attribut sich in EingeschriebenIn ändert 

(d.h. bei Update und Insert). 

Analog für RESTRICT für Insert und Update bei card(RHS, LHS) = (3, .) 


CHECK(EXISTS( 

SELECT * FROM EingeschriebenIn E1, 

WHERE E1.StudMatrNr = MatrNr 

AND EXISTS( 

SELECT * FROM EingeschriebenIn E2 

WHERE MatrNr = E2.StudMatrNr 

AND E1.SName E2.SName 

AND EXISTS( 


WHERE E3.StudMatrNr = MatrNr 

AND E1.SName E3.SName 

AND E2.SName E3.SName)))); 

• Modi für Delete und Update für Komponentenabhängigkeiten R[S] ⊆ S


REFERENCES Student(MatrNr) 

ON DELETE CASCADE 

ON UPDATE RESTRICT, 

... 



); 


CHECK(EXISTS(SELECT * FROM EingeschriebenIn 

WHERE EingeschriebenIn.StudMatrNr = MatrNr)); 

Damit erhalten wir die folgende Auflösung für den Fall R 1 [X] ⊑ (1,.) R 2 [Y ] für den Fall, 

daß Y ein Schlüssel von R 2 ist: 

CASCADE RESTRICT NO ACTION NULL/DEFAULT 

insert R1 

delete R1 – – – – 

update R1 

insert R2 – – – – 

delete R2 foreign key foreign key foreign key foreign key 

update R2 foreign key foreign key foreign key foreign key 

Im allgemeinen Fall erhalten wir die folgende Auflösung für den Fall R 1 [X] ⊑ (a,.) R 2 [Y ] 

: 

CASCADE RESTRICT NO ACTION NULL/DEFAULT 

insert R1 stored procedure CHECK CHECK DEFER- 

RED 

delete R1 – – – – 

update R1 trigger CHECK CHECK DEFER- 

RED 

insert R2 – – – – 

delete R2 

update R2 

2. Numerische Beschränkungen card(RHS, LHS) = (0, b) 

• Insertion in LHS: kein Effekt 

• Insertion in RHS: CASCADE in RHS (Bereinigung (DELETE von Konkurrenten)) oder RE- 

STRICT bzw. NO ACTION in RHS oder bewußte Verletzung (SKIP) 

• Delete in LHS: keine Auswirkungen (bzw. positive Auswirkungen) 

• Delete in RHS: keine Auswirkungen 

• Update in LHS: CASCADE in RHS oder RESTRICT bzw. NO ACTION in LHS oder bewußte 

Verletzung (SKIP) 

• Update in RHS: CASCADE in RHS (Bereinigung (DELETE von Konkurrenten)) oder RE- 

STRICT bzw. NO ACTION in RHS oder bewußte Verletzung (SKIP) 

Erzwingungsmodus als Hexatupel (λ, i RHS , λ, λ, u LHS , u RHS ) 

ausreichend ist bereits Tripel (i RHS , u LHS , u RHS ) 

z.B. card(EingeschriebenIn, Student) = (0, 3) erfordert (i Eing =R,u Student =C,u Eing =R) 

. 

Spezielle numerische Beschränkungen sind funktionale Abhängigkeiten. Diese können 

wie card(RHS, LHS) = (0, 1)-Abhängigkeiten behandelt werden. 

• Primärschlüsselabhängigkeiten werden sowohl im Entry als auch Intermediate Level 

von SQL’92 sofort erzwungen. Es wird die “Entity-Integrität” gefordert (keine 

Nullwerte in diesen Attributen), d.h. es wird gefordert ∀t ∈ R C (t[K]!). 

• Sekundarschlüsselabhängigkeiten erlauben einen variablen Erzwingungsmodus: im-


• SQL-99 fordert bei UNIQUE-Bedingungen den Vergleich nur bei gleichzeitig 

voll definierten Teiltupeln: 

∀t∀t ′ (t[X]! ∧ t ′ [X]! → t[X] ≠ t ′ [X]). 

• ORACLE erzwingt UNIQUE nur für vollständig definierte Teiltupel, d.h. 

∀t∀t ′ (t[X] = NULL ∨ t ′ [X] = NULL ∨ 

((∃A ∈X (t[A]! ∨ t[A]!)) → t[X] ≠ t ′ [X]). 

• DB2, Informix, Sybase, MS SQL, Ingres, Sybase Anywhere definieren dagegen 

∀t∀t ′ (t[X] ≠ t ′ [X]) . 

Realisierung: 

• RESTRICT für Insert und Update bei card(RHS, LHS) = (0, 2) in der Relation 

EingeschriebenIn : 

ALTER TABLE EingeschriebenIn ADD CONSTRAINT 

CHECK(NOT EXISTS( 

SELECT * FROM EingeschriebenIn E1, 

WHERE EXISTS( 


WHERE E1.StudMatrNr = E2.StudMatrNr 

AND E1.SName E2.SName 

AND EXISTS( 


WHERE E3.StudMatrNr = E2.StudMatrNr 

AND E1.SName E3.SName 

AND E2.SName E3.SName)))); 

Analog mit Schachtelung der Tiefe b + 1 für card(RHS, LHS) = (0, b). 

Besser ist in diesem Fall sogar die Einführung eines Surrogat-Schlüssels für die Relation 

EingeschriebenIn, weil bei komplexeren Schlüsseln die Bedingungen E1.SName E3.SNa 

dann um den gesamten Schlüssel von EingeschriebenIn erweitert werden müssen. 

Relationale Integritätsbedingungen: Relationale Integritätsbedingungen werden auf der Basis der 

relationalen Algebra formuliert. 

Unter der Menge der möglichen relationalen Integritätsbedingungen sind zwei Klassen besonders 

zu beachten, da sie in der Modellierungspraxis recht häufig benötigt werden: 

Inklusionsbeziehungen: Durch Inklusionsbeziehungen werden statische Beziehungen zwischen 

Objekten in der Datenbank beschrieben. Ihre Transformation kann, wie in den vorherigen 

Fällen, in Trigger oder Ausnahmen erfolgen. Da die beiden Transformationen ineinander 

überführbar sind, wird hier im folgenden nur die Transformation in eine Ausnahme 

betrachtet. 

CREATE ASSERTION R inc S 

CHECK ( 

NOT EXISTS ( 

SELECT * FROM R 

WHERE NOT EXISTS ( 

SELECT S id 

FROM S 

WHERE S.Y1 = R.X1, . . . , S.Yk = R.Xk 

) 

) 

) 

Bei mehreren Inklusionsabhängigkeiten zwischen R und S muss der Name der Ausnahme


CREATE TABLE EingeschriebenIn ( 

StudMatrNr char[7] CHECK( 

StudMatrNr IN (SELECT MatrNr FROM Student) 

), 

... 



); 

Exklusionsbeziehungen: Die Exklusionsbeziehungen werden analog zu den Inklusionsbeziehungen 

in eine Ausnahme transformiert. Hierzu ist zu prüfen, das es kein Element in R 

gibt, zu dem ein passendes Element in S existiert. Dies wird durch den SQL Ausdruck 

CREATE ASSERTION R_exclus_S 

CHECK ( 

NOT EXISTS ( 

SELECT * FROM R 

WHERE EXISTS ( 

SELECT S id 

FROM S 

WHERE S.Y1 = R.X1, . . . , S.Yk = R.Xk 

) 

) 

) 

comp(R, R i ) = (m, n) 

CREATE TRIGGER comp_R_i_R_insert 

AFTER INSERT ON R_i 

REFERENCING NEW TABLE inserted 

WHEN ( ( SELECT COUNT(*) FROM R, inserted 

WHERE R.R i = inserted.R_i_id ) < m ) OR 

( SELECT COUNT(*) FROM R, inserted 

WHERE R.R_i = inserted. R_i_id ) > n ) ) 

ROLLBACK TRANSACTION 

CREATE TRIGGER comp_R_i_R_update 

AFTER UPDATE OF R_i id ON R_i 


REFERENCING OLD TABLE deleted 

WHEN ( ( SELECT COUNT(*) FROM R, deleted 

WHERE R.R_i = inserted.R_i_id ) < m ) OR 


WHERE R.R_i = inserted. R_i_id ) > n ) ) 


CREATE TRIGGER comp R_R_i_insert 

AFTER INSERT ON R 


WHEN ( ( SELECT COUNT(*) FROM R_i, inserted 

WHERE inserted.R_i = R_i. R_i_id ) < m ) OR 


WHERE inserted.R_i = R_i. R_i_id ) > n ) ) 


CREATE TRIGGER comp_R_R_i_update


WHERE deleted.R_i = R_i.R_i_id ) < m ) OR 

( SELECT COUNT(*) FROM R_i, inserted 

WHERE inserted.R_i = R_i. R_i_id ) > n ) ) 


CREATE TRIGGER comp_R_R_i_delete 

AFTER DELETE ON R 

REFERENCING OLD TABLE deleted 

WHEN ( ( SELECT COUNT(*) FROM R_i, deleted 

WHERE deleted.R_i = R_i.R_i_id ) < m ) ) 


3.3.5 Übersetzung in Netzwerk- und hierarchische Modelle 

Netzwerkmodell 

Zwei Konstrukte: Recordtyp, Settyp 

stark implmentationsabhängig trotz Codasyl-Standards 

Recordtyp : Name, Menge von Attributen mit ihren Wertebereichen 

Attribute 

• einfache Attribute 

• mengenwertige Attribute: Vektor 

• zusammengesetzte mengenwertige Attribute: Wiederholgruppe 

Settyp : beschreibt 1-m-Beziehung zwischen Recordtypen 

Records, die mit mehreren anderen Records in Beziehung stehen: Owner 

die in Beziehung gesetzten: Member 

hat eigenen Namen und keine Attribute 

Settypen können auch mehrere Membertypen haben, meist wird jedoch Zweistelligkeit der Beziehung 

hervorgehoben und nur jeweils ein Membertyp zugelassen; damit dann graphische Repräsentation 

durch Bachman-Diagramme 

Settyp ist kein Mengentyp !! Codasyl empfiehlt Liste !! 

Professor 

hält 

✲ 


Ein Pfeil wird von A nach B gezeichnet, wenn eine partielle Funktion von B C nach A C existiert. 

entgegen der Pfeilrichtung 

Settyp (Member-Records eines Sets) wird kann auf folgende Art und Weise implementiert: 

• entweder first/last: neuer Record stets als erstes/letztes Mitglied einer Set-Occurrence 

eingefügt 

• oder next/prior: Einfügen jeweils vor bzw. nach laufendem Pointer (z.B. letzte Anfrag) 

• oder System Default: wird durch System übernommen 

• oder Sortiert: nach Werten vorgegebener Attribute


erlaubt ist jedoch zusätzlich: 

ein Record kann mehrfach Owner-Record verschiedener Settypen sein 

ein Record kann gleichzeitig Member-Record verschiedener Settypen sein 

es können gleichzeitig mehrere Settypen zwischen gleichen Paaren von Recordtypen gebildet werden 

Abfederung der Inflexibilität durch: 

Set-Insertion-Option Einfügen eines neuen Member-Records vom Typ R 

• Automatisch: falls R Membertyp in Settyp S, dann neuer Record auch in S eingefügt 

• Manual: Einfügen in S ist Programmierersache 

Set-Retention-Option Member-Record vom Typ R in S löschen 

• Optional: Record kann ohne Mitgliedschaft in Set-Occurrence in DB existieren 

• Mandatory: Record muß in eine Occurrence eingebunden sein 

• Fixed: Record R muß in S verbleiben 

Da im obigen Schema Vorlesung kein Attribut haben darf: 

• entweder Hinzunahme der Vorlesungsattribute zum Professor 

• oder 

Übersetzung von ER-Schemata in Netzwerkdiagramme 

Verschiedene Strukturen müssen aufgelöst werden: 

• Relationship-Typen höherer Ordnung (> 1) bzw. Arität (> 2) 

• Relationship-Typen mit eigenen Attributen 

• rekursive Relationship-Typen 

• IsA-Relationship-Typen 

• z.T. 1-1-Beziehungen 

• Cluster 

Folgende Strukturen können im wesnetlichen erhalten bleiben: 

• Entity-Typen mit genesteten Attributen 

• attributlose, binäre 1:n Relationshiptypen 

Übersetzung der Problemfälle 

• 1-1-Beziehungen ohne Attribute: entweder Zusammenfassen zu einem Typ oder Bildung eines 

Settyps für einen der beiden Typen 

• m-n-Beziehungen bzw. nicht-binaäre Beziehungen: Einführen mehrerer Settypen und eines 

Membertyps (Kett-Typ) mit Set-Beziehungen zwischen diesem und dem Ownertypen 

Attribute werden dem Kett-Typen zugeordnet 

• IsA-Beziehungen: wie 1-1-Beziehungen in umgekehrter Richtung 

Unterscheidung total/partiell geht verloren; muß über DML gelöst werden 

• Rekursive Typen: Duplizierung des Recordtyps mit Umbenennung oder Einbeziehung eines 

Dummy-Member-Typs


Person 

IsA 

IsA 

❄ 

Professor 

✠ 

Student 

✠ betreut 

hält 

❘ 


besucht wird-besucht 

❘ 

✠ 

Stud-Vorles 




setzt 

voraus IsA 

❄ ❄ 

Dummy 

wird vorausgesetzt 

von IsA 

✻ 

❄ 

Vorausges 


✻ wird vorausgesetzt 

von 

✻ 

IsA 

Vorausges 


Optimierung der Übersetzung durch entsprechende ER-Normalisierung 

Ersetzung der genesteten Strukturen durch flache: 

Mengennestung wird durch Einführung eines neuen Kett-Typs aufgehoben mit entsprechender Set- 

Typen-Einführung 

Tupelnestung wird verflacht 

Integritätsbedingungen sind Programmiereraufgabe bis auf: 

Domain-Bedingungen: mit CHECK-Klausel 

Intrarecord-Bedingung: duplicates are not allowed for < Attribut > 

ist aber keine Schlüsselbedingung 

Interrecord-Bedingung: gleichbenannte Attribute können über CHECK getestet werden (damit referentielle 

Integrität möglich) 

Hierarchisches Modell 

alle Daten durch Baumstrukturen dargestellt 

Datenbank durch Wald strukturiert 

Beziehungen sind 1:1 oder 1:n 

Wurzel ist nicht optional


3.4 Normalisierung 

3.4.1 Gründe zur Normalisierung 

Probleme der Modellierung. 

Die Datenbankspezifikation ist gezeichnet von 

Modellierungsbeschränkungen durch die 

gewählte Spezifikationssprache, in der ggf. die Anwendung nur mit komplexen Spezifikationen 

und verwickelten Schemata unterstützt wird, 

gewählte Spezifikationsmethodik, die ggf. zu falschen Spezifikationsurteilen führt, den Kontext 

der Modellierung und die gewählte Referenzmodellierung 

unterlegte Spezifikationstheorie mit Modalität, Gewißheit und Schärfe der Modellierungsurteile, 

sowie die Urteilsart und 

Wahl des Ausschnittes der Realität, der modelliert wird 

Implementationsbeschränkungen z.B. aufgrund der Verarbeitung im DBMS. Typische Beschränkungen 

sind: 

Beschränkungen des SQL-Dialektes 

Beschränkungen der Integritätspflege z.B. durch Zulassung von wenigen Integritätsbedingungen 

wie 

Wertebereichsbeschränkungen 

Schlüsselbeschränkungen und 

referentielle Integritätsbedingungen 

Beschränkungen des DBMS insbesondere Speicherverwaltung und Transaktionsverarbeitung 

Verhalten von semantisch sinnvollen Einheiten, das (nicht) berücksichtigt wird und durch Dekomposition 

ggf. erschwert wird. 

Optimierungserfordernisse. 

Probleme bei der Optimierung von Datenbankanwendungen sind: 

(A) Redundanzprobleme durch schwierige oder ggf. auch Nichtunterstützung kontrollierter Redundanz 

(B) Informationsblockierung aufgrund der Informationskapazität des Schemas 

Insert-Anomalie durch rigide Erzwingung von einfügebeschränkenden Integritätsbedingungen 

(C) Informationsverluste von DB-Modifikation z.B. 

Delete-Anomalie: Es werden Teil-Informationen in Objekten, die eine eigenständige Bedeutung 

haben vernichtet 

(D) Evolutionsempfindlichkeit und Instabilität bei Veränderungen (Evolutionsresistenz bzw. Evolutionsrobustheit 

erfordert eine vollständig andere Architektur von Schemata. Dazu existiert bis 

auf die TIS@CAU-Ansätze kein Lösungsvorschlag.) 

(E) Unterschiedliche Abstraktionen in partieller Koexistenz z.B. auch Sichten 

(F)Performanzprobleme durch Spezifika der Anwendung, durch falsche Strukturierung (ggf. auch 

bei Wahl der falschen Normalisierung), komplexe oder verwobene Datenstrukturen.


Update-Anomalie, bei der eine Einobjektoperation zu einer Bulkoperation wird, z.B. ein 

table scan erfordert, damit die Architektur von DBMS schon aufgrund der beschränkt 

vorhandenen Ressourcen im Puffer- und Cache-Bereich grausam überfordert 

Anfragefehlverhalten aufgrund von der Berechnungskomplexität priorisierter Anfragen 

Wird aufgehoben durch Zusammenführung von Strukturen (Denormalisierung): 

Vorteile der Denormalisierung: 

Erhöhung der Berechnungsgeschwindigkeit im Retrieval 

Blockierung der Separation semantisch sinnvoller Einheiten und damit Vermeidung von 

zusätzlichen Verbunden und Reduktion von Fremdschlüsseln 

Vorausberechnung und Mitführung abhängiger Daten mit redundanten Attributen und 

abgeleitete Daten 

Reduktion von notwendigen Indizes 

Reduktion der Anzahl von Tabellen 

Einführung von Surrogatattributen zur Vereinfachung der Identifikation und von Fremdschlüsseln 

Nachteile der Denormalisierung 

Update slow down und DBMS-internes slow down 

hohe Abhängikeit von der Anwendung und Inflexibilität bei Evolution 

hohe Redundanz ohne einfache Pflegemechanismen 

(G) Schwierige Pflege und Modifizierbarkeit von Daten 

Ansatz zur Messung der Qualität von Schemata. 

Gegeben sei eine Menge M aller möglichen Typen einer Anwendung. Diese Menge kann von einer 

minimalen Menge erzeugt werden. Es können nun Teilmengen von M betrachtet werden. 

Vollständige Teilmengen erlauben die Ableitung aller anderen Typen in M. 

Korrekte Teilmengen besitzen keine Typen, die mit anderen Typen im Widerspruch stehen. 

Unter den vollständigen und korrekten Teilmengen F ULL(P(M)) können wir die optimalen Schemata 

OP T IMAL(P(M)) herausschälen. Es kann nun das gefundene Schema S dagegen bewertet 

werden. Dazu werden die minimalen Abstände gemessen: 

NumbOfConcept(S) − NumbOfErr(S, S ′ ) 

correctness OP T (S) = max S ′ ∈OP T IMAL(P(M)) 

Concept(S ′ ) 

NumbOfConcept(S) − NumbOfDifferences(S, S ′ ) 

completeness OP T (S) = max S ′ ∈OP T IMAL(P(M)) 

Concept(S ′ ) 

Diese beiden Maße können kombiniert werden zu: 

mit 

SQ = (β2 + 1.0) × completeness OP T (S) × correctness OP T (S) 

β 2 × completeness OP T (S) + correctness OP T (S) 

β = 1: Korrektheit und Vollständigkeit gleichwertig 

β = 0: nur Korrektheit bewertet 

β = ∞: nur Vollständigkeit bewertet 

Diese Maße stehen in Korrelation zu Maßen aus dem Information Retrieval 

Präzision zum Messen der Korrektheit (F: gefunden; R: relevant)

• verlustfrei: gleiche Daten repräsentiert 


Recall zum Messen der Vollständigkeit 

Fallout zum Messen der Inkorrekheit einer Funktion 

3.4.2 Allgemeines Herangehen 

|F(q, D 1 )) ∩ R Q S 1 ,S 2 

(q, D 1 )| 

|R Q S 1 ,S 2 

(q, D 1 )| 

|F(q, D 1 )) \ R Q S 1 ,S 2 

(q, D 1 )| 

|ALL \ R Q S 1 ,S 2 

(q, D 1 )| 

Zerlegung der Datenbankanwendung in Komponenten. 

Dieser Ansatz stellt eine Eigenentwicklung der TIS@CAU-Gruppe dar, basiert auf dem Herausschälen 

von Komponenten und einer Entwicklung einer Kollaborationsarchitektur zwischen den Komponenten. 

Herausfinden von verbotenen Teilstrukturen. 

2. Normalform Teilschlüssel implizieren nicht Nicht-Schlüsselattribute 

3. Normalform jedes Nicht-Schlüssel-Attribut darf nur direkt von einem Schlüssel abhängen (kein 

transitiver Schluß) 

Boyce-Codd-Normalform jede nicht-triviale funktionale Abhängigkeit ist eine Schlüsselabhängigkeit 

4. Normalform jede geltende mehrwertige Abhängigkeit ist ableitbar aus den geltenden Schlüsselabhängigkeiten 

5. Normalform jede geltende Verbundabhängigkeit ist ableitbar aus den geltenden Schlüsselabhängigkeiten 

Einfüge-, Lösch- und Update-Anomalien treten genau dann nicht auf, wenn nur funktionale Abhängigkeiten 

gelten und Schema in BCNF ist 

Separation von verschiedenen Gesichtspunkten. 

Schema Datenbank Anfragen Anfrageergebnisse 

zeitunabhängige Beschreibung 

zeitabhängige Beschreibung 

Entwurf durch Modularisierung und Separation von Aspekten 

Redundanzarmut und günstiges Verhalten (z.B. keine Anomalien (insert, delete, update erfordern 

Nacharbeit)) durch Verbot von Teilstrukturen und Trennung von Gesichtspunkten 

R = (R 1 , ..., R m , Σ 0 ) , R i = (U i , Σ i ), Σ = ⋃ m 

i=1 Σ i ∪ Σ 0 verbotene Teilstrukturen 

durch Normalisierung 

als adäquate Dekomposition T und Wiederherstellungsoperation f 

T (R i , Σ i ) = (R i,1 , ..., R i,k , Σ T i ) 

R j i = (U i,j, Σ i,j ) 

2 Eigenschaften

Boyce-Codd-Normalform verboten ist folgende Eigenschaft in Σ i : 


• Unabhängige Pflege der Teilstrukturen 

Damit erhalten wir 4 Teilaufgaben: 

1. Semantische Eigenschaften = syntaktische Eigenschaften 

2. Beweis der obigen = 

3. Algorithmen zur Gewinnung 

4. geringe Kosten 

Formalisierung von Heuristiken 

Separation Einheitliches Verhalten Ableit. von Gesichtspunkten 

Aufgabe 1 : Aufgabe 1: 

( keine verbotenen Teilstrukturen) (semantische Forderungen) 

- 3NF - Verbundpfade eindeut. - sichere Sichteninstanzunterstütz. 

- BCNF -sichere Sichtenanfrageunterst. 

- 4NF 

- 5NF (syntaktische Forderungen) - für FD’s : join support 

- referent. NF - γ-azyklisch (X 1 , ..., X n ) ∈ Σ + 

- unique-key NF - α-azyklisch ∪F i ) + ⊇ F 

Beziehungen 

- BCNF & Verbundunterstützung sind compatibel (Dekomp.) 

- 3NF und sichere Verbundunterstützung sind compatibel (Synthese) 

γ-azyklisch gdw. Verbundpfade sind wesentlich eindeutig 

Optimierung zur Entwurfszeit 

Aufgabe 4: Syntaktische Eigenschaften garantieren geringe Kosten 

Speicherung Anfragen update 

-Normalformen γ-Azykliz. ohne Referenzen 

- Verbundbäume monoton 1 Schlüssel 

- Projektion über Überdeck. BCNF 

von Verbunden 

α-Azykliz. 

- Existenz von 

monotonen Verbundbäumen 

3.4.3 FD-basierte Normalformen für das relationale Modell 

Üblicher Zugang: 

T ist definiert durch eine Verbundabhängigkeit und Projektion und f ist der entsprechende Verbund 

möglich ist ebenso: Horizontale Dekompositionsabhängigkeit, Partition und Vereinigung 

Verbotene Teilstrukturen definiert durch verschiedene Normalformen : 

3NF verboten ist folgende Eigenschaft in Σ i : 

Z → {A} ∈ Σ + i , A ∉ Z, A Nichtschlüsselattribut (d.h. in keinem Schlüssel von R i), Z → 

U i ∉ Σ + i 

Nachteil: entscheidbar in NP



Z →→ X ∈ Σ + i , X ⊈ Z, Z → U i ∉ Σ + i 

Strenge Project-Join-NF verboten ist folgende Eigenschaft in Σ i : 

(Y 1 , ..., Y k ) ∈ Σ + i 

, {X → U i ∈ Σ + i } ̸|= (Y 1, ..., Y k ) 


(Y 1 , ..., Y k ) ∈ Σ + i 

, ∃j : Y j → U i ∉ Σ + i 

Project-Join-NF verboten ist folgende Eigenschaft in Σ i : 

(Y 1 , ..., Y k ) ∈ Σ + i 

, {X → U i ∈ Σ + i } ̸|= (Y 1, ..., Y k ) 

Überstrenge Project-Join-NF verboten ist folgende Eigenschaft in Σ i : 

(Y 1 , ..., Y k ) ∈ Σ + i 

, ∀X → U i ∈ Σ + i 

: {X → U i } ̸|= (Y 1 , ..., Y k ) 

InklusionsNF verboten ist folgende Eigenschaft in Σ i : 

R i [X] ⊆ R j [Y ] ∈ Σ + und Y → U j ∉ Σ + 

Referentielle Normalform 

genau ein Schlüssel verboten ist folgende Eigenschaft in Σ i : 

es existieren zwei verschiedene mininale Schlüssel 

Vorteil: entscheidbar in P 

Domain-Schlüssel-Abhängigkeit (DKNF) verboten ist die folgende Teilstruktur für die Menge Σ i,K 

der Schlüssel- und Domainabhängigkeiten von Σ + i 

: 

α ∈ Σ + i 

, nichttrivial und Σ i,K ̸|= α 

Achtung: Verschiedene Bücher verwenden davon abweichende Notationen. 

Afunktionale und min-max-Abhängigkeiten 

afunktionale Abhängigkeit: R t |= X −→‖ Y falls für alle ν ∈ R t existiert µ ∈ R t mit ν = X µ und 

ν ≠ Y µ 

zur horizontalen Dekomposition von Relationen 

R t = R t 1 ∪ Rt 2 mit 

• ∅ = R t 1 ∩ Rt 2 

• R t 1 |= X → Y 

• R2 t |= X −→‖ Y 

min-max-Abhängigkeiten geben Wiederholfaktor an und gleichzeitig Begrenzung für Redundanz 

Nichtnull-Abhängigkeiten 

Ableitbarkeit von Aspekten 

Semantische Forderungen der relationalen Praxis


Sichere Unterstützung von Sichten wenn = 

Sichtenanfrage-Unterstützung ∀Q ∈ Query(V, R)∃P ∈ Query(U, R) : Q(V t ) = P (R t ) 

Charakterisierung der semantischen Forderungen 

Sichtenbehandlung Sichtenanfrage-Unterstützung gdw. Unterstützung von Sichten 

im positiven Fall sogar effizient 

sichere Unterstützung von Sichten gdw. ( ⋃ F i ) + ⊇ F und (U 1 , ..., U m ) ∈ Σ + 

Unique-Key Hat ein Relationenschema genau einen minimalen Schlüssel, dann ist es genau 

dann in BCNF, wenn es in 3NF ist. 

DKNF - Anomalien Ein Relationenschema hat genau dann keine Insert und Delete anomalien, 

wenn es in DKNF ist. 

NF-Beziehungen Überstrenge PJNF ⇒ strenge PJNF 

strenge PJNF ⇒ PJNF 

PJNF ⇒ 4NF 

4NF ⇒ BCNF 

BCNF ⇒ 3NF 

||dom(A)|| ≥ 2 : DKNF ⇒ 4NF 

Alle domain-Abhängigkeiten lassen mindestens k Werte zu für k = max.-Komponenten- 

Anzahl in JD von Σ, die eine Überdeckung der Dekomposition darstellen. Dann DKNF 

⇒ PJNF 

Eigenschaften von Integritätsbedingungen: 

Entscheidbarkeit der Implikationseigenschaft 

• entscheidbar für tupelerzeugende und gleichungserzeugende Abhängigkeiten 

• nicht entscheidbar für eingebettete JD’s 

• nicht entscheidbar für eingebettete MVD’s 

• nicht entscheidbar FD’s und ID’s 

Axiomatisierbarkeit von Klassen von Integritätsbedingungen 

• axiomatisierbar FD’s ∪ MVD’s 

• nicht axiomatisierbar für FD’s und Inklusionsabh. 

• axiomatisierbar für tupel- und gleichungserzeugende Abhängigkeiten 

• nicht axiomatisierbar für JD’s 

Komplexität des Implikationsproblemes 

• 3NF ist NP-complete 

• ‘Ist A Schlüsselattribut’ ist NP-vollständig 

• BCNF ist polynomial 

• Ein-Schlüssel-Problem ist polynomial 

{A ∈ U i |U i \ {A} ∉ Σ i } −→ U i ∈ Σ i 

Algorithmen Normalisierung in 2 verschiedenen Herangehensweisen 

Analyse allgemeines Herangehen: wenn Schema nicht redundanzfrei, dann zerlege das Schema 

in 2 (oder mehrere) Teilschemata 

Beispiel:


R 1,1 = ({SSN, Stadt, Alter, Sex}, {SSN → Stadt, SSN → Alter, SSN → Sex}) 

R 1,2 = ({Stadt, Land}, {Stadt → Land}) 

R 2 = ({Land, Staat}, {Land → Staat}) 

Nachteile: Erhaltung der IC’s ist meist schwierig zu kontrollieren 

Weiteres Beispiel: 

Ort, Bundesland, Ministerpräsident, Einwohneranzahl 

Regierung: Bundesland 

Städte: Ort, Bundesland, Einwohneranzahl 

Hintergrund: Dekomposition nach Blattabhängigkeiten 

Synthese allgemeines Herangehen: Generierung einer minimalen Überdeckung aller IC’s und 

Synthese nach dieser minimalen Überdeckung von Schemata 

Beispiel: 

R wie oben 

minimale Überdeckung aller Abhängigkeiten : {SSN → Stadt, Stadt → Land, Land → 

Staat, SSN → Alter, SSN → Sex}) 

Gruppenbildung: {SSN, Stadt, Alter, Sex} , {Stadt, Land}, {Land, Staat} 

Hinzufügen eines Schlüsselschemas 

R 1 = ({SSN, Stadt, Alter, Sex}, {SSN → Stadt, SSN → Alter, SSN → Sex}) 

R 2 = ({Stadt, Land}, {Stadt → Land}) 

R 3 = ({Land, Staat}, {Land → Staat}) 

3NF-Algorithmus 

Input: Menge von funktionalen Abhängigkeiten für einen Typ 

Output: ein normalisiertes Schema 

Bestimmung einer kanonischen Überdeckung einer Menge von funktionalen Abhängigkeiten 

Σ c heist kanonische Uberdeckung von ΣF, wenn die folgenden drei Kriterien erfüllt 

sind: 

• Σ + c = Σ + c 

• . In Σ c existieren keine FDs , die überflüßige Attribute enthalten. D.h. es muß 

folgendes gelten: 

• ∀A ∈ X ∧ X → Y ∈ Σ c : Σ c \ {X → Y } ∪ {X \ {A} → Y } ̸|= Σ c 

• ∀B ∈ Y ∧ X → Y ∈ Σ c : Σ c \ {X → Y } ∪ {X → Y \ {B}} ̸|= Σ c 

• Jede linke Seite einer funktionalen Abhängigkeit in Σ c ist einzigartig. Dies kann 

durch sukzessive Anwendung der Vereinigungsregel auf FDs der Art X → Y, X → 

Y ′ erzielt werden, so dass die beiden FDs durch X → Y ∪ Y ′ ersetzt werden. 

Berechnung der kanonischen Überdeckung 

• Führe fur jede FD X → Y ∈ Σ c die Linksreduktion durch, d.h.: 

Überprüfe fur alle A , ob A überflüssig in X → Y ist, d.h. ob A ∈ X + Sigma c 

, X \ 

{A} gilt. Falls dies der Fall ist, ersetze X \ {A} → Y . 

• Führe für jede (verbliebene) FD die Rechtsreduktion durch. 

Überprüfe fur alle B, ob B überflüssig ist, d.h. ob 

∀B ∈ Y ∧ X → Y ∈ Σ c : Σ c \ {X → Y } ∪ {X → Y \ {B}} |= Σ c gilt. 

Falls dies der Fall ist, ist B auf der rechten Seite überflüssig und kann eliminiert 

werden. 

• Entferne die FDs der Form X → ∅, die im 2. Schritt möglicherweise entstanden 

sind. 

• Fasse mittels der Vereinigungsregel FDs der Form X → Y 1 ... X → Y m zu 

X → Y 1 ∪ Y m . 

Konstruktion einer Dekomposition bestehend aus 2 (ggf. leeren) Teilen 

• Für jede funktionale Abhängigkeit von Σ c wird ein Schema angelegt. 

• Ist kein X mit X → Y m zu X → Y 1 ∪ Y m ∈ Σ c ein Schlüssel von R, dann wird


Eigenschaft des Algorithmus: (SSA) 

Proposition 1 Es werden alle Abhängigkeiten erhalten. 

Proposition 2 Das Resultat ist ein Schema, in dem alle Relationenschemata in dritter 

Normalform sind. 

Überblick über Normalisierungsalgorithmen 

Author Strategie NF IC Relships Komplex. 

Bernstein Synthese 3NF FD CR polyn. 

Fagin Analyse 4NF FD+MVD LD exp. 

Biskup/D/B Synthese 3NF FD LD+CR polyn. 

Ullman Analyse 4NF FD+MVD LD exp. 

Tsou/Fischer Analyse 4NF FD+MVD LD polyn. 

Zaniolo/Melkanoff Analyse 3NF FD+MVD LD+CR expon. 

LD = lossless decomposition ; CR = constraint representation 

Theorem 1 Die Zerlegung π X∪Y (R C ) und π X∪Z (R C ) ist verlustlos für disjunkte Mengen 

X, Y, Z falls π X∪Y ∪Z (R C ) = π X∪Y (R C ) ✶ π X∪Y (R C ) gilt. 

Proposition 3 Gilt die funktionale Abhängigkeit X → Y in R C , dann ist die Zerlegung π X∪Y \X (R C ) 

und π X∪U\(X∪Y ) (R C ) verlustlos. 

∀(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 ) 

sind in BCNF 

∀(U, F )∃(X 1 , ..., X m ) : (U, F ) unterstützt sicher (X i , F i ) mit Verbund für Anfragen und alle 

(X i , F i ) sind in 3NF 

Leider werden BCNF nicht durch einen Synthesealgorithmus erzeugt. Es existiert jedoch die 


Ursache von Nicht-BCNF-fähigen Schemata: Überladung von Attributen (Makowsky) 

Behebung: Aufspleißen des Attributes 

Ort, PLZ, Straße 

{ Ort, Straße } → {P LZ} 

{P LZ} → {Ort} 

Überladenes Attribut, das zerlegt werden kann 

PLZ Ortsbereich, PLZ Zustellbezirk 

{ Ort, Straße } → {P LZ Zustellbezirk} 

{P LZ Ortsbereich} ↔ {Ort} 

Speicherkosten Ein Schema S ist in xNF gdw. jede Dekomposition T von S hat für jede DB S t 

komplexere Darstellung, d.h. 

size(S t ) ≤ size(T (S t )) 

Update-Kosten ∀R ∀X ⊆ U i (X → U i ∈ Σ + )∀(R1 t , ..., Rt m) ∀{t} ∈ SAT (R i ) 

{t}, Ri+1 t , ..., Rt m) ∈ SAT (R) 

gdw. R i referenziert nicht, hat genau einen Schlüssel und ist in BCNF 

(R t 1 , ..., Rt i−1 , Rt i ∪ 

Konsistenz von Schemata Verbundabhängigkeit heißt m-zyklisch, wenn äquivalent zu einer Menge 

von Verbundabhängigkeiten mit höchstens m Komponenten jeweils. 

2-zyklisch = azyklisch


Regel 2: falls Y i ⊆ Y j , i ≠ j : (Y 1 , ..., Y m ) ⇒ (Y 1 , .., Y i−1 , Y i+1 , ..., Y m ) 

(Y 1 , ..., Y m ) ⇒ ∗ λ gdw. azyklisch 

Schema R heißt k-konsistent, wenn für beliebige j 1 , ..., j k ∈ {1, ..., m} und i ∈ {j 1 , ..., j k } 

gilt: (R j1 ✶ ... ✶ R jk )[R i ] = R i 

R ist konsistent, wenn m-konsistent 

R ist k-konsistent gdw. (U 1 , ..., U m ) k-zyklisch ist 

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 ] 

Hypergraphen 

zur Darstellung der Join-Verbindung von Attributen in Schemata 

damit kann für Attribute auch eindeutiges Verständnis von Gesichtspunkten ausgedrückt werden 

Universalrelationen-Annahme (universal relation schema assumption) : Jedes Attribut ist bzgl. seiner 

Bedeutung eindeutig unabhängig vom Schema definiert. 

Wenn erfüllt, dann kann gesamte Datenbank als eine Universalrelation (evt. aufgefüllt mit Nullwerten 

- schwache Universalrelation) aufgefaßt werden. 

Basiszusammenhang-Annahme (basic connection assumption): Jede Attributteilmenge X ⊆ U 

hat genau eine Bedeutung im Schema. 

damit Anfragebedeutung durch Attributmenge eindeutig bestimmt 

Ein-Geschmack-Annahme (unique flavour assumption): für jeden Benutzer und jede Attributmenge 

in einem relationalen Ausdruck und jede Datenbank R t ist jedem Tupel unabhängig von der 

Art seiner Erzeugung eine Bedeutung zugeordnet 

Arten von Zyklen in Hypergraphen 

Pfade im Hypergraphen deuten auf die Komplexität der Berechnung von Anfragen hin 

je einfacher der Pfad ist, umso einfacher wird die Berücksichtigung von Nebenbedingungen 

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 

i,j,l 

für Attribute gibt es mindestens zwei verschiedene verbindende Pfade 

z.B. ({A, B}, {B, C}, {C, D}, {D, E}, {E, A}) 

damit zwischen A, C zwei verbindende Pfade, die auch verschiedene Zusammenhänge formalisieren 

können 

γ-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 ≠ ∅ 

dann existieren für Attribute in (Y 2 ∩ Y 3 ) \ Y 1 ≠ ∅ und (Y 1 ∩ Y 2 ) \ Y 3 ≠ ∅ wieder 2 verbindende 

Pfade 

Beispiel: ({A, C, H}, {B, C, K}, {A, B, C, L}) 

zwei verschiedene Pfade zwischen A, B, die evt. verschiedene Zusammenhänge formalisieren 

Damit ist Schema 

γ-azyklisch falls weder purer noch γ-Zyklus existiert 

α-azyklisch wenn obiger Reduktionsalgorithmus von Graham λ liefert 

Ein Schema ist gd. γ-azyklisch, wenn Join monoton ist, bzw. wenn verlustlose Projektionen (join und 

project sind vertauschbar) existieren bzw. gdw. eindeutige Verbindungen existieren . 

d.h. Verbundabhängigkeit des Schemas impliziert alle eingebetteten Verbundabhängigkeiten


C 

✻ 

A 

✛ 

R 

✲ 

B 

A 

✛ 

R2 

Abbildung 9: Ein Beispielschema 

R2 ✲ 

C 

✛ 

R3 

C 

✛ 

❄ 

R1 ✲ 

Schema 2 

B 

❄ 

A 

✛ R1 ✲ 

Schema 3 

❄ 

B 

C 

C 

✛ 

✛ 

R1 ✲ A ✛ R2 ✲ 

Schema 1’ 

R1 ✲ A ✛ R2 ✲ 

Schema 1 

C 

C 

Abbildung 10: Die Zerlegung des Beispielschemas 

Klassische Dekompositionstheorie ergibt bereits eine Reihe von Schemazerlegungen, z.B. das Schema 

in Bild ?? kann in eines der Schemata in Bild ?? zerlegt werden. 

Die Zerlegung hängt von der Gültigkeit von Integritätsbedingungen ab. Der Fall ‘funktionale 

Abhängigkeiten’ ist in der folgenden Tabelle dargestellt. 

Funktionale Abhängigkeiten Schema nach Dekomposition 

{A} → {B} Schema 1 

{A} → {B} → {C} Schema 1’ 

{A} → {B, C} Schema 1 

{A} ↔ {B} → {C} Schema 1, Schema 1’ 

{A} ↔ {B, C} Schema 2 

{A} ↔ {B} ↔ {C} Schema 3 

{A} → {B} ← {C} Schema 3 

{A, B} → {C} 

kein neues Schema 

{A} ↔ {B} Schema 1, Schema 1’ 

Eine analoge Tabelle läßt sich auch für mehrwertige Abhängigkeit angeben. 

Vorsicht vor anderen Zerlegungen der Proponenten des binären Entity-Relationship-Modelles. 

3.4.4 ER-Entwurfstheorie 

Verschiedene Gründe für die Normalisierung: 

+ Speicherminimierung: Redundante Daten erfordern zusätzlichen Speicherplatz. 

+ Minimierung des Risikos inkonsistenter Datenbanken: Die Kontrolle der Konsistenz von 

Datenbanken erfordert zusätzliche Operationen. Da damit die Integritätspflege die Performanz 

eines Systemes negativ beeinflußt, sollte die Konsistenzpflege minimiert werden. 

+ Anomalien: Sind in einer Datenbank Werte redundant gespeichert, dann ist bei jeder Operation 

über solchen Werten entweder diese Operation auch auf redundante Werte angewandt werden 

oder eine extra Spezifikation der Integritätspflege vorgenommen werden.


Traditionelle Normalisierungstheorie 

Lokale Normalisierung: Jede Relation separat. 

Eingeschränkte IC-Zielmenge: Es werden i.a. nur Schlüsselbedingungen unterstützt. 

Besser: 

Globale Normalisierung mit eingeschränkten Zielen (Lokalisierung der zu normalisierenden Teile, 

...). 

Einfache IC-Mengen: Abbildung von (S, Σ) auf (S ′ , Σ ′ ) mit Σ ′ ⊆ GoodConstraints. 

Beispiel bereits in Ansätzen in der relationalen Theorie: DK/NF (domain-key-NF), domain dependencies, 

key dependencies 

Normalisierungszugänge sind meist auf die Struktur einer Datenbank ausgerichtet und berücksichtigen 

kaum, ob semantisch sinnvolle Einheiten zerlegt werden oder sogar die Performanz dadurch sinkt. 

Damit wird nicht die akurate Modellierung bewertet, sondern eher die strukturelle Korrektheit. Deshalb 

wird hier auf Normalisierung nicht in vollem Umfange Wert gelegt. Wir unterscheiden zwischen 

relationaler, hierarchischer und Netzwerk-Normalisierung. Da auch bei der Modellierung bereits 

die Art der Plattform mit berücksichtigt werden kann, sollte man in diesem Schritt auch die Art der 

Normalisierung mit berücksichtigen. Im weiteren wird die relationale Normalisierung bevorzugt. 

Ziel ist ein Schema, das sich in ein Normalform-Schema des logischen Zielmodelles übersetzen läßt 

ohne daß eine zusätzliche Normalformbetrachtung erforderlich wird. Im Vorgriff definieren wir deshalb 

eine HERM-Normalform relationaler Schemata. Darauf aufbauend wird eine Normalform für 

HERM-Schemata definiert. 

Für ein relationales Schema R = (R, F, I) mit der Attributmenge R, den funktionalen Abhängigkeiten 

F und den Inklusionsabhängigkeiten I wird anhand der Inklusionsbeziehungen ein Graph mit 

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 ] 

zusammengestellt (verlassende ID’s). Z R = ∪ n i=1 X i 

Relationshiptyp 0-ter Ordnung: Typ, der keine unpaaren verlassenden ID’s hat (d.h. T [Z] ⊆ R[X] ⇒ 

R[X] ⊆ T [Z]). 

Relationshiptyp i-ter Ordnung: Im Graphen gelten folgende Eigenschaften: 

1. Keine unpaaren verlassenden ID’s. 

2. Mindestens ein Typ S j ist (i − 1)-ter Ordnung. Die maximale Ordnung der Typen S j ist 

i − 1. 

3. Alle linken Seiten der verlassenden ID’s sind paarweise disjunkt. 

4. Alle linken Seiten Z R bilden eine Schlüssel von R. 

Schwacher Typ i-ter Ordnung: Folgende Bedingungen gelten: 

1. n ≥ 1 

2. Für jeden minimalen Schlüssel W von R existiert eine Zerlegung W 1 , W 2 so daß W 1 ∩ 

X i = ∅ oder W 1 ∩ X i = X i gilt und W 2 ∩ Z = ∅. 

Ein relationales Schema ist in HERM-Normalform, falls 

1. die ID-Menge azyklisch und nicht redundant ist, 

2. alle ID’s schlüsselbasiert sind (d.h. R[X] ⊆ S[Y ] ⇒ Y Teil eines Schlüssels von S oder selbst


4. R zerlegt werden kann in Relationshiptypen entsprechender Ordnung bzw. schwache Typen 

entsprechender Ordnung. 

Ein HERM-Schema ist in Normalform, wenn jeder Typ in BCNF ist, alle Inklusionsabhängigkeiten 

schlüsselbasiert sind und wenn Relationshiptypen durch ihre Komponenten identifizierbar sind. 

Es gilt: Ein HERM-Schema ist in ein relationales Schema in HERM-Normalform genau dann 

durch einfache Transformation ohne Einbettung transformierbar, wenn es in HERM-Normalform 

ist. 

(d.h.: Jedem Typen wird ein relationaler Typ zugeordnet. Komponenten in Relationshiptypen werden 

durch einen minimalen Schlüssel mit entsprechenden Erweiterungen des Namen dargestellt.) 

Analog kann eine Transformation mit Einbettung über comp(R, R ′ ) = (1, 1) definiert werden. Es sei 

V = R \ Z. 

Relationshiptyp 0-ter Ordnung mit Fremdschlüsseln Es gibt nur solche unpaare verlassende ID’s 

R[X] ⊆ S[Y ] mit X ∩ K = ∅ für einen Schlüssel K von R. 

Relationshiptyp i-ter Ordnung mit Fremdschlüsseln wie oben 

Schwacher Typ i-ter Ordnung mit Fremdschlüsseln 

2. wie oben 

1. wie oben 

3. mindestens eine verlassende ID R[X] ⊆ S[Y ], wobei X ein Teil eines minimalen Schlüssels 

ist. 

Ein relationales Schema ist in schwacher HERM-Normalform, falls 

1. die ID-Menge azyklisch und nicht redundant ist, 

2. alle ID’s schlüsselbasiert sind (d.h. R[X] ⊆ S[Y ] ⇒ Y Teil eines Schlüssels von S oder selbst 

Schlüssel von S ist), 

3. alle Typen in BCNF bzgl. F ∪ I sind und 

4. R zerlegt werden kann in Relationshiptypen mit Fremdschlüsseln entsprechender Ordnung bzw. 

schwache Typen mit Fremdschlüsseln entsprechender Ordnung. 

Beispiel: 

Institut = (Name, Gebäude) 

Angestellter = (Name, ArbeitetIn.Institut.Name, Gehalt) 

Angestellter[ArbeitetIn.Institut.Name] ⊆ Institut[Name] 

Dieses relationale Schema kann nach obigen Regeln zur Überführung in ein HERM-Schema überführt 

werden. Wir erhalten die Typen 

Institut’ = ( { Name, Gebäude }, { Name } ) 

Angestellter’ = ( { Name, Gehalt }, { Name } ) . 

Das relationale Schema Angestellter enthält einen Fremdschlüssel. Außerdem gilt die Inklusionsabhängigkeit. 

Bei Einführung eines Relationshiptypen 

ArbeitetIn = ( Angestellter’, Institut’, ∅ ) 

mit den Komplexitätsbeschränkungen 

comp(ArbeitetIn, Angestellter ≽ (0,1) , comp(ArbeitetIn, Angestellter) ≽ (1,n) , 

die sich aus der Schlüsselabhängigkeit von Angestellter undder Inklusionsabhängigkeit ableiten. Das 

HERM-Diagramm ist in Bild ?? dargestellt. Die Einlagerung kann mitunter besser sein aus operationalen 

Gesichtspunkten.


Name 

Gehalt 

Name 

Gebäude 

Angestellter’ ✛ 

(1,1) 

ArbeitetIn 

✲ 

Institut’ 

Abbildung 11: Beispiel für ein HERM-Schema, das in eine schwache HERM-NF überführt wird 

* Festlegen des für den Benutzer noch tolerierbaren veränderten Schemas; 

Hat ein anderes Schema ein besseres operationales Verhalten, ist aber für den Benutzer nicht 

ausreichend einsichtig, dann kann das Transformationsverfahren als Regelwerk abgelegt werden. 

* Automatische Überführung des normalisierten HERM-Schemas in ein normalisiertes relationales 

Schema. 

Der Benutzer kann im weiteren auf dem HERM-Schema arbeiten und ist nicht auf ein Verständnis 

der Normalisierung angewiesen. 

Es gibt eine Reihe von Verhaltensproblemen in Datenbanken, die auf schlechte Strukturierung zurückführbar 

sind: 

Schlüsselbasierte update-Anomalien: Durch eine update-Operation kann eine, die Primär- oder 

alle Schlüsselbeziehungen außer Kraft gesetzt werden. Die beiden ersten Fälle werden bei 4NF 

bzw. BCNF vermieden. 

Schlüsselbasierte insert-Anomalien: Obwohl nach einer insert-Operation alle Schlüsselbeziehungen 

gelten, kann eine andere Integritätsbedingung, die vorher galt, nicht mehr gelten. Schemata 

in vierter Normalform sind frei von diesen Anomalien. 

Schlüsselbasierte delete-Anomalien: Obwohl nach einer delete-Operation alle Schlüsselbeziehungen 

gelten, kann eine andere Integritätsbedingung, die vorher galt, nicht mehr gelten. Schemata 

in vierter Normalform sind frei von diesen Anomalien. 

Nichtdeterministische Operationen: Die Verfeinerung der Operation führt zu einer Operation, die 

je nach Fall verschiedene Eingabeinformationen erfordert. Man kann unterscheiden in Identifikationsinformationen 

und Objektinformationen, die auf das betroffene Objekt abzielen. Ist ein 

Typ in BCNF bzw. in 4NF, dann ist ein solches Verhalten ausgeschlossen für die Verfeinerung 

der einfachen Operationen. 

Objektbasierte update-Anomalien: Obwohl das Einfügen des modifizierten Objekten wieder zu 

einem konsistenten Zustand führt, ist die direkte Modifikation nicht konsistent. 

Redundante Informationsmengen: Eine Information kann ohne Benutzung dieser aus bereits in 

der Datenbank vorhandenen Informationen abgeleitet werden. 

3.4.5 ER-basierte Behandlung von mehrwertigen Abhängigkeiten 

Mehrwertige Abhängigkeiten sind genuine ER-Abhängigkeiten wie wir im weiteren zeigen werden. 

Wir betrachten zuerst einige einfache Beispiele: 

Name 

Gehalt 

Name 

Gebäude 

Angestellter’ ✛ 

(1,1) 

ArbeitetIn 

✲ 

Institut’ 

Abbildung 12: Beispiel für ein HERM-Schema, das in eine schwache HERM-NF überführt wird

Äquivalenzbeweis: (1) ⇒ (2) ⇒ (3) ⇒ (1) 

Z.B. für (1) ⇒ (2) ist Ziel: R C ⊇ R C [X ∪ Y ] ✶ R C [X ∪ Z] 

Gegeben seien t 1 ∈ R C [X ∪ Y ] und t 2 ∈ R C [X ∪ Z] mit t 1 = X t 2 

⇒ {t 1 } ✶ {t 2 } ⊆ R C wegen R C |= X → Y |Z 


Student ✛ 

✻ 

❨ 

Belegt 

✲ 

Vorles 

InDept 

Von 

❄ 

Dept 

❥ 

Leiter 

Abbildung 13: Ungünstige Zerlegung des komplexen Typen 

Student ✛ 

Belegt 

✲ 

Vorles 

✻ 

InDept 

❄ 

Dept 

✛ 

Leitet 

✲ 

Leiter 

Abbildung 14: Bessere Zerlegung des komplexen Typen 

{ Name } → { Abteilung, Mitversichert }|{ Projekt, Produkt, Lieferant } 

{ Name } → { Mitversichert }|{ Abteilung, Projekt, Produkt, Lieferant } 

{ Projekt } → { Name, Abteilung, Mitversichert }|{ Produkt, Lieferant } 

{ Produkt } → { Abteilung, Name, Mitversichert, Projekt }|{ Lieferant } 

Ein Mitarbeiter determiniert die Abteilung und seine Mitversicherte unabhängig von den Projekten 

und benutzten Produkten, sowie deren Lieferanten. 

... 

In einem Projekt wird mit Produkten von Lieferanten unabhängig von den Mitarbeitern, deren Mitversicherten 

und deren Abteilungen gearbeitet. 

Ein Produkt wird von einem Lieferanten geliefert, unabhängig wer in welchem Projekt damit arbeitet. 

Gegeben: relationales Schema R = (U R , Σ R ), Relation R C über R 

Teilmengen X, Y ⊆ U R und Z = U R \ (Y ∪ X) 

(1) Klassische Definition: R C |= X → Y |Z 

falls für alle t, t ′ ∈ R C mit t = X t ′ ein Element t ′′ ∈ R C 

existiert mit t ′′ = X∪Y t und t ′′ = X∪Y t ′ 

(2) Dekompositionsdefinition: R C |= X → Y |Z 

falls R C = R C [X ∪ Y ] ✶ R C [X ∪ Z] 

(3) Unabhängigkeitsdefinition: R C |= X → Y |Z 

falls (σ X=x (R C ))[Y ] = (σ (X=x)∧(Z=z) (R C ))[Y ] 

für alle X-Werte x ∈ R C [X] und alle Z-Werte z ∈ R C [Z]


Name Abteilung Project Produkt ... 

Bodo DB-Adm Migration DB2 ... 

Bodo DB-Adm Integration Sybase ... 

Bodo DB-Prog Migration DB2 ... 

Bodo DB-Prog Integration Sybase ... 

Hans DB-Adm Ablösung MS SQL ... 

Hans Middlew Ablösung MS SQL ... 

Karl DB-Prog Migration DB2 ... 

Karl DB-Prog Portal Sybase ... 

... ... ... ... ... 

• Ableitung von Tupeln aus existierenden: 

Name Abteilung Project Produkt ... 

Bodo DB-Adm Migration DB2 ... 

Bodo DB-Prog Integration Sybase ... 

Bodo DB-Adm Integration Sybase ... 

• Dekomposition in { Name, Abteilung } und { Name, Project, Produkt,...} 

Name Abteilung Name Project Produkt ... 

Bodo DB-Adm Bodo Migration DB2 ... 

Bodo DB-Prog Bodo Integration Sybase ... 

Hans DB-Adm Hans Ablösung MS SQL ... 

Hans Middlew Karl Migration DB2 ... 

Karl DB-Prog Karl Portal Sybase ... 

... ... ... ... ... 

Zwei weitere Definitionen sind die folgenden: 

(4) Konstruktordefinition: R C |= X → Y |Z 

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] 

d.h. ν Z (ν Y \X (ν X (R C ))) = ν Y \X (ν Z (ν X (R C ))) 

(5) Strukturierungsdefinition: R C |= X → Y |Z 

R C {X} {Y } {Z} 

A 1 ... A k A k+1 ... A m A m+1 ... A n 

... ... ... ... ... ... ... ... ... 

X = {A 1 , ..., A k }, Y = {A k+1 , ...., A m }, Z = {A m+1 , ..., A n } 

als verschachtelte Relation 

Weiterführung der Beispiele 

• Verschachtelte Relation: (Name, {Abteilung }, { Project, Produkt,...} ) 

Name { Abteilung } { (Project, Produkt, ...) } 

Bodo { DB-Adm, DB-Prog } { (Migration, DB2, ...) 

(Integration, Sybase,...) } 

Hans { DB-Adm, Middlew } { (Ablösung, MS SQL, ... )} 

Karl { DB-Prog } { (Migration, DB2, ...) 

(Portal, Sybase, ...) } 

... ... ... 

Die ER-Behandlung von MVD’s. 

Gegeben: relationales Schema R = (U R , Σ R ), Relation R C über R 

Teilmengen X, Y ⊆ U R und Z = U R \ (Y ∪ X)


Y ✛ XY ✲ X ✛ XZ ✲ 

Z 

✛ 

XY ✲ X ✛ XZ ✲ 

Das Beispielschema und die behandelte MVD wird dann durch das folgende ER-Diagramm repräsentiert: 


Ein adäquate Behandlung von MVD ist nur mit vollständiger rechter Seite sinnvoll. 

Die Axiomatisierung von mehrwertigen Abhängigkeiten in der ER Welt. 

Ableitungsregeln in der klassischen relationalen Notation: 

Gegeben seien: 

X, X ′ , X ′′ , Y, Y ′ , Z, Z ′ , V, W ⊆ U 

alle Mengen einer Abhängigkeit bilden Überdeckung von U 

Axiom: (1 M ) X → ∅|Z 

Regeln 

(23 M ) 

(27 M ) 

(21 M ) 

X → X ′ ∪ Y |X ′′ ∪ Z 

X ∪ X ′ ∪ X ′′ → Z|Y 

X ∪ V → Y |Z , X → Y ∪ Z|V 

X → Y |Z ∪ V 

(Abschwächung) 

(Wurzelreduktion) 

X → Y ∪ Y ′ |Z ∪ Z ′ , X → Y ∪ Z|Y ′ ∪ Z ′ (Baumrestrukturierung) 

X → Y |Z ∪ Z ′ ∪ Y ′ 

Theorem 2 (1) (1 M ), (21 M ) und (23 M ) sind vollständig für mehrwertige Abhängigkeiten 

(2) (1 M ), (21 M ), (23 M ) und (27 M ) sind korrekt 

Ableitungsregeln (Strukturell): 

Ableitungsregeln für MVD und FD 

X, X ′ , X ′′ , Y, Y ′ , Z, Z ′ , V, W ⊆ U 

alle Mengen einer mehrwertigen Abhängigkeit bilden Überdeckung von U 

Axiom: (1 F ) X ∪ Y −→ Y (1 M ) X → ∅|Z 

X −→ Y 

Regeln (21 F ) 

(FD − MVD − Reduktion) 

X → Y 

X −→ Y , Y −→ Z 

(22 F ) 

(FD − Transitivität) 

X ∪ V ∪ W −→ V ∪ Z 

(23 M ) 

(3 F,M ) 

(21 M ) 

X → X ′ ∪ Y |X ′′ ∪ Z 

X ∪ X ′ ∪ X ′′ → Z|Y 

X ∪ V → Y |Z , X → Y ∪ Z|V 

X → Y |Z ∪ V 

X ∩ Y 

→ Y \ X|X \ Y , X −→ Z 

X ∩ Y −→ Y ∩ Z 

(MVD − Abschwächung) 

(MVD − Wurzelreduktion) 

(FD − Rückkopplung) 

Theorem 3 (1 F ), (1 M ), (21 F ), (22 F ), (23 M ), (3 F,M ) sind vollständig und korrekt für funktionale 

und mehrwertige Abhängigkeiten.

X 


(Abteilung) 

DB-Adm 

DB-Prog 

Middleware 

✲ Mitarb. ✛ 

Bodo 

Hans 

Karl 

(Project, Produkt,...) 

(Migration, DB2, ...) 

(Integration, Sybase,...) 

(Ablösung, MS SQL, ... ) 

(Portal, Sybase, ...) 

Axiom 

Wurzelreduktion 

X ∪ Z 

✲ 

X 

Y (X) 

✲ X ∪ V ✛ (X)Z Y ∪ Z(X) 

✲ X ✛ (X)V 

Y (X) 

✲ 

X 

✛ (X)Z ∪ V 

Beweis: siehe B. Thalheim - HERM-Buch 

→ Y 1 |Y 2 |...|Y m als Verallgemeinerung der mehrwertigen Abhängi- 

Hierarchische Abhängigkeit X 

keiten 

Ableitungsregel: 

(27 H ) 

X → Y ∪ Y ′ |Z ∪ Z ′ , X → Y ∪ Z|Y ′ ∪ Z ′ (Baumentfaltung) 

X → Y |Y ′ |Z|Z ′ 

Abhängigkeitsbasis 

Gegeben Menge funktionaler und mehrwertiger Abhängigkeiten Σ 

X + = { A ∈ U | Σ |= X −→ {A} } 

Dep M (X, Σ) = { Y i | Σ |= X → Y i , Y i ∩ X + = ∅, 

̸ ∃Y i ′ ⊂ Y i(Y i ′ ≠ Y i ∧ Σ |= X → Y i ′) 

} 

Dep M,F (X, Σ) = Dep M (X, Σ) ∪ { X + \ X } 

Berechnung über Axiomatisierung mit hierarchischen Abhängigkeiten 

analoge Theorie zu Graph-Abhängigkeiten 

Erwünscht: Konkurrenzfreie (konfliktfreie) Abhängigkeitsbasis 

Ausblick zur Abhängigkeitsbasis 

• Es existiert ein O(|R|·|Σ| p )-Algorithmus zur Bestimmung der Abhängigkeitsbasis einer Menge 

X ⊆ U. 

• Konkurrierende Abhängigkeitsbasis besitzt 

• Wurzelschnitt: es existiert für X → Y |Z ∈ Σ ∗ eine spleißende Abhängigkeit 

S → T |V ∈ Σ ∗ , d.h. es gilt sowohl X ∩ T ≠ ∅ als auch X ∩ V ≠ ∅ , 

oder 

• Schnittanomalie: aus Σ |= X → Z|V, Y 

→ Z. 

→ Z|W folgt nicht Σ |= (X ∩Y ) → 

Baumrestrukturierung 

Abschwächung 

Y ∪ Y ′ (X) 

(X)Y ′ ∪ Z ′ 

X ′ ∪ Y (X) 

✲ 

X 

✛ (X)X ′′ ∪ Z 

❄ 

X 

✛ (X)Z ∪ Z ′ 

Y ∪ Z(X) 

✲ 

❄ 

X


Y 2 (X) ... 

Y 1 (X) 

❄ 

✲ 

X ✛ 

(X)Y m 

✲ 

Y ∪ Y ′ (X) 

✛ (X)Z ∪ Z ′ 

X 

✲ 

Y ∪ Z(X) 

✛ (X)Y ′ ∪ Z ′ 

X 

Y (X) 

Y ′ (X) 

❄ 

✲ 

Z(X)... 

❄ 

X ✛ 

(X)Z ′ ✲ 

• Konkurrierende Abhängigkeitsbasis führt zu unterschiedlichen 

Schema-Varianten je nach Sichtweise 

Vereinheitlichung durch Vergröberung oder 

Ergänzung der Abhängigkeiten 

Reduzierte Abhängigkeitshülle: 

Σ ∗ = { X → Y |Z | Σ |= X → Y |Z , X ∩ Y = X ∩ Z = Y ∩ Z = ∅ , Y ≠ ∅ , Z ≠ ∅ } 

Sichtweisen durch Abhängigkeitsbasis 

Sichtweisen durch Abhängigkeitsbasis 

Dekomposition des Relationship-Typen zu einem Teilschema 

nur im Fall konkurrenzfreier mehrwertiger Abhängigkeiten 

ansonsten Wahl einer Sichtweise 

oder Wahl einer Abschwächung 

oder wiederholte Betrachtung der Abhängigkeiten 

z.B. kann Lieferant ggf. falsch angebunden sein (zu schwach spezifiziert) 


Unterschiedliche Sichtweisen sind ggf. je nach Aspekt der Anwendung interessant und können ggf. 

auch konkurrierend benutzt werden. 


Eine kombinierte Sichtweise kann, muß aber nicht existieren. 


• Mehrwertige Abhängigkeiten spezifizieren eine interne Strukturierung. 

• Mehrwertige Abhängigkeiten sind axiomatisierbar. 

Abhängigkeitsbasis 

X 

X + \ X 

✠ 

(X)Y 1 

✛ 

(X)Y 2 

❪ ... 

als Stern-Schema 

Unterschiedliche Sichtweisen 

über Schalen des Sterns


Mitarbeitsichtweise 

DepBasis(Name,Σ) \{ Name} = 

{{ Abteilung }, { Mitversichert }, { Project, Produkt, Lieferant }} 

(Project, Produkt, Lieferant) 

❄ 

Abteilung ✲ Name ✛ Mitversichert 

Projektsichtweise 

DepBasis(Projekt,Σ) \{ Projekt} = 

{{ Produkt }, { Lieferant }, { Name, Abteilung, Mitversichert }} 

(Name, Abteilung, Mitversichert) 

❄ 

Produkt ✲ Projekt ✛ Lieferant 

Kombinierte Sichtweise 

DepBasis(Name,Σ) \{ Name} = 

{{ Abteilung }, { Mitversichert }, { Project, Produkt, Lieferant }} 

DepBasis(Projekt,Σ) \{ Projekt} = 

{{ Produkt }, { Lieferant }, { Name, Abteilung, Mitversichert }} 

Abteilung 

✛ 

arbeitet ✲ Name ✛ Mitversichert 

❄ 

Produkt ✲ Projekt ✛ Lieferant


(auch gemeinsam mit funktionalen Abhängigkeiten 

nicht aber gemeinsam mit Inklusionsabhängigkeiten 

(Verwaschung der Arten)) 

• Die Abhängigkeitsbasis erlaubt eine vollständige Entfaltung zu stärkster hierarchischer Abhängigkeit. 

Die ER-Repräsentation führt zu einem verständlichem Schema. 

• Es können konkurrierende Schemata existieren.


3.5 Verhaltensmodellierung 

Paradigmen 

formale Sprache \ Theorie Abstraktion Entwurf 

erfinden 

• 

verwirklichen • ⋄ 

benutzen 

• 

Einheit von statischen Gesichtspunkten (grundlegende Seiende und Beziehungen) und dynamischen 

Gesichtspunkten 

Veränderungen im Wissen müssen stets zu einer statischen Gesichtspunkten genügenden Aufzählung 

führen 

somit müssen Handlungen stets statisch abbildbar sein 

Seiendes - etwas, das wirklich existiert; kann seine Existenz unabhängig von anderen beginnen und 

beenden; 

damit formale Handlungen des Existenzbeginns und Ende als grundlegend 

Komplexität ⇒ leicht ausführbare Änderung 

Einfügen muß allein der Eindeutigkeitsbedingung genügen 

Löschen soll nicht Löschen von Werten anderer Seinender nachziehen 

Ein Informationssystem besteht aus verschiedenen Teilen. In DBS meist nur struktureller Teil 

korrekt modelliert. Es lassen sich verschiedene Sichten auf ein IS unterscheiden: 

Vermarktungssicht kein Teil eines Verhaltensmodells im Gegensatz zu den weiteren Teilen 

Problemdefinition 

Verkaufsdokumente 

Vermarktungsplanung 

Operationale Sicht Systemausrichtung 

Kontextdiagramme 

Ereignisdiagramme 

Datensicht Datenwörterbuch 

ER-Definition 

Architektursicht Diagramme der Szenarios 

Spezifikation der Szenarios 

Zustandsdiagramme 

Verhaltenssicht Verhaltensdiagramme 

Verhaltensspezifikation 

Prozeßsicht Datenflußdiagramme 

Steuerflußdiagramme 

Prozeßspezifikationen 

Darstellungsmethoden 

Datenflußdiagramme i.a. als Mehrebenendarstellung für unterschiedliche Abstraktionsebenen 

Kontextdiagramme zur Darstellung der Input/Output-Datenströme ohne Aufzeigen der Struktur 

Dialogflußdiagramme zur Darstellung des interaktiven Verhaltens 

Datenflußmodellierung zur Darstellung der Hauptprozesse;


Erweiterungen zu Real-Time-Systeme mit einer expliziten Modellierung der Steuerung (Steuerprozesse, 

Zielprozesse) und des Steuerflußes 

Datendefiniton wie bereits oben 

Prozeßspezifikation zur Modellierung der Datentransformation und Datenverarbeitungspolitik in 

verschiedenen Darstellungssprachen 

Struktogramme, Programmlogik Verzweigung, Schleifen, Verkettung mit Blockbildung 

Strukturierte natürliche Sprache bzw. Pseudocode mit Verben, die imperativ sind, Wörtern, 

die durch ein Wörterbuch begrenzt sind, und einigen logischen Konstrukten zur Darstellung 

der Entscheidung in Verzweigungen, der Wiederholung, der Gruppierung, sowie der 

Input/Output-Darstellung und der Fileverarbeitung 

Allgemeine Aufrufe zur Verarbeitung 

Suspendierung, Termination, Kommentare 

Entscheidungsbäume und -tabellen mit Entscheidungsregeln 

Charts und Graphen zur Darstellung der Abhängigkeit 

Damit allgemeines Verhaltensmodell: 

Motive Ereignisse Szenarios Verhaltensmuster 

zu jeweils einem Motiv zu jeweils einem Ereignis zu jeweils einem Szenario 

Geschäftsprozeß Handlungen Prozesse 

Motivations- Geschäftsprozeß- Aktions- konzeptionelle 

schicht schicht schicht Schicht 

Installation Petrinetze Interfaces Modellierung 

Pflege über Sichten Constraints von Programmen 

Adminstrier. Beziehungen Automatendiagr. 

Benutzung Aggregationen Aktionsdiagr. 

Operationale Integr. Unabhängigk. 

Datenintegrität temp. Sichten 

Operationale Sicht Architektursicht Verhaltenssicht 

Es fehlt hier im Schema jedoch die Implementationsschicht. 

Programme als Verfeinerung der Prozesse. 

Operationale Sicht eines Systems als ‘Customersicht’, wie der Benutzer System sehen möchte; 

darauf aufbauend, warum der Benutzer eine bestimmte Funktion erwartet 

Operationen und Motive (Grund für ein Ereignis und erwartetes Resultat) 

7 verschiedene Erwartungen: Installation, Pflege, Administrierung, Benutzeroperationen, 

Garantierung der Integrität, Fortführung der Funktionalität (operationale Integrität), Benutzerinterface 

Dynamische Integritätsbedingungen, Transitionsbedingungen, Anforderungen über Operationsbedingungen 

(externe Faktoren, die System und Operationen begrenzen), Operationsbegrenzungen 

(Kapazität, Leistungsparameter, Zuverlässigkeit, Sicherheit, Zeitbegrenzungen, 

Interface) 

Spezifikation der Operationsumgebung (Zugriff woher), Kosten (die der Benutzer bereit 

ist zu zahlen), Lieferintervall (wie lange ist der Benutzer bereit zu warten) und Kapazität 

(TA’s/sec, Kommunikationsaufwand, Speicheraufwand,...) 

Systemanforderungen deklarative: 

Leistungsanforderungen der Benutzer 

Zuverlässigkeitsanforderungen der Benutzer für durchgängigen Betrieb (Ein-Prozessor,


Motivationsschicht 

Motive, Ideen, 

Aufgaben, Workflow 

Operationale Sicht - Geschäftsprozeßschicht 

Datensicht 

HERM-Diagramme 

Geschäftsprozesse 

Verhaltensdiagramm 

Systemnutzen 

Kontextdiagramm 

Ereignisdiagramm 

Grobentwurf 

Grobes 

HERM-Schema 

Für jedes Ereignis 

... 

Architektursicht - Aktionsschicht 

✮ 

✙ 

Handlungen❄ 

... 

Szenariospezifikat. 

Szenariodiagramm 





Vorentwurf 

Skelett- 

HERM-Schema 

Verhaltenssicht - Konzept. Schicht 

✮ 

✙ 

Für jeden Prozeß 

... 

... 

Prozesse 

❄ 

Verhaltensspezifikat. 





Konzeptionelles 

Schema 

HERM-Schema 

Für jedes Programm 

... 

Implementationsschicht 

✮ 

✙ 

... 

Programme❄ 

Programmspezifikat. 

Programmdarstellung 





Phys./Log. 

Datensicht 

DBMS 

Data 

Dictionary


Externe Schnittstellen mit Help etc. 

Andere Anforderungen 

Ereignis - Änderung im System oder Umgebung, die eine Aktivität auslöst oder durch System 

auslöst 

Externe Ereignisse System reagiert auf externe Ereignisse mit Input (stimulus) und generiert Output 

(response); 

haben Motiv 

Temporale Ereignisse bedingen Systemaktivität (Trigger etc.) aufgrund Auslösungsmechanismus 

(Zeit etc.) (interne Motive) 

Interne (anormale) Ereignisse , die durch System erkannt werden (interne Organisation zur Herstellung 

der Leistung, ...) 

Motive und Ereignisse als Benutzersicht des Systems ⇒ 5 Motive 

Installationsmotive Installation, Update, Setzen von Systemparametern, Initialisierung von Datenbeständen, 

etc. 

Berücksichtigung im Installationsdialog 

Pflegemotive bei neuen releases, Datenbackup, Recovery ... 

Administrative Motive : neuer Benutzer, Systembenutzung (-mißnutzung), Datensicherheit, temporale 

Ereignisse hinzufügen 

Benutzungsmotive , die zur Notwendigkeit des Systems führen 

Integritätspflege 

Beziehungen zwischen Ereignissen zur Behandlung der Komplexität der Benutzererwartungen 

Entities und Ereignisse Behandlung durch Ereignisdiagramme in Petrinetzdarstellung (Ereignisse 

und Sichten) mit Input/Output in Eventknoten 

Knoten = Ereignisse ∪ Sichten 

Kanten = Ereignisse × Sichten 

Sichten × Ereignisse 

Output von Ereignissen, Input von Sichten 

Output auf requests an 

andere Ereignisse 

Sichten werden aufgefaßt als Input/Output-Generator 

Mehrfachinput kann in ‘and’-Form für Ereignisse aufgefaßt werden 

Mehrfachinput an Sichten ist eine ‘or’-Form zum Anstoßen 

Unabhängigkeit von Ereignissen zur sauberen Modellierung 

falls Daten zwischen Ereignissen ausgetauscht werden müssen, dann über temporale Sichten 

Adminstrative Beziehungen zwischen Ereignissen können über temporale Sichten ebenso 

modelliert werden (als shared Zwischenspeicherung) 

Aggregationen von Ereignissen zur Darstellung der Auslösung mehrerer Zwischenereignisse 

Direktive Beziehungen von Ereignissen zur Darstellung der Auslösung eines Ereignissen 

durch Steuerfluß oder Datenfluß eines anderen Ereignisses 

Als generellen Überbau: Benutzerschnittstellen werden analog spezifiziert. 

Außerdem werden Sichten für die Ereignisse abgeleitet. 

3.5.1 Sprachen zur Verhaltensmodellierung 

Es existieren viele Modelle zur Darstellung der Prozesse und wenige Modelle zur Darstellung der


Formular-orientierte Sprachen erlauben die Modellierung von Folgen von zusammenhängenden 

Aktivitäten. Mit Ablaufmodellen kann der Lebenszyklus eines (Datenbank-)Objektes dargestellt 

werden. In einer Form Definition Component werden die Objekte selbst beschrieben. Mit 

der Document Flow Component wird der Datenfluß beschrieben. Die Document Transformation 

Component erlaubt die programmiersprachliche Beschreibung der Aktivitäten. Aktivitäten 

können selbst zu Gruppen zusammengefaßt werden. Verschiedene parallele Berechnungen sind 

möglich. 

Fluß-orientierte Sprachen modellieren formale Handlungen als Flüsse von Objekten und Mitteilungen. 

Aktivitätengraphen bzw. Vorgangskettendiagramme, Prozeßmodelle und Beschreibungen 

von Lebenszyklen erlauben die Beschreibung von komplexem Verhalten. 

3.5.2 Ereignisorientierte Spezifikation 

Wir wählen hier zuerst einen ereignisorientierten Zugang. Der Zusammenhang von Entities und 

Ereignissen wird durch Ereignisdiagramme in Petri-Netz-Darstellung (Ereignisse und Sichten) mit 

Input/Output in Eventknoten dargestellt. Knoten sind Ereignisse oder Sichten bzw. in einfachen Fällen 

Teilschemata. Kanten verlaufen von Ereignissen nach Sichten bzw. von Sichten nach Ereignissen. 

Sichten werden aufgefaßt als Input/Output-Generatoren. Ein Mehrfachinput kann in ‘and’-Form für 

Ereignisse aufgefaßt werden. Ein Mehrfachinput an Sichten ist eine ‘or’-Form zum Anstoßen. Damit 

ergibt sich eine Petri-Netz-Darstellung wie in Bild ??. 

als 

Sender 

gedeutete 

Sichten: 

Mitteilung 

ermittelt 

Information 

als Erstellung 

und Übertragung von 

Mitteilungen 

gedeutete Transition 

als 

Empfänger 

gedeutete 

Sichten 

eingehende 

Mitteilungen 

Auslösung 

von 

anschließenden 

Handlungen 

✲ 

✯ 

✲ 

... and 

❥ 

✯ 

Transition 

... 

✲ 

❥ 

✲ 

Abbildung 16: Petri-Netz-Darstellung von formalen Handlungen 

Verallgemeinerte Petri-Netze zur Spezifikation von Verhalten. 

Das Verhalten für Einzelobjekte kann durch eine Lebenszyklusspezifikation mit einem verallgemeinerten 

Petri-Netz-Modell (Prädikaten-Transitionsnetz) oder einem Automatengraphen beschrieben 

werden: 

Menge von Zuständen: S o für jedes Objekt in der Datenbank; 

Menge von Aktivitäten: T o für jedes Objekt in der Datenbank; 

Diagramm: D ⊆ S o × T o ∪ T o × S o ; 

Vor- und Nachbedingungen zu Aktivitäten: V o (s, t) für (s, t) ∈ S o ×T o als Vorbedingung für eine 

Aktivität und N o (t, s) für (t, s) ∈ S o × T o als Nachbedingung für eine Aktivität. Damit kann 

eine Darstellung durch eine Hoare-Logik V tN verwendet werden. 

Spezifikation eines Lebenszyklus: (S o , T o , F o , V o , N o ) .


Der Moment eines Lebenszyklus sind alle Eigenschaften des Objektes im Zustand s. 

Beispiel: Personen werden Studenten etc. 

Exmatrikulation 

✲ 

Absolvent 

✒ 

Person ✲ Immatrikulation ✲ Student 

✲ 

Betreuersuche 

✲ 

Student mit 

Betreuer 

Belegt 


✠ 

❄ 

Abschluß 

Vertrag 

❘ 

Auswahl 

Nebenfach 

❄ 

Auswahl des 

Themas 

❄ 

Student 

mit Resultat 

❄ 

HiWi 

❄ 

Student 

mit Nebenfach 

❄ 

Diplomand 

Abbildung 17: Lebenszyklus eines Studenten in der Datenbank 

Die Vor- und Nachbedingungen sind nicht in der Zeichnung dargestellt. So gilt z.B., daß für die 

Exmatrikulation sämtliche Beziehungen gelöst werden. 

Die Vertragsgestaltung erbt das Objekt Student vom Objekt Person. Personen sind über Verträge 

Mitarbeiter von Projekten. Bei dieser Vererbung wird auch die Bezeichnung Mitarbeiter überschrieben. 

Man kann die und-oder Graphen auch weiter verfeinern. (siehe Modellierungskapitel) 

Die Sichtbarkeitsregeln folgen der Sichtendefinition. 

Außerdem kann der Graph auch zyklisch sein. 

Kanten können mehrwertig sein (Z.B. für die Auswahl des Nebenfaches). 

Darstellung von gemeinsamen Verhalten mehrerer Objekte. 

Unterscheidung in aktive Objekte, aktivierte Objekte und passive Objekte 

Entwicklung von Kooperationsverträgen zwischen den Objekten 

Prozesse können sich auch gegenseitig 

bedingen, 

blockieren, 

abweisen, 

starten 

Kopplung. 

Verschiedene Arten von Kopplungsmechanismen: 

• Interaktionskopplung 

rufen dieselben Daten ab; rufen sich gegenseitig auf 

dabei verschiedene Kopplungsmechanismen

Ereignisgesteuerte Prozeßketten. 


• Kontrollflußkopplung 

• Wanderdatenkopplung 

• Parameterkopplung 

• keine Kopplung 

• Komponentenkopplung 

verschiedene Grade 

• versteckte Kopplung 

• verstreute Kopplung 

• spezifizierte Kopplung 


• Vererbungskopplung 

verschiedene Arten 

Kohäsion. 

• Änderungskopplung 

• Signaturänderungskopplung 

• Implementationsänderungskopplung 

• Verfeinerungskopplung 

• Signaturverfeinerungskopplung 

• Implementationsverfeinerungskopplung 

• Erweiterungskopplung 


(Bindung zwischen den einzelnen kooperierenden Objekten) 

verschiedene Arten 

• Operationskohäsion 

• zufällige Kohäsion 

• logische Kohäsion 

• temporale Kohäsion 

• prozedurale Kohäsion 

• Kommunikationskohäsion 

• sequentielle Kohäsion 

• funktionale kohäsion 

• Typkohäsion 

• zerlegbare Kohäsion 

• mehrschichtige Kohäsion 

• nicht delegierte Kohäsion 

• verborgene Kohäsion 

• Vererbungskohäsion


• Funktionen (als abgerundete Rechtecke dargestellt) 

• Ereignisse (als Sechsecke) [gemeint sind eigentlich Zustände] 

• Verknüpfungsoperationen (dargestllt mit Kreisen) 

Kanten von Funktion zu Ereignis bzw. Ereignis zu Funktion 

wobei Funktionen 

• von einem Zustand oder mehreren Zuständen ausgelöst werden und 

• ein Zustand einen oder mehrere Zustände erzeugt 

Ein Zustand kann 

• von einer Funktion oder mehreren Funktionen ausgel¨st werden und 

• eine Funktion oder mehrere Funktionen auslösen. 

Verknüpfungsoperationen als logische Verknüpfungen 

• UND (in der Bedeutung “sowohl als auch”), 

• XOR (in der Bedeutung “entweder oder”) 

• OR 

(nicht für die konzeptionelle Modellierung geeignet) 

geeignet für Darstellung während der Anforderungsanalyse 

Antrag zur 

Bearbeitung 

liegt vor 

✲ 

XOR 

✛ 

❄ 

AND 

❄ 

❄ 

Antrag 

prüfen 

Nebenbedingungen 

prüfen 

❄ 

❄ 

❄ 

XOR 

❄ 

❄ 

XOR 

❄ 

Unterlagen 

unvollständig 

Unterlagen 

vollständig 


erfüllt 


nicht erfüllt 

❄ 

Weitere 

Unterlagen 

beschaffen 

❄ 

Weitere 

Unterlagen 

liegen vor 

✲ 

AND 

❄ 

Vertrag 

genehmigen 

❄ 

✛ 

Antrag 

genehmigen 

❄ 

Vertrag nicht 

genehmigen 

❄ 

Antrag 

abgelehnt


Aufblähung der Spezifikation durch alternierende Darstellung von Funktionen und Zuständen 

Blockdiagramme zur Darstellung der Funktionen 

Fehlende Abstraktion und damit Forderung nach feingranalarer Darstellung 

Fehlende Hierarchien und damit nichtsichtbare Schichtung 

Funktionsbäume als Alternative 

Fehlende zeitliche Schichtung bei Abhängigkeiten der Ereignisse vom Zeitverlauf 

Balkendiagramme (Gantt charts) zur 2D-Darstellung von Ereignis und Zeit(intervall) 

Fehlende Integration mit Organisationsstruktur 

Rasterdiagramme (Ereignisfolgendiagramme) zur Darstellung der Vorgangsbearbeitung als Tabellendarstellung 

von Organisationsstrukturen und Aktionen mit Beziehungsgraphen der Zellen 

Überwindung dieser Nachteile durch Anreicherung 

Akteur 

(Stelle, Rolle) 

✲ 

Funktionerweiterung 

✛ 

✲ 

Output-Daten 

Input-Daten 

Hauptproblem: Bruch in den Paradigmen 

3.5.3 Zustandsbasierte Spezifikation des Verhaltens 

Anforderungen an Spezifikation des Verhaltens 

Visualisierung des Verhaltens 

Verfeinerung und Kompositionalität mit induktivem Aufbau 

Rigide Semantik zur eindeutigen Interpretation 

Interoperabilität mit anderen Spezifikationen insbesondere zum Austausch 

Akzeptanz und breite Verwendung 

statecharts (David Harel) 

in Verallgemeinerung des deterministischen endlichen Automaten 

Zustandübergang 

Transition 

• zwei Zustände 

• auslösendes Ereignis, 

• für Transition notwendige Bedingung, 

• durch die Transition ausgelöste, meist externe Bedingung 

Vor- und Nachteile 

+ einfache graphische Notation 

+ einfache intuitiv verständliche Semantik 

+ theoretisch sauber 

- alle Zustände atomar (Verfeinerung ?, Hierarchisierung ?) 

- keine Unterstützung der Zerlegung 

- Zustandsexplosion


✛ 

Transition 

✻ 

H 

❄ 

❘ 

Zustand 

Ereignisse [Bedingungen] 

/Aktionen zu Transition 

✲ 

Transition 

Abbildung 18: 

• enthält Zustandsdiagramm bzw. andere Superzustände 

• erlaubt die Vereinfachung mehrfacher Transitionen zu einem Zielzustand durch 

• Einführung eines zusammenfassenden Zustandes und Substitution aller Transitionen von 

Zuständen zum Zielzustand durch Transition vom Superzustand zum Zielzustand 

diese Zusammenfassung entspricht dem XOR 

Argumente/Parameter mit zustandsabhängiger Instantiierung 

Transition zur Zustandsüberführung 

• Repräsentation einer Zustandsänderung eines Objekts 

• i.a. getriggert (gefeuert) durch ein Ereignis 

Konvention: Ereignisse ohne Trigger (?-Transitionen) feuern sofort 

• feuern sofort 

• von exakt einem Zustand zu einem anderen (oder sich selbst (self-transition)) können nicht 

unterbrochen werden 

Wächter (guards) 

• logische Bedingung 

• guarded transition feuert, wenn dies die Bedingung erlaubt 

• i.a. kann nur eine Transition feuern; deshalb sind Wächter paarweise exklusiv 

• Ereignisse können auch Wächter besitzen 

Ereignisse (events) 

• gekoppelt an einen Zeitpunkt 

• Zeitlogik i.a. diskret, mit oder ohne Grenzen,


ein Signal von einem Objekt an ein anderes (delived) 

eine Nachricht, empfangen von einem Objekt (check item) 

zu einer bestimmten Zeit (nach 10 Sekunden (in einem Zustand), 7.12.2004, 18.45 (Chanukkah) 

• Ereignisse können Argumente benutzen (deliver to (receiver:Kunde) 

• Ereignisse setzen auf dem Schema auf (über Attributen insb.) 

Parallelität von Teil-Statechart 

durch gestrichelte Linie gekennzeichnet 

Gleichzeitigkeit in Zustandsdiagrammen 

ein Objekt kann Verhalten haben, das separierbar ist in unabhängige Komponenten 

anzeigen der Separation durch ‘Gabeln (Fork) (Doppelungssemantik) oder gleichzeitigem (konkurrierendem) 

Superzustand 

History-Funktion 

Operationale Semantik von Statecharts. 

Execution state of statechart (S, T, V ): 

subset states ⊆ S of currently active states s.t. 

• root of S is in states 

• if s in states and type of s is AND then all children of s are in states 

• if s in states and type of s is XOR then exactly one child of s is in states 

Execution context of statechart (S, T, V ): 

current values of variables defined by val : V → Dom 

Configuration of statechart (S, T, V ) : (states, val) 

Initial configuration 

Evaluation of expression in configuration: 

eval(expr, conf) defined inductively 

Effect of action on context: 

modification of variable values in val 

fire(conf) = set of transitions 

t = (source, target, [cond]/action) with source(t) in states for which eval(cond, conf) = 

true 

for transition t: 

when t fires: 

• a = lca(source(t), target(t)) 

• src(t) = child of a in subtree of source(t) 

• tgt(t) = child of a in subtree of target(t) 

• set of left states source ∗ (t): 

• src(t) is in source ∗ (t) 

• if s in source ∗ (t) then all children of s are in source ∗ (t) 

set of entered states target ∗ (t):

Architektursicht der Daten- und Prozeßorganisation 

alle Ereignisse werden durch Prozessoren unterlegt 


For a given configuration conf = (states, val) a successor configuration conf ′ = (states ′ , val ′ ) 

is derived by selecting one transition t from fire(conf) with the effect: states ′ = statessource∗ 

(t) ∪ target ∗ (t) val ′ captures the effect of action(t) and equals val otherwise 

Theorem 4 The operational semantics of a statechart (S, V, T ) is the set of all possible executions 

along configurations conf 0 , conf 1 , conf 2 , ... with initial configuration conf 0 and conf i+1 being a 

successor configuration of conf i . 

Verfeinerung von Statecharts. 

Das Zustandsdiagramm in Bild ?? 

completed 

login 

✛ 

login 

request 

disabled 

login 

✛ 

❄ 

enabled 

login 

offer 

✲ 

offered 

lecture 

completed 

offer 

✛ 

commit 

❄ 

validated 

offer 

Abbildung 19: Abstrakter Statechart zur Vorlesungsplanung 

wird durch das Zustandsdiagramm in Bild ?? verfeinert. 

Vor- und Nachteile. 

Wann sollte man Zustandsdiagramme nutzen? Von Nutzen bei Beschreibung des Verhaltens von 

Objekten über mehrere Anwendungfälle hinweg. sowie bei Klassen, deren Verhalten noch nicht 

wohlverstanden ist. 

Wann sollte man Zustandsdiagramme nicht nutzen? Beschreibung des Verhaltens von mehreren 

Objekten, die innerhalb eines Anwendungsfalles auftreten (dann Interaktionsdiagramme) 

Beschreibung der Verhaltens mehrerer Anwendungsfälle und mehrerer Objekte (dann Aktivitätendiagramme) 

Beschreibung des Verhaltens von kooperierenden Objekten 

3.5.4 Top-down-Beschreibung 

Szenarien, Architektur und Zustände. 

Nun Modellierung der Erwartungen für jedes Ereignis. 

Alle möglichen Szenarios können nicht entworfen werden. 

In Datenbanksystemen werden Szenarios durch Transaktionen (siehe spezielles Kapitel) dargestellt 

(evt. mit Teiltransaktionen, aber ohne Wiederholungen, expliziter Parallelität).


reset 

state 

✻ 

❄ 

disabled 

login 

✕ 

❘ 

completed 

login 

❄ 

unknown 

user 

send name 

❄ 

name 

known 

send password 

❄ 

known name, 

password 

✛ 

✲ 

renew 

login 

✻(count ≠ 0) 

(count 

counter =0) ✲ reject 

check 

login 

✻(false) 

login (true) ✲ 

validated 

✻{count:=3} 

login 

unclear 

✛ 

H 

✻ 

correct 

login 

enabled login 

✻ 

login 

accepted 

✲ 

✛ 

correct 

login 

✠ 

roles, rights 

unclear 

{ role, right 

generation ❄ } 

roles, rights 

assigned 

✛ 

Abbildung 20: Verfeinerung des Statechart für das Login 

Technologische Beschränkungen und Bedingungen der Kommunikationskanäle, der Input/Output- 

Geräte, der Prozessoren, der Speicher, der Geschwindigkeit, ... 

Spezifikation der Architekturanforderungen Prozessoren, Zuverlässigkeit, Prioritäten, Leistung, 

Kapazität, Zeitbeziehungen, Interface, Sicherheit, fail-safety, safety, ... 

dokumentiert in Szenario-Spezifikation, Szenariodiagramm 

Szenario - Menge von I/O-Datenströmen, Steuerströmen, Verhalten eines Ereignisses 

Endliche Automatten als Darstellungsmittel als spezifische Darstellungsform 

Zustand eines Informationssystemes 

Zustandsüberführungsdiagramme mit I/O-Kanten 

Zustandsüberführungstabellen in klassischer Form 

Statecharts als State-Transition-Diagramme mit concurrency, Hierarchisierung und Kommunikation 

D. Harel, Statecharts: A visual formalism for complex systems. North-Holland, New York, 

1987 

Aktionsdiagramme in Szenarios oder Struktogramme zur Spezifikation der Programmabläufe in 

Szenarios (mit Erweiterung für parallele Handlungen) 

Verhaltensmuster (Skripte). 

als Programme auf der Grundlage expliziter atomarer Operationen 

Verhaltenssicht eines Systemes zur Modellierung der Benutzererwartungen und der Prozesse

2. Für jede Klasse bestimmen: 

was tut oder wei diese Klasse ? 

welche anderen Klassen benötigen diese Fähigkeiten ? 

stimmt die Rolle (Anbieter / Kunde) der Klasse ? (z.B. phys. Geräte sind typischerweise Anbieter) 


Prozeßbeschränkungen technologische Beschränkungen, Beschränkungen der Technik, Beschränkungen 

der Kommunikation 

Verhaltensanforderungen Prozeßanforderungen, Prioritäten, Leistungsanforderungen, Zeit, 

fail-safety, safety, negotiale Anforderungen (was sollte keinesfalls passieren), ... 

Verhalten als Basisaktivitäten des Systems; komplexes Verhalten als Teilsysteme; 

Definition von Verhalten über Programme über Aktivitäten 

Benennung von Verhalten z.B. input, output, verify, activate, calculate, terminate, logische 

Ableitung 

Erweiterungen Luxus am Anfang 

Flexible Systeme 

Kontrolle der Erwartungen, Einbettungen 

Aktionsdiagramme definieren Verhaltensmuster 

Systemerweiterungen inkrementelle 

CRC Cards. 

CRC = Class - Responsibility - Collaboration 

innerhalb einer Geschäftsprozeschicht: keine Interface-Spez. 

Operationen: prinzipielle Verantwortlichkeiten einer Klasse 

• Verantwortlichkeit 

high-level Beschreibung des Zieles der Klasse keine Orientierung auf Daten, Prozesse 

Darstellung des Zieles, Motivation 

• Kollaboration ( (in Zusammenarbeit mit) Verantwortlichkeiten mit anderen Klassen 

Verbindungen mit anderen Klassen 

Trick: auf Karteikarten kann nur begrenzte Information. 

Günstig für Beschreibung der Schnittstellen der Klassen, insbesondere deren Verhalten, sowie 

bei Teamentwicklung. Anwendungsfall durch ein oder mehrere Karten 

• Kooperationen zwischen Objekten 

Objekt kann Verantwortlichkeit selbst erfüllen vs. benötigt Fähigkeiten anderer Objekte (–¿ 

Kooperation) 

Kooperationen modellieren die Interaktion zwischen Objekten (Daten- und Kontrollflu) 

Rolle der Objekte (Anbieter / Kunde) bezüglich der Kooperation wird bestimmt 

(abgeschlossene) Teilsysteme können identifiziert werden 

Kooperationen finden 

1. Für jede Verantwortlichkeit einer Klasse überlegen: 

kann die Klasse die Verantwortlichkeit selbst erfüllen ? 

falls nicht: welche Informationen /Fähigkeiten werden benötigt und welche andere Klasse stellt 

diese bereit ?


3. weitere Beziehungen zwischen den Klassen analysieren 

besteht-aus (Aggregation) 

Komposition 

Behälter-Klassen (z.B. Array, geordnete Menge) 

kennt (Assoziation) 

Benutzung 

“hole Information von” Kooperationen 

hängt-ab-von 

gibt Hinweise auf Kooperationsketten 

3.5.5 Abstrakte Zustandsmaschinen 

Das Datenbank-Schema definiert die Strukturierung der Datenbank. Ein Zustand der Datenbank kann 

durch eine Modifikation partiell geändert werden. Änderungsoperationen T (s 1 , ..., s n ) := t vom 

Teiltyp T ′ von T basieren auf Anfragen. Sie sind auf einem Objekt einer Klasse T C definiert, falls 

| σ T ′ =(s 1 ,...,s n)(T C ) | ≤ 1 gilt. 

Eine Menge U = {T i (s i,1 , ..., s i,ni ) := o i |1 ≤ i ≤ m} von objekt-basierten Änderungsoperationen 

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 

o i = o j folgt. 

Das Resultat der Ausführung einer konsistenten Menge U von Änderungsoperationen führt zu 

einer Zustandsänderung der Datenbank ER C zu ER C + U 

{ 

(ER C Update(Ti , s 

+ U)(o) = 

i,1 , ..., s i,ni , o i ) falls T i (s i,1 , ..., s i,ni ) := o i ∈ U 

ER C (o) 

andernfalls 

für Objekte o of ER C . 

Ein parametrisiertes Programm r(x 1 , ..., x n ) = P der Stelligkeit n besteht aus einem Programmnamen 

r, einer Transitionsregel P und einer Menge {x 1 , ..., x n } von freien Variablen von P . 

Eine Datenbank ER C ist ein Modell von φ (kurz bezeichnet als ER C |= φ ) falls [[φ]] ERC 

ζ 

= true 

für alle Variablenbelegungen ζ für die freien Variablen von φ. 

Eine Workflow-Maschine W = (ER, ER C 0 

, P, Σ) basiert auf einem Datenbank-Schema ER, 

einer initialen Datenbank ER C 0 

, einer Menge von parametrisierten Programmen und einem ausgezeichneten 

Programm, das Hauptprogramm genannt wird, sowie den dynamischen Integritätsbedingungen. 

Eine Transitionsregel P führt zu einer Menge U von Änderungsoperationen in einem Zustand 

ER C , falls dieser konsistent ist. Sie verändert den Zustand der Datenbank mit einer Variablenbelegung 

ζ zu yields(P, ER C , ζ, U). 

Die Semantik einer Transitionsregel wird durch einen Kalkül mit Regeln der Form 

Voraussetzung 1 , ..., Voraussetzung n 

Folgerung 

Bedingung 

definiert. 

Wir verzichten hier auf die vollständige Angabe der Semantik und verweisen auf die Literatur. Als 

Beispiel führen wir die folgenden Regeln an, ohne auf den Beweis dieser Regeln einzugehen: 

yields(P, ER C , ζ, U) , yields(Q, ER C , ζ, V) 

yields(DO P PAR Q, ER C , ζ, U ∪ V) 

U ∪ V 

konsistent 

Die Konsistenzbedingung kann weggelassen werden, wenn man die Theorie der partiell-geordneten 

Durchläufe für ASM anwendet. Wir wollen jedoch hier nicht im Detail auf die Theorie eingehen. 

yields(P, ER C , ζ[x ↦→ a], U) 

yields(LET x = t IN P DO P , ER C , ζ, U) 

wobei 

a = [[t]] ERC 

ζ 

∀ a ∈ I : yields(P, ER C , ζ[x ↦→ a], U a ) 

yields(FOR ALL x WITH φ DO P , ER C , ζ, ⋃ a∈I U wobei I = range(x, φ, ER C , ζ) 

a) 

Der Wertebereich range(x, φ, ER C , ζ)) ist definiert durch die Menge {o ∈ ER C | [[φ]] ERC =


yields(CHOOSE x WITH φ DO P , ER C , ζ, ∅) 

falls 

range(x, φ, ER C , ζ) = ∅ 

yields(P, ER C , ζ, U) , yields(Q, ER C + U, ζ, V) 

yields(DO P ; Q , ER C , ζ, U ⊕ V) 

falls U konsistent ist 

yields(P, ER C , ζ, U) 

yields(DO P ; Q , ER C , ζ, U) 

falls U inkonsistent ist 

yields(SKIP , ER C , ζ, ∅) 

yields(f(s 1 , ..., s n ) = t , ER C , ζ, (Update(l, v)) 

wobei 

l = f([[s 1 ]] ERC 

ζ , ..., [[s n ]] ERC 

ζ ) und v = [[t] ERC 

ζ 

yields(P, ER C , ζ, U) 

yields(IF φ THENP ELSE Q , ER C , ζ, U) 

falls 

[[φ]] ERC 

ζ 

= true 

yields(Q, ER C , ζ, V) 

yields(IF φ THENP ELSE Q , ER C , ζ, V) 

falls 

[[φ]] ERC 

ζ 

= false 

yields(P t 1,...,t n 

x 1 ,...,x n 

, ER C , ζ, U) 

yields(r(t 1 , ..., t N ) , ER C , ζ, U) 

mit 

r(t 1 , ..., t n ) = P 

Die angegebene Workflow-Maschine erlaubt eine allgemeine Spezifikation des Verhaltens des Datenbanksystems. 

Mit dieser Grundlage können wir eine pragmatischere Spezifikationssprache im weiteren 

verwenden. 

3.5.6 Dynamische Integritätsbedingungen 

Dynamische Integritätsbedingungen werden in der Literatur meist aufgrund ihrer Kompliziertheit 

weggelassen. Sie sind jedoch für die Datenbank-Entwicklung nicht minder wichtig. Deshalb führen 

wir auch einige Klassen explizit ein. 

Wir betrachten dazu temporale Klassen vom Typ R: 

Jedem potentiellen Objekt o von dom(R) kann eine Lebenszeit l R (o) ⊆ IN in der Datenbank zugeordnet 

werden. Damit können wir 

• temporale Klassen (R C , l R ) und 

• ihre Schnappschüsse S(i, R C , l R ) = {o ∈ dom(R)|i ∈ l R (o)} 

einführen. 

Gegeben seien eine Formel α über R, eine temporale Klasse (R C , l R ) über R, und Schnappschüsse 

S(0, R C , l R ), ...,S(i, R C , l R ), ... S(maxT, R C , l R ). 

Wir können nun eine Erfüllbarkeit von Formeln analog zur Modallogik definieren. 

Ein Zeitrahmen ZR besteht aus einem Paar (T S, W ) von Intervallen von IN und einer binären Relation 

W über T S. Wir bezeichnen mit maxT S den maximalen Zeitpunkt von T S und mit minT S den 

minimalen Zeitpunkt. Der einfachste Zeitrahmen ist das Intervall T S = [0, maxT S] betrachtet. Die 

binäre Relation W stellt eine Erreichbarkeit von Intervallen untereinander her. Wir sind damit in der 

Lage, Zeiträume zu betrachten und ggf. auch voneinander zu separieren. 

• Die Gültigkeit von α in einem Schnappschuß S(i, R C , l R ) ist induktiv wie für statische Integritätsbedingungen 

definiert und wird mit (R C , l R , i) |= α notiert. 

• Die Formel α is notwendig gültig in (R C , l R ), zu einem Zeitpunkt i ∈ I, I ∈ T S und für einen 

Zeitrahmen ZR falls (R C , l R , i ′ ) |= α für alle Intervalle I, I ′ mit (I, I ′ ) ∈ W und alle 

Zeitpunkte i ′ ∈ I ∪ I ′ . 

Wir notieren dies mit (R C , l R , i, ZR) |= ✷α bzw. (R C , l R , I, ZR) |= ✷α 

Die Formel ist gültig in jedem Zeitpunkt des Intervalls I, dem i angehört, und in jedem Zeitpunkt, 

der durch W aus I erreicht werden kann. In der Modallogik wird zwischen der Gültigkeit


• 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 

falls (R C , l R , i) |= α für alle Intervalle I ′ mit (I 1 , I ′ ) ∈ W bzw. (I ′ , I 2 ) ∈ W und 

i ∈ I 1 ∪ I 2 ∪ I ′ . 

Wir bezeichnen die zeitweilige volle Gültigkeit mit (R C , l R , [I 1 , I 2 ], ZR) |= ✷α . 

Wir können damit die Gültigkeit zwischen Phasen definieren. 

• Die Formel α ist gültig in (R C , l R ) und ZR falls (R C , l R , i) |= α für jeden Zeitpunkt i 

jedes Intervalls I des Zeitrahmens (bezeichnet mit (R C , l R , ZR) |= α ). 

In diesem Fall ist α eine statische Integritätsbedingung, falls ⋃ I∈T S 

I = [minT S, maxT S]. 

• 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) |= 

α (bezeichnet mit (R C , l R , ZR) |= ✸α ). 

Besitzt ein Zeitrahmen ZR Unterbrechungen, dann wird für die Formel α keine Forderung erhoben. 

Ein Zeitrahmen wird für die Implementationsschicht direkt durch Phasen repräsentiert. Damit 

kann die Gültigkeit von Formeln und die Zulässigkeit von Prozessen zu gewissen Zeitpunkten direkt 

modelliert werden. 

Wir können damit auch unterschiedliche Klassen von dynamischen Integritätsbedingungen einführen. 

Dafür werden der Zeitrahmen ZR Schritt = ( { {i} |i ∈ IN } , { ({i}, {(i + 1)}) |i ∈ IN }) und 

ZR Punkt = ( { {i} |i ∈ IN } , ∅) , sowie ZR Voll = ( IN , IN × IN) eingeführt. 

Transitionsbedingung: Eine Formel α heißt Transitionsbedingung, falls α notwendig gültig in allen 

Intervalle von ZR Schritt ist. 

Wir notieren Transitionsbedingungen auch durch α −→ next α . 

Allgemeine Vor- und Nachbedingung: Ein Paar von Formeln α und β heißt Vor- und Nachbedingungen 

falls aus (R C , l R , i, ZR Punkt ) |= ✷α die Gültigkeit von (R C , l R , i+1, ZR Punkt ) |= ✷β 

folgt. 

Wir notieren allgemeine Vor- und Nachbedingungen auch durch α −→ next β . 

Wird der Zeitrahmen durch die Anwendung eines Prozesses P oder Programmes P definiert, 

dann schreiben wir α −→ P β . 

Temporale Formeln sind mit (R C , l R , i, ZR Voll ) |= ✷β bzw. (R C , l R , i, ZR Voll ) |= ✸β im Sinne 

der Modallogik notwendig oder möglich gültig. 

In analoger Form können damit auch allgemeine Gültigkeiten temporaler Formeln eingeführt werden: 

∀ f : immer (in der Zukunft) 

∀ p : immer (in der Vergangenheit) 

∃ f : einmal (in der Zukunft) 

∃ p : einmal (in der Vergangenheit). 

U(α, β) : 

α ist gültig bis β gültig wird. 

Weiche (deontische) Integritätsbedingungen werden für ZR Schrit eingeführt: 

Obligation: Eine Obligation Oα ist durch die Gültigkeit von (R C , l R , 1, ZR Schritt ) |= ✷α definiert. 

Erlaubnis: Eine Erlaubnis P α ist durch die Gültigkeit von (R C , l R , 1, ZR Schritt ) |= ✸α definiert. 

Verbot: Ein Verbot F α ist durch die Gültigkeit von (R C , l R , 1, ZR Schritt ) |= ✷¬α definiert. 

Wir können daraus direkt einige Ableitungsregeln ableiten:


KD3 : P α ↔ ¬O¬α 

KD4 : F α ↔ ¬P α 

Die Erlaubnis ist dual zur Obligation. 

Verboten heißt “nicht erlaubt”. 

Weitere allgemeingültige Formeln der deontischen Logik sind z.B.: 

• Oα ↔ ¬P ¬α 

• O(α ∧ β) ↔ Oα ∧ Oβ 

• ¬(Oα ∧ O¬α) 

• P (α ∨ β) ↔ P α ∨ P β 

• (Oα ∨ Oβ) → O(α ∨ β) 

• Oα → O(α ∨ β) 

• P (α ∧ β) → P α ∧ P β 

• F α → F (α ∧ β) 

• (Oα ∧ P β) → P (α ∧ β) 

• (Oα ∧ O(α → β)) → Oβ 

• (P α ∧ O(α → β)) → P β 

• (F β ∧ O(α → β)) → F α 

• F β ∧ F r ∧ O(α → (β ∨ γ)) → F α 

• ¬(O(α ∨ β) ∧ F α ∧ F β) 

• (Oα ∧ O((α ∧ β) → γ)) → O(β → γ) 

• O(¬α → α) → Oα 

• Oβ → O(α → β) 

• F α → O(α → β) 

• O¬α → O(α → β) 

• ¬α → (α → Oβ) 

• ¬O(α ∧ ¬α) 

• (Oα ∧ O(α → β) ∧ (¬α → O¬β) ∧ ¬α) ↔ false 

• α → β / Oα → Oβ 

Wir werden uns jedoch im weiteren auf Transitionsbedingungen und Vor- und Nachbedingungen 

konzentrieren, sowie auf weiche Integritätsbedingungen der deontischen Logik. 

3.5.7 Verhaltensoptimierung


3.6 Schrittweise Modellierung an einem Beispiel 

Angaben 

zur Reise 

Reisedaten 

Reiseablaufdaten 

Kostenüberweisung 

Finanzdaten 

Kostenabrechnungsdaten 

Reisekostenanerkennung 

Abbildung 21: Die Grobstruktur der Anwendung 

Storyschritt 

Vertreter 

✻ 

❄ 

❄ 

Akteur 

✛ 

Rolle 

✲ 

Sicht 

Abbildung 22: Das Akteurmodell für die Geschäftsprozeßschicht


Verbuchung 

✻ 

(1,1) 

Überweisung 

Genehmigung 

Abrechnung 

abgerechnet durch 

(1,n) (1,1) 

Antragsteller ✛ beantragt ✲ 

❄ 

(1,n) 

Dienstreise 

Genehmigung 

Reiseverlauf 

Abbildung 23: Grobdarstellung der Struktur der Anwendung 

Abrechnungssicht 

Beantragungssicht 

Sicht für allgemeine Verbuchung 

Abbildung 24: Sichtenskizze für unsere Anwendung 

Beantragung ✲ Ausfüllen ✲ Befürwortung ✲ Genehmigung 

❄ 

Abrechnung 

❄ 

Verbuchung ✲ Genehmigung 

der Abrechnung 

✲ 

Kontrolle der 

Abrechnung, 

Berechnung 

der Kostensätze 

✲ 

Genehmigung der 

Verbuchung 

❄ 

Verrechnung ✲ Zuordnung zum 

Abrechnungsmodus 

✯ 

✲ 

❥ 

Überweisung 

Kassenbereitstellung 

Rückforderung


Antragsteller Vorges. des Antragst. Dekan 


❄ Antragsteller 

Abrechnung 

❄ 

Dekan 



✲ 

Sachbearb. X 

Kontrolle der 

Abrechnung, 

Berechnung 


✲ 

Sachbearb. Y 


Verbuchung 

❄ 

Sachbearb. X 

Verrechnung ✲ Zuordnung zum 

Abrechnungsmodus 

✯ 

✲ 

❥ 

Sachbearb. X 

Überweisung 

Kassenbereitstellung Kassiererin 

RückforderungSachbearb. X 

Abbildung 26: Themen und Akteuren für Behandlung des Dienstreiseantrages (Normalverfahren) 

Akteur 

✛ 

Rolle 

✲ Dialogschritte ✛ 

zugeordnete 

✲Sichtenelemente 

✻ 

✻ 

❄ Vertreter ❄ 

❄ 

Rechte 

berechnet 

durch 

Abbildung 

❄ 

Handlungsschritte ✛ 

In 

❄ 

✲ Skelettelement 

Abbildung 27: Das Akteurmodell für die Aktionsschicht 

Beantragungssicht Genehmigungssicht 1 Genehmigungssicht 2 


❄Abrechnungssicht 

Abrechnung 

❄ 

Genehmigungssicht 3 



✲ 

Verbuchungssicht 1 

Kontrolle der 

Abrechnung, 

Berechnung 


✲ 

Genehmigungssicht 4 


Verbuchung 

❄ 

Verrechnungssicht 1 Verrechnungssicht 2 

✯ Überweisung 

Verrechnung ✲ Zuordnung zum ✲ 

Verrechnungssicht 3 

Kassenbereitstellung 

Abrechnungsmodus


Antragsteller 

≈ (1, 10) 

200 (1, n) 

500 ✛ 

2000 

≈ (1, 2) 

(1, 30) 

Reise 

beantragt 

❄ 

1000 

5000 

30000 

≈ (1, 1) 

(0, 1) 

✛ 

wird 

abgerechnet 

(Vorschlag) 

(1, 50) 

❄ 

Verbuchung 100 

200 

300 

Abbildung 29: Erster Entwurf für die Beantragungssicht 

System Historie Optionen Fenster 

Antragstellerdaten Reisedaten Verbuchungsdaten 

Name 

Vorname 

Institut 

Lehrstuhl 

Wohnort 

Dienstort 

Datum 

Unterschrift 

Vergüt.-stufe 

Reisek.-stufe 

f 1(name,vorname) 

f 2 (name,vorname) 

Abbildung 30: Dialogobjekt zur Darstellung von Antragstellerdaten für Lehrstuhlanträge 

System Historie Optionen Fenster 

Antragstellerdaten Reisedaten Verbuchungsdaten 

Name 

Vorname 

Institut 

Lehrstuhl 

Ziel 

Dauer - von 

Dauer - bis 

Zweck 

Weitere 

Teilnehmer 

Zus.hang zu 

Privatreise 

Beförd.-mittel 

Poliz. Kennz. 

bei Privat PkW


Auto 

0 

30 

3000 

≈ (1,1) 

(1,2) 

≈ (1,1) 

(0,4) 

≈ (1,200) 

(1,n) 

✻ 

Benutzt 

≈ (1,1) 

(0,4) 

Wohnort 

✻ Privatzweck 

Dienstort 

AHatV 

PolKZ 

Art 

1 

3 

4 

≈ (1,1) 

(1,4) 

≈ (1,10) 

(1,n) 

Ort 

zugeordnet 

zu 

Von Bis Zweck 

beantragt 

Land 

Reisekostenstufe 

≈ (1,2) 

(1,30) 

✛≈ (0,1) 

(0,2) 

AntrDatum 

0 

1000 

∞ 

✛ 

≈ (1,1) 

(1,3) 

✲ 

≈ (20,80) 

(0,n) 

Name 

≈ (10,40) 

(0,n) 

✻ 

Kostenstelle 

Beförderungsmittel 

Verbuchung 

100 

200 

300 

Titel 

 

Mögliche 

Reise 

20 

90 ✛ 

150 

≈ (1,1) 

(1,2) 

Vorschuß(Höhe,Auszahlart) 

≈ (0,n) 

(0,n) 

✲ 

In 

❄ 

Vergütungsgruppe 

Name Vorname 

❄ ✢ 

Antragsteller 

200 

500 ✛ 

2000 

Reiseziele 

Art 

1 

3 

8 

≈ (2,5) 

(0,n) 

✲ 

Fakultät 

Nr 

1 

5 

5 

Abbildung 32: Beantragung einer Dienstreise mit Verbuchung über den Lehrstuhl 

Auto 

0 

30 

3000 

≈ (1,1) 

(1,2) 

≈ (1,1) 

(0,4) 

≈ (1,200) 

(1,n) 

✻ 

Benutzt 

≈ (1,1) 

(0,4) 

Wohnort 


Dienstort 

AHatV 

PolKZ 

Art 

1 

3 

4 

≈ (1,1) 

(1,4) 

≈ (1,10) 

(1,n) 

Ort 

zugeordnet 

zu 

Von Bis Zweck 

beantragt 

Lehrstuhl 

❄ 


Name Vorname 

❄ ✢ 

Antragsteller 

200 

500 ✛ 

2000 

Reiseziele 

Land 


≈ (1,2) 

(1,30) 

✛≈ (0,1) 

(0,2) 

AntrDatum 

0 

1000 

∞ 

✛ 

≈ (1,1) 

(1,3) 

✲ 

≈ (20,80) 

(0,n) 

Name 

Lehrstuhl 

≈ (10,40) 

(0,n) 

✻ 

Kostenstelle 


Verbuchung 

100 

200 

300 

Titel 

20 

90 ✛ 

150 

≈ (1,1) 

(1,2) 

Vorschuß(Höhe,Auszahlart) 

≈ (0,n) 

(0,n) 

✲ 

In 

 

Mögliche 


Art 

1 

3 

8 

≈ (2,5) 

(0,n) 

✲ 

Fakultät 

Nr 

1 

5 

5


Auto 

0 

30 

3000 

≈ (1,1) 

(1,2) 

≈ (1,1) 

(0,4) 

≈ (1,200) 

(1,n) 

✻ 

Benutzt 

≈ (1,1) 

(0,4) 

Wohnort 


Dienstort 

AHatV 

PolKZ 

Art 

1 

3 

4 

≈ (1,1) 

(1,4) 

≈ (1,10) 

(1,n) 

Ort 

zugeordnet 

zu 

Von Bis Zweck 

beantragt 

❄ 


Name Vorname 

❄ ✢ 

Antragsteller 

200 

500 ✛ 

2000 

Reiseziele 

Land 


≈ (1,2) 

(1,30) 

✛ 

AntrDatum 

0 

1000 

∞ 

✛ 

≈ (1,1) 

(1,3) 

✲ 

≈ (20,80) 

(0,n) 

Name 

Verbuchung 

Lehrstuhl 

20 

90 ✛ 

150 

≈ (1,1) 

(1,2) 

Kostenstelle 

≈ (0,1) 

(0,2) 

≈ (0,n) 

(0,n) 

✲ 

In 

Vorschuß 

(Höhe,Auszahlart) 

Art 

1 

3 

8 

≈ (2,5) 

(0,n) 

✲ 

Fakultät 

≈ (10,40) 

(0,n) 

✻ 

Nr 

 

Mögliche 



100 

200 

300 

Titel 

1 

5 

5 

Abbildung 34: Beantragung einer Dienstreise mit Verbuchung über die Fakultät 

DekanBestät 

✲ LehrstGenehm 

DekGenehm 

Person ✛ Antragsteller✛ 

beantragt ✛ 

2 

❄ 

LVerbuch 

❄ 

LBefürw 

✻ 

✻ 

✻ 

❄ 

❄ 

❄ 

ArbeitetAn 

Reise 

LehrstFonds 

✯ 

FVerbuch 

leitet 

✲ 

❄ 

Lehrstuhl 

✛ 

LHatFond 

✻ 

DekanVonF 

FakVonL 

✲ 

✲ 

Fakultät 

✛ 

FakHatFond 

✲ 

❄ 

FakFonds



Genehmigungssicht1 


Abrechnungssicht 


Verbuchungssicht1 


... 

Verrechnungssicht1 

Verrechnungssicht4 

❘ ❄ ✠ 

Zentrale 


❘ ❄ ✠ 

Zentrale 

Verbuchungssicht 

3 ❯ 

❄ 

Integriertes Datenbankschema zum Dienstreiseantrag 

❘ ❄ ✠ 

Zentrale 

Verrechnungssicht 

✙ 

Abbildung 36: Sichtenintegration in unserer Anwendung 

Benutzersichten 

zur Vereinfachung 

des Zugriffs 




... 

Sicherheitssichten 

zur Kontrolle 

des Zugriffs 

❄ ❄ ❄ 

Zugriffsbeschr. 






... 

Zentrale 

Sichten 

zur Darstellung 

der Unabhängigkeit 

❘ ❄ ✠ 

Zentrale 


... 

Integriertes 

Schema 

zur Darstellung 

der Speicherung 

3 

Integriertes Datenbankschema zum Dienstreiseantrag 

Abbildung 37: Ausschnitt aus der Sichtenarchitektur mit Sicherheitssichten


V 1 

V 2 

Reisen{(Ort, Land, Zweck, Von, Bis) } 

Reisezeitraum (Von, Bis) 

Reisende{ (Name, Vorname) } 

Dienstreisender 

Dienstreisen 

Name Vorname 

Ort Land Zweck 

✛ 

V 3 

Von 

führt 

durch 

Bis 

✲ 

Dienstreisender 

Dienstreise 

Name Vorname Ort Land Zweck 

Abbildung 38: Zwei verschiedene Sichten auf eine Dienstreise und eine integrierte Sicht


Auto 


✻ 

✻ 

Benutzt 

AHatV 

DekanBestät 

✲ LehrstGenehm 

DekGenehm 

❄ 

❥ 

Person ✛ Antragsteller 

✛ 

beantragt 

✛ 

2 

❄ 

LVerbuch 

❄ 

LBefürw 

✻ 

✻ 

✻ 

leitet 

✲ 

ArbeitetAn 

❄ 

Lehrstuhl 

✻ 

✛ 

❄ 

Mögliche 

Reise 

LHatFond 

✯ 

❘ 

❫ 

❄ 

LehrstFonds 

Reiseziele 


❄ 

FVerbuch 

DekanVonF 

FakVonL 

✲ 

✲ 

Fakultät 

✛ 

FakHatFond 

✲ 

❄ 

FakFonds 

Abbildung 39: Integration der Beantragungs- und Genehmigungssichten bei Verbuchung über den 

Lehrstuhl bzw. die Fakultät 

Hauptmenü 

✲ Beantragungsmenü 

3 ... 

❥ ... 

✯ 

✿ 

✲ 

3 

❥ 

Antragsteller 

Reisedaten 

Verbuchungsvorschlag 

Befürwortung 

Genehmigung 

Abbildung 40: Die Organisation der Menüs für die Beantragung


HERM und OLAP bzw. data warehouses 

Person 

OtherData 

Person 

Postal 

Person 

POBox 

 

✶ 

❄ 

Person 

Basic 

Data 

✻ 

✮ 

✐ 

Person 

EmailURL 

Person 

SMTP 

Person 

PhoneFax 

Abbildung 41: HERM Representation of the Star Type Person 

CUBE A: PARTICIPANTS PER LECTURE AND DAY 

CUBE B: USAGE OF ROOMS PER DAY 

Lectures 

✛ 

HeldOn 

✲ 

Day 

Room 

✛ 

Usage 

✲ 

Day 

#Participants 

#TotalUsage 

Room# 

SCHEDULING SCHEMA ON UNIVERSITY AND EVENING LECTURES 

University 

Lecture 

✛ 

Room 

✻ 

Room# 

University 

Lectures 

✛ 

HeldOn 

#Participants 

✲ 

Working 

Day 

✻ 

✲ 

IsA Room ✛ ❄ 

IsA 

General 

Purpose 

Room 

✻ 

Room# 

Title 

IsA ✲ Day ✛ 

Organized 

On 

✲ 

Evening 

Lectures 

#Participants 

Abbildung 42: Scheduling Views on Lectures Given in a University


Code 

Description 

Dimension 

Type 

✻ 

Dimension 

OfType 

[Reason] 

FromDate 

ThruDate 

[Quantity] 

Brand 

Name 

Product 

Type 

Product 

Quality 

UOM 

UnitOf 

Measure 

2 

Product 

Obsolesence 

Product 

Substitute 

Consists 

Of 

Identification 

Type 

Item 

Variant 

✮ 

Party 

Address 

✛ 

✲ 

■ 

❦ 

2 

✛ 

may be 

converted in 

Conversion 

Factor 

AReplacementNeededFor 

SuperceededBy 

[Comment] 

[Instruction] 

[Comment] 

[QuantityUsed] 

ThruDate 

FromDate 

❥ ❥ ❘ 

✲ 

✲ 

By UsedAs 

Additional Identifier 

(ManifacturerID | 

StockKeepingUnit | 

UniversalProductCode 

(American UPCA | European UPCE) | 

IntStandBookNumb ISBN)) 

Id TypeCode Description 

PhysicalInventoryDate 

Quantity 

Reason 

[Comment] 

Dimension 

❑ 

Converted 

❘ 

✻ 

✻ 

Inventory 

Item ⊕ 

❄ 

Container 

⊕ 

Product ✙ 

Characteristic 

❄ 

Product 

✲ 

Color 

✻ 

✻ 

Code 

Description 

❘ Product 

Characterized 

WorkIn 

Progress 

Container 

Type 

Other 

Characteristic 

✕ 

Base 

Product 

Price 

Discount 

Component 

PriceSequenceNum 

Specified 

For 

Surcharge 

Component 

MadeUpOf 

ProdCode Name [Comment] 

[IntroductionDate] 

[SalesDiscontinuationDate] 

[SupportDiscontinuationDate] [ManufSuggestRetailPrice] 

UsedIn 

WarehousedAt 

Id 

Organization 

Raw 

Material 

Additional 

✾ 

❂ 

Item 

✛ Item ✛ 

Finished 

Good 

Identification 

Item 

Shrinkage ✲ 

Overages 

[ReorderQuantity] 

[ReorderLevel] 

PhysicalOccurenceOf 

StorageFor 

SerialNumber 

QuantityOnHand 

Id 

✻ 

ID 

[ThruQuantity] 

Service 

FromQuantity 

❄ 

Quantity 

Price 

Component 

Break Type 

✻ ✕ ❃ 

Discount 

Level 

❯ 

❫ Product 

Component 

Price 

✗ 

Code 

✠ 

✛ 

✻ 

Priced 

By 

Prod 

Category 

Class 

❄ 

Product 

Category 

Used To 

Define 

[ThruDate] 

[Price] 

FromDate 

[Percent] 

[Comment] 

[Comment] 

AvailableTruDate 

❘ 

✌ 

Product 

Supplier 

FromDate 

FromDate 

Description 

✛ 

Costed 

By 

Producer 

Of 

[ThruDate] 

[Comment] 

PrimaryFlag 

[ThruDate] 

Code 

CompTypeCode 

Description 

Purchaser 

Of 

Location 

UsedToDefine 

Estimated 

Product 

Cost 

Market 

Interest 

❄ 

Party 

Type 

✿ 

Product 

Supplier 

✲ RatingType 

❘ 

✒ 

OptionalComponent 

DependentOn 

Supplier 

Cost 

RatingTypeCode 

❫ 

✲ 

Name 

FromDate 

Comment 

Description 

PartyTypeCode 

Party 

Type 

Description 

GeoAreaCode 

Geographic 

Boundary 

Name 

FromDate 

[ThruDate] 

PrefTypeCode 

Product 

Supplier 

Preference 

Description 

Description 

[TaxIdNum] 

UsedTo 

Define 

[ThruDate] 

From 

Id 

Code 

Description 

Abbildung 43: Pattern for Products


Das Vorlesungsbeispiel: 

• volle ID-Entfaltung 

• rigides Nullwerte-Management 

• Separation von Schemadefintion und Integritätsbedingungen 

• minimale Indexunterstützung (nur Schl¨ssel (Primär- und Fremd-)) 

• minimale Menge von Wertebereichen 

• vollständige Verflachung 

• Auflösung aller Cluster-Typen 

• Event-Nonseparation mit Surrogat-Auflösung 

• Einbettung von (0,1)-*-Beziehungen 

• Namensgenerierung mit Präfixerweiterung und vorgegebener Präfixmenge, Trennung durch 

als Delimiter 

-- Database Section 

-- ________________ 

create database DB1_Vorlesungsbeipiel; 

-- DBSpace Section 

-- _______________ 

-- Table Section 

-- _____________ 

create table Studiengang ( 

ID_Stu char(10) not null, 

SName char(1) not null, 

Betreuer char(1) not null, 

Pruefungsamt char(6) not null, 

ID_Ins char(10) not null, 

primary key (ID_Stu)); 

create table Kurs ( 

ID_Kur char(10) not null, 

KursNr char(7) not null, 

Bezeichnung char(20) not null, 

primary key (ID_Kur)); 

create table Raum ( 

ID_Rau char(10) not null, 

Gebaeude char(4) not null, 

Raumnr numeric(5) not null, 

primary key (ID_Rau));

create table eingeschrieben in ( 

E_S_ID_Stu char(10) not null, 


von date not null, 

bis date not null, 


Telefon numeric(4) not null, 

IName char(1) not null, 

Sprecher char(15) not null, 

Fakultaet char(1) not null, 

primary key (ID_Ins)); 

create table Semester ( 

ID_Sem char(10) not null, 

Jahreszeit char(2) not null, 

Jahr numeric(4) not null, 

primary key (ID_Sem)); 

create table Projekt ( 

ID_Pro char(10) not null, 

Projektnr char(8) not null, 

Beschreibung varchar(90) not null, 

Bezeichnung char(20) not null, 

primary key (ID_Pro)); 

create table Student ( 


ID_Per char(10) not null, 

MatrNr char(7) not null, 

primary key (ID_Stu), 

unique (ID_Per)); 

create table Professor ( 



Spezialisierung char(1) not null, 

primary key (ID_Pro), 

unique (ID_Per)); 

create table Person ( 


Geburtsort char(15) not null, 

Adresse char(40) not null, 

Personenname char(25) not null, 

Geburtsdatum date not null, 

primary key (ID_Per)); 

create table Betreuer ( 




bis date, 

Thema varchar(30) not null, 

primary key (ID_Pro, ID_Stu));

alter table Student add constraint FKPer_Stu 

foreign key (ID_Per) 

references Person; 



ID_Vor char(10) not null, 

Resultat char(10) not null, 

Note char(2), 

primary key (ID_Vor, ID_Stu)); 

create table Projektmitarbeiter ( 



P_P_ID_Pro char(10) not null, 

primary key (ID_Pro), 

unique (ID_Stu), 

unique (P_P_ID_Pro)); 

create table Vorlesung ( 

ID_Vor char(10) not null, 

Wochentag char(2) not null, 

Block char(2) not null, 

Nummer char(9) not null, 


ID_Sem char(10) not null, 

ID_Rau char(10) not null, 

ID_Kur char(10) not null, 

primary key (ID_Vor)); 

create table In ( 


Seit char(1) not null, 

ID_Ins char(10) not null, 

primary key (ID_Pro)); 

create table wirkt mit ( 

W_P_ID_Pro char(10) not null, 


bis date not null, 

Kontraktnr char(6) not null, 


primary key (ID_Pro, W_P_ID_Pro)); 

-- Constraints Section 

-- ___________________ 

alter table Studiengang add constraint FKverantwortlich fuer 

foreign key (ID_Ins) 

references Institut; 

--alter table Student add constraint 

-- check(exists(select * from eingeschrieben in 

-- where eingeschrieben in.E_S_ID_Stu = ID_Stu));


-- where In.ID_Pro = ID_Pro)); 

alter table Professor add constraint FKPer_Pro 

foreign key (ID_Per) 

references Person; 

alter table Betreuer add constraint FKBet_Stu 

foreign key (ID_Stu) 

references Student; 

alter table Betreuer add constraint FKBet_Pro 

foreign key (ID_Pro) 

references Professor; 

alter table eingeschrieben in add constraint FKein_Stu_1 


references Studiengang; 

alter table eingeschrieben in add constraint FKein_Stu 

foreign key (E_S_ID_Stu) 


alter table hoert add constraint FKhoer_Vor 

foreign key (ID_Vor) 

references Vorlesung; 

alter table hoert add constraint FKhoer_Stu 



alter table Projektmitarbeiter add constraint FKStu_Pro 



alter table Projektmitarbeiter add constraint FKPro_Pro 

foreign key (P_P_ID_Pro) 


alter table Vorlesung add constraint FKliest 



alter table Vorlesung add constraint FKim 

foreign key (ID_Sem) 

references Semester; 

alter table Vorlesung add constraint FKveranstaltet 

foreign key (ID_Rau) 

references Raum; 

alter table Vorlesung add constraint FKzu 

foreign key (ID_Kur) 

references Kurs;

create unique index IDBetreuer 


alter table In add constraint FKIn_Ins 

foreign key (ID_Ins) 

references Institut; 

alter table wirkt mit add constraint FKwir_Pro_1 


references Projektmitarbeiter; 

alter table wirkt mit add constraint FKwir_Pro 

foreign key (W_P_ID_Pro) 

references Projekt; 

-- Index Section 

-- _____________ 

create unique index ID 

on Studiengang (ID_Stu); 

create index FKverantwortlich fuer 

on Studiengang (ID_Ins); 


on Kurs (ID_Kur); 


on Raum (ID_Rau); 


on Institut (ID_Ins); 


on Semester (ID_Sem); 


on Projekt (ID_Pro); 


on Student (ID_Stu); 

create unique index FKPer_Stu 

on Student (ID_Per); 


on Professor (ID_Pro); 

create unique index FKPer_Pro 

on Professor (ID_Per); 


on Person (ID_Per);

create unique index IDwirkt mit 


on Betreuer (ID_Stu); 

create index FKBet_Pro 

on Betreuer (ID_Pro); 

create unique index IDeingeschrieben in 

on eingeschrieben in (ID_Stu, E_S_ID_Stu); 

create index FKein_Stu_1 

on eingeschrieben in (ID_Stu); 

create index FKein_Stu 

on eingeschrieben in (E_S_ID_Stu); 

create unique index IDhoert 

on hoert (ID_Vor, ID_Stu); 

create index FKhoer_Vor 

on hoert (ID_Vor); 

create index FKhoer_Stu 

on hoert (ID_Stu); 


on Projektmitarbeiter (ID_Pro); 

create unique index FKStu_Pro 

on Projektmitarbeiter (ID_Stu); 

create unique index FKPro_Pro 

on Projektmitarbeiter (P_P_ID_Pro); 


on Vorlesung (ID_Vor); 

create index FKliest 

on Vorlesung (ID_Pro); 

create index FKim 

on Vorlesung (ID_Sem); 

create index FKveranstaltet 

on Vorlesung (ID_Rau); 

create index FKzu 

on Vorlesung (ID_Kur); 

create unique index FKIn_Pro 

on In (ID_Pro); 

create index FKIn_Ins 

on In (ID_Ins);


on wirkt mit (ID_Pro); 

create index FKwir_Pro 

on wirkt mit (W_P_ID_Pro);


Literaturhinweis 

Bernhard Thalheim: Entity-Relationship Modeling, Foundations of Database Technology. Springer, 

2000. ISBN 3-540-65470-4 

An die Teilnehmer der Veranstaltung wird der Verkauf des Buches zu einem ermäßigten Preis (80% bzw. weniger) 

durch das Sekretariat TIS organisiert. Bitte sprechen Sie persönlich bei Frau Kruse vor. 

Die folgenden Bücher sind als Ergänzung des Stoffes dieses Kapitels geeignet: 

Joachim Biskup: Grundlagen von Informationssystemen, Vieweg, 1995 1 

Das Skriptum zu Vorlesungen zu diesem Buch ist abgelegt unter: 

http://www.is.informatik.uni-kiel.de/∼thalheim/vorlesungen/biskup/Biskup.pdf 

Alfons Kemper, André Eickler: Datenbanksysteme - Eine Einführung, 5. Auflage. Oldenbourg 2003 

Die Skripte zur Vorlesung sind abgelegt unter: 

http://www.is.informatik.uni-kiel.de/∼thalheim/vorlesungen/kemper/kapitel1.pdf — kapitel 13.pdf 

Weitere Literaturquellen zu diesem Kapitel der Vorlesung sind: 

• Ramesh Elmasri, Sham B. Navathe: Fundamentals of Database Systems (4nd Edition), Benjamin/Cummings, 

Redwood City etc., 2004 (auch in Deutsch) 

• Jeffrey D. Ullman, Jennifer Widom: A First Course in Database Systems. Prentice-Hall 1997 

• Carlo Batini, Stefano Ceri, Shamkant Navathe: Conceptual Database Design - An Entity-Relationship 

Approach, Addison-Wesley, 1991 

• Toby J. Teorey: Database Modeling & Design, Morgan Kaufmann, 1998 

• Robert J. Muller: Database Design for Smarties - Using UML for Data Modeling, Morgan 

Kaufmann, 1999 

• David Harel, Michal Politi: Modeling Reactive Systems - the Statemate Approach, McGraw 

Hill, 1998 

• Frank Leymann, Dieter Roller: Production Workflow - Concepts and Techniques, Prentice Hall, 

1999

Vorlesung Datenbanken I 3. Datenbank-Modellierung - Technologie ...

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?