3 - Ebenen - Architektur (ANSI/ SPARC)

Transkript

1 3 - Ebenen - Architektur (ANSI/ SPARC) EXTERNE EBENE Kunden-Bestellungen Artikel-Bestellungen K-Nr Artikel Art-Nr Kunden Art-Nr Art-Name K-Nr K-Name (Datensicht für Programm 1) (Datensicht für Programm 2) Externe Schemata KONZEPTIONELLE EBENE Kunde K-Nr K-Name bestellt 0..* 0..* Artikel Art-Nr Art-Name Konzeptionelles Schema (Entity-Relationship-Datenmodell) Kapitel 3 Kunde K-Nr K-Name Bestell K-Nr Art-Nr Logisches Schema (Relationales Datenmodell) Artikel Art-Nr Art-Name INTERNE EBENE Kapitel 2 Transformation Normalisierung Satzspeicherungsart, Speichergröße, Blockgröße, Verteilung, Indexe, Transaktionsverhalten,.. Internes Schema Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Nikolai Preiß, Holger Seubert Datenbanksysteme Kap. 1 Einführung 1

2 3. Relationale Datenmodellierung Relationale Datenbanksysteme verwalten Daten in Form von Relationen (Tabellen) => Entitätstypen und Beziehungstypen (fachliche Sicht) müssen in Relationen überführt werden ( = Relationenmodell) Relationenmodell als DV-technischer Entwurf der Datenbankstruktur Darstellungsformen: - natürlich (für die Ableitung aus dem ER-Datenmodell - Schritt 1) - normalisiert (zwecks Verhindern von Datenunstimmigkeiten/ Inkonsistenzen und als Vorlage für die Datenbankdefinition mit SQL - Schritt 2) 3.1. Grundlagen der relationalen Datenmodellierung Grundlegendes Strukturierungselement: Relation Beschreibung mittels (weitere Strukturierungselemente): Attribut Wertebereich Primärschlüssel Fremdschlüssel Integritätsbedingung Im Gegensatz zum ER-Datenmodell, wo es zwei wesentliche Strukturierungselemente gibt (Entitätsund Beziehungstypen), gibt es im Relationen-Modell ausschließlich die Relation als grundlegendes Strukturierungselement. 2

3 3.1. Grundlagen Relation strukturierte Beschreibung gleichartiger Informationsobjekte (=Instanzen von Entitäts-Typen) Datenpool für gleich strukturierte Datensätze (Tupel) Gegenstück zum Entitätstyp im ER-Datenmodell Substantive als Bezeichner Darstellung in Form einer Tabelle Spalten: Attribute (Struktur der Datensätze, Metadaten) Zeilen: Datensätze Relation Angestellter Attribute Datensätze Personalnummer Name (Vorname, Nachname) Geschlecht Gehalt Sprachen MZ Max Zweistein männlich ,78 deutsch englisch BF Bettina Fröhlich weiblich ,33 spanisch JF Jutta Feldbusch weiblich ,21 deutsch Abb. 1: Relation mit Datensätzen Tupel 3

4 3.1. Grundlagen Attribut Eigenschaft, Merkmal (analog ER-Datenmodell), zentrale Struktur einer Relation atomar oder zusammengesetzt (strukturiert) einwertig oder mehrwertig zusammengesetzte und mehrwerte Attribute können von normalen RDBMs nicht verarbeitet werden normalisierte Relation besitzt lediglich atomare und einwertige Attribute (Transformation) Wertebereich Menge der möglichen Werte für Attribute (analog ER-Datenmodell) Standard-Wertebereiche (in Anlehnung an SQL-Datentypen) im Relationenmodell, z.b.: INTEGER und DECIMAL für Zahl (DEC bei Bedarf mit bestimmter Stelligkeit) CHAR oder VARCHAR für Zeichen -kette (mit bestimmter Stelligkeit) DATE für Datum (JJJJ.MM.TT) TIME für Zeit (HH:MM:SS) BOOLEAN für Wahrheit -swert (wahr falsch) in jedem Wertebereich enthalten: NULL (Nullwert) keine Unterscheidung zwischen Wert unbekannt und Wert existiert nicht Ausschluss Nullwert für Attribut durch NOT NULL -Kennzeichnung 4

5 3.1. Grundlagen Primärschlüssel jede Relation besitzt einen Primärschlüssel (analog ER-Datenmodell) minimale Attributkombination zur eindeutigen Identifikation von Datensätzen (Tupel) evtl. mehrere Schlüsselkandidaten vorhanden Kennzeichnung: bei Primärschlüsselattributen Angabe PS Primärschlüsselwerte dürfen: nicht geändert werden keinen Nullwert aufweisen (explizite NOT NULL Angabe ist nicht erforderlich) 5

6 3.1. Grundlagen Fremdschlüssel Beziehungen zwischen den Relationen werden durch Fremdschlüssel ausgedrückt im Relationenmodell gibt es keine Beziehungstypen als Strukturierungselement (nur Relation) Fremdschlüssel haben im Relationenmodell eine größere Bedeutung als im ER-Datenmodell, da der Bezug zw. Relationen ausschließlich über ein FS Konstrukt hergestellt wird größte Abweichung zw. ER-Datenmodell und Relationenmodell (= meiste Arbeit bei der Transformation) Primärschlüssel einer anderen (fremden) Relation wird ausgeliehen => Referenz: Fremdschlüssel bezieht sich auf Primärschlüssel einer anderen Relation Referentielle Integrität (RI): FS-Wert entspricht einem PS-Wert der referenzierten Relation oder ist ein Nullwert Kennzeichnung: (I) im Relationenmodell bei Attributdef.: FS referenziert <referenzierte Relation> (<PS-Attribute>) (II) im Relationendiagramm: Mitarbeiter Personal-Nr PS Name. Arbeitsplatz FS Abteilung AbtNr Name Budget Abb. 3-4: Relationendiagramm mit Fremdschlüsselbeziehung PS Sofern der Fremdschlüssel den Nullwert annehmen darf (optional), wird dies durch ein O -Kennzeichen an der Pfeilspitze zum Ausdruck gebracht. 6

7 3.1. Grundlagen Integritätsbedingung garantiert ordnungsgemäßen Zustand / Integrität einer Datenbank (analog ER-Datenmodell) Angaben für Attribute (in Anlehnung an SQL-Angaben): Wertebereich, Primärschlüssel und Fremdschlüssel NOT NULL bzw. NOT NULL (<Attributliste>) UNIQUE bzw. UNIQUE (<Attributkombination>) für z.b. Schlüsselkandidaten DEFAULT = <Wert> CHECK (<Bedingung>) Relationale Datenbank Bestandteile: Relationales Datenbankschema Strukturbeschreibungen für die (normalisierten) Relationen Durch SQL (Data Definition Language = DDL) erstellt Relationale Datensätze Durch SQL (Data Manipulation Language = DML) in das relationale Datenbankschema eingefügt 7

8 3.2. Überführung ER-Datenmodell ins Relationenmodell Überführung Entitätstyp Relationen einer Datenbank müssen zunächst per Transformation des ER-Datenmodells ermittelt werden Bei der Umsetzung von mehrwertigen Attributen und Beziehungstypen sind besondere Maßnahmen erforderlich Beispiel 3-4: Abb. 3-6a zeigt einen Entitätstyp Angestellter, der in eine Relation überführt werden soll. Angestellter PersNr: ZAHL [1..1] Name: ZEICHEN (40) [1..1] Geburtsdatum: DATUM [0..1] Familienstand: {ledig verheiratet geschieden} STANDARD = ledig [0..1] Ehepartner: [0..1] Name: ZEICHEN (40) [1..1] Geburtsdatum: DATUM [0..1] TelefonNr: ZAHL (15) [0..5] Gehalt: ZAHL (9,2) [1..1] Abb. 3-6a: Entitätstyp Angestellter 8

9 3.2. Überführung ER-Datenmodell ins Relationenmodell Aus ER-Diagramm überführtes Relationenmodell: Angestellter PersNr INTEGER PS Name VARCHAR (40) NOT NULL Geburtsdatum DATE Familienstand VARCHAR (11) DEFAULT = ledig CHECK (VALUE IN (ledig, verheiratet, geschieden)) Partner-Name VARCHAR (40) Partner-Gebdatum DATE Gehalt DECIMAL (9,2) NOT NULL Telefon PersNr INTEGER PS FS referenziert Angestellter (PersNr) TelefonNr DECIMAL (15) PS CHECK (Anzahl Datensätze mit der selben PersNr 5) Abb. 3-6b: Relationenmodell für den Entitätstyp Angestellter Hinweis: Es ist zu beachten, dass sich manche Angestellte den Telefonanschluss teilen. TelefonNr ist also nicht eindeutig. 9

10 3.2. Überführung ER-Datenmodell ins Relationenmodell Überführung Entitätstyp ERDM-Konstrukt Entitätstyp, Sub-Entitätstyp, Weak-Entitätstyp, Beziehungsentitätstyp (inkl. zugehörigem Bez.-typ) atomares einwertiges ([?..1]) Attribut zusammengesetztes Attribut mehrwertiges ([?..* ]) Attribut Wertebereiche: Zahl, Zeichen, Datum, Zeit, Wahrheit Aufzählung als Wertebereich Primärschlüssel Integritätsbedingungen: Eindeutig, [1..?], Standard, Check RM-Konstrukt Relation (bei Weak-Entitätstyp eigener PS erforderlich) Attribut (atomar, einwertig) wird unverändert übernommen Teilattribute einzeln atomar auflösen (evtl. jew. mit Gesamtattributname als Präfix) (1) auslagern in eigene, zusätzliche Relation (Normalfall) (mit PS des ursprünglichen Entitätstyps als FS ergänzt + Auswahl eigener PS) (2) Notlösung: Attribut mehrfach einzeln atomar (mit lfd.nr. bis Obergrenze) Nur sinnvoll wenn die meisten Datensätze auch tatsächlich Werte aufweisen. In (SQL-) Datentypen überführen. Am häufigsten: INTEGER/ DECIMAL, CHAR/ VARCHAR, DATE, TIME, BOOLEAN Basis-SQL-Datentyp mit Zusatzbedingung: CHECK (VALUE IN ( )) Primärschlüssel wird unverändert übernommen (bei Weak-Entitätstyp eigener, künstlicher PS erforderlich) In (SQL-) Integritätsbedingungen überführen: UNIQUE (eindeutig), NOT NULL [1..?], DEFAULT (Standard), CHECK 10

11 3.2. Überführung ER-Datenmodell ins Relationenmodell Überführung Beziehungstyp Im Relationenmodell kein entsprechendes Gegenstück, daher in FS-Konstrukte zu überführen Allgemeine Assoziation Beispiel 3-5: Die Abb. 3-7a zeigt ein ER-Diagramm mit unterschiedlich komplexen Beziehungstypen (binär), das in ein Relationenmodell überführt werden soll. wirkt mit bei 0..* Projekt PNr. 1..* Angestellter Abteilung AngNr. 1..* arbeitet in 1 AbtNr leitet 0..1 Abb. 3-7a: Beziehungstypen mit unterschiedlichen Multiplizitäten 11

12 3.2. Überführung ER-Datenmodell ins Relationenmodell Überführung der Assoziation: wirkt mit bei 0..* Projekt PNr. 1..* Beziehungsrelation Angestellter AngNr. 1..* arbeitet in 1 Abteilung AbtNr. Mitwirkung Projekt AngNr FS PS PNr PS PNr FS PS leitet 0..1 Angestellter Abteilung AngNr PS AbtNr PS AbtNr. FS Leiter. FS Hinweis: Die Form der Überführung einer allgemeinen Assoziation ist von den Multiplizitäten des Beziehungstyps abhängig. Abb. 3-7b: Relationendiagramm mit verschiedenen Fremdschlüssel-Beziehungen 12

13 3.2. Überführung ER-Datenmodell ins Relationenmodell Abhängigkeit Beispiel 3-6: Die Abb. 3-8a zeigt den Abhängigkeitsbeziehungstyp zwischen dem Weak-Entitätstyp Kind und dem Entitätstyp Angestellter. Dieser Abhängigkeitsbeziehungstyp soll in ein Relationenmodell überführt werden. Angestellter AngNr * weak Kind Name. Abb. 3-8a: Abhängigkeitsbeziehungstyp Hinweis: Auch ist ist auf die Multiplizitäten des Beziehungstyps zu achten. 13

14 3.2. Überführung ER-Datenmodell ins Relationenmodell Beziehungsrelation künstl. PS Angestellter AngNr PS. Ang-Kind AngNr FS PS KNr FS PS Kind KNr PS Name. Abb. 3-8b: Relationendiagramm für den Abhängigkeitsbeziehungstyp Hinweis: Falls die Obergrenzen der beiden Multiplizitätsangaben 1 und 1 lauten, können die Attribute aus Vereinfachungsgründen in die Relation die aus dem normalen Entitätstyp resultiert integriert werden (evtl. mit entsprechenden Kennzeichen). In diesem Fall würde die eigene Relation für den Weak-Entitätstyp entfallen. 14

15 3.2. Überführung ER-Datenmodell ins Relationenmodell Aggregation Beispiel 3-7: Die Abb. 3-9a zeigt den Aggregat-Entitätstyp Kraftfahrzeug, der sich aus den Komponenten-Entitätstypen Fahrwerk, Karosserie und Sonderausstattung zusammensetzt. Diese Aggregationsbeziehungstypen sollen in ein Relationenmodell überführt werden. Kraftfahrzeug KfzNr * * FwNr. Fahrwerk Karosserie KarNr. Sonderausstattung SaNr. Abb. 3-9a: Aggregationsbeziehungstyp 15

16 3.2. Überführung ER-Datenmodell ins Relationenmodell Beziehungsrelation Kraftfahrzeug KfzNr PS. KFZ-Ausstattung KfzNr FS PS SaNr FS PS Fahrwerk FwNr PS KfzNr FS. Karosserie KarNr PS KfzNr FS. Sonderausstattung SaNr PS. PS des Aggregats immer als FS in Komponente Abb. 3-9b: Relationendiagramm für die Aggregationsbeziehungstypen 16

17 3.2. Überführung ER-Datenmodell ins Relationenmodell Generalisierung Beispiel 3-8: Die Abb. 3-10a zeigt den Super-Entitätstyp Person, der sich vollständig (total) aus den Sub-Entitätstypen Angestellter und Kunde zusammensetzt, wobei ein Angestellter auch Kunde sein kann (nicht disjunkt). Diese Generalisierung/Spezialisierung soll in ein Relationenmodell überführt werden. Person PersNr Name Adresse Geschlecht AngNr Gehalt Abteilung Angestellter (t,n) KundenNr Kunde Abb. 3-10a: Generalisierung/Spezialisierung 17

18 3.2. Überführung ER-Datenmodell ins Relationenmodell Angestellter PersNr FS PS AngNr Gehalt Abteilung Person PersNr PS Name Adresse Geschlecht Kunde PersNr FS PS KundenNr Relation des Sub-Entitätstyps erbt PS der Relation des Super- Entitätstyps (der gleichzeitig FS ist) Abb. 3-10b: Relationendiagramm für die Generalisierung/Spezialisierung Hinweis: total mittels Datenbank-Prüfroutine (z.b. Stored-Procedure) sicherbar: Die Menge der PersNr-Werte bei Person muss der Menge der PersNr-Werte bei Angestellter + Kunde entsprechen. 18

19 3.2. Überführung ER-Datenmodell ins Relationenmodell Beziehungstyp mit Grad > 2 Beispiel 3-9: Die Abb. 3-11a zeigt den Beziehungstyp kauft... bei vom Grad 3, der zur Verwaltung von Wareneinkäufen dient. Dieser Beziehungstyp vom Grad 3 soll in ein Relationenmodell überführt werden. Abteilung AbtNr 0..* kauft bei 0..* ArtNr Artikel 0..1 Händler HNr Abb. 3-11a: Beziehungstyp mit Grad = 3 19

20 3.2. Überführung ER-Datenmodell ins Relationenmodell Jeder Beziehungstyp mit einem Grad > 2 wird in eine (Beziehungs-) Relation überführt, die vom Beziehungstyp die FS und PS als Attribute übernimmt Abteilung AbtNr PS Kauf AbtNr FS PS ArtNr FS PS HNr FS PS ArtNr Artikel PS HNr Händler PS Abb. 3-11b: Relationendiagramm für Beziehungstyp mit Grad = 3 20

21 3.2. Überführung ER-Datenmodell ins Relationenmodell Sonstige Besonderheiten Beispiel 3-10: Die Abb. 3-12a zeigt einen rekursiven Beziehungstyp mit Rollennamen und einen Beziehungstyp mit Multiplizitätsobergrenze 2. Dieses ER-Diagramm soll in ein Relationenmodell überführt werden. Mitarbeiter Abteilung MANr 1..1 leitet 0..2 AbtNr Ehemann Ehefrau ist verheiratet mit Abb. 3-12a: ER-Diagramm mit Rollennamen und fixer Multiplizitätsobergrenze 21

22 3.2. Überführung ER-Datenmodell ins Relationenmodell Der rekursive Bez.-Typ ist verheiratet mit führt dazu, dass die bei der Überführung entstehende Relation Mitarbeiter den eigenen PS als FS erhält. Da PS und FS nicht denselben Bezeichner haben dürfen, empfiehlt sich für den FS einer der beiden Rollennamen. Mitarbeiter MANr PS Ehefrau FS Abteilung AbtNr PS Leiter FS Abb. 3-12b: Relationendiagramm für ER-Diagramm aus Abb. 3-12a Hinweis: Multiplizitätsobergrenze 2 bei Abteilung mittels Integritätsbedingung sicherbar: CHECK (Anzahl Datensätze mit dem selben Leiter 2) 22

23 3.2. Überführung ER-Datenmodell ins Relationenmodell Überführung Beziehungstyp ERDM-Konstrukt Beziehungstyp mit Grad > 2 (inkl. zugehör. Beziehungsentitätstyp, falls vorhanden) allg. Assoziation mit viele zu viele -Multiplizität 1 zu viele -Multiplizität 1 zu 1 -Multiplizität RM-Konstrukt Relation Relation mit PS der am Bez.-typ beteiligten ET als FS und PS PS der Relation auf 1 -Seite als FS in Relation auf viele -Seite (FS mit Not Null, falls auf 1 -Seite Multiplizität 1..1 ) PS der Relation auf einer Seite (bei Multiplizität 1..1, falls vorhanden) als FS in Relation auf anderer Seite (FS mit Not Null, falls Multiplizität 1..1 ) Abhängigkeit mit Weak-Entitätstyp Aggregation normale starke wie bei Assoziation bei 1 zu 1 -Multiplizität: Attribute des Weak-ET können in Relation für ET integriert werden, von dem Weak-ET abhängig ist (evtl. mit Weak-ET-Name als Präfix) wie bei Assoziation PS der Aggregat-Relation als FS mit Not Null in Komponente-Relation 23

24 3.2. Überführung ER-Datenmodell ins Relationenmodell Überführung Beziehungstyp ERDM-Konstrukt Generalisierung Super-Entitätstyp Sub-Entitätstyp Multiplizität RM-Konstrukt Relation eigene Relation mit PS des Super-ET als FS und PS (ansonsten ohne Attribute des Super-ET; bei Bedarf: total/partiell + (nicht) disjunkt mittels Prüfroutine = Stored Procedure sichern) - Notlösung: falls Sub-ET ohne eigene Attribute (nur eigener BT), keine eigene Relation für Sub-ET (BT des Sub-ET als BT des Super-ET behandeln) (steuert die Umwandlung (s. Fallunterscheidungen)) (bei Bedarf: konkrete Unter-/Obergrenze durch Check-Anweisung sichern) Rolle kann bei FS-Attributnamen einfließen 24

25 3.2. Überführung ER-Datenmodell ins Relationenmodell Übungsaufgabe 4: weak Kind Seminar Überführen Sie das ER-Datenmodell aus Übungsaufgabe 2 in ein Relationenmodell. ist Vorgesetzter von Auszubildender (t,d) 0..* 1..2 Mitarbeiter 0..* 0..* besucht bei 0..1 Institut * arbeitet in Angestellter 1..1 leitet 1..1 enthält Infos über 1..* Projektbeteiligung ist beteiligt bei 0..* Projekt Abteilung Personalakte 1..1 beurteilt * 0..1 Vertrag Beurteilung 25

26 3.2. Überführung ER-Datenmodell ins Relationenmodell Mitarbeiter Personalnummer: ZEICHEN (10) EINDEUTIG [1..1] Name: [1..1] Vorname: ZEICHEN (20) [1..1] Nachname: ZEICHEN (20) [1..1] Anschrift: [1..*] Straße: ZEICHEN (30) [1..1] PLZ: ZAHL (5) CHECK (> 0) [1..1] Ort: ZEICHEN (30) [1..1] Weak Kind Vorname: ZEICHEN (20) [1..1] Geburtsdatum: DATUM [1..1] Auszubildender Beruf: ZEICHEN (20) [1..1] Angestellter Gehalt: ZAHL (8,2) CHECK (> 0) [1..1] Abteilung Kürzel: ZEICHEN (5) EINDEUTIG [1..1] Name: ZEICHEN (25) [1..1] Seminar Seminarnummer: ZEICHEN (10) EINDEUTIG [1..1] Titel: ZEICHEN (30) [1..1] Beschreibung: ZEICHEN (1000) [1..1] Institut Name: ZEICHEN (30) EINDEUTIG [1..1] Anschrift: [1..1] Straße: ZEICHEN (30) [1..1] PLZ: ZAHL (5) CHECK (> 0) [1..1] Ort: ZEICHEN (30) [1..1] Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Nikolai Preiß, Holger Seubert Datenbanksysteme Kap. 2 ER-Datenmodellierung 26

27 3.2. Überführung ER-Datenmodell ins Relationenmodell Personalakte Aktennummer: ZEICHEN (10) EINDEUTIG [1..1] Vertrag Vertragsnummer: ZEICHEN (10) EINDEUTIG [1..1] Vertragstyp: {Arbeit Ausbildung} STANDARD = Arbeit [1..1] Abschluss: DATUM [1..1] Text: ZEICHEN ( ) [1..1] Beurteilung Beurteilungsnummer: ZEICHEN (10) EINDEUTIG [1..1] Datum: DATUM [1..1] Fachkompetenz: ZEICHEN (10.000) [1..1] Sozialkompetenz: ZEICHEN (10.000) [1..1] Projekt Projektname: ZEICHEN (30) EINDEUTIG [1..1] Start: DATUM [1..1] Ende: DATUM [0..1] Budget: ZAHL (9,2) CHECK ((> 0) und (< )) [0..1] Strategisch: WAHRHEIT STANDARD = falsch [1..1] Projektbeteiligung Personalnummer: ZEICHEN (10) FS [1..1] Projektname: ZEICHEN (30) FS [1..1] Rolle: ZEICHEN (20) [1..*] Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Nikolai Preiß, Holger Seubert Datenbanksysteme Kap. 2 ER-Datenmodellierung 27

28 3.2. Überführung ER-Datenmodell ins Relationenmodell Lösung der Übungsaufgabe 4: Kind MA-Kind Seminar Seminarbesuch Institut Mitarbeiter MA-Adresse Adresse Angestellter Projekt Abteilung Personalakte Auszubildender Projektbeteiligung Projekt- Rollen Vertrag Beurteilung 28

29 3.2. Überführung ER-Datenmodell ins Relationenmodell Mitarbeiter PersNr: CHAR (10) PS Vorname: VARCHAR (20) NOT NULL Nachname: VARCHAR (20) NOT NULL Adresse AdressNr: INTEGER PS Straße: VARCHAR (30) NOT NULL PLZ: DECIMAL (5) NOT NULL CHECK (> 0) Ort: VARCHAR (30) NOT NULL MA-Adresse MA-Nr: CHAR (10) PS FS referenziert Mitarbeiter (PersNr) Anschrift: INTEGER PS FS referenziert Adresse (AdressNr) Kind KindNr: INTEGER PS CHECK (> 0) Vorname: VARCHAR (20) NOT NULL GebDatum: DATE NOT NULL MA-Kind MA-Nr: CHAR (10) PS FS referenziert Mitarbeiter (PersNr) KindNr: INTEGER PS FS referenziert Kind (KindNr) (bei Bedarf: CHECK (Anzahl Datensätze mit dem selben KindNr-Wert 2) ) Auszubildender PersNr: CHAR (10) PS FS referenziert Mitarbeiter (PersNr) Beruf: VARCHAR (20) NOT NULL 29

30 3.2. Überführung ER-Datenmodell ins Relationenmodell Angestellter PersNr: CHAR (10) PS FS referenziert Mitarbeiter (PersNr) Gehalt: DECIMAL (8,2) NOT NULL CHECK (> 0) Chef: CHAR (10) FS referenziert Angestellter (PersNr) Abteilung: CHAR (5) FS referenziert Abteilung (Kürzel) NOT NULL (bei Bedarf: CHECK (Anzahl Datensätze mit dem selben Chef-Wert 20) ) Abteilung Kürzel: CHAR (5) PS Name: VARCHAR (25) NOT NULL Leiter: CHAR (10) FS referenziert Angestellter (PersNr) NOT NULL (bei Bedarf: CHECK (Anzahl Datensätze mit dem selben Leiter-Wert 2) ) Seminar SemNr: CHAR (10) PS Titel: VARCHAR (30) NOT NULL Beschreibung: VARCHAR (1000) NOT NULL Institut Name: VARCHAR (30) PS Anschrift: INTEGER FS referenziert Adresse (AdressNr) NOT NULL Seminarbesuch MA-Nr: CHAR (10) PS FS referenziert Mitarbeiter (PersNr) SemNr: CHAR (10) PS FS referenziert Seminar (SemNr) InstName: VARCHAR (30) FS referenziert Institut (Name) NOT NULL 30

31 3.2. Überführung ER-Datenmodell ins Relationenmodell Personalakte AktenNr: CHAR (10) PS MA-Nr: CHAR (10) FS referenziert Mitarbeiter (PersNr) NOT NULL Vertrag VertragsNr: CHAR (10) PS Vertragstyp: VARCHAR (10) DEFAULT = Arbeit NOT NULL CHECK ((= Arbeit) oder (= Ausbildung)) Abschluss: DATE NOT NULL Text: VARCHAR ( ) NOT NULL PersAkte: CHAR (10) FS referenziert Personalakte (AktenNr) NOT NULL Beurteilung BeurteilNr: CHAR (10) PS Datum: DATE NOT NULL Fachkompetenz: VARCHAR (10.000) NOT NULL Sozialkompetenz: VARCHAR (10.000) NOT NULL PersAkte: CHAR (10) FS referenziert Personalakte (AktenNr) NOT NULL 31

32 3.2. Überführung ER-Datenmodell ins Relationenmodell Projekt Projektname: VARCHAR (30) PS Start: DATE NOT NULL Ende: DATE Budget: DECIMAL (9,2) CHECK ((> 0) und (< )) Strategisch: BOOLEAN DEFAULT = falsch NOT NULL Projektbeteiligung ProjBeteilNr: INTEGER PS CHECK (> 0) MA-Nr: CHAR (10) FS referenziert Mitarbeiter (PersNr) NOT NULL ProjName: VARCHAR (30) FS referenziert Projekt (Projektname) NOT NULL Beurteilung: CHAR (10) FS referenziert Beurteilung (BeurteilNr) Projektrollen ProjBeteil: INTEGER PS FS referenziert Projektbeteiligung (ProjBeteilNr) Rolle: VARCHAR (20) PS 32

33 3.3. Normalisierung im Relationenmodell Grundidee der Normalisierung Relationales Datenbankschema gut strukturiert (in 3. Normalform), falls zunächst ER-Datenmodell erstellt und dieses dann in Relationenmodell überführt. Ansonsten Unregelmäßigkeiten (Anomalien) beim Einfügen, Ändern und Löschen von Datensätzen möglich Beispiel 3-11: Die studentischen Prüfungsergebnisse sollen in einer Relation Prüfung verwaltet werden. Prüfung PNr Fach Datum Vorlesung Student VNr VName Zeit MatrNr SName SG SGLeiter Note 1 Allg. BWL St Steuern Max Wirtsch.-inf. Einstein 4,0 Bi Bilanz Moritz Wirtsch.-inf. Einstein 3, Ute Wirtsch.-inf. Einstein 2,0 2 SW-Entwicklung J1 Java Max Wirtsch.-inf. Einstein 1,5 Xm XML Verona Angewandte Inf. Zweistein 5, Angela Angewandte Inf. Zweistein 3,5 3 Rechnersysteme Li Linux Otto Informatik Zuse 2,5 Xm XML 60 Abb. 3-13: Relation zur Verwaltung von Prüfungsergebnissen 33

34 3.3. Normalisierung im Relationenmodell Grundidee Probleme: mehrwertige Attribute Vorlesung und Student (mit einem relationalen Datenbanksystem nicht verwaltbar) unerwünschte Effekte (Anomalien) bei der Verarbeitung der Datensätze: - Einfügen: Daten über Vorlesungen und Studenten können nur abgespeichert werden, wenn diese an einer Prüfung beteiligt sind. - Ändern: Wenn sich Studentendaten ändern (bspw. der Name), muss die Änderung bei allen Prüfungen vorgenommen werden, an denen der Student teilgenommen hat, wobei keine seiner Prüfungen vergessen werden darf (sonst ist der Datenbestand nicht mehr korrekt). - Löschen: Wird die letzte Prüfung gelöscht, an der ein Student teilgenommen hat, gehen zwangsweise auch alle Daten des Studenten verloren und müssen bei der nächsten Prüfung wieder komplett neu eingegeben werden. Einfüge-, Änderungs- und Lösch-Anomalien durch korrekte Zuordnung der Attribute zu Relationen vermeidbar: ü korrekte Zuordnung der Attribute durch Normalisierung überprüfbar: F nacheinander 1NF, 2NF, 3NF, BCNF, 4NF, 5NF einrichten 34

35 3.3. Normalisierung im Relationenmodell Attribut-Abhängigkeiten Normalisierung = Zusammenfassung der voneinander abhängigen Attribute in eine gemeinsame Relation Grundlage der Normalisierung: Abhängigkeiten der Attribute (klären wie Attribute voneinander abhängig sind) Attribute können auf zwei Arten voneinander abhängig sein: funktionale Abhängigkeit (fast in jeder Relation vorhanden) mehrwertige Abhängigkeit (kommen weit weniger häufig vor) (1) Funktionale Abhängigkeit Funktionale Abhängigkeiten werden bei der Datenanalyse ermittelt. Ein Attribut B ist funktional abhängig von einem Attribut A (Attributkombination A1,, An): falls: A B bzw. A1,, An B Ein Attribut A (bzw. eine Attributkombination A1,, An) bestimmt ein anderes Attribut B... wenn zwei Datensätze einer Relation die gleichen Werte für das Attribut A (bzw. für die Attribute A1,, An) besitzen, dann ist auch der Wert für das Attribut B identisch. 35

36 3.3. Normalisierung im Relationenmodell funkt. Abhängigkeit Beispiel 3-12: Personal Abteilung PersNr PName AbtNr Gehalt AbtNr AName ChefPersNr Budget 007 Bond A A-1 Außendienst Mio Smith A P-0 Personal ,5 Mio Walker P Miller P Relation Personal mit Attribut PersNr als PS => funktionale Abhängigkeiten: PersNr PName PersNr AbtNr PersNr Gehalt abgekürzt: PersNr PName, AbtNr, Gehalt Fremdschlüsselabhängigkeiten: Personal.AbtNr Abteilung.AbtNr ChefPersNr PersNr Es kann auch die folgende Bedingung gelten: ChefPersNr AbtNr (jeder Chef leitet nur eine Abteilung) 36

37 3.3. Normalisierung im Relationenmodell funkt. Abhängigkeit zwecks effektiver Arbeit bei der Normalisierung ist man an der minimalen Menge der funktionalen Abhängigkeiten interessiert wertlose Angaben zu funktionalen Abhängigkeiten (sind auszuschließen): nicht volle funktionale Abhängigkeit F falls A B gilt, und es gilt auch: A, D B F B ist bei A, D B nur von einem Teil der Attribute auf der linken Seite abhängig => B ist nicht voll funktional abhängig von den Attributen der linken Seite F man ist lediglich an vollen funktionalen Abhängigkeiten interessiert (minimale linke Seite) => A, D B ist wertlos transitive Abhängigkeit F falls S A und A B gilt, dann gilt auch: S B (transitiver Schluss) F transitiver Schluss ist wertlos (da redundant) F B ist von S transitiv abhängig, falls: es gilt S A und A B, aber es gilt nicht A S (d.h.: A ist kein Schlüssel) 37

38 3.3. Normalisierung im Relationenmodell (2) Mehrwertige Abhängigkeit funktionale Abhängigkeiten gelten zwischen einwertigen Attributen Attribut A (bzw. Attributkombination A1., An) kann aber auch mehrwertiges Attribut B bestimmen: A B bzw. A1,, An B mehrwertiges Attribut mit relationalem Datenbanksystem aber nicht verwaltbar mehrwertiges Attribut kann zu einwertigem Attribut umgeformt werden (s. folgendes Bsp. 3-13): bei jedem Datensatz wird jede Ausprägung des mehrwertigen Attributs mit den Einzel- Ausprägungen der anderen Attribute kombiniert. => aus dem einen Datensatz werden mehrere Datensätze (führt zu Redundanz) besitzt ein Datensatz mehrere mehrwertige Attribute, so muss jede Ausprägung eines mehrwertigen Attributs mit jeder Ausprägung der anderen mehrwertigen Attribute kombiniert werden F dies nennt man eine mehrwertige Abhängigkeit 38

39 3.3. Normalisierung im Relationenmodell mehrwert. Abhängigkeit Beispiel 3-13: In der Relation Prüfung aus Abb sollen nur atomare Attribute (d.h. nicht strukturierte und einwertige Attribute) verwendet werden. Dies kann durch eine Umformung entsprechend Abb erreicht werden. Prüfung PNr Fach Datum VNr VName Zeit MatrNr SName SG SGLeiter Note 1 Allg. BWL St Steuern 90Prüfung 1111 Max Wirtsch.-inf. Einstein 4,0 PNr 1 Fach Allg. BWL Datum Vorlesung St Steuern 90 Student 2222 Moritz Wirtsch.-inf. Einstein 3,0 1 Allg. BWL VNr St VName Steuern Zeit 90 MatrNr 3333 SName Ute SG Wirtsch.-inf. SGLeiter Einstein 2,0 Note 1 Allg. BWL St Bi Steuern Bilanz Max Wirtsch.-inf. Einstein 4,0 1 Allg. BWL Bi Bilanz Moritz Wirtsch.-inf. Einstein 3,0 1 Allg. BWL Bi Bilanz Ute Wirtsch.-inf. Einstein 2,0 2 SW-Entwicklung J1 Java Max Wirtsch.-inf. Einstein 1,5 2 SW-Entwicklung Xm J1 XML Java Verona Angewandte Inf. Zweistein 5,0 2 SW-Entwicklung J1 Java Angela Angewandte Inf. Zweistein 3,5 23 Rechnersysteme SW-Entwicklung Li Xm Linux XML Otto Max Informatik Wirtsch.-inf. Zuse Einstein 1,5 2,5 2 SW-Entwicklung Xm Xm XML Verona Angewandte Inf. Zweistein 5,0 2 SW-Entwicklung Xm XML Angela Angewandte Inf. Zweistein 3,5 3 Rechnersysteme Li Linux Otto Informatik Zuse 2,5 3 Rechnersysteme Xm XML Otto Informatik Zuse 2,5 Abb. 3-15: Relation Prüfung mit atomaren, einwertigen Attributen 39

40 3.3. Normalisierung im Relationenmodell mehrwert. Abhängigkeit Probleme durch diese Umformung: viel Redundanz mehrwertige Abhängigkeit: jeder Student einer Prüfung muss mit jeder Vorlesung einer Prüfung kombiniert werden (sonst ist der Datenbestand nicht mehr korrekt) => die einzelnen Datensätze sind nicht unabhängig voneinander Erkenntnis: Relationen mit mehrwertigen Abhängigkeiten sind sehr schlecht zu verwalten und sollten auf jeden Fall vermieden werden. 40

41 3.3. Normalisierung im Relationenmodell Erste Normalform Eine Relation heißt normalisiert, d.h. sie ist in der ersten Normalform (1NF), wenn die Relation lediglich atomare, einwertige Attribute aufweist. Weist eine Relation ein mehrwertiges Attribut auf, so kann diese nicht normalisierte Relation durch das folgende Zerlegungsverfahren in die 1NF überführt werden (s. Bsp. 3.14): Lagere das mehrwertige Attribut in eine eigene, zusätzliche Relation aus. (Das mehrwertige Attribut wird in der Ursprungsrelation gelöscht) Ist das mehrwertige Attribut strukturiert, löse es in seine Einzelattribute auf. Ergänze die zusätzliche Relation mit dem Primärschlüssel der Ursprungsrelation als Fremdschlüssel, um die Beziehung zur Ursprungsrelation herzustellen. Bestimme in der Zusatzrelation einen geeigneten Primärschlüssel. Die (verlustfreie) Zerlegung einer Relation R1 in mehrere kleinere Relationen R1... Rn ist grundlegendes Prinzip der Normalisierung und wird bei der Einrichtung aller Normalformen angewendet! 41

42 3.3. Normalisierung im Relationenmodell 1. Normalform Prüfung PNr Fach Datum Vorlesung Student VNr VName Zeit MatrNr SName SG SGLeiter Note 1 Allg. BWL St Steuern Max Wirtsch.-inf. Einstein 4,0 Bi Bilanz Moritz Wirtsch.-inf. Einstein 3,0 Beispiel 3-14: Die Relation Prüfung aus Bsp soll normalisiert werden. Für die Relation gelten die folgenden Abhängigkeiten: 3333 Ute Wirtsch.-inf. Einstein 2,0 2 SW-Entwicklung J1 Java Max Wirtsch.-inf. Einstein 1,5 Xm XML Verona Angewandte Inf. Zweistein 5, Angela Angewandte Inf. Zweistein 3,5 3 Rechnersysteme Li Linux Otto Informatik Zuse 2,5 Xm XML 60 PNr Fach, Datum VNr VName VName VNr PNr, VNr Zeit MatrNr SName, SG, SGLeiter SG SGLeiter PNr, MatrNr Note PNr Vorlesung PNr Student Relation Prüfung verletzt 1NF: besitzt mehrwertige Attribute Vorlesung und Student diese Attribute in jeweils eigene Relation auslagern 42

43 3.3. Normalisierung im Relationenmodell 1. Normalform PS der Ausgangsrelation wird als FS in den neuen Relationen ergänzt Prüfung PNr Fach Datum 1 Allg. BWL SW-Entwicklung Rechnersysteme Prüf-Vorlesung PNr VNr VName Zeit 1 St Steuern 90 1 Bi Bilanz 60 2 J1 Java Xm XML 45 3 Li Linux 45 3 Xm XML 60 Prüf-Student PNr MatrNr SName SG SGLeiter Note Max Wirtsch.-inf. Einstein 4, Moritz Wirtsch.-inf. Einstein 3, Ute Wirtsch.-inf. Einstein 2, Max Wirtsch.-inf. Einstein 1, Verona Angewandte Inf. Zweistein 5, Angela Angewandte Inf. Zweistein 3, Otto Informatik Zuse 2,5 Da sowohl einzelne Vorlesungen als auch einzelene Studenten in mehreren Prüfungen auftreten können, bestehen die PS der neuen Rel. aus VNr + PNr und MatrNr + PNr. Abb. 3-16: Datenbank mit 1NF-Relationen 43

44 3.3. Normalisierung im Relationenmodell Zweite Normalform 1NF verhindert noch keine Einfüge-, Änderungs- und Lösch-Anomalien Beispiel 3-14a: Für die 1NF-Relationen in Abb gelten unverändert die unerwünschten Effekte (Anomalien), die auch für die Ausgangsrelation Prüfung gelten (s. Bsp. 3-11): - Einfüge-Anomalie: Da es keine eigenen Relationen für Vorlesungen und Studenten gibt, können Daten über Vorlesungen und Studenten nur abgespeichert werden, wenn diese an einer Prüfung beteiligt sind. - Änderungs-Anomalie: Wenn sich Studentendaten ändern (bspw. der Name), muss die Änderung bei allen Prüfungen vorgenommen werden, an denen der Student teilgenommen hat, wobei keine seiner Prüfungen vergessen werden darf (sonst ist der Datenbestand nicht mehr korrekt). - Lösch-Anomalie: Wird die letzte Prüfung gelöscht, an der ein Student teilgenommen hat, gehen zwangsweise auch alle Daten des Studenten verloren und müssen bei der nächsten Prüfung wieder komplett neu eingegeben werden. => 1NF-Relation muss weiter normalisiert werden Viele dieser Anomalien resultieren aus der Tatsache, dass die Datenfelder unterschiedlicher IO in einer gemeinsamen Relation abgespeichert werden (Attr. nur von Teil des PS abhängig). 44

45 3.3. Normalisierung im Relationenmodell 2. Normalform Eine Relation ist in der zweiten Normalform (2NF), wenn sich die Relation in der ersten Normalform befindet und jedes Nichtschlüsselattribut von jedem Schlüsselkandidaten voll funktional abhängig ist. eine 1NF-Relation kann durch das folgende Zerlegungsverfahren in die zweite Normalform überführt werden (s. Bsp. 3.15): Lagere alle Nichtschlüsselattribute, die von einem bestimmten Teilschlüssel (bestehend aus einem oder mehreren Attributen) abhängig sind, in eine eigene, zusätzliche Relation aus. (Die ausgelagerten Nichtschlüsselattribute werden in der Ursprungsrelation gelöscht.) Ergänze die zusätzliche Relation mit dem betreffenden Teilschlüssel und definiere ihn dort als Primärschlüssel. In der Ausgangsrelation wird der betreffende Teilschlüssel als Fremdschlüssel verwendet, um die Beziehung zur neuen Zusatzrelation herzustellen. 45

46 3.3. Normalisierung im Relationenmodell 2. Normalform Prüf-Vorlesung PNr VNr VName Zeit 1 St Steuern 90 1 Bi Bilanz 60 2 J1 Java Xm XML 45 3 Li Linux 45 3 Xm XML 60 Prüfung PNr Fach Datum 1 Allg. BWL SW-Entwicklung Rechnersysteme Prüf-Student PNr MatrNr SName SG SGLeiter Note Max Wirtsch.-inf. Einstein 4, Moritz Wirtsch.-inf. Einstein 3, Ute Wirtsch.-inf. Einstein 2, Max Wirtsch.-inf. Einstein 1, Verona Angewandte Inf. Zweistein 5, Angela Angewandte Inf. Zweistein 3, Otto Informatik Zuse 2,5 Beispiel 3-15: Die Relationen aus Abb sollen weiter normalisiert werden. Dazu ist im nächsten Schritt eine Überführung in die 2NF erforderlich. Relation Prüfung: Relation Prüf-Vorlesung: ist bereits in der 2NF ist bereits in der 2NF Relation Prüf-Student: verletzt die 2NF durch folgende Teilabhängigkeit: MatrNr SName, SG, SGLeiter => diese Attribute in eigene Relationen auslagern (s. folgende Abb. 3-17) 46

47 3.3. Normalisierung im Relationenmodell 2. Normalform Prüfung PNr Fach Datum 1 Allg. BWL SW-Entwicklung Rechnersysteme PS Student MatrNr SName SG SGLeiter 1111 Max Wirtsch.-inf. Einstein 2222 Moritz Wirtsch.-inf. Einstein 3333 Ute Wirtsch.-inf. Einstein Das Attribut MatrNr wird als weiteres Attr. in der Rel. Student übernommen und dient dort als PS (in der Rel Verona Angewandte Inf. Zweistein 9999 Angela Angewandte Inf. Zweistein 4567 Otto Informatik Zuse Prüf-Student als FS) Prüf-Vorlesung PNr VNr VName Zeit 1 St Steuern 90 1 Bi Bilanz 60 2 J1 Java Xm XML 45 3 Li Linux 45 3 Xm XML 60 FS Prüf-Student PNr MatrNr Note , , , , , , ,5 Die drei Nichtschlüsselattribute sind in der Prüf-Student Relation zu streichen und in einer eigenen, zusätzlichen Relation Student auszulagern Abb. 3-17: Datenbank mit 2NF-Relationen 47

48 3.3. Normalisierung im Relationenmodell 2. Normalform Betrachtung der Anomalien vor 2NF: Einfüge-Anomalie für Studentendaten beseitigt (für Vorlesungsdaten noch nicht!) : Daten über Studenten können gespeichert werden, ohne dass diese an einer Prüfung beseitigt sind. Änderungs-Anomalie beseitigt Wenn sich der Name eines Studenten ändert, muss die Änderung lediglich an einer Stelle in der Relation Student vorgenommen werden. Lösch-Anomalie beseitigt Wird die letzte Prüfung gelöscht, an der ein Student teilgenommen hat, gehen die Daten des Studenten dadurch nicht verloren. Relationen in der 2NF verhindern viele Anomalien und erleichtern damit die Verarbeitung relationaler Datensätze erheblich. Es können aber nicht alle unerwünschten Nebeneffekte ausgeschlossen werden, insbesondere solche, die auf sog. transitiven Abhängigkeiten beruhen. 48

49 3.3. Normalisierung im Relationenmodell Dritte Normalform 2NF verhindert nicht alle Einfüge-, Änderungs- und Lösch-Anomalien Beispiel 3-16: Für die 2NF-Relation Student in Abb gelten noch die folgenden Anomalien: Einfüge-Anomalie: Da es keine eigene Relation für Studiengänge gibt, können Daten über Studiengänge nur abgespeichert werden, wenn es Studenten in diesen Studiengängen gibt. Änderungs-Anomalie: Wenn sich der Leiter eines Studienganges ändert, muss die Änderung für alle Studenten dieses Studienganges vorgenommen werden. Student MatrNr SName SG SGLeiter 1111 Max Wirtsch.-inf. Einstein 2222 Moritz Wirtsch.-inf. Einstein 3333 Ute Wirtsch.-inf. Einstein 8888 Verona Angewandte Inf. Zweistein 9999 Angela Angewandte Inf. Zweistein 4567 Otto Informatik Zuse Lösch-Anomalie: Wird der letzte Student eines Studienganges gelöscht, gehen zwangsweise auch alle Daten des Studienganges verloren. Fazit: 2NF-Relationen müssen weiter normalisiert werden... 49

50 3.3. Normalisierung im Relationenmodell 3. Normalform Eine Relation ist in der dritten Normalform (3NF), wenn sich die Relation in der zweiten Normalform befindet und kein Nichtschlüsselattribut von anderen Nichtschlüsselattributen funktional abhängig ist. eine 2NF-Relation kann durch das folgende Zerlegungsverfahren in die dritte Normalform überführt werden (s. Bsp. 3.17): Lagere alle Nichtschlüsselattribute, die von einem bestimmten Nichtschlüsselattribut oder von einer bestimmten Kombination von Nichtschlüsselattributen abhängig sind, in eine eigene, zusätzliche Relation aus. (Die ausgelagerten Nichtschlüsselattribute werden in der Ursprungsrelation gelöscht.) Ergänze die zusätzliche Relation mit den jeweils bestimmenden Nichtschlüsselattributen und definiere sie dort als Primärschlüssel. In der Ausgangsrelation werden die jeweils bestimmenden Nichtschlüsselattribute als Fremdschlüssel verwendet, um die Beziehung zur neuen Zusatzrelation herzustellen. 50

51 3.3. Normalisierung im Relationenmodell 3. Normalform Prüfung PNr Fach Datum 1 Allg. BWL Student 2 SW-Entwicklung MatrNr SName SG SGLeiter 3 Rechnersysteme Max Wirtsch.-inf. Einstein Prüf-Student Prüf-Vorlesung PNr VNr VName Zeit 1 St Steuern 90 1 Bi Bilanz 60 2 J1 Java Xm XML 45 3 Li Linux 45 3 Xm XML Moritz Wirtsch.-inf. Einstein 3333 Ute Wirtsch.-inf. Einstein 8888 Verona Angewandte Inf. Zweistein 9999 Angela Angewandte Inf. Zweistein 4567 Otto Informatik Zuse PNr MatrNr Note , , , , , , ,5 Beispiel 3-17: Die Relationen aus Abb (s. oben) sollen weiter normalisiert werden. Dazu ist im nächsten Schritt eine Überführung in die 3NF erforderlich. Relation Prüfung Relation Prüf-Vorlesung Relation Prüf-Student Relation Student ist bereits in der 3NF ist bereits in der 3NF ist bereits in der 3NF verletzt die 3NF durch transitive Abhängigkeit: MatrNr SG SGLeiter => die beteiligten Nichtschlüsselattribute in eigene Relation auslagern (s. folgende Abb. 3-18) 51

52 3.3. Normalisierung im Relationenmodell 3. Normalform Student Prüfung MatrNr SName SG PNr Fach Datum 1111 Max Wirtsch.-inf. 1 Allg. BWL Moritz Wirtsch.-inf. 2 SW-Entwicklung Ute Wirtsch.-inf. 3 Rechnersysteme Verona Angewandte Inf Angela Angewandte Inf Otto Informatik Prüf-Vorlesung PNr VNr VName Zeit SGLeiter wird in Rel. 1 St Steuern 90 Student gestrichen und in 1 Bi Bilanz 60 eigene Rel. ausgelagert. 2 J1 Java 1 60 Prüf-Student Dort wird SGLeiter durch 2 Xm XML 45 PNr MatrNr Note PS SG ergänzt. In Rel. 3 Li Linux ,0 3 Xm XML ,0 Student dient SG dann ,0 als FS ,5 Studiengang ,0 SG SGLeiter ,5 Wirtsch.-inf. Einstein ,5 Angewandte Inf. Zweistein Informatik Zuse Abb. 3-18: Datenbank mit 3NF-Relationen 52

53 3.3. Normalisierung im Relationenmodell 3. Normalform Betrachtung der Anomalien vor 3NF: Einfüge-Anomalie beseitigt Daten über Studiengänge können nun eigenständig ohne Studenten abgespeichert werden Änderungs-Anomalie beseitigt Wenn sich der Lehrer eines Studiengangs ändert, muss die Änderung nur an einer Stelle in der Relation Studiengang vorgenommen werden. Lösch-Anomalie beseitigt Wird der letzte Student eines Studiengangs gelöscht, gehen die Daten des Studiengangs dadurch nicht verloren. 3NF beseitigt alle Unregelmäßigkeiten die auf Grund von Nichtschlüsselattributen entstehen können. Jetzt noch: ausschließen von Unregelmäßigkeiten die sich auf Grund von Schlüsselattributen ergeben können. 53

54 3.3. Normalisierung im Relationenmodell Boyce-Codd-Normalform 3NF verhindert alle Anomalien, die durch Nichtschlüsselattribute verursacht werden es gibt noch Anomalien, die durch Schlüsselattribute verursacht werden Beispiel 3-18: Für die 3NF-Relation Prüf-Vorlesung in Abb gelten noch die folgenden Anomalien: - Einfüge-Anomalie: Da es keine eigene Relation für Vorlesungen gibt, können Daten über Vorlesungen nur abgespeichert werden, wenn es Prüfungen über diese Vorlesungen gibt. - Änderungs-Anomalie: Wenn sich der Name einer Vorlesung ändert, muss die Änderung für alle Prüfungen mit dieser Vorlesung vorgenommen werden (z.b. XML). - Lösch-Anomalie: Wird die letzte Prüfung gelöscht, in der eine bestimmte Vorlesung geprüft wurde, gehen zwangsweise auch alle Vorlesungsdaten verloren. Prüf-Vorlesung PNr VNr VName Zeit 1 St Steuern 90 1 Bi Bilanz 60 2 J1 Java Xm XML 45 3 Li Linux 45 3 Xm XML 60 => 3NF-Relationen müssen weiter normalisiert werden, wenn immer noch Datenfelder unterschiedlicher IOs in einer gemeinsamen Relation gespeichert werden. 54

55 3.3. Normalisierung im Relationenmodell Boyce-Codd-NF Eine Relation ist in der Boyce-Codd-Normalform (BCNF), wenn sich die Relation in der dritten Normalform befindet und die Relation keine Teilschlüssel-Abhängigkeiten aufweist. eine 3NF-Relation kann durch das folgende Zerlegungsverfahren in die Boyce-Codd- Normalform überführt werden (s. Bsp. 3.19): Lagere alle Attribute, die von einem bestimmten Teilschlüssel abhängig sind, in eine eigene, zusätzliche Relation aus. (Die ausgelagerten Attribute werden in der Ausgangsrelation gelöscht.) Ergänze die zusätzliche Relation mit dem betreffenden Teilschlüssel und definiere ihn dort als Primärschlüssel. In der Ausgangsrelation wird der betreffende Teilschlüssel als Fremdschlüssel verwendet, um die Beziehung zur neuen Zusatzrelation herzustellen. 55

56 3.3. Normalisierung im Relationenmodell Boyce-Codd-NF Prüfung PNr Fach Datum 1 Allg. BWL SW-Entwicklung Rechnersysteme Prüf-Vorlesung PNr VNr VName Zeit 1 St Steuern 90 1 Bi Bilanz 60 2 J1 Java Xm XML 45 3 Li Linux 45 3 Xm XML 60 Student MatrNr SName SG 1111 Max Wirtsch.-inf Moritz Wirtsch.-inf Ute Wirtsch.-inf Verona Angewandte Inf Angela Angewandte Inf Otto Informatik Studiengang SG SGLeiter Wirtsch.-inf. Einstein Angewandte Inf. Zweistein Informatik Zuse Prüf-Student PNr MatrNr Note , , , , , , ,5 Beispiel 3-19: Die Relationen aus Abb (s. oben) sollen weiter normalisiert werden. Dazu ist im nächsten Schritt eine Überführung in die BCNF erforderlich. Relation Prüfung Relation Student Relation Prüf-Student Relation Studiengang Relation Prüf-Vorlesung VNr VName ist bereits in der BCNF ist bereits in der BCNF ist bereits in der BCNF ist bereits in der BCNF verletzt die BCNF durch die Teilschlüssel-Abhängigkeit: => VName in eigene Relation auslagern (s. folgende Abb. 3-19) 56

57 3.3. Normalisierung im Relationenmodell Boyce-Codd-NF Vorlesung VNr VName St Steuern Bi Bilanz J1 Java 1 Xm XML Li Linux Prüfung PNr Fach Datum 1 Allg. BWL SW-Entwicklung Rechnersysteme Student MatrNr SName SG 1111 Max Wirtsch.-inf Moritz Wirtsch.-inf Ute Wirtsch.-inf Verona Angewandte Inf Angela Angewandte Inf Otto Informatik Prüf-Vorlesung PNr VNr Zeit 1 St 90 1 Bi 60 2 J Xm 45 3 Li 45 3 Xm 60 Prüf-Student PNr MatrNr Note , , , , , , ,5 Studiengang SG SGLeiter Wirtsch.-inf. Einstein Angewandte Inf. Zweistein Informatik Zuse Abb. 3-19: Datenbank mit BCNF-Relationen 57

58 3.3. Normalisierung im Relationenmodell Boyce-Codd-NF Betrachtung der Anomalien nach 3NF: Einfüge-Anomalie beseitigt Daten über Vorlesungen können nun eigenständig ohne Prüfungen abgespeichert werden. Änderungs-Anomalie beseitigt Wenn sich der Name einer Vorlesung ändert, muss die Änderung nur einmal in der Relation Vorlesung vorgenommen werden. Lösch-Anomalie beseitigt Wird die letzte Prüfung gelöscht, in der eine bestimmte Vorlesung geprüft wurde, gehen dadurch die Vorlesungsdaten nicht verloren. 58

59 3.3. Normalisierung im Relationenmodell Vierte Normalform bei BCNF-Relationen kann es noch zu Anomalien kommen, die durch mehrwertige Abhängigkeiten verursacht werden (s. Bsp. 3-20) diese mehrwerten Abhängigkeiten entstehen nur dann, wenn mehrwertige Attribute im Rahmen der 1NF nicht in eigene, zusätzliche Relationen ausgelagert, sondern die Attributwerte einzeln miteinander kombiniert werden (s. Bsp. 3-20) werden bei Einrichtung der 1NF mehrwertige Attribute in eigene Relationen ausgelagert, gibt es keine mehrwertigen Abhängigkeiten mehr Eine Relation ist in der vierten Normalform (4NF), wenn sich die Relation in der Boyce-Codd- Normalform befindet und die Relation keine mehrwertigen Abhängigkeiten aufweist. Eine BCNF-Relation mit mehrwertigen Abhängigkeiten kann durch das gleiche Zerlegungsverfahren wie für die Überführung in die 1NF in die vierte Normalform überführt werden (s. Bsp. 3-20). 59

60 3.3. Normalisierung im Relationenmodell 4. Normalform Beispiel 3-20: Die 1NF-Relation Prüfung aus Abb soll in die 2NF, 3NF und BCNF überführt werden. Prüfung PNr Fach Datum VNr VName Zeit MatrNr SName SG SGLeiter Note 1 Allg. BWL St Steuern Max Wirtsch.-inf. Einstein 4,0 1 Allg. BWL St Steuern Moritz Wirtsch.-inf. Einstein 3,0 1 Allg. BWL St Steuern Ute Wirtsch.-inf. Einstein 2,0 1 Allg. BWL Bi Bilanz Max Wirtsch.-inf. Einstein 4,0 1 Allg. BWL Bi Bilanz Moritz Wirtsch.-inf. Einstein 3,0 1 Allg. BWL Bi Bilanz Ute Wirtsch.-inf. Einstein 2,0 2 SW-Entwicklung J1 Java Max Wirtsch.-inf. Einstein 1,5 2 SW-Entwicklung J1 Java Verona Angewandte Inf. Zweistein 5,0 2 SW-Entwicklung J1 Java Angela Angewandte Inf. Zweistein 3,5 2 SW-Entwicklung Xm XML Max Wirtsch.-inf. Einstein 1,5 2 SW-Entwicklung Xm XML Verona Angewandte Inf. Zweistein 5,0 2 SW-Entwicklung Xm XML Angela Angewandte Inf. Zweistein 3,5 3 Rechnersysteme Li Linux Otto Informatik Zuse 2,5 3 Rechnersysteme Xm XML Otto Informatik Zuse 2,5 Bei der Normalisierung entstehen die sechs Relationen aus Abb. 3-19, wobei die Ausgangsrelation auf die Form in Abb (s. nächste Seite) reduziert wird. 60

61 3.3. Normalisierung im Relationenmodell 4. Normalform Abb. 3-20: Relation mit mehrwertiger Abhängigkeit Prüf-Vorl-Stud PNr VNr MatrNr 1 St St St Bi Bi Bi J J J Xm Xm Xm Li Xm 4567 Die Relation Prüf-Vorl-Stud weist die folgenden Attributabhängigkeiten auf: PNr VNr PNr MatrNr und verletzt somit die vierte Normalform. 61

62 3.3. Normalisierung im Relationenmodell 4. Normalform Aus dieser mehrwertigen Abhängigkeit resultieren die folgenden Anomalien: - Einfüge-Anomalie: Bei 30 Prüfungsteilnehmern muss jede Vorlesung einer Prüfung 30 Mal eingetragen werden. - Änderungs-Anomalie: Wenn bei einer Prüfung aus Versehen für eine Vorlesung eine falsche VNr verwendet wurde und nachträglich geändert werden muss, betrifft dies bei 30 Prüfungsteilnehmern 30 Datensätze. - Lösch-Anomalie: Wenn sich ein Student von einer Prüfung abmeldet, muss er an drei Stellen gelöscht werden, wenn die Prüfung drei Vorlesungen beinhaltet. => umständlich: Relationen Prüf-Vorl-Stud muss weiter normalisiert werden: von BCNF in 4NF: s. Abb Attribute VNr und MatrNr jeweils in eine eigene Relation auslagern, und dort mit PNr ergänzen. => die restlichen Relationen (s. Abb. 3-19) sind alle schon in der 4NF 62

63 3.3. Normalisierung im Relationenmodell 4. Normalform Prüf Prüf-Vorl Prüf-Stud PNr PNr VNr PNr MatrNr St 1 Bi 2 J1 2 Xm 3 Li 3 Xm Abb. 3-21: Datenbank mit 4NF-Relationen Vergleich obiger Relationen aus Abb mit den sechs 4NF Relationen aus Abb. 3-19: Relation Prüf ist ein Teil der Relation Prüfung Relation Prüf-Vorl ist ein Teil der Relation Prüf-Vorlesung Relation Prüf-Stud ist ein Teil der Relation Prüf-Student => Relationen aus Abb sind redundant => Relationen ersatzlos streichen => Endergebnis ist identisch 63

64 3.3. Normalisierung im Relationenmodell Übungsaufgabe 5: In einem Unternehmen werden die Seminarbesuche aus Übungsaufgabe 4 (Entitätstypen Mitarbeiter, Institut, Seminar und Beziehungstyp besucht bei) in einer einzigen Relation Mitarbeiter wie folgt verwaltet: Mitarbeiter PNr Name Anschrift Seminar VName NName Straße PLZ Ort SNr Titel Beschreib Institut IName IAnschrift IStraße IPLZ IOrt P11 Max Struwel Viehweg 1234 Kieshausen 171 Datenbanken Es ist ein E-Lern Lernweg 1111 Lernhausen Ortsgasse 4321 Sandheim 471 Konflikte Immer als Easy-L Gripsstr Gripsbach 841 Buchhaltung Konten in E-Lern Lernweg 1111 Lernhausen P55 Moritz Struwel Nebenstr Lumpenstadt 471 Konflikte Immer als Easy-L Gripsstr Gripsbach 171 Datenbanken Es ist ein Schlaule Bahnsteig 5555 Schlauheim 911 Logistik Route A Einstein Steinstr Steinheim P99 Daniel Düse Hauptstr Helferstadt 100 Patente 1 sagt Einstein Steinstr Steinheim Ideenweg 1010 Entenhausen 200 Geldanlage Gewinn ab.. Schlaule Bahnsteig 5555 Schlauheim 64

65 3.3. Normalisierung im Relationenmodell Für die Attribute dieser Relation gelten die folgenden Abhängigkeiten: PNr VName, NName SNr Titel, Beschreib PNr, SNr IName IName IAnschrift PNr Anschrift PNr Seminar Überführen Sie die nicht normalisierte Relation Mitarbeiter mit deren Datensätzen nacheinander in die: a) erste Normalform (1NF) b) zweite Normalform (2NF) c) dritte Normalform (3NF) d) Boyce-Codd-Normalform (BCNF) e) vierte Normalform (4NF). 65

66 3.3. Normalisierung im Relationenmodell a) Erste Normalform (1NF): mehrwertige Attribute Anschrift und Seminar in eigene Relationen auslagern Mitarbeiter MA-Anschrift PNr VName NName PNr Straße PLZ Ort P11 Max Struwel P11 Viehweg 1234 Kieshausen P55 Moritz Struwel P11 Ortsgasse 4321 Sandheim P99 Daniel Düse P55 Nebenstr Lumpenstadt P99 Hauptstr Helferstadt P99 Ideenweg 1010 Entenhausen PS aus allen vorhanden Attributen, da keines der Anschrift Attribute mit PNr zusammen identifizierend ist Seminar PNr SNr Titel Beschreib IName IStraße IPLZ IOrt P Datenbanken Es ist ein E-Lern Lernweg 1111 Lernhausen P Konflikte Immer als Easy-L Gripsstr Gripsbach P Buchhaltung Konten in E-Lern Lernweg 1111 Lernhausen P Konflikte Immer als Easy-L Gripsstr Gripsbach P Datenbanken Es ist ein Schlaule Bahnsteig 5555 Schlauheim P Logistik Route A Einstein Steinstr Steinheim P Patente 1 sagt Einstein Steinstr Steinheim P Geldanlage Gewinn ab.. Schlaule Bahnsteig 5555 Schlauheim Auch die strukturierten Attribute müssen entsprechend aufgelöst werden 66

67 3.3. Normalisierung im Relationenmodell b) Zweite Normalform (2NF): Teilschlüssel-Abhängigkeit SNr Titel, Beschreib beseitigen => in eigene Relationen auslagern Mitarbeiter PNr VName NName P11 Max Struwel P55 Moritz Struwel P99 Daniel Düse MA-Anschrift PNr Straße PLZ Ort P11 Viehweg 1234 Kieshausen P11 Ortsgasse 4321 Sandheim P55 Nebenstr Lumpenstadt P99 Hauptstr Helferstadt P99 Ideenweg 1010 Entenhausen Seminarbesuch PNr SNr IName IStraße IPLZ IOrt P E-Lern Lernweg 1111 Lernhausen P Easy-L Gripsstr Gripsbach P E-Lern Lernweg 1111 Lernhausen P Easy-L Gripsstr Gripsbach P Schlaule Bahnsteig 5555 Schlauheim P Einstein Steinstr Steinheim P Einstein Steinstr Steinheim P Schlaule Bahnsteig 5555 Schlauheim Seminar SNr Titel Beschreib 171 Datenbanken Es ist ein 471 Konflikte Immer als 841 Buchhaltung Konten in 911 Logistik Route A 100 Patente 1 sagt 200 Geldanlage Gewinn ab.. 67

68 3.3. Normalisierung im Relationenmodell c) Dritte Normalform (3NF): Nichtschlüssel-Abhängigkeit IName IStraße, IPLZ, IOrt beseitigen => in eigene Relationen auslagern Mitarbeiter PNr VName NName P11 Max Struwel P55 Moritz Struwel P99 Daniel Düse MA-Anschrift PNr Straße PLZ Ort P11 Viehweg 1234 Kieshausen P11 Ortsgasse 4321 Sandheim P55 Nebenstr Lumpenstadt P99 Hauptstr Helferstadt P99 Ideenweg 1010 Entenhausen Seminarbesuch PNr SNr IName P E-Lern P Easy-L P E-Lern P Easy-L P Schlaule P Einstein P Einstein P Schlaule Institut IName IStraße IPLZ IOrt E-Lern Lernweg 1111 Lernhausen Easy-L Gripsstr Gripsbach Schlaule Bahnsteig 5555 Schlauheim Einstein Steinstr Steinheim Seminar SNr Titel Beschreib 171 Datenbanken Es ist ein 471 Konflikte Immer als 841 Buchhaltung Konten in 911 Logistik Route A 100 Patente 1 sagt 200 Geldanlage Gewinn ab.. Relationen befinden sich auch in der BCNF (in allen 5 Relationen gibt es nur einen Schlüssel, den PS, und es existieren keine Abhängigkeiten eines Schlüsselattributs von einem Teilschlüssel) und in der 4NF (da bei der Überführung in die 1NF alle mehrwertigen Attribute ausgelagert wurden) 68