Troisième forme normale - Third normal form

La troisième forme normale ( 3NF ) est une approche de conception de schéma de base de données pour les bases de données relationnelles qui utilise des principes de normalisation pour réduire la duplication des données, éviter les anomalies de données , assurer l' intégrité référentielle et simplifier la gestion des données. Il a été défini en 1971 par Edgar F. Codd , un informaticien anglais qui a inventé le modèle relationnel pour la gestion des bases de données .

Une relation de base de données (par exemple une table de base de données ) est dite conforme aux normes de la troisième forme normale si tous les attributs (par exemple les colonnes de la base de données ) dépendent fonctionnellement de la seule clé primaire . Codd a défini cela comme une relation sous une seconde forme normale où tous les attributs non premiers dépendent uniquement des clés candidates et n'ont pas de dépendance transitive sur une autre clé.

Un exemple hypothétique de non-respect de la troisième forme normale serait une base de données hospitalière comportant une table de patients comprenant une colonne pour le numéro de téléphone de leur médecin. Le numéro de téléphone dépend du médecin plutôt que du patient, il serait donc mieux stocké dans une table de médecins. Le résultat négatif d'une telle conception est que le numéro d'un médecin sera dupliqué dans la base de données s'il a plusieurs patients, augmentant ainsi à la fois le risque d'erreur de saisie et le coût et le risque de mise à jour de ce numéro en cas de changement (par rapport à un troisième modèle de données conforme au formulaire qui ne stocke le numéro d'un médecin qu'une seule fois sur une table de médecin).

Codd s'est rendu compte plus tard que 3NF n'éliminait pas toutes les anomalies de données indésirables et a développé une version plus forte pour résoudre ce problème en 1974, connue sous le nom de forme normale Boyce-Codd .

Définition de la troisième forme normale

La troisième forme normale (3NF) est une forme normale utilisée dans la normalisation des bases de données . 3NF a été initialement défini par E. F. Codd en 1971.

La définition de Codd stipule qu'une table est en 3NF si et seulement si les deux conditions suivantes sont remplies :

• La relation R (table) est en deuxième forme normale (2NF).
• Chaque attribut non premier de R est dépendant de manière non transitive de chaque clé de R.

Un attribut non premier de R est un attribut qui n'appartient à aucune clé candidate de R. Une dépendance transitive est une dépendance fonctionnelle dans laquelle X → Z ( X détermine Z ) indirectement, en vertu de X → Y et Y → Z (où ce n'est pas le cas que Y → X ).

Une définition 3NF équivalente à celle de Codd, mais exprimée différemment, a été donnée par Carlo Zaniolo en 1982. Cette définition stipule qu'une table est en 3NF si et seulement si pour chacune de ses dépendances fonctionnelles X → A , au moins l'une des suivantes conditions tient :

• X contient A (c'est-à-dire que A est un sous-ensemble de X , ce qui signifie que X → A est une dépendance fonctionnelle triviale),
• X est une super - clé ,
• chaque élément de A  \  X , la différence d'ensemble entre A et X, est un attribut premier (c'est-à-dire que chaque attribut de A  \  X est contenu dans une clé candidate ).

La définition de Zaniolo donne un sens clair de la différence entre 3NF et la forme normale Boyce-Codd plus stricte (BCNF). BCNF élimine simplement la troisième alternative ("Chaque élément de A  \  X , la différence d'ensemble entre A et X , est un attribut premier.").

"Rien que la clé"

Une approximation de la définition de Codd de 3NF, parallèle à l' engagement traditionnel de fournir des preuves vraies devant un tribunal, a été donnée par Bill Kent : « [chaque] [attribut] non-clé doit fournir un fait sur la clé, la clé entière, et rien que la clé". Une variante courante complète cette définition avec le serment "Alors aide-moi Codd ".

Exiger l'existence de "la clé" assure que la table est en 1NF ; exiger que les attributs non-clés dépendent de "la clé entière" assure 2NF ; exiger en outre que les attributs non clés dépendent de « rien d'autre que la clé » garantit 3NF. Bien que cette phrase soit un mnémonique utile, le fait qu'elle ne mentionne qu'une seule clé signifie qu'elle définit certaines conditions nécessaires mais pas suffisantes pour satisfaire les 2e et 3e formes normales. 2NF et 3NF sont concernés de la même manière par toutes les clés candidates d'une table et pas seulement par une seule clé.

Chris Date fait référence au résumé de Kent comme « une caractérisation intuitivement attrayante » de 3NF et note qu'avec une légère adaptation, il peut servir de définition de la forme normale Boyce-Codd légèrement plus forte : « Chaque attribut doit représenter un fait concernant la clé, l'ensemble clé, et rien que la clé." La version 3NF de la définition est plus faible que la variation BCNF de Date, car la première vise uniquement à garantir que les attributs non clés dépendent des clés. Les attributs premiers (qui sont des clés ou des parties de clés) ne doivent pas du tout être fonctionnellement dépendants ; ils représentent chacun un fait concernant la clé dans le sens de fournir une partie ou la totalité de la clé elle-même. (Cette règle s'applique uniquement aux attributs fonctionnellement dépendants, car son application à tous les attributs interdirait implicitement les clés candidates composites, puisque chaque partie d'une telle clé violerait la clause "clé entière".)

Un exemple de table 2NF qui ne satisfait pas aux exigences de 3NF est :

Étant donné que chaque ligne du tableau doit nous indiquer qui a remporté un tournoi particulier au cours d'une année particulière, la clé composite {Tournoi, Année} est un ensemble minimal d'attributs garantis pour identifier de manière unique une ligne. C'est-à-dire que {Tournoi, Année} est une clé candidate pour la table.

La violation de 3NF se produit parce que l'attribut non principal (date de naissance du gagnant) dépend de manière transitive de la clé candidate {Tournoi, Année} via l'attribut non principal Gagnant. Le fait que la date de naissance de Winner dépende fonctionnellement de Winner rend le tableau vulnérable aux incohérences logiques, car rien n'empêche d'afficher la même personne avec des dates de naissance différentes sur des enregistrements différents.

Afin d'exprimer les mêmes faits sans enfreindre les 3NF, il faut scinder le tableau en deux :

Des anomalies de mise à jour ne peuvent pas se produire dans ces tables, car contrairement à avant, Winner est désormais une clé candidate dans la deuxième table, n'autorisant ainsi qu'une seule valeur pour la Date de naissance pour chaque Gagnant.

Calcul

Une relation peut toujours être décomposée sous une troisième forme normale, c'est-à-dire que la relation R est réécrite en projections R ₁ , ..., R _n dont la jointure est égale à la relation d'origine. De plus, cette décomposition ne perd aucune dépendance fonctionnelle , en ce sens que chaque dépendance fonctionnelle sur R peut être dérivée des dépendances fonctionnelles qui tiennent sur les projections R ₁ , ..., R _n . De plus, une telle décomposition peut être calculée en temps polynomial .

Dérivation des conditions de Zaniolo

La définition de 3NF proposée par Carlo Zaniolo en 1982, et donnée ci-dessus, est prouvée de la manière suivante : Soit X → A une FD non triviale (ie où X ne contient pas A) et soit A un attribut non-clé. Soit aussi Y une clé de R. Alors Y → X.

Normalisation au-delà de 3NF

La plupart des tables 3NF sont exemptes d'anomalies de mise à jour, d'insertion et de suppression. Certains types de tables 3NF, rarement rencontrés en pratique, sont concernés par de telles anomalies ; ce sont des tableaux qui sont soit inférieurs à la forme normale Boyce-Codd (BCNF), soit, s'ils répondent à BCNF, inférieurs aux formes normales supérieures 4NF ou 5NF .

Considérations relatives à l'utilisation dans les environnements de génération de rapports

Alors que 3NF était idéal pour le traitement machine, la nature segmentée du modèle de données peut être difficile à utiliser par un utilisateur humain. Les analyses via des requêtes, des rapports et des tableaux de bord étaient souvent facilitées par un autre type de modèle de données qui fournissait des analyses pré-calculées telles que des courbes de tendance, des calculs cumulatifs (cumul mensuel, cumulé trimestriel, à ce jour), calculs cumulatifs, statistiques de base (moyenne, écart type, moyennes mobiles) et comparaisons de périodes précédentes (il y a un an, il y a un mois, il y a une semaine), par exemple la modélisation dimensionnelle et au-delà de la modélisation dimensionnelle, l'aplatissement des étoiles via Hadoop et la science des données .

Voir également

• Système attribut-valeur

Les références

Lectures complémentaires

Liens externes

• Conseils de Litt : normalisation
• Bases de la normalisation des bases de données par Mike Chapple (About.com)
• Une introduction à la normalisation de base de données par Mike Hillyer.
• Un tutoriel sur les 3 premières formes normales par Fred Coulson
• Description des bases de la normalisation de base de données par Microsoft
• Troisième forme normale avec des exemples simples par exploreDatabase