Einfache Datenbank Normalisierung Frage

Question

Ich habe eine kurze Frage in Bezug auf eine Datenbank, die ich bin die Gestaltung und sicherstellen, dass es normiert ...

ich einen Kunden Tisch haben, mit einem Primärschlüssel von customerId. Es verfügt über eine Statuscode Spalte, die einen Code aufweist, der die Kunden Status dh Konto widerspiegelt. 1 = Open, 2 = geschlossen, 3 = Suspended etc ...

Nun würde Ich mag ein anderes Feld in der Kundentabelle haben, dass Flags, ob das Konto erlaubt ist, ausgesetzt wird oder nicht ... bestimmte Kunden automatisch ausgesetzt werden, wenn sie dort Handelsbedingungen brechen ... andere nicht ... so dass die relevanten Tabellenfelder werden als so sein:

Kunden (CustomerId (PK): Statuscode: IsSuspensionAllowed)

Jetzt sind beiden Felder abhängig von dem Primärschlüssel, wie Sie den Status nicht bestimmen können oder ob Suspensionen auf einem bestimmten Kunden erlaubt sind, wenn Sie die spezifischen Kunden kennen, außer natürlich, wenn das IsSuspensionAllowed Feld auf YES gesetzt ist, die die Kunden sollte nie einen Statuscode von 3 (Suspended) hat.

Es scheint aus dem obigen Tabelle Design es möglich ist, dies zu erreichen, es sei denn eine Überprüfung contraint meine Tabelle hinzugefügt wird. Ich kann nicht sehen, wie eine andere Tabelle der relationalen Design hinzugefügt werden, könnte dies allerdings zu erzwingen, wie es nur in dem Fall, in dem IsSuspensionAllowed auf YES gesetzt ist und Statuscode auf 3 gesetzt ist, wenn die beiden eine Abhängigkeit voneinander haben.

Also nach meiner langen umständlichen Erklärung meiner Frage ist: Ist das eine Normalisierung Problem und ich sehe nicht ein relationales Design, das diese erzwingen wird ... oder ist es eigentlich nur eine Geschäftsregel, die mit einem Scheck erzwungen werden sollen, contraint und die Tabelle ist in der Tat immer noch normalisiert.

Cheers,

Steve

Answer 1

Ja, es ist möglich. Sie können es mit einer Check-Einschränkung tun und eine Case-Anweisung:

Create Table Customer   (
        CustomerId <datatype> not null Primary Key
        , StatusCode int not null
        , IsSuspensionAllowed int not null Default( 1 )
        , Constraint CK_Customer_IsSuspensionAllowed 
                    Check ( IsSuspensionAllowed In(0,1) )
        , Constraint CK_Customer_StatusCodeRange 
                    Check ( StatusCode Between 0 And ?? )
        , Constraint CK_Customer_StausCodeValid 
                    Check ( Case
                When StatusCode = 3 And IsSuspensionAllowed = 1 Then 0
                                                                Else 1
                                                                End = 1 )
        , ....
        )

Sie haben nicht den Datentyp des PK erwähnen so dass ich einfach einen Platzhalter eingefügt. Wenn Sie SQL Server verwenden, können Sie ein wenig Säule anstelle des int und Check-Einschränkung verwenden kann ich oben erwähnt (bit ist nicht Teil der ANSI-Spezifikation).

Dies ist ein gutes Beispiel dafür, wo Ersatzschlüssel für Dinge wie Status-Codes auch nicht immer funktionieren. Es wäre besser, String-Werte die Statuscodes repräsentieren zu haben, in welchem ??Fall die Case-Anweisung When StatusCode = 'Suspended' And IsSuspendedAllowed = 0... lesen würde.

Von einer Normalisierung Standpunkt, ich habe nichts falsch sehen. Ob Suspension wird ein Attribut spezifisch für einen Kunden und nicht ein anderes Attribut. Was Sie mit der Check-Einschränkung sagen, dass bestimmte Zustände der Attributwerte nicht existieren können, die in Ordnung ist.

BTW, würde nicht mehr Sinn machen, zu sagen, dass der Status „Ausgesetzt“ ist nicht erlaubt, wenn IsSuspensionAllowed = 0? Verwenden Sie Ihre Daten sollten nicht den Zustand, der nicht be StatusCode = 3 and IsSuspensionAllowed = 0 erlaubt ist?