Das Entity-Relationship-Modell. Schnell und einfach erklärt.
Patrick Boekhoven
https://www.youtube.com/watch?v=fVbYB_34v-E

Transkript (automatisch erstellt)

0:00 Heute schauen wir uns an was ein Entity Relationship Model bzw eine ER-Modell ist. Wenn ihr noch nicht dabei seid, dann gerne ein Abo da um keine weiteren Videos zu verpassen.
0:17 Aber jetzt soll es es erstmal mit dem Video losgehen. Zu Beginn schauen wir uns erstmal an wofür wir ein ER-Modell eigentlich nutzen können. Wir brauchen das ER-Modell dafür, um
0:28 eine Datenbank zuerst einmal zu planen. Wir wissen, dass eine gute Planung als Informatiker viel wert ist. Wer vernünftig plant, der wird am Ende belohnt. Und deswegen nutzen wir das ER-Modell.
0:38 Es lässt sich einerseits in der Konzeptionsphase für die Kommunikation mit den Anwender nutzen, damit wir eine Grundlage haben um über die Fachlichkeiten zu sprechen.
0:50 Andererseits aber auch in der Implementierungsphase als eine Art Umsetzungsplan. Wir dokumentieren also, was wir wie in unseren Implementierung umsetzen möchten. Zuerst einmal schauen wir uns die Elemente des
1:03 ER-Modells Schritt für Schritt an, um dann am Ende ein komplettes ER-Modell zu erhalten. Das ganze schauen wir uns anhand der hyperEDV, also einem kleinen Computerladen an, der eine
1:16 Datenbank benötigt um seine Bestellungen und seine Kunden abzuspeichern. Als erstes zentrales Element im ER-Modell gucken wir uns die Entität an. Diese wird als Rechteck dargestellt und
1:27 darunter verstehen wir ein Objekt aus der realen Welt, über das wir Informationen abspeichern wollen. Entitäten bei unserer hyperEDV können zum Beispiel ein Kunde, ein Artikel oder auch nur eine Bestellung sein.
1:39 Jeder dieser Entitäten stellt am ende in unserer Datenbank einen einzelnen Datensatz dar. Beispielsweise stellen wir uns den Kunden Ludger Sievert der schon häufiger bei der hyperEDV bestellt hat.
1:49 Und der findet sich in unserer Datenbank als ein Datensatz wieder und somit auch als eine Entität. Als nächstes wichtiges Element schauen wir uns die Beziehung an. Diese wird durch
2:01 eine Raute dargestellt und sie verbindet jeweils zwei Entitäten miteinander. In die Raute schreiben wir immer ein Verb hinein, welches angibt, wie die Entitäten miteinander verbunden sind.
2:12 Kommen wir jetzt einmal zur hyperEDV zurück. Hier tätigt ein Kunde eine Bestellung und eine Bestellung selber enthält verschiedene Artikel. Wenn man das ganze jetzt anschaut besteht unser ER-Modell jetzt schon
2:27 aus verschiedenen Entitäten und Beziehungen. Als nächste schauen wir uns das Attribut Unter einem Attribut verstehen wir bestimmte Eigenschaften die unsere Entitäten besitzen.
2:40 Das Attribut stellt sozusagen einen Bauplan dar, aus denen die Entitäten zusammengesetzt sind. Schauen uns das erst mal für den Kunden an. Für unsere Kunden könnte das beispielsweise ein Vor- und ein Nachnane sein.
2:52 Wichtig ist auch für unseren Kunden, dass jeder Kunde eine Kundennummer hat. Diese dient als Primärschlüssel und dieser wird unterstrichen dargestellt.
3:06 Die Kundennummer ist dafür da zweifelsfrei unsere Kunden zu identifizieren. Bleiben wir mal bei unseren Kunden Ludger Sievert. Der hat eine Kundennummer und die ist einzigartig. Die kriegt auch kein anderer Kunde. Und dadurch kann jeder
3:18 Kunde durch seine Kundennummer, also auch unser Ludger Sievert, zweifelsfrei identifiziert werden. Jede Tabelle brauch einen Primärschlüssel. Und der kann aus einem Attribut oder aber auch aus mehreren Attributen bestehen.
3:28 Als nächstes schauen wir uns die Bestellung an. Und hier eignen sich als Attribute die Bestellnummer und das Datum . Die Bestellnummer ist wieder unterstrichen und sie hat dieselbe Funktion wie die Artikelnummer beim Artikel.
3:40 Und dient als Primärschlüssel da die Bestellnummer für jede Bestellung einzigartig ist. Als Attribute für unsere Artikel können wir uns
3:51 hier die Artikelnummer als Primärschlüssel vorstellen die Bezeichnung und den Preis Natürlich ist eine Datenbank im realen leben deutlich komplexer. Aber wir gucken uns das hier anhand einiger Beispiele an,
4:02 wo wir etwas abstrahieren müssen. Bedeutet, dass wir die Komplexität etwas runterschrauben. Komplett ist unser ER-Modell aber immer noch nicht. Es fehlen noch die sogenannten Kardnalitäten.
4:14 Darunter verstehen wir die Mengenangaben für unsere Beziehung. Also wie viele Entitäten eines Entitättyps mit genau einer Entität des anderen and Entitättyps in Beziehung stehen können oder sogar müssen.
4:28 Hier existieren verschiedene arten der Darstellung. Die bekannteste ist dabei die Chen Notation. Und diese auch gebräuchlicher Standard. Bei dieser unterscheiden
4:39 wir zwischen drei möglichen Beziehungen. Als erstes die 1:n Beziehung, wo jeder Datensatz aus Tabelle A höchstens einem Datensatz aus Tabelle B zugeordnet ist. Beispielsweise können wir uns
4:51 vorstellen, dass wir einen Ausweis haben und der ist einer Person zugeordnet. Ein Ausweis kann nicht zu mehreren Personen gehören und in der Regel kann eine Person auch nicht mehrere ausweise haben.
5:02 Zumindest keine gültigen Ausweise. Jetzt gucken wir uns noch die 1:n Beziehung an, wo in Tabelle A ein, kein oder mehrere passende Datens ätze in Tabelle B zugeordnet sein können.
5:16 Aber einen Datensatz und Tabelle b ist nie mehr als einen Datensatz der Tabelle A zugeordnet. Dafür nehmen wir mal folgendes Beispiel: Ein Schüler ist einer Klasse zugeordnet. Also ein Schüler geht immer in eine Klasse.
5:28 Eine klasse wiederum hat aber in der Regel mehrere Schüler, beziehungsweise einer Klasse können mehrere Schüler zugeordnet sein. Zum Schluss schauen wir uns doch die n:n Beziehung an.
5:42 Also die viele zu viele Beziehung. Hier können auf beiden Seiten beliebig viele Entitäten miteinander in Verbindung stehen. Da sei es Beispiel Lehrer und Klasse zu nennen. Ich als Lehrer habe in der Regel
5:53 mehrere Klassen und die Klassen haben auch mehrere Lehrer. Und nun wieder zurück zu unserer Datenbank in der wir unser frisch erworbenes wissen anwenden können. Schauen wir uns jetzt unsere Bestellung an,
6:05 dann wird schnell klar, unsere Bestellung selber hat immer genau einen Kunden. Denn eine Bestellung tätigt immer genau eine Person und bezahlt diese auch. Deshalb entscheiden wir wir uns
6:15 an dieser stelle als Kardinalität für die 1. Die 1 schreiben wir gegenüber von der Bestellung, also an die Tabelle Kunde. Unsere Kunden hingegen können mehrere Bestellungen getätigt haben.
6:27 Sicherlich gibt es Shops wo ihr schon mehrfach bestellt habt. Ein kunde kann aber auch nur eine Bestellung oder auch keine Bestellungen getätigt haben. Also entscheiden wir uns an dieser Stelle für
6:38 das n als Kardinalität. Zu guter Letzt fehlt noch die Kardinalität für die Beziehung zwischen Artikel und Bestellung. Ein Artikel kann in mehreren Bestellungen auftauchen oder vielleicht, wenn es schlecht läuft, in einer oder in keiner Bestellung.
6:51 Also bietet sich logischerweise nur das n an. Und eine Bestellung kann mehrere Artikel enthalten. Optional natürlich auch nur einen.
7:02 Was für uns bedeutet, dass wir es jetzt mit einer n:m Beziehung zu tun haben. Und jetzt schauen wir noch einmal über das ganze Modell. Und wir sehen wir sind fertig. Wir haben verschiedene Entitäten,
7:15 wir haben verschiedene Attribute und wir haben Beziehungen. Und wir haben gleichzeitig unsere Kardinalitäten richtig gesetzt. Bedeutet, unsere hyperEDV hat eine kleine Datenbank, beziehungsweise
7:26 ein ER-Modell, was zu einer Datenbank werden kann. Das war mein Video zum ER-Model aus dem Bereich Datenbanken. Und wenn ihr Kritik habt, wenn ihr Anregungen habt, schreibt sie mir gerne in die Kommentare.
7:37 Ich freue mich natürlich immer über Kommentare, beziehungsweise. Macht's gut und bis zum nächsten mal.