So modellieren Sie eine optionale 1: n-Beziehung in 1NF

Question

Wie können Sie eine Beziehung null, eine oder viele Typen modellieren, ohne die erste Normalform zu unterbrechen? Das heißt, keine NULL-Werte speichern.

Getrennte Beziehungstabelle? Ist es "wert", eine Tabelle hinzuzufügen, oder ist dies eine Über-Normalisierung?

Hier ist ein Beispiel, das zu meiner realen Welt Fall entspricht:

Sagen wir ein College haben, mit einigen freien Kursen und einigen freien Schlafsäle. Einige der Kurse und Schlafsäle sind jedoch mit einer Gebühr verbunden. Und viele der Kurse und Zimmer haben die gleiche Gebühr (Betrag), obwohl sie verschiedene Kurse/Zimmer sind.

wir So haben:

tblCourse 
Id 
Name 

tblDormRoom 
Id 
Address 

tblFee 
Id 
Amount 

Um dieses mein nehmen zu modellieren war zwei Tabellen hinzufügen, um die optional eine Eins-zu-viele-Beziehung zu halten.

tblCourseToFee 
CourseId 
FeeId 

tblDormRoomToFee 
DormRoomId 
FeeId 

So kann ich keine Nullwert zu speichern vermeiden kann, und auch doppelte Speicherung der Fee vermeiden, die zwischen Dormroom und Kurs geteilt werden.

Und die schnelle n dreckige Version betrachtet, die nicht streng an 1NF anhaftet:

tblFee 
Id 
CourseId (nullable) 
DormRoomId (nullable) 
Amount 

Dies nur eine Tabelle anstelle von drei verwendet, aber NULL-Werten führt ..

Answer 1

Dies ist ein Interessante Frage - ein gutes Beispiel für eine Eins-zu-Viele-Beziehung in der ersten Normalform findet sich on Wikipedia (Ich möchte hier einige Inhalte posten, aber es ist nicht Stackoverflow-Format-freundlich).

Die Grundidee ist, dass Sie zwei Tabellen und die Kennung der Haupttabelle definieren wird als Kennung der zugehörigen Tabelle mit dem Verständnis verwendet, dass die dazugehörige Tabelle doppelte Kennungen enthält.

Arbeiten Sie aus Neugierde an einem Datamining-Projekt? Ich wäre daran interessiert, mehr darüber zu erfahren, wie dies angewendet wird.

Answer 2

sehen Andrew Link zu Wikipedia, und beachten Sie, dass die ‚keine NULL-Werte in 1NF‘ Mahnung von Datum controverisal ist bestenfalls - nicht häufig unpraktisch zu erwähnen. Wenn Nullen gut genug für Codd sind, sind sie gut genug für mich ;-) das sagte, der normale (Wortspiel beabsichtigt) Weg, eine Null, eine oder viele Beziehung zu modellieren ist mit einer Kind-Tabelle, z.

create table Parent (
    Id int not null identity(1), 
    Somefield nvarchar(256) not null, 
    ... 
) 

create table Child (
    Id int not null identity(1), 
    ParentId int not null, --foreign key to Parent table's Id 
    AnotherField nvarchar(128) not null 
    ... 
) 

Answer 3

Schauen Sie sich dieses Problem semantisch an. Ist es eine ternäre Beziehung oder zwei binäre Beziehungen? In einfachen Worten: Ist die Gebühr gesammelt

• für einen Kurs
• für ein Wohnheim
• für ein Wohnheim verwendet in bleiben, während einen Kurs
  
  Für die ersten beiden Fälle besuchen Sie müssen die zwei untergeordneten Tabellen haben. Wenn Fall drei wahr ist, müssen Sie nur eine Schnittmenge zwischen Kurs, Gebühr und Wohnheim haben. Oft ist das Vorhandensein oder Fehlen von NULLs sehr eng mit subtilen Designproblemen verbunden.