Übersicht Inhalt: Überblick Entity Relation Ship Diagramm Attribute Relationenmodell (Tabellendarstellung) Normalisierung Integritätsbedingungen Christoph Riewerts Seite 1
Überblick Phasen: Begriffe/Merkmale: Analyse-Phase Informationsobjekte ERD (oder auch ERM) Design-Phase Tabellen Datenbankschema Integritätsbedingung Programmier-Phase Datensätze, Indizes Speicherstrukturen Seite 2
ER-Diagramm (ERD): Entity Relationship (ER) Diagramm Ein ER-Diagramm ist die grafische Darstellung von Informationsobjekten (auch Entitäten genannt) und deren Beziehungen untereinander (Peter Chen). Informationsobjekt: Ein Informationsobjekt ist ein individuelles und identifizierbares Exemplar von Dingen, Personen oder Begriffen der realen oder der Vorstellungswelt. gezeichnet im ERD als Rechteck Namensvergabe: Substantiv wird durch Attribute näher beschrieben Beispiele (für Personen, Dinge, Aktionen und abstrakte Begriffe): Projekt Mitarbeiter Fertigmeldung Kündigung Bestellung Artikel Abteilung Seite 3
Beziehung: Entity Relationship (ER) Diagramm Eine Beziehung assoziiert wechselseitig zwei (oder mehr) Entitäten (Informationsobjekte): gezeichnet im ERD als Raute mit einer Linie zur jeweiligen Entität Namensvergabe: Verb, um die Darstellung Entität-Beziehung-Entität von links nach rechts lesen zu können oder Substantiv, wenn aus Gründen der Vereinheitlichung ein Hauptwort gefordert ist oder mehr als 2 Entitäten assoziiert sind. wird durch Attribute näher beschrieben Es gibt drei Typen von Beziehungen (nach Chen): 1:1, 1:n und n:m, die man mit dem Konditionalzeichen c erweitern kann, so dass Kann- und Muss-Beziehungen unterschiedlich dargestellt werden können, wie z.b. 1:c, 1:mc und n:mc mit n = 1,2,3,4, und m = 1,2,3,4, c = 0 oder 1 und mc = 0,1,2,3,4, Seite 4
Entity Relationship (ER) Diagramm 1:1-Beziehung (Muss-Beziehung) 1:c-Beziehung (Kann-Beziehung) 1:n-Beziehung (Muss-Beziehung): Zu jedem Vater gibt es ein oder mehrere Kinder, jedes Kind hat genau einen Vater. 1:mc-Beziehung (Kann-Beziehung): Es gibt Männer, die haben keine Kinder. Seite 5
Entity Relationship (ER) Diagramm n:m-beziehung (Muss-Beziehung): Ein Schüler muss mindestens einen Kurs besuchen. Umgekehrt muss jeder Kurs von mindestens einem Schüler belegt werden. nc:mc-beziehung (Kann-Beziehung): Ein Schüler kann ein Fach oder mehrere Fächer belegen, ein Fach kann von mehreren Schülern belegt sein, jedoch auch von keinem. Implizite Beziehung: (heißt im INNOVATOR hierarchische Beziehung ) Buch 1 gibt es mc als Bibliotheksexemplar Seite 6
Entity Relationship (ER) Diagramm Implizite Beziehung (is part of): Rechnung 1 n enthält Rechnungsposition Implizite Beziehung (is a): Artikel auf Lager oder auch nicht Geschäftspartner kann ein Lieferant oder ein Kunde sein. Lagerartikel Geschäftspartner 1 c ist vorh. als 1 ist ein c c Sortimentsartikel Lieferant Kunde Rekursive Beziehung (mit Rollenbezeichnungen): c Bauteil mc Baugruppe Teil besteht aus Mitarbeiter c Vorgesetzter ist Chef von mc Untergebener Mitarbeiter Seite 7
Entity Relationship (ER) Diagramm Gegenüberstellung von (1,m,n)- und (min, max)-notation: Eine Beziehung R = (E1, E2) wird in der (min, max)-notation durch Angabe der zwei Komplexitätsgrade Comp(E1, R) und Comp(E2, R) beschrieben, wobei für die Eckwerte von min und max gilt: 0 ge min ge 1 ge max ge * mit ge = grössergleich: Weitere alternative Darstellungsformen der Kardinalität ( Krähenfüße ): (1,M,N)-Notation (min, max)-notation Comp(E1, E2) Comp(E1, R) Comp(E2, R) 1:1 (1,1) (1,1) 1:c (0,1) (1,1) 1:n (1,*) (1,1) 1:nc (0,*) (1,1) mc:nc (0,*) (0,*) Bitte bei (min, max)-notation Umkehrung beachten! Seite 8
Entity Relationship (ER) Diagramm Übung: Tragen Sie in das nebenstehende ERD zusätzlich die Lieferant 1 1 c besitzt Konto (min, max)-notation ein. erhält mc Bestellung nc enthält m Artikel 1 besteht aus n Bestellposition Seite 9
Attribute von Entitäten: Identifizierende Attribute (Schlüsselattribute): Primärschlüssel (i. d. R. durch Unterstrich gekennzeichnet, obligatorisch, kann zusammengesetzt sein) Sekundärschlüssel (alternativer Primärschlüssel) Fremdschlüssel (existiert in anderen Entitäten als Primärschlüssel) Beschreibende Attribute (sind optional): sollten funktional vom Primärschlüssel abhängen (2.Normalform) sollten untereinander nicht funktional abhängen (3. Normalform) Darstellung: als Liste Attribute Mitarbeiter = (Pers-Nummer, Name, Geburtsdatum) in einer Ellipse als Erweiterung im ERD: Kontostand Kontonr Konto Seite 10
Attribute von Beziehungen: Primärschlüssel von den assoziierten Informationsobjekten ( = Fremdschlüssel) Beschreibende Attribute (sind optional) Beispiel: n:m-beziehung Attribute Mitarbeiter = (Pers-Nummer, Name, Geburtsdatum,..) Projekt = (Projekt-ID, Projektlaufzeit,..) Primärschlüssel Primärschlüssel Mitarbeiter n arbeitet in mc Projekt arbeitet in = (Pers-Nummer, Projekt-ID, Kapazität) Kapazität ist ein beschreibendes Attribut Seite 11
Übung (IM12): Entity Relationship (ER) Diagramm Entwerfen Sie für den nachstehenden Geschäftsvorfall ein Entity Relationship Diagramm (ERD) und geben Sie die Attribute an, die zur Beschreibung der Informationsobjekte und der Beziehung(en) notwendig sind. Ein landwirtschaftlicher Betrieb produziert mehrere Produkte. Diese Produkte können sein: verschiedene Getreide, verschiedene Gemüse und Obst. Ein Produkt wird im Gegenzug von mehreren Betrieben produziert. Die bei der Produktion eines Produkts verwendete Fläche, gemessen in qm, soll erfasst werden. Zur Kennzeichnung eines Betriebs wird der Name des Anwesens, seine Adresse und die gesamte Betriebsfläche (Anbaufläche plus Verwaltungsfläche) herangezogen. Seite 12
Übung (IM13): Entity Relationship (ER) Diagramm Stellen Sie für die folgenden Aussagen ein Entity Relationship Diagramm (ERD) auf und diskutieren Sie die unterschiedlichen Möglichkeiten der Darstellung, d.h. Anzahl der Entitäten und Attribute. In einer bestimmten Stadt gibt es mehrere Schulen, die jeweils von einem Direktor geleitet werden. Jeder Schüler gehört zu einer Schulstufe, innerhalb derer er bestimmte fachspezifische Kurse besuchen muss und andere wahlweise belegen kann. Jeder Kurs wird von einem Lehrer geleitet. Erweiterung: Jeder Lehrer unterrichtet mindestens zwei Fächer. Beispiele für Schulstufen: Sekundarstufe 1, Oberstufe,.. Beispiele für Kurse: Engl. Literatur, Musikgeschichte, Spanisch für Fortgeschrittene,.. Beispiele für Fächer. Englisch, Biologie, Sport,.. Seite 13
Relationenmodell: Relationenmodell Beim Übergang von der Analyse zum Design und damit bei der Wahl einer Relationalen Datenbank wird das Datenmodell in ein Relationenmodell überführt. In einer relationalen Datenbank sind alle Informationen explizit auf der logischen Ebene genau auf eine Art repräsentiert: als Werte in Tabellen (= Relationen) (E.F. Codd) Primärschlüssel Reihenfolge der Zeilen und Reihenfolge der Spalten sind ohne Bedeutung. Die Raute des Informationsmodells wird umgesetzt und erscheint als Fremdschlüssel- Beziehung in einer Tabelle. Attributwerte sind immer vom gleichen Typ (Domäne) Buch- Signatur Vormerkung Name Datum SN-32 Mayer 01.02.2007 BB-45 Mayer 01.02.2007 AW-90 Müller 06.02.2007 SN-32 Müller 13.02.2007 Attribute (Spalte) Ausprägung (Tupel) Seite 14
1:n Beziehung im Relationenmodell: Relationenmodell Der Primärschlüssel der 1-Relation erscheint als zusätzliches Attribut in der n-relation und wird dort als Fremdschlüssel bezeichnet: Abteilungs-_ Kürzel Abteilung Anzahl MA 1 beschäftigt n Name Angestellter Angestellter- ID Tabelle Seite 15
Relationenmodell Übung zur 1:n Beziehung im Relationenmodell: Wie sehen die 2 Tabellen aus incl. Fremdschlüssel, wenn man die Relation beschäftigt nicht dem Angestellten zuordnet - wie vorgeschrieben -, sondern der Abteilung (s. Bild)? Diskutieren Sie diese Alternative. Abteilungs-_ Kürzel Abteilung Anzahl MA 1 beschäftigt n Name Angestellter Angestellter- ID Tabelle Seite 16
Mehrfachattribute: Relationenmodell Sind in der 1. Normalform (s. Normalisierung) nicht erlaubt Beispiel: Mitarbeiter ist in mehreren Wohnorten gemeldet Mitarbeiter = (Mitarbeiter-Nummer, Adressen, Name) Lösung 1, wenn Anzahl der Wohnsitze begrenzt und bekannt Mitarbeiter = (Mitarbeiter-Nummer, Adresse1, Adresse2, Adresse3, Name) Lösung 2 (Entität statt Attribut) Mitarbeiter = (Mitarbeiter-Nummer, Name) Adresse = (Wohnsitz) Frage: wenn jetzt mehrere Mitarbeiter dieselbe Adresse haben? Seite 17
n:m Beziehung im Relationenmodell: Relationenmodell Aus einer n:m Beziehung im Datenmodell werden zwei 1:n Beziehungen mit einer sogenannten Beziehungsentität: Mitarbeiter n arbeitet in mc Projekt Tabelle Seite 18
Übung (IM14): Relationenmodell und SA-Modell Stellen Sie für die folgende Aussage ein Entity Relationship Diagramm (ERD) auf. Editieren Sie anschließend das ERD als Relationenmodell mit dem INNOVATOR, wobei Sie bitte alle Attribute (mit Kennzeichnung der Primär- und Fremdschlüssel) in das ERD mit einzeichnen lassen. Kunden können aus einem Veranstaltungskalender Seminare buchen. Dieselben Seminare werden zu unterschiedlichen Zeiten angeboten, wobei auch die Dauer differieren kann. Titel und Zielsetzung jedoch bleiben gleich. Die Veranstaltungen werden von Dozenten durchgeführt, für die jeweils Name, Adresse und Biografie gespeichert sind. Bei der Vergabe der notwendigen Attribute orientieren Sie sich bitte an folgenden Fragestellungen, für die das Modell die entsprechenden Antworten liefern muss; modellieren Sie die fünf Auswerteprozesse in einem Datenflussdiagramm (SA- Methode): 1) Wie viele Kunden haben das Seminar mit dem Titel Function Point Analyse gebucht? (DFD nebenstehend) 2) Welche Ausbildung hatten die Dozenten, die 2006 das Seminar über SW-Metriken gehalten hatten? 3) Welche Seminare sind ausgebucht? 4) Wie viele Kunden haben sich bis Montag letzter Woche angemeldet? 5) Welche Kunden haben neue Seminare gebucht, obwohl sie alte Rechnungen noch nicht bezahlt haben? Seminartitel Anzahl der Kunden Anzahl Buchungen ermitteln bucht Veranstaltung Seite 19
Unnormalisierte Tabelle: Redundante Datenhaltung Normalisierung Speicheroperationen wie Neuzugang, Löschen und Aktualisieren können zu einer inkonsistenten Datenhaltung führen Schwierige Handhabung (z.b. wegen der Mehrfach-Attribute) Mitarbeiter MA-Nr. Name Abt-Nr Abt-Name Zeit [%] Projektnr Projektname 112224 Meyer E7 Entwicklung 80 20 S30001 S30002 SW-Installation HW-Installation 112225 Graf K Konstruktion 100 S30020 PM-Einsatz 112226 König K Konstruktion 20 80 S30020 S30021 PM-Einsatz CASE-Konzept 112227 Keiser ZEU Zentraleinkauf 100 S30022 PC-Angebot Aufgabe: Bringen Sie die Tabelle in die 1. Normalform. Seite 20
1. Normalform Normalisierung Eine Tabelle (Relation) ist in der 1. Normalform, wenn jedes Attribut zu einem bestimmten Schlüsselwert höchstens einen(!) Attributwert besitzt Mitarbeiter MA-Nr. Name Abt-Nr Abt-Name Zeit [%] Projektnr Projektname 112224 Meyer E7 Entwicklung 80 S30001 SW-Installation 112224 Meyer E7 Entwicklung 20 S30002 HW-Installation 112225 Graf K Konstruktion 100 S30020 PM-Einsatz 112226 König K Konstruktion 20 S30020 PM-Einsatz 112226 König K Konstruktion 80 S30021 CASE-Konzept 112227 Keiser ZEU Zentraleinkauf 100 S30022 PC-Angebot Aufgabe: Bringen Sie die Tabelle in die 2. Normalform. Seite 21
2. Normalform Normalisierung Eine Tabelle (Relation) ist in der 2. Normalform, wenn sie in der 1. Normalform ist und jedes nicht dem Schlüssel angehörende Attribut funktional abhängig ist vom Gesamtschlüssel, nicht aber von einzelnen Schlüsselteilen. Mitarbeiter MA-Nr. Name Abt-Nr Abt-Name 112224 Meyer E7 Entwicklung 112225 Graf K Konstruktion 112226 König K Konstruktion 112227 Keiser ZEU Zentraleinkauf Projektzugehörigkeit MA-Nr. Projektnr Zeit [%] 112224 S30001 80 112224 S30002 20 112225 S30020 100 Projektnr S30001 S30002 S30020 S30021 S30022 Projekt Projektname SW-Installation HW-Installation PM-Einsatz CASE-Konzept PC-Angebot 112226 S30020 20 112226 S30021 80 112227 S30022 100 Aufgabe: Bringen Sie die Tabelle(n) in die 3. Normalform. Seite 22
3. Normalform Normalisierung Eine Tabelle (Relation) ist in der 3. Normalform, wenn sie in der 2. Normalform ist und jedes Attribut direkt vom Schlüssel abhängig ist. Mitarbeiter MA-Nr. Name Abt-Nr 112224 Meyer E7 112225 Graf K 112226 König K 112227 Keiser ZEU Abteilung Abt-Nr Abt-Name E7 Entwicklung K Konstruktion ZEU Zentraleinkauf Projektzugehörigkeit Projektnr S30001 S30002 S30020 S30021 S30022 Projekt Projektname SW-Installation HW-Installation PM-Einsatz CASE-Konzept PC-Angebot MA-Nr. Projektnr Zeit [%] 112224 S30001 80 112224 S30002 20 112225 S30020 100 112226 S30020 20 112226 S30021 80 112227 S30022 100 Seite 23
Übung: Normalisierung Kennzeichnen Sie in den vier Tabellen aus dem Normalisierungsbeispiel (s.v.) diejenigen Attribute, die Fremdschlüssel sind. Wandeln Sie danach die Tabellen in ein ERD um unter Verwendung der Tabellennamen für die Entitäten. Die richtigen Kardinalitäten können aus den Beispieleinträgen abgeleitet werden. Spezifizieren Sie abschließend bitte noch den Prozess Mitarbeiter-Tabelle zusammenstellen, der aus den einzelnen Attributen der normalisierten Tabellen die unnormalisierte Mitarbeiter-Tabelle erzeugt. Verwenden Sie dazu das DFD (mit dem Innovator) und modellieren Sie die normalisierten Tabellen als Datenspeicher. Seite 24
Übung (IM15) zum Thema: Weinhandlung Entity Relationship (ER) Diagramm Die Winzer Felsengarten, Sonnenberg und Neckartal stellen folgende Weine her: Winzer Felsengarten: Kerner und Riesling. Winzer Sonnenberg: Trollinger, Riesling und Weißherbst. Winzer Neckartal: Trollinger und Spätburgunder Folgende Kunden haben Weine erworben: Kunde Jim Panse kauft Kerner vom Felsengarten und Riesling vom Sonnenberg Kunde Paul Aner kauft Riesling und Trollinger vom Sonnenberg und Spätburgunder vom Neckartal Tragen Sie diese Werte in die Tabellen ein, die durch nebenstehendes ERD spezifiziert wurden. Werten Sie die Tabellen aus, indem Sie aus den vorhandenen Einträgen für die Kunden eine Rechnung erstellen. Beurteilen Sie diese Rechnung und stellen gegebenenfalls ein verbessertes ERD auf. n Winzer m n liefert Winzername Kundenname Winzername Weinsorte erzeugt Kunde m Wein n m kauft Weinsorte Kundenname Seite 25
Integritätsbedingungen sind notwendig, um mit den Abhängigkeiten der Tabellen (Fremdschlüsselbeziehungen) richtig umgehen zu können: Anwendungsbezogene Integrität (domain integrity): Zwischen den Attributen bestehen inhaltliche Abhängigkeiten, z.b. Summenattribut Wertebereich von Attributen soll eingehalten werden Zwei Beziehungen sollen sich gegenseitig ausschließen. Ganzheitliche Integrität (entity integrity): Integritätsbedingungen Kein Attribut, das Teil eines Primärschlüssels einer Tabelle ist, darf Nullwerte annehmen. Referenzielle Integrität / Beziehungsintegrität (referential integrity): Für jeden vom Nullwert verschiedenen Fremdschlüssel muss ein entsprechender Primärschlüssel aus derselben Domäne existieren. Für jeden Fremdschlüssel sind festzulegen: Darf der Fremdschlüssel Nullwerte annehmen? Was soll mit dem Fremdschlüssel geschehen, wenn der Primärschlüssel gelöscht bzw. modifiziert wird? Seite 26
Integritätsbedingungen Beispiele für Beziehungsintegrität (Löschen des Primärschlüssels): 1.) Weitergabe der Löschung (CASCADE), d.h. alle Tupel der Tabelle mit einem Fremdschlüssel, der dem gelöschten Primärschlüssel entspricht, werden ebenfalls gelöscht. Seite 27
Integritätsbedingungen Beispiele für Beziehungsintegrität (Löschen des Primärschlüssels): 2.) Bedingte Löschung (RESTRICT, default), d.h. ein Tupel in der Tabelle mit dem Primärschlüssel kann nur dann gelöscht werden, wenn in der referierenden Tabelle kein Tupel mehr mit einem Fremdschlüssel existiert, der dem Primarschlüssel entspricht. Seite 28
Integritätsbedingungen Beispiele für Beziehungsintegrität (Löschen des Primärschlüssels): 3.) Nullsetzen bei der Löschung (SET NULL), d.h. alle Fremdschlüsselwerte, die dem Primärschlüssel entsprechen, werden in der referenzierten Tabelle zu Null gesetzt. Seite 29
Übung (IM16): Entity Relationship (ER) Diagramm Stellen Sie für folgenden Geschäftsvorfall ein Entity Relationship Diagramm (ERD) auf. Anschließend führen sie das Diagramm bzw. die Diagramme über in eine Tabellendarstellung, d.h. aus dem Datenmodell wird ein Relationenmodell entwickelt. Thema: Bankgeschäfte Täglich werden in einer Bank Buchungen mit Datum und Betrag getätigt. Die Beträge werden dabei auf dem einen Konto als Sollbetrag gebucht und auf dem anderen als Habenbetrag. Die Konten werden durch die Kontonummer eindeutig identifiziert. Seite 30
Normalisierung Lösung der Übungsaufgabe aus dem Vorlesungsskript, speziell das DFD: Seite 31