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
- Objekte (Entities)
- deren Eigenschaften (Attribute), sowie
- ihre Beziehungen (Relationships)
beschrieben.
- Begriffe
- Vorgehensweise
- Eignung des ER-Modells
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.
- Peter Müller besitzt den weißen Porsche mit Kennzeichen M-..
- Petra Meier besitzt den roten Golf mit Kennzeichen S-..
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
- identifizierende Attribute (Identifikatoren, Primärschlüssel),
- referenzierende Attribute (Fremdschlüssel) und
- charakterisierende (lokale) Attribute
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.
Darstellung von Entity-Typen und Beziehungs-Typen
Die Möglichkeiten dieser grundlegenden Notation werden durch folgendes Beispiel nach Ward&Mellor veranschaulicht:
Darstellungsmöglichkeiten mit grundlegender Notation
inhaltliche Erläuterung zur Notation
- "Startet auf" beschreibt die Beziehung zwischen vielen verschiedenen individuellen Flugzeugen und Pisten.
- Zwischen zwei Entities können mehrere Relationen existieren ("startet auf" und "landet auf").
- Ein Entity kann mit mehreren anderen Entities in Beziehung stehen ( "Flugzeug" mit "Pilot", "Passagier" und "Piste")
- Durch eine einzige Relation können 3 oder mehr Entities verbunden sein ("fliegt mit" verbindet "Pilot", "Passsagier" und "Flugzeug".
- Andererseits kann eine Relation auch nur Verbindungen zu einem einzigen Entity-Typ haben ("Piste" "kreuzt" Piste").
- Entity-Typen repräsentieren nicht immer materielle Objekte (z.B. mündlich mitgeteilter "Flugplan").
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
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.
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
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 |  |
| Krähenfuß |  |
| Pfeil |  |
| min-max |  |
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 |  |
| Krähenfuß |  |
| Pfeil |  |
| min-max |  |
Varianten der Optionalitätsdarstellung
Vorgehensweise
Bei der Erstellung eines ERM hat sich folgende Vorgehensweise bewährt:
- Ermittlung der relevanten Entity-Typen
- Ermittlung der relevanten Beziehungstypen
- Beschreiben der Entity-Typen durch Festlegung ihrer Attribute
- Beseitigung der Redundanz zwischen verschiedenen Entity-Typen
- Beseitigung der Redundanz innerhalb von Entity-Typen durch Normalisieren
Zu jedem dieser Punkte finden Sie eine kleine Checkliste, teilweise durch Beispiele ergänzt.
Ermittlung der relevanten Entity-Typen
 |
Entity-Kandidaten können sein:
|
 |
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.
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:
UPDATE-Regeln gelten analog. Folgende Einträge sind im Data Dictionary enthalten (Unterstreichung kennzeichnet den Primärschlüssel):
"Lesernr" ist in diesem Beispiel sowohl Fremdschlüssel als auch Primärschlüssel―bestandteil von "Ausleihe". Es gelten folgende Fremdschlüsselregeln:
"Signatur" ist in obigem Beispiel sowohl Fremdschlüssel als auch Primärschlüs-sel―bestandteil von "Ausleihe". Es gelten folgende Fremdschlüsselregeln:
|
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
Ein Objekt setzt sich aus vielen Teilobjekten zusammen. Je nach Wichtigkeit dieser Teilobjekte für die Außenwelt
- bleiben diese Teilobjekte völlig unberücksichtigt,
- spiegeln sie sich in den charakterisierenden Attributen des entsprechenden Entity-Typs nieder (z. B. Anzahl Triebwerke, Höhe des Kabinendrucks, ..) oder
- werden sie als strukturelle Beziehungen auch nach außen sichtbar gemacht (z.B. falls die Wartungstermine der einzelnen Triebwerke relevant sind).
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:
- Ermittlung der relevanten Datenobjekte und ihrer Bedeutung
- Formulierung von Geschäftsregeln, welche sich in den Beziehungen zwischen den Datenobjekten ausdrücken
- Festlegung der strategischen Spanne des SW-Systems (was wird es können - was wird es aufgrund der zugrundeliegenden Daten nie können)
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.