Übung 4.2: Frage zu Anomalien in der Übung

waza-ari
Windoof-User
Windoof-User
Beiträge: 32
Registriert: 3. Nov 2010 20:26

Übung 4.2: Frage zu Anomalien in der Übung

Beitrag von waza-ari »

Hallo,

ich habe eine kurze Frage zu den Beispielen bezüglich Einfüge/Update-Anomalien. Mein Verständnis ist:

- Einfüge-Anomalie: Ich kann etwas nicht einfügen, ohne auch etwas anderes vorher anlegen zu müssen. In 4.2a: Ich kann eine Filiale nicht anlegen, ohne auch mindestens einen Raum anzulegen
- Lösch-Anomalie: Ich verliere zusätzliche Informationen, wenn ich einen Datensatz lösche
- Update-Anomalie: Ich muss ein Datum an vielen Stellen ändern

Nun meine Frage zu den Lösungen:

4.2a: In den Folien ist als EInfüge/Updateanomalie eine Tabelle angegeben, wo die Raum# und Stockwerk abweichen. Ich frage mich hier, warum das eine Einfügeanomalie ist? Die funktionalen Abhängigkeiten sind falsch definiert, da ein Stockwerk natürlich von Filiale und Raumnummer abhängig ist. Ich sehe ein, dass das Einfügen korrekter Informationen (R207 im 1.OG) die funktionalen Abhängigkeiten verletzt, diese sind meiner Ansicht nach aber einfach unpassend.

4.2a Löschanomalie: Wir löschen eine Zeile. Offensichtlich löschen wir keine Filiale, sondern einen Raum (denn die Filiale Ulm gibt es ja noch). Warum ist das eine Löschanomalie? Wir löschen die Information ja offensichtlich absichtlich, dabei gehen natürlich Informationen verloren. Wäre es nicht sinnvoller zu argumentieren, dass beim Löschen des letzten Raums einer Filiale auch alle Informationen über die Filiale verloren gingen (zugegeben, hier sind keine Informationen in der Tabelle).

4.2b Einfügeanomalie: Hier ist ein falscher Datensatz eingefügt worden. Sind das auch Anomalien, die auf eine zu niedrige NF zurückführbar sind? Man könnte jetzt argumentieren, dass bei Aufteilung der Relation zur 3NF das nicht mehr passieren könnte, da dann nur noch die Steuer-Kategorie in der Relation wäre und der tatsächliche Satz in einer anderen Relation mit der Kategorie verknüpft werden. Die Frage dazu: Zählt es auch als Anomalie, wenn die Datenbank durch zu niedrige NF es dem Nutzer erlaubt, inkonsistente Daten einzufügen, die eine funktionale Abhängigkeit verletzt?

Benutzeravatar
Robert
Ehemalige Fachschaftler
Beiträge: 511
Registriert: 6. Okt 2004 17:38
Wohnort: DA

Re: Übung 4.2: Frage zu Anomalien in der Übung

Beitrag von Robert »

Bei dem Thema ist es wichtig die gegebenen FDs zu beachten. Bei der Aufgabe 4.2. haben wir zwei FDs:

Code: Alles auswählen

Filiale, Raum# → Größe
Raum# → Stockwerk
Ob die FDs Sinn machen ist erstmal nicht wichtig, da man sie als gegeben annimmt. Die FDs sind also nie falsch!
(Raum# → Stockwerk macht übrigens deshalb Sinn, da es in Gebäuden üblich ist, dass die erste Ziffer das Stockwerk bezeichnet. So weiß man leicht, dass Raum 123 im 1. Stock ist und 679 im 6. Stock)

Nun zu den Anomalien:
Die Zeile Hamburg, 207, 70, 1. OG kann ich durch Einfügen erzeugen, oder durch ändern des Stockwerkes z.B. von 2.OG in 1.OG.
Die Konsistenz der Relation ist dadurch nicht verletzt, da der PK (Filiale, Raum#) weiterhin unique ist und die Attribute identifiziert. ABER die Logik, welche von den FDs definiert wird, ist verletzt da die Beziehung Raum# → Stockwerk kaputt ist. Die anderen Beispiele sind analog zu sehen.

Die Frage war jetzt was eine Anomalie genau ist:
Eine Anomalie ist wenn ich durch korrekte Operationen auf den Daten trotzdem etwas erzeugen kann, was mir die durch die FDs definierte Logik der Daten verletzt.

Natürlich könnte ich meine DB auch in der 1NF anlegen und vor jeglicher Änderung prüfen ob ich damit irgendwas verletzen würde. Für Löch-Anomalien müsste man dann Sonderfälle einführen um Informationen nicht zu verlieren. Eine solche Behandlung ist aber extrem aufwendig und wird daher nicht gemacht. Stattdessen hat man die Normalformen erdacht welche durch ihre Struktur diese Probleme schon von vornherein nicht mehr haben.
(Das ist so ähnlich wie wenn ich eine Menge von Elementen z.B. aufsteigend sortiert lesen will. Ich könnte die Menge unsortiert lassen und vor jedem Lesen alle Elemente durchgehen und mir das Größte suchen. Aber das ist höchst ineffizient. Daher sortiert man sich die Elemente einmal vor, oder nimmt gleich eine andere Datenstruktur, z.B. B-Baum, die das unterstützt.)

Antworten

Zurück zu „Archiv“