Nach meinem Verständnis ist eine Determinante möglicherweise kein Kandidatenschlüssel, wenn die Tabelle nicht vollständig normalisiert ist. In der Tat wird das Wort determinant verwendet, wenn der Prozess der Übernahme von nicht-normalen Daten in eine nützlichere, normalisierte Form beschrieben wird.
Betrachten Sie diese (offensichtlich nicht normale) Tabelle:
%Vor%State ist eine Determinante für StateName und StateTax, aber es ist kein Kandidatenschlüssel für die Zeile. Richtige Normalisierung würde daher StateName und StateTax aus der US_Address-Tabelle und in eine States-Tabelle verschieben.
Weitere Informationen finden Sie hier .
Hier habe ich Folgendes gefunden:
Definition: Eine Determinante in einer Datenbanktabelle ist ein beliebiges Attribut, mit dem Sie die anderen zugewiesenen Werte bestimmen können Attribut (e) in derselben Zeile.
Beispiele: Betrachten Sie eine Tabelle mit den Attributen Mitarbeiter_ID, Vorname, Nachname und Geburtsdatum. In diesem Fall das Feld employee_id bestimmt die verbleibenden drei Felder. Die Namensfelder tun dies Ermitteln Sie die employee_id nicht, da die Firma mehrere haben kann Mitarbeiter mit demselben Vor- und / oder Nachnamen. In ähnlicher Weise die DOB Feld bestimmt nicht die Mitarbeiter_ID oder die Namensfelder, weil Mehr als ein Mitarbeiter kann denselben Geburtstag haben.
Ist die Definition nicht auch für Kandidatenschlüssel gültig?
Nehmen Sie ein Beispiel aus hier , um eine Tabelle mit folgenden Spalten zu erhalten:
Kundennummer, Name, Adresse, Kredit, Verkaufsnummer, Name des Verkaufsrepräsentanten
und sagen wir, dass %code% das %code% eindeutig bestimmen kann. Daher ist %code% eine Determinante für %code% , aber kein Kandidat für diese Tabelle.
TL; DR Nein, " Determinante " und " Kandidatenschlüssel " sind nicht dasselbe Konzept. Eine Determinante ist einer FD . Ein CK ist einer Tabelle . Wir können vernünftigerweise schlampig sagen, dass ein CK eine Determinante (einer FD) seiner Tabelle ist, da sie jede Spalte & amp; Spalte darin gesetzt.
Alle folgenden Begriffe / Konzepte werden parallel für die Tabellen -Werte und Variablen definiert. Eine Tabellenvariable hat eine Instanz einer FD ( funktionale Abhängigkeit), Determinante, Superkey, CK (Kandidatenschlüssel) oder PK (Primärschlüssel) (im Variablen Sinne), wenn jeder Tabellenwert, der dafür in dem gegebenen Geschäft / Anwendung entstehen kann, diese Instanz (im Tabellensinn) hat.
Für Sätze von Spalten X und Y können wir schreiben X - & gt; Y . Wir sagen, dass X die Determinante / Bestimmungsmenge ist und Y die bestimmte Menge der funktionalen Abhängigkeit ist ( FD ) X - & gt; Y.
Wir sagen X funktional bestimmt Y und Y ist funktional bestimmt durch X. Wir sagen X ist die Determinante von X - & gt; Y. In {C} - & gt; Y wir sagen, dass C funktional bestimmt Y. In X - & gt; {C} wir sagen X bestimmt funktionell C. Wenn X eine Obermenge von Y ist, sagen wir X - & gt; Y ist trivial .
Wir sagen X - & gt; Y gilt in Tabelle T, wenn jeder Subrow-Wert für X nur mit dem einen bestimmten Subrow-Wert für Y erscheint. Oder wir sagen X - & gt; Y ist ein FD von / in T. Wenn X eine Determinante von einigen FD in Tabelle T ist, sagen wir, dass X eine Determinante von / in T ist. Jedes triviale FD einer Tabelle enthält darin.
Ein Superkey einer Tabelle T ist eine Menge von Spalten, die jede Spalte funktional bestimmt. Ein Kandidatschlüssel ( CK ) ist ein Superschlüssel, der keinen kleineren Superschlüssel enthält. Wir können einen CK als Primärschlüssel (< em> PK ) und rufen dann die anderen CKs alternativen Schlüssel ( AKs ) auf. Eine Spalte ist prim , wenn sie sich in einem CK befindet.
Beachten Sie, dass eine Determinante einer FD oder schlampig (eine FD, die eine Tabelle enthält) sein kann. Jeder CK ist eine Determinante seiner Tabelle. (Aber dann ist in einer Tabelle jeder Satz von Spalten eine Determinante: von sich selbst trivial. Und ähnlich jeder Spalte.)
(Diese Definitionen hängen nicht von der Normalisierung ab. FDs und CKs einer Tabelle werden verwendet, um sie zu normalisieren. Eine Tabelle ist in BCNF, wenn jede Determinante einer nicht-trivialen FD darin enthalten ist ein Superkey .)
SQL-Tabellen sind keine Relationen und SQL-Operatoren sind nicht ihre relationalen / mathematischen Gegenstücke. Unter anderem hat SQL doppelte Zeilen, Nullen & amp; eine Art 3-wertige Logik. Aber obwohl Sie Begriffe ausleihen und ihnen SQL-Bedeutungen geben können, können Sie diese Bedeutungen nicht einfach durch andere RM-Definitionen oder -Sätze ersetzen und etwas Vernünftiges erhalten oder wahr . Also müssen wir ein SQL-Design in ein relationales Design konvertieren, relationale Konzepte anwenden und dann zurück in SQL konvertieren . Es gibt spezielle Fälle, in denen wir bestimmte Dinge direkt in SQL machen können, weil wir wissen, was passieren würde, wenn wir konvertieren, anwenden & amp; zurück konvertieren.