Eine vollständige Funktionsabhängigkeit ist ein Zustand der Datenbanknormalisierung, der dem Normalisierungsstandard von Second Normal Form (2NF) entspricht. Kurz gesagt bedeutet dies, dass es die Anforderungen von First Normal Form (1NF) erfüllt und alle Nicht-Schlüsselattribute vollständig vom Primärschlüssel abhängen.
Das ist nicht so kompliziert, wie es klingt. Schauen wir uns das genauer an.
Zusammenfassung der ersten Normalform
Bevor eine Datenbank voll funktionsfähig sein kann, muss sie zuerst mit First Normal Form übereinstimmen.
All dies bedeutet, dass jedes Attribut einen einzigen atomaren Wert enthalten muss.
In der folgenden Tabelle ist dies beispielsweise der Fall nicht 1NF einhalten, da die Mitarbeiterin Tina mit zwei Standorten verbunden ist, die beide in einer Zelle liegen:
| Mitarbeiter | Ort |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles, Chicago |
Das Zulassen dieses Designs kann sich negativ auf Datenaktualisierungen oder -einträge auswirken. Um die 1NF-Kompatibilität zu gewährleisten, ordnen Sie die Tabelle neu an, sodass alle Attribute (oder Spaltenzellen) einen einzigen Wert enthalten:
Erste Normalform-Konformität
1NF reicht jedoch noch nicht aus, um Probleme mit den Daten zu vermeiden.
Funktionsweise von 2NF zur Gewährleistung der vollständigen Abhängigkeit
Um vollständig abhängig zu sein, müssen alle Nicht-Kandidaten-Schlüsselattribute vom Primärschlüssel abhängen. (Denken Sie daran, dass ein Kandidatenschlüsselattribut ein beliebiger Schlüssel ist (z. B. ein Primär- oder ein Fremdschlüssel), mit dem ein Datenbanksatz eindeutig identifiziert wird.
Datenbankdesigner verwenden eine Notation, um die abhängigen Beziehungen zwischen Attributen zu beschreiben:
Wenn das Attribut A den Wert von B bestimmt, schreiben wir diesA -> B- Bedeutet, dass B funktional von A abhängig ist. In dieser Beziehung bestimmt A den Wert von B, während B von A abhängig ist.
Zum Beispiel im Folgenden Mitarbeiterabteilungen Tabelle, EmployeeID und DeptID sind beide Kandidatenschlüssel: EmployeeID ist der Primärschlüssel der Tabelle, während DeptID ein Fremdschlüssel ist.
Jedes andere Attribut - in diesem Fall EmployeeName und DeptName - muss vom Primärschlüssel abhängen, um seinen Wert zu erhalten.
| Mitarbeiter-ID | Mitarbeitername | DeptID | DeptName |
|---|---|---|---|
| Emp1 | John | Dept001 | Finanzen |
| Emp2 | Tina | Dept003 | Der Umsatz |
| Emp3 | Carlos | Dept001 | Finanzen |
In diesem Fall ist die Tabelle nicht vollständig abhängig, da der EmployeeName vom Primärschlüssel EmployeeID abhängt, der DeptName jedoch von der DeptID. Das nennt man partielle Abhängigkeit .
Damit diese Tabelle 2NF entspricht, müssen die Daten in zwei Tabellen aufgeteilt werden:
| Mitarbeiter-ID | Mitarbeitername | DeptID |
|---|---|---|
| Emp1 | John | Dept001 |
| Emp2 | Tina | Dept003 |
| Emp3 | Carlos | Dept001 |
Wir entfernen das DeptName-Attribut aus dem Angestellte Tabelle und erstellen Sie eine neue Tabelle Abteilungen :
| DeptID | DeptName |
|---|---|
| Dept001 | Finanzen |
| Dept002 | Humanressourcen |
| Dept003 | Der Umsatz |
Nun sind die Beziehungen zwischen den Tabellen vollständig abhängig oder in 2NF.
Warum volle Abhängigkeit wichtig ist
Die vollständige Abhängigkeit zwischen Datenbankattributen trägt zur Gewährleistung der Datenintegrität und zur Vermeidung von Datenanomalien bei.
Betrachten Sie zum Beispiel die Tabelle im obigen Abschnitt, die nur für 1NF gilt. Hier ist es wieder:
| Mitarbeiter | Ort |
|---|---|
| John | Los Angeles |
| Tina | Los Angeles |
| Tina | Chicago |
Tina hat zwei Platten. Wenn wir eine aktualisieren, ohne zu wissen, dass es zwei gibt, sind die Daten inkonsistent.
Oder was ist, wenn wir einen Mitarbeiter zu dieser Tabelle hinzufügen möchten, den Standort jedoch noch nicht kennen? Es ist möglicherweise nicht zulässig, sogar einen neuen Mitarbeiter hinzuzufügen, wenn das Location-Attribut keine NULL-Werte zulässt.
Volle Abhängigkeit ist jedoch nicht das ganze Bild, wenn es um Normalisierung geht. Sie müssen sicherstellen, dass sich Ihre Datenbank in Third Normal Form (3NF) befindet.
