question de la normalisation de la simple base de données

Question

J'ai une petite question au sujet d'une base de données que je suis la conception et en vous assurant qu'il est normalisé ...

J'ai une table à la clientèle, avec une clé primaire de customerId. Il a une colonne StatusCode qui a un code qui reflète l'état du compte des clients à savoir. 1 = Ouvert, 2 = Fermé, 3 = Suspendu etc ...

Maintenant je voudrais avoir un autre champ dans la table client qui indique si le compte est autorisé à être suspendu ou non ... certains clients seront automatiquement suspendu si elles briserai conditions commerciales ... d'autres pas ... donc les champs de table pertinents seront comme si:

clients (CustomerId (PK): StatusCode: IsSuspensionAllowed)

maintenant, les deux champs dépendent sur la clé primaire car vous ne pouvez pas déterminer l'état ou si des suspensions sont autorisées sur un client particulier à moins que vous connaissiez le client spécifique, sauf bien sûr lorsque le champ IsSuspensionAllowed est défini sur YES, le le client ne devrait jamais avoir un StatusCode de 3 (Suspendu).

Il semble que d'après la conception de tableau ci-dessus, il est possible que cela se produise à moins qu'une contrainte de vérification soit ajoutée à ma table. Je ne vois pas comment une autre table pourrait être ajoutée à la conception relationnelle pour l'appliquer, mais seulement dans le cas où IsSuspensionAllowed est défini sur YES et que StatusCode est défini sur 3 lorsque les deux dépendent l'un de l'autre. Donc, après ma longue explication, ma question est la suivante: est-ce un problème de normalisation et je ne vois pas un design relationnel qui fera respecter cela ... ou est-ce juste une règle d'affaires qui devrait être appliquée avec un vérifier la contrainte et la table est en fait encore normalisée.

Cheers,

Steve

Answer 1

Oui, il est possible. Vous pouvez le faire avec une contrainte de vérification et une déclaration de cas:

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) 
     , .... 
     ) 

Vous n'avez pas mentionné le type de données de la PK donc je simplement inséré un espace réservé. Si vous utilisez SQL Server, vous pouvez utiliser une colonne de bits au lieu du int et vérifier la contrainte que j'ai mentionnée ci-dessus (bit ne fait pas partie de la spécification ANSI).

Ceci est un bon exemple de cas où les clés de substitution pour des choses comme les codes d'état ne fonctionnent pas toujours bien. Il vaudrait mieux que les valeurs de chaîne représentent les codes d'état, auquel cas l'instruction Case se lirait When StatusCode = 'Suspended' And IsSuspendedAllowed = 0.... Du point de vue de la normalisation, je ne vois rien de mal. La suspension autorisée est un attribut spécifique à un client et non un autre attribut. Ce que vous dites avec la contrainte de vérification, c'est que certains états de valeurs d'attributs ne peuvent pas exister ce qui est bien. Btw, n'aurait pas plus de sens de dire que le statut de "Suspendu" n'est pas autorisé lorsque IsSuspensionAllowed = 0? En utilisant vos données, l'état non autorisé ne devrait-il pas être StatusCode = 3 and IsSuspensionAllowed = 0?