+

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}