Das ER-Modell

ER = Entity-Relationen Modell
Entity = Objekte = Tabellen
Relation = Beziehung
Mit dem ER-Modell kann man komplexe
Beziehungen in Datenbanken verstehen und bauen
Aus einem ER-Modell kann man mit einfachen
Regeln ein Physikalisches DB-Modell bauen

Vorgehensweise bei der ERModellierung

Schritt 1: Anforderungsanalyse = Gesprchsprotokoll:
Alle Oberbegriffe unterstreichen
Schritt 2: Liste aller wichtigen Entitten
(=Tabellenkandidaten) mit ihren Hauptspalten
Schritt 3:Relationen zwischen den Entitten bestimmen
und ER-Modell zeichnen
Schritt 4: ER-Modell in physisches Modell umwandeln
(Schlssel zu den Spaltenbeschreibungen hinzufgen)
Schritt 5 (optional): Erhaltene Tabellen normalisieren

Schritt 1: Anforderungen und

Entitten identifizieren
Unsere Kunden bestellen bei Maxmedia
Artikel zu optimalen Preisen. Wir
ordern diese Artikel bei Lieferanten und
stellen sie ins Lager. Artikel haben
verschiedene Tagespreise. Wir liefern diese
Artikel an die Lieferadresse des Kunden.
Wir geben guten Kunden sowohl Rabatte
als auch Kredite, die unter einem
Kreditlimit liegen mssen.

Schritt 2: Entittenliste gliedern

Echte Entitten: (haben viele Unterspalten)
Kunden, Artikel
Unechte Entitten (= i.d.R. nur Spalten, sind
einfache Zahlen oder Namen):
Rabatt, Preis, Kredit, Kreditlimit
Noch unklar:
Lager, Lieferant, Adresse

Notation fr ER-Modelle
(1)

(2)

(3)

(5)
Bedeutung

(4)

0..1

0 oder
genau
1 UNIQUE
c
OPTIONAL

0..*

0 oder
viele
mc beliebig
OPTIONAL
MULTIPLE

1..1

Genau
1MANDATORY UNIQUE
1

1..*

Mind.
beliebig
viele
m 1 oder
MANDATORY
MULTIPLE

Legende :
(1) Beschreibung des Bereiches ( * : keine obere Grenze)
(2) Darstellung in ER-Diagrammen
(3) Darstellung nach [Chen76]
(4) Darstellung nach [Zehn85]
(5) Schlsselworte in den tabellarischen Beschreibungen

Relationen
Fhren
Ehe
Ehemann

Ehefrau

Mann

fhren
Ehe

Frau

Motor

Treibt
an

Kfz

1:1

n:1
n:m

Reifen

Ist
montiert
an

Kfz

Bundesbrger

Hat
Wohnsitz
in

Gemeinde in BRD

Schritt 3 ER-Modell zeichnen

Was wird Tabelle, was wird Spalte?
Kredit und Lager werden
daher zu einfachen
Spalten in Kunde und
Artikel und knnen aus dem
ER-Modell entfernt werden
Eine 1:n oder n:m Beziehung
besteht zwischen Tabellen.

Wenn Unklarheit besteht (Ist ein Lager eine

komplexe Einheit oder nur ein anderes Wort fr
Artikelmenge in Lager?)
Die Entitt zunchst durch 1-2 einfache Spalten
(z.b.: Lagermenge, Lagerposition) in der
Artikeltabelle ersetzen

Kunde

bestellt
bei MM

Artikel

Hat
bei MM

Kredit

Eine 1:1 Beziehung ist ein Kandidat

fr eine Spalte, da in jeder Tabelle bereits
der Primrschlssel eine 1:1 Beziehung mit
den anderen Spalten hat
steht
im Lager

Lager ?

Schritt 4: Bau physik.Modell

Eine l:n-Beziehung zwischen 2 komplexen
Entitten (Ort, Kunde) wird in 2 Tabellen realisiert,
wobei der Primrschlssel der 1-Seite zum
Fremdschlssel der n-Seite wird

Ort

wohnt
in

Um eine n:m-Beziehung in ein

Datenmodell einzubauen, wird
Aus der Raute eine eigene Tabelle

Kunde

bestellt
bei MM

Artikel

Eine 1:n-Beziehung wird direkt in ein

Physikalisches Modell eingebaut.
Aus den 3 Entitten und 2 Beziehungen
werden also 4 physische Tabellen
(bernchste Folie)!

Physisches Datenmodell
Alle echten Entitten werden Tabellen
Unechte Entitten (z.b.:Kredit) werden zu
Attributen der echten Entitten.
Bei einer n:m Beziehungen wird aus der Relation
(bestellen) eine Tabelle (Bestellung) mit je zwei
n:1 Beziehungen. (Die Primrschlssel tauchen als
Fremdschlssel in der Relationstabelle auf)
In die fertigen Tabellen werden Schlssel und
noch fehlende Attribute hinzugefgt
Bestelldatum & Bestellmenge kommt zu Bestellung

Physikalisches Modell

bung: ER-Modell Kreuzfahrt

gehrt zu

Crew

Fhrt mit

Fhrt durch

Person

Yacht

Gebucht
fr

Hafen

Ist Station
auf

Tour

Erweiterung: Vererbung in
Tabellen

Viele Entitten sind Varianten eines Grund- oder Obertyps.

User (Kunden, Mitarbeiter)
Kunden (Privatkunden, Firmenkunden, Konzernkunden)
Mitarbeiter (Angestellte, Manager, externe Berater)
Bauteile (Widerstnde, Spulen, Dioden, Transistoren...)
All diese UnterTypen sind sich mehr oder weniger hnlich und
haben bestimmte zustzliche oder vernderliche Attribute, Eigenschafte
Oder Methoden
Die Frage ist: Wieviele Tabellen mssen geschaffen werden,
Um solche hnlichkeiten(=Vererbungsbeziehungen) darzustellen?

Beispielanforderungen
Die Nutzer einer Applikation unterteilen sich in Gastnutzer,
feste Kunden, interne Mitarbeiter und Admins.
Alle haben gemeinsame Attribute (z.b.: Name, Vorname,
Loginname, Passwort, Email, Telefon) aber auch
spezifische Attribute (z.b.: Fax-Nr, Firmenzugehrigkeit,
Kundennummer, 2.Wohnsitz, Beziehung zu anderen Usern, etc.)

Mgliche Lsung 1:
ER-Modell Minimale Tabellen

Gehrt
zu

User

Typ

Vorteil: Maximales Ausnutzen der Relationalen Modellierung

Nachteil: Jede Menge Vielleicht Felder in der Usertabelle
tbl_User
User_ID
AW
Adress_ID Zahl
Vorname Text(30)
Nachname Text(30)
Email
Text(30)
Firma ? Text(30)
Fax_Nr? Text(30)
Sonderrabatt?
Etc. etc. etc.

0..*

tbl_User_Typ
KT_ID
AW
User_ID
Zahl
Typ_ID
Zahl
Gltig_ab Date
Gltig_Bis Date
Bemerkung Text

ref_Typ
Typ_ID
AW
Typ_Name Date
Rechte_ID Zahl

0..*

Mgliche Lsung 2:
ER-Modell Maximale Tabellen

Gast

Privatkunde
Firmenkunde

Admin
Int_Mitarbeiter

Konzernkunde

Vorteile: Keine Typenrelation ntig, da jeder Kundentyp eigene Entitt

Keine berflssigen Attribute mehr
Nachteil: Relationeninflation zu anderen Tabellen Schlsselinflation

tbl_Priv_Kunde

tbl_F_Kunde

tbl_Int_Mitarb

User_ID
AW
Adress_ID Zahl
Vorname Text(30)
Nachname Text(30)
Email
Text(30)
Firma
Text(30)
Fax_Nr
Text(30)
Sonderrabatt

User_ID
AW
Vorname Text(30)
Nachname Text(30)
Email
Text(30)
Fax_Nr Text(30)
Abteilung_ID Zahl
Status_ID

tbl_Gast
User_ID
AW
Vorname Text(30)
Nachname Text(30)
Email
Text(30)

User_ID
AW
Adress_ID Zahl
Vorname Text(30)
Nachname Text(30)
Email
Text(30)

Mgliche Lsung 3:
Ober- und Subtypen
User
Gast

Privatkunde

Firmenkunde
Kleine Firma

Konzern

Intern
Admin

Mitarbeiter

tbl_User
User_ID
AW
Vorname Text(30)
Nachname Text(30)
Email
Text(30)

tbl_Priv_Kunde
User_ID
Adress_ID

AW
Zahl

tbl_F_Kunde
User_ID

AW
Adress_ID Zahl
Firma
Text(30)
Fax_Nr
Text(30)
Sonderrabatt

Vorteil:
Nachteil:
1:1-Relationen
tbl_Int_Mitarb
User_ID
AW
Abteilung_ID Zahl
Status_ID