Beispiel: Lastenheft: Für eine Hochschule soll eine Verwaltungssoftware geschrieben werden, die alle relevanten Daten in einem relationalen Datenbanksystem speichert. Zu diesen Daten zählen die Stamm- und Adressdaten der Professoren, sonstigen Dozenten, Assistenten und Studenten (also name, vorname, geschlecht, geburtsdatum, plz, ort, strasse), bei den Dozenten und Professoren die Fachgebiete, die sie lehren können und lehren, bei den Assistenten die Ausbildung und fachliche Schwerpunkte. Dazu die an der Hochschule existierenden Fachbereiche mit den zugeordneten Professoren und Dozenten und Assistenten, und die Veranstaltungen in den Fachbereichen mit den typischen Daten (titel, typ, semester, prüfungsart,...). Zusätzlich sollen auch alle Prüfungsdaten für jeden Studenten festgehalten werden (welcher Student hat wann welche Prüfung bei welchem Dozenten im wievielten Versuch mit welcher Note gemacht, usw... 1
Ziel: Modellierung einer Ausgangssituation in einen relationalen Datenbankentwurf: 1. Erfassen der Ausgangssituation in einem Lastenheft 2. Abstrahieren des Lastenheftes in ein erstes semantisches Modell (UML, ERM, etc.) 3. Überführen des Modells in ein relationales Datenmodell RDM 2
Beispiel: Lastenheft: Für eine Hochschule soll eine Verwaltungssoftware geschrieben werden, die alle relevanten Daten in einem relationalen Datenbanksystem speichert. Zu diesen Daten zählen die Stamm- und Adressdaten der Professoren, sonstigen Dozenten, Assistenten und Studenten (also name, vorname, geschlecht, geburtsdatum; plz, ort, strasse), bei den Dozenten und Professoren die Fachgebiete, die sie lehren können und lehren, bei den Assistenten die Ausbildung und fachliche Schwerpunkte. Dazu die an der Hochschule existierenden Fachbereiche mit den zugeordneten Professoren und Dozenten und Assistenten, und die Veranstaltungen in den Fachbereichen mit den typischen Daten (titel, typ, semester, prüfungsart,...). Zusätzlich sollen auch alle Prüfungsdaten für jeden Studenten festgehalten werden (welcher Student hat wann welche Prüfung bei welchem Dozenten im wievielten Versuch mit welcher Note gemacht, usw... 3
Beispiel: ER-Diagramm: 4
Beispiel: Relationales Datenmodell RDM: Tabellen: Person = ({persnr, vorname, name, geschlecht, gebdat, telnr, e-mail}, Person ) Dozent = ({doznr, titel, einstelldatum, büro, persnr, fbnr}, Dozent ) Professor = ({profnr, doznr}, Professor ) Lehrauftrag = ({lanr, von, bis, aufgaben, lbanr}, Lehrauftrag ) Lehrbeauftragter = ({lbanr, doznr}, Lehrbeauftragter ) Assistent = ({titel, einstelldatum, büro, persnr, fbnr}, Assistent ) Student = ({matrnr, persnr}, Student ) Adresse = ({adrnr, plz, ort, str, persnr}, Adresse ) Fachbereich = ({fbnr, bezeichnung, sekretärin}, Fachbereich ) Fachgebiet = ({fnr, bezeichnung, kategorie}, Fachgebiet ) Veranstaltung = ({vnr, titel, typ, semester, prüfart, stgnr}, Veranstaltung ) Studiengang = ({stgnr, bezeichnung}, Studiengang ) Lehren = ({doznr, fnr}, Lehren ) Besuchen = ({matrnr, vnr}, Besuchen } Halten = ({doznr, vnr, semester}, Halten ) Betreuen = ({persnr, vnr, semester}, Betreuen ) Prüfen = ({doznr, matrnr, fnr, prüfdatum, prüferg}, Prüfen ) 5
Zentrale Modellkonstrukte: Def.: (Entity) Als Entity bezeichnet man eine Modellierungseinheit, die eindeutig einem wohlunterscheidbaren und eindeutig identifizierbaren Begriff, einer ebensolchen Sache oder einer ebensolchen Person zugeordnet werden kann. Def.: (Relationship) Eine Relationship modelliert eine konkrete Beziehung zwischen zwei oder mehreren konkreten Entities. 6
Zentrales Modellkonstrukt: Entity Zur Modellierung von Entities gibt es die Konstrukte: Attribut Wertebereich A dom(a) Entity-Format X = { A 1, A n } Schlüssel K (als Teilmenge von X) Entity-Set: E s Menge von Entities gleichen Typs Entity-Typ: E = ( X, K ) 7
Zentrales Modellkonstrukt: Entity Formale Definitionen: Def.: (Entity-Typ) Ein Entity-Typ ist ein benanntes Tupel der Form E = (X, K), wobei E den Namen des Typs, X das Format und K den Schlüssel bezeichnet. Def.: (Entity) Ist E = (X, K) ein E-Typ und X = {A 1,...,A n } das Format, so ist ein Entity e definiert als injektive Abbildung e: X dom(a 1 ) dom(a n ), mit ( 1 i n) ( e(a i ) dom(a i ) ) Def.: (Entity-Set) Ein Entity-Set E s ist eine Teilmenge der Menge aller möglichen Entities zu einem bestimmten Typ E = (X, K), die den Schlüssel K erfüllen (d.h. nur sinnvolle bzw. zulässige Entities). Erfüllen heißt hier, dass eben alle Entities über den Schlüssel K identifizierbar sein müssen,also: 8 ( e 1, e 2 E s ) ( e 1 [K] = e 2 [K] e 1 = e 2 ).
Prof. Dr. Günter Brackly FB Informatik / MST Zentrales Modellkonstrukt: Entity Zur Identifikation von Entities können nur Attribute des Formats dienen. Alle Attribute zusammen identifizieren jedes Entity eindeutig! Es gibt aber auch kleinere Mengen identifizierender Attribute: Def.: (Schlüssel): Sei X das Format eines Entity-Sets, K X eine Teilmenge. K heißt Schlüssel des E-Sets, falls die folgenden beiden Bedingungen erfüllt sind: (i) K identifiziert jedes Entity des Sets eindeutig; (ii) K ist minimal mit dieser Eigenschaft (i), d.h. es gibt keine echte Teilmenge K K mit der Eigenschaft (i). Ein Entity-Set kann mehrere Schlüssel haben! Ist dem so, zeichnet man meist einen aus, mit dem man arbeiten will. Dieser ausgezeichnete Schlüssel heißt Primärschlüssel. 9
Zentrales Modellkonstrukt: Entity Beispiel: E-Typ: Student = ( {matrikelnr, name, vorname, gebdat, geschlecht}, {matrikelnr} ) E-Format: X = {matrikelnr, name, vorname, gebdat, geschlecht} Schlüssel: K = {matrikelnr} Entity: e = {852111, Mentär, Rudi, 01.04.1980, M} E-Set: E s = { {852111, Mentär, Rudi, 01.04.1980, M}, {851999, Huana, Mari, 07.02.1970, W}, {854333, Schweiss, Axel, 11.09.1985, M},.} 10
Zentrales Modellkonstrukt: Entity Graphische Notation: E-Typ: Student = ( {matrikelnr, name, vorname, gebdat, geschlecht}, {matrikelnr} ) Graphisch: matrikel nr name vorname gebdat geschlecht Student 11
Zentrales Modellkonstrukt: Entity Bestimmung der Entity-Typen am Beispiel Hochschulverwaltung: Für eine Hochschule soll eine Verwaltungssoftware geschrieben werden, die alle relevante Daten in einem relationalen Datenbanksystem speichert. Zu diesen Daten zählen die Stamm- und Adressdaten der Professoren, sonstigen Dozenten, Assistenten und Studenten (also name, vorname, geschlecht, geburtsdatum,; plz, ort strasse), bei den Dozenten und Professoren die Fachgebiete, die sie lehren können und lehren, bei den Assistenten die Ausbildung und fachliche Schwerpunkte. Dazu die an der Hochschule existierenden Fachbereiche mit den zugeordneten Professoren und Dozenten und Assistenten, und die Veranstaltungen in den Fachbereichen mit den typischen Daten (titel, typ, semester, prüfungsart,...). Zusätzlich sollen auch alle Prüfungsdaten für jeden Studenten festgehalten werden (welcher Student hat wann welche Prüfung bei welchem Dozenten im wievielten Versuch mit welcher Note gemacht, usw... rot: potentielle Entity-Typen blau: potentielle Attribute 12
Beispiel: ER-Diagramm: 13
Zentrales Modellkonstrukt: Relationship Eine Relationship drückt eine Beziehung zwischen 2 oder mehr Entities aus. Zur Modellierung von Relationships gibt es die Konstrukte: Relationship r Relationship-Typ R = ( Ent, Y ) Relationship-Set R s Kardinalität 1:1, 1:n, n:m 14
Zentrales Modellkonstrukt: Relationship Formale Definitionen: Def.: (Relationship-Typ) Ein Relationship-Typ ist ein benanntes Tupel der Form R = (Ent, Y), wobei R den Namen, Ent die Menge der beteiligten Entity-Sets und Y eine (eventuell leere) Menge eigener Attribute bezeichnet. Def.: (Relationship) Eine Relationship r vom Typ R = (Ent, Y) mit Ent = {E 1s,...,E ms } und Y = {B 1,...,B t } ist eine konkrete Ausprägung von Ent und Y, d.h. eine Beziehung zwischen konkreten Entities e i aus E is mit konkreten Attribut- Bewertungen b j dom(b j ): r = ( e 1,...,e m, b 1,...,b t ) E 1s E ms dom(b 1 ) dom(b t ) Def.: (Relationship-Set) Ein Relationship-Set ist eine Zusammenfassung von Relationships eines bestimmten Typs zu einer Menge (Kollektion): R s E 1s E ms dom(b 1 ) dom(b t ), mit Ent = {E 1s,...,E ms } und Y = {B 1,...,B t } 15
Zentrales Modellkonstrukt: Relationship Beispiel: R-Typ: besuchen = ( {Student, Veranstaltung}, {semester} ) Relationship: r = ( {852111,Mentär, Rudi, 01.01.1980, M}, {Datenbanken, Vorlesung}, {SS06} ) R-Set: besuchen s = { ( {852111, Mentär, Rudi, 01.01.1980, M}, {Datenbanken, Vorlesung}, {SS06} ), ( {854122, Mentär, Rudi, 01.01.1980, M}, {Betriebssysteme, Vorlesung}, {SS04} ), ( {852999, Schweiss, Axel, 04.11.1978, M}, {RNTK, Vorlesung}, {SS06} ),. } 16
Zentrales Modellkonstrukt: Relationship Kardinalitäten: Def.: (Kardinalität) Die Kardinalität einer 2-stelligen Relationship (eines Relationship-Sets, eines Relationship-Typs) gibt an, wieviele Entities des einen Entity-Sets mit wieviel Entities des anderen Entity-Sets in Beziehung stehen können. Chen-Notation: 1:1, 1:n oder n:m, mit n,m >= 0 Beispiele: besuchen = ( {Student, Veranstaltung}, {semester} ) n:m ausleihen = ( {Leser, Buch}, {ausleihdatum} ) n:m angehören = ( {Dozent, Fachbereich}, { } ) n:1 prüfen = ( {Dozent, Student, Fach}, {prüfdatum, prüfergebnis} )? 17
Zentrales Modellkonstrukt: Relationship Kardinalitäten: graphisch: semester Student n besuchen m Veranstaltung prüfdatum prüfergebnis Dozent prüfen Fach Student 18
Zentrales Modellkonstrukt: Relationship Kardinalitäten: Problem: Kardinalitäten für mehr als 2-stellige Relationships In der Standard-Interpretation haben die Kardinalitäten hier keine eindeutige Bedeutung mehr! prüfdatum prüfergebnis Dozent n prüfen m Fach k Student 19
Nicht- Zentrales Modellkonstrukt: Relationship Kardinalitäten für mehr als 2-stellige Relationships Neue Interpretation: Kardinalität als Teilnahmeanzahl prüfdatum prüfergebnis Dozent n prüfen m Fach k Student Ein Dozent-Entity kann n-mal an der Beziehung teilnehmen; Ein Fach-Entity kann m-mal an der Beziehung teilnehmen; Ein Student-Entity kann k-mal an der Beziehung teilnehmen; 20
Nicht- Zentrales Modellkonstrukt: Relationship Kardinalitäten als Intervalle (Min- Max- Notation): Dozent [0,*] [1,1] angehören Fachbereich Bedeutung: Ein Dozent-Entity gehört genau einem Fachbereich an! (mindestens und höchstens einem) Einem Fachbereich-Entity können kein, genau ein oder mehrere Dozent-Entities angehören! 21
Zentrales Modellkonstrukt: Relationship Spezielle Relationships: Funktionale Beziehungen Dozent n 1 angehören Fachbereich Einem Entity des einen E-Sets ist immer genau ein Entity des anderen E-Sets zugeordnet! Alle 2-stelligen Beziehungen mit der Kardinalität 1:n sind funktional! Alternative Notation: Dozent angehören Fachbereich 22
Zentrales Modellkonstrukt: Relationship Spezielle Relationships: Funktionale Beziehungen als Komposition Buchexemplar n 1 gehört zu Buch Ein Buchexemplar-Entity ist in seiner Existenz abhängig von der Existenz des zugehörigen Buch-Entity! Diese funktionale Beziehung besitzt Schlüsseleigenschaft, d.h. ein Exemplar-Entity kann nur zusammen mit dieser Beziehung identifiziert werden! Deshalb wird der Name der Beziehung wie bei normalen Schlüsselattributen unterstrichen. 23
Zentrales Modellkonstrukt: Relationship Spezielle Relationships: IS A (kind of) - Beziehung Mit IS A Relationships werden Vererbungsbeziehungen realisiert: Person IS A Dozent Student 24
Zentrales Modellkonstrukt: Relationship Spezielle Relationships: IS A (kind of) - Beziehung Formal: Seien E 1 = (X 1, K 1 ), E 2 = (X 2, K 2 ) zwei Entity-Typen. Dann besteht zwischen E 1 und E 2 eine IS-A-Beziehung der Form E 1 IS-A E 2 genau dann, wenn i) ( A X 2 ) (A X 1 ) ii) ( e 1 E 1s ) ( e 2 E 2s ) mit e 1 [X 2 ]= e 2 [X 2 ] Notation: IS A = ( {Student, Person}, {} ) 1:1 25
Enhanced-ERM Erweiterungen des : Zusammengesetzte Attribute Beispiel: adresse(plz, ort, str) Mehrwertige Attribute Beispiel: {hobbies} weitere Konstrukte des objektorientierten Paradigmas Komplexe Datentypen, Typkonstruktoren, objektwertige Attribute, etc 26
Enhanced-ERM Erweiterungen des : Beispiel: Person = ( { persnr, name, vorname, {adresse(plz, ort, str)}, {hobbies} }, {persnr} ) graphisch: plz ort str persnr name vorname adresse hobbies Person 27
Fazit: 1. Das Standard ERM ist die Vorlage für ein relationales Datenmodell (RDM) 2. Es gibt feste Regeln zur Überführung des ERM in ein RDM 3. Reichhaltigere Erweiterungen des sind vorhanden, damit kann wirklichkeits-genauer modelliert werden. 4. Es gibt auch andere Möglichkeiten, von einer Ausgangssituation zu einem RDM zu kommen: - UML oder andere Analysemodelle - Erzeugen einer Universalrelation 5. Für die meisten Modelle aus 3. und 4. gibt es aber keine regelbasierte Transformation in ein RDM! Ausnahme: Ausgehend von einer Universalrelation kann durch Algorithmen (z.b. SYNTHESE) ein RDM generiert werden! 28