ERM - Entity Relationship Modell _______________________________________________________________________________________

1. Übersicht Datenbankdesign

Das Design einer Datenbank läßt sich in folgende Schritte gliedern:

Analyse Design Implementierung Entity-Relationsship logisches physisches DB Modellierung DB-Design DB-Design Installation

wahre Relationenmodell Eigenschaften Anwender-DB Anforderungen Quantifizierung DB-System einrichten

In der Analyse wird das logische Datenmodell entworfen, das sich nach den aktuellen und in Zukunft erwarteten Anforderungen des Anwenders richtet.

Ziel ist die Erstellung eines konzeptionellen Modells, das die wesentliche Semantik der Systemdaten beschreibt.

Das konzeptionelle Modell wird anhand von Symbolen aus einer Modelliermethode, die unter dem Begriff ERM-Modellierung (Entity Relationship Modelling bzw. Einheit- Beziehung-Analyse ) bekannt ist.

Die Methode wurde erstmals von Chen im Jahr 1976 eingeführt.

Im logischen DB-Design wird das ERM in ein Relationenmodell umgesetzt, d. h.

aus Einheiten und Beziehungen werden Tabellen bzw. Relationen.

Im physischen DB-Design wird das „Logische Modell“ auf eine konkrete Datenbank umgesetzt.

Im letzten Schritt wird schließlich die Datenbank entsprechend dem vorangegangenen Design installiert..

2. ERM- Methode

2.1 ERM-Analyse:

Die ERM-Analyse benutzt folgende Abstraktionen zu Beschreibung von Daten:

- Einheiten : bestimmte Dinge im Unternehmen

- Beziehungen: Wechselwirkungen zwischen Einheiten (Objekten) - Attribute: Eigenschaften von Einheiten und Beziehungen

Beispiel:

Die ERM-Analyse arbeitet nach folgendem Konzept

a) Vergleichbare Objekte werden in Entitytypen bzw. „Entity-Sets“ gruppiert

b) Die Wechselwirkungen zwischen den Objekten von Entitytypen Beziehungen (Relationships) und Beziehungstypen modelliert c) Das Ergebnis wird in einer ERM-Notation dargestellt

Mitarbeiter

Arbeit

Projekte

Attribute von Entitytypen und Beziehungstypen können im Diagramm ergänzt oder separat in einem „Datenkatalog“ notiert werden:

Personal-Nr

Mitarbeiter Name

Anschrift

Personal-Nr Arbeit Projekt-Nr Zeitaufwand

Projekt-Nr.

Projekte Anfangsdatum Budget

Datenkatalog:

Mitarbeiter = @Personal-Nr+Name+Anschrift Projekte = @Projekt-Nr+Anfangsdatum+Budget Arbeit = @Personal-Nr+@Projekt-Nr+Zeitaufwand

2.2 ERM-Strukturen:

ERM-Diagramme können in vielfältigen komplexen Strukturen konstruiert werden:

(1) ERM mit vielen Einheiten- Beziehungstypen

(2) ERM mit 2 Beziehungen zwischen 2 gleichen Einheiten

(3) Reduzierung von N-Beziehungstypen

(4) Zu modellierendes System in ERM-Diagrammen a) Einbindung des Systems

Teile fertigen Geschäft verkaufen an Kunden

Nicht korrekt, weil

- Geschäft ist Gegenstand der Modellierung - Einheitentyp Geschäft umfasst nur eine Einheit

b) Das korrekte Modell

Teile verkaufen an Kunden

(5) Abgeleitete Beziehungstypen

Abteilungen

haben

Bereiche aus

beschäftigen

Mitarbeiter

Abgeleitete Beziehungstypen sind überflüssig und sollten daher vermieden werden

2.3 Eigenschaften von Verbindungen und Ihre Bedeutung:

Eine Rechnung enthält eine. evtl. aber auch mehrere Positionen. Eine Position gehört

aber immer zu genau einer Rechnung.

Eine Person kann mehrere Autos haben. Es ist aber auch möglich1 daß kein Auto besitzt.

Jedes Auto hat aber genau einen Besitzer.

Ein Student von mehreren besucht mehrere Vorlesungen. Eine Vorlesung wird von mehreren Studenten besucht. Der Beziehungstyp wird durch (mindestens ein) Attribut beschrieben. Das Ergebnis des Vorlesungsbesuchs ist weder eine Eigenschaft des

Studenten noch der Vorlesung, sondern eine Eigenschaft der Tatsache, daß ein bestimmter Student eine bestimmte Vorlesung besucht hat.

ERM - Terminologie

In der verwirrenden Begriffsvielfalt heben sich folgende Begriffe heraus, die auch in den folgenden Texten verwendet werden:

Entity - entity Instance (Objekt, Objekttyp, Entity. Klasse):

ein real oder begrifflich existierender Gegenstand mit fester, bekannter Menge von Eigenschaften (Attributen); gleichartige Entities sind Ausprägungen (Instanzen) eines Entitytyps; sie werden beschrieben durch Werte der Atrribute des zugehörigen Entitytyps.

Entitytyp - entity type (Objekt, Objekttyp, Entity, Klasse):

ist eine Menge von gleichartig zusammengesetzten, eindeutig identifizierbaren Entities und wird beschrieben durch Attribute (Eigenschaften); für jede Ausprägung (Instanz) wird den Attributen jeweils ein Atrributwert zugeordnet.

Identifikator (identifizierender Schlüssel, Primärschlüssel)

eines der Attribute muß als ^„identifizierender SchIüssel“ geeignet sein, jede Ausprägung des Entitytyps eindeutig anzusprechen.

Beziehung - relationship (Relation1 Beziehungsausprägung)

eine Beziehung kann zwischen Entities bestehen, wenn zwischen den zugehörigen Entitytypen ein Beziehungstyp definiert ist; die Beziehung wird beschrieben durch verknüpfte Aufzählung der Werte der identifizirenden Schlüssel der in Verbindung stehenden Entities.

Beziehungstyp - relationship type (Relationship, Relation, Beziehung) ein Beziehungstyp ist eine Menge von Beziehungen und besteht nur zwischen Entitytypen, nicht zwischen Entities und Attributen; er wird beschrieben durch verknüpfte Aufzählung der

identifizierenden Schlüssel der in Verbindung stehenden Entitytypen; eine Beziehung ist Ausprägung eines Beziehungstyps.

Attribut - attribute (Merkmal, Eigenschaft)

sind beschreibende Eigenschaften von Entitytypen; sie werden durch die Menge zulässiger Attributwerte definiert; ein Attribut besitzt keine weiteren Atrributwerte.

Attributwert - attribute value (Attributausprägung)

Attributwerte sind Elemente einer Menge von zulässigen Werten des Attributs.

Wertebereich - domain

ist eine Menge von Werten, aus denen eines oder mehrere Attribute eines Entities ihre aktuellen Werte entnehmen.

2.5 ERM - Notationen

zugehörige Datenkatalogeinträge:

Artikel

-

-@

Relationenmodell

Beschreibung der Relation Kraftfahrzeug"'

Das Beispiel zeigt eine einfache Relation, weil die Wertebereiche aller Attribute einfach sind.

Erläuterung:

Attribut = Feld, Spalte

Tupel = Zeile, Datensatz

Kardinalität = Anzahl der Zeilen

Grad = Anzahl der Spalten

Primärschlüssel = identifizierender Schlüssel Wertebereich = Menge zulässiger Werte

Ein einfacher Wertebereich besteht nur aus einem einzigen Wert (Skalar), zusammengesetzte Wertebereiche bestehen aus mehreren einfachen Wertebereichen

3.2. Integrität

3.2.1 Schlüssel:

(1) Schlüsselkandidat

Ein (zusammengesetztes) Attribut K einer Relation R heißt Schlüsselkandidat wenn gilt:

- Eindeutigkeit: Zu keinem Zeitpunkt haben verschiedene Tupel von R denselben Wert für K

- Minimalität: Wenn K zusammengesetzt ist, kann keine Komponente von K entfernt werden, ohne daß die Eindeutigkeit zerstört wird.

(2) Primärschlüssel

Aus den Schlüsselkandidaten wird ein Primärschlüssel ausgewählt (3) Fremdschlüssel

Ein (zusammengesetztes) Attribut FK einer Relation R heißt Fremdschlüssel wenn gilt:

- Jeder Wert von FK ist entweder komplett null oder komplett nichtnull - Es gibt eine Relation R1 die FK als Primärschlüssel hat

Ein Fremdschlüssel heißt ungebunden, wenn er nichtnull ist, aber kein gleicher Primärschlüsselwert in der Zielrelation existiert.

3.2.2 Integritätsregeln

Regel 0: Bereichsprüfungen

Jeder Attributwert darf nur dem definiertem Wertebereich entnommen werden Regel 1: Entity-Integrität

Keine Komponente eines Primärschlüssels darf NULL-Werte enthalten Regel 2: Referentielle Integrität

Das Datenmodell darf keine ungebundenen Fremdschlüsselwerte enthalten

Beispiel: Bibliothekssystem

Relation Leser (LeserNr, Name, Adresse)

Relation Buch (BuchNr, LeserNr, Autor, Titel, Verlag, Jahr) Fremdschlüssel (LeserNr) referenziert Leser 1:n Beziehung zwischen den Relationen über LeserNr

Regel 1: Jeder Leser muß eine eindeutige LeserNr und jedes Buch muß eine eindeutige BuchNr haben

Regel 2: a) Buch ist nicht ausgeliehen: LeserNr in Buch enthält keinen Eintrag b) Buch ist ausgeliehen: LeserNr in Buch enthält einen Eintrag, zu dem es ein Tupel Leser geben muß

3.2.3 Fremdschlüsselregeln Fragestellungen:

(1) Darf der Fremdschlüssel null-Werte enthalten

(2) Was soll geschehen, wenn das Ziel-Entity einer Fremdschlüssselverbindung gelöscht wird ?

(3) Was soll geschehen, wenn das Ziel-Entity einer Fremdschlüssselverbindung geändert wird ?

Verhaltensmuster zu (2) und (3)

restriktiv:

Ein Ziel Entity darf nicht gelöscht/geändert werden, wenn Fremdschlüsselverbindungen existieren

kaskadiert:

Zusammen mit dem Ziel-Entity werden auch alle über Fremdschlüssel abhängigen

Entities gelöscht/geändert.

akzeptierend:

Das Ziel-Entity wird gelöscht/geändert nachdem die Fremdschlüsselwerte aller abhängigen Entities auf null gesetzt worden sind.

Übung: Kursorganisation

Eine Vertriebsfirma führt für Kunden und Interessenten Schulungen durch. Die durchgeführten Schulungen werden einfach in Karteikarten protokolliert. Für jeden Teilnehmer eines Kurses wird folgende Information (Beispiel) abgespeichert:

Aktenzeichen: 47-11-007-025

---

Firma: Pascal GmbH

Adresse: Spatzengasse 5

20891 Mäusedorf

---

Teilnehmername: Hr. James Bond

Adresse: unbekannt

Funktion im Betrieb: Systemanalytiker

--- Kursbezeichnung: Datenmodellierung für Profis

Zielgruppe: Analytiker

Datum: 17. - 20.7.1998

Teilnahme erfolgreich: ja

Diese Informationen sollen nun von einer ACCESS-Anwendung verwaltet werden.

1.) Entwerfen Sie hierfür passende Entitäten und Beziehungen.

a) Vermeiden Sie hierbei die redundante Speicherung von Daten (z.B. der Informationen über eine Firma), die im manuellen Karteisystem einen hohen Änderungsaufwand verursacht!

b) Geben Sie zu den Beziehungen jeweils die Kardinalität an.

c) Achten Sie darauf, daß Ihr Entwurf den Integritätsregeln genügt und geben Sie insbesondere die Regeln für Fremdschlüssel an!

Zusatzbetrachtung: Mögliche (spätere) Änderungen im Datenbestand - Ein Teilnehmer wechselt die Firma  in allen Kursen des Teilnehmers

- Eine Firma zieht um  in den Kursen aller Teilnehmer der Firma - Ein Kurs wird unter einer

neuen Bezeichnung angeboten  in allen bisherigen Teilnahmen des Kurses Wo muß überall geändert werden?

Wie kann man den hohen Änderungsaufwand vermeiden?

3.3. Funktionale Abhängigkeiten

(1) Seien A und B Attribute einer Relation R. B heißt funktional abhängig von A, wenn die Kenntnis des Wertes von A ausreicht um den Wert von B zu kennen A --> B , B = f(A)

Beispiele:

a) Personal-Nr. --> Name

LänderKZ --> Land

b) Alle Attribute einer Relation sind von ihrem Primärschlüssel funktional abhängig.

Die „2. Normalform“ verlangt, daß alle Nicht-Schlüsselattribute abhängig von dem gesamten Primärschlüssel sind.

(BestNr,TeileNr,BestDat,Menge)

ist nicht in der 2.NF da gilt: BestNr --> BestDat

(2) Seien A, B und C Attribute einer Relation R. C heißt transitiv funktional abhängig von A (über B), wenn gilt: A --> B und B --> C

Beispiele:

a) Aus Manager --> ProjektNr und Projekt --> Budget folgt Manager --> Budget b) Die 3. Normalform verlangt, daß es keine funktionalen Abhängigkeiten unter Nicht-Schlüsselattribute gibt, d.h. das jedes Nichtschlüsselattribut nichttransitiv abhängig von dem gesamten Primärschlüssel ist.

(ZulassNr, Halter, Modell, Hersteller, Zylinder)

ist nicht in der 3.NF da gilt: Modell, Hersteller --> Zylinder

4. Datenbankdesign für relationale DB

1. ERM-Analyse 2. Relationen-Modell

- Festlegung von Primärschlüssel - Fremdschlüsselregeln

- Normalisierung

3. Festlegen von quantitativen Daten - Datentypen, Feldlängen

- Anzahl Sätze (Zeilen) pro Tabelle

4. Spezifikation der Zugriffsanforderungen (Abfragen)

- Tabelle(n) auf die in der Anforderung zugegriffen wird - Reihenfolge der Zugriffe

- Zugriffsschlüssel und verwendete Attribute - Häufigkeit der Zugriffe

Beispiel: Projekte nutzen Teile a) ERM

Projekt-Nr Projekte Anfangsdatum

Budget

Projekt-Nr

nutzen Teile-Nr

Verbrauchsmenge

Teile-Nr

Teile Gewicht

Farbe Preis

b) Relationenmodell

Projekt (ProjektNr,Anfangsdatum,Budget) Nutzung (ProjektNr,TeileNr,Menge)

Fremdschlüssel (ProjektNr) ref Projekt Null-Werte: nicht erlaubt,

Ändern: kaskadierend, Löschen: kaskadierend

Fremdschlüssel (TeileNr) ref. Teile Null-Werte: nicht erlaubt,

Ändern: kaskadierend, Löschen: restriktiv

Teile (TeileNr, Gewicht, Farbe, Preis)

c) Festlegen von quantitativen Daten

c1) ProjektNr. char(8) Anfangsdatum date

Budget number(double) ...

c2) Anzahl Projekte 100 Anzahl TeileNr 2000 Anzahl Nutzungen 5000 ...

d) Zugriffsanforderungen

(A) Hole Anfangsdatum für ein bestimmtes Projekt (B) Hole Preis von Teilen für Projekte

(C) Hole Anfangsdatum für Projekte, die eine bestimmte TeileNr. verwenden A/1: Schlüssel: ProjektNr, Hole: Anfangsdatum, Häufigkeit: 50/Tag

B/1: Schlüssel: ProjektNr, Hole: TeileNr, Häufigkeit: 150/Tag

B/2: Schlüssel: TeileNr, Hole: Preis, Häufigkeit: 7500/Tag (50*150) C/1: Schlüssel: TeileNr, Hole: ProjektNr, Häufigkeit: 20/Tag

C/2: Schlüssel: ProjektNr, Hole: Anfangsdatum, Häufigkeit: 50/Tag