Comment faire face à des anomalies de modification SQL et formes normales

Une multitude de problèmes - appelé anomalies de modification - peut affliger une base de données si vous ne structurer la base de données SQL correctement. Pour éviter ces problèmes, vous pouvez normaliser la structure de base de données. La normalisation implique généralement diviser une table de base de données dans deux tables plus simples.

Anomalies de modification sont ainsi nommés parce qu'ils sont produits par l'addition de, modification de, ou l'effacement des données d'une table de base de données.

image0.jpg

Supposons, par exemple, que votre entreprise vend des produits d'entretien ménager, et vous facturer tous les clients le même prix pour chaque produit. La table SALES garde la trace de tout pour vous. Supposons que le client se déplace loin 1001 et non plus est un client. Vous ne vous souciez pas de ce qu'il a acheté dans le passé, parce qu'il ne va pas acheter quelque chose de nouveau. Vous voulez supprimer sa ligne de la table.

Si vous le faites, toutefois, vous ne perdent pas seulement le fait que le client a acheté 1 001 buanderie un détergent vous perdez aussi le fait que les détergents à lessive coûte 12 $. Cette situation est appelée un suppression anomalie. En supprimant un fait (ce client a acheté 1 001 détergent à lessive), vous supprimez par inadvertance un autre fait (que détergent à lessive coûte 12 $).

Vous pouvez utiliser la même table pour illustrer une anomalie d'insertion. Par exemple, supposons que vous voulez ajouter bâton déodorant à votre ligne de produit à un prix de 2 $. Vous ne pouvez pas ajouter ces données à la table des ventes jusqu'à ce qu'un client achète bâton déodorant.




Le problème avec la table de vente est que ce tableau porte sur plus d'une chose: il couvre non seulement les produits dont les clients achètent, mais aussi ce que les produits coûtent. Pour éliminer les anomalies, vous devez diviser la table des ventes en deux tables, chacune traitant d'un seul thème ou une idée.

image1.jpg
  • CUST_PURCH, qui traite de la seule idée d'achats des clients.

  • PROD_PRICE, qui traite de l'idée unique de la tarification des produits.

Vous pouvez maintenant supprimer la ligne pour le client à partir de 1 001 CUST_PURCH sans perdre le fait que les détergents à lessive coûte 12 $. (Le coût de détergent à lessive est maintenant stocké dans PROD_PRICE.) Vous pouvez également ajouter bâton déodorant PROD_PRICE si oui ou non quelqu'un a acheté le produit. Informations d'achat est stockée ailleurs, dans le tableau de CUST_PURCH.

Le processus de la rupture d'une table en plusieurs tables, dont chacune a un thème unique, est appelé normalisation. Une opération de normalisation qui résout un problème peut ne pas affecter d'autres problèmes. Vous pourriez avoir à effectuer plusieurs opérations successives de normalisation pour réduire chaque table résultant d'un thème unique.

Chaque table de base de données doit faire face à un - et un seul - thème principal. Parfois (comme vous l'aurez deviné) la détermination qu'une table vraiment traite de deux ou plusieurs thèmes peuvent être difficiles.

Vous pouvez classer les tableaux selon les types d'anomalies de modification à laquelle ils sont soumis. Dans un article 1970, EF Codd a identifié trois sources d'anomalies de modification et définit des première, deuxième, troisième et formes normales (1NF, 2NF, 3NF) comme des remèdes à ces types d'anomalies. Dans les années qui ont suivi, Codd et d'autres ont découvert d'autres types d'anomalies et spécifiées nouvelles formes normales de traiter avec eux.

La forme Boyce-Codd normale (BCNF), la quatrième forme normale (4NF), et la cinquième forme normale (5NF) chaque bénéficient un degré plus élevé de protection contre les anomalies de modification. Pas avant 1981, cependant, a fait un papier, écrit par Ronald Fagin, décrire forme normale domaine-clé ou DK / NF. Grâce à cette dernière forme normale vous permet de garantie qu'une table est libre d'anomalies de modification.

Les formes normales sont nichée dans le sens où une table qui est en 2NF est automatiquement aussi dans 1FN. De même, une table dans 3NF est automatiquement en 2NF, et ainsi de suite. Pour la plupart des applications pratiques, mettre une base de données en 3NF est suffisante pour assurer un degré élevé d'intégrité. Pour être absolument sûr de son intégrité, vous devez mettre la base de données en DK / NF.

Après vous normaliser une base de données autant que possible, vous pouvez faire dénormalisations sélectionnés pour améliorer les performances. Si vous le faites, être conscient des types d'anomalies qui peuvent désormais possible.


» » » » Comment faire face à des anomalies de modification SQL et formes normales