Teil 2-5. Vorlesung. Modul: Programmierung B-PRG Grundlagen der Programmierung II

Transkript

1 Teil 2-5. Vorlesung Modul: Programmierung B-PRG Professur für Datenbanken und Informationssysteme Dr. Karsten Tolle 1

2 Anmeldung zur Klausur Bis spätestens zum anmelden! was passiert dann? Raumzuordnung wird erstellt. Dort prüfen wo man schreibt! Klausur ist Freitag den 23. Juli 2

3 Literatur Folien/Übungen zu DB1 und DB2 sind online zugänglich Bib. unter H, Treppe hoch, dann lauft ihr in DB-Bücher 3

4 Fahrplan Heute: ER relationales Modell Nächste Woche: FDs und NFs SQL Letzte Vorlesung: Diverses Fragen und Antworten 4

5 Entity-Relationship Modell (E-R Model) P. Chen (ACM Artikel von 1976: The Entity Relationship Model Toward A Unified View of Data) Einfache graphische Darstellung der Welt 5

6 Die Welt Otto Müller lebt in Frankfurt am Main, in der Robert-Mayer-Str. 11. Er hat ein Flug nach Kapstadt gebucht. Person lebt_in Haus lebt_in 6

7 Das Entity-Relationship Modell Aus der Sicht des Objekt-Beziehungs-Modells (Entity-Relationship-Model) besteht die Welt aus Objekten (Entities) und Beziehungen (Relationships) zwischen diesen Objekten. Objekt (Entity): Modell eines Dings, das in der Umwelt erkannt und eindeutig identifiziert werden kann. Modellierungskonzept der Klassifikation: Objekte werden zu Objekttypen (Entity-Typs), und Beziehungen zu Beziehungstypen (Relationship-Typs) zusammengefasst. 7

8 Begriffe im Alltag Achtung: Die Begriffe Entity und Entity-Typ Beziehung (Relation) und Beziehungstyp (Relationship-Typ) werden im Alltag oft als Synonyme verwendet. 8

9 (Objekt) Attribute Ein Objekttyp ist durch einen bestimmten Satz von Merkmalen (Attributen) gekennzeichnet. Jedes Merkmal kann Werte (values), das sind in der Umwelt beobachtbare oder messbare Größen, aus einem bestimmten Wertebereich (value set) annehmen. Beispiel: Passagier Name Freigepäck Status Otto Müller 20kg Economy Class 9

10 Wichtig! Ein Beziehungstyp zwischen zwei Entity-Typen kann eine mathematische Relation aufgefasst werden. Name Geb_Datum Person lebt_in Stadt S_Name Population Instanz: Person = { p1, p2, p3 } Stadt = { c1, c2, c3 } lebt_in = { <p1,c1>, <p2,c3>, <p3,c3> } 10

11 Min/Max Kardinalitäten Person (1,1) (0,n) lebt_in Stadt min_card(person, Lebt_in) = 1 max_card(person, Lebt_in) = 1 min_card(stadt, Lebt_in) = 0 max_card(stadt, Lebt_in) = n Es gilt immer: min_card <= max_card! p1 p2 p3 Person, verbindlich c1 c2 c3 c4 Stadt, optional Bem.: Es gibt andere Notationen, z.b. wird manchmal nur max_card angegeben. 11

12 Kardinalitäten Instanz: Person = { p1, p2, p3 } Stadt = { c1, c2, c3 } lebt_in = { <p1,c1>, <p2,c3>, <p3,c3> } Instanz: Person = { p1, p2, p3, p4} Stadt = { c1, c2, c3, c4, c5 } lebt_in = { <p1,c1>, <p2,c1>, <p3,c3>, <p1, c4> } p1 p2 p3 c1 c2 c3 p1 p2 p3 p4 c1 c2 c3 c4 Person Stadt Person c5 Stadt Name Geb_Datum Person (1,1) (1,1) lebt_in Stadt S_Name Population Name Geb_Datum Person (0,n) lebt_in (0,n) Stadt S_Name Population 12

13 Klassifizierung der Beziehungstypen one-to-one (max_card auf beiden Seiten = 1) Person (1,1) (0,1) lebt_in Stadt one-to-many (max_card auf einer Seiten = 1, auf der anderen n) Person (0,1) (0,n) lebt_in Stadt many-to-many (max_card auf beiden Seiten n) Person (0,n) (1,n) lebt_in Stadt 13

14 (Beziehungs) Attribute Eine Beziehung kann durch Merkmale (Attribute) gekennzeichnet werden. Beispiel: Rolle Die Funktion, die ein Objekt in einer Beziehung erfüllt, nennt man seine Rolle. Gebuchter_Passagier PASSAGIER bucht Gebuchter_Flug FLUG SITZNR. 14

15 (Beziehungs) Attribute Instanz: Passagier = { p1, p2, p3 } Flug = { c1, c2, c3 } bucht = { <p1,c1, D2 >, <p2,c1, D3 >} D1 D2 p1 p2 p3 D2 D3 c1 c2 c3 c4 Gebuchter_Passagier PASSAGIER bucht Gebuchter_Flug FLUG Passagier Flug SITZNR. 15

16 Die Uni Studenten können sich von Professoren über eine Vorlesung mündlich prüfen lassen. Alt. 1: Name Geb_Datum Student prüft Prof Name Gehalt Vorlesung Alt. 2: Name Geb_Datum Student prüft Prof Name Gehalt (N-näre Beziehung) Titel SWS Vorlesung 16

17 Zusammengesetzte Attribute Aggregation von Attributen die etwas gemeinsam haben, z.b.: Person A d r e s s e Strasse Nummer Ort PLZ 17

18 Generalisierung Hierarchien für Entity-Typen (entspricht Klassenhierarchy in OO) Person Mann Frau 18

19 Schlüssel Ein Schlüssel besteht aus einer Menge von Attributen, deren Werte eine Instanz (Entity) eines Entity-Types eindeutig bestimmt. Person Personalausweisnummer Person Name Geb.Datum Geb.Ort Name Name des Vaters einfacher Schlüssel zusammengesetzter Schlüssel 19

20 ER Zusammenfassung Entitäten und Entity-Typen Beziehungen und Beziehungstypen Attribute für Entitäten(Typen) und Beziehungen(Typen) einfach oder zusammengesetzt ausgezeichnet als Schlüssel Kardinalitäten Generalisierung 20

21 Entity-Typ oder Attribut??? Möbelstück Farbe Möbelstück hat Farbe Entities sind Klassen von Objekten der realen Welt und nehmen keine Werte an. Attribute dagegen sind beschreibende Eigenschaften und nehmen Werte an. Die Entscheidung ist abhängig vom Kontext (Situation/Anwendungsfall). Farbe (1,n) besteht aus (1,n) Lack Nr. Name Intensität Menge Name Preis 21

22 Professor hält hält Lehrveranst. hält B B-E B-C B-D D A A-C A-D Ausbilder hält Seminar C E A-E besser so besser so A-C A A-E Personal Lehrer Lehrveranst. A-D C D E Professor Ausbilder Seminar B-D 22 B-C B B-E

23 Ausdruckskraft Ein Angestellter einer Abteilung soll nicht mehr verdienen, als der entsprechende Abteilungsleiter. Gehalt Angesteller arbeitet_ in Abteilung leitet Benötigt zusätzliche Beschreibung, sogenannte Business Rules. Ein Angestellter darf nicht mehr Gehalt bekommen als der Abteilungsleiter, zu dessen Abteilung der Angestellte gehört. Ein Abteilungsleiter muss zu der Abteilung gehören, die er leitet. 23

24 Business Rules (im weitesten Sinne) können angesehen werden als: 1. Die semantische Definition eines für Anwendungen relevanten Konzeptes, genauer, die semantische Definition eines Objektes, eines Attributes oder einer Relation des ER-Modells. Für diesen Fall werden natürlich sprachliche Sätze verwendet, da es unmöglich ist hierfür eine präzise Syntax zu definieren. 2. Integritätsbedingungen für die Daten einer Anwendung (als zusätzliche Beschreibung der im ER-Modell enthaltenen Bedingungen oder zusätzliche Bedingungen). 3. Abgeleitete Bedingungen bzw. Folgerungen aus anderen Bedingungen (z.b. Brutto ist Summe aus Netto plus Steuer). 24

25 PERSON NAME AGE ( 1, n ) FAN COACH PLAYER PRESIDENT ( 1, 1 ) ( 1, 1 ) ( 1, 1 ) ( 1, 1 ) SUPPORTS MANAGES PLAYS _ FOR IS _ PRESIDENT ( 1, n ) ( 1, 1 ) ( 1, n ) ( 1, 1 ) NAME TEAM ( 1, n ) ( 1, n ) ( 1, n ) DATE PLAYS _ AGAINST PRACTICES ( 1, n ) ATTENDS ( 1, n ) NUMBER DATE GAME ( 1, 1 ) FINAL _ SCORE ( 0, 1 ) ATTENDAN CE ( 0, 1 ) TIME TAKES PLACE _ AT ( 0, n ) STADIUM LOCATION SIZE NAME 25

26 NAME STATE CITY ( 0, n ) BIRTHPLACE _ OF ( 1, 1 ) PERSON LAST _ NAME AGE ( 0, n ) NAME TELEPHONE RESIDENCE _ CITY _ OF BELONGS _ TO ( 1, n ) DEPARTMENT ( 1, 1 ) ( 1, 1 ) ( 0, n ) STUDENT PROFESSOR ( 0, n ) ( 0, n ) SEMESTER SEMESTER ENROLLED PLANNED GRADUATE _ STUDENT ( 1, 1 ) ADVISED _ BY GRADE START _ APPOINTMENT ( 1, n ) ( 1, n ) COURSE ( 1, n ) TITLE TAUGHT _ BY ( 1, 2 ) TERMINATE _ APPOINTMENT VISITING _ PROFESSOR ( 3, 5 ) MEETS ( 1, n ) ROOM ROOM _ NO BUILDING ( 1, n ) 26 DAY TIME HOUR

27 27

28 28

29 Relationales Datenmodell Nach Edgar F. Codd definiert sich ein Datenbankmodell aus drei Eigenschaften: Einer generischen Datenstruktur, die die Struktur einer Datenbank beschreibt. Einer Menge von generischen Operatoren, die man bei beliebigen Schemata auf die Datenstrukturen anwenden kann, um Daten einzutragen, zu ändern, abzufragen oder abzuleiten. Einer Menge von Integritätsbedingungen, mit denen man die zulässigen Datenbankinhalte über die Grundstrukturen hinaus weiter einschränken kann. Dem Relationalen Datenmodell (E.F. Codd, 1970) liegt die mengentheoretische Relation zugrunde. 29

30 Relationales Datenmodell Tabellen mit Zeilen und Spalten um die Daten darzustellen. Employee Attribute EMPNO FIRSTNME LASTNME PHONENO SALARY Tupel 001 Jon Lucas Jon Smith Lucas Jon Jon Smith Schema (Relationenschema): Employee(EMPNO, FIRSTNME, LASTNME, PHONENO, SALARY)

31 Formalisierung des Relationenmodells I Definition: Ein Relationenschema R ist eine endliche Menge von Attributnamen {A 1, A 2,..., A n }. Notation: R = {A 1, A 2,..., A n } oder R(A 1, A 2,..., A n ) Attributnamen können auch verkürzt nur als Attribute bezeichnet werden. 31

32 Formalisierung des Relationenmodells II Definition: Zu jedem Attribut A i, 1 i n, gibt es eine Menge D i, den Wertebereich (domain) von A i. Notation: dom(a i ) ist der Wertebereich von A i. Beispiel: Das Attribut GESCHLECHT hat den Wertebereich dom(geschlecht) = {männlich, weiblich}. 32

33 Formalisierung des Relationenmodells III Definition: Sei D = D 1 D 2 D 3... D n das kartesische Produkt der Domänen D 1, D 2, D 3,..., D n. Eine Relation r auf einem Relationenschema R, bezeichnet mit r(r), ist eine endliche Menge von Abbildungen {t 1,..., t n } von R nach D, wobei für jede Abbildung t r, der Wert t(i) aus der Domäne D i, 1 i n, stammt. Diese Abbildungen werden Tupel genannt. Der Wert eines Tupels t für ein Attribut A, t(a) = a, heißt A-Wert von t. 33

34 Relationales Datenmodell Tabellen mit Zeilen und Spalten um die Daten darzustellen. Employee Attribute EMPNO FIRSTNME LASTNME PHONENO SALARY Tupel t 001 Jon Lucas Jon Smith Lucas Jon Jon Smith t(empno) = 001 t(firstnme) = Jon dom(salary) = Werte, die als mögliche Gehälter in Frage kommen

35 Relationales Datenmodell Employee EMPNO FIRSTNME LASTNME PHONENO SALARY Tupel t 001 Jon Lucas Jon Smith t 1, t Lucas Jon Jon Smith t(empno, FIRSTNME) = (001, Jon) t 1, t 2 r und t 1 (FIRSTNME, LASTNME) = t 2 (FIRSTNME, LASTNME)

36 Bemerkungen Relationen sind Abstraktionen von Teilen der realen Welt. Relationen sind veränderlich, sie ändern ihren Zustand in der Zeit Einfügen, Löschen, Ändern von Tupeln Relationenschemata sind unveränderlich Sind den Spalten einer Relation Attributnamen zugeordnet, so ist deren Reihenfolge unwichtig. (In der Definition der Relation auf S. 5 ist die Reihenfolge der Spalten wichtig.) 36

37 Schlüssel Ein Schlüssel identifiziert eine Entität. Er besteht aus einer Menge von Attributen, deren Werte alle Instanzen einer Entität eindeutig bestimmen. (aus ER!) Ein Schlüssel (key) einer Relation r(r) ist eine minimale Teilmenge K von R, so dass für je zwei verschiedene Tupel t 1, t 2 r gilt: t 1 (K) t 2 (K) und keine echte Teilmenge K' von K hat diese Eigenschaft. Ein Schlüssel kann als Integritätsbedingung angesehen werden. Falls K Schlüssel von r(r), t 1 r, t 1 (K) = t 2 (K), t 1 t 2 dann dürfte t 2 nicht in r(r) eingefügt werden. 37

38 Oberschlüssel K ist ein Oberschlüssel (super key) der Relation, falls K einen Schlüssel enthält. also aus Schlüssel Oberschlüssel (aber nicht umgekehrt) Oberschlüssel Schlüssel 38

39 Beachte!!! EMPNO FIRSTNME LASTNME PHONENO SALARY 001 Jon Lucas = 003 Jon Smith Lucas Jon Jon Lucas im mathematischen mengentheoretischen Modell EMPNO FIRSTNME LASTNME PHONENO SALARY 001 Jon Lucas Jon Smith Lucas Jon

40 Schlüssel, die explizit zu einem Relationenschema angeführt sind, heißen ausgezeichnete Schlüssel (designated keys). Eine Relation kann mehrere Schlüssel besitzen. Man spricht dann von Schlüsselkandidaten. Im Allgemeinen wird ein Schlüssel als Primärschlüssel ausgezeichnet. Dieser wird im Relationenschema durch Unterstreichen gekennzeichnet. 40

41 ER-Abbildung zu Relationen Entitätstypen Ein Entitätstyp wird zu einer Relation (Tabelle), dessen Relationenschema aus allen Attributen des Entitätstyp besteht. Jedes Tupel der Tabelle entspricht dann genau einer Entität des Entitätstyps. Etwaige Schlüssel werden übernommen und üblicherweise an den Anfang des Relationenschemas gestellt. Regel : Schlüssel Attribut_A Attribut_B Entitätstyp E E (Schlüssel, Attribut_A, Attribut_B) 41

42 Beispiel Angestellter Pers.Nr. Name Vorname ANGESTELLTER (Pers.Nr., Name, Vorname) ANGESTELLTER PersNr Name Vorname 001 Jon Lucas 003 Jon Smith 103 Lucas Jon 42

43 many-to-many Schlüssel1 A_1 Entität_1 (0:n) (0:n) B Beziehung Schlüssel2 A_2 Entität_2 ENTITÄT_1 (Schlüssel1, A_1) ENTITÄT_2 (Schlüssel2, A_2) BEZIEHUNG (Schlüssel1, Schlüssel2, B) 43

44 Beispiel seit Person (0:n) (0:n) lebt_in Ort AusweisNr. Name Vorname PLZ Ortsname PERSON ORT LEBT_IN (AusweisNr., Name, Vorname) (PLZ, Ortsname) (AusweisNr., PLZ, seit) 44

45 Beispiel mit Instanzen PERSON AusweisNr Name Vorname 001 Jon Lucas 003 Jon Smith 103 Lucas Jon LEBT_IN Ort AusweisNr PLZ seit PLZ Ortsname 501 Buli 503 Wali 603 Kali Jon Lucas (001) lebt_in Buli (501), seit dem ! 45

46 one-to-many (min_card = 0) Schlüssel1 A_1 Entität_1 (0:1) (0:n) B Beziehung Schlüssel2 A_2 Entität_2 ENTITÄT_1 (Schlüssel1, A_1) ENTITÄT_2 (Schlüssel2, A_2) BEZIEHUNG (Schlüssel1, Schlüssel2, B) 46

47 Beispiel Datum Buch verliehen an (0:1) (0:n) Entleiher BuchNr. Titel Autor Nummer Name BUCH ENTLEIHER VERLIEHEN_AN (BuchNr., Titel, Autor) (Nummer, Name) (BuchNr., Nummer, Datum) 47

48 one-to-many (min_card = 1) Schlüssel1 A_1 Entität_1 (1:1) (0:n) B Beziehung Schlüssel2 A_2 Entität_2 ENTITÄT_1 (Schlüssel1, A_1, Schlüssel2, B) ENTITÄT_2 (Schlüssel2, A_2) Hier sind nur noch zwei Relationen notwendig! 48

49 Beispiel Datum Person geboren in (1:1) (0:n) Ort AusweisNr. Name Vorname PLZ Ortsname PERSON (AusweisNr., Name, Vorname, PLZ, Datum) ORT (PLZ, Ortsname) 49

50 aber auch möglich! (geht immer ) Schlüssel1 A_1 Entität_1 (1:1) (0:n) B Beziehung Schlüssel2 A_2 Entität_2 ENTITÄT_1(Schlüssel1, A_1) ENTITÄT_2 (Schlüssel2, A_2) BEZIEHUNG (Schlüssel1, Schlüssel2, B) Person geboren in Datum (1:1) (0:n) Ort AusweisNr. Name Vorname PLZ Ortsname PERSON (AusweisNr., Name, Vorname, PLZ, Datum) ORT (PLZ, Ortsname) GEBOREN_IN (AusweisNr., PLZ, Datum) 50

51 one-to-one Eine one-to-one Beziehung kann wie eine one-to-many Beziehung in beide Richtungen betrachtet werden. Sind beide min-kardinalitäten = 0, so muss das allgemeine Verfahren angewendet werden. Ist nur eine min-kardinalität = 1, so wendet man die Abbildung der one-to-many Beziehung an. Schlüssel1 A_1 Entität_1 (1:1) (0:1) B Beziehung Schlüssel2 A_2 Entität_2 51 ENTITÄT_1 (Schlüssel1, A_1, Schlüssel2, B) ENTITÄT_2 (Schlüssel2, A_2)

52 Beispiel seit Abteilung geleitet von (1:1) (0:1) Mitarbeiter AbteilungsNr. Bezeichnung Pers.Nr. Name ABTEILUNG (AbteilungsNr., Bezeichnung, Pers.Nr., seit) MITARBEITER (Pers.Nr., Name) 52

53 one-to-one (beide min-card = 1) Schlüssel1 A_1 Entität_1 (1:1) (1:1) B Beziehung Schlüssel2 A_2 Entität_2 ENTITÄT_1_2 (Schlüssel1, A_1, Schlüssel2, A_2, B) oder ENTITÄT_1_2 (Schlüssel1, A_1, Schlüssel2, A_2, B) Nur noch eine Relation notwendig! 53

54 Beispiel Ablauf- Datum Ausweis (1:1) (1:1) gehört Person AusweisNr. Behörde Name Vorname PERSON (AusweisNr., Behörde, Ablaufdatum, Name, Vorname) 54

55 Sonderfälle Auto (3:5) (0:1) hat_räder Rad KFZ-Kennzeichen Hersteller Fabr.-Nr. Breite (Hier sind RAD1 RAD3 verbindlich, also NOT NULL, während RAD4 und RAD5 durchaus Nullwerte beinhalten dürfen.) AUTO (KFZ-Kennzeichen, Hersteller, RAD1,... RAD5) RAD (Fabr.-Nr., Breite) 55

56 Abbildung der Generalisierung Schlüssel Attribut_A Attribut_B Oberklasse Subklasse_1 Attribut_A_1 Attribut_B_1 Subklasse_2 Attribut_A_2 Hier: Drei Möglichkeiten mit unterschiedlichen Vor- und Nachteilen! 56

57 1. Möglichkeit Alle Entitätstypen zu eigenständigen Relationen, die alle für sie relevanten Informationen beinhalten. Die Subklassen enthalten neben ihren neuen Attributen noch alle Attribute ihrer Oberklasse. Der Vorteil der Performance überwiegt nur in wenigen Fällen gegenüber der entstehenden Redundanz, deren Gefahren der Inkonsistenz und des zusätzlichen Speicherbedarfs. Schlüssel Attribut_A Attribut_B Oberklasse Kto.-Nr. Kunde Kto.Stand Konto Subklasse_1 Attribut_A_1 Attribut_B_1 Subklasse_2 Attribut_A_2 OBERKLASSE (Schlüssel, Attribut_A, Attribut_B) SUBKLASSE_1 (Schlüssel, Attribut_A, Attribut_B, Attribut_A_1, Attribut_B_1) SUBKLASSE_2 (Schlüssel, Attribut_A, Attribut_B, Attribut_A_2) Girokonto Sparkonto Kreditrahmen Zinssatz KONTO (Kto.Nr., Kunde, Kto.Stand) GIROKONTO (Kto.Nr., Kunde, Kto.Stand, Kreditrahmen) SPARKONTO (Kto.Nr., Kunde, Kto.Stand, Zinssatz) 57

58 2. Möglichkeit Die Entitätsmengen, die die Subklassen bilden, beinhalten in ihrer entstehenden Relation neben ihren eigenen Attributen nur noch den Schlüssel der Oberklassen-Entitätsmenge. Damit lassen sich alle Daten einer Subklassen-Entität durch einen natürlichen Verbund (natural join) gewinnen. Schlüssel Attribut_A Attribut_B Kto.-Nr. Kunde Kto.Stand Oberklasse Konto Subklasse_1 Subklasse_2 Girokonto Sparkonto Attribut_A_1 Attribut_B_1 Attribut_A_2 Kreditrahmen Zinssatz OBERKLASSE (Schlüssel, Attribut_A, Attribut_B) SUBKLASSE_1 (Schlüssel, Attribut_A_1, Attribut_B_1) SUBKLASSE_2 (Schlüssel, Attribut_A_2) KONTO (Kto.Nr., Kunde, Kto.Stand) GIROKONTO (Kto.Nr., Kreditrahmen) SPARKONTO (Kto.Nr., Zinssatz) 58

59 3. Möglichkeit Man erstellt eine Relation, die als Schema die Vereinigung der Attribute aller Subklassen und der Oberklasse hat. Die Attribute, die eine bestimmte Entität nicht hat, werden durch Nullwerte ersetzt. Schlüssel Attribut_A Attribut_B Kto.-Nr. Kunde Kto.Stand Oberklasse Konto Subklasse_1 Subklasse_2 Girokonto Sparkonto Attribut_A_1 Attribut_B_1 Attribut_A_2 Kreditrahmen Zinssatz KLASSE (Schlüssel, Attribut_A, Attribut_B, Attribut_A_1, Attribut_B_1, Attribut_A_2) KONTO (Kto.Nr., Kunde, Kto.Stand, Kreditrahmen, Zinssatz) 59

60 Größeres Beispiel Abt-Nr. beschäftigt Pk-Nr Name Lohn Angestellter Abteilung (1,1) (1,1) geleitet_von seit Manager AT-Klasse Außendienst Datum verkauft ANGESTELLTER (PK-NR, NAME, LOHN) AUSSENDIENST (PK-NR) ABT_MANAGER (ABT-NR, SEIT, PK-NR, AT-KLASSE) BESCHÄFTIGT (ABT-NR, PK-NR) POLICE (POLICE-NR, ART, NEHMER, SUMME, DATUM, PK-NR) Police (1,1) Summe Nehmer Art Police-Nr. 60

61 Schlüssel? Kontext: Deutschland ADRESSE PLZ Ort StraßeNr Frankfurt Kettenhofweg Offenbach Bahnhofstr Offenbach Waldweg 34 61