ER-Modell
In der Informatik ist im Kontext des Datenbankdesigns das Entity-Relationship-Modell [1] (oder Entity-Assoziation- Modell ; häufiger ER-Modell ) ein theoretisches Modell zur konzeptuellen und grafischen Darstellung von Daten auf hohem Abstraktionsniveau . 1976 von Peter Chen formalisiert [2] .
Das Entity-Relationship-Modell wird häufig in der ersten Phase des Entwurfs einer Datenbank verwendet, in der es notwendig ist, die aus der Analyse einer bestimmten Domäne resultierenden Informationen in ein konzeptionelles Schema zu übersetzen, das als Entity-Relationship- Diagramm (oder ER-Diagramm ) bezeichnet wird ). [3]
Im Bereich des Datenbankdesigns gibt es drei unabhängige und aufeinander folgende Designebenen: konzeptionelles Design , logisches Design, physisches Design. Genau genommen ist das ER-Modell die Haupttechnik für die konzeptionelle Entwurfsphase, das relationale Modell für die logische Entwurfsphase. Erst in der letzten Phase des physikalischen Entwurfs werden die auf dem Markt vorhandenen Software- und Hardwareanwendungen , ob proprietär oder nicht, berücksichtigt.
Allgemeine Informationen
Das ER-Modell basiert auf einer Reihe von Konzepten, die der interessierenden Realität sehr nahe kommen: daher für Designer leicht verständlich (und allgemein auch für Nicht-Techniker als ausreichend verständlich und aussagekräftig angesehen), aber nicht auf Computern umsetzbar . Tatsächlich ist das Modell, obwohl es auf das Design von Datenbanken ausgerichtet ist, unabhängig von den spezifischen Kriterien der physischen Organisation persistenter Daten in IT-Systemen . Es gibt Techniken zum Übersetzen von Konzepten auf hoher Ebene (für Menschen besser verständlich) in Konzepte auf niedrigerer Ebene, die typisch für die verschiedenen logischen Modelle (zum Beispiel das relationale Modell ) sind, die in den verschiedenen existierenden DBMSs implementiert sind.
Das ER-Modell stellt seit langem (und vielleicht noch heute) einen der solidesten Ansätze zur Modellierung von Anwendungsdomänen im IT-Bereich dar; Aus diesem Grund wurde es auch oft außerhalb des Kontexts des Datenbankdesigns verwendet und diente als Referenzmodell für zahlreiche andere Modellierungsnotationen. Unter anderem wurde die OMT -Notation vom ER-Modell inspiriert und später in die UML überführt .
Durch einen Identifikations-Superschlüssel (Felder: Elterncode_ID, Kindcode_ID) stellt das Entity-Association-Schema einen Baumgraphen auf beliebig vielen Ebenen dar (insbesondere auch eine Stückliste ), wie er in der Computerwelt sehr verbreitet ist. Das Sunburst-Diagramm ermöglicht eine einfache und weit verbreitete grafische Darstellung hierarchischer Daten.
Die Hauptkonstrukte des Modells
Analyse der Hauptkonstrukte des ER-Modells: Entitäten, Assoziationen und Attribute.
Entität
Sie stellen Klassen von Objekten (Fakten, Dinge, Personen, ...) dar, die gemeinsame Eigenschaften und autonome Existenz zum Zweck der Anwendung von Zinsen haben. Ein Vorkommen einer Entität ist ein Objekt oder eine Instanz der Klasse, die die Entität darstellt. Wir sprechen hier nicht vom Wert, der das Objekt identifiziert, sondern vom Objekt selbst. Eine interessante Folge dieser Tatsache ist, dass ein Entitätsvorkommen unabhängig von den damit verbundenen Eigenschaften existiert. Darin unterscheidet sich das ER-Modell deutlich vom relationalen Modell, bei dem wir ein Objekt nicht darstellen können, ohne einige seiner Eigenschaften zu kennen.
In einem Diagramm hat jede Entität einen Namen, der sie eindeutig identifiziert, und wird grafisch durch ein Rechteck mit dem Namen der darin enthaltenen Entität dargestellt.
Assoziation
Assoziationen (auch Beziehungen genannt) stellen eine Verbindung zwischen zwei oder mehr Entitäten dar. Die Anzahl der verbundenen Einheiten wird durch den Assoziationsgrad angegeben: Ein gutes ER-System zeichnet sich durch eine Prävalenz von Assoziationen mit Grad zwei aus. Es ist möglich, eine Entität mit sich selbst zu binden (über eine Ringzuordnung) sowie dieselben Entitäten mit mehreren Zuordnungen zu binden.
Es wird normalerweise grafisch durch eine Raute dargestellt, die den Namen des Vereins enthält. Das Substantiv kann ein Verb sein, um eine Leserichtung anzugeben, oder es kann ein Substantiv sein, um keine Leserichtung anzugeben. Die neueste akademische und berufliche Orientierung neigt dazu, das Substantiv genau zu verwenden, um der Assoziation keine Richtung zu geben.
Attribute
Entitäten und Assoziationen können mit einer Reihe von Attributen beschrieben werden. Alle Objekte derselben Entitätsklasse (oder Assoziation) haben dieselben Attribute – das meinen wir, wenn wir von ähnlichen Objekten sprechen. Die Auswahl der Attribute spiegelt den Detaillierungsgrad wider, mit dem wir Informationen über Entitäten und Beziehungen darstellen wollen. Für jede Entitätsklasse oder Assoziation wird ein Schlüssel definiert. Der Schlüssel ist ein minimaler Satz von Attributen, der eine Instanz einer Entität oder Assoziation eindeutig identifiziert. Das Attribut wird mit einer Ellipse dargestellt, in der der Name des Attributs angegeben ist oder bei komplexen Diagrammen auch einfach nur der Name angegeben ist, möglicherweise in Übereinstimmung. Bei einem Primärschlüssel ist der Attributname unterstrichen oder eingekreist.
Andere Modellkonstrukte
Kardinalität von Assoziationen
Sie werden für jede an einer Assoziation beteiligte Entität angegeben und geben an, wie oft in einer Assoziation zwischen Entitäten ein Vorkommen einer dieser Entitäten mit Vorkommnissen der anderen an der Assoziation beteiligten Entitäten verknüpft werden kann (gibt die minimale und maximale Anzahl von Vorkommen an ).
Attributkardinalität
Es ist auch möglich, Kardinalitätseinschränkungen für Attribute mit zwei Zwecken zu definieren:
- Optionalität angeben;
- weisen auf mehrwertige Attribute hin.
Fehlt die Constraint-Spezifikation, was in den meisten Fällen der Fall ist, ist die Kardinalität des Attributs (1,1). Betrachten wir das folgende Beispiel:
Da die Kardinalitätseinschränkungsspezifikation im Namen fehlt, bedeutet dies, dass die Kardinalität (1,1) ist.
- (0,1) NumeroPatente bedeutet, dass ein Arbeitnehmer einen Führerschein haben kann, aber auch keinen, bzw. ein Arbeitnehmer höchstens einen Führerschein haben kann.
- (0, n) NumeroTelefono, bedeutet, dass ein Mitarbeiter viele Telefonnummern haben kann, er kann aber auch keine Telefonnummer haben.
- (1, n) TitleStudio bedeutet, dass ein Mitarbeiter viele Qualifikationen haben kann, aber mindestens eine haben muss.
Entitätskennungen
Sie stellen eine Teilmenge der Attribute einer Entität dar, die jedes Vorkommen derselben Entität eindeutig identifizieren. Ein Beispiel kann das Attribut CodiceFiscale der Entität CittadinoItaliano sein. Es ist nämlich bekannt, dass jeder Vorfall der Körperschaft von CittadinoItaliano, d. h. jeder Bürger mit Wohnsitz im Hoheitsgebiet der Italienischen Republik, anhand seiner Steuernummer eindeutig identifiziert werden kann. Dies bedeutet, dass es nicht zwei italienische Staatsbürger mit derselben Steuernummer geben kann (es sei denn, es liegt ein Fall von Homokodie vor ).
Verallgemeinerungen
Sie stellen logische Verknüpfungen dar, die zwischen zwei oder mehr Entitäten bestehen. Unter den beteiligten Einrichtungen stechen die folgenden hervor:
- eine und nur eine Muttergesellschaft;
- eine oder mehrere untergeordnete Entitäten.
Untergeordnete Entitäten sind "Sonderfälle" der übergeordneten Entität. Jedes Attribut der übergeordneten Entität ist auch ein Attribut von untergeordneten Entitäten, aber untergeordnete Entitäten können Attribute haben, die sie von ihrem Vater und ihren Geschwistern unterscheiden. Folgendes Beispiel zeigt das:
- jede Person wird durch eine Steuernummer identifiziert und ist durch einen Nachnamen, einen Vornamen und ein Alter gekennzeichnet;
- jede Person unterscheidet sich in Mann oder Frau;
- Auch die militärische Stellung kann beurteilt werden.
Generalisierungen werden in "total" und "partial" unterteilt. Eine Verallgemeinerung ist total, wenn die Vereinigung der Teilmengen der Kinder den ganzen Vater bildet. Beispielsweise ist die Verallgemeinerung von Person zu Mann oder Frau total, da alle Menschen entweder Männer oder Frauen sind, daher erhalten wir durch Kombinieren der Teilmengen von Männern und Frauen die Menge von Personen. Eine Verallgemeinerung ist partiell, wenn andererseits die Vereinigung der Teilmengen der Kinder die Menge des Vaters nicht global identifiziert. Beispielsweise ist eine übergeordnete Entität Fortbewegungsmittel mit den untergeordneten Entitäten Fahrrad und Automobil eine partielle Verallgemeinerung, da es neben Fahrrädern und Autos auch andere Fortbewegungsmittel wie Mopeds, Züge, Schiffe etc. Die Vereinigung der Teilmengen Fahrrad und Auto reicht daher nicht aus, um die Elternmenge der Fortbewegungsmittel zu identifizieren.
Eine Verallgemeinerung kann auch „ausschließlich“ oder „überlappend“ sein. Eine Verallgemeinerung ist exklusiv, wenn die Schnittmenge der Teilmengen der Kinder leer ist; es wird stattdessen überlappt, wenn die Schnittmenge der Teilmengen der Kinder nicht leer ist. Eine übergeordnete Entität „Worker“ mit den untergeordneten Entitäten „Employee“ und „Student“ identifiziert eine sich überschneidende Verallgemeinerung, da es Mitarbeiter geben kann, die gleichzeitig Studenten sind. Zusammenfassend kann eine Verallgemeinerung lauten:
- total exklusiv (t, e);
- insgesamt überlagert (t, s);
- teilweise exklusiv (p, e);
- teilweise überlagert (p, s).
Manchmal können die Abkürzungen (t, e) und letzteres gerade angegeben in den ER-Schemata erscheinen, um Informationen über die Art der Verallgemeinerung hinzuzufügen; ihre Verwendung innerhalb des ER-Grafikschemas ist jedoch nicht bindend.
Datenmodell Entität – Attribut – Wert (EAV)
Ein Entity – Attribute – Value (EAV) Datenmodell wird vorteilhafterweise in Fällen verwendet, in denen die Datenbanken bestehen aus:
- einzelne Attribute des variablen Typs im Laufe der Zeit;
- Hunderte von Tabellen oder Kategorien von variabler Größe im Laufe der Zeit, die jedoch aus einigen Dutzend Zeilen oder Instanzen bestehen; und eine relativ kleine Anzahl von Tabellen, aber jede mit Tausenden oder Millionen von Zeilen oder Instanzen.
Im Bereich Business Intelligence könnte eine Informationsstruktur dieser Art ein mehrdimensionaler OLAP-Würfel sein , dem der Benutzer häufig eine Analysedimension hinzufügen muss, von einer unvorhersehbaren Anzahl und im Laufe der Zeit variabel: Die EAV-Tabellen geben eine zusammenfassende Darstellung, wenn die zu analysierenden Daten sind extrem verstreut, beispielsweise in einer biomedizinischen Wissensdatenbank. Dasselbe EAV-Modell kann auch verwendet werden, um EAV-Tabellen direkt in den OLAP-Cube zu importieren [4] .
Ein ER-Modell hätte die Grenze, alle Tabellen auf die übliche Weise zu verwalten, auch aus visueller Sicht, unabhängig von ihrer Größe und Bedeutung. Das Entitäts-Attribut-Wert-Modell ist ein Datenmodell, das diese Grenze überwindet und eine IT- effiziente Darstellung von Konzepten in Situationen ermöglicht, in denen einzelne Entitäten durch eine relativ viel kleinere Anzahl von Attributen (Eigenschaften oder Parametern) beschrieben werden als diejenigen, die möglicherweise für eine effektive konzeptionelle und logische Darstellung geeignet sind.
ER Schematische Dokumentation
Ein ER-Schema allein reicht aus verschiedenen Gründen fast nie aus, um alle Aspekte einer Anwendung zu beschreiben. Zunächst einmal erscheinen in einem ER-Schema nur die Namen der verschiedenen darin enthaltenen Konzepte, aber dies reicht möglicherweise nicht aus, um ihre Bedeutung zu verstehen. Bei besonders komplexen Schemata kann es vorkommen, dass Sie die verschiedenen Konzepte nicht verständlich und vollständig darstellen können.
Aus diesem Grund ist es wichtig, jedes ER-Schema mit unterstützender Dokumentation zu versehen, die dazu dienen kann, die Interpretation des Schemas selbst zu erleichtern und Eigenschaften aus den dargestellten Daten zu beschreiben, die nicht direkt durch die Modellkonstrukte ausgedrückt werden können. Daher müssen Werkzeuge vorhanden sein, um das Schema zu vervollständigen.
Geschäftsregeln
Eines der von Informationssystemanalysten am häufigsten verwendeten Werkzeuge zur Beschreibung von Eigenschaften einer Anwendung, die nicht direkt mit konzeptionellen Modellen dargestellt werden können, sind Geschäftsregeln . Diese Bedeutung ergibt sich aus der Tatsache, dass das, was wir ausdrücken möchten, in den meisten Fällen nur eine Regel des bestimmten Anwendungsbereichs ist, den wir in Betracht ziehen.
Der Begriff Geschäftsregel wird von Analysten mit einer breiteren Bedeutung verwendet, um alle Informationen anzugeben, die einen Aspekt einer Anwendung definieren oder einschränken. Basierend auf einer eher konsolidierten Klassifizierung kann eine Geschäftsregel insbesondere sein:
- die Beschreibung eines für die Anwendung relevanten Konzepts oder die genaue Definition einer Entität, eines Attributs oder einer Assoziation des ER-Modells;
- eine Integritätsbeschränkung für die Anwendungsdaten, sei es die Dokumentation einer Beschränkung, die mit einem Konstrukt des ER-Modells ausgedrückt wird (z. B. die Kardinalität einer Assoziation), oder die Beschreibung einer Beschränkung, die nicht direkt mit den Konstrukten des Modells ausgedrückt werden kann;
- eine Ableitung oder ein Konzept, das durch eine Inferenz oder eine arithmetische Berechnung aus anderen Konzepten des Schemas erhalten werden kann.
Für die Regeln des ersten Typs ist es offensichtlich unmöglich, eine genaue Syntax zu definieren, und es werden im Allgemeinen Sätze in natürlicher Sprache verwendet. Diese Regeln werden typischerweise in Form von Glossaren dargestellt, wobei die Beschreibungen entsprechend gruppiert werden.
Die Regeln, die Integritätsbedingungen und Ableitungen beschreiben, eignen sich eher für formale Definitionen mit mehr oder weniger komplexer Syntax. Da es jedoch keine Standardisierungen gibt und der gewählte Formalismus Gefahr läuft, nicht ausreichend aussagekräftig zu sein, werden wir dennoch auf Definitionen in natürlicher Sprache zurückgreifen und darauf achten, diese Definitionen angemessen zu strukturieren. Insbesondere die Regeln, die Integritätsbedingungen beschreiben, können in Form von Behauptungen oder Aussagen ausgedrückt werden, die immer in unserer Datenbank überprüft werden müssen. Aus Gründen der Übersichtlichkeit und zur Erleichterung ihrer Konstruktion müssen diese Aussagen atomar sein, dh sie dürfen nicht in Sätze zerlegt werden, die noch Aussagen darstellen. Da sie zur Dokumentation eines ER-Schemas verwendet werden, müssen die Behauptungen außerdem deklarativ in einer Form angegeben werden, die keine Methode zu ihrer Erfüllung vorschlägt. Dies ist in der Tat ein Realisierungsproblem und daher für die begriffliche Darstellung nicht relevant. Daher sind Notationen wie if <condition> then <action> nicht geeignet, um Geschäftsregeln auszudrücken, wenn sie ein ER-Schema dokumentieren. Eine vordefinierte Struktur zum Aussprechen von Geschäftsregeln in Form von Zusicherungen könnte wie folgt aussehen:
- <Konzept> muss / kann nicht <Ausdrücke auf Konzepte>
wobei die zitierten Begriffe entweder Begriffen entsprechen können, die in dem ER-Schema vorkommen, auf das Bezug genommen wird, oder Begriffen, die durch sie definiert werden können.
Geschäftsregeln, die Ableitungen ausdrücken, können ausgedrückt werden, indem Operationen (arithmetische oder andere) spezifiziert werden, die es ermöglichen, das abgeleitete Konzept zu erhalten. Eine mögliche Struktur ist daher:
- <Konzept> führt zu <Operation auf Konzepten>
Dokumentationstechniken
Die Dokumentation der verschiedenen in einem Diagramm dargestellten Konzepte oder der beschreibenden Geschäftsregeln kann mit Hilfe eines Data Dictionary erstellt werden. Es besteht aus zwei Tabellen: Die erste beschreibt die Schemaentitäten mit dem Namen, einer informellen Definition in natürlicher Sprache, der Liste aller Attribute (mit allen zugehörigen Beschreibungen) und möglichen Bezeichnern. Die andere Tabelle beschreibt die Assoziationen mit dem Namen, ihrer informellen Beschreibung, der Liste der Attribute (mit beliebigen Beschreibungen) und der Liste der beteiligten Entitäten zusammen mit ihrer Teilnahmekardinalität.
Was andere Regeln betrifft, können Sie immer noch eine Tabelle verwenden, in der die verschiedenen Regeln aufgelistet sind, und jedes Mal ihren Typ angeben. Es ist wichtig, alle Regeln darzustellen, die Beschränkungen beschreiben, die nicht durch das Schema ausgedrückt werden, aber es ist manchmal nützlich, auch Regeln darzustellen, die Beschränkungen dokumentieren, die bereits in dem Schema ausgedrückt sind.
ER-Schemaübersetzung
Die Übersetzung des ER-Schemas in ein äquivalentes logisches Schema (basierend auf einem logischen Modell, wie dem relationalen Modell ) , d. h. in der Lage, dieselben Informationen darzustellen, ist ein grundlegender Schritt des logischen Designs , dem normalerweise die Umstrukturierungsphase vorausgeht des Schemas ER . Das Hauptelement der Übersetzung eines ER-Schemas in ein äquivalentes logisches Schema ist die Tatsache, dass Beziehungen im relationalen Modell nicht existieren , daher müssen sowohl Entitäten als auch Assoziationen in Beziehungen übersetzt werden , durch geeignete codierte Regeln, basierend auf den ermittelten Hauptbezeichnern in der Umstrukturierungsphase des ER-Schemas die Kardinalität der Assoziationen und das Vorhandensein externer Identifikatoren.
Während die Vorbereitungsphase der Umstrukturierung des ER-Schemas nur teilweise automatisierbar ist, sind verschiedene Softwareprogramme auf dem Markt in der Lage, aus dem umstrukturierten ER-Schema automatisch das entsprechende relationale Schema, die eigentliche Datenbank, abzuleiten. Eine offensichtliche Folge dieser Tatsachen und offensichtlich auch der Art der beteiligten Modelle ist, dass die Aktivität des automatischen Ableitens eines ER -Schemas aus dem relationalen Schema , das auf der Grundlage der physischen Implementierung der DB abgeleitet wurde, eine von einigen zur Verfügung gestellte Funktion ist Software, erlaubt es im Allgemeinen nicht, das ursprüngliche ER-Schema zu erhalten .
Der Name jeder Entität entspricht dem Kopf einer Tabellenmatrix, die so viele Spalten hat, wie es Attribute der Entität gibt. Wenn das Attribut ein Primärschlüssel oder Teil eines Superschlüssels ist, der aus mehreren Attributen besteht, kann es nicht den Wert NULL annehmen (nicht optionales, obligatorisches Attribut) und kann nicht zwei Vorkommen desselben Werts annehmen (eindeutige, nicht wiederholte Werte).
Wenn die Assoziation zwischen zwei oder mehr Entitäten ein oder mehrere Attribute hat, führt die Assoziation normalerweise zu einer Tabelle, die als Identifikationsschlüssel den Satz von Primärschlüsseln aller durch die Beziehung (mit beliebiger Kardinalität) verbundenen Entitäten und als Felder die Attribute, die der Relation im ER-Schema zugeordnet sind. Diese Passage, die logischer Natur ist, sollte nicht mit der Verdinglichung einer Assoziation zu einer Entität verwechselt werden, eine Passage, die konzeptionellen Charakter hat und im ER-Schema durchgeführt werden kann.
In einem zweiten Schritt kann die Anzahl der Tabellen unter Berücksichtigung der maximalen Kardinalität (unitary, n-air), die zwei Tabellen verbindet, deutlich reduziert werden.
Notizen
- ↑ Der Begriff ist eine Abformung des englischen Entity-Relationship-Modells .
- ^ "The Entity Relationship Model: Toward a Unified View of Data" für Entity-Relationship-Modellierung.
- ^ Weniger verbreitetes Entity-Relationship-Schema , sogar im Vergleich zum ER-Schema .
- ^ Peter Thanisch , Tapio Niemi , Marko Niinimaki, Jyrki Nummenmaa, Using the Entity-Attribute-Value Model for OLAP Cube Construction , inKonferenzbeitrag ausgewählt in: Perspectives in Business Informatics Research: 10th International Conference , BIR 2011. Proceedings , Riga, Lettland, 6. Oktober 2011, DOI : 10.1007 / , ISSN 1865-1348 . Abgerufen am 17. Mai 2018 .
Bibliographie
- EF Codd, A Relational Model of Data for Large Shared Data Banks , IBM Research Laboratory, San Jose, California, Communications of the ACM – Band 13 / Nummer 6 / Juni 1970
- Atzeni, Ceri, Paraboschi, Torlone, Datenbanken (Modelle und Abfragesprachen) , McGraw Hill, 2003
- Atzeni, Ceri, Fraternali, Paraboschi, Torlone, Datenbanken (Architekturen und Evolutionslinien) , McGraw Hill, 2003
- Ramez Elmasri, Shamkant B. Navathe, Datenbanksysteme , Grundlagen , Pearson - Addison Wesley, 2003
Andere Projekte
Wikimedia Commons enthält Bilder oder andere Dateien zum Entitäts-Assoziations-Modell
