Prof. Dr. Rolf Lauser

Transkript

1 Prof. Dr. Rolf Lauser Dr.-Gerhard-Hanke-Weg Dachau Tel.: 08131/ Fax: 08131/ Von der Industrie- und Handelskammer für München und Oberbayern öffentlich bestellter und vereidigter Sachverständiger für Systeme und Anwendungen der Informationsverarbeitung im kaufmännisch-administrativen Bereich Sowie Datenschutz und Datensicherheit Datenmodellierung und Normalisierung 1 Es ist eine Datenbank zu modellieren in der eine Zuordnung von Personal zu Projekten abgebildet werden kann. Der Systemplaner hat im Rahmen der Analyse herausgearbeitet, dass dazu die folgenden Attribute notwendig sind: Attribut Beschreibung P# Personal-Nummer (Ganzzahlig, Key) P_Name Name des Mitarbeiters (Text) Abtl Abteilungskürzel der Abteilung (Text) Abt-Nam Benennung der Abteilung (Text) Pjt# Projekt-Nummer (Ganzzahlig) Pjt_Nam Benennung des Projektes (Text) P_Pjt_Zeit Prozentuale Aufteilung der Arbeitszeit auf die Projekte (Ganzzahlig) 1 ) Literatur : Hansen / Neumann; Wirtschaftsinformatik 1; Kapitel 2.2.3; Stuttgart (2009) Abts / Mülder; Masterkurs Wirtschaftsinformatik; Kapitel 11; Wiesbaden 2010)

2 Prof. Dr. Rolf Lauser Seite 2 Als Tabelle könnte dies folgendermaßen aussehen: PERSONAL P# P_Name Abtl Abt-Nam Pjt# Pjt_Nam P_Pjt_Zeit 101 Hans 1 Physik 11,12 A, B 60, Rolf 2 Chemie 13 C Karl 2 Chemie 11, 12, 13 A, B, C 20, 50, Paul 1 Physik 11, 13 A, C 80, 20 Die obige Tabelle ist gut verständlich, aber sie ist noch nicht in der ersten Normal-Form, da die Tabelle noch Attribute besitzt, die nicht einfache Werte sind. Die Attribute Pjt#, Pjt_Nam und P_Pjt_Zeit beinhalten nämlich noch interne Tabellen. Dies widerspricht aber der ersten Normal-Form Eine Relation befindet sich in der ersten Normal-Form, wenn ihre Attribute nur einfache Attribut-Werte aufweisen. Die Überführung in die erste Normal-Form ändert noch nichts an der Struktur der Relation. Lediglich die Abspeicherung der Daten ist von diesem ersten Schritt der Normalisierung betroffen.

3 Prof. Dr. Rolf Lauser Seite 3 In der ersten Normal-Form hätte dann unsere Tabelle das folgende Aussehen: PERSONAL-PROJEKT P# P_Name Abtl Abt-Nam Pjt# Pjt_Nam P_Pjt_Zeit 101 Hans 1 Physik 11 A Hans 1 Physik 12 B Rolf 2 Chemie 13 C Karl 2 Chemie 11 A Karl 2 Chemie 12 B Karl 2 Chemie 13 C Paul 1 Physik 11 A Paul 1 Physik 13 C 20 Der Informations-Gehalt der Relation hat sich nicht geändert. Aber um einen eindeutigen Zugriff zu ermöglichen war es notwendig, den Key zu erweitern. Es ist eindeutig ersichtlich, dass diese Relation noch Redundanzen aufweist: P_Nam kann aus P# abgeleitet werden (ist abhängig) Pjt_Nam kann aus Pjt# abgeleitet werden Darüber hinaus kann bei dieser Relation eine sog. Mutations-Anomalie auftreten:

4 Prof. Dr. Rolf Lauser Seite 4 Wir beispielsweise im ersten Tupel der Name von Hans auf Fritz geändert, diese Änderung aber nicht im zweiten Tupel nachvollzogen, so wird, da beide Tupel die gleiche P# haben die Relation widersprüchlich. Das Problem liegt offensichtlich darin, dass in der gleichen Relation verschiedene Sachverhalte: Personalien, Abteilungszugehörigkeiten und Projektzuordnungen beschrieben werden Diese unterschiedlichen Sachverhalte sind jedoch unabhängig voneinander und können in der Realität unabhängig voneinander geändert werden. Dieses Problem ist durch die Überführung in die zweite Normal-Form zu beheben. Eine Relation ist in der zweiten Normal-Form, wenn sie in der ersten Normal-Form ist und jedes nicht zum Identifikations-Schlüssel gehörige Attribut voll von diesem abhängig ist. Die Zweite Normal-Form erzwingt deshalb eine Umgruppierung der Attribute.

5 Prof. Dr. Rolf Lauser Seite 5 In unserem Beispiel ist deshalb unsere Ausgangs-Relation in 3 Relationen aufzusplitten PERSONAL P# P_Nam Abtl Abt_Nam 101 Hans 1 Physik 102 Rolf 2 Chemie 103 Karl 2 Chemie 104 Paul 1 Physik PROJEKT Pjt# Pjt_Nam 11 A 12 B 13 C PROJEKTZUGEHÖRIGKEIT P# Pjt# P_Pjt_Zeit

6 Prof. Dr. Rolf Lauser Seite Diese 3 Relationen besitzen den identischen Informationsgehalt wie die ursprüngliche Relation. Die Verbindung zwischen den Relationen erfolgt implizit durch korrespondierende Attribute. Die Relationen PROJEKT und PROJEKTZUGEHÖRIGKEIT enthalten jetzt keine inneren Redundanzen mehr. In der Relation PERSONAL hingegen ist für jeden Mitarbeiter der Abteilungsname abgespeichert, wobei dieser sich bereits aus der Abteilungs-Nummer (Abtl) ergibt. Ändert sich aber der Abteilungsname, so könnte auch hier eine Mutations-Anomalie auftreten. Um dies zu verhindern ist die Dritte Normal-Form notwendig. Eine Relation befindet sich in der dritten Normal-Form, wenn sie in der zweiten Normal-Form ist und kein Attribut das nicht zum Identifikations-Schlüssel gehört, transitiv von diesem abhängt. Die Relation PERSONAL (P#, P_Nam, Abtl, Abt_Nam) ist zwar in der zweiten, nicht aber in der dritten Normal-Form, weil das Attribut Abt_Nam über Abtl transitiv vom Schlüssel P# abhängt. Oder umgekehrt auch Abtl über Abt_Nam.

7 Prof. Dr. Rolf Lauser Seite 7 Zur Überführung in die dritte Normal-Form ist es unerlässlich, die Relation PERSONAL in 2 Relationen aufzuspalten. PERSONAL P# P_Nam Abtl 101 Hans Rolf Karl Paul 1 ABTEILUNG Abtl Abt_Nam 1 Physik 2 Chemie 13 C PROJEKT Pjt# Pjt_Nam 11 A 12 B 13 C PROJEKTZUGEHÖRIGKEIT P# Pjt# P_Pjt_Zeit

8 Prof. Dr. Rolf Lauser Seite Relationen in der dritten Normal-Form werden auch kurz als Normalisiert bezeichnet. In der Praxis heißt eine Datenbank dann relational, wenn sie aus einer Menge von Relationen, die alle in der ersten Normal-Form sind, besteht, Allerdings besteht dabei die Gefahr von Mutations-Anomalien. Deshalb sollte die Normalisierung nicht bei der ersten Normal-Form stehen bleiben.

9 Prof. Dr. Rolf Lauser Seite 9 Aufgabe: Es ist eine Auftrags-Datenbank zu Modellieren und in die dritte Normal-Form zu überführen. Diese Datenbank soll in Summe die folgenden Attribute umfassten: AUFTRAG Auftragsnummer (Auf#) (Key) Artikelnummer (Art#) Artikelbezeichnung (Art_Bez) Menge (Meng) Preis (Preis) Kundennummer (Kund#) Kundenname (Kund_Nam) Adresse des Kunden (K_Adr) Datum (Datum)