Vorlesung Datenbankmanagementsysteme

Transkript

1 Vorlesung Datenbankmanagementsysteme ER-Modellierung M. Lange, S. Weise Folie #3-1

2 ER-Modellierung Wiederholung - Drei-Ebenen-Schema-Architektur - ANSI-SPARC-Architektur - Fünf-Schichten-Architektur ER-Modellierung - Datenbankmodelle - Datenbankentwurf im ER-Modell - Erweiterungen des ER-Modells Zusammenfassung M. Lange, S. Weise Folie #3-2

3 Wiederholung M. Lange, S. Weise Folie #3-3

4 Architekturen von DB Betrachtung von DB-Architekturen aus verschiedenen Blickwinkeln: - Schema-Architektur Zusammenhang zwischen konzeptuellem, internem und externem Schema Einordnung der DB-Anwendungsprogramme in diese Schemata - System-Architektur Aufbau des DBS aus Komponenten, Bausteinen oder Werkzeugen Normierung von Schnittstellen zw. den Komponenten Keine Normierung der Komponenten selbst - Anwendungsarchitektur Ablauf der Anwendungsentwicklung mit Datenbanken Beschreibung von erforderlichen Vorgängen und Arbeitsschritten M. Lange, S. Weise Folie #3-4

5 Schema-Architektur Internes Schema - Beschreibung der physikalischen Speicherstrukturen - Nutzung eines physischen Datenmodells - Details der Datenspeicherung und Zugriffspfade Konzeptuelles Schema - Beschreibung der Gesamtstruktur der DB für alle Nutzer - Nutzung eines logischen (abstrahierenden) Datenmodells mit Entitäten, Datentypen, Beziehungen, Benutzeroperationen - Verbergen der Details zu physischen Speicherstrukturen Externes Schema - Benutzersichten als Blick auf einen Teil der Datenbank für Nutzergruppen - Nutzung eines logischen (abstrahierenden) Datenmodells - Verbergen der übrigen Daten M. Lange, S. Weise Folie #3-5

6 Schema-Architektur II Externes Schema 1... Externes Schema n Konzeptuelles Schema Internes Schema Anfragebearbeitung Datendarstellung M. Lange, S. Weise Folie #3-6

7 Beispiel: Konzeptuelle Sicht Relationale Darstellung der Daten in zwei Tabellen mit Fremdschlüsselbeziehung [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 2-6] M. Lange, S. Weise Folie #3-7

8 Beispiel: Externe Sicht Präsentation der Daten in einer flachen Relation [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 2-7] M. Lange, S. Weise Folie #3-8

9 Beispiel: Externe Sicht II Präsentation der Daten in einer hierarchischen Relation [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 2-7] 2-8] M. Lange, S. Weise Folie #3-9

10 Beispiel: Interne Darstellung [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 2-9] M. Lange, S. Weise Folie #3-10

11 Datenunabhängigkeit Def.: Stabilität der Schnittstelle gegen Änderungen Physische Datenunabhängigkeit (Implementierungsunabhängigkeit) - Änderungen der Dateiorganisation und Zugriffpfade haben keinen Einfluss auf das konzeptuelle Schema Logische Datenunabhängigkeit (Anwendungsunabhängigkeit) - Änderungen am konzeptuellen und gewissen externen Schemata haben keine Auswirkungen auf andere externe Schemata und Anwendungsprogramme Mögliche Auswirkungen von Änderungen am konzeptuellen Schema - Eventuell externe Schemata betroffen (Ändern von Attributen) - Eventuell Anwendungsprogramme betroffen (Rekompilieren der Anwendungsprogramme, eventuell Änderungen nötig) - Überwachung und Erkennung durch DBMS M. Lange, S. Weise Folie #3-11

12 ANSI-SPARC-Architektur ANSI: American National Standards Institute SPARC: Standards Planning and Requirement Committee Vorschlag von 1978 Im Wesentlichen Verfeinerung der Drei-Ebenen-Schema- Architektur - Verfeinerung von interner Ebene / Betriebssystem - Mehr interaktive und Programmier-Komponenten - Bezeichnung und Normierung der Schnittstellen M. Lange, S. Weise Folie #3-12

13 ANSI-SPARC-Architektur II Externe Ebene Konzeptuelle Ebene Interne Ebene Benutzerkomponenten Transformationskomponenten Anfragen Updates Optimierer Auswertung Plattenzugriff P 1... DB Operationen Einbettung Data Dictionary P n Masken Programmierkomponenten Sichtdefinition Datendefinition Dateiorganisation Definitionskomponenten M. Lange, S. Weise Folie #3-13

14 Fünf-Schichten-Architektur Basis: Idee von Senko (1973) Weiterentwicklung von Härder (1987) durch operationale Schnittstellen Umsetzung im Rahmen des IBM-Prototyps System R Genauere Beschreibung der Transformationskomponenten eines DBMS - Schrittweise Transformation von Anfragen/Änderungen bis hin zu Zugriffen auf Speichermedien - Definition der Schnittstellen zwischen Komponenten M. Lange, S. Weise Folie #3-14

15 Fünf-Schichten-Architektur II Schnittstellen - Mengenorientierte Schnittstelle (MOS): Stellt deklarative DML auf Tabellen, Sichten, Zeilen bereit Z.B. SQL - Satzorientierte Schnittstelle (SOS): Stellt navigierenden Zugriff auf interner Darstellung von Relationen bereit Z.B. auf typisierte Datensätze, logische Dateien, logische Zugriffspfade (Indizes) Typisiert aufgrund unterschiedlicher Relationstypen - Interne Satzschnittstelle (ISS): Einheitliche Verwaltung interner Tupel (keine Typisierung) Implementierung der Speicherstrukturen der Zugriffspfade Implementierung von Operationen (z.b. Sortierung, Transaktionsverwaltung) M. Lange, S. Weise Folie #3-15

16 Fünf-Schichten-Architektur III Schnittstellen (Forts.) - Systempufferschnittstelle (SPS): Z.B. Seiten, Seitenadressen Freigeben und Bereitstellen von Seiten - Datei- oder Seitenschnittstelle (DS) des Betriebssystems: Hole Seite, schreibe Seite - Geräteschnittstelle (GS) des Betriebssystems : Spuren, Zylinder Armbewegungen M. Lange, S. Weise Folie #3-16

17 Fünf-Schichten-Architektur IV Mengenorientierte Schnittstelle Satzorientierte Schnittstelle Interne Satzschnittstelle Systempuffer Schnittstelle Datei Schnittstelle Geräte Schnittstelle Datensystem Zugriffssystem Speichersystem Pufferverwaltung Betriebssystem Übersetzung, Zugriffpfadauswahl, Zugriffskontrolle, Integritätskontrolle Data Dictionary, Currency Pointer, Sortierung, Transaktionsverwaltung Record Manager, Zugriffpfadverwaltung Sperrverwaltung, Log/Recovery Systempufferverwaltung mit Seitenwechselstrategie Externspeicherverwaltung Relationen, Sichten Externe Sätze, Index Strukturen Interne Sätze, Bäume, Hashtab. Segmente, Seiten Dateien, Blöcke Zylinder, Spuren M. Lange, S. Weise Folie # Fünf-Schichten-Architektur

18 ER-Modellierung M. Lange, S. Weise Folie #3-18

19 Datenbankmodelle Grundlagen von Datenbankmodellen - Datenbankmodell System von Konzepten zur Beschreibung von Datenbanken Festlegung von Syntax und Semantik von Datenbankbeschreibungen für ein Datenbanksystem - Datenbankbeschreibungen = Datenbankschemata M. Lange, S. Weise Folie #3-19

20 Datenbankmodelle II Festlegungen im Datenbankmodell - statische Eigenschaften Objekte Beziehungen inklusive der Standard-Datentypen, die Daten über die Beziehungen und Objekte darstellen können - dynamische Eigenschaften Operationen Beziehungen zwischen Operationen - Integritätsbedingungen an Objekte Operationen M. Lange, S. Weise Folie #3-20

21 Datenbankmodelle III Arten von Datenbankmodellen - Klassische Datenbankmodelle sind speziell geeignet für große Informationsmengen mit relativ starrer Struktur und die Darstellung statischer Eigenschaften und Integritätsbedingungen - Entwurfsmodelle (abstrakt, erste formale Beschreibung des Fachproblems) (E)ER-Modell UML, - Realisierungsmodelle (konkret) Relationenmodell objektorientierte Modelle, M. Lange, S. Weise Folie #3-21

22 Datenbankentwurf im ER-Modell Entity-Relationship-Modelle (ERM) - P. P. Chen im Jahre Entwurfsmodell (keine Anfragesprache und kein DBMS) - Beliebt zur konzeptuellen Modellierung beim Datenbankentwurf - Nutzung durch viele Entwurfswerkzeuge - Bildhafte Darstellung von ER-Schemata (ER-Diagramme) - Übersetzungsalgorithmus zum relationalen Modell - Viele ERM-Varianten M. Lange, S. Weise Folie #3-22

23 Datenbankentwurf im ER-Modell II Grundlegende Konzepte - Entity Objekt der realen oder der Vorstellungswelt, über das Informationen zu speichern sind z.b. Vorlesungsveranstaltung, Buch, Lehrperson, Produkte, oder Informationen über Ereignisse: Prüfungen, Bestellungen - Relationship Beschreibung einer Beziehung zwischen Entities z.b. eine Lehrperson hält eine Vorlesung, Kunde bestellt ein Album - Attribut Repräsentation einer Eigenschaft von Entities oder Beziehungen z.b. die ISBN eines Buchs, der Titel einer Vorlesung, oder das Semester, in dem eine Vorlesung gehalten wird M. Lange, S. Weise Folie #3-23

24 Datenbankentwurf im ER-Modell III Fragen des konzeptuellen Entwurfs mit ERM - Welche Entitäten und Beziehungen sind interessant? (universum of discourse) - Welche Informationen der Entitäten und Beziehungen sollen festgehalten werden? - Welche Integritätsbedingungen oder Geschäftsregeln müssen berücksichtigt werden? M. Lange, S. Weise Folie #3-24

25 Datenbankentwurf im ER-Modell IV [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-10] M. Lange, S. Weise Folie #3-25

26 Grundkonzepte des ERM Werte - Werte: primitive Datenelemente, die direkt darstellbar sind - Wertemengen sind beschrieben durch Datentypen, die neben einer Wertemenge auch die Grundoperationen auf diesen Werten charakterisieren - ER-Modell: vorgegebene Standard-Datentypen, etwa die ganzen Zahlen int, die Zeichenketten string, Datumswerte date etc. - Jeder Datentyp stellt Wertebereich mit Operationen und Prädikaten (Aussagen über Werte, z.b. between) dar M. Lange, S. Weise Folie #3-26

27 Grundkonzepte des ERM II 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 E1, E2, - Menge der aktuellen Entities: σ(e 1 ) = {e 1, e 2,..., e n } [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-12] M. Lange, S. Weise Folie #3-27

28 Grundkonzepte des ERM III 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 - textuelle Notation: E(A 1 : D 1,..., A m : D m ) [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-13] M. Lange, S. Weise Folie #3-28

29 Grundkonzepte des ERM IV Komplexe Attribute - Unterstützung durch einige ERM-Varianten - Mehrwertiges Attribut: enthält Menge von Werten - Abgeleitetes Attribut: Wert wird anhand einer Berechnungsvorschrift aus nicht abgeleiteten Attributen ermittelt - Strukturiertes Attribut: wird durch weitere Attribute beschrieben Wert eines strukturierten Attributes entspricht Verkettung der Unterattributwerte - Optionales Attribut: Attributwert nicht für jede Entität vorhanden M. Lange, S. Weise Folie #3-29

30 Grundkonzepte des ERM V 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 durch Markieren mit Unterstreichung: E(, S 1,, S i, ) M. Lange, S. Weise Folie #3-30

31 Grundkonzepte des ERM VI 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 Beziehungstypen R gehören n Entity-Typen E 1,, E n - Ausprägung eines Beziehungstyps: σ(r) σ(e 1 ) σ(e 2 ) σ(e n ) M. Lange, S. Weise Folie #3-31

32 Grundkonzepte des ERM VII Beziehungstypen (Forts.) - Beispiel - 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) [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-16] M. Lange, S. Weise Folie #3-32

33 Grundkonzepte des ERM VIII Beziehungsattribute - Beziehungen können ebenfalls Attribute besitzen - Attributdeklarationen werden beim Beziehungstyp vorgenommen - gilt auch hier für alle Ausprägungen eines Beziehungstyps - textuelle Notation: R(E 1,..., E n ; A 1,..., A k ) [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-17] M. Lange, S. Weise Folie #3-33

34 Beziehungen Merkmale - 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 M. Lange, S. Weise Folie #3-34

35 Stelligkeit von Beziehungen Zwei- vs. mehrstellige Beziehungen [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-19] M. Lange, S. Weise Folie #3-35

36 Stelligkeit von Beziehungen II Zwei- vs. mehrstellige Beziehungen: Ausprägungen am Beispiel [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-20] M. Lange, S. Weise Folie #3-36

37 Stelligkeit von Beziehungen III Zwei- vs. mehrstellige Beziehungen: Rekonstruktion der Ausprägungen Bei mehrstelliger Beziehung: 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 [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-21] M. Lange, S. Weise Folie #3-37

38 Kardinalität von Beziehungen 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 [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-22] M. Lange, S. Weise Folie #3-38

39 Kardinalität von Beziehungen II 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 [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-23] M. Lange, S. Weise Folie #3-39

40 Kardinalität von Beziehungen III n:1-beziehungen - 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. [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-24] M. Lange, S. Weise Folie #3-40

41 Kardinalität von Beziehungen IV m:n-beziehungen - Keine Restriktionen - Beispiel: Bestellung umfasst Produkte [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-25] M. Lange, S. Weise Folie #3-41

42 Kardinalität von Beziehungen V Einschränkung der möglichen Teilnahmen von Instanzen der beteiligten Entity- Typen an der Beziehung, durch Vorgabe eines minimalen und eines maximalen Wertes 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 * [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-26] M. Lange, S. Weise Folie #3-42

43 Kardinalität von Beziehungen VI 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, da jede Instanz aus E 1 genau einer Instanz aus E 2 zugeordnet ist M. Lange, S. Weise Folie #3-43

44 Kardinalität von Beziehungen VII 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 Produkten 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 Lieferanten geliefert, aber ein Lieferant kann durchaus mehrere Produkte liefern. M. Lange, S. Weise Folie #3-44

45 Kardinalität von Beziehungen VIII Alternative Kardinalitätsangaben [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-29] M. Lange, S. Weise Folie #3-45

46 Abhängige Entity-Typen Abhängiger Entity-Typ: Identifikation über funktionale Beziehung Auch schwacher Entity-Typ (weak entity) Instanzen eines abhängigen Entity-Typen existieren nur in Abhängigkeit von anderen Entities Bestellungen können ohne Bestellpositionen exisitieren, aber nicht umgekehrt. Abhängige Entities im ER-Modell: Funktionale Beziehung als Schlüssel [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-30] M. Lange, S. Weise Folie #3-46

47 Abhängige Entity-Typen II Mögliche Ausprägung für abhängige Entities [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-31] M. Lange, S. Weise Folie #3-47

48 Abhängige Entity-Typen III Alternative Notation nach Elmasri/Navathe [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-32] M. Lange, S. Weise Folie #3-48

49 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 [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-33] M. Lange, S. Weise Folie #3-49

50 IST-Beziehung II Eigenschaften der IST-Beziehung - Album IST Produkt - 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) mit Produkt#, Titel, Preis von Produkt - Nicht nur die Attributdeklarationen vererben sich, sondern auch jeweils die aktuellen Werte für eine Instanz M. Lange, S. Weise Folie #3-50

51 IST-Beziehung III Alternative Notation - Hervorhebung der speziellen Rolle der IST-Beziehung durch Funktionspfeil [Quelle: Heuer, Saake: Foliensatz Datenbanken I, 4-35] M. Lange, S. Weise Folie #3-51

52 IST-Beziehung IV Kardinalitätsangaben - 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 M. Lange, S. Weise Folie #3-52

53 Erweiterungen des ER-Modells Spezialisierung und Generalisierung - Spezialisierung Entspricht IST-Beziehung Beispiel: Album als Spezialisierung von Produkt - Generalisierung Entities in einen allgemeineren Kontext Beispiel: Album oder Film als Produkt - Partitionierung Spezialfall der Spezialisierung Mehrere disjunkte Entity-Typen Beispiel: Partitionierung von Produkten in Album und Film M. Lange, S. Weise Folie #3-53

54 Erweiterungen des ER-Modells II Komplexe Objekte - Aggregierung Entity aus einzelnen Instanzen anderer Entity-Typen zusammengesetzt Beispiel: Album zusammengesetzt aus Titeln, Bonus-Video, Booklet - Sammlung oder Assoziation Mengenbildung Beispiel: 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 M. Lange, S. Weise Folie #3-54

55 Zusammenfassung M. Lange, S. Weise Folie #3-55

56 Datenbankmodelle Ein Datenbankmodell ist ein System von Konzepten zur Beschreibung von Datenbanken. Es legt Syntax und Semantik von Datenbankbeschreibungen für ein Datenbanksystem fest. Arten von Datenbankmodellen - Klassische Datenbankmodelle sind speziell geeignet für große Informationsmengen mit relativ starrer Struktur und die Darstellung statischer Eigenschaften und Integritätsbedingungen - Entwurfsmodelle (abstrakt, erste formale Beschreibung des Fachproblems) (E)ER-Modell UML, - Realisierungsmodelle (konkret) Relationenmodell objektorientierte Modelle, M. Lange, S. Weise Folie #3-56

57 Datenbankentwurf im ER-Modell II Grundlegende Konzepte - Entity Objekt der realen oder der Vorstellungswelt, über das Informationen zu speichern sind z.b. Vorlesungsveranstaltung, Buch, Lehrperson, Produkte, oder Informationen über Ereignisse: Prüfungen, Bestellungen - Relationship Beschreibung einer Beziehung zwischen Entities z.b. eine Lehrperson hält eine Vorlesung, Kunde bestellt ein Album - Attribut Repräsentation einer Eigenschaft von Entities oder Beziehungen z.b. die ISBN eines Buchs, der Titel einer Vorlesung, oder das Semester, in dem eine Vorlesung gehalten wird M. Lange, S. Weise Folie #3-57