DB-Entwurf im ER-Modell

Transkript

1 DB-Entwurf im 1 Datenbankentwurf 2 Datenbankmodell 3 4 Erweiterungen des s 5 Weiteres Vorgehen beim Entwurf Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 1

2 Datenbankentwurf Entwurfsaufgabe Datenhaltung für mehrere Anwendungssysteme und mehrere Jahre daher: besondere Bedeutung Anforderungen an Entwurf Anwendungsdaten jeder Anwendung sollen aus Daten der Datenbank ableitbar sein (und zwar möglichst effizient) nur vernünftige (wirklich benötigte) Daten sollen gespeichert werden nicht-redundante Speicherung Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 2

3 Datenbankentwurf Phasenmodell Anforderungsanalyse Konzeptioneller Entwurf Verteilungsentwurf Logischer Entwurf Datendefinition Physischer Entwurf Implementierung & Wartung Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 3

4 Datenbankentwurf Anforderungsanalyse Vorgehensweise: Sammlung des Informationsbedarfs in den Fachabteilungen Ergebnis: informale Beschreibung (Texte, tabellarische Aufstellungen, Formblätter, usw.) des Fachproblems Trennen der Information über Daten (Datenanalyse) von den Information über Funktionen (Funktionsanalyse) Klassischer DB-Entwurf: nur Datenanalyse und Folgeschritte Funktionsentwurf: siehe Methoden des Software Engineering Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 4

5 Datenbankentwurf Konzeptioneller Entwurf erste formale Beschreibung des Fachproblems Sprachmittel: semantisches Datenmodell Vorgehensweise: Modellierung von Sichten z.b. für verschiedene Fachabteilungen Analyse der vorliegenden Sichten in Bezug auf Konflikte Integration der Sichten in ein Gesamtschema Ergebnis: konzeptionelles Gesamtschema, z.b. (E)ER-Diagramm Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 5

6 Datenbankmodell Grundlagen von Datenbankmodellen Ein Datenbankmodell ist ein System von Konzepten zur Beschreibung von Datenbanken. Es legt Syntax und Semantik von Datenbankbeschreibungen für ein Datenbanksystem fest. Datenbankbeschreibungen = Datenbankschemata Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 6

7 Datenbankmodell Ein Datenbankmodell legt fest... 1 statische Eigenschaften 1 Objekte 2 Beziehungen inklusive der Standard-Datentypen, die Daten über die Beziehungen und Objekte darstellen können, 2 dynamische Eigenschaften wie 1 Operationen 2 Beziehungen zwischen Operationen, 3 Integritätsbedingungen an 1 Objekte 2 Operationen Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 7

8 Datenbankmodell Datenbankmodelle Klassische Datenbankmodelle sind speziell geeignet für große Informationsmengen mit relativ starrer Struktur und die Darstellung statischer Eigenschaften und Integritätsbedingungen (also die Bereiche 1(a), 1(b) und 3(a)) Entwurfsmodelle: (E), UML,... Realisierungsmodelle: Relationenmodell, objektorientierte Modelle,... Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 8

9 Das Entity: Objekt der realen oder der Vorstellungswelt, über das Informationen zu speichern sind, z.b. Produkte (CD, Album), Musiker oder Kunde; aber auch Informationen über Ereignisse, wie z.b. Bestellungen Relationship: beschreibt eine Beziehung zwischen Entities, z.b. ein Kunde bestellt ein Album oder ein Album wird von einem Musiker eingespielt Attribut: repräsentiert eine Eigenschaft von Entities oder Beziehungen, z.b. Name eines Kunden, Titel eines Albums oder Datum einer Bestellung Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 9

10 ER-Beispiel BestellNr Datum Menge AlbumNr Titel Bestellung umfasst Album Preis bestellt Versand eingespielt von Telefon Kunde Name Musiker Land KundenNr Name MNr Name Adresse Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 10

11 Werte Werte: primitive Datenelemente, die direkt darstellbar sind Wertemengen sind beschrieben durch Datentypen, die neben einer Wertemenge auch die Grundoperationen auf diesen Werten charakterisieren : vorgegebene Standard-Datentypen, etwa die ganzen Zahlen int, die Zeichenketten string, Datumswerte date etc. jeder Datentyp stellt Wertebereich mit Operationen und Prädikaten dar Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 11

12 Entities Entities sind die in einer Datenbank zu repräsentierenden Informationseinheiten im Gegensatz zu Werten nicht direkt darstellbar, sondern nur über ihre Eigenschaften beobachtbar Entities sind eingeteilt in Entity-Typen, etwa E 1, E 2... Album Menge der aktuellen Entities: σ(e 1 )={e 1, e 2,...,e n } Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 12

13 Attribute Attribute modellieren Eigenschaften von Entities oder auch Beziehungen alle Entities eines Entity-Typs haben dieselben Arten von Eigenschaften; Attribute werden somit für Entity-Typen deklariert AlbumNr Album Titel Preis textuelle Notation E(A 1 : D 1,...,A m : D m ) Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 13

14 Identifizierung durch Schlüssel Schlüsselattribute: Teilmenge der gesamten Attribute eines Entity-Typs E(A 1,...,A m ) {S 1,...,S k } {A 1,...,A m } in jedem Datenbankzustand identifizieren die aktuellen Werte der Schlüsselattribute eindeutig Instanzen des Entity-Typs E bei mehreren möglichen Schlüsselkandidaten: Auswahl eines Primärschlüssels Notation: markieren durch Unterstreichung: E(...,S 1,...,S i,...) Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 14

15 Beziehungstypen Beziehungen zwischen Entities werden zu Beziehungstypen zusammengefasst allgemein: beliebige Anzahl n 2 von Entity-Typen kann an einem Beziehungstyp teilhaben zu jedem n-stelligen Beziehungstyp R gehören n Entity-Typen E 1,...,E n Ausprägung eines Beziehungstyps σ(r) σ(e 1 ) σ(e 2 ) σ(e n ) Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 15

16 Beziehungstypen /2 Notation Album eingespielt von Musiker textuelle Notation: R(E 1, E 2,...,E n ) wenn Entity-Typ mehrfach an einem Beziehungstyp beteiligt: Vergabe von Rollennamen möglich verheiratet(frau: Person, Mann: Person) Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 16

17 Beziehungsattribute Beziehungen können ebenfalls Attribute besitzen Attributdeklarationen werden beim Beziehungstyp vorgenommen; gilt auch hier für alle Ausprägungen eines Beziehungstyps Beziehungsattribute Menge Bestellung umfasst Album textuelle Notation: R(E 1,...,E n ; A 1,...,A k ) Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 17

18 Merkmale von Beziehungen Stelligkeit oder Grad: Anzahl der beteiligten Entity-Typen häufig: binär Beispiel: Lieferant liefert Produkt Kardinalität oder Funktionalität: Anzahl der eingehenden Instanzen eines Entity-Typs Formen: 1:1, 1:n, m:n stellt Integritätsbedingung dar Beispiel: maximal 5 Produkte pro Bestellung Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 18

19 Zwei- vs. mehrstellige Beziehungen Produkt ProdId Produkt ProdId Name P-V Name bestellt Versand K-P Versand K-V Kunde KundenNr Kunde KundenNr Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 19

20 Ausprägungen im Beispiel Kunden Produkte Kunden Produkte K 1 P 1 K 1 P 1 K 2 P 2 K 2 P 2 V 1 V 2 Versand V 1 V 2 Versand Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 20

21 Rekonstruktion der Ausprägungen Kunden Produkte K 1 P 1 K 2 P 2 K 1 P 1 V 1 K 1 P 2 V 2 K 2 P 1 V 2 aber auch: K 1 P 1 V 2 V 1 V 2 Versand Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 21

22 1:1-Beziehungen jedem Entity e 1 vom Entity-Typ E 1 ist maximal ein Entity e 2 aus E 2 zugeordnet und umgekehrt Beispiele: Prospekt beschreibt Produkt, Mann ist verheiratet mit Frau Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 22

23 1:N-Beziehungen jedem Entity e 1 vom Entity-Typ E 1 sind beliebig viele Entities E 2 zugeordnet, aber zu jedem Entity e 2 gibt es maximal ein e 1 aus E 1 Beispiele: Lieferant liefert Produkt, Mutter hat Kinder Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 23

24 N:1-Beziehung invers zu 1:N, auch funktionale Beziehung zweistellige Beziehungen, die eine Funktion beschreiben: Jedem Entity eines Entity-Typs E 1 wird maximal ein Entity eines Entity-Typs E 2 zugeordnet. R : E 1 E 2 Produkt geliefert von Lieferant ProdId Preis Name Adresse Titel Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 24

25 M:N-Beziehungen keine Restriktionen Beispiel: Bestellung umfasst Produkte Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 25

26 [min,max]-notation E 1 [min 1, max 1 ] [min R n, max n ] E n [min 2, max 2 ]... E 2 schränkt die möglichen Teilnahmen von Instanzen der beteiligten Entity-Typen an der Beziehung ein, indem ein minimaler und ein maximaler Wert vorgegeben wird Notation für Kardinalitätsangaben an einem Beziehungstyp R(E 1,...,E i [min i, max i ],...,E n ) Kardinalitätsbedingung: min i {r r R r.e i = e i } max i Spezielle Wertangabe für max i ist Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 26

27 Kardinalitätsangaben [0, ] legt keine Einschränkung fest (default) R(E 1 [0, 1], E 2 ) entspricht einer (partiellen) funktionalen Beziehung R : E 1 E 2, da jede Instanz aus E 1 maximal einer Instanz aus E 2 zugeordnet ist totale funktionale Beziehung wird durch R(E 1 [1, 1], E 2 ) modelliert Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 27

28 Kardinalitätsangaben: Beispiele partielle funktionale Beziehung lagert_in(produkt[0,1],fach[0,3]) Jedes Produkt ist im Lager in einem Fach abgelegt, allerdings wird ausverkauften bzw. gegenwärtig nicht lieferbaren Produkte kein Fach zugeordnet. Pro Fach können maximal drei Produkte gelagert werden. totale funktionale Beziehung liefert(lieferant[0,*],produkt[1,1]) Jedes Produkt wird durch genau einen Lieferant geliefert, aber ein Lieferant kann durchaus mehrere Produkte liefern. Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 28

29 Alternative Kardinalitätsangabe Produkt [1,1] [0,*] geliefert von Lieferant Produkt N 1 geliefert von Lieferant Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 29

30 Abhängige Entity-Typen abhängiger Entity-Typ: Identifikation über funktionale Beziehung Bestellposition gehört zu Bestellung PosNr Produkt BestNr Datum Menge Abhängige Entities im : Funktionale Beziehung als Schlüssel Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 30

31 Abhängige Entity-Typen /2 Mögliche Ausprägung für abhängige Entities gehört zu PosNr: 1 Menge: 2 Produkt: Amplified BestNr: 1011 Datum: PosNr: 2 Menge: 1 Produkt: Rosenrot gehört zu gehört zu PosNr: 1 Menge: 1 Produkt: Living With War BestNr: 1012 Datum: Bestellposition Bestellung Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 31

32 Abhängige Entity-Typen /3 Alternative Notation Bestellposition gehört zu Bestellung PosNr Produkt BestNr Datum Menge Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 32

33 Die IST-Beziehung Spezialisierungs-/Generalisierungsbeziehung oder auch IST- Beziehung (engl. is-a relationship) textuelle Notation: E 1 IST E 2 IST-Beziehung entspricht semantisch einer injektiven funktionalen Beziehung Album IST Produkt Genre ProdId Preis Laufzeit Titel Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 33

34 Eigenschaften der IST-Beziehung Jeder Album-Instanz ist genau eine Produkt-Instanz zugeordnet Album-Instanzen werden durch die funktionale IST-Beziehung identifiziert Nicht jedes Produkt ist zugleich ein Album (z.b. Single, Film,...). Attribute des Entity-Typs Produkt treffen auch auf Alben zu: vererbte Attribute Album(Produkt#,Titel,Preis,Genre,Laufzeit) } {{ } von Produkt nicht nur die Attributdeklarationen vererben sich, sondern auch jeweils die aktuellen Werte für eine Instanz Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 34

35 Alternative Notation für IST-Beziehung Album Produkt Genre ProdId Preis Laufzeit Titel Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 35

36 Kardinalitätsangaben: IST für Beziehung E 1 IST E 2 gilt immer: IST(E 1 [1, 1], E 2 [0, 1]) Jede Instanz von E 1 nimmt genau einmal an der IST-Beziehung teil, während Instanzen des Obertyps E 2 nicht teilnehmen müssen Aspekte wie Attributvererbung werden hiervon nicht erfasst Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 36

37 Optionalität von Attributen Kunde KundenNr Adresse Name Telefon Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 37

38 Weitere Konzepte Strukturierte Attributwerte im Kunde KundenNr Ort Adresse PLZ Telefon Name Straße Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 38

39 Weitere Konzepte Abgeleitete Attributwerte im Album Nettopreis AlbumNr Preis Nettopreis := Preis * 1,17 Titel Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 39

40 Erweiterungen des s Erweiterungen des s Spezialisierung und Generalisierung Spezialisierung enstpricht IST-Beziehung: Album Spezialisierung von Produkt Generalisierung: Entities in einen allgemeineren Kontext. Album oder Film als Produkt Partitionierung: Spezialfall der Spezialisierung, mehrere disjunkte Entity-Typen. Partitionierung von Produkten in Album und Film. Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 40

41 Erweiterungen des s Erweiterungen des s /2 Komplexe Objekte Aggregierung: Entity aus einzelnen Instanzen anderer Entity-Typen zusammengesetzt. Album zusammengesetzt aus Titeln, Bonus-Video, Booklet Sammlung oder Assoziation: Mengenbildung. Team als Gruppe von Personen Beziehungen höheren Typs Spezialisierung und Generalisierung auch für Beziehungstypen. Beispiel: Beziehung bestellt zu bestelltperexpress spezialisiert. Beziehungen zwischen Beziehungsinstanzen: Beziehungen zweiter und höherer Ordnung Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 41

42 Weiteres Vorgehen beim Entwurf Weiteres Vorgehen beim Entwurf ierung von verschiedenen Sichten auf Gesamtinformation, z.b. für verschiedene Fachabteilungen eines Unternehmens konzeptueller Entwurf Analyse und Integration der Sichten Ergebnis: konzeptionelles Gesamtschema Verteilungsentwurf bei verteilter Speicherung Abbildung auf konkretes Implementierungsmodell (z.b. Relationenmodell) logischer Entwurf Datendefinition, Implementierung und Wartung physischer Entwurf Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 42

43 Weiteres Vorgehen beim Entwurf Sichtenintegration Analyse der vorliegenden Sichten in Bezug auf Konflikte Integration der Sichten in ein Gesamtschema Sicht #1 Sicht #2 Konsolidierung Globales Schema Sicht #3 Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 43

44 Weiteres Vorgehen beim Entwurf Integrationskonflikte Namenskonflikte: Homonyme / Synonyme Homonyme: Schloss; Kunde Synonyme: Auto, KFZ, Fahrzeug Typkonflikte: verschiedene Strukturen für das gleiche Element Wertebereichskonflikte: verschiedene Wertebereiche für ein Element Bedingungskonflikte: z.b. verschiedene Schlüssel für ein Element Strukturkonflikte: gleicher Sachverhalt durch unterschiedliche Konstrukte ausgedrückt Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 44

45 Weiteres Vorgehen beim Entwurf Verteilungsentwurf sollen Daten auf mehreren Rechnern verteilt vorliegen, muss Art und Weise der verteilten Speicherung festgelegt werden z.b. bei einer Relation KUNDE (KNr, Name, Adresse, PLZ, Konto) horizontale Verteilung: KUNDE_1 (KNr, Name, Adresse, PLZ, Konto) where PLZ < KUNDE_2 (KNr, Name, Adresse, PLZ, Konto) where PLZ >= vertikale Verteilung (Verbindung über KNr Attribut): KUNDE_Adr (KNr, Name, Adresse, PLZ) KUNDE_Konto (KNr, Konto) Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 45

46 Weiteres Vorgehen beim Entwurf Logischer Entwurf Sprachmittel: Datenmodell des ausgewählten Realisierungs -DBMS z.b. relationales Modell Vorgehensweise: 1 (automatische) Transformation des konzeptionellen Schemas z.b. ER relationales Modell 2 Verbesserung des relationalen Schemas anhand von Gütekriterien (Normalisierung, siehe Kapitel 5): Entwurfsziele: Redundanzvermeidung,... Ergebnis: logisches Schema, z.b. Sammlung von Relationenschemata Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 46

47 Weiteres Vorgehen beim Entwurf Datendefinition Umsetzung des logischen Schemas in ein konkretes Schema Sprachmittel: DDL und DML eines DBMS z.b. Oracle, DB2, SQL Server Datenbankdeklaration in der DDL des DBMS Realisierung der Integritätssicherung Definition der Benutzersichten Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 47

48 Weiteres Vorgehen beim Entwurf Physischer Entwurf Ergänzen des physischen Entwurfs um Zugriffsunterstützung bzgl. Effizienzverbesserung, z.b. Definition von Indexen Index Zugriffspfad: Datenstruktur für zusätzlichen, schlüsselbasierten Zugriff auf Tupel ( Schlüsselattributwert, Tupeladresse ) meist als B*-Baum realisiert Sprachmittel: Speicherstruktursprache SSL Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 48

49 Weiteres Vorgehen beim Entwurf Indexe in SQL create [ unique ] index indexname on relname ( attrname [ asc desc ], attrname [ asc desc ],... ) Beispiel create index AlbumIdx on Album (Titel) Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 49

50 Weiteres Vorgehen beim Entwurf Notwendigkeit für Zugriffspfade Beispiel: Tabelle mit 10 GB Daten, Festplattentransferrate ca. 10 MB/s Operation: Suchen eines Tupels (Selektion) Implementierung: sequentielles Durchsuchen Aufwand: /10 = sec. 17 min. Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 50

51 Weiteres Vorgehen beim Entwurf Implementierung und Wartung Phasen der Wartung, der weiteren Optimierung der physischen Ebene, der Anpassung an neue Anforderungen und Systemplattformen, der Portierung auf neue Datenbankmanagementsysteme etc. Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 51

52 Weiteres Vorgehen beim Entwurf Zusammenfassung Phasen des Datenbankentwurfs Datenbankmodell, Datenbankschema, Datenbank(instanz) Entity-Relationship-Modell ER-Erweiterungen: Spezialisierung, Generalisierung, Partitionierung weitere Entwurfsschritte Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 52