ER-Modell

+
ER-Modell
Das Relationenmodell
+
Sinn eines Relationenmodells
 
Dieses Modell soll eine mathematische Brücke zwischen dem
ER-Modell und den Tabellen einer Datenbank schaffen.
 
Dazu werden Entitäten und Beziehungen in Relationen
dargestellt.
 
Diese Relationen lassen sich dann nahezu direkt in ein
Tabellensystem umwandeln.
+
Ein Tupel
 
Ein Tupel ist ein Menge von Attributen, die ein Exemplar aus der
Miniwelt beschreiben.
 
Beispiele:
 
 
("Quattro Stagioni", "Tomaten, Käse, Champignon, Vorderschinken, Salami,
Peperoni", 6.20)
 
("Hawai", "Tomaten, Käse, Vorderschinken, Ananas", 5.70)
 
("Florian Huber", "Asamstr. 16 99110 Börishofen", "01110/1357", 1240)
Durch solche Kombinationen der einzelnen Attribute werden sie
zueinander in Relation gesetzt, daher der Name.
+
Die Relation
 
Die Relation ist die mathematische Menge aller Tupel, die in
der Miniwelt vorkommen.
 
In der Miniwelt eines regulären Pizzaservice dürfte z.B. das
folgende Tupel nicht existieren:
("Hawai", "Salami Peperoni", 122.235)
 
und ist folglich auch kein Element der Relation.
+
Das Relationenschema
 
Ein Relationenschema (oder Datenbankschema) ist die
Beschreibung, wie so ein Tupel aufgebaut ist.
 
Beispiele:
 
 
 
Pizza{Name: STRING, Zutaten: STRING, Preis: FLOAT}
Angestellter{Name: STRING, Adresse: STRING, Telefon: STRING, Gehalt:
FLOAT}
oder in Kurzform:
 
Pizza{Name, Zutaten, Preis}
 
Angestellter{Name, Adresse, Telefon, Gehalt}
+
Relationenschemata des
Pizzaservice (Entitäten)
 
 
 
 
Bestellung{Datum, Uhrzeit}
Angestellter{Name, Adresse, Telefon, Gehalt}
Kunde{Name, Adresse, Telefon}
Pizza{Name, Zutaten, Preis}
  Wie
man sieht, sind die Entitäten hervorragend beschrieben,
es fehlen aber die Beziehungen.
+
Relationenschemata des
Pizzaservice (Beziehungen)
 
Beziehungen lassen sich ebenfalls mit Relationen beschreiben,
sie enthalten aber Referenzen (Entität.Attribut) auf die mit ihnen
verbunden Entitäten.
 
Ein erster Ansatz würde etwa so ausschauen:
 
 
gibt ab {Bestellung.Uhrzeit,Kunde.Name}
nimmt auf {Bestellung.Datum,Angestellter.ID}
 
bäckt {Angestellter.Name,Pizza.Name}
fährt aus {Angestellter.Name,Pizza.Name}
 
erhält {Kunde.Name,Pizza.Name}
 
enthält {Bestellung.Uhrzeit,Pizza.Name}
 
+
 Problem
 
Es existieren mehrere Kunden mit dem Namen "Maier" und
folgendes Tupel ist gespeichert: (20:30, "Maier“)
 
Dann sind die so gespeicherten Daten nicht aussagekräftig,
da weder die Uhrzeit der Bestellung noch der Name des
Kunden eindeutig sind.
+
 Lösung
 
Zur Lösung dieses Problems bekommt jede Entität und das
zugehörige Relationenschema einen
Primärschlüssel.
+
Primärschlüssel
 
Um einen Datensatz (ein Tupel) eindeutig beschreiben zu können,
gibt es drei Möglichkeiten:
1. 
Ein vorhandenes Attribut ist bereits eindeutig, z.B. der Name einer
Pizza
2. 
Man kombiniert mehrere Attribute, z.B. Datum und Uhrzeit bei der
Bestellung
3. 
Man führt eine Zahl ein, die mit jedem neu erzeugten Tupel steigt (id).
 
Die so erhaltenen Attribute sind der Schlüssel zur eindeutigen
Identifizierung eines Datensatzes, sie heißen deshalb
Primärschlüssel.
 
Im ER-Diagramm und im Relationenmodell werden sie durch
Unterstreichen gekennzeichnet.
+
Verbesserte Relationenschemata
des Pizzaservice
+
Das zugehörige Relationenmodell
 
Bestellung{Datum, Uhrzeit}
 
Angestellter{ID, Name, Adresse, Telefon, Gehalt}
 
Kunde{ID, Name, Adresse, Telefon}
 
Pizza{Name, Zutaten, Preis}
 
gibt ab{Bestellung.Uhrzeit,Bestellung.Datum,Kunde.ID}
 
nimmt auf{Bestellung.Uhrzeit,Bestellung.Datum,Angestellter.ID}
 
bäckt{Angestellter.ID,Pizza.Name}
 
fährt aus{Angestellter.ID,Pizza.Name}
 
erhält{Kunde.ID,Pizza.Name}
 
enthält{Bestellung.Uhrzeit,Bestellung.Datum,Pizza.Name}
+
Umsetzung in Tabellen
+
Aufgabe
 
Dies ist die Fortsetzung zu den Beispielen der ERModellierung.
 
Nimm dir jedes ER-Modell vor und setze entsprechende
Primärschlüssel
 
Wandle alle aktualisierten ER-Modelle in ein
Relationenmodell um.
+
Bsp. Postleitzahlen
 
Primärschlüssel im Postleitzahlenverzeichnis: Die Postleitzahlen sind
eindeutig, Städte werden oft durch Zusätze eindeutig identifiziert,
z.B. "Frankfurt/Oder".
 
Relationenschemata:
 
Postleitzahl{Nummer}
 
Ort{Name, Zusatz}
identifiziert{Nummer, Name, Zusatz}
 
+
Bsp. Zeugnisse
 
Für Schüler (wie Personen allgemein) sind als Primärschlüssel am besten
(Kenn-) Zahlen geeignet. Demzufolge werden auch die Zeugnisse
zusätzlich durchnummeriert.
 
Relationenschemata:
 
Schüler{ID, Nachname, Vorname}
 
Zeugnis{ID, Mitarbeit, Verhalten, Fachnoten}
erhält {Schüler.ID, Zeugnis.ID}
 
+
Bsp. Digitalfoto
 
Die Digitalfotos erhalten am einfachsten ebenfalls Nummern als
Primärschlüssel, ein Stichwort "spricht für sich", verwendet also das Wort
selbst als eindeutige Bezeichnung.
 
Relationenschemata:
 
Foto{ID, Datum, Auflösung}
 
Stichwort{Bezeichnung}
gehört zu{Foto.ID,Bezeichnung}
 
+
Bsp. CD-Sammlung
 
Interpreten sind im allgemeinen durch ihren (Künstler-)namen eindeutig identifiziert,
CDs durch ihre ISBN-Nummer und Songs benötigen eine Nummer.
 
Relationenschemata:
  Interpret{Name}
  CD{ISBN, Titel}
 
 
 
Song{ID, Titel}
nimmt auf{Name, ISBN}
enthält{ISBN,Song.ID}
+
Bsp. Programmierung
 
Entwickler sind Personen, am sinnvollsten ist hier ein eigener
Schlüssel durch eine Nummer, Komponenten werden im
allgemeinen so benannt, dass sie eindeutig bezeichnet sind.
 
Relationenschemata:
 
Entwickler{ID, Name}
 
Komponente{Name}
enthält{Containerkomponente.Name,
enthalteneKomponente.Name}
programmiert{Entwickler.ID,Komponente.Name}
 
 
+
Bsp. Lehrerdatenbank
 
Lehrer erhalten (als Personen) eine ID, Klassen und Fächer sind normalerweise
im Namen eindeutig.
 
Relationenschemata:
  Lehrer{ID, Vorname, Nachname, Geburtsdatum, Adresse}
  Klasse{Name, Schülerzahl}
  Fach{Name}
  unterrichtet{Lehrer.ID, Klasse.Name}
  hat_Lehrbefähigung{Lehrer.ID, Fach.Name}
  wird_unterrichtet{Klasse.Name, Fach.Name}