Entity Relationship Modelling (ERM) - Datenstrukturanalyse (DSA) - Information Modelling (IM) .ppt

Das Entity Relationship Modell wurde ursprünglich von P.P.-S. Chen zur Datendefinition beim Datenbankentwurf entwickelt. Da Entity Relationship Modelle die Objekte der realen Welt mit ihren Eigenschaften und Beziehungen modellieren und damit nicht nur die Datenstruktur sondern auch deren Bedeutung repräsentieren, wird die Entity Relationship-Modellierung auch im Analyseprozess eingesetzt.

Die ERM ist ein datenorientierter Ansatz; da die Datenstrukturen langlebiger als die Funktionen sind, werden sie in den Mittelpunkt der Analyse gestellt, um so ein zukunftssicheres System zu erhalten. Das angestrebte Ziel besteht darin, die Datenstrukturen direkt nach den Erfordernissen der Realität zu entwickeln, und zwar unabhängig von den Funktionen der Vergangenheit.

Die ERM ist auch unter mehreren Namen mit gleicher bzw. leicht unterschiedlicher Bedeutung bekannt (z. B. Information Modelling (IM), Datenstrukturanalyse (DSA) und Semantische Modellierung von Datenstrukturen). Es existieren auch enge Verbindungen zum Relationenmodell, welches als Grundlage für das physische Datenbankdesign gilt.

Im Entity Relationship Modell werden für ein zu entwickelndes System die relevanten

beschrieben.

Begriffe

Entities und Entity-Typen

Ein Entity ist ein existierendes, eindeutig identifizierbares Objekt, über das Informationen gespeichert werden müssen.

Bei ähnlichen Objekten handelt es sich um unterschiedliche Exemplare (Ausprägungen, Instanzen) des gleichen Entity-Typs (z. B. Haus, Person, Stadt, Buch, Projekt, Abteilung, Mitarbeiter, Strategie, Zeitplan). Alle Entities eines Entity-Typs haben die gleiche Art (nicht Ausprägung) von Eigenschaften.

Beziehungen und Beziehungs-Typen

Eine Beziehung ist eine inhaltliche Verbindung zwischen Entities.

Zwischen den Entity-Typen "Person" und "Auto" läßt sich ein Beziehungs-Typ "besitzt" definieren (1 Person besitzt kein, ein oder mehrere Autos / jedes Auto hat genau einen Besitzer).

Beziehungen (relationships) sind Verknüpfungen zwischen zwei oder mehreren Entities; dabei müssen die verknüpften Entities nicht notwendigerweise zu verschiedenen Entity-Typen gehören (z. B. Mitarbeiter "betreut" Mitarbeiter). Zwischen zwei Entity-Typen können auch mehrere Beziehungs-Typen existieren (z. B. zwischen den Entity-Typen Mitarbeiter und Abteilung die Beziehungs-Typen "arbeitet in" und "leitet").

Die Beziehungen repräsentieren Sachverhalte, die sich das System merken muß.

Attribute, Werte und Wertebereiche

Attribute sind die beschreibende Eigenschaften (Merkmale) von Entity-Typen bzw. Beziehungs-Typen. Dem Attribut ist ein bestimmter Wertebereich von zulässigen Werten zugeordnet.

Es gibt

Attribute müssen nicht zwingend lesbar sein; auch Farbe, Foto, Video, Geräusch, Fingerabdruck, Geruch, oder Geschmack können wichtige Eigenschaften darstellen.

Grafische Notation

Die grundlegende Notation für Entity Relationship Diagramme orientiert sich an der Chen-Notation; hiernach werden Entity-Typen als Rechteck und Beziehungs-Typen als Raute dargestellt.

Entity- und Beziehungstypen

Darstellung von Entity-Typen und Beziehungs-Typen

Die Möglichkeiten dieser grundlegenden Notation werden durch folgendes Beispiel nach Ward&Mellor veranschaulicht:

Notation

Darstellungsmöglichkeiten mit grundlegender Notation

inhaltliche Erläuterung zur Notation

Assoziierte Entity-Typen

Es gibt im obigen Beispiel Attribute, die eindeutig dem Entity "Flugzeug" zugeordnet werden können (Anzahl Triebwerke, Länge, Gewicht, Passagierkapazität). Daneben gibt es Attribute, die eindeutig dem Entity "Piste" zugeordnet werden können (Länge, Breite, Oberflächenmaterial, zulässiger Bodendruck).

Ein spezieller Landeanflug verknüpft ein ganz spezielles Flugzeug mit einer ganz speziellen Piste; dies ist kennzeichnend für eine Relation. Andererseits sollen für den Landeanflug - wie für andere Entity-Typen - Informationen gespeichert werden, wie z.B. Datum, Uhrzeit, Windrichtung, Windgeschwindigkeit. Der Entity-Typ "Landung" soll auch mit anderen Entity-Typen (z.B. "Pilot") verbunden werden können. Bei dieser Doppelrolle spricht man von einem "assoziierten Entity-Typ".

assoziierter Entity-Typ

assoziierter Entity-Typ

Die Doppelrolle kommt auch in der grafischen Notation des assoziierten Entity-Typs zum Ausdruck: das Entity-Rechteck ist durch einen Pfeil mit der unbenannten Relationenraute verbunden; der Name gilt sowohl für die Entity als auch für die Relation.

Der Pfeil signalisiert jedoch einen wichtigen Unterschied : Während die Entity-Typen Flugzeug und Piste eigenständige Entity-Typen sind, hängt der Entity-Typ Landung von der Existenz der anderen Entity-Typen ab. (Es gibt neu gebaute Flugzeuge, die noch nie auf einer Piste gelandet sind; es gibt neu gebaute Pisten, auf denen noch nie ein Flugzeug gelandet ist. Eine Landung jedoch ist stets das Ergebnis einer Beziehung zwischen einem speziellen Flugzeug und einer speziellen Piste).

Generalisierung und Spezialisierung mit Super- und Subtypen

Supertypen und Subtypen bezeichnen einen Entity-Typ und zugehörige Unterkategorien, welche durch eine Beziehung miteinander verbunden sind.

Arbeitnehmer ist die allgemeine Kategorie; die Unterkategorien sind Lohnempfänger und Gehaltsempfänger.

Um die besondere Art des Beziehungs-Typs Generalisierung" zu unterstreichen, wird dieser in der grafischen Notation nicht als Raute, sondern als Dreieck dargestellt.

Super- und Sub-Typen

Darstellung von Super- und Sub-Typen

Der Supertyp wird durch Attribute beschrieben, welche auch auf alle Subtypen zutreffen (z. B. Name, Adresse, Personal-Nr., Dauer der Firmenzugehörigkeit). Die Subtypen jedoch haben unterschiedliche Attribute (z.B. Gehaltsempfänger : Monatliches Gehalt / Lohnempfänger: Stundenlohn).

Attributdarstellung

Attribute (Eigenschaften) eines Entity-Typs können im Diagramm durch Ovale dargestellt werden, die mit dem Entity-Typ durch eine Linie verbunden werden.

Attributdarstellung

Attributdarstellung

Komplexitätsgrad / Kardinalität

Der Komplexitätsgrad (Kardinalität einer Beziehung) gibt an, wieviele Exemplare des einen Entity-Typs mit einem Exemplar des anderen Entity-Typs in Beziehung stehen (bzw. in wieviel konkret vorhandenen Beziehungen ein Entity mindestens und höchstens vorkommen kann). Nachstehend eine Übersicht über die Kardinalitätsdarstellung von 4 gebräuchlichen Notationsarten.

Notation Grafische Darstellung
Chen Chen-Notation
Krähenfuß Krähenfuß-Notation
Pfeil Pfeil-Notation
min-max min-max-Notation

Varianten der Kardinalitätsdarstellung

Bei der min-max-Notation wird die Kardinalitätsangabe in Kleinbuchstaben vor die Beziehungsraute geschrieben, um so eine allgemeinere, auch für Mehrfachbeziehungen gültige Darstellung zu erhalten. Damit einhergehend erfolgt eine Umformulierung der Sichtweise: eine Person taucht in bis zu m Besitzverhänissen auf; ein Auto taucht in maximal einem Besitzverhänis auf.

Optionalität (Muß- oder Kann-Beziehung)

Die Optionalitätsangabe erweitert die Kardinalitätsaussage und legt fest, ob eine Muß- oder eine Kann-Beziehung vorliegt. Auch für die Optionalität einer Beziehung existieren entsprechende Darstellungsvarianten.

Notation Grafische Darstellung
Chen Chen-Notation
Krähenfuß Krähenfuß-Notation
Pfeil Pfeil-Notation
min-max min-max-Notation1

Varianten der Optionalitätsdarstellung

Vorgehensweise

Bei der Erstellung eines ERM hat sich folgende Vorgehensweise bewährt:

Zu jedem dieser Punkte finden Sie eine kleine Checkliste, teilweise durch Beispiele ergänzt.

Ermittlung der relevanten Entity-Typen

Entity-Kandidaten können sein:
  • Objekte (Firma, Artikel, Auto, Flugzeug, ...)
  • Personen (Lieferant, Kunde, Mitarbeiter, ...)
  • Ereignisse (Bestellung, Lieferung, Vertrag, Rechnung, Bilanz, Anfrage, Reklamation, ...)
  • Grundsätze (Zahlungsbedingungen, Rechtsvorschriften, ...)
Entity muß eindeutig identifizierbar sein.
Kunde kauft Artikel. Der Entity-Typ Kunde" wäre z.B. unterscheidbar anhand Kundennummer, Name oder Kontonummer. Im Supermarkt jedoch ist der Kunde anonym ; "Kunde" ist in diesem Fall kein sinnvoller Entity-Typ (stattdessen u.U. Kassenbon" als Reklamationsgrundlage).
Entity muß für die Funktionalität des Systems erforderlich sein.
In einer Firma ist jeder Pförtner individuell identifizierbar. Entscheidend ist jedoch, ob das Ziel-System nur mit Zugriff auf diese Pförtner-Daten funktionieren kann (essentielle Entities").
Verwendung assoziierter Entity-Typen um Beziehungs-Typen mit Attributen zu beschreiben.
Für die ermittelten Entities ist der Primärschlüssel mit seiner Bedeutung und seinem Wertebereich festzulegen.

Ermittlung der relevanten Beziehungstypen

Erforderliche Beziehungstypen ergänzen.
Um die erforderlichen Beziehungs-Typen zu vervollständigen, kann man das ERM gedanklich als "Frage-Antwort-Maschine" betrachten.
  • Welches Flugzeuge landeten auf einer speziellen Piste ?
  • Auf welchen Pisten landete ein spezielles Flugzeug ?
  • Welche Landungen hat ein spezieller Pilot durchgeführt ?
  • Welcher Pilot machte eine spezielle Landung ?
  • Welches Flugzeug flog der Pilot während einer speziellen Landung ?
  • Welche Piste benutzte der Pilot bei einer speziellen Landung ?
  • Mit welchen Flugzeugen ist ein spezieller Pilot gelandet ?
  • Auf welchen Pisten ist ein Pilot bereits gelandet ?

Die Frage "Welche Flugzeuge kann ein Pilot fliegen ?" würde jedoch einen zusätzlichen Beziehungstyp erfordern.

Kardinalität und Optionalität des Beziehungs-Typs klären.

Es ist zu klären, in wieviel konkret vorhandenen Beziehungen ein Entity mindestens vorkommen muß und höchstens vorkommen darf.

Es handelt sich hierbei um Geschäftsregeln, welche sich in den Beziehungen zwischen den Datenobjekten ausdrücken.

Definition der Fremdschlüssel.

Mit Fremdschlüsseln als Hilfsmittel werden die Beziehungen zwischen den verschiedenen Entity-Typen realisiert. Der Fremdschlüsselwert muß mit einem Primärschlüsselwert übereinstimmen, um eine Beziehung zwischen zwei Entitäten herzustellen.

Festlegung der Fremdschlüsselregeln (zur Wahrung der Beziehungsintegrität).

Für jeden Fremdschlüssel müssen entsprechend den fachlichen Anforderungen Festlegungen getroffen werden (Regeln zur Beziehungsintegrität / Fremdschlüsselregeln), die bewirken sollen, dass ein Fremdschlüsselwert immer einem Primärschlüsselwert entspricht. Hierzu ist festzulegen, was geschehen soll, wenn das Ziel-Entity einer Fremdschlüsselverbindung gelöscht bzw. geändert werden soll.

Grundsätzlich sind jeweils folgende 4 Verhaltensmuster für die DELETE- bzw. UPDATE-Regeln möglich:

  • Restriktives DELETE
    Solange noch ein Fremdschlüsselwert existiert, der dem zu löschenden Primärschlüsselwert entspricht, wird die Löschoperation nicht durchgeführt.
  • Kaskadiertes DELETE (Weitergabe der Löschung)
    Alle Entities deren Fremdschlüsselwerte dem zu löschende Primärschlüsselwert entsprechen, werden ebenfalls gelöscht.
  • Akzeptierendes DELETE
    Alle Fremdschlüsselwerte, die dem zu ändernden Primärschlüsselwert entsprechen, werden auf null" gesetzt (d.h. es existiert kein Wert für den Fremd―schlüssel). Voraussetzung hierbei ist, dass der Nullwert für Fremdschlüssel aus fachlichen Gründen zulässig ist !
  • Nutzerdefiniertes DELETE
    Falls keine der 3 Standardregeln die betriebliche Welt korrekt beschreibt, so muß eine anwendungsspezifische Integritätsregel formuliert werden.

UPDATE-Regeln gelten analog.

Folgende Einträge sind im Data Dictionary enthalten (Unterstreichung kennzeichnet den Primärschlüssel):

Leser =Lesernr + Name + Anschrift
Buch =Signatur + ISBN + Autor + Titel + Verlagsname + Jahr
Ausleihe =Signatur + Lesernr+
  [Ausleihdatum | Verlängerungsdatum] + Leihfrist

"Lesernr" ist in diesem Beispiel sowohl Fremdschlüssel als auch Primärschlüssel―bestandteil von "Ausleihe". Es gelten folgende Fremdschlüsselregeln:

  • Kaskadiertes UPDATE :
    D.h. zusammen mit der Leser-Entity wird auch das über Fremdschlüsselverbindung abhängige Ausleih-Entity geändert (eine Rückgabe der Bücher ist also nicht erforderlich!).
  • Restriktives DELETE :
    D.h. ein Nutzer kann nur gelöscht werden, wenn es keine Ausleihen von diesem Nutzer mehr gibt.

"Signatur" ist in obigem Beispiel sowohl Fremdschlüssel als auch Primärschlüs-sel―bestandteil von "Ausleihe". Es gelten folgende Fremdschlüsselregeln:

  • restriktives UPDATE :
    D.h. die Signatur kann nur geändert werden, wenn Buch nicht ausgeliehen ist.
  • restriktives DELETE :
    D.h. ein Buch kann nur gelöscht werden, wenn es nicht ausgeliehen ist.

Beschreiben der Entity-Typen durch Festlegung ihrer Attribute

Definition der Attribute und Vergabe von sprechenden Namen.

Identifizierende Attribute (Primärschlüssel) und referenzierende Attribute (Fremdschlüssel) wurden bereits festgelegt. Jetzt sind die charakterisierenden Attribute zu spezifizieren.

Richtige Zuordnung zu Objekttypen.

Abteilungsnummer ist z.B. kein Attribut von Mitarbeiter sondern ein Attribut der Abteilung.

Abgrenzung Attribut / Entity-Typ (Sichtbarkeit von strukturellen Beziehungen).

Abhängig vom Blickwinkel können Attribute zu Entity-Typen werden und umgekehrt. Hilfreiche Vorstellung : Im Inneren eines Entity-Typen sind viele interne Beziehungen; entscheidend ist jedoch, ob sie für die Außenwelt überhaupt relevant sind.

(Un-)Sichtbarkeit von strukturellen Beziehungen

(Un-)Sichtbarkeit von strukturellen Beziehungen

Ein Objekt setzt sich aus vielen Teilobjekten zusammen. Je nach Wichtigkeit dieser Teilobjekte für die Außenwelt

Beseitigung der Redundanz zwischen verschiedenen Entity-Typen

Die gleiche Person kann innerhalb eines Datenmodells verschiedene Rollen einnehmen: z. B. Angestellter/Kunde, Lieferant/Kunde, Arzt/Patient, Geschädigter/Schadensverursacher. Damit beispielsweise die Anschrift nach einer Anschriftenänderung konsistent bleibt, ist eine Generalisierung und Spezialisierung von Entity-Typen erforderlich.

Für das eigene Unternehmen ist der Entity-Typ MITARBEITER eine natürliche Person, mit Name, Anschrift, Geburtsdatum, ...
Beim Entity-Typ GESCHÄFTSPARTNER hingegen interessiert in der Regel nur die juristische Person (in besonderen Fällen jedoch vielleicht doch das Geburtsdatum der Kunden für Geburtstagskarten?)
Ob eine Generalisierung von MITARBEITER und GESCHÄFTSPARTNER zu PERSON sinnvoll ist, richtet sich nach dem konkreten Fall. Nachteilig ist z.B. wenn man gezwungen ist, gemeinsame Attribute wie Name, Anschrift künstlich allgemeingültig zu definieren und später redundanzfrei zu speichern.

Beseitigung der Redundanz innerhalb von Entity-Typen durch Normalisieren

Die interne Struktur der Entity-Typen läßt sich in Tabellen-Notation darstellen. In den Vorgehensschritten, die sich mit den internen Struktureigenschaften der Tabellen beschäftigen, spricht man auch von Relationen (im Sinne des relationalen Datenmodells) anstatt von Entity-Typen.

Die Normalisierung wird am Beispiel einer nach Nutzern sortierten Ausleihliste für Bücher dargestellt. Der Primärschlüssel ist in den folgenden Beispielen stets unterstrichen.

Ausleihliste
Lesernr. Name Adresse Datum Signatur Titel Autor
L 001 A. Adler Ahornstr. 7 1.7.94

SIG 44

Schatzinsel Stevenson
      1.7.94 SIG 45 Robinson Defoe
L 002 B. Bär Birkenstr. 8 2.7.94 SIG 56 Winnetou May
             

nicht normalisierte Ausleihliste

Überführung in die erste Normalform

Ein Entity-Typ befindet sich in der 1. Normalform, wenn jedes Attribut einer Entität höchstens einen Wert besitzt, d.h. es gibt keine Attribute mit Mehrfachwerten / keine Wiederholgruppen.

Um die obige Ausleihliste in die erste Normalform zu überführen, werden jene Attribute, welche Mehrfachwerte besitzen, aus der Relation herausgelöst. Im obigen Beispiel handelt es sich hierbei um die von einem Nutzer bei einer Ausleihe ausgeliehenen Bücher.

Buch
Signatur Titel Autor
SIG 44 Schatzinsel Stevenson
SIG 45 Robinson Defoe
SIG 56 Winnetou May
     

ausgegliederter Entity-Typ "Buch"

Nutzerausleihe
Signatur Lesernr. Name Adresse Datum
SIG 44 L 001 A. Adler Ahornstr. 7 1.7.94
SIG 45 L 001 A. Adler Ahornstr. 7 1.7.94
SIG 56 L 002 B. Bär Birkenstr. 8 2.7.94
         

Tabelle der Nutzerausleihen

Überführung in die zweite Normalform

Ein Entity-Typ befindet sich in der 2. Normalform, wenn die 1. Normalform vorliegt und jedes Attribut direkt abhängig ist vom gesamten Primärschlüssel, d.h. es dürfen keine funktionalen Abhängigkeiten der Nichtschlüsselattribute von Schlüsselteilen existieren.

Bei der obigen Relation "Nutzerausleihe" sind die Nichtschlüsselattribute "Lesername" und "Leseradresse" direkt vom Teilschlüssel "Lesernr." abhängig. Diese Teilschlüsselabhängigkeit kann dadurch beseitigt werden, indem die Leserdaten in einen separaten Entity-Typ ausgegliedert werden.

Leser
Lesernr. Name Adresse
L 001 A. Adler Ahornstr. 7
L 002 B. Bär Birkenstr. 8

ausgegliederter Entity-Typ "Leser"

Ausleihe
Signatur Lesernr. Datum
SIG 44 L 001 1.7.94
SIG 45 L 001 1.7.94
SIG 56 L 002 2.7.94

verbleibender Entity-Typ "Ausleihe"

Überführung in die dritte Normalform

Ein Entity-Typ befindet sich in der 3. Normalform, wenn die 2. Normalform vorliegt und jedes Attribut direkt abhängig ist vom gesamten Primärschlüssel, d.h. es dürfen keine funktionalen Abhängigkeiten der Nichtschlüsselattribute untereinander existieren.

Bei den obigen Entity-Typen "Buch", "Leser" und "Ausleihe" existieren keine funktionalen Abhängigkeiten der Nichtschlüsselattribute untereinander. Zur Erläuterung deshalb ein modifiziertes Beispiel für den Entity-Typ "Buch".

Buch
Signatur Titel Autor Verlag Erscheinungsort
SIG 44 Schatzinsel Stevenson rororo Hamburg
SIG 45 Robinson Defoe rororo Hamburg
SIG 56 Winnetou May dtv München

Abhängigkeit von Nichtschlüsselattributen

Diese transitiven Abhängigkeit kann durch weiteres Aufspalten in unterschiedliche Entity-Typen beseitigt werden. Die beiden betroffenen Attribute "Verlag" und "Erscheinungsort" sind voneinander abhängig werden deshalb in einem separaten Entity-Typ zusammengefaßt.

Verlag
Verlag Erscheinungsort
rororo Hamburg
dtv München

neuer Entitytyp "Verlag"

Buch
Signatur Titel Autor Verlag
SIG 44 Schatzinsel Stevenson rororo
SIG 45 Robinson Defoe rororo
SIG 56 Winnetou May dtv

verbleibender Entityp "Buch"

Denormalisierung

Aus Performancegründen kann anschließend eine kontrollierte Denormalisierung erfolgen.

Eignung des ER-Modells

Einsatzschwerpunkte

Das ER-Modell ermöglicht eine übersichtliche grafische Repräsentation der Daten. In der Analysephase können mit der Entity-Relationship-Modellierung folgende Aufgabenbereiche bearbeitet werden:

Die Entity-Relationship-Modellierung ist vor allem für Systeme geeignet, deren Hauptaufgabe die Aktualisierung und Darstellung von Daten ist.

Transformierbarkeit in Relationenmodell / Grundlage für Datenbankentwurf

In der Analysephase geht es primär um das Festlegen von Dateninhalten und der Beziehungen zwischen den Daten, jedoch nicht um einen vorgezogenen Datenbankentwurf. Zur konzeptionellen Modellierung wird zunächst das ER-Modell verwendet; das sich ergebende konzeptionelle Schema kann dann auf einfache Weise in ein entsprechendes logisches Schema auf der Basis des Relationenmodells transformiert werden. Die Beschreibung der Datenstrukturen im Relationenmodell ist der Ausgangs―punkt für das physische Datenbankdesign im Hinblick auf ein beliebiges Datenbank-Zielsystem.

Entwicklung von Unternehmensdatenmodellen mit ERM

In einem Unternehmensdatenmodell werden auf einer hohen Abstraktionsebene die grundlegenden Entity- und Beziehungs-Typen des gesamten Unternehmens beschrieben. Dieses Unternehmensdatenmodell bildet die Grundlage für eine strategische Anwendungssystem-Planung. Bei der Entwicklung eines konkreten Anwendungssystems muß ein Detailmodell erstellt werden, das mit dem unternehmensweiten Grobmodell und den bereits vorhandenen Detailmodellen verträglich ist, so dass es problemlos in das Grobmodell integriert werden kann.

Integration von ERM in Structured Analysis (SA)

Im Zuge der Erweiterungen der Structured Analysis (SA, SA/RT) durch /McMenamin&Palmer/, /Ward&Mellor/, /Hatley&Pirbhai/ und /Yourdan/ wurde ERM in SA integriert.

Darüber hinaus gibt die Analyse der Lebenszyklen der modellierten Entity-Typen Aufschluß über wichtige Geschäftsvorfälle. Anhand von Zustandsübergangsdiagrammen für diese Lebenszyklen läßt sich eine Ereignistabelle aufstellen. Mittels der Ereignistabelle kann die essentielle Ebene des SA-Modells hergeleitet werden.

Basis für diese Beschreibung ist ein Vortrag von U. Bechstein, SBS.