Читать книгу Relationale Datenbanken - Josef Ludwig Staud - Страница 14
Оглавление5 Beziehungen erkennen und einrichten
5.1 Beziehungen erkennen
Beziehungen zwischen Objekten und zwischen Objektklassen
In Kapitel 3 zur konzeptionellen Modellierung wurden bereits die Beziehungen zwischen Objekten bzw. Objektklassen eingeführt, die im Anwendungsbereich erkannt werden und die für die Anwendung von Bedeutung sind. Also zum Beispiel die Beziehung zwischen Angestellten und Abteilungen: Ein Angestellter ist in genau einer Abteilung, eine Abteilung hat mehrere Angestellte.
Diese Beziehungen müssen beim Datenbankentwurf beachtet werden. Einige werden schon in der konzeptionellen Modellierung entdeckt und festgehalten. Andere erst, wenn die Relationen angelegt werden und das Datenmodell vervollständigt wird. Wiederum andere ergeben sich aus der Notwendigkeit, Beziehungen zwischen Relationen im Datenmodell und in der Datenbank zu verankern.
Dabei geht es nur um semantisch sinnvolle Beziehungen, nur um solche, die für den Anwendungsbereich von Bedeutung sind. Spielen z.B. Geschäftsprozesse im Anwendungsbereich eine Rolle, dann müssen alle die Beziehungen erfasst werden, die zu deren Abwicklung benötigt werden.
Zwei- und mehrstellig. Die meisten Beziehungen sind zweistellig (zwei Objektklassen / Relationen stehen in Beziehung), mehrstellige kommen aber auch vor und werden deshalb unten auch erläutert. Zu Beginn wollen wir aber hier von zweistelligen Beziehungen ausgehen.
Kardinalitäten. Wichtig ist, wieviele Objekte von jeder Relation an der Beziehung teilhaben. Im obigen Beispiel zu Abteilungen und Angestellten ist dies z.B.
• 1: n
Gesprochen wird dies "eins zu n", die Buchstaben n oder m stehen für "1 Objekt oder mehrere". Diese Angabe wird Kardinalität genannt. Sie bestimmt, auf welche Weise die Beziehung im Datenmodell und dann in den Daten erfasst wird. Dazu unten mehr. Datenbanktechnisch notwendig ist die Unterscheidung von genau drei Kardinalitäten:
• 1: 1-Beziehungen, d.h. eine Beziehung der Kardinalität 1: 1
• 1: n-Beziehungen, …
• n: m-Beziehungen, …
Kardinalität 1: 1, 1: 1 - Beziehung
Die folgende Abbildung zeigt ein erstes Beispiel. Der Text zwischen den Relationen beschreibt die gewünschte Beziehung. Im ersten Fall geht es um die Beziehung zwischen Angestellten und PCs in einer Organisation. Hier soll es so sein, dass jedem Angestellten genau ein PC zugewiesen ist und er oder sie diesen auch alleine nutzt.
Abbildung 5.1-1: Relationen aus dem Anwendungsbereich ANGESTELLTE
Das zweite Beispiel betrifft die Beziehung zwischenden Artikeln und dem Ort im Lager, wo sie aufbewahrt werden. Hier soll es so sein, dass jeder Artikel an einem Lagerplatz ist und umgekehrt an einem Lagerplatz nur ein einziger Artikel.
Abbildung 5.1-2: Relationen aus dem Anwendungsbereich RECHNUNGSSTELLUNG
Diese beiden Beispiele stellen 1: 1 - Beziehungen dar, da sie jeweils ein Tupel der einen Relation mit einem der anderen in Beziehung setzen.
Kardinalität 1: n, 1: n - Beziehung
Ganz anders in den folgenden Beispielen. Zwischen Abteilungen und den Angestellten gibt es die Beziehung Abteilungszugehörigkeit. Für diese gelten die in der Abbildung angegebenen Wertigkeiten. Sie drücken aus, dass eine Abteilung mehrere Angehörige hat und dass ein Angestellter nicht in mehr als einer Abteilung sein kann. Hier liegt also eine 1: n - Beziehung vor.
Abbildung 5.1-3: Relationen aus dem Anwendungsbereich ANGESTELLTE
Die Beziehung zwischen Rechnungen und Kunden erfasst das nachfolgende Beispiel. Eine Rechnung ist für genau einen Kunden bestimmt, ein Kunde kann natürlich viele Rechnungen beim jeweiligen Unternehmen haben. Also auch wieder eine 1: n - Beziehung.
Abbildung 5.1-4: Relationen aus dem Anwendungsbereich RECHNUNGSSTELLUNG
Kardinalität n: m, n: m – Beziehung
Projekte – Angestellte. Der dritte Beziehungstyp bringt mehrere Tupel der einen Relation mit mehreren der anderen in Beziehung. Das erste Beispiel betrifft Projekte (in Unternehmen) und Angestellte. Dabei gilt, dass in einem Projekt typischerweise mehrere Angestellte mitarbeiten und ein Angestellter in mehreren Projekten mitarbeiten kann. Damit liegt die Kardinalität n: m vor.
Kunden – Adresssen. Genauso kann man es bei der Erfassung von Adressangaben machen. Ein Kunde kann mehrere Adressen haben, unter einer Adresse können mehrere Kunden wohnen. Dies wird oft einfacher erfasst, z.B. ohne den zweiten Aspekt. Dann wäre die Kardinalität 1: n. Oder man lässt je Kunde nur eine Adresse zu, die "Hauptadresse", dann wird die Beziehung zu einer 1: 1-Beziehung.
Zusammenfassung
Die folgende Abbildung drückt die verschieden Kardinalitäten grafisch aus. Die Punkte auf den beiden Seiten repräsentieren die Objekte bzw. Tupel. Die Linien zwischen ihnen die Beziehungen. Entsprechend ist bei einer Kardinalität von 1: 1 jeder Punkt einer Seite mit genau einem auf der anderen Seite verbunden. Bei einer Kardinalität von 1: n ist ein Punkt der einen Seite mit einem oder mehreren verbunden. Bei der Kardinalität von n: m ist von beiden Seiten aus ein Punkt mit mehreren auf der anderen Seite verknüpft.
Abbildung 5.1-5: Mögliche Kardinalitäten in Relationalen Datenmodellen
5.2 Schlüssel und Fremdschlüssel
Bevor nun die konkrete Art und Weise, wie diese Verknüpfungen realisiert werden, besprochen wird, müssen zwei Begriffe geklärt werden. Zuerst der des Schlüssels.
Schlüssel: Definition 3
Als Schlüssel wird ein Attribut bezeichnet, das für jedes Tupel eine andere Ausprägung hat. Ein Schlüssel weist somit jedem Objekt oder jeder Beziehung eine andere Ausprägung zu. Ein Schlüssel kann auch aus einer Kombination von Attributen bestehen. Dann gilt obiges entsprechend.
Zum Objektbegriff: Hier wird der Einfachheit halber weiterhin davon ausgegangen, dass jedes Tupel (jede Zeile) einer Relation ein Objekt (eine Beziehung) beschreibt und die Relation als Ganzes die Objektklasse (Beziehungsklasse).
Fremdschlüssel. Beziehungen in relationalen Datenmodellen und Datenbanken führen zu entsprechenden Verknüpfungen zwischen Attributen verschiedener Relationen, meist zwischen Schlüsseln und Fremdschlüsseln, weshalb letztere jetzt genauer betrachtet werden. Es wird in den folgenden Abschnitten vielfach und in allen Varianten gezeigt: Eine Beziehung zwischen zwei zu verknüpfenden Relationen A und B wird im Kern auf folgende Weise realisiert: Der Schlüssel von Relation A (IdA) wird zu der Relation B hinzugefügt. Dort wird er unterstrichen und stellt dann einen sog. Fremdschlüssel dar.
Relation-A (#IdA, …)
Relation-B (#IdB, …, IdA)
Dies ist nur eine von zahlreichen Varianten, die wir im folgenden kennenlernen. Ist eine Datenbank in guter Verfassung6 gibt es dann für jede Ausprägung des Fremdschlüssels auch eine Attributsausprägung beim zugehörigen Schlüssel (hier IdA). Diese referentielle Integrität wird in der relationalen Theorie gefordert. Damit kann man wie folgt definieren:
Definition: Fremdschlüssel
Ein Attribut, das zusammen mit dem Schlüssel einer anderen Relation eine relationale Verknüpfung realisiert, wird Fremdschlüssel genannt. Es entspricht dem Schlüssel der anderen Relation, d.h., es hat auch seine Attributsausprägungen. Normalerweise besteht ein Fremdschlüssel aus einem einzelnen Attribut, selten aus mehreren. Die Verknüpfung erfolgt über die Ausprägungen von Schlüssel und Fremdschlüssel, z.B. mit Hilfe entsprechender SQL-Befehle.
Die folgenden Abschnitte bringen zahlreiche Beispiel mit allen möglichen Varianten.
5.3 Umsetzung von 1: 1
1: 1 - Einer hier, einer dort. Betrachten wir nun die in Abschnitt 5.1 vorgestellten Beispiele. Das erste betraf die Beziehung zwischen Angestellten und PCs. Es wurde hier als 1: 1-Beziehung festgestellt. Es wird also angenommen, dass die PC-Nutzung so geregelt ist, dass einem Mitarbeiter genau ein PC zugeordnet ist und dieser ihm alleine zur Verfügung steht. Eine solche semantische Beziehung verknüpft also je ein Tupel aus den beiden Relationen (je ein Objekt aus den beiden Objektklassen) und wird 1: 1 - Beziehung genannt.
In einem relationalen Datenmodell wird eine solche Beziehung verankert, indem entweder der Schlüssel von Angestellte zu den Attributen von PC oder der von PC zu den Attributen von Angestellte hinzugefügt wird:
Entweder also
Angestellte (#PersNr, Name, VNname, DatEinst, GebTag, InvNrPC)
PC (#InvNr, Bez, Typ)
oder
Angestellte (#PersNr, Name, VNname, DatEinst, GebTag)
PC (#InvNr, Bez, Typ, PersNr)
In der Tabellendarstellung mit Beispielsdaten wird die Verknüpfung noch klarer. Zuerst die beiden Ausgangsrelationen:
Angestellte
| #PersNr | Name | VName | … |
| 100 | Sulger | Paul | … |
| 200 | Müller | Ulrike | … |
| 150 | Radetzky | Siegfried | … |
PC
| #InvNr | Typbez | … |
| Inv001 | Server | … |
| Inv005 | Laptop | … |
| Inv004 | Laptop | … |
| Inv002 | Desktop | … |
| Inv003 | Desktop | … |
Nach der Übernahme des Schlüssels von PC in die Relation Angestellte könnten sich dann zum Beispiel folgende Fremdschlüsseleinträge ergeben:
Angestellte
| #PersNr | Name | VName | … | InvNrPC |
| 100 | Sulger | Paul | … | Inv005 |
| 200 | Müller | Ulrike | … | Inv001 |
| 150 | Radetzky | Siegfried | … | Inv003 |
Hier noch die beiden Varianten in der grafischen Darstellungsweise. Dabei wird auch der Fremdschlüssel in das Rechteck aufgenommen und die relationale Verknüpfung durch eine Pfeillinie zwischen Schlüssel und Fremdschlüssel dargestellt. Diese beiden Attributsarten, Schlüssel und Fremdschlüssel, sind auch die einzigen, die in dieser grafischen Darstellungsart angegeben werden. Mit ihnen und den Pfeillinien der Verknüpfungen werden dann die relationalen Datenmodelle dargestellt. Vgl. dazu die zahlreichen Beispiele in den Kapiteln 16 und 17.
1: 1 - Beziehungens
Abbildung 5.3-1: Zwei Varianten einer Verknüpfung entlang einer 1: 1-Beziehung - im Beispiel Angestellte / PC
Genauso bei dem Beispiel Artikel/Lagerort. Auch hier kann der Schlüssel der einen Relation als Fremdschlüssel in die andere kommen - in beide Richtungen.
Abbildung 5.3-2: Zwei Varianten einer Verknüpfung entlang einer 1: 1-Beziehung - im Beispiel Artikel / Lagerort
5.4 Min-/Max-Angaben und "1: 1vertieft"
Min- / Max-Angaben - Wertigkeiten
Die oben gezeigte Verknüpfungsart ist zwar richtig, aber für die konkrete Arbeit nicht genau genug. Denn sie berücksichtigt nicht, ob es sich um Pflichtbeziehungen oder um optionale Beziehungen handelt. Im obigen Beispiel zu Angestellten und PCs:
• Nehmen alle Angestellten an der Beziehung teil, haben also alle einen zugeordneten PC?
• Sind alle PCs einem Angestellten zugeordnet oder gibt es welche, die zwar beschafft, aber nicht zugewiesen sind, z.B., weil sie erst noch hergerichtet werden?
Min-/Max-Angaben. Dies ist datenbanktechnisch und für die Gestaltung der Verknüpfungen von großer Bedeutung, wie gleich unten gezeigt wird, und muss deshalb auch erfasst werden. Dazu gibt man statt der Kardinalität bei jeder an der Beziehung beteiligten Relation an, wieviele Tupel mindestens und wieviele höchstens daran teilhaben. Damit entstehen sog. Min-/Max-Angaben (auch Wertigkeiten), mit denen dann für jede Relation die Beziehung wesentlich genauer angegeben werden kann. Im obigen Fall zum Beispiel:
• Jeder Angestellte muss genau einen zugeordneten PC haben. Min-/Max-Angabe: 1,1 (mindestens ein Tupel, höchstens ein Tupel => genau ein Tupel). Pflichtteilnahme.
• Ein Angestellter kann, muss aber nicht einen PC haben. Min-/Max-Angabe: 0,1 (evtl. kein Tupel, höchstens ein Tupel). Optionale Teilnahme.
• Jeder PC muss genau einem Angestellten zugeordnet sein. Min-/Max-Angabe: 1,1. Pflichtteilnahme.
• Ein PC kann, muss aber nicht einem Angestellten zugeordnet sein. Min-/Max-Angabe: 0,1. Optionale Teilnahme.
Für die 1: 1 -Beziehung zwischen Angestellten und PCs sind also folgende Varianten möglich:
• 1,1: 1,1
• 0,1: 1,1
• 1,1: 0,1
• 0,1: 0,1
Lesehinweis:
Meistens beziehen sich Min-/Max-Angaben auf zwei Relationen und deren Attribute (i.d.R. Schlüssel und Fremdschlüssel). Z.B. Relation 1 / Relation 2. Bei der Interpretation der Min-/Max-Angaben ist die Reihenfolge zu beachten, in der die Relationen angeführt sind. Der erste Min-/Max-Ausdruck vor dem Doppelpunkt bezieht sich auf die erstgenannte Relation (gibt also an, wie sie an der Beziehung teilnimmt), der zweite Min-/Max-Ausdruck auf die zweite. Liegen z.B. die Min-/Max-Angaben
1,1: 1,n vor, bedeutet dies hier:
• Jedes Tupel von Relation 1 nimmt mindestens und maximal ein Mal an der Beziehung teil (“genau ein mal“)
• Jedes Tupel von Relation 2 nimmt mindestens ein Mal an der Beziehung teil. Also auch u.U. mehrfach
Entsprechend in den Grafiken mit Datenmodellen. Von einer Relation ausgehend ist der erste Teil der Min-/Max-Angabe der für diese Relation zuständige.
Verknüpfungsvarianten
Die damit möglichen Präzisierungen der Verknüpfungen werden im folgenden dargestellt. Zuerst aber eine grafische Darstellung der Varianten in der folgenden Abbildung. Dabei repräsentieren die Punkte die Objekte (Tupel) der Relationen und die Linien die relationale Verknüpfung. Bleiben Punkte ohne Linie, handelt es sich um eine für die jeweilige Relation optionale Beziehung (mit Minimalwert 0), ansonsten ist es eine Pflichtbeziehung. Der Kardinalität 1: 1 entsprechend ist hier jeweils ein Objekt (Tupel) der einen Seite mit genau einem der anderen Seite verknüpft. Durch die nicht verknüpften Punkte wird die Optionalität bzw. der Pflichtcharakter der Beziehung für die jeweilige Relation verdeutlicht.
Abbildung 5.4-1: Min-/Max-Varianten für Kardinalität 1: 1
Verknüpfung für die Min-/Max-Angaben 1,1: 1,1
Der oben bei der Diskussion der Kardinalität vorgestellte Fall betrifft die Situation, wenn auf beiden Seiten 1,1 als Min-/Max-Angabe vorliegt. Dann besteht freie Wahl, welcher Schlüssel in die andere Relation als Fremdschlüssel übernommen wird, genauso wie es oben in Abbildung 5.3-2 gezeigt wurde.
Verknüpfung für die Min-/Max-Angaben 1,1: 0,1
Ist die Teilnahme der PCs an der Beziehung optional, muss der Schlüssel von PC in die Relation Angestellte aufgenommen werden:
Angestellte (#PersNr, Name, VNname, DatEinst, GebTag, InvNr)
PC (#InvNr, Bez, Typ)
Die andere Richtung ist nicht möglich, weil es da wiederum für den Fremdschlüssel teilweise keine Ausprägungen geben kann. Zur Veranschaulichung eine Tabelle mit der falschen Lösung. Es soll so sein, dass Müller, Stanis und Stoll keinen PC haben, die anderen aber schon. Dann wäre bei den drei genannten kein sinnvoller Eintrag möglich.
Angestellte
| #PersNr | Name | VName | … | InvPC |
| 100 | Sulger | Paul | … | Inv005 |
| 200 | Müller | Ulrike | … | ????? |
| 150 | Radetzky | Siegfried | … | Inv001 |
| 199 | Stanis | Rolf | … | ????? |
| 244 | Stoll | Eva | ????? |
Die folgende Abbildung zeigt die richtige Lösung, d.h. die richtige Platzierung des Fremdschlüssels.
Abbildung 5.4-2: Relationale Verknüpfung für Angestellte / PC und die Min-/Max-Angaben 1,1 - 0,1
Kardinalität: 1:1
Min-/Max-Angaben: 1,1: 0,1
Semantik:
- Allen Angestellten ist ein PC zugewiesen. Dies fordert auch die referentielle Integrität.
- Es gibt PCs, die noch keinem Angestellten zugewiesen sind.
Verknüpfung für die Min-/Max-Angaben 0,1: 1,1
Was ist, wenn auf der Seite der Angestellten die Min-/Max-Angabe 0,1 vorliegt? Dann kann in diese Relation nicht der Schlüssel von PC aufgenommen werden, denn es gäbe dann Tupel, für die es einen Attributseintrag nicht geben kann. Somit muss in diesem Fall die PersNr als Fremdschlüssel in PC eingefügt werden.
Angestellte (#PersNr, Name, VNname, DatEinst, GebTag)
PC (#InvNr, Bez, Typ, PersNr)
Abbildung 5.4-3: Relationale Verknüpfung für Angestellte / PC und die Min-/Max-Angaben 0,1: 1,1
Kardinalität: 1:1
Min-/Max-Angaben: 0,1: 1,1
Semantik:
- Es gibt Angestellte, denen kein PC zugewiesen ist. Ansonsten haben sie maximal einen.
- Jeder PC wird datenbanktechnisch immer einem Angestellten zugeordnet.
Verknüpfung für die Min-/Max-Angaben 0,1: 0,1
Dritte Relation. Eine Sondersituation liegt vor, wenn die Beziehung Angestellte / PC die Min-/Max-Angaben 0,1: 0,1 hat. Dann kann weder der Schlüssel von Angestellte nach PC noch der von PC nach Angestellte genommen werden. In diesem Fall ist eine neue dritte Relation ("PC-NUTZUNG ") nötig, in der die Schlüssel der beiden Relationen vereinigt sind:
PC-NUTZUNG (#AngNr, #InvNrPC)
Dies drückt dann die Beziehung korrekt aus. In tabellarischer Darstellung könnte es sich so ergeben:
PC-NUTZUNG
| #PersNr | #InvPC |
| 100 | Inv005 |
| 150 | Inv001 |
Durch diese neue Relation werden nur die wirklich existierenden Beziehungen erfasst. Eine Besonderheit dieser Relation ist, dass beide Attribute alleine Schlüssel sein können, da aufgrund der Zahl eins an der zweiten Stelle der Min-/Max-Angaben die Attribute PersNr und InvPC jede Ausprägung nur einmal besitzen.
Hier noch die grafische Darstellung.
Abbildung 5.4-4: Relationale Verknüpfung für Angestellte / PC und die Min-/Max-Angaben 0,1: 0,1
Kardinalität: 1:1
Min-/Max-Angaben: 0,1: 0,1
Semantik:
- Es gibt Angestellte, denen kein PC zugewiesen ist. Ansonsten haben sie maximal einen.
- Es gibt PC, die keiner Angestellten zugewiesen sind. Ansonsten ist maximal einer zugewiesen..
5.5 Umsetzung von 1: n
Grundsätzlich gilt: Allein die Möglichkeit, dass mehr als ein Objekt (mehr als ein Tupel) an einer Beziehung teilhaben kann, erhöht bereits ihre Stelligkeit auf der jeweiligen Seite über 1 hinaus, da dieser Fall dann ja in der Datenbank erfasst werden muss und die höhere Stelligkeit die niedrigere umfasst, aber nicht umgekehrt.
Ausdifferenzierung
Die oben eingeführten 1: n-Beziehungen können mit den Min-/Max-Angaben ebenfalls ausdifferenziert werden. Insgesamt gibt es folgende Varianten, von denen aber nicht alle datenbanktechnisch bedeutsam sind:
• 1,1: 1,n (für beide Relationen Pflicht)
• 1,1: 0,n (Pflicht für die eine Relation, Option für die andere)
• 0,1: 1,n (optional für die eine Relation, Pflicht für die andere)
• 0,1: 0,n (optionale Beziehung für beide Relationen)
Die folgende Abbildung drückt für die Kardinalität 1: n die verschiedenen Min-/Max-Angaben grafisch aus. Der Kardinalität entsprechend ist hier jeweils ein Objekt (Tupel) der einen Seite mit mehreren der anderen Seite verknüpft. Dabei repräsentieren wiederum die Punkte die Objekte (Tupel) der Relationen und die Linien die relationale Verknüpfung. Bleiben Punkte ohne Linie, handelt es sich um eine für die jeweilige Relation optionale Beziehung (mit Minimalwert 0), ansonsten ist es eine Pflichtbeziehung.
Abbildung 5.5-1: Varianten der Kardinalität 1: n entlang der Min-/Max-Angaben
Konkrete Realisierung der Verknüpfung
1,1 : 1,n
Die erste Variante ist der Fall, an den man denkt, wenn man die Kardinalität 1: n wahrnimmt. In der Realität ist sie aber eher die Ausnahme. Bei ihr nimmt jedes Tupel der beiden Relationen an der Beziehung teil.
Im Beispiel Abteilungen / Angestellte bedeutet dies - durchaus nachvollziehbar - dass jede Abteilung Angestellte hat (mindestens eine/n) und jede/r Angestellte in einer Abteilung ist. Dementsprechend kann der Schlüssel von Abteilungen in der Angestelltenrelation hinterlegt werden:
Abteilungen (#AbtBez, AbtLeiter, Standort)
Angestellte (#PersNr, Name, VNname, DatEinst, GebTag, AbtBez)
Umgekehrt geht dies nicht. Der Schlüssel von Angestellte in Abteilungen würde zu Mehrfacheinträgen führen, was für relationale Datenmodelle verboten ist. Die folgende Abbildung zeigt die Umsetzung in ein Datenmodell.
Abbildung 5.5-2: Relationale Verknüpfung für Abteilungen / Angestellte und die Min-/Max-Angaben 1,n: 1,1
Kardinalität: 1:n
Min-/Max-Angaben: 1,n: 1,1
Semantik:
- Eine Abteilung hat mindestens einen Angestellten.
- Ein Angestellter ist genau einer Abteilung zugeordnet.
1,1: 0,n. Diese Variante bedeutet, dass der Fremdschlüssel in der Relation mit Pflichtteilnahme hinterlegt werden muss. Dies ist dann die, von der jedes Tupel genau eine Beziehung eingeht. Sie bedeutet in diesem Beispiel, dass es Abteilungen gibt, denen (noch) keine Angestellten zugeordnet sind, z.B. weil sie zwar eingerichtet aber noch nicht mit Personal ausgestattet wurden. Andererseits nehmen alle Angestellten an der Beziehung teil. Deshalb kann die Umsetzung hier genauso wie im vorigen Fall sein.
0,n: 1,1 - Neue Relation. Diese Variante bedeutet, dass der Fremdschlüssel in der Relation hinterlegt werden müsste, bei der jedes Tupel eine mehrfache Beziehung eingehen könnte. Dies ist aber nicht möglich, weil dabei Mehrfacheinträge entstehen würden. Damit ergibt sich hier die Notwendigkeit für die relationale Beziehung eine neue Relation (Abteilungszughörigkeit; AbtZug) einzurichten.
0,1: 0,n. Genau dasselbe gilt für die Variante 0,1: 0,n. Sie bedeutet ja, dass der Fremdschlüssel in keiner der beiden Relationen untergebracht werden kann, da es dann in beiden Fällen Tupel gäbe, bei denen der Fremdschlüssel keinen Eintrag haben könnte und ein Fall sowieso wegen drohender Mehrfacheinträge nicht in Frage kommt. Also auch hier die neue Relation. Für beide obigen Fälle ergibt sich damit die folgende Lösung.
Abteilungen (#AbtBez, AbtLeiter, Standort)
Angestellte (#PersNr, Name, VNname, DatEinst, GebTag)
AbtZug (#(AbtBez, PersNr))
Die neue Relation hat einen zusammengesetzten Schlüssel, bestehend aus den zwei Fremdschlüsseln. Die folgende Abbildung zeigt das dabei entstehende kleine Datenmodell.
Abbildung 5.5-3: Relationale Verknüpfung für Abteilungen / Angestellte und die Min-/Max-Angaben 0,1: 1,n sowie 0,1: 0,n
Kardinalität: 1:n
Min-/Max-Angaben: 0,1: 1,n oder 0,1: 0,n.
Semantik 0,1: 1,n:
- Einer Abteilung ist kein Angestellter, einer oder es sind mehrere zugewiesen.
- Ein Angestellter ist keiner oder genau einer Abteilung zugewiesen.
Semantik 0,1: 0,n:
- Einer Abteilung ist ein Angestellter zugewiesen oder mehrere („mindestens einer)“.
- Ein Angestellter ist keiner oder genau einer Abteilung zugewiesen
5.6 Umsetzung von n: m
Eine Kardinalität von n: m bedeutet, dass mehrere Tupel der einen Relation mit mehreren der anderen in Beziehung stehen und dies in beide Richtungen. Folgende Varianten sind möglich:
• 1,n: 1,m
• 0,n: 1,m
• 1,n: 0,m
• 0,1: 0,m
Die folgende Abbildung drückt für die Kardinalität n: m die verschiedenen Min-/Max-Angaben grafisch aus. Der Kardinalität entsprechend ist hier jeweils ein Objekt (Tupel) der einen Seite mit mehreren der anderen Seite verknüpft - in beide Richtungen. Dabei repräsentieren wiederum die Punkte die Objekte (Tupel) der Relationen und die Linien die relationale Verknüpfung. Bleiben Punkte ohne Linie, handelt es sich um eine für die jeweilige Relation optionale Beziehung (mit Minimalwert 0), ansonsten ist es eine Pflichtbeziehung.
Verknüpfungsvarianten für n: m
Abbildung 5.6-1: Varianten der Kardinalität n: m entlang der Min-/Max-Angaben
Realisierung der Verknüpfung - Verbindungsrelation
Die Lösung besteht hier immer aus der Einrichtung einer neuen Relation, da jede Übernahme eines Schlüssels in die andere Relation zu Mehrfacheinträgen führen würde. In der neuen Relation, die Verbindungsrelation genannt wird, sind die beiden Schlüssel der zu verknüpfenden Relationen zusammen Schlüssel und dabei einzeln jeweils Fremdschlüssel. Hier ergibt die Betrachtung der verschiedenen Min-/Max-Angaben keine Notwendigkeit für spezielle Lösungen. In allen Varianten leistet die Verbindungsrelation die problemfreie Verknüpfung.
Beispiel Projektmitarbeit. So bei einer Beziehung "Projektmitarbeit" zwischen Angestellten und Projekten einer Organisation. Ein Angestellter kann in mehreren Projekten mitarbeiten, ein Projekt kann mehrere Angestellte zugewiesen haben:
Angestellte(#PersNr,Name,VNname,DatEinst,GebTag)
Projekte (#Bez, TagEinr, Dauer, Budget)
Die Verbindungsrelation ergibt sich wie folgt:
ProjMitarb (#(PersNr, BezProj))
Zusammen mit den Ausgangsrelationen ergibt sich ein kleines Datenmodell, das die n: m-Beziehung in allen Min-/Max-Varianten erfasst.
Abbildung 5.6-2: Relationale Verknüpfung für Angestellte / Projekte und die Kardinalität n: m
Kardinalität: n: m
Min-/Max-Angaben:
1,n: 1,m / 1,n: 0,n / 0,n: 1,m / 0,n: 0,m
Semantik:
• 1,n: 1,m: Eine Angestellte ist mindestens einem Projekt zugeordnet. Ein Projekt hat mindestens einen zugewiesenen Angestellten.
• 1,n: 0,n: Eine Angestellte ist keinem, einem oder mehreren Projekten zugewiesen. Ein Projekt hat mindestens einen zugewiesenen Angestellten.
• 0,n: 1,m: Eine Angestellte ist mindestens einem Projekt zugeordnet. Ein Projekt hat keinen, einen oder mehrere zugewiesene Angestellte.
• 0,n: 0,m: Eine Angestellte ist keinem, einen oder mehreren Projekten zugewiesen. Ein Projekt hat keinen, einen oder mehrere zugewiesene Angestellte.
Schlüssel: Zusammengesetzt aus zwei Attributen. Für jedes Tupel müssen beide Attribute Einträge haben.
Die konkrete Verknüpfung zeigt die folgende tabellarische Darstellung mit Beispielsdaten.
Angestellte
| #PersNr | Name | VName | … |
| 100 | Sulger | Paul | … |
| 200 | Müller | Ulrike | … |
| 150 | Radetzky | Siegfried | … |
| 102 | Meindl | Karl | … |
| 300 | Friedrich | Eugenie | … |
| 350 | Paulsen | Heinrich | … |
| 390 | Lürsen | Lars | … |
| 400 | Schlichter | Ute | … |
Projekte
| #Bez | Leiter | Budget | … |
| BPR | Müller | 10000 | … |
| Change Management | Paulsen | 50000 | … |
| IT2014 | Lürsen | 1500000 | … |
BPR: Business Process Reengineering (Geschäftsprozessoptimierung)
Die Verbindungsrelation hält in jedem Tupel eine Projektmitarbeit fest. Arbeitet ein Angestellter in mehreren Projekten mit, gibt es entsprechend mehrere Tupel.
ProjMitarb
| ProjBez | PersNr | … |
| BPR | Müller | … |
| BPR | Radetzky | … |
| Change Management | Radetzky | … |
| IT2014 | Lürsen | … |
| IT2014 | Schlichter | … |
| … | … | … |
Schlüssel: #(ProjBez, PersNr)
Diese angegebenen Tupel genügen, um die n: m - Beziehung deutlich zu machen: Ein Projekt hat mehrere Mitarbeiter, ein Mitarbeiter ist in mehreren Projekten.
Verbindungsrelation. Die Bezeichnung Verbindungsrelation rührt daher, weil sie die anderen beiden semantisch (und dann später auch für Abfragen und Auswertungen) verknüpft. Auch sie benötigt natürlich einen Schlüssel. Dieser besteht aus den beiden von den Ausgangsrelationen übernommenen Attributen und ist unten an der Tabelle angegeben. Er ist das erste Beispiel für einen zusammengesetzten Schlüssel. Dazu später mehr.
Beziehungen in relationalen Datenmodellen und damit in relationalen Datenbanken können meist nur auf die oben beschriebene Weise erfasst werden, also nur durch Attribute, die von der einen Relation kommen (meist als Schlüssel) und bei der anderen eingefügt werden (meist als Fremdschlüssel). Nach der Übernahme eines Attributs als Fremdschlüssel gibt jedes Tupel eine der Beziehungen an.
5.7 Verknüpfung konkret
Es wurde oben schon deutlich: Relationen stehen nicht isoliert im Datenmodell, sondern sind miteinander verknüpft. Dies ist sogar ein grundsätzliches Wesensmerkmal relationaler Datenmodelle. Alle Relationen eines relationalen Datenmodells müssen untereinander in Beziehung stehen, wobei mit Beziehung die oben eingeführte Verknüpfung durch Attribute gemeint ist.
Anmerkung:
Eine Ausnahme von dieser Regel ergibt sich, wenn man Tabellen zum "Nachschlagen" mit in das Datenmodell integriert. Z.B. mit Kalenderdaten, wenn es um ein Datenmodell geht, bei dem Kalenderdaten eine große Rolle spielen. Eine solche "Nachschlagetabelle" ist nicht auf die übliche "relationale" Weise mit den übrigen Relationen des Datenmodells verknüpft (wie es in diesem Abschnitt erläutert wird), hat aber trotzdem Bedeutung für das Datenmodell.
Bei Datenbanken, deren Ersteller wenig Kompetenz in Datenmodellierung haben, sieht man Lösungen ohne attributbasierte Schlüssel-/Fremdschlüsselbeziehungen. Da werden dann diese Beziehungen im Anwendungsprogramm hinterlegt und durch dieses realisiert. Die jeweilige Semantik ist damit im Programm hinterlegt.
DBS / PROD mit Min-/Max-Angaben 1: n
Was bedeuten nun solche Verknüpfungen konkret? Die folgenden Abbildungen sollen darauf eine Antwort geben. Als Beispiel dient die Beziehung zwischen Datenbanksystemen (DBS) und ihren Produzenten . Da ein Produzent u.U. mehrere Datenbanksysteme herstellt und ein Datenbanksystem von einem einzigen Produzenten kommt, handelt es sich hier um eine 1: n - Beziehung mit den Min-/Max-Angaben 1,1: 1,n. D.h., wir nehmen nur die Produzenten auf, von denen wir auch eine Datenbank erfasst haben. DBS erhält also einen Fremdschlüssel. Die textliche Fassung sei wie folgt:
DBS (#(Bez, Typ, Plattform, IdProd)
PROD (#IdProd, Ort, Straße, Land)
Hier das Datenmodell in grafischer Fassung.
Abbildung 5.7-1: Datenmodellfragment DBS / Prod in grafischer Darstellung
Nun zur Verdeutlichung die Relationen in Tabellenform mit abstrahierten Daten. Die Verbindungslinie soll wiederum zeigen, dass bei gleichen Ausprägungen eine Verknüpfung erfolgen kann. Dabei wird dann, z.B. mit SQL, das Tupel zu DBS4 über den Fremdschlüsseleintrag "P2" mit dem Tupel von "P2" in Prod verknüpft.
Abbildung 5.7-2: Datenmodellfragment DBS / PROD in Tabellendarstellung
Dies wird noch deutlicher, wenn man wie in der nächsten Abbildung diese Tupelverknüpfung verdeutlicht. Die Pfeile deuten jetzt an, dass ein Tupel der Relation PROD(uzenten) mit mehreren Tupeln der Relation DBS verbunden sein kann, entsprechend der 1: n-Verknüpfung.
Hier kann man sich auch die Probleme vorstellen, die entstehen, wenn es Fremdschlüsseleinträge gibt, die beim zugehörigen Schlüssel nicht vorhanden sind. Dies ist auch explizit untersagt. Liegt es nicht vor, ist die sog. referentielle Integrität des Datenmodells und später der Datenbank gesichtert (vgl. Abschnitt 5.9). Dagegen macht es datenbanktechnisch keine Probleme, wenn beim Schlüsselattribut einer solchen Verknüpfung Ausprägungen vorhanden sind, die "auf der anderen Seite" fehlen. Dann ist die Beziehung eben optional im oben diskutierten Sinn.
Abbildung 5.7-3: Darstellung der Verknüpfung auf Tupelebene
Über eine solche relationale Verknüpfung können die beiden Relationen auch insgesamt zusammengeführt werden.
5.8 Mehrstellige Beziehungen
Zusammengesetzte Schlüssel. Es gibt natürlich auch mehrstellige Beziehungen in Datenbanken und Datenmodellen. In diesen Fällen muss immer eine Verbindungsrelation gebildet werden. Diese hat einen zusammengesetzten Schlüssel, der aus den Schlüsseln der beteiligten Relationen besteht, wie es auch dieses abstrakte Beispiel zeigt:
R1 (#Attr1, Attr2, Attr3, …)
R2 (#Attr4, Attr5, …)
R3 (#Attr6, Attr7, Attr8)
Verbindungsrelation
R1-R2-R3 (#(Attr1, Attr4, Attr6))
Soweit - sozusagen - die Standardlösung in einfacher abstrahierter Darstellung. In jedem Tupel der Verbindungsrelation ist dann genau eine Beziehung festgehalten. Der konkrete Aufbau hängt dann noch von den Min-/Max-Angaben und einer eventuellen zeitlichen Dimension ab. Außerdem werden natürlich nur die Schlüsselbestandteile Fremdschlüssel, für die es eine beschreibende Relation "am anderen Ende der Verknüpfung" gibt.
Beispiel: Training. Zwei Beispiele sollen dies noch mehr verdeutlichen. Im ersten geht es um das Training von Mannschaften, z.B. im Fussball. Der Trainer ist ein Angestellter des Vereins und hat deshalb eine Personalnummer (PersNr). Das Training kann an verschiedenen Orten stattfinden (Bezeichnung Ort: BezOrt). Die (vereinfachten) Relationen seien wie folgt:
Mannschaften (#MannschNr, Bez, …)
Trainer (#PersNr, Name, VName, …)
Orte (#BezOrt, Typ, Strasse, PLZ, Ort)
In einer konkreten Trainingsdurchführung kommen dann drei Objekte (im Sinne der konzeptionellen Modellierung) bzw. Relationen zusammen. Hinzugenommen werden muss noch der Zeitpunkt des Trainings (vgl. zur zeitlichen Dimension in der Datenmodellierung Kapitel 15), hier mit der Angabe des Tages. Der Einfachheit halber soll angenommen werden, dass nur einmal am Tag trainiert wird, dann reicht die Angabe des Tages aus:
Training (#(MannschNr, PersNr, BezOrt, Tag), Beginn, Ende)
Damit identifiziert jeder Schlüssel eine Trainingseinheit und das Tupel als Ganzes beschreibt sie. Hier einige Beispiele:
Training
| MannschNr | PersNr | BezOrt | Tag | Beginn | Ende |
| 1001 | 700 | Stadion | 20.9.2021 | 8.00 | 12.00 |
| 2000 | 440 | Stadion | 17.7.2021 | 9.00 | 10.30 |
| 1001 | 700 | Halle | 22.9.2021 | 14.00 | 17.30 |
| … |
Vorlesungsbetrieb (VLB). Das zweite Beispiel betrifft die Durchführung von Vorlesungen über die Semester hinweg. Welche Vorlesung hat stattgefunden? Welcher Dozent hat sie realisiert, usw.? Also nicht die konkreten Vorlesungstermine, sondern die Durchführung der einzelnen Vorlesungen in den Semestern, z.B. der Vorlesung Datenbanksysteme mit der Vorlesungsnummer (VorlNr) 9012 im SS2021 durch den Dozenten mit der DozId Sta. Das könnte die folgende Relation leisten:
VLB (#(VorlNr, Semester, DozId))
Zusätzlich existieren Relationen zu den Vorlesungen und den Dozenten:
Vorlesungen (#VorlNr, Bez, SWS, cps, …)
Dozenten (#DozId, Name, Vorname, …)
Vgl. Abschnitt 16.5 für ein umfassendes Beispiel zum Vorlesungsbetrieb.
5.9 Integritäten
Dies ist nun die Stelle, um zwei grundsätzliche Forderungen an Relationen bzw. Datenmodelle anzuführen: Objektintegrität und referentielle Integrität.
Objektintegrität - Nie ohne vollständigen Schlüssel
Objektintegrität wird die Forderung genannt, dass kein Tupel mit unvollständigem Schlüssel in eine Relation eingetragen werden darf. D.h., es kommt natürlich vor, dass unvollständige Tupel in eine Relation eingetragen werden, z.B. weil eine Information noch fehlt, aber der Schlüssel muss vollständig vorhanden sein. Dies wird normalerweise gar nicht als Problem erkannt, da bei einem Schlüssel, der aus einem Attribut besteht, niemand auf die Idee kommt, ihn wegzulassen. Besteht der Schlüssel aber aus mehreren Attributen (vgl. den nächsten Abschnitt), kann man beim Eintragen schon auf diese Idee kommen.
Referentielle Integrität
Es wurde oben schon öfters thematisiert. Bei einer relationalen Verknüpfung sollten beim Fremdschlüssel keine Ausprägungen vorhanden sein, die es beim zugehörigen Schlüssel nicht gibt. Denn ist dies der Fall, gibt es zu der Ausprägung keine "Fortsetzung" in der anderen Relation.
Man kann es auch so formulieren: In den jeweiligen Fremdschlüssel einer relationalen Verknüpfung darf eine Ausprägung nur eingetragen werden, wenn sie als Ausprägung des Schlüssels in der anderen Relation (wo dieses Attribut ja Schlüssel ist) vorkommt. Damit soll verhindert werden, dass Fremdschlüsseleinträge erfolgen, die nicht verknüpft werden können.
Betrachten wir als Beispiel nochmals die beiden Relationen DBS (mit dem Fremdschlüssel IdProd) und PROD (mit dem Schlüssel IdProd). Die Forderung der referentiellen Integrität verbietet es, einen Produzenten in DBS.IdProd einzutragen, der nicht in PROD.IdProd vorhanden ist.
Erinnerung: Die Schreibweise DBS.IdProd bedeutet "Attribut IdProd von der Relation DBS". Entsprechend bedeutet PROD.IdProd "Attribut IdProd von der Relation PROD".
5.10 Schlüssel vertieft
Oben kam es nun schon mehrmals vor. Zuletzt bei den mehrstelligen Verknüpfungen und davor in Abschnitt 5.6: Schlüssel, die aus mehr als einem Attribut bestehen. Das Beispiel aus Abschnitt 5.6 betraf die Projektmitarbeit. Die Relation
ProjMitarb (#(PersNr, BezProj))
benötigt zwei Attribute um den Sachverhalt ausdrücken, welche Angestellten in welchen Projekten mitarbeiten. Dann sieht man, dass Radetzky in den Projekten BPR und Change Management mitarbeitet, Müller aber nur im Projekt BPR.
Relation ProjMitarb
| BezProj | PersNr |
| BPR | Müller |
| BPR | Radetzky |
| Change Management | Radetzky |
| … | … |
Hier noch die grafische Darstellung solcher Relationen:
Textliche Notation. In der textlichen Notation werden zusammengesetzte Schlüssel wie oben gesehen angegeben. Hier noch ein weiteres Beispiel aus den obigen Abschnitten, Abteilungszugehörigkeit (AbtZug), mit den Min-/Max-Angaben 01, : 0,n.
AbtZug (#(AbtBez, PersNr)) // vgl. Abschnitt 5.5
Grundsätzlich müssen die einzelnen Attribute des Schlüssels ("Schlüsselattribute") nicht Fremdschlüssel sein, sie sind es aber oft, da meist eine von den Fremdschlüsseln ausgehende relationale Verknüpfung vorliegt.
Konkurrierende Schlüssel
Von dieser Situation, dass ein Schlüssel aus mehreren Attributen besteht, ist zu unterscheiden, wenn eine Relation mehrere, voneinander unabhängige Schlüssel hat (konkurrierende Schlüssel). Nehmen wir als Beispiel eine Relation zu Abteilungen:
Abteilungen (#AbtID, #AbtBez, AbtLeiter, Standort)
Hier sind AbtId und AbtBez jeweils identifizierend.
Die grafische Darstellung:
Primärschlüssel und Sekundärschlüssel
Es soll zu jeder Abteilung eine identifizierende Kurzbezeichnung geben wie PW, ORG, IT, usw. und zusätzlich die ganz normale Bezeichnung. Beide erhalten die Raute für die Kennzeichnung als Schlüssel. In einem solchen Fall macht es auch Sinn, von Sekundärschlüsseln und Primärschlüsseln zu reden. Einer der Schlüssel, meist der für die interne Verknüpfung verwendete, wird zum Primärschlüssel, der andere ist dann der Sekundärschlüssel.
Der von einigen Autoren verwendete Begriff Schlüsselkandidat ist eine direkte Übersetzung des amerikanischen Begriffs "candidate key" für Sekundärschlüssel.
6 Also nicht Beiträger zur oft thematisierten Stammdatenkrise, zu der auch fehlerhafte Schlüssel- / Fremschlüsselbeziehungen gehören.
