Table des matières:
Vidéo: Plaquettes de frein : Les conseils de nos garagistes / Top Entretien #1 (avec Denis Brogniart) 2025
Une fois qu'une base de données SQL est dans sa troisième forme normale, vous avez éliminé la plupart des anomalies de modification, mais pas toutes. Les formes normales au-delà du tiers sont définies pour écraser ces quelques bogues restants.
Forme normale de clé de domaine (DK / NF)
La forme normale de Boyce-Codd (BCNF), la quatrième forme normale (4NF) et la cinquième forme normale (5NF) sont des exemples de telles formes. Chaque formulaire élimine une éventuelle anomalie de modification mais ne garantit pas la prévention de toutes les anomalies de modification possibles. Cependant, la forme normale de la clé de domaine fournit une telle garantie.
Une relation est dans forme normale (DK / NF) si toute contrainte sur la relation est une conséquence logique de la définition des clés et des domaines. Une contrainte dans cette définition est une règle suffisamment précise pour que vous puissiez évaluer si elle est vraie ou non. Une clé est un identifiant unique d'une ligne dans une table. Un domaine est l'ensemble des valeurs autorisées d'un attribut.
Regardez cette base de données, qui se trouve dans 1NF, pour voir ce que vous devez faire pour mettre cette base de données dans DK / NF.
Tableau: VENTES (Customer_ID, Produit, Prix)
Clé: Customer_ID
Contraintes:
-
Customer_ID détermine Produit
-
Produit détermine Prix
-
Customer_ID doit être un nombre entier > 1000
Pour appliquer Contrainte 3 (cet ID client doit être un nombre entier supérieur à 1000), vous pouvez simplement définir le domaine pour Customer_ID afin d'incorporer cette contrainte. Cela fait de la contrainte une conséquence logique du domaine de la colonne CustomerID. Le produit dépend de Customer_ID, et Customer_ID est une clé, donc vous n'avez aucun problème avec Constraint 1, qui est une conséquence logique de la définition de la clé.
La contrainte 2 est un problème. Le prix dépend (est une conséquence logique) du produit et le produit n'est pas une clé. La solution consiste à diviser la table SALES en deux tables. Une table utilise Customer_ID comme clé et l'autre utilise Product comme clé. La base de données, en plus d'être en 3NF, est également en DK / NF.
Concevez vos bases de données pour qu'elles soient en DK / NF si possible. Si vous pouvez le faire, l'application des restrictions de clé et de domaine entraîne le respect de toutes les contraintes et les anomalies de modification ne sont pas possibles. Si la structure d'une base de données est conçue pour vous empêcher de la mettre en DK / NF, alors vous devez construire les contraintes dans le programme d'application qui utilise la base de données. La base de données elle-même ne garantit pas que les contraintes seront satisfaites.
Forme anormale
Comme dans la vie, donc dans les bases de données: Parfois être anormal est payant.Vous pouvez vous laisser emporter par la normalisation et aller trop loin. Vous pouvez diviser une base de données en autant de tables que tout devient lourd et inefficace. La performance peut chuter. Souvent, la structure optimale pour votre base de données est quelque peu dénormalisée.
En fait, les bases de données pratiques (les plus grosses, en tout cas) ne sont presque jamais normalisées jusqu'à DK / NF. Vous voulez normaliser autant que possible les bases de données que vous concevez, afin d'éliminer la possibilité de corruption de données résultant d'anomalies de modification.
Après avoir normalisé la base de données autant que vous le pouvez, effectuez certaines extractions en tant que cycle d'analyse. Si les performances ne sont pas satisfaisantes, examinez votre conception pour voir si la dénormalisation sélective améliorerait les performances sans sacrifier l'intégrité. En ajoutant prudemment la redondance dans des emplacements stratégiques et en dénormalisant juste assez , vous pouvez arriver à une base de données à la fois efficace et à l'abri des anomalies.
