3. Normalform?

[brechi]

Ich habe eine Tabelle die soll Attribute zu Objekten beschreiben. z.B. hat ein Baum als Attribut die Höhe.

Das Attribut wird wie folgt gespeichert:

{AttributId}: Integer // Primärschlüssel
{ObjektID}: Integer // Veweis auf ein Objekt (z.B. Baum)
{Name}: VarChar(32) // Name des Attributs (z.B. Höhe)
{Datentyp}: Integer; // 0 = Ganzzahl, 1 = Fließkomma, 2 = Text
{Laenge}: Integer; // bei Ganzzahl = Anzahl der stellen, bei Text Anzahl der Buchstaben
{Nachkomma}: Integer; // Irrelavant bei Text/Ganzzahl, bei Fließkomma Anzahl der Nachkommstellen

1. Normalform sollte klar sein (Werte der Attribut sind atomar, Primärschlüssel vorhanden)

Schlüsselkandidaten sind: {AttributId}, {ObjektID, Name}
NichtschlüsselAttribut sind: {Datentyp, Laenge, Nachkomma}

2. Normalform da die Nichtschlüsselattribute alle von den Schlüsselkandidaten abhängen (z.B. ObjektID+Name bestimmt eindeutig den Datentyp

Gilt die 3. Normalform?
Laut wiki darf kein NA von einem anderen NA abhängen: Nachkomma hängt aber vom Datentyp ab oder nicht? (bzw. im Grunde ist es egal was drinsteht)

Vill kann mir ja jemand da weiterhelfen der sich besser auskennt Ich blick da gerade nicht durch.

[mirage228]

Also es geht bei der 3. NF um eine transitive Abhängigkeit. Ein nicht-Schlüsselattribut darf nicht über ein anderes Nicht-Schlüsselattribut ("Determinante") vom Primärschlüssel abhängig sein.
Du könntest also "Nachkomma" als eigene Relation mit Primärschlüssel "Datentyp" auslagern (ggf. Nachkomma dann "NULL" erlauben), wenn für jeden Float-Datentyp eine eindeutig zuordnenbare Anzahl an Nachkommastellen hat (ansonsten wäre es ja nicht transitiv von Datentyp abhängig).

[brechi]

Also wenn es transitiv abhängig wäre müsste ich eine neue Relation anlegen. Meine Frage konkret: ist das obige in 3. NF?

Entscheidend ist jetzt:
Hängt also Nachkomma vom Datentyp ab?

Wenn Datentyp = String oder Ganzzahl dann hängt es NUR davon ab.
Wenn Datentyp = float dann hängt es zusätzlich vom Attribut ab (Höhe = 2 Nachkommastellen, Durchmesser = 3).

Demnach würde ich sagen Nachkomma hängt von dem Datentyp UND dem Attribut ab -> Die Tabelle ist so in der 3. NF.

Kannst du das so bestätigen?

Dein Tabellenaufbau:
Wenn ich jetzt Nachkomma in eine extra Tabelle auslagere dann muss ich in der Attributtabelle darauf verweisen (jedenfalls wenn das Attribut eine Fließkommzahl ist).
Problem ist dann -> in der Tabelle Nachkomma muss kein Eintrag vorhanden sein, bzw. in der Attributtabelle kann der NULL wert eingetragen sein (daher Interpretation d.h. NULL-Wert -> 0)

Würde ich ungerne machen und auch vermeiden wenn meine Tabelle in 3.NF wäre (wo ich mir z.Z. unsicher bin)

[mirage228]

Zitat von brechi:

Entscheidend ist jetzt:
Hängt also Nachkomma vom Datentyp ab?

Wenn Datentyp = String oder Ganzzahl dann hängt es NUR davon ab.
Wenn Datentyp = float dann hängt es zusätzlich vom Attribut ab (Höhe = 2 Nachkommastellen, Durchmesser = 3).

Demnach würde ich sagen Nachkomma hängt von dem Datentyp UND dem Attribut ab -> Die Tabelle ist so in der 3. NF.

Kannst du das so bestätigen?

Ah okay. So ist die Sache schon klarer. Nachkomma ist also bei String/Integer egal (also "NULL" z.B.), und wird sonst durch eine Kombination von Attribut und Datentyp eindeutig definiert.
Dann stimmt alles und Du hast die 3. NF
Und da hier auch mindestens ein Nicht-Schlüsselattribut mit drin hast und in 3. NF bist, bist Du automatisch in 4. und 5. NF

Viele Grüße

[alzaimar]

Ich hoffe, die Frage nach der 3NF ist nur theoretischer Natur. Denn es *nicht* das Ziel einer guten DB, die 3NF auf Deibel komm raus zu designen.

[quendolineDD]

Mir hilft es bei DB-Sachen immer, das Problem grafisch in einem ERM (Entity-Relationship-Model) darzustellen. Dazu ist eine Schreibtafel am Besten geeignet. Nimm dir ein Blatt Papier und überführ das ganze mal in ein Diagramm. Dann wirst du auch sehen, bei welchen Relationen du eine neue Tabelle einfügen musst, bei 1:n-Relationen wo der entsprechende Foreign Key hingehen muss etc.

Und btw. finde ich persönlich die 4. und 5. NF eher theoretischer Natur.