Normalisierung (Dekomposition)

Ähnliche Dokumente
Datenbanksysteme 1 Sommersemester Juni 2006

Datenbanksysteme I Übung: Normalformen und Relationale Algebra Jana Bauckmann

Aufgabe 7. Sei die Schema R(A, B, C, D, E) mit folgenden fkt. Abh.:

Datenbanksysteme I Übung: Relationaler Datenbankentwurf. Jana Bauckmann

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D.

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

Grundlagen: Datenbanken

Relationale Entwurfstheorie (Teil 2)

3. Normalform. Redundanz: Land mehrfach gespeichert Anomalien?

Zerlegung einer Relation

5. Relationaler Datenbankentwurf. Relationaler DB-Entwurf: Überblick. Bücher-Relation mit Redundanzen

Datenmanagement Übung 5

Übung 9. Tutorübung zu Grundlagen: Datenbanken (Gruppen Do-T24 / Do-T31 WS 2016/2017)

Normalformen. Was sind Kriterien eines guten Entwurfs? So wenig Redundanz wie möglich. Keine Einfüge-, Lösch-, Änderungsanomalien

Themenübersicht Relationale Entwurfstheorie. Inhalt

Chapter 3 Das Relationenmodell

Wir haben folgende Ausprägung der Relation Studenten:

Das Relationenmodell. Contents. Pierre Fierz. Attribute und Domänen. 1 Attribute und Domänen. Relationenschema, Relation und Tupel

Dieser Foliensatz darf frei verwendet werden unter der Bedingung, dass diese Titelfolie nicht entfernt wird.

Abhängigkeiten und Normalisierung

Normalisierung II. Ziele

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

Introduction to Data and Knowledge Engineering

Lösungen der Übungsaufgaben von Kapitel 12

Datenbanken Wintersemester 2013/2014 Datenbanken 1 Sommersemester 2013/

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D.

S.Müllenbach Datenbanken Informationsanalyse Normalformen- 1. Kurse. Name TNR ...

Kapitel DB:VII (Fortsetzung)

2. Übungsblatt 3.0 VU Datenmodellierung

Kapitel 11: Relationale Entwurfstheorie

9. Logischer DB-Entwurf

Übung Datenbanksysteme I Relationaler Datenbankentwurf. Thorsten Papenbrock

Datenbanken 6: Normalisierung

Vorlesung Datenbankmanagementsysteme

Kapitel 11: Relationale Entwurfstheorie

Gruppe A Bitte tragen Sie SOFORT und LESERLICH Namen und Matrikelnr. ein, und legen Sie Ihren Studentenausweis bereit.

Entwurfstheorie relationaler Datenbanken 7. Entwurfstheorie relationaler Datenbanken

Grundlagen: Datenbanken WS 15/16

Übung Datenbanksysteme Normalformen

2. Übungsblatt 3.0 VU Datenmodellierung

7.1.2 Membership-Test - fortgesetzt

Gruppe B Bitte tragen Sie SOFORT und LESERLICH Namen und Matrikelnr. ein, und legen Sie Ihren Studentenausweis bereit.

Rückblick: Relationales Modell

Chapter 6 Normalisierung

Normalisierung I. Ziele

Kapitel 7: Formaler Datenbankentwurf

8. Tutorübung zu Grundlagen: Datenbanken

Dieser Foliensatz darf frei verwendet werden unter der Bedingung, dass diese Titelfolie nicht entfernt wird.

mehrwertige Abhängigkeiten

5. Relationale Entwurfstheorie

Datenbanken und SQL. Kapitel 3. Datenbankdesign Teil 1: Normalformen. Edwin Schicker: Datenbanken und SQL

Verfeinerung des relationalen Schemas

Kapitel 7: Normalformen

Vorlesung Datenbanktheorie. Church-Rosser-Eigenschaft der Verfolgungsjagd. Berechnung von chase(t, t, Σ) Vorlesung vom Mittwoch, 05.

Informationssysteme. Prof. Dr.-Ing. Sebastian Michel TU Kaiserslautern. Sommersemester

Datenbanksysteme Übungsblatt 1

2.4 Einführung in die Design Theorie

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D.

Kapitel 7: Normalformen

DEVO 5.1. Normalformen. Wolfgang Slany TU Wien

konzeptionelles DB-Design

Kapitel 7: Normalformen

3. Übungszettel (Musterlösung)

Grundlagen: Datenbanken

Transkript:

Kapitel 6 Normalisierung (Dekomposition) Aufgabe 6.1 [Hülle] gegeben ist: R = {A, B, C, D, E} und F = {A BC, CD E, AC E, B D, E AB} a) Ein Schlüssel für R = (R, F) ist: {E} b) Weitere Schlüssel sind: {A}, {B, C} und {D, C} c) Die zwei folgenden FDs sind aus F ableitbar und nicht trivial (1) AD E (2) BC A d) Beweis von c) (1) Ableitung für AD E A BC AD BCD (A3) AD CD (A5) CD E in F AD E (A2) (2) Ableitung für BC A B D BC DC (A3) DC E in F BC E (A2) E AB in F BC AB (A2) BC A (A5) Aufgabe 6.2 [Basis] Gegeben ist: G = {A C, AB C, C DI, CD I, EC AB, EI C} a) Basis für die FD Menge: B = {EC A, C I, EC B, EI C, A C, C D} 6-1

b) Datenbankschema: c) Betrachtung zur BCNF: R1 = ({E, A, B, C}, {EC A, EC B, A C}) R2 = ({D, C, I}, {C I, C D}) R3 = ({E, C, I}, {C I, EI C}) R1: Die einzigen Schlüssel in R1 sind {E, C} und {E, A}. Die linke Seite der FD A C ist kein Superschlüssel. Daher ist R1 nicht in BCNF. R2: Der einzige Schlüssel von R2 ist {C}. Da ausser den Schlüsselbedingungen keine weiteren nicht trivialen FDs existieren, ist R2 in BCNF. R3: Die einzigen Schlüssel in R3 sind {E, C} und {E, I}. Die linke Seite der FD C I ist kein Superschlüssel. Daher ist R3 nicht in BCNF. Aufgabe 6.3 [Normalisierungsaufgabe] a) An Hand der Problembeschreibung wollen wir die wichtigsten funktionalen Abhängigkeiten festlegen. Dazu werden noch die folgenden Annahmen getroffen, die nicht in der Beschreibung enthalten sind (andere Annahmen könnten zu einer anderen Zerlegung führen): Eine Abteilung hat nur einen Manager. Projekte können erfasst werden, wenn noch kein Angestellter am Projekt arbeitet. An einem Projekt können mehrere Mitarbeiter beteiligt sein. Ein Angestellter hat nur einen Namen aber mehrere Angestellte können denselben Namen haben. Eine Telefonnummer ist nur einem Mitarbeiter zugeteilt. In einem Büro können mehrere Angestellte der gegebenen Abteilung arbeiten. Aus den Beschreibungen der Aufgabe und den obigen Ergänzungen ergeben sich nun die folgenden Funktionalen Abhängigkeiten: anr Manager Manager anr anr ABudget pnr Name pnr TelNr TelNr pnr pnr BueroNr TelNr BueroNr pnr anr BueroNr anr pnr Manager prnr Bezeichnung {prnr, anr} PRBudget In der Abbildung 1-1 sind diese Abhängigkeiten dargestellt. 6-2

PRBudget anr prnr Bezeichnung Name pnr TelNr BueroNr anr Manager ABudget Abbildung 6-1: Volle funktionale Abbhängigkeiten b) Aus den gefundenen FDs geht hervor, dass es zwei mögliche Schlüssel für diese Relation gibt: {pnr, prnr} und {prnr, TelNr} c) Aus diesen Abhängigkeiten können wir die Schemata in 2NF ableiten. Angestellt Projekt AngProj AbtProj = ({pnr, Name, TelNr, BueroNr, anr, Manager, ABudget}, {pnr},ks{telnr}) = ({prnr, Bezeichnung}, {prnr}) = ({prnr, pnr}, {prnr, pnr} fs({prnr}, Projekt, cas), fs({pnr}, Angestellt, cas)) = ({prnr, anr, PRBudget}, {prnr, anr}, fs({prnr}, Projekt, cas)) Das Schema AngProj ist notwendig, damit wir festhalten können, welche Mitarbeiter am Projekt arbeiten. Die Schemata Projekt, AngProj und AbtProj sind bereits in 3. Normalform, da neben dem Primärschlüssel höchstens noch ein Attribut existiert. In Angestellt ist TelNr ein Kandidatschlüssel, da zwischen Angestellten und Telefonnummern eine 1 zu 1 Beziehung besteht. Also ergeben sich die folgenden transitiven abhängigkeiten: pnr BueroNr anr und pnr anr Manager und pnr anr ABudget Um diese Abhängigkeiten zu eliminieren zerlegen wir die Relation Angestellt folgendermassen: Angestellt = ({pnr, Name, TelNr, BueroNr}, {pnr}, ks{telnr}, fs({bueronr}, Buero, res)) Buero = ({BueroNr, anr}, {BueroNr}, 6-3

Abteilung fs({anr}, Abteilung, res)) = ({anr, Manager, ABudget}, {anr}, ks{manager}, fs({manager}, Angestellt, res)) Es existieren nun keine weiteren transitiven abhängigkeiten daher erhalten wir folgendes Datenbankschema in 3NF: Abteilung = ({anr, Manager, ABudget}, {anr}, ks{manager}, fs({manager}, Angestellt, res)) Angestellt = ({pnr, Name, TelNr, BueroNr}, {pnr}, ks{telnr}, fs({bueronr}, Buero, res)) Projekt AngProj AbtProj Buero Aufgabe 6.4 [Binäre Relation] = ({prnr, Bezeichnung}, {prnr}) = ({prnr, pnr}, {prnr, pnr} fs({prnr}, Projekt, cas), fs({pnr}, Angestellt, cas)) = ({prnr, anr, PRBudget}, {prnr, anr}, fs({prnr}, Projekt, cas)) = ({BueroNr, anr}, {BueroNr}, fs({anr}, Abteilung, res)) Gegeben sei das Relationenschema R = {A 1, A 2 }. a) Wir stellen fest, dass nur zwei nichttriviale FDs möglich sind: A 1 A 2 und A 2 A 1. In beiden Fällen ist dann die linke Seite ein Schlüssel für die Relation. Das heisst, die Relation ist in 3NF. b) Mit derselben Überlegung wie bei a) können wir sagen, dass die Relation in BCNF ist. c) Fast wahr aber nicht ganz. Wir nehmen an, dass für die Relation r REL(R) die folgende Formel gilt. r = π A1 (r) π A2 (r) Da die beiden Projektionen keine gemeinsamen Attribute aufweisen, ist die Verbundoperation gleich dem Kartesischen Produkt der beiden Projektionen. In diesem Fall gelten die beiden speziellen aber nicht trivialen mehrwertigen Abhängigkeiten A 1 und A 2 Das heisst, r verletzt die 4NF, da kein Schlüssel von r ist. Aufgabe 6.5 [Dekomposition] a) Wir müssen folgendes zeigen: ( r REL(R))A B = r = π A,B (r) π A,C (r) 6-4

r π A,B (r) π A,C (r): (a, b, c) r (a, b) π A,B (r) (a, c) π A,C (r) (a, b, c) π A,B (r) π A,C (r) π A,B (r) π A,C (r) r: (a, b, c) π A,B (r) π A,C (r) (a, b) π A,B (r) (a, c) π A,C (r) (a, b, d) r (a, e, c) r b = e weil A B (a, b, c) r b) Das folgende kleine Beispiel zeigt, dass die Umkehrung von a) nicht gilt. r(r) A B C b1 c1 b2 c1 b1 c2 b2 c2 π A,B (r(r)) A B b1 b2 π A,C (r(r)) A C c1 c2 Man sieht sofort, dass die obige Gleichung r(r) = π A,B (r(r)) π A,C (r(r)) erfüllt ist aber die funktionale Abhängigkeit R.A R.B ist nicht erfüllt. 6-5