Datenbanken und SQL. Kapitel 3. Datenbankdesign Teil 2: Entity-Relationship-Modell. Edwin Schicker: Datenbanken und SQL

Transkript

1 Datenbanken und SQL Kapitel 3 Datenbankdesign Teil 2: Entity-Relationship-Modell

2 Datenbankdesign Entity-Relationship-Modell ERM Entitäten und ihre Eigenschaften Beziehungen zwischen den Entitäten Überführung der Entitäten in Relationen Überführung der Beziehungen in Fredschlüssel Fredschlüsseleigenschaften Schwache Entitäten Subtypen 2

3 Entity-Relationship-Modell (ERM) Bisher: Betrachten einzelner Relationen isoliert für sich Jetzt: Betrachten des Zusaenspiels der Relationen Auszug aus ERM der Datenbank Bike Kunde 1 1 vergibt Auftragsposten 1 Auftrag wird verkauft wird betreut von c Personal leitet c 3

4 Begriffe i Entity-Relationship-Modell Entität Eigenschaft Beziehung Subtyp Supertyp Schwache Entität Ein eindeutig unterscheidbares Objekt, ein unterscheidbares Eleent Ein Teil einer Entität, der die Entität beschreibt Eine Entität, die zwei oder ehr Entitäten iteinander verknüpft Eine Entität, die ein Teil einer anderen, ufassenderen Entität ist Eine Entität, die Subtypen enthält Entität, die von einer anderen Entität vollständig abhängig ist 4

5 Beispiele zu den Begriffen Begriff Entität Eigenschaft Beziehung Subtyp Supertyp Schwache Entität 5 Beispiele Person, Werkzeug, Produkt, Rechnung Nae, Vornae, PLZ, Ort einer Person; Größe, Gewicht eines Werkzeugs; Preis eines Produkts, Rechnungsdatu Die Entitäten Verkäufer und Produkt stehen iteinander in einer Beziehung: Der Verkäufer verkauft Produkte. Die Entität Verkäufer ist ein Subtyp zur Entität Mitarbeiter Die Entität Mitarbeiter ist ein Supertyp der Entität Verkäufer Die Entität Arbeitszeit ist schwach gegenüber der Entität Mitarbeiter

6 Beispiel: Entität Person Person Gehalt Adresse Persnr Nae PLZ Nr Vornae Zunae Ort Straße Entität Eigenschaft 6

7 Entität Person in UML -Notation Person Gehalt PLZ Ort Straße Nr Persnr Vornae Nachnae Entität In die Entität werden die Eigenschaften it aufgenoen Manchal werden auch Priärschlüssel, alternative Schlüssel und Fredschlüssel gleich it gekennzeichnet 7

8 Beispiel einer Beziehung Person arbeitet in einer Abteilung Abteilung 1 abgekürzt: Abteilung 1 enthält enthält Person In Abteilung sind ehrere Personen Person Beziehung In einer Abteilung arbeiten ehrere () Personen Eine Person arbeitet in genau einer (1) Abteilung 8

9 Schwache Entität Produkt Schwache Entität unabhängig voll abhängig Einzelteil: Einzelteil Ist auf Lager, auch wenn Produkt nicht ehr ex. Unabhängig vo Produkt Fehlerliste Produkt-Fehlerliste: Wertlos, wenn Produkt nicht ehr ex. Koplett abhängig vo Produkt 9

10 Usetzung der Entität Person in SQL Person Persnr Vornae Nachnae Gehalt PLZ Ort Straße Nr Ganzzahl CREATE TABLE Person ( Persnr INTEGER, PRIMARY KEY (Persnr), Vornae CHARACTER(20), Nachnae Gehalt NUMERIC (10, 2), PLZ CHARACTER(5), Ort CHARACTER(25), Strasse CHARACTER(25), Nr CHARACTER(4) ) ; Priärschlüssel Zeichenkette der Länge 20 CHARACTER(20) NOT NULL, Nachnae uss angegeben werden Gleitpunktzahl: 10 Zeichen, davon 2 Nachkoastellen 10

11 Beziehungen (grobe Einteilung) 1 zu 1 Beziehung Ein Auto hat einen Motor Ein Motor ist in eine Auto zu 1 Beziehung In einer Abteilung arbeiten ehrere Personen Eine Person ist einer Abteilung zugeordnet zu n Beziehungen Ein Verkäufer verkauft ehrere Produkte Ein Produkt wird von ehrerenverkäufern angeboten 11

12 Beziehungen (Besonderheiten) : Mehrere kann sein: 0, 1, 2, 13, usw. entspricht de häufig verwendeten Sternsybol ( * ) n: Nur ein anderer Buchstabe für 1: Eins kann sein: 0 oder 1 (Beispiel: Ein Motor ist nicht i KFZ!) Unterscheidung ist wichtig in relationalen Datenbanken Wir verwenden c für 0 oder 1, also c {0, 1} Wir verwenden 1, wenn der Wert 0 nicht vorkoen darf 12

13 Mögliche Beziehungen Beziehungen c (0..1) 1 c (0..1) A c c B A c Syetrie! 1 B A c Syetrie! B 1 A 1 c B A 1 Nicht öglich 1 B A 1 Syetrie! B A c B A 1 B A B 13

14 1 zu c Beziehung 1 Verkäufer ist genau 1 Mitarbeiter Verkaufsbezirk 1 Mitarbeiter ist 1 oder kein Verkäufer Provision Nae Adresse Persnr c Verkäufer 1 ist Mitarbeiter ist 1 c Inforatiker Gehalt Prograiersprache Betriebssyste Datenbank Detailinfos: ausgelagert in Subtypen Verkäufer, Inforatiker Reduziert Redundanzen 14

15 c zu c und 1 zu 1 Beziehungen c zu c: Sehr selten, etwa: Auto --- Motor Spezialfall von zu c, zusätzlich: Fredschlüssel ist eindeutig 1 zu 1: Erfordert, dass in beiden Entitäten ier je ein Eintrag existiert (ein Verweis uss ja gegenseitig existieren!) In relationalen Datenbanken erfolgt erst ein Eintrag der einen, dann ein Eintrag der anderen, also: 1 zu c Bedingung In relationalen Datenbanken treten diese Beziehungen also nicht auf (außer ittels koplexer Transaktionsechanisen) 15

16 zu 1 Beziehung Abteilung 1 Person enthält In einer Abteilung arbeiten ehrere Personen Eine Person ist exakt einer Abteilung zugeordnet Wichtig: Eine Person ist ier einer Abteilung zugewiesen Aber: In einer Abteilung können vorübergehend auch keine Personen arbeiten lässt den Wert 0 zu! 16

17 zu c Beziehungen Abteilung c Person enthält In einer Abteilung arbeiten ehrere Personen Eine Person ist einer oder keiner Abteilung zugeordnet Szenario: Abteilung wird aufgelöst. Mitarbeiter gehören dann keiner Abteilung an und werden erst nach und nach anderen Abteilungen zugeordnet Dies erfordert: zu c! 17

18 zu n Beziehungen Verkäufer n Produkt verkauft Ein Verkäufer verkauft ehrere Produkte Ein Produkt wird von ehreren Verkäufern verkauft Wichtig: zu n schließt ein: Ein neuer Verkäufer hat noch nichts verkauft Ein neues Produkt wurde noch nicht verkauft 18

19 Beispiele (1) Beziehung KFZ-Halter KFZ cc zzzz Student Vorlesung zzzz nn Kunde Bestellung 1 zzzz Bewohner Haus zzzz 1 Beerkung 1 Halter kann ehrere KFZ anelden 1 KFZ ist auf axial einen Halter zugelassen 1 Student besucht ehrere Vorlesungen 1 Vorlesung belegen ehrere Studenten 1 Kunde gibt ehrere Bestellungen auf 1 Bestellung gehört zu genau eine Kunden 1 Bewohner wohnt in eine Haus In 1 Haus wohnen ehrere Bewohner 19

20 Beispiele (2) Beziehung Park Bau 1 zzzz Park Bauart zzzz nn KFZ Motor cc zzzz cc KFZ-Typ Motortyp zzzz n Leiter Abteilung cc zzzz 1 Beerkung In 1 Park wachsen ehrere Bäue 1 bestiter Bau steht in eine Park In 1 Park wachsen ehrere Bauarten 1 Bauart wächst in ehreren Parks 1 KFZ besitzt axial einen Verbrennungsotor 1 Motor wird in axial eine KFZ eingebaut 1 KFZ-Typ besitzt ehrere Motorvarianten 1 Motortyp wird in ehreren KFZ-Typen verbaut 1 Abteilungsleiter leitet genau eine Abteilung 1 Abteilung besitzt axial einen Abteilungsleiter 20

21 zu n Beziehungen: Realisierung (1) Verkäufer Verkaeufer verkauft n Produkt verkauft Verknuepfung Produkt VerkNr 2 Fredschlüssel ProdNr Eigene Relation erforderlich Relation enthält 2 Fredschlüssel Die 2 Fredschlüssel sind Schlüsselkandidat Beziehungsrelation 21

22 zu n Beziehungen: Realisierung (2) Fredschlüssel verkauft Verkaeufer Verknuepfung Produkt VerkNr ProdNr CREATE TABLE Verknuepfung ( VerkNr CHARACTER(4) REFERENCES Verkaeufer, ProdNr CHARACTER(4) REFERENCES Produkt, Usatz INTEGER, PRIMARY KEY (VerkNr, ProdNr) ) ; Fredschlüssel Priärschlüssel 22

23 Definition (Beziehungsrelation) Seien k Relationen it k>1 gegeben. Eine Relation R heißt Beziehungsrelation, wenn sie diese k Relationen wie folgt iteinander verbindet: R enthält k Fredschlüssel it k>1, die je auf genau eine der k gegebenen Relationen verweisen. Die k Fredschlüssel bilden zusaen einen Schlüsselkandidaten. Wichtig: Jede Relation it obigen Eigenschaften ist also eine Beziehungsrelation! 23

24 zu 1 Beziehung: Realisierung Abteilung 1 24 Person enthält In der Beziehung wird ein Fredschlüssel hinzugefügt CREATE TABLE Person ( PersNr INTEGER, Nae CHARACTER (25),... Abteilungsnr PRIMARY KEY (Persnr) ) ; Priärschlüssel INTEGER NOT NULL REFERENCES Abteilung, Fredschlüssel Wegen zu 1

25 Einschub: zu n = Zwei zu 1 Fredschlüssel verkauft Verkaeufer 1 Verknuepfung 1 Produkt CREATE TABLE Verknuepfung ( VerkNr CHARACTER(4) REFERENCES Verkaeufer, ProdNr CHARACTER(4) REFERENCES Produkt, Usatz INTEGER, PRIMARY KEY (VerkNr, ProdNr) ) ; Fredschlüssel Kein NOT NULL, da Teil des Priärschlüssels 25

26 zu c Beziehung: Realisierung Abteilung c 26 Person enthält Wie zu 1, allerdings sind Nullwerte erlaubt CREATE TABLE Person ( PersNr INTEGER, Nae CHARACTER (25),... Abteilungsnr PRIMARY KEY (Persnr) ) ; Priärschlüssel INTEGER REFERENCES Abteilung, Kein NOT NULL Fredschlüssel

27 1 zu c Beziehung: Realisierung Persnr Gehalt Verkaufsbezirk Provision Nae Adresse Mitarbeiter 1 c Verkaeufer Fredschlüssel in c Beziehung! 27 Fredschlüssel in Verkaeufer erfordert NOT NULL und Eindeutigkeit Der Priärschlüssel ist eist auch Fredschlüssel (bei Subtypen!) CREATE TABLE Verkaeufer ( PersNr INTEGER REFERENCES Mitarbeiter, PRIMARY KEY (PersNr),... ) ; Fredschlüssel Priärschlüssel

28 c zu c Beziehung: Realisierung besitzt 28 KFZ c c Motor Wie zu c Beziehung, allerdings ist Fredschlüssel zusätzlich eindeutig Epfehlung: Die ufassendere Entität enthält den Fredschlüssel CREATE TABLE KFZ ( KFZNr INTEGER, PRIMARY KEY (KFZNr), MotorNr INTEGER REFERENCES Motor, UNIQUE (MotorNr),... Fredschlüssel ) ; Eindeutig!

29 Zusaenfassung zur Realisierung Beziehung zu n zu c zu 1 c zu c c zu 1 Überführung in Relationen und Fredschlüssel Erfordert Beziehungsrelation it zwei zu 1 oder zu c Beziehungen Hinzufügen eines Fredschlüssels zur Relation Wie zu c! Zusätzlich: Fredschlüssel ist NOT NULL Wie zu c! Zusätzlich: Fredschlüssel ist UNIQUE Wie c zu c! Zusätzlich: Fredschlüssel ist NOT NULL Meist ist Fredschlüssel der Priärschlüssel 29

30 Fredschlüsseleigenschaften (1) Darf ein Fredschlüsselwert leer bleiben, also Null- Werte enthalten? (2) Darf ein Tupel gelöscht werden, auf den sich ein Fredschlüssel bezieht? Wie sollte die Datenbank reagieren? (3) Darf ein Tupel geändert werden, auf den sich ein Fredschlüssel bezieht? Wie sollte die Datenbank reagieren? 30

31 Frage 1: Nullwerte erlaubt? Halter c eldet an KFZ Kunde 1 erteilt Bestellung ERM gibt die Antwort vor! Bei c Beziehung: Nullwerte sind ier zuzulassen Bei 1 Beziehung: Nullwerte sind ier verboten Zu beachten: Für Priärschlüssel gilt ier NOT NULL 31

32 Frage 2: Löschen eines Tupel Fredschlüsselbedingungen in SQL ON DELETE NO ACTION ON DELETE SET NULL ON DELETE CASCADE Funktionsweise Wird ein Tupel gelöscht, auf den ein Fredschlüssel it obiger Bedingung verweist, dann wird das Löschen dieses Tupel verhindert (Nichtstun, No Action) wird der darauf verweisende Fredschlüssel auf Null gesetzt (Set Null) wird auch das den Fredschlüssel enthaltene Tupel gelöscht (Cascade) 32

33 Frage 3: Ändern des Priärschlüssels Analog wird das Ändern eines Priärschlüssel behandelt: ON UPDATE NO ACTION ON UPDATE SET NULL ON UPDATE CASCADE Funktionsweise Wird ein Priärschlüsselwert geändert, auf den ein Fredschlüssel it obiger Bedingung verweist, dann wird das Ändern dieses Tupel verhindert (Nichtstun, No Action) wird der darauf verweisende Fredschlüssel auf Null gesetzt (Set Null) wird der Fredschlüsselwert it geändert (Cascade) 33

34 Hinweise zu Frage 2 und 3 zu 1 und c zu 1 Beziehungen: ON DELETE SET NULL ist nicht erlaubt! ON UPDATE SET NULL ist nicht erlaubt! Es gelten die Hinweise zu kaskadierenden Löschen aus Kapitel 2 Wir fügen zu jede Fredschlüssel eine ON DELETE Eigenschaft hinzu Wir fügen zu jede Fredschlüssel eine ON UPDATE Eigenschaft hinzu ON UPDATE CASCADE wird grundsätzlich epfohlen 34

35 Relation Verknuepfung (vollständig) CREATE TABLE Verknuepfung ( VerkNr CHARACTER(4) REFERENCES Verkaeufer ON DELETE NO ACTION ON UPDATE CASCADE, ) ; ProdNr CHARACTER(4) REFERENCES Produkt ON DELETE NO ACTION ON UPDATE CASCADE, Usatz INTEGER, PRIMARY KEY (VerkNr, ProdNr) 35

36 Relation KFZ (vollständig) CREATE TABLE KFZ ( KFZNr INTEGER, MotorNr INTEGER REFERENCES Motor ON DELETE SET NULL ON UPDATE CASCADE, PRIMARY KEY (KFZNr), UNIQUE (MotorNr),... ) ; Falls Motor kaputt und entsorgt wird, so wird autoatisch die MotorNr auf NULL gesetzt! 36

37 Schwache Entität Person 1 Arbeitszeit Schwache Entität Arbeitszeit ist vollständig abhängig von der Person Also: Arbeitszeit ist schwache Entität gegenüber Person Für schwache Entitäten gilt generell: NOT NULL ON DELETE CASCADE ON UPDATE CASCADE 37

38 Definition (Schwache Entität) Eine Entität heißt schwach, wenn für die dazugehörige Relation R gilt: R enthält genau einen Fredschlüssel it den drei Eigenschaften Not Null, On Delete Cascade und On Update Cascade. Auf R verweist kein Fredschlüssel. Eine Relation, auf die Fredschlüssel verweisen, ist nicht schwach! 38

39 Subtypen Verkaufsbezirk Provision Nae Adresse Persnr c Verkäufer 1 Mitarbeiter 1 c Inforatiker Gehalt Prograiersprache Betriebssyste Datenbank Verkäufer und Inforatiker sind Subtypen zu Mitarbeiter Subtypen sind schwach und enthalten Zusatzinforationen Es liegen 1 zu c Beziehungen vor! 39

40 Subtyp Verkaeufer CREATE TABLE Verkaeufer ( PersNr INTEGER REFERENCES Mitarbeiter ON DELETE CASCADE ON UPDATE CASCADE, PRIMARY KEY (PersNr),... ) ; NOT NULL Priärschlüssel ist auch Fredschlüssel ON DELETE CASCADE ON UPDATE CASCADE Keine weiteren Fredschlüssel schwache Entität! 40

41 Zusaenfassung Bestien aller Entitäten it ihren Eigenschaften. Erittlung der Beziehungen zwischen den einzelnen Entitäten. Überführung der Entitäten in Relationen und der Eigenschaften in die Attribute dieser Relationen. Noralforen beachten! Überführung der zu n Beziehungen in Beziehungsrelationen und aller anderen Beziehungen in Fredschlüssel. Erittlung der Eigenschaften der Fredschlüssel. Hier helfen Stichworte wie schwache Entität und Subtyp weiter. 41