Si une table avec une clé de substitution a une colonne connue pour avoir des valeurs non nulles uniques (par exemple SSN), est-ce qu'elle viole 3NF?

Si je comprends bien, la troisième forme normale (3NF) signifie essentiellement qu'il devrait y avoir exactement une clé.

Si une table avec, par exemple, une idcolonne d' incrémentation automatique a également une colonne connue pour être unique et non nulle, par exemple le numéro de sécurité sociale, cette autre colonne pourrait être utilisée comme clé.

Ignorant les problèmes pratiques / commerciaux (par exemple, risque pour la sécurité / la confidentialité lors du passage du SSN en tant que clé / FK), du point de vue de la conception d'un schéma, une telle table ne serait-elle pas en 3NF car il y a effectivement 2 clés?

La réponse varierait-elle selon qu'il y avait une clé unique dans l'autre colonne? Si oui, pourquoi?

Une relation R est sous une troisième forme normale si chaque attribut non premier de R dépend de manière non transitoire de chaque clé candidate de R

EFCodd, 1971, poursuite de la normalisation du modèle relationnel de la base de données

Il est implicite dans la définition d'une relation qu'une relation doit avoir au moins une clé. Rien dans 3NF ni dans aucune autre forme normale n'exige qu'une relation ne comporte qu'une seule clé.

Malheureusement, les livres sur la conception et la normalisation des bases de données contiennent de nombreux exemples de relations avec une seule clé et un nombre plutôt limité d'exemples avec plusieurs clés. Cela me semble étrange étant donné que plusieurs clés semblent être une pratique très courante de nos jours. Le manque d'exemples pratiques dans la littérature non académique semble être une cause de confusion sur le rôle des clés dans la conception des bases de données. Une autre cause de confusion est le mnémonique populaire "rien que la clé". Cette phrase est généralement attribuée à Bill Kent, mais ce n'est pas une définition précise de 3NF.

Étant donné que la question est basée sur une interprétation d'une règle, nous devons d'abord examiner ces informations liées, qui sont (soulignement le mien):

2. tous les attributs d'une table sont déterminés uniquement par les clés candidates de cette table et non par des attributs non premiers.

Je pense que la confusion est le résultat d'une mauvaise interprétation du terme "clés candidates". Il peut y avoir plusieurs clés candidates dans une table. C'est pourquoi nous avons des termes modificateurs à spécifier davantage dans ce groupe: Primaire et Alternatif. Si les tables pouvaient avoir une et une seule clé, le terme clé "primaire" serait trompeur et aurait plutôt dû être appelé autre chose (peut-être "parent" ou "origine" ou "identification", etc.). Mais "primaire" implique qu'il peut y avoir des clés "secondaires", et celles-ci sont appelées clés "alternatives".

Les clés alternatives sont indiquées dans les modèles physiques via une contrainte unique ou un index unique. Il convient également de noter que les deux types de clés candidates (primaires et alternatives) peuvent être référencés par des clés étrangères (même si généralement une personne ne devrait / ne devrait pas faire une telle chose sans une très bonne raison!).

La réponse varierait-elle selon qu'il y avait une clé unique dans l'autre colonne? Si oui, pourquoi?

Non, car c'est une question de modélisation physique vs logique. Vous pouvez avoir une table qui a un IDENTITYchamp mais pas encore de clé primaire définie. La table et ses données peuvent facilement être en 3NF, même si le modèle physique ne l'impose pas. Cette distinction est similaire à la définition ou non des clés étrangères. Vous pouvez sûrement JOINDRE des tables et n'avoir aucun enregistrement orphelin, que des PK / FK aient été définis ou non. Et les données peuvent être correctes à 100% sans ces constructions. Mais avoir les PK et FK définis est la différence entre l'intégrité référentielle (logique) et l' intégrité référentielle déclarative (physique). Le fait d'avoir les contraintes dans le modèle physique permet simplement d'appliquer les règles du modèle logique.

En ce qui concerne le SSN (" numéro de sécurité sociale " pour ceux qui ne connaissent pas cet acronyme), et qu'il s'agit d'une clé alternative et ayant un index / contrainte unique:

Je recommanderais de ne pas considérer un SSN comme une clé alternative et d'y mettre une contrainte ou un index unique, même s'il est courant de le faire (le SSN est souvent considéré comme une clé "naturelle" - qui existe dans le monde réel) . Il y a deux principales raisons:

1. Précision: La plupart du temps, ces valeurs sont saisies dans un système par une personne remplissant un formulaire, que ce soit sur papier ou en ligne. Les gens font des erreurs tout en faisant la saisie de données tout le temps, surtout si la source était un formulaire papier qui est entré par quelqu'un qui lit une écriture manuscrite bâclée (comme la mienne, qui est à peine lisible).

   Même si les données proviennent d'un autre système, pouvez-vous être sûr que le système source a validé les informations? Pouvez-vous être sûr qu'il n'y avait pas de bogue dans leur exportation de données? Et s'il y a un bug dans votre importation de données?

2. Unicité: même si la principale administration de la sécurité sociale n'a jamais émis d'ID en double, cela ne signifie pas qu'il n'y a pas eu de duplication. En dehors des problèmes de vol d'identité, je me souviens avoir entendu il y a quelques années quelqu'un qui travaillait comme DBA pour le département du Revenu des États (je crois) et qui devait gérer les prestations de sécurité sociale, comment ils avaient des "problèmes" avec ce qui était un ancienne pratique consistant à réaffecter le SSN d'une personne décédée au conjoint survivant (généralement la veuve) afin qu'il soit plus facile pour le conjoint survivant de continuer à percevoir les prestations. Je suis sûr que cette pratique a pris fin il y a quelque temps, mais les données "en double" étaient toujours dans le système.

Si je comprends bien, la troisième forme normale (3NF) signifie essentiellement qu'il devrait y avoir exactement une clé.

Les n ° 2NF, 3NF et Boyce Codd Normal Form (BCNF) traitent des dépendances fonctionnelles . Une table en 2NF signifie qu'il n'y a pas de dépendances de clés partielles où une colonne non clé dépend d'un certain sous-ensemble approprié d'une clé multi-colonnes. Des tables telles que celle de notre exemple sont déjà en 2NF car chaque clé candidate est une seule colonne. Une table en 3FN signifie que chaque colonne non-clé est également ne dépend pas fonctionnellement sur une autre colonne non-clé, et créant ainsi une dépendance transitive. Peu importe qu'il y ait une ou cent clés candidates. En fait, c'est BCNF, et non 3NF, qui est la forme normale "finale" en ce qui concerne les dépendances fonctionnelles. En effet, une table peut être en 3NF mais pas en BCNF car il peut y avoir plusieurs clés candidates qui se chevauchent. Ainsi, lorsque nous utilisons le terme 3NF pour signifier «entièrement normalisé» en ce qui concerne les dépendances fonctionnelles, ce que nous voulons vraiment dire, c'est BCNF.

Si une table avec, par exemple, une colonne d'identification à incrémentation automatique a également une colonne connue pour être unique et non nulle, par exemple le numéro de sécurité sociale, cette autre colonne pourrait être utilisée comme clé.

Non seulement cela pourrait l'être, mais cela doit l' être si nous voulons nous assurer que les données stockées dans la base de données restent cohérentes avec les règles que nous avons identifiées dans le monde réel!

Ignorant les problèmes pratiques / commerciaux (par exemple, risque pour la sécurité / la confidentialité lors du passage du SSN en tant que clé / FK), du point de vue de la conception d'un schéma, une telle table ne serait-elle pas en 3NF car il y a effectivement 2 clés?

Comme expliqué ci-dessus, le fait que la table soit ou non en 3NF (ou plus important encore en BCNF) est orthogonal au nombre de clés candidates qu'elle contient.

La réponse varierait-elle selon qu'il y avait une clé unique dans l'autre colonne? Si oui, pourquoi?

Non, tout simplement parce que déterminer si la table est ou non dans 3NF n'a rien à voir avec le nombre de clés candidates qu'elle possède. Au lieu de cela, il a tout à voir avec le fait de s'assurer que toutes les colonnes non clés dépendent entièrement de ces clés candidates.

Mais cela ne mettre un point intéressant. Notez qu'une clé unique lorsqu'elle est définie comme une contrainte dans un SGBD n'est pas la même chose qu'un identificateur unique défini comme une règle métier dans un modèle commercial conceptuel. Peut-être que dans notre monde, nous connaissons toujours le SSN de la personne et qu'il sert donc de clé candidate pour une personne, et peut-être que nous introduisons également une clé de substitution dans le schéma logique que nous appelons l' ID de personne . Notre modèle commercial comprend la règle stipulant que le SSN est un identifiant unique pour une personne dans notre monde. Cela implique une dépendance fonctionnellede tous les attributs descriptifs de cet attribut d'identité. Cette règle ne change pas simplement parce que nous avons oublié ou choisi de ne pas informer le SGBD. C'est précisément pourquoi il est essentiel que la contrainte soit déclarée - afin que le SGBD puisse garantir que les données stockées sont conformes aux règles du modèle d'entreprise! Si nous n'avons pas créé cette contrainte unique sur SSN, nous pouvons maintenant créer par inadvertance plusieurs lignes pour la même personne avec le même SSN; chaque ligne ayant un identifiant de personne différent!

Une excellente introduction à ces sujets est la série de bases de données pratiques de Fabian Pascal et la conception de bases de données et la théorie relationnelle de Chris Date , dont découle cette réponse. Bien que chaque article de Fabian soit une lecture incontournable, l'article # 1 (qui définit clairement la différence entre les niveaux conceptuel, logique et physique) et l'article # 4 (qui définit clairement les différents types de clés) abordent spécifiquement cette question. De même, le livre entier de Chris est une lecture incontournable tandis que la partie II est la section consacrée à la normalisation en ce qui concerne la dépendance fonctionnelle.