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

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

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)

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

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

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

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

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

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

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

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

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

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