Das Entity-Relationship-Modell (ERM)
Die Wirklichkeit, Relationen und Tabellen
Wir bleiben gedanklich bei einem Online-Shop. Ohne Zweifel gibt es da Kunden, also wirklich existierende Personen.
Von diesen Kunden werden Datensätze gespeichert, die persönliche Daten wie Name, Vorname enthalten und Weiteres
wie Rechnungs- und Lieferanschrift.
Die Datensätze über Kunden stehen also
in Beziehung zur Wirklichkeit,
und werden daher mit dem englischen Begriff
Relation (die Übersetzung wird im Deutschen genauso geschrieben)
bezeichnet. Eine
Relation ist also eine Menge an Informationen über einen Sachverhalt der Wirklichkeit.
Und diese Menge wird in einer Tabelle notiert. Beispiel:
Loginname |
Passwort |
Name |
Vorname |
EMail |
jojo44 |
*** |
Krause |
Sabine |
krause@example.com |
shoppingqueen |
**** |
Müller |
Luise |
prinzessin@example.com |
frank83 |
***** |
Frank |
Herbert |
frank83@example.com |
Zu beachten ist folgendes:
-
Alle registrierten Kunden sind in einer Tabelle gespeichert
- Jede Zeile steht für genau einen Kunden (auch nur diese eine Zeile)
- Jede Spalte steht für eine Eigenschaft, die dem Kunden zugeordnet ist
Und genauso wird
jede Relation in einer
eigenen Tabelle notiert:
- Eine Tabelle »Produkt« würde alle Produkte enthalten, jede Zeile genau ein Produkt beschreiben;
- eine Tabelle »Warenkorb« würde alle Warenkörbe enthalten, jede Zeile genau einem Warenkorbeintrag entsprechen;
- usw.
Es hat keinen Zweck, jetzt darüber nachzudenken, ob das so sinnvoll ist.
Der Beweis der Zweckmäßigkeit kommt später.
Wir lernen erst mal einige (wenige) Begriffe.
- Der allgemeine Begriff, was in einer Tabelle vorkommt, ist: Relation (kennen wir schon)
- Der allgemeine Begriff für das, was eine Zeile darstellt (also ein Kunde, oder ein Produkt, ...) ist: Entity (Entität)
- Der allgemeine Begriff für das, was jede Spalte darstellt (also jede Eigenschaft) ist: Attribute (Attribut)
Sicher, wer HTML kennt, der kennt
Entity und
Attribut in ganz anderer Bedeutung.
Jeder Fachbereich hat eben sein eigenes Fach-Chinesisch, und im Entity-Relationship-Modell (kurz:
ERM)
gelten die Begriffe in der oben erklärten Bedeutung.
Wer ist Wer?
Es ist ziemlich wichtig, dass die Entities einer Tabelle genau voneinander zu unterscheiden sind.
Wenn es also Werte gibt, die bei jedem Entity anders sind, dann ist das der Schlüssel zur Unterscheidung;
wir sagen dazu: Primärschlüssel (Primary Key).
In unserer Kundentabelle oben könnte der Loginname ein Primärschlüssel sein, sofern der Onlineshop
verhindert, dass ein neuer Kunde einen Loginnamen nehmen will, den es bereits gibt.
Es ist aber großes Glück, wenn man genau eine Spalte als Primärschlüssel findet, bei anderen Tabellen
muss man u.U. mehrere Spalten als Primarschlüssel verwenden;
ein Primärschlüssel wird dann vom mehreren Primärattributen gebildet.
Damit das nicht zu kompliziert wird, greift die Datenbanktechnik zu einem Trick:
Die Entities (also Tabellenzeilen) werden einfach durchnummeriert.
Jede Zahl kommt nur einmal vor, also verwendet man die Nummernspalte als Primärschlüssel.
Entsprechend ergänzt sähe die Kundentabelle so aus (PS steht für Primärschlüssel):
PS |
Loginname |
Passwort |
Name |
Vorname |
EMail |
1 |
jojo44 |
*** |
Krause |
Sabine |
krause@example.com |
2 |
shoppingqueen |
**** |
Müller |
Luise |
prinzessin@example.com |
3 |
frank83 |
***** |
Frank |
Herbert |
frank83@example.com |
Weitere Tabellen
Möglicherweise denken Sie darüber nach, wie groß die Tabellen eines realen Onlineshops wären,
wenn alle Kunden in einer Tabelle, alle Produkte in einer Tabelle, alle Warenkörbe in einer Tabelle, ... sind.
Ich kann Sie beruhigen: Tabellen sind in der Realität oft riesig, die Datenbanksoftware muss das abkönnen -
und kann es auch. Nicht umsonst ist Datenbanksoftware, wenn man sie kauft, ziemlich teuer.
Wir denken uns also die Tabellen Warenkorb und Produkt vereinfacht so vor:
Warenkorb |
|
Produkt |
FSK |
Eingelegt |
FSP |
2 |
12.12.2016, 17:30 |
1 |
2 |
12.12.2016, 17:32 |
3 |
3 |
18.12.2016, 09:00 |
2 |
|
|
PS |
Name |
1 |
Mantel |
2 |
Waschpulver |
3 |
Gürtel |
|
Okay, die Tabelle »Produkt« ist extrem einfach gehalten, sie enthält die Namen der angebotenen Produkte
mit einer laufenden Nummer, die als Primärschlüssel verwendet werden kann.
Die Warenkorb-Tabelle dagegen sieht ziemlich merkwürdig aus.
Soviel sei gesagt: jede Zeile (also jedes Entity des Warenkorbs) ist genau ein eingelegter Artikel.
Also besteht diese Tabelle aus eingelegten Artikeln.
Die Warenkorb-Tabelle
Nun wird es Zeit, mal diese komische Tabelle zu betrachten. Die Spalte »Eingelegt« beschreibt,
zu welchem Zeitpunkt ein Artikel in den Warenkorb gelegt wurde.
Aber wo steht, um welchen Artikel es sich
handelt?
Da jedes Produkt durch seinen Primärschlüssel eindeutig unterschieden wird, genügt es, den Primärschlüssel
des Produkts anzugeben, und der steht in der Spalte FSP. FSP ist nur die Abkürzung von »Fremdschlüssel des Produkts«.
Damit ist klar, dass
-
am 12.12.2016 um 17:30 Uhr ein Mantel eingelegt wurde
(FSP:1 ist ein Wert aus der Spalte PS von Produkt, und da ist 1 der Mantel);
- und am 18.12.2016 um 09:00 Uhr Waschpulver
(3
in Spalte FSP ist gleich der 3
in Spalte PS von Produkt) .
Werte von Primärschlüsseln aus anderen Relationen werden Fremdschlüssel (Foreign Key)
genannt.
FSK steht als Abkürzung für »Fremdschlüssel des Kunden«, und daran ist zu erkennen, dass Kunde
shoppingsqueen
(Primärschlüsselwert: 2
) zweimal zugeschlagen hat, nämlich einen Mantel und
einen Gürtel in den Warenkorb gelegt hat.
Spätestens jetzt erkennt man: Diese Tabelle Warenkorb enhält ja die Einlagen der Warenkörbe aller Kunden!
Das sieht ja aus, als gäbe es nur einen einzigen Warenkorb für alle Kunden. Ist denn das richtig?
Es ist richtig! Das wird später verständlich, wenn wir mit unserem Datenbestand arbeiten werden.
Beziehungskisten
Die so getrennt notierten Relationen wären sinnlos, wenn es zwischen ihnen nicht Beziehungen gäbe;
englischer Begriff: Relationship. Und dieses Beziehungen betrachten wir mal genauer, bevor wir
uns dem Warenkorb weiter widmen.
- Dazu stellen wir uns gedanklich auf die Kunden-Tabelle und fragen:
Darf ein Kunde mehrere Produkte in den Warenkorb legen? Antwort: ja
(nein wäre geschäftsschädigend)
Wir halten fest: mehrere; mathematisch n
Produkte.
- Nun stellen wir uns auf die Warenkorb-Tabelle und fragen:
Gehört eine Warenkorbeinlage mehreren Kunden? Antwort: nein
(sonst würde ich vielleicht bezahlen was andere einkaufen)
Wir halten fest: nur 1 Kunde
Damit steht fest: zwischen Kunde und Warenkorb gibt es eine
1 zu n
- Beziehung
Dass zwischen Produkt und Warenkorb auch eine 1 zu n
- Beziehung besteht, kann man jetzt
leicht selbst festellen:
Denn eine Warenkorbeinlage kann nur ein Produkt sein, aber das gleiche (nicht dasselbe)
Produkt können auch andere gekauft haben, kann also in mehreren Warenkorbeinlagen vorkommen.
Zeichnen wir das auf, ergibt sich folgendes ERM (Entity-Relationship-Modell) unseres gedachten Datenbestands:
In einem ERM sind alle Tabellen über 1 zu n
- Beziehungen direkt oder
indirekt miteinander verbunden.