Modellierung von Ja/Nein-Attributen in der Datenbank

Question

Ich habe ein ziemlich häufiges Szenario, in dem ein Benutzer aus einer Reihe von Attributen auswählen kann. Die Attribute in der Benutzeroberfläche werden durch Kontrollkästchen dargestellt.

Zum Beispiel:

Komponenten: Festplatte (y/n), die CPU (y/n), Monitor (y/n), Tastatur (y/n), etc ....

in der Vergangenheit habe ich in der Regel dieses Szenario wie folgt modelliere:

"PCs" 1:M "PC Components" M:1 "Components" 

Eine weitere Option ist die „Attribute“ als y/n Felder in dem „PC“ Tisch zu machen.

z.B.

In der Vergangenheit basiert mein Grundprinzip dafür, ob man mit einem oder dem anderen gehen kann, darauf, ob der Benutzer neue Attribute eingeben kann. Wenn die Antwort ja ist, dann gehe ich mit der ersten Option, wenn die Antwort nein ist, dann gehe ich normalerweise mit y/n-Attributen.

Aber jetzt habe ich ein Szenario, wo es etwa 20 Attribute in mehrere Kategorien unterteilt sind. Nach dem Erstellen der ERD sieht es einfach "falsch" aus und die Tabelle hat eine absurde Anzahl von Spalten.

Meine Frage ist, gibt es eine Standard/korrekte Möglichkeit, dies zu modellieren? Wenn ja, hat es einen Namen?

Answer 1

Man ist versucht, ein "kompakteres" Datenmodell (etwas anderes als eine Spalte pro Attribut) zu entwerfen, weil die Attribute kompatible Datentypen haben (sie sind alle y/n).

Wenn die Attribute jeweils unterschiedliche Datentypen hatten, z. B. wenn sie auf eine Gruppe von Werten mit unterschiedlichen Nachschlagetabellen beschränkt waren, wäre es ein Kinderspiel, eine Spalte pro Attribut zu verwenden.

Siehe Domain-Key Normal Form. Das Modellieren Ihrer y/n-Attribute als Zeilen bedeutet, dass es keine Möglichkeit gibt, obligatorische Attribute darzustellen (für die Sie müssen entweder Y oder N-Wert haben). Sie hätten also eine Einschränkung, dass es für N Attribute N Zeilen geben muss. Eine Einschränkung für die Mindestanzahl von Zeilen ist weder eine Domänenbeschränkung noch eine Schlüsseleinschränkung, daher schlägt der DKNF-Test fehl.

Es ist nicht notwendig, dass jede Tabelle DKNF entsprechen muss, aber wenn Sie fragen, welcher Begriff den Entwurf einer Spalte pro Attribut beschreibt, schlage ich vor, dass "Domain/Key Normal Form" passen würde.

Answer 2

Ich folge dieser einfachen Regel: Ein Stück Daten pro Spalte. Lassen Sie die Datenbank die Speicherstruktur optimieren.

In der SQL Server-Welt gehe ich daher mit dem BIT-Datentyp und ja, separate Spalten. Andere Datenbanken, ich bin sicher, haben einen entsprechenden Typ.