Anfängerfragen zu Normalisierung, Anomalien und Beziehungen

NoBrainDB

Aktiver Benutzer
Beiträge
30
Hallo!

Ich fange gerade erst an mit dem relationalen Datenmodell und Datenbanken und habe da natürlich gleich ein paar Fragen:

1. Bedeutet bei der Normalisierung "Funktionale Abhängigkeit" dass es eine bijektive Abbildung zwischen den beiden Daten gibt? Also ist hier funktional im mathemarischen Sinne gemeint? D. h. es geht darum, dass ich sagen kann "Wenn ich den Wert von Attribut X kenne, dann kann ich 100%ig sicher auf den Wert von Y schließen und umgekehrt"?

2. Wie finde ich bei der 2. Normalenform die Primärschlüssel? Meistens sind das ja irgendwelche IDs oder ArtikelNr oder sowas. Aber kann ich nicht theoretisch JEDE einzigartige Kombination von Attributen als Primärschlüssel nehmen (sofern es keine noch kleinere einzigartige Kombination gibt)? Oder ist das zu kochrezept-mäßig?

3. Die Einfüge- und Löschanomalien:

Beispiel hier aus Wikipedia: http://de.wikipedia.org/wiki/Anomalie_(Informatik)#Einf.C3.BCge-Anomalie

Das ist doch eigentlich nur dann ein Problem, wenn ich die Felder, in denen die Fragezeichen stehen, nicht mit "null" belegen darf, oder? Denn wenn da null stehen dürfte, dann könnte ich die Fahrzeuge ja anlegen und später die null-Felder belegen, oder?

Das Problem bei der Löschanomalie ist ja, dass man in relationalen DB imme rnur ganze Zeilen löschen kann, oder?

4. Eine 1:1 Beziehung zwischen 2 Entitäten kann man in eine Tabelle machen, was man aber oft nicht macht, um die Daten doch noch voneinander zu trennen, ist das richtig?

5., Generell zur Normalisierung (bis zur 3. Stufe): Könnte man das Ganze auch so formulieren: Im Prinzip ist das Ziel, alle Daten, die mit nur einem einzigen Primärschlüssel identifiziert werden können, in eine eigene Tabelle auszulagern und nur noch diejenigen ein einer gemeinsamen Tabelle zu haben, für die ein einzelner Schlüssel nicht reicht?
 
Werbung:
Hi @NoBrainDB

Zu 1:
Nicht ganz. Zusätzlich gibt es auch physische FA. Zum Beispiel kann ein Zug nicht gleichzeitig in Berlin und München sein. Allerdings muss eine FA nicht bidirektional sein. Wenn ich eine Postleitzahl von Berlin habe kann ich den Ort 100% angeben. Wenn ich allerdings nur Berlin habe erhalte ich mehrere Postleitzahlen.

Zu 2:
Wenn es mehrere Schlüsselkandidaten gibt sucht man für gewöhnlich den Superschlüssel. Daher den, auf die Anzahl der Attribute bezogen, Kleinsten. Allerdings besteht dann eine große Wahrscheinlichkeit, dass die Relation dann noch nicht in der 2. NF ist. Denn jede FA zu einem Nichtschlüsselattribut verstößt dagegen.

Zu 3:

Natürlich kannst du Anomalien durch die Anwendung verhindern. Aber warum willst du dich hier auf den Programmierer der Anwendung verlassen wenn das Problem durch Normalisierung verhindert werden kann?

Auch die Löschanomalie lässt sich durch den kreativen Einsatz von NULL-Werten umgehen. Aber auch hier machst du dich von der korrekten Funktion der Anwendung abhängig.

Du entziehst damit der Datenbank ihre Aufgabe die Daten zu jeder Zeit in einem konsistenten Zustand zu halten.

Zu 4:
Warum sollte man das tun? In einem ERM werden Entitäten natürlich getrennt modelliert. Das spätere Datenbankmodell versucht den Entwurf allerdings mit so wenig Tabellen/Attributen/Schlüsseln wie möglich umzusetzen. Durch 2 einzelne 1:1 Tabellen erzwingst du später immer einen teuren JOIN. So ein Vorgehen kann sinnvoll sein wenn du deine Datenbank partitionieren musst. Hier sprechen wir allerdings von Datenmengen die auf mehrere Festplatten verteilt werden.

Zu 5:
Das Ziel der 3. NF ist es Redundanzen und damit Anomalien zu vermeiden. Wie groß der Schlüssel der einzelnen Tabellen ist spielt keine Rolle. Der Datenbank ist es völlig gleichgültig ob du ein Auto-ID Feld als Primärschlüssel oder einen zusammengesetzen Schlüssel verwendest. Dank der, sowieso automatisch angelegten, Indizes wird kein Ansatz signifikant schneller oder langsamer sein.

Im Gegenteil sind zusammengesetzte Schlüssel, bei schwachen Entitäten, eher die Regel als die Ausnahme. Wenn hier ein Auto-ID Feld eingesetzt wird müssen physische FA oder Eindeutigkeit sogar zusätzlich durch Constraints abgesichert werden. Das führt dann häufig sogar zu höheren Schreibkosten.

Schlüssel spielen natürlich eine wichtige Rolle. Allerdings solltest du sie eher als Mittel zum Zweck verstehen.

Gruß
Hony
 
Vielen Dank erst mal für deine ausführliche Antwort!

Zu 1)
- Also funktional im Prinzip schon von Funktion, aber eine Funktion muss nicht zwangsläufig bijektiv sein, sondern kann auch surjektiv sein (also z. B. mehrere PLZ -> Berlin, aber nicht Berlin -> eindeutige PLZ), so richtig? Und die physische FA kommt noch dazu.

zu 3)
- also theoretisch könnte man Anomalien so verhindern, aber klar, da muss man dann die ganze Zeit höllisch aufpassen...

zu 4)
- Da steht hier was dazu:
http://www.sqldocu.com/nine/relationship.htm#einszueins

"Jeder Datenbank Designer vermeidet es, 2 Entitäten in einer Zeile einer Tabelle abzuspeichern. Als Primärschlüssel bietet sich DienstNr an. Fällt aus einem Grund ein Capitain aus, besitzt unsere Relation keinen Primären Schlüssel mehr. Es macht also Sinn, jede Entität (Raumschiff, Captain) in einer eigenen Relation abzuspeichern."


Generell zu 2. NF und Primärschüssel, mal am Beispiel dieses PDFs:
http://maihack.de/Vorlesungen/datenbanken/sql/Folien/Übungen-Normalisierung_1.pdf

Könnte da nicht auch P# und Pj-Name Primärschlüssel sein? Die Kombination ist ja auch eindeutig, oder?
 
Zu 1:
Der Wikipedia Artikel zur Funktionalen Abhängigkeit ist meiner Meinung nach recht ausführlich ohne dabei zu technisch zu werden.

Zu 4:

Es kommt immer auf den Einzelfall an. Die Entitäten Bahnhof und Adresse zusammen in einer Tabelle zu speichern ist problemlos möglich, da keine der beiden ohne die andere eine sinnvolle Information liefert. Hingegen könnte Bahnhof und Bahnhofvorsteher zu Löschanomalien führen. Gibt es jetzt zu Bahnhof noch die Spezialisierungen Personenbahnhof und Güterbahnhof und beide können die gleiche Adresse besitzen müsste im Zuge der Normalisierung die Adresse in einer eigene Tabelle gespeichert werden. Dann wäre es allerdings auch keine 1:1 Beziehung mehr.

Könnte da nicht auch P# und Pj-Name Primärschlüssel sein? Die Kombination ist ja auch eindeutig, oder?

Natürlich kann Pj-Name hier der Primärschlüssel sein. Streng genommen könnte man in diesem Beispiel auf die Tabelle PROJEKT verzichten. Aber hier greifen auch weitere Überlegungen:

Kann es mehrere, gegebenenfalls zeitlich versetzte, Projekte mit dem gleichen Namen geben?
In dem Fall ist der Projektname als Schlüssel pauschal ungeeignet.

Könnten sich Projektnamen ändern?
Wenn ja, dann ist der Name ebenfalls ungeeignet, da sonst die Gefahr von Update-Anomalien besteht. Sind darüber hinaus Projektnamen allerdings eindeutig muss zusätzlich ein UNIQUE Constraint definiert werden.

Generell gibt es beim Datenbankdesign einige Gesetzmäßigkeiten und darüber hinaus einen großen Strauß an Regeln. Die Regeln konsequent anzuwenden führt für gewöhnlich zu einem soliden Design. Allerdings sollte man nie vergessen, dass jede Regel einem bestimmten und definiertem Ziel dient. Deshalb ist es meines Erachtens nach wichtig jede angewandte Regel zu hinterfragen und im speziellen Fall auch davon abzuweichen. Dadurch können spezielle Anforderungen nach niedrigen Schreib- oder Lesekosten erfüllt werden und das Design kann, gemessen am Verwendungszweck, besser werden.

Für gewöhnlich wird daher bis zur BCNF normalisiert. In der Praxis wird es allerdings immer wieder Fälle geben in denen eine Normalisierung bis zur BCNF keinen Gewinn bringt und nur die Zugriffskosten erhöht. Beispiele dafür sind »Import-Tabellen« oder generell generierte Werte. Unter der Annahme, dass der Vorgang fehlerfrei durchgeführt wird und die Daten ebenso fehlerfrei sind können keine Anomalien entstehen. Hier gilt es dann eine Risikobeurteilung vorzunehmen.
 
Werbung:
@NoBrainDB
Es gibt natürlich »Kochrezepte«. Und wie ich schon schrieb bekommst du damit eigentlich immer ein solides Design. Für den Anfang würde ich daher durchaus empfehlen nur dann davon abzuweichen wenn du genau begründen kannst warum du das tun willst.
 
Zurück
Oben