Seien Teilmengen eines Relationenschemas . ist von funktional abhängig oder bestimmt funktional, geschrieben , genau dann wenn zu jeder Relation und jedem Wert in genau ein Wert in gehört:
Lieferant()
Funktionale Abhängigkeiten:
{LName} → {LAdr}
{LName, Ware} → {Preis}
{LName} → {LName} (trivial)
{LName, Ware} → {Ware} (trivial)
{LName, Ware} → {LAdr} (partiell)
Funktionale Abhängigkeiten sind wichtige Regeln, um die Datenqualität sicherzustellen. Sollte in einer Relation die FD erfüllt sein, so darf folgende SQL-Anfrage kein Ergebnis liefern:
select A, count(distinct B)
from r
group by A
having (count(distinct B) > 1)
Diese Überprüfung garantiert aber nicht, dass auch zukünftig die FD erfüllt ist.
Funktionale Abhängigkeiten sind wichtige Regeln, um die Datenqualität sicherzustellen.
xxxxxxxxxx
select *
from r
where A = a and B <> b
Hohe Datenqualität
Geringe Kosten, um die Datenqualität zu prüfen
Anlegen eines Index für jede FD
Zwar kann jede FD in logarithmischer Zeit geprüft werden, aber die Anzahl der FDs kann sehr hoch sein
Minimierung der Anzahl der FDs
Gibt es eine zu äquivalente Menge , die
Ziel: Zu einer gegebenen Menge an FDs soll eine möglichst kleine äquivalente Menge von FDs berechnet werden.
Naiver Ansatz
Effizienterer Ansatz
Direkte Überprüfung, ob eine FD aus einer vorgegebenen Menge ableitbar ist.
Erstellung einer minimalen Repräsentantenmenge , so dass alle FDs in aus ableitbar sind
Vorgehensweise
Eine FD ist trivial, wenn gilt
Eine FD heißt voll, wenn es keine echte Teilmenge gibt, so dass gilt.
Seien und (aber nicht ). Sei und gelte . Dann ist transitiv abhängig von
Zu einer gegebenen Menge von FDs soll die Menge aller gültigen FDs berechnet werden.
Zur Berechnung von werden folgende Regeln genutzt (Armstrong Axiome):
Alle gültigen FDs in können mit Hilfe dieser Regeln auch hergeleitet werden.
Trotz der Eigenschaften der Armstrong-Axiome ist es komfortabler noch folgende Regeln zu benutzen:
Algorithmus zur Berechnung der Hülle mit gegebenen F (Menge der FDs einer Anwendung) und A (alle Attribute die von A funktional bestimmt werden)
xxxxxxxxxx
Hülle(F,A):
Erg = A // A → A trivial
While(Erg ändert sich):
Foreach(B → C in F):
if(B ⊆ Erg):
Erg = Erg + C
return Erg
Gesucht ist Hülle
Erklärung zu den einzelnen Schritten:
Ziel: Minimierung der FDs einer Anwendung (Menge )
Gegeben: Menge mit funktionalen Abhängigkeiten
Führe für jede FD aus F die Linksreduktion durch:
Überprüfe für alle , ob überflüssig ist, d.h. ob Hülle
Ist dies der Fall, ersetze in durch
Führe für jede verbliebende FD die Rechtsreduktion durch:
Überprüfe für alle , ob überflüssig ist, d.h. ob Hülle
Ist dies der Fall, wird durch ersetzt
Entferne die FDs der Form (die im 2-ten Schritt entstanden sind)
Ersetze alle FDs der Form durch ...
Schritt 1: Linksreduktion
Info: Einelementige linke Seiten werden übersprungen.
, A ist überflüssig, da in der Hülle von enthalten ist: Hülle. Ersetze also mit .
Wir erhalten also:
Schritt 2: Rechtsreduktion
Fragestellung bei der ersten FD : Kommen wir, wenn wir weglassen trotzdem irgendwie von nach ? Antwort: Nein! Wir kommen von nur nach , aber von nicht mehr weiter. muss also weiterhin enthalten bleiben.
Führt man diesen Schritt für alle FDs aus erhält man:
Schritt 3: Entferne FDs der Form
Schritt 4: Fasse alle FDs mit gleicher linker Seite zu einer zusammen
Definition verlustlose Zerlegung:
Sei zerlegt in und , die Zerlegung ist verlustlos, falls:
Zusätzlich wollen wir, dass die FDs lokal auf den zerlegten Relationen prüfbar sind, daraus ergibt sich folgende Definition.
Definition hüllentreue Zerlegung:
Seien lokale Mengen von FDs für die Relationen . Eine Zerlegung heißt hüllentreu, falls gilt:
=
Sei und eine Zerlegung von RS. Zeigen oder widerlegen Sie, ob die folgende Zerlegung von verlustlos und hüllentreu ist.
Verlustlosigkeit:
Aus der Definition folgt, dass entweder oder gelten muss.
Wir sehen, dass also gilt. Somit ist die Zerlegung verlustlos.
Hüllentreue:
Hierfür schauen wir, ob alle FDs aus in den beiden Schemata und "untergebracht" werden können. Beispielsweise könnte in untergebracht werden, da sowohl , als auch in dieser Relation enthalten sind. Somit ergibt sich:
Also und somit ist die Zerlegung auch hüllentreu.
Normalformen sollen einen guten Datenbankentwurf garantieren.
Schlüsselkandidaten: Gibt es mehrere Schlüssel in einer Relation, nennt man diese auch Schlüsselkandidaten Prime Attribute: Attribute, die Teil eines Schlüsselkandidaten sind Nicht-Prime Attribute: Attribute, die nicht Teil eines Schlüsselkandidaten sind
Alle Attribute können nur atomare, nicht weiter zerlegbare Werte annehmen.
Jedes Nicht-Prime Attribut ist von jedem Schlüsselkandidaten voll funktional abhängig.
In diesem Beispiel ist TeilMenge voll funktional vom Schlüsselkandidaten (ProjektId, TeilId) abhängig. Projektleiter ist jedoch nur von ProjektId abhängig, daher wäre es nur partiell und nicht voll funktional vom Schlüsselkandidaten abhängig. Also muss die Relation in zwei Relationen aufgeteilt werden, um die 2. NF zu erhalten.
Info: 2. NF kann nur verletzt sein, wenn der Schlüssel zusammengesetzt ist.
Es gibt kein Nicht-Prime Attribut, welches von einem Schlüsselkandidaten transitiv abhängig ist.
Projektleiter ist direkt abhängig von ProjektId, ProjektLeiterEmail jedoch nur von Projektleiter und somit transitiv vom abhängig vom Schlüsselkandidaten. Um die Relation in die 3. NF zu bringen muss auch hier wieder eine neue Relation erzeugt werden.
Ziel: Zerlegung einer Universalrelation in Relationen unter folgenden Bedingungen:
Eingabe:
Ausgabe:
Ablauf:
Berechnung der kanonischen Überdeckung von
Für jede :
Falls kein erzeugtes Schema den Kandidatenschlüssel von enthält, erzeuge Relation mit Schema und .
Eliminiere alle Schemata, die in einem anderen Schema enthalten sind.
Synthesealgorithmus liefert ein Datenbankschema mit folgenden Eigenschaften:
Schritt 2 (Relationenschemata erzeugen):
mit FDs mit FDs mit FDs
Schritt 3:
Da Schlüsselkandidat in diesem Beispiel unbekannt, muss man diesen erst herausfinden: Alle Attribute können über und erreicht werden, daher ist der Schlüssel . Da in keiner der Relationen aus Schritt 2 vollständig enthalten ist, muss entsprechend eine 4. Relation erzeugt werden:
Schritt 4:
Keine Relation kann eliminiert werden, da keine Relation vollständig in einer anderen Relation enthalten ist.