2017-01-03 2 views
0

Stellen Sie sich die folgende Tabelle vor. In meinem Fall bin ich ganz sicher, dass nameunique und not null [unique + not null = Primärschlüssel] sein muss. Daher ist name ein Primärschlüssel. Aus einigen Gründen (wahrscheinlich aus Gewohnheit) habe ich natürlich einen Primärschlüssel id Spalte des Typs int erstellt.SQL-Datenbank: Tabelle mit 2 Spalten (ID-Name) und 2 Primärschlüssel Dritte Normalform Boyce-Codd Normalform

Andere Annahmen: Ich muss unbedingt name in meiner Tabelle zu halten, und ich bin absolut sicher, dass name (des Typs varchar) wird niemals 20 Zeichen überschreiten.

Nun ist meine erste Frage [wahrscheinlich enge Frage mit Ja oder Nein erwartet]: Respektiere ich BCNF Boyce-Codd Normalform, wenn ich eine solche Tabelle erstellen?

Zweite optionale Frage [wahrscheinlich offene Frage]: ist es gute Praxis, Spalte id in diesem Fall zu erstellen?

CREATE TABLE Y (
    id int, 
    name varchar(20), 
    PRIMARY KEY(id, name) 
    ); 
+0

'name' und' id' sind beide * Kandidatenschlüssel *. Nur einer von ihnen kann als Primärschlüssel gewählt werden. Und um BCNF zu verletzen, benötigen Sie mindestens drei Spalten (vorausgesetzt, es hat eine PK). – joop

+1

* eindeutig + nicht null = Kandidat Schlüssel * –

+0

@ MikeSherrill'CatRecall 'Ja, Sie haben Recht. Es ist mein Fehler. Ich hätte sagen sollen: unique + not null = Kandidatentaste – S12000

Antwort

1

Wenn jede Spalte eindeutig ist, werden Sie wahrscheinlich wollen entweder

CREATE TABLE Y (
    id int primary key, 
    name varchar(20) not null unique, 
); 

oder

CREATE TABLE Y (
    id int not null unique, 
    name varchar(20) not null unique 
); 

Die hier FDs sind id-> Name und Namen-> id.

Informell erfüllen Sie BCNF, wenn jeder Pfeil in Ihren FDs ein Pfeil aus einem Kandidatenschlüssel ist. Dies erfüllt BCNF.

Es ist keine gute Sache, eine Ersatz-ID-Spalte aus Gewohnheit zu erstellen. Denken Sie zuerst nach und machen Sie sich bewusst, welche Kompromisse und Nebenwirkungen es gibt.

1

Obwohl die Beziehungen, die nur zwei Attribute sind immer in BCNF, ist Ihre Frage ein bisschen schwierig zu beantworten, da der Text nicht mit dem Tabellenentwurf entspricht.

Wenn ich nehme Ihren Tabellenentwurf als Basis für die erste Frage zu beantworten: Sie eine Tabelle erstellen Y mit zwei Attributen id und name, die die einzigen Attribute Y sind und bilden zusammen den einzigen Schlüssel, dann ist es immer in BCNF.

Wenn ich Ihre Textbeschreibung, wo Sie sagen, dass name einzigartig ist (im Sinne des relationalen Modells ein Schlüssel), dann hat man die Bedeutung des Surrogat-Attribut denken id (oder Schlüssel?):

a. Wenn id ebenfalls ein Schlüssel ist, dann sind FDs id->name; name->id, wobei id ein Schlüssel ist und name ein Schlüssel ist, so dass jedes FD einen Schlüssel auf seiner linken Seite hat. BCNF ist somit erfüllt.

b. Wenn id kein Schlüssel für sich ist, aber name->id gilt, dann ist es immer noch in BCNF (weil die einzige FD einen Schlüssel auf seiner LHS hat). Obwohl ich würde dann nicht verstehen, warum Sie ein zusätzliches Attribut haben id um alle.

Die Hauptsache ist jedoch, dass Ihr Datenbankschema haftet nicht einfach auf die im Text genannten Regeln: Der einzige Schlüssel mit (id, name) ist einfach falsch ausgedrückt, weil Sie id als Primärschlüssel und name als eindeutige Einschränkung haben sollten (dh ein alternativer Schlüssel) oder umgekehrt. Dann wäre es eindeutig in BCNF und würde der oben erwähnten Option (a) entsprechen.

Es ist also keine Frage von BCNF oder nicht, sondern eine Frage von "Schema korrekt ausgedrückt oder nicht".

Verwandte Themen