Das Entity-Relationship-Datenmodell , auch ER genannt , ist eines der verschiedenen Datenmodelle, die Sie verwenden können, um über Ihre Daten nachzudenken.
Insbesondere ist es ein konzeptionelles Datenmodell , da es nicht an eine bestimmte Implementierung gebunden ist. Das ist eine Aufgabe, die dem logischen Datenmodell überlassen wird.
Das ER-Datenmodell ist so allgemein, so hoch, dass es von einer Vielzahl völlig unterschiedlicher Arten von Datenbanken implementiert werden kann.
Das ist großartig, weil Sie nicht an die Implementierungsdetails denken, sondern nur an Ihre Daten und deren Organisation . Und dabei sind Sie gezwungen, das Problem auf eine Weise zu analysieren, an die Sie vorher nicht gedacht haben.
Ich finde ER-Diagramme großartig, um Ihnen bei der Analyse eines Szenarios zu helfen, in dem Daten involviert sind.
Das ER-Modell bietet Ihnen die Werkzeuge, um mithilfe einer grafischen Notation alle Daten darzustellen, die Sie modellieren müssen, die Beziehungen zwischen den verschiedenen Arten von Daten und die damit verbundenen Informationen.
Ein ER-Modell besteht aus zwei Elementen:
- die Entitäten
- die Beziehungen
Entitäten sind Datentypen wie Gegenstände oder Personen, die gemeinsame Eigenschaften haben.
Beziehungen sind die Beziehungen zwischen Entitäten.
Lassen Sie mich Ihnen ein Beispiel geben, lassen Sie uns über Bücher und ihre Autoren sprechen. Wir haben 2 Entitäten :
- Buch
- Autor
Ein bestimmtes Buch ist eine Instanz der Buchentität.
Da wir 2 Entitäten haben, haben wir 2 Beziehungen zwischen ihnen. Einer ist die Beziehung zwischen einem einzelnen Buch und der Entität des Autors. Eine davon ist die Beziehung zwischen einem einzelnen Autor und der Entität Bücher. Wenn wir darüber nachdenken, hätten wir:
- Ein Buch hat einen Autor
- ein Autor kann viele verschiedene Bücher schreiben
Die visuelle Notation für Entitäten
Anhand dieses einfachen Beispiels können wir mit der Einführung der visuellen Notation beginnen, die uns bei der Erstellung des ER-Datenmodells unseres Szenarios helfen wird.
Hinweis:Es gibt viele verschiedene Möglichkeiten, ER-Diagramme zu zeichnen. Ich werde das verwenden, das meiner Meinung nach , ist visueller und sinnvoller.
Entitäten werden als Rechtecke dargestellt, mit etwas Text darin, um sie zu identifizieren:
Die visuelle Notation für Beziehungen
Die Beziehung zwischen Entitäten wird in ihrer einfachsten Form dargestellt, indem eine Linie verwendet wird, die zwei Beziehungen verbindet, und eine Raute mit etwas Text darin, um die Art der Beziehung zu identifizieren:
Beachten Sie, dass ich die beiden Beziehungen „Buch hat Autor“ und „Autor schrieb Buch“ nicht erstellt habe. Ich habe zwischen einem Buch und einem Autor eine einzelne Beziehung „autorisiert“ erstellt.
Kardinalitäten
Sobald wir eine Beziehung haben, müssen wir jetzt die beteiligten Zahlen angeben. Im Moment haben wir viele Fragen:
- Wie viele Autoren kann ein Buch haben?
- Kann ein Autor mehrere Bücher schreiben?
- Muss ein Autor mindestens ein Buch schreiben, um als Autor bezeichnet zu werden?
- Kann ein Buch von mehreren Autoren geschrieben werden?
- Kann ein Buch ohne mindestens einen Autor existieren?
All das sind gute Fragen, und in diesem Fall denke ich, dass die Antworten ziemlich offensichtlich sind. Und wenn die Antwort nicht offensichtlich ist, können Sie über das Problem nachdenken und Ihre eigenen Einschränkungen hinzufügen.
Es gibt verschiedene Möglichkeiten, Kardinalitäten in einem Diagramm visuell anzuzeigen. Einige ziehen es vor, die Form der Linie zu ändern, wenn sie mit einer Entität verknüpft ist.
Ich bevorzuge Zahlen, die machen die Sache klarer:
Die obigen Zahlen bedeuten Folgendes:Ein Buch kann von einem oder mehreren Autoren verfasst werden. n bedeutet eine beliebige Anzahl von Elementen.
Und ein Autor kann von 0 Büchern (vielleicht schreibt er gerade eines) bis zu einer unendlichen Anzahl von Büchern verfasst haben.
Die erste wird als Null-zu-Viele-Beziehung bezeichnet . Die zweite ist eine Eins-zu-Viele-Beziehung .
Wir können auch haben:
- Eins-zu-Eins-Beziehungen
- viele-zu-viele-Beziehungen
- Null-zu-Eins-Beziehungen
Attribute
Jede Entität kann ein oder mehrere Attribute haben.
Nehmen wir an, wir verwenden die obige Beziehung in einer Buchhandlung. Jeder Autor hat einen Namen, eine Biografie, eine Website-URL.
Jedes Buch hat einen Titel, einen Verlag, ein Erscheinungsjahr, eine ISBN. Der Herausgeber könnte auch eine Entität sein, wenn wir wollen. Wir können es aber auch als Attribut eines Buches definieren.
So können wir die obigen Informationen darstellen:
Identifier-Attribute
Entitäten müssen durch einen eindeutigen Schlüssel identifiziert werden. Die Buchentität kann durch das ISBN-Attribut eindeutig identifiziert werden. Jedes Buch hat eine einzige ISBN (wenn man bedenkt, dass wir kein einzelnes Exemplar eines Buches darstellen, sondern einen „Buchtitel“).
Wir identifizieren die Primärschlüsselattribute, indem wir ihnen zugrunde liegen:
Der Autor hingegen hat derzeit keine eindeutige Kennung. Zwei Autoren können denselben Namen haben.
Wir müssen daher ein eindeutiges Schlüsselattribut hinzufügen. Zum Beispiel eine id Attribut:
Bezeichnerattribute können sich über mehrere Attribute erstrecken.
Beispielsweise identifizieren die Pass-ID und das Land des Autors die Person eindeutig und könnten die id ersetzen Attribut, das wir hinzugefügt haben:
Welche soll man wählen? Es kommt darauf an, was in Ihrer Bewerbung sinnvoller ist. Wenn wir eine Buchhandlung modellieren, können wir nicht erwarten, die Länder- und Pass-ID aller Buchautoren zu haben. Wir verwenden daher eine zufällige id Wir werden jeden Autor auswählen und mit ihm in Verbindung bringen.
Beziehungsattribute
Attribute sind nicht eindeutig für Entitäten. Relationen können auch Attribute haben.
Stellen Sie sich vor, wir müssen eine Bibliothek modellieren. Zusätzlich zu den Buch- und Autorenentitäten führen wir jetzt die Leserentität ein , eine Person, die sich das Buch ausleiht, um es zu lesen. Wir nehmen seinen Namen und seine Ausweisnummer, wenn er es ausleiht:
Aber wir vermissen immer noch Informationen. Wir müssen wissen, wann die Person das Buch ausgeliehen hat und wann sie es zurückgegeben hat, damit wir die Informationen über die gesamte Geschichte eines bestimmten Buchs in unserer Bibliothek speichern können. Diese Informationen gehören weder dem Buch noch dem Leser; es gehört zur Relation:
Schwache Entitäten
Wir haben oben über Primärschlüssel gesprochen und wie die Hilfe dabei hilft, eine Entität eindeutig zu identifizieren.
Einige Entitäten sind für ihre Existenz von anderen Entitäten abhängig und werden als schwache Entitäten bezeichnet .
Angenommen, wir müssen Bestellungen für einen Online-Shop modellieren.
Für jede Bestellung speichern wir die Bestell-ID, die bei 1 beginnt und sich im Laufe der Zeit erhöht, das Datum und die Uhrzeit der Bestellung sowie die Informationen über den Kunden, damit wir wissen, wem wir die Rechnung stellen und wohin wir sie versenden.
Dann müssen wir auch wissen, was sie bestellt haben. Wir erstellen eine schwache Entität „bestellter Artikel“, die jeden Artikel im Warenkorb zum Zeitpunkt des Bezahlvorgangs darstellt.
Diese Entität speichert den Artikelpreis zum Zeitpunkt des Bezahlvorgangs (wenn wir also den Preis der im Angebot befindlichen Produkte ändern, hat dies keine Auswirkungen auf die bereits aufgegebenen Bestellungen), die Menge der bestellten Artikel und die gewählten Optionen. Angenommen, wir verkaufen T-Shirts, daher müssen wir die Farbe und Größe des bestellten T-Shirts speichern.
Es ist eine schwache Entität, da eine bestellte Artikelentität nicht ohne eine Bestellentität existieren kann.
Rekursive Beziehungen
Eine Entität kann eine rekursive Beziehung zu sich selbst haben. Angenommen, wir haben eine Person-Entität. Wir können die Eltern-Kind-Beziehung folgendermaßen modellieren:
Eine Person kann 0 bis n Kinder haben, ein Kind hat 2 Eltern (im einfachsten Fall).
ISA-Beziehungen
ISA steht für IS-A und ist eine Möglichkeit, Verallgemeinerungen im ER-Modell zu modellieren.
Wir verwenden es, um ähnliche Einheiten unter einem gemeinsamen Dach zu gruppieren. Zum Beispiel können ein Autor und ein Leser im Falle des Beispiels Bücher und Bibliothek unter Verwendung einer Person-Entität verallgemeinert werden.
Sie haben beide einen Namen, also extrahieren wir den Namen bis zur Personenentität und verwalten nur die Besonderheiten, ein Autor oder Leser in der entsprechenden Entität zu sein:
Nicht-binäre Beziehungen
Nicht jede Beziehung ist strikt binär. Nehmen wir ein Unterrichtsszenario.
Heute um 10:00 Uhr findet in einem Raum der Schule eine Unterrichtsstunde mit einem Lehrer statt, der mit einer Klasse über Physik spricht.
Eine Unterrichtsstunde wird also zu einer bestimmten Tageszeit erteilt, sie umfasst ein Fach, einen Lehrer, eine Klasse und einen Raum.
Wir können es folgendermaßen modellieren:
