Ok, deux choses:
- php n'a rien à voir avec cela. la normalisation concerne la modélisation des données
- La normalisation ne consiste pas à économiser de l'espace disque. Il s'agit d'organiser les données pour qu'elles soient facilement maintenables, ce qui est un moyen de maintenir l'intégrité des données.
- La normalisation est généralement décrite en quelques étapes ou «formes normales». En pratique, les personnes qui conçoivent des bases de données relationnelles ont souvent intuitivement «bien fait les choses» la plupart du temps. Mais il est toujours bon d'être conscient des formes normales et de leurs caractéristiques. Il y a beaucoup de documentation sur ce sur Internet (fe http://en.wikipedia.org/wiki/Database_normalization), et vous devriez certainement faire vous propres recherches, mais les étapes les plus importantes sont:
données unormalized: à ce stade, les données ne sont pas véritablement sous forme de tableau ('relationnel'). Il y a beaucoup de discussions sur ce que signifie réellement le tabulaire, et les experts ne sont pas d'accord entre eux. mais la plupart des gens conviennent que les données sont non normalisées dans le cas où il y a des attributs à plusieurs valeurs (= colonnes qui peuvent contenir une liste comme valeur), ou dans le cas où il existe des groupes répétitifs (= plusieurs colonnes ou plusieurs groupes de colonnes). type de données)
Exemple de colonne à plusieurs valeurs: personne (prenom, last_name, phoneNumbers) ici, phoneNumbers implique qu'il pourrait y avoir plus phoneNumbers, stockées dans une colonne
Exemple de groupe répéter: personne (prenom , last_name, child1_first_name, child1_birth_date, child2_first_name, child2_birth_date ..., childN_first_name, childN_birth_date) Ici, la table des personnes a un nombre de paires de colonnes (child_first_name, child_birth_date) t o stocker les enfants de la personne. Notez que quelque chose comme order (shipping_address, billing_address) n'est pas un groupe répétitif: les adresses de facturation et d'expédition peuvent être des éléments de données similaires, mais chacun a son propre rôle pour une commande, les deux représentent juste un aspect différent d'une commande. child1 thru child10 non - les enfants n'ont pas de rôles spécifiques et la liste des enfants est variable (vous ne savez jamais combien de groupes vous devez réserver à l'avance)
Dans les deux cas, colonnes à valeurs multiples et groupes récurrents, vous fondamentalement avoir structure de "table imbriquée" - une table dans une table. Les données sont dites en 1NF (première forme normale) si aucune de ces deux conditions ne se présente.
Le 1NF concerne les caractéristiques structurelles: la forme tabulaire des données. Toutes les formes normales subséquentes ont à voir avec l'élimination de la redondance. La redondance se produit lorsque la même information est stockée indépendamment plusieurs fois. La redondance est mauvaise: si vous voulez changer un fait, vous devez le changer à plusieurs endroits. Si vous oubliez de hasarder l'un d'entre eux, vous avez des données incohérentes - les données se contredisent.
De nombreux processus peuvent éliminer la redondance, chacun conduisant à une forme normale plus élevée, allant de 1nf à 6nf. Cependant, la plupart des bases de données sont correctement normalisées à 3nf (ou une variante de la forme normale de boyce-codd, BCNF). Vous devriez étudier 2nf et 3nf, mais le principe est très simple: une table est correctement normalisée si:
- la table est en 1NF
- la table dispose d'une clé (une combinaison de colonne ou d'une colonne dont les valeurs sont nécessaires, et qui identifie de manière unique une ligne. - autrement dit, il ne peut y avoir qu'une seule rangée ayant cette combinaison de valeurs de la colonnes de clé)
- Aucune colonne de clés ne sont fonctionnellement endent sur une partie de la clé (mais dépendent complètement fonctionnellement de la clé entière).
La dépendance fonctionnelle signifie que la valeur d'une colonne peut être dérivée d'une autre colonne. exemple simple:
order_item (order_id, item_number, customer_id, product_code, PRODUCT_DESCRIPTION, montant)
supposons (order_id, item_number) est la clé. Le code du produit et la description du produit dépendent fonctionnellement l'un de l'autre: pour un code_produit particulier, vous trouverez toujours la même description du produit (comme si la description du produit était une fonction du code_produit). Le problème est maintenant: supposons qu'une description de produit change pour un code de produit particulier, vous devez changer toutes les commandes que nous code_produit. oubliez un seul et vous avez une base de données incohérente. Le moyen de le résoudre est de créer une nouvelle table de produit avec (product_code, product_description), ayant (code_produit) comme clé, puis au lieu de stocker tous les champs de produit dans l'ordre, seulement stocker une référence à une ligne dans le table de produits dans les enregistrements order_item (dans ce cas, order_item ne doit conserver que product_code, ce qui suffit pour rechercher une ligne dans la table product et trouver la description_produit)
Comme vous pouvez le voir, avec cette solution, vous faites économiser de l'espace (en ne stockant pas toutes ces descriptions de produit dans chaque commande_item qui arrive à commander le produit) et vous obtenez plus de tables (séparer le produit de order_item) Mais souvenez-vous que ce n'est pas parce que vous économisez espace disque: éliminer la redondance, ce qui rend t plus facile de maintenir les données. car il vous suffit maintenant de changer une ligne dans la table des produits pour changer la description
Vous avez une bonne réponse a commencé, mais pouvez-vous préciser quand il ne serait pas judicieux d'utiliser la normalisation et quand cela serait le cas? – jerebear
@jerebear Eh bien .. Cela dépend. En général, il peut y avoir des raisons de performance pour les données de dénormalisation. Ceux-ci sont principalement spécifiques au fonctionnement d'une base de données particulière. En cas de doute, utilisez des données normalisées. Gardez juste à l'esprit qu'il existe des exceptions à la règle. – troelskn