Übungsblatt 4. Aufgabe 7: Datensicht Fachkonzept (Klausur SS 2002, 1. Termin)

Transkript

1 Übungsblatt 4 Aufgabe 7: Datensicht Fachkonzept (Klausur SS 2002, 1. Termin) Die Saartal Linien beauftragen Sie mit dem Entwurf der Datenstrukturen für ein Informationssystem. Dieses soll zur Verwaltung der relevanten Informationen und zur Unterstützung von Dispositionsaufgaben eingesetzt werden. Ihnen ist folgender Sachverhalt bekannt: Ein Jahresfahrplan enthält Informationen zu mehreren Linien. Eine Linie setzt sich aus mindestens fünf Teilstrecken zusammen, wobei eine Teilstrecke zu verschiedenen Linien gehören kann (bspw. Teilstrecke Kaiserstrasse - Hauptbahnhof). Eine Teilstrecke ist eindeutig definiert durch zwei Haltestellen und die dafür geltenden Ankunfts- und Abfahrtszeiten. Jeder Teilstrecke einer Linie sind genau ein Fahrer und ein Bus zugeordnet. Ein Fahrer kann natürlich für mehrere Teilstrecken einer Linie eingesetzt werden, was auch für die Busse gilt. Neben den Busfahrern sind das Wartungs- und Verkaufspersonal ebenfalls Mitarbeiter der Saartal Linien. Verwenden Sie zur Modellierung das Entity-Relationship-Modell und geben Sie auch die Kardinalitäten (in min/max-notation) und die Schlüsselattribute an!

2 Aufgabe 8: Relationenmodell (Klausur SS 2000, 1. Termin) Überführen Sie das dargestellte Entity Relationship Model (ERM) in ein Relationenmodell (Auf den Normalisierungsprozess kann verzichtet werden)!

3 Relationenmodell: Teil der DV-Konzept Ebene (Überführung des Fachkonzepts ins DV- Konzept) Folie 1: Vom ERM zum Relationenmodell Es wird eine Tabelle erzeugt, die Daten des Entitys enthält Folie 2: Datenbeschreibung n:m Beziehung Aus den Entitys werden Tabellen angelegt mit den Daten des Entitys. Die Relation wird in einer eigenen Tabelle angelegt. Diese enthält die Schlüsselattribute der beiden Entitys.

4 Folie 3: Datenbeschreibung 1:n Beziehung Kann eigentlich auch gelöst werden wie n:m Beziehung mit drei Tabellen. Aber es geht auch einfacher: Man nimmt das Schlüsselattribut der n-relation mit in die Tabelle der 1- Relation als eigene Spalte. Dieses "importierte" Schlüsselattribut wird als Fremdschlüssel bezeichnet ("foreign key") Folie 4: Datenbeschreibung 1:1 Beziehung Man kann beide Entitys in eine Tabelle schreiben. Das Schlüsselattribut wird aus den beiden ausgewählt. (welches ist am sinnvollsten?)

5 Folie 5: Mehrstellige Beziehung Z.B. Drei Entitytypen sind miteinander verbunden. Alle drei Schlüsselattribute werden in der Tabelle als Spalten angelegt. Folie 6: Generalisierung/Spezialisierung

6 Folie 7: Rekursive Beziehungen Bei Überführung in die Relation wird die Tabelle für das Entity gebildet Die Struktur wird abgebildet in dem die Schlüssel in der Struktur aufgespalten werden, als einzelne Spalten in einer Tabelle. Lösung der Aufgabe 8: Schritt 1: Überführung der Entitytypen: R.Mitarbeiter (MANR, NAME) R.Zeit (DATUM) R.Projekt (PNR, PNAME) R.Innerbetriebliche Leistung (LNR, LNAME) Schritt 2: Überführung der Relationen R.Position (MANR, DATUM, LNR) R.Auftragskopf (MANR, DATUM) R.Leitet (MANR, PNR) da 1:n Beziehung kann auch statt R.Leitet zu kreieren kann PNR als Attribut zur R.Mitarbeiter genommen werden Datenanomalien - Einfügeanomalie (im u.g. Beispiel: neuer Angestellter hat keine TelNr wenn er noch keinem Projekt zugeordnet ist) - Löschanomalie (im u.g. Beispiel: Wenn Ang-Projekt-Eintrag gelöscht wird, ist TelNr des Angestellten "weg") - Update-Anomalie (im u.g. Beispiel: Bei Änderungen der TelNR müssen alle Datensätze durchlaufen werden)

7 Beispiel: R.Angestellter (ANR, NAME, ANSCHRIFT, BERUF, ABTNR) R.Projekt (PNR, PNAME, PBESCHR, P-LEITER) R.Ang-Proj (PNR, ANR, TELNR, PROZ-ARBZEIT) R.Abteilung (ABTNR, ABT-LEITER, GEBNR, HAUSMEISTER) Anforderungen an Relationen: Relationen sollen so entworfen werden, dass: - keine untergeordneten Relationen enthalten sind (aus einer Relation können mehrere R. gebildet werden) - das Datenmodell möglichst redundanzfrei ist (jedes Datum kommt z.b. genau einmal vor) - keine Inkonsistenzen (Zustand eindeutig und nachvollziehbar) - die Datenpflege problemlos zu bewerkstelligen ist (einfache Aktualisierung) Analyse und Modifikation eines initialen Relationenmodells durch Normalisierung (nach Codd) :

8 Aufgabe 9: Normalisierung Ein Handelsunternehmen kauft verschiedene Artikel von unterschiedlichen Lieferanten ein. Überführen Sie die dargestellte Tabelle in die 3. Normalform. Geben Sie dabei auch die Ergebnisse der 1. und 2. Normalform an! Normalisierung beinhaltet Transformationsregeln zur Überführung in Relationen 1. Normalform Definition 1.NF: Eine Relation R ist dann in der ersten Normalform wenn jeder Attributwert elementar ist. (d.h. in der Tabelle ist jeder Wert ausgefüllt) Die 1.NF wird durch Elimination von Wiederholungsgruppen erreicht. -> Alle Attribute sind funktional abhängig Sei S Primärschlüssel, A sei nicht Primärschlüssel A ist funktional abhängig von S, wenn jedem S genau ein A zugeordnet ist. S->A (A ist funktional abhängig von S) In der Tabelle der Aufgabe sind die erste Zeile und die vierte Zeile elementar. Die zweite, dritte, fünfte und sechste Zeile hingegen nicht!! -> Also ist die Tabelle nicht in der 1. NF!!! Überführung der Tabelle in die 1.NF: Tabelle teilen in zwei Tabellen: - Eine Tabelle für Lieferanten (hat zwei Datensätze: Lieferant Maier und Müller) - Eine Tabelle für Artikel (ab ANR) Der Schlüssel aus der Lieferantentabelle wird in die Artikeltabelle übernommen, damit der Bezug nicht verloren geht, welcher Artikel von welchem Lieferanten stammt.

9 1.NF Lösung: 2. Normalform: Definition 2.NF: Eine Relation R ist dann in der zweiten NF, wenn sie die erste NF erfüllt und jedes Nichtschlüsselattribut von jedem Schlüsselattribut voll funktional abhängig ist. Wenn eine Relation 1.NF ist und nur ein Schlüsselattribut hat, ist sie automatisch in der 2.NF!!! Ein Attribut A ist voll funktional abhängig vom zusammengesetzten Schlüssel S, wenn A funktional abhängig vom Gesamtschlüssel, nicht aber von Schlüsselteilen ist. Der Ausdruck "voll funktional" bedeutet: Das Schlüsselattribut der zweiten Tabelle ist zusammengesetzt aus LNR und ANR. Jedes der Attribute dieser Tabelle (=Spaltenüberschriften) muss von beiden Teilen des Schlüsselattributes abhängig sein!!! Also: Artikelbezeichnung ist abhängig von Artikelnummer, aber ist nicht abhängig von der Lieferantennr. -> Also nicht voll funktional abhängig!!! Einkaufspreis ist voll funktional abhängig, weil er von Lieferant zu Lieferant unterschiedlich sein kann Verkaufspreis ist nicht voll funktional abhängig, da er nicht vom Lieferant abhängig ist. Verkäufernr. ist nicht voll funktional abhängig Verkäufername ist nicht voll funktional abhängig Überführung der Tabelle in die 2.NF: Für den Einkaufspreis wird eine eigene Tabelle angelegt mit den zwei Schlüsselattributen.

10 2.NF Lösung : 3. Normalform Definition 3.NF: Eine Relation R ist in der 3.NF, wenn sie 2.NF erfüllt und kein Nicht-Schlüsselattribut transitiv von einem Schlüsselattribut abhängig ist. Wenn eine Relation 2.NF ist, und nur ein Nicht-Schlüsselattribut besitzt, dann ist sie automatisch in der 3.NF. "Transitive Abhängigkeit" bedeutet: dass ein Attribut nicht direkt vom Schlüssel abhängig ist sondern über ein anderes Attribut abhängig ist. Also sozusagen "Abhängigkeit über Umwege". Z.B.: A2 ist nicht abhängig von Schlüssel aber dafür ist es abhängig von A1 und A1 ist abhängig vom Schlüssel. Transitive Abhängigkeit in der Aufgabe: Der Verkäufername ist abhängig von der Verkäufernr., aber nicht direkt von der Artikelnummer. Überführung der Tabelle in die 3.NF: Neue Relation: Verkäufertabelle Damit die Information welcher Verkäufer für welchen Artikel zuständig ist nicht verloren geht, muss die VerkNr in der Artikeltabelle stehen bleiben!!

11 3.NF Lösung : Vorteile der Normalisierung: - Redundanzfreiheit: Jedes Faktum ist nur einmal in der DB gespeichert - Integritätssicherung: Widerspruchsfreie Datenhaltung bei Vorliegen der 3.NF Nachteile der Normalisierung: - Normalisierung kann aufwändig werden - Laufzeitverhalten (Zusammenfügen von vielen Relationen ist teuer) Normalisierungsentscheidungen müssen je nach Anwendungsfall getroffen werden.