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.

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

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:

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.

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?

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?

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.