Ganz zu Anfang haben wir einen groben Überblick uns verschafft über das, was wir in dieser Vorlesung machen wollen.

Konzeptionelle Modellierung.

Jetzt kommen wir langsam dahin, wo wir hin wollen.

Ziel unseres Entwurfsprozesses ist, einen Ausschnitt der realen Welt, den wir Miniewelt nennen, in einer Datenbank zu repräsentieren.

Den Zustand dieser Miniewelt wollen wir in einer Datenbank repräsentieren.

Bevor wir das direkt implementieren, haben wir eine Zwischensprache verwendet, um das, was wir abbilden wollen, was für uns relevant ist, was wir vom Datenbanksystem sichergestellt haben wollen, formal darzustellen.

Unabhängig von der Implementierung.

Im nächsten Schritt dann bilden wir das ab auf ein Relationales Datenbankschema.

Bevor wir das machen können, müssen wir uns zunächst einmal mit dem Relationalen Datenmodell überhaupt beschäftigen.

Was bedeutet das überhaupt? Was haben wir da denn für Modellierungskonstrukte?

Das ist das, was wir heute machen wollen.

Vorher fassen wir noch einmal kurz zusammen, was wir jetzt hier beim ER-Modell eigentlich gelernt haben.

Wir haben unabhängig von der Implementierung versucht, die Gegenstände, die wir abbilden wollen in unserer Datenbank, formal zu beschreiben.

Wie haben wir das getan?

Ich mache das jetzt hier mal unabhängig von einer bestimmten Anwendung.

Wir haben Entity-Typen spezifiziert.

Die Entity-Typen mit Kästchen beschrieben haben und ein bisschen genauer spezifiziert.

Dann haben wir die noch über Attribute.

Nehmen wir mal an, wir haben ein Entity-Typ A.

Dann haben wir verschiedene Entity-Typen zueinander in Beziehung gesetzt, über solche Rauten.

Entities vom Typ A stehen in Beziehung zu Entities vom Typ B.

Dieser Beziehung, der konnten wir auch noch einen Namen geben.

Und jede Instanz zu einer Beziehung setzt genau ein A-Entity zu genau einem B-Entity in Beziehung.

Im Prinzip könnte man sich die Instanzen, die einzelnen Ausprägungen dieses Beziehungstyps vorstellen als Tupel.

Mit jeweils einem A-Entity und jeweils einem B-Entity.

So sehen diese Beziehungen aus.

Was haben wir dann gemacht?

Dann haben wir noch definiert, welche Beziehungen zulässig sind und welche nicht.

Oder wir haben, anders ausgedrückt, Einschränkungen definiert in der Menge der möglichen Beziehungen.

Constraints, sagt man dazu auch im Englischen.

Zum Beispiel haben wir mit der sogenannten Chen-Notation definieren können, zu einem B-Entity gibt es höchstens ein A-Entity.

Das ist die Chen-Notation.

Damit haben wir eine funktionale Abhängigkeit definiert.

So was haben wir damit definiert.

Wenn wir an den Kanten hier in N stehen haben, dann definieren wir keine Einschränkungen.

Sobald da eine 1 an einer Kante steht, definieren wir damit eine Einschränkung, eine funktionale Abhängigkeit.

Das Gleiche gilt auch für mehrstellige Beziehungstypen.

Nehmen wir an, wir haben so etwas, einen mehrstelligen Beziehungstyp, in dem Fall einen ternären Beziehungstyp, an dem drei Entitytypen beteiligt sind.

Das bedeutet, jede Ausprägung dieses Beziehungstyps setzt genau drei Entities zueinander in Beziehung, nämlich ein A, ein B und ein C.

Also man kann im Prinzip eine Beziehung eines ternären Typs als Trippel auffassen.

Genauso wie bei den B-Nären kann man jetzt dadurch Angaben von Kardinalitäten, Einschränkungen definieren, Constraints.

Wenn wir jetzt also hier 1 an die Kanten schreiben, was haben wir jetzt damit definiert?

Auch funktionale Abhängigkeiten haben wir damit definiert.

Welche haben wir hier definiert? Mit dieser ersten Eins haben wir definiert, A hängt funktional ab von der Kombination aus B und C.

Also pro B und pro C-Tuppel gibt es nur höchstens einen A-Tuppel.

Außerdem haben wir da noch eine Eins stehen, das bedeutet pro B und A gibt es höchstens einen C.

Funktionale Abhängigkeiten definieren wir.

Da haben wir noch eine andere Notation kennengelernt, die sogenannte Min-Max-Notation.

Die ist völlig anders definiert, die ist eben nicht über funktionale Abhängigkeiten definiert, sondern

da haben wir dann spezifiziert,