Eine Entität mit einem Attribut
Eine Entität kann definiert werden als ein Ding, das zu einer unabhängigen Existenz fähig ist und eindeutig identifiziert werden kann. Eine Entität ist eine Abstraktion von den Komplexitäten einer Domäne. Wenn wir von einer Entität sprechen, sprechen wir normalerweise von einem Aspekt der realen Welt, der von anderen Aspekten der realen Welt unterschieden werden kann.
Eine Entität ist ein Ding, das entweder physisch oder logisch existiert. Eine Entität kann ein physisches Objekt wie ein Haus oder ein Auto sein (sie existieren physisch), ein Ereignis wie ein Hausverkauf oder ein Autoservice, oder ein Konzept wie eine Kundentransaktion oder eine Bestellung (sie existieren logisch – als Konzept). Obwohl der Begriff Entität am häufigsten verwendet wird, sollten wir nach Chen eigentlich zwischen einer Entität und einem Entity-Typ unterscheiden. Ein Entity-Typ ist eine Kategorie. Eine Entität ist genau genommen eine Instanz eines bestimmten Entitätstyps. Von einem Entity-Typ gibt es normalerweise viele Instanzen. Da der Begriff Entitätstyp etwas sperrig ist, neigen die meisten Leute dazu, den Begriff Entität als Synonym für diesen Begriff zu verwenden
Entitäten kann man sich als Substantive vorstellen. Beispiele: ein Computer, ein Mitarbeiter, ein Lied, ein mathematisches Theorem usw.
Eine Beziehung beschreibt, wie Entitäten miteinander in Beziehung stehen. Beziehungen kann man sich als Verben vorstellen, die zwei oder mehr Substantive miteinander verbinden. Beispiele: eine „owns“-Beziehung zwischen einer Firma und einem Computer, eine „supervises“-Beziehung zwischen einem Mitarbeiter und einer Abteilung, eine „performs“-Beziehung zwischen einem Künstler und einem Song, eine „proves“-Beziehung zwischen einem Mathematiker und einer Vermutung usw.
Der oben beschriebene linguistische Aspekt des Modells wird in der deklarativen Datenbankabfragesprache ERROL verwendet, die Konstrukte der natürlichen Sprache nachahmt. Die Semantik und Implementierung von ERROL basiert auf der Reshaped Relational Algebra (RRA), einer relationalen Algebra, die an das Entity-Relationship-Modell angepasst ist und dessen linguistischen Aspekt erfasst.
Entitäten und Beziehungen können beide Attribute haben. Beispiele: eine Entität „Mitarbeiter“ kann ein Attribut „Sozialversicherungsnummer“ (SSN) haben, während eine Beziehung „bewiesen“ ein Attribut „Datum“ haben kann.
Alle Entitäten außer schwachen Entitäten müssen eine minimale Menge von eindeutig identifizierenden Attributen haben, die als eindeutiger/primärer Schlüssel verwendet werden können.
Entitäts-Beziehungs-Diagramme zeigen keine einzelnen Entitäten oder einzelne Instanzen von Beziehungen. Vielmehr zeigen sie Entitätsmengen (alle Entitäten desselben Entitätstyps) und Beziehungsmengen (alle Beziehungen desselben Beziehungstyps). Beispiele: ein bestimmtes Lied ist eine Entität; die Sammlung aller Lieder in einer Datenbank ist eine Entitätsmenge; die Essensbeziehung zwischen einem Kind und seinem Mittagessen ist eine einzelne Beziehung; die Menge aller solcher Kind-Mittagessen-Beziehungen in einer Datenbank ist eine Beziehungsmenge.Mit anderen Worten, eine Beziehungsmenge entspricht einer Relation in der Mathematik, während eine Beziehung einem Mitglied der Relation entspricht.
Bestimmte Kardinalitätsbeschränkungen auf Beziehungsmengen können ebenfalls angegeben werden.
Mapping natürlicher Sprache
Chen schlug die folgenden „Faustregeln“ für das Mapping natürlichsprachlicher Beschreibungen in ER-Diagramme vor: „Englisch, Chinesisch und ER-Diagramme“ von Peter Chen.
| Englische Grammatikstruktur | ER-Struktur |
|---|---|
| Common Substantiv | Entitätstyp | Proper Substantiv | Entität | Transitives Verb | Beziehungstyp |
| Intransitives Verb | Attribut-Typ |
| Adjektiv | Attribut für Entität |
| Adverb | Attribut für Beziehung |
Die physische Ansicht zeigt, wie die Daten tatsächlich gespeichert werden.
Beziehungen, Rollen und KardinalitätenBearbeiten
In Chens Originalarbeit gibt er ein Beispiel für eine Beziehung und ihre Rollen. Er beschreibt eine Beziehung „Ehe“ und ihre zwei Rollen „Ehemann“ und „Ehefrau“.
Eine Person spielt in einer Ehe (Beziehung) die Rolle des Ehemannes und eine andere Person spielt in der (gleichen) Ehe die Rolle der Ehefrau. Diese Wörter sind Substantive. Das ist keine Überraschung; um Dinge zu benennen, braucht man ein Substantiv.
Chen hat seine Terminologie auch auf frühere Ideen angewendet. Die Linien, Pfeile und Krähenfüße mancher Diagramme verdanken sich eher den früheren Bachman-Diagrammen als Chens Beziehungsdiagrammen.
Eine weitere gängige Erweiterung von Chens Modell ist es, Beziehungen und Rollen als Verben oder Phrasen zu „benennen“.
RollenbenennungBearbeiten
Es hat sich auch eingebürgert, Rollen mit Phrasen wie ist der Besitzer von und ist im Besitz von zu benennen. Korrekte Substantive sind in diesem Fall Besitzer und Besitz. So spielt Person die Rolle des Besitzers und Auto die Rolle des Besitzes, anstatt Person spielt die Rolle von, ist der Besitzer von usw.
Die Verwendung von Substantiven hat einen direkten Nutzen bei der Generierung von physischen Implementierungen aus semantischen Modellen. Wenn eine Person zwei Beziehungen zu einem Auto hat, dann ist es möglich, Namen wie Besitzer_Person und Fahrer_Person zu generieren, die sofort aussagekräftig sind.
KardinalitätenBearbeiten
Änderungen an der ursprünglichen Spezifikation können von Vorteil sein. Chen beschrieb die Look-across-Kardinalitäten. Nebenbei bemerkt, die Barker-Ellis-Notation, die im Oracle Designer verwendet wird, verwendet same-side für minimale Kardinalität (analog zur Optionalität) und Rolle, aber look-across für maximale Kardinalität (der Krähenfuß).
In Merise, Elmasri & Navathe und anderen gibt es eine Präferenz für same-side für Rollen und sowohl minimale als auch maximale Kardinalitäten. Neuere Forscher (Feinerer, Dullea et al.) haben gezeigt, dass dies kohärenter ist, wenn es auf n-äre Beziehungen der Ordnung größer als 2 angewandt wird.
Bei Dullea et al. liest man „Eine ‚look across‘-Notation, wie sie in der UML verwendet wird, repräsentiert nicht effektiv die Semantik von Partizipationsbeschränkungen, die Beziehungen auferlegt werden, deren Grad höher als binär ist.“
Bei Feinerer heißt es „Probleme entstehen, wenn wir mit der look-across-Semantik arbeiten, wie sie für UML-Assoziationen verwendet wird. Hartmann untersucht diese Situation und zeigt, wie und warum verschiedene Transformationen scheitern.“ (Wobei die erwähnte „Reduktion“ fadenscheinig ist, da die beiden Diagramme 3.4 und 3.5 in Wirklichkeit gleich sind) und auch „Wie wir auf den nächsten Seiten sehen werden, führt die look-across-Interpretation mehrere Schwierigkeiten ein, die die Erweiterung einfacher Mechanismen von binären auf n-äre Assoziationen verhindern.“
Chens Notation für die Modellierung von Entity-Beziehungen verwendet Rechtecke, um Entity-Sets darzustellen, und Rauten, um Beziehungen darzustellen, die für Objekte erster Klasse geeignet sind: Sie können eigene Attribute und Beziehungen haben. Wenn eine Entitätsmenge an einer Beziehungsmenge beteiligt ist, werden sie mit einer Linie verbunden.
Attribute werden als Ovale gezeichnet und sind mit einer Linie mit genau einer Entitäts- oder Beziehungsmenge verbunden.
Kardinalitätsbeschränkungen werden wie folgt ausgedrückt:
- Eine Doppellinie zeigt eine Teilnahmebeschränkung an, Totalität oder Surjektivität: alle Entitäten in der Entitätsmenge müssen an mindestens einer Beziehung in der Beziehungsmenge teilnehmen;
- Ein Pfeil von der Entitätsmenge zur Beziehungsmenge zeigt eine Schlüssel-Beschränkung an, d. h.d. h. Injektivität: jede Entität der Entitätsmenge kann an höchstens einer Beziehung in der Beziehungsmenge teilnehmen;
- eine dicke Linie zeigt beides an, d. h. Bijektivität: jede Entität in der Entitätsmenge ist an genau einer Beziehung beteiligt.
- ein unterstrichener Name eines Attributs zeigt an, dass es ein Schlüssel ist: zwei verschiedene Entitäten oder Beziehungen mit diesem Attribut haben immer verschiedene Werte für dieses Attribut.
Attribute werden oft weggelassen, da sie ein Diagramm unübersichtlich machen können; andere Diagrammtechniken listen Entitätsattribute oft innerhalb der für Entitätssätze gezeichneten Rechtecke auf.
Verwandte Techniken der Diagrammkonvention:
- Bachman-Notation
- Barker-Notation
- EXPRESS
- IDEF1X
- Crow’s Foot-Notation (auch Martin-Notation)
- (min, max)-Notation von Jean-Raymond Abrial aus dem Jahr 1974
- UML-Klassendiagramme
- Merise
- Objekt-Rollen-Modellierung
Crow’s foot notationEdit
Crow’s foot notation, deren Anfänge auf einen Artikel von Gordon Everest (1976) zurückgehen, wird in der Barker-Notation, der Structured Systems Analysis and Design Method (SSADM) und in der Informationstechnik verwendet. Crow’s-Foot-Diagramme stellen Entitäten als Kästen und Beziehungen als Linien zwischen den Kästen dar. Unterschiedliche Formen an den Enden dieser Linien repräsentieren die relative Kardinalität der Beziehung.
Die Crow’s-Foot-Notation wurde in der Beratungspraxis CACI verwendet. Viele der Berater bei CACI (darunter Richard Barker) wechselten später zu Oracle UK, wo sie die frühen Versionen der CASE-Tools von Oracle entwickelten und die Notation einem breiteren Publikum bekannt machten.
Bei dieser Notation können Beziehungen keine Attribute haben. Wo es notwendig ist, werden Beziehungen zu eigenständigen Entitäten erhoben: Wenn es zum Beispiel notwendig ist, zu erfassen, wo und wann ein Künstler einen Song performt hat, wird eine neue Entität „Performance“ eingeführt (mit Attributen, die Zeit und Ort widerspiegeln), und die Beziehung eines Künstlers zu einem Song wird zu einer indirekten Beziehung über die Performance (artist-performs-performance, performance-features-song).
Drei Symbole werden verwendet, um die Kardinalität darzustellen:
- der Ring steht für „Null“
- der Strich steht für „Eins“
- der Krähenfuß steht für „Viele“ oder „Unendlich“
Diese Symbole werden paarweise verwendet, um die vier Arten von Kardinalität darzustellen, die eine Entität in einer Beziehung haben kann. Die innere Komponente der Notation steht für das Minimum und die äußere Komponente für das Maximum.
- Ring und Strich → Minimum null, Maximum eins (optional)
- Strich und Bindestrich → Minimum eins, Maximum eins (zwingend)
- Ring und Krähenfuß → Minimum null, maximal viele (optional)
- Bindestrich und Krähenfuß → minimal eins, maximal viele (obligatorisch)
ModellierbarkeitsproblemeBearbeiten
Bei der Verwendung einer modellierten Datenbank können Benutzer auf zwei bekannte Probleme stoßen, bei denen die zurückgegebenen Ergebnisse etwas anderes bedeuten als die vom Abfrageautor angenommenen Ergebnisse.
Das erste ist die „Fächerfalle“. Sie tritt bei einer (Master-)Tabelle auf, die mit mehreren Tabellen in einer Eins-zu-Viel-Beziehung verknüpft ist. Das Problem hat seinen Namen von der Art und Weise, wie das Modell aussieht, wenn es in einem Entity-Relationship-Diagramm gezeichnet wird: Die verknüpften Tabellen „fächern“ von der Master-Tabelle aus auf. Diese Art von Modell sieht ähnlich aus wie ein Sternschema, eine Art von Modell, das in Data Warehouses verwendet wird. Wenn Sie versuchen, Summen über Aggregate mit Standard-SQL über die Master-Tabelle zu berechnen, können unerwartete (und falsche) Ergebnisse auftreten. Die Lösung ist entweder die Anpassung des Modells oder der SQL. Dieses Problem tritt meist in Datenbanken für Entscheidungsunterstützungssysteme auf, und Software, die solche Systeme abfragt, enthält manchmal spezielle Methoden zur Behandlung dieses Problems.
Das zweite Problem ist eine „Abgrundfalle“. Eine Abgrundfalle tritt auf, wenn ein Modell das Vorhandensein einer Beziehung zwischen Entitätstypen suggeriert, aber der Pfad zwischen bestimmten Entitätsvorkommen nicht existiert. Ein Gebäude hat z. B. einen oder mehrere Räume, die null oder mehr Computer enthalten. Man würde erwarten, dass man das Modell abfragen kann, um alle Computer im Gebäude zu sehen. Computer, die derzeit keinem Raum zugewiesen sind (weil sie gerade repariert werden oder woanders stehen), werden jedoch nicht in der Liste angezeigt. Eine weitere Relation zwischen Gebäude und Computern wird benötigt, um alle Computer im Gebäude zu erfassen. Dieses letzte Modellierungsproblem ist darauf zurückzuführen, dass nicht alle Beziehungen, die in der realen Welt existieren, im Modell erfasst werden. Siehe Entity-Relationship-Modellierung 2 für Details.