Herzlich willkommen zur Vorlesung konzeptionelle Modellierung.

Wir haben letzte Woche das Relationale Datenmodell vorgestellt, also das wichtigste Datenmodell, das am weitesten verbreitet ist.

Und das wollen wir heute ganz kurz wiederholen, überblicksartig. Zentral ist für das relationale Datenmodell, alle Daten werden in Form von Tabellen abgelegt, oder innerhalb von Tabellen abgelegt.

Uns interessiert, wie wollen wir letztlich die Entities, die wir in unserem ER-Modell jetzt schon informal beschrieben haben, letztlich in einer Datenbank abbilden.

Letzte Woche haben wir schon gesagt, wenn wir das in Tabellenform machen, dann können wir sagen, in erster Näherung wird also so ein Entity repräsentiert durch eine Zeile in so einer Tabelle.

So eine Tabelle hat also Zeilen und Spalten. Die Spalten, die nennen wir Attribute, die Zeilen, die nennen wir Tupel.

Und dann hat so eine Relation noch einen Namen und die Attribute, die haben auch alle einen Namen.

Hier das Attribut hat dann noch einen Wertebereich.

Da haben wir die Attribute und diese Kopfzeile hier oben, das nennen wir das Relationen Schema.

Das ist sozusagen die Beschreibung der Tabelle. Der Name der Tabelle, welche Spalten hat die Tabelle.

Das ist die Beschreibung der Tabelle, die Intention, nennen wir das auch.

Die Menge der Zeilen, das ist die Extension. Das ist die eigentliche Tabelle, die nennen wir auch Relation.

Also eine Menge von Tupeln, das nennen wir Relation.

Da haben wir dann verschiedene, mehr oder weniger formale Definitionen dafür eingeführt.

Ganz informal haben wir einfach gesagt, Tabelle. Ein bisschen formaler schon haben wir gesagt, eine Relation ist eine Menge von Tupeln.

Und damit haben wir ein paar Dinge ausgedrückt, nämlich eine Menge von Tupeln bedeutet, es gibt keine zwei gleichen Tupeln.

Das gehört zur Mengeneigenschaft. Und zweitens, es gibt keine definierte Reihenfolge der Tupel.

In einer Menge gibt es nicht das erste, zweite, dritte Tupel, sondern da haben wir keine definierte Reihenfolge.

Wir können also auch nicht die Datenbank fragen, gib mir das fünfte Tupel. So was gibt es nicht.

So, dann haben wir noch den Grad der Relation kennengelernt. Das ist einfach die Anzahl der Spalten.

Und die Kardinalität. Okay, herzlich willkommen.

Die Kardinalität ist die Anzahl der Zeilen.

So, dann haben wir das in diversen Beispielen. Hier haben wir noch eine etwas weitere Formalisierung der Definition.

Wie kann man das noch etwas formaler definieren?

Da haben wir gesagt, eine Relation kann man auch mathematisch etwas korrekter definieren als eine Teilmenge des Kreuzprodukts der Wertebereiche der Attribute.

Das Kreuzprodukt der Wertebereiche der Attribute ist nichts anderes als die Menge aller möglichen Tupel, die aufgrund der Wertebereiche definiert sind.

Und eine Relation ist immer eine Teilmenge davon.

So, das wollten wir uns dann nochmal merken.

Wichtig dann, für Tabellen wollen wir das gleiche haben, wie auch für Entitytypen und Entitymengen bereits.

Wir wollen die einzelnen Zeilen in dieser Tabelle eindeutig identifizieren können.

Und das wollen wir ausschließlich über Attributwerte machen.

Warum wollen wir das ausschließlich über Attributwerte machen? Damit wir einen gewissen Grad an Datenunabhängigkeit erreichen.

Wir wollen also nicht irgendwelche physischen Zeiger auf Datensätze haben.

Wenn der Benutzer das verwenden möchte, dann hätte er eben keine Datenunabhängigkeit, wenn er so physische Zeiger verwendet, die auf irgendeinem Speicherbereich zeigen.

Sondern wir wollen die Tupel, unsere Datensätze ausschließlich über Attributwerte identifizieren können.

Und schön wäre es, wenn wir einen ausgezeichneten Attributwert hätten, der uns genau das leistet, einzelne Zeilen eindeutig zu identifizieren.

Weil wir gesagt haben, eine Tabelle ist eine Menge von Tupeln und da gibt es keine Duplikate drin, haben wir damit auch gesagt,

dass alle Attribute zusammengenommen auf jeden Fall eine Zeile eindeutig identifizieren.

Jede Kombination von Attributen, die diese identifizierende Eigenschaft hat, die haben wir Superschlüssel genannt.

Wenn wir zusätzlich zu der identifizierenden Eigenschaft noch sagen können, diese Menge von Tupeln ist minimal,

wir können keins dieser Attribute weglassen, ohne die identifizierende Eigenschaft zu verlieren, dann reden wir von einem Schlüsselkandidaten.

Es kann sein, dass es in einer Tabelle mehrere Schlüsselkandidaten gibt, von denen wählen wir einen aus, den wir konventionsgemäß dann zur Identifikation der Zeilen verwenden.

Den nennen wir Primärschlüssel.

Wenn wir jetzt dem Datenbanksystem mitteilen, hier die Matrikelnummer, das ist der Primärschlüssel zur Identifikation von Studenten,

dann garantiert uns das Datenbanksystem, dass in diesem Attribut erstens keine Nullwerte drinstehen und zweitens da gibt es keine Duplikate.

Wenn wir das haben, dann können wir dieses Attribut als logischen Zeiger verwenden.

Wir können ein anderes Attribut definieren und auf Tupel verweisen, mit Hilfe von Werten in so einem Primärschlüsselattribut.

Und Attribut, das solche Verweise enthält, nennen wir Fremdschlüsselattribut.

Da haben wir ein paar Beispiele, hier haben wir eine Tabelle Personen und da steht zum Beispiel ein Fremdschlüsselattribut Abteilung drin.

Und in diesem Fremdschlüsselattribut stehen nur Werte drin, die es hier in der Tabelle Abteilung als Primärschlüssel gibt.