DBS III

Constraints

• Die Constraints setzen uns "regeln" und definieren was wann wo erlaubt ist
• Die müssen unter allen validen Bedingungen fest halten, und auch wirklich gültig sein

Functional Dependencies

• Wir brauchen für dependencies, mit denen wir Daten verknüpfen und oder zusammenbauen #
• Wir nutzen hier das Akronym FD
• 
• Die Funktionalen Dependencies werden von den "bedeutungen" der attribute abgeleitet und stellen dar, wie die attribute miteinander Interagieren
• Wenn wir eine Datenbank bauen, müssen wir verstehen, wie FDs daten über alle möglichen Verbindungen interagieren
• Nur relation-states die mit den bestimmten FDs übereinstimmen bzw. diese Respektieren werden von uns als Valide akzeptiert

Inference RUles (IRs) for FDs

• 
• Wir betrachten "F" als menge von FDs die auf dem Relationsschema R definiert sind
• Normalerweise werden die FDs aufgestellt, die semantisch "offensichtlich" sind
• Allerdings gibt es auch sachen die von den FDs inferred werden können
• 
• "F" enthält alle legalen relationen auf der R, dementsprechend können wir schauen, wenn irgendetwas da rein passt / da drin ist, dass es dann dazugehört
• Interferiert werden die dinge mit den sog. Armstrong Axiomen (yay)

Armstrong's Axiom

Soundness, Completeness and Closure

• 
• Sound
  • Naja das passiert, wenn diese Regel jede mögliche relation die im originalen set enthalten ist enthält
• Completeness
  • Ist Complete, wenn wir die regeln wiederholt anwenden können, sodass alle möglichen FDs von der gegebenen Menge F abgeleitet werden können
• Closure
  • Eine Closure auf einer Menge F ist die Komplette menge von allen Funktionalen dependencies, die von F abgeleitet werden können

Closure

• FD Closure
  • Wenn F eine Menge von FD s ist, ist die closure $F^{+}$ eine Menge von allen FDs die logisch von F impliziert werden
• Attribute Closure
  • Wenn X eine Attribumenge ist, wird die closure $X^{+}$ eine menge von allen attributen B sein, dass $X\to B$
  • Alos, dass $X^{+}$ alle attribute die funktional von X impliziert / abgeleitet werden enthält

Algorithm

• 
• Wir schauen das uns jeztt mal als Beispiel an
• Dieses Format sehen wir warscheinlich auch in der Klausur / in der echten welt
• Wir müssen immer wieder nachfragen und checken, ob das was wir uns vorstellen, tatsächlich zutrifft
  • Das machen wir so lange, bis wir irgend eine Wand erreichen / irgend ein hindernis erkennen
• Wir können sowas einfach "ausrechnen", wir müssen allerdings auch schauen welche vorraussetzungen und welche "guidelines" uns übergeben wurden

Cover and Equivalence of FDs

• Equivalence
  • Zwei mengen von FDs E und F sind equivalent zu einander, das impliziert, dass jede Menge alle FDs von der anderen Menge ableiten kann
• Cover
  • Eine menge an FDs kann eine andere Menge E überlappen, wenn jede FD in der überlappten menge E von F inferred werden kann
• Minimal Cover of FDs

Normalization

• Es gibt verschiedene Normalformen (die kommen von codd)
• Es gibt eine stärkeare ausführung der 3NF, das ist dann die Boyce-Codd normalform BCNF
• Es gibt auch mehrere, allerdings betrachten wir hier nur die ersten 3

1NF

• 
• Keys
  • Dürfen keine multiwertattribute haben
  • Keine zusammengesetzen attributen
  • Alle keyattrubute dürfen nur einen wert haben
• Setzen sicherheit, integrität und simplicity vorraus, und verhindern komplexe strukturen
• jede DB der 1NF limitiert sich auf simple, atomic werte, wo jedes attribut einnerhalt eines Tupels ist, wodurch die komplexität von verschachtelten relationen eliminiert wird

2NF

• 
• Eine 2NF ist eine 1NF auf der alle nicht-key elemente funktional von dem primary key abhängig sind, dementsprechend gibt es keine partiellen dependencies
• 2NF baut auf dem prinzip der "vollständigen abhängigkeit"
  • Full Functional Dependency: Jedes Attribut Y ist vollständig funktional abhängig von einer menge von attributen namens X, wenn die abhängigkeit abbricht, wenn ein attribut von x entfernt wird.
    • Also: Y ist von allen X gemeinsam abhängig
  • Partial Dependency: Passiert, wenn ein attribut Y immernoch auf einem subset von X abhängig ist, was zeigt, dass nicht alle elemente von X für diese Relation benlötigt wird
• 2NF ist sehr wichtig, wenn man verdopplungen verringern will, und daten nur dann ordentlich abzuspeichern, wenn sie von einem vollständigen primary key abhängig sind

3NF

• Eine Relation ist in 3NF, wenn sie schon 2NF ist, und kein nichtprimäres Attribut eine transitive abhängigkeit zu dem Primarykey hat
  • Eine Transitive Dependency ist eine funktionale Abhängigkeit $X\to Y$ ist genau dann transitiv, wenn es eine mittelmenge $Z$ gibt, sodass $X\to Z$ und $Z\to Y$ gilt, und Z nicht teil eines Kandidatenschlüssel ist
  • Achieving 3NF enhances database design by ensuring each non-key attribute is directly related to the primary key, eliminating indirect dependencies that can cause data anomalies

Boyce-Codd Normalform (BCNF)

• Die BCNF ist eine striktere version der 3NF
• Eine Relaiton ist genau dann BCNF, wenn es in 1NF ist und jede nicht-triviale funktionale dependency $X\to A$ X ein superkey von $R$ ist
• Anders als 3NF, erlaubt BCNF keine nicht-superkey funktionalen dependencies, wo die rechte hand primäre attribute sind. Die absence macht BCNF strikter

3NF VS BCNF

• Die meissten Datenbanken die 3NF erreichen erfüllen auch BCNF.
• Um sich an BCNF zu halten, müssen viele sich an BCNF halten, um redundanz und datensicherheit zu maintainen