Qu'est-ce que la normalisation (ou normalisation)?
Pourquoi les gars de la base de données parlent-ils de normalisation?
Qu'Est-ce que c'est? Comment ça aide?
S'applique-t-il à quelque chose en dehors des bases de données?
La normalisation consiste essentiellement à concevoir un schéma de base de données de manière à éviter les doublons et les redondances. Si un élément de données est dupliqué à plusieurs endroits dans la base de données, il y a le risque qu'il soit mis à jour à un endroit mais pas à l'autre, conduisant à une corruption des données.
Il existe un certain nombre de niveaux de normalisation allant de 1. la forme normale à 5. la forme normale. Chaque formulaire normal décrit comment se débarrasser d'un problème spécifique, généralement lié à la redondance.
Quelques erreurs de normalisation typiques:
(1) Avoir plus d'une valeur dans une cellule. Exemple:
UserId | Car
---------------------
1 | Toyota
2 | Ford,Cadillac
Ici, la colonne "Car" (qui est une chaîne) a plusieurs valeurs. Cela offense la première forme normale, qui dit que chaque cellule ne doit avoir qu'une seule valeur. Nous pouvons normaliser ce problème en ayant une ligne distincte par voiture:
UserId | Car
---------------------
1 | Toyota
2 | Ford
2 | Cadillac
Le problème avec plusieurs valeurs dans une cellule est qu'il est difficile à mettre à jour, difficile à interroger et que vous ne pouvez pas appliquer d'index, de contraintes, etc.
(2) Avoir des données non clés redondantes (c'est-à-dire des données répétées inutilement sur plusieurs lignes). Exemple:
UserId | UserName | Car
-----------------------
1 | John | Toyota
2 | Sue | Ford
2 | Sue | Cadillac
Cette conception est un problème car le nom est répété pour chaque colonne, même si le nom est toujours déterminé par l'UserId. Cela permet théoriquement de changer le nom de Sue sur une ligne et non sur l'autre, ce qui est une corruption de données. Le problème est résolu en divisant la table en deux et en créant une relation clé primaire/clé étrangère:
UserId(FK) | Car UserId(PK) | UserName
--------------------- -----------------
1 | Toyota 1 | John
2 | Ford 2 | Sue
2 | Cadillac
Maintenant, il peut sembler que nous avons encore des données redondantes car les UserId sont répétés; Cependant, la contrainte PK/FK garantit que les valeurs ne peuvent pas être mises à jour indépendamment, donc l'intégrité est sûre.
Est-ce important? Oui, c'est très important. En ayant une base de données avec des erreurs de normalisation, vous ouvrez le risque d'obtenir des données invalides ou corrompues dans la base de données. Comme les données "vivent éternellement", il est très difficile de se débarrasser des données corrompues lors de leur première entrée dans la base de données.
N'ayez pas peur de la normalisation . Les définitions techniques officielles des niveaux de normalisation sont assez obtus. Cela donne l'impression que la normalisation est un processus mathématique compliqué. Cependant, la normalisation est essentiellement le bon sens, et vous constaterez que si vous concevez un schéma de base de données en utilisant le bon sens, il sera généralement entièrement normalisé.
Il existe un certain nombre d'idées fausses concernant la normalisation:
certains pensent que les bases de données normalisées sont plus lentes et que la dénormalisation améliore les performances. Cela n'est cependant vrai que dans des cas très particuliers. En règle générale, une base de données normalisée est également la plus rapide.
parfois, la normalisation est décrite comme un processus de conception graduel et vous devez décider "quand vous arrêter". Mais en réalité, les niveaux de normalisation décrivent simplement différents problèmes spécifiques. Les problèmes résolus par des formes normales au-dessus de la 3e NF sont des problèmes assez rares en premier lieu, donc les chances sont que votre schéma soit déjà en 5NF.
Est-ce que cela s'applique à quelque chose en dehors des bases de données? Pas directement, non. Les principes de normalisation sont assez spécifiques aux bases de données relationnelles. Cependant, le thème général sous-jacent - que vous ne devriez pas avoir de données en double si les différentes instances peuvent se désynchroniser - peut être appliqué de manière large. Il s'agit essentiellement du principe DRY .
Les règles de normalisation (source: inconnue)
... Alors aidez-moi Codd.
Plus important encore, il permet de supprimer la duplication des enregistrements de la base de données. Par exemple, si vous avez plus d'un endroit (tables) où le nom d'une personne pourrait apparaître, vous déplacez le nom vers une table distincte et le référencez partout ailleurs. De cette façon, si vous devez changer le nom de la personne plus tard, vous n'avez qu'à le changer au même endroit.
Il est essentiel pour une conception appropriée de la base de données et, en théorie, vous devez l'utiliser autant que possible pour conserver l'intégrité de vos données. Cependant, lorsque vous récupérez des informations de nombreuses tables, vous perdez des performances et c'est pourquoi parfois vous pouvez voir des tables de base de données dénormalisées (également appelées aplaties) utilisées dans des applications critiques pour les performances.
Mon conseil est de commencer par un bon degré de normalisation et de ne dénormaliser que lorsque cela est vraiment nécessaire
P.S. consultez également cet article: http://en.wikipedia.org/wiki/Database_normalization pour en savoir plus sur le sujet et sur les soi-disant formes normales
Normalisation: procédure utilisée pour éliminer la redondance et les dépendances fonctionnelles entre les colonnes d'une table.
Il existe plusieurs formes normales, généralement indiquées par un nombre. Un nombre plus élevé signifie moins de redondances et de dépendances. Toute table SQL est en 1NF (première forme normale, à peu près par définition) La normalisation signifie changer le schéma (souvent en partitionnant les tables) de manière réversible, donnant un modèle fonctionnellement identique, sauf avec moins de redondance et de dépendances.
La redondance et la dépendance des données ne sont pas souhaitables car elles peuvent entraîner des incohérences lors de la modification des données.
Il vise à réduire la redondance des données.
Pour une discussion plus formelle, voir Wikipedia http://en.wikipedia.org/wiki/Database_normalization
Je vais donner un exemple quelque peu simpliste.
Supposons que la base de données d'une organisation qui contient généralement des membres de la famille
id, name, address
214 Mr. Chris 123 Main St.
317 Mrs. Chris 123 Main St.
pourrait être normalisé comme
id name familyID
214 Mr. Chris 27
317 Mrs. Chris 27
et une table familiale
ID, address
27 123 Main St.
La normalisation presque complète (BCNF) n'est généralement pas utilisée en production, mais est une étape intermédiaire. Une fois que vous avez mis la base de données dans BCNF, l'étape suivante consiste généralement à dénormaliser de manière logique pour accélérer les requêtes et réduire la complexité de certains inserts courants. Cependant, vous ne pouvez pas bien le faire sans d'abord le normaliser correctement.
L'idée étant que les informations redondantes se réduisent à une seule entrée. Cela est particulièrement utile dans des domaines comme les adresses, où M. Chris soumet son adresse en tant que Unit-7 123 Main St. et Mme Chris répertorie le Suite-7 123 Main Street, qui apparaîtra dans le tableau d'origine comme deux adresses distinctes.
En règle générale, la technique utilisée consiste à rechercher des éléments répétés et à isoler ces champs dans une autre table avec des ID uniques et à remplacer les éléments répétés par une clé primaire référençant la nouvelle table.
Citant CJ Date: Théorie IS pratique.
Les écarts de normalisation entraîneront certaines anomalies dans votre base de données.
Les écarts par rapport à First First Form entraîneront des anomalies d'accès, ce qui signifie que vous devez décomposer et analyser les valeurs individuelles afin de trouver ce que vous recherchez. Par exemple, si l'une des valeurs est la chaîne "Ford, Cadillac" donnée par une réponse antérieure, et que vous recherchez toutes les occurrences de "Ford", vous allez devoir ouvrir la chaîne et regarder le sous-chaînes. Dans une certaine mesure, cela va à l'encontre de l'objectif de stockage des données dans une base de données relationnelle.
La définition de la première forme normale a changé depuis 1970, mais ces différences ne doivent pas vous concerner pour l'instant. Si vous concevez vos tables SQL à l'aide du modèle de données relationnel, vos tables seront automatiquement en 1NF.
Les écarts par rapport à la deuxième forme normale et au-delà entraîneront des anomalies de mise à jour, car le même fait est stocké à plusieurs endroits. Ces problèmes rendent impossible le stockage de certains faits sans le stockage d'autres faits qui peuvent ne pas exister et doivent donc être inventés. Ou lorsque les faits changent, vous devrez peut-être localiser tous les plces où un fait est stocké et mettre à jour tous ces endroits, de peur de vous retrouver avec une base de données qui se contredit. Et, lorsque vous allez supprimer une ligne de la base de données, vous pouvez constater que si vous le faites, vous supprimez le seul endroit où un fait encore nécessaire est stocké.
Ce sont des problèmes logiques, pas des problèmes de performances ou des problèmes d'espace. Parfois, vous pouvez contourner ces anomalies de mise à jour en programmant soigneusement. Parfois (souvent), il vaut mieux prévenir les problèmes en premier lieu en respectant les formes normales.
Malgré la valeur de ce qui a déjà été dit, il convient de mentionner que la normalisation est une approche ascendante et non descendante. Si vous suivez certaines méthodologies dans votre analyse des données et dans votre conception initiale, vous pouvez être assuré que la conception sera conforme à 3NF au moins. Dans de nombreux cas, la conception sera entièrement normalisée.
Lorsque vous souhaitez vraiment appliquer les concepts enseignés dans le cadre de la normalisation, c'est lorsque vous recevez des données héritées, à partir d'une base de données héritée ou à partir de fichiers constitués d'enregistrements, et que les données ont été conçues dans l'ignorance complète des formes normales et des conséquences du départ. d'eux. Dans ces cas, vous devrez peut-être découvrir les écarts par rapport à la normalisation et corriger la conception.
Attention: la normalisation est souvent enseignée avec des connotations religieuses, comme si tout écart par rapport à la normalisation complète était un péché, une infraction contre Codd. (petit jeu de mots là-bas). N'achetez pas ça. Lorsque vous apprendrez vraiment, vraiment la conception de bases de données, vous saurez non seulement comment suivre les règles, mais aussi quand il est sûr de les enfreindre.
La normalisation est l'un des concepts de base. Cela signifie que deux choses ne s'influencent pas l'une l'autre.
Dans les bases de données signifie spécifiquement que deux (ou plusieurs) tables ne contiennent pas les mêmes données, c'est-à-dire qu'elles n'ont aucune redondance.
À première vue, c'est vraiment bien parce que vos chances de faire des problèmes de synchronisation sont proches de zéro, vous savez toujours où sont vos données, etc. Mais, probablement, votre nombre de tables augmentera et vous aurez des problèmes pour traverser les données et pour obtenir des résultats résumés.
Donc, à la fin, vous terminerez avec une conception de base de données qui n'est pas purement normalisée, avec une certaine redondance (ce sera dans certains des niveaux de normalisation possibles).
Qu'est-ce que la normalisation?
La normalisation est un processus formel par étapes qui nous permet de décomposer les tables de base de données de manière à ce que la redondance des données et les anomalies de mise à jour sont minimisées.
Processus de normalisation 
Courtoisie
Première forme normale si et seulement si le domaine de chaque attribut ne contient que des valeurs atomiques (une valeur atomique est une valeur qui ne peut pas être divisée), et la valeur de chaque attribut ne contient qu'une seule valeur de ce domaine (exemple: - le domaine de la colonne genre est: "M", "F".).
La première forme normale applique ces critères:
- Éliminez les groupes répétitifs dans les tableaux individuels.
- Créez une table distincte pour chaque ensemble de données associées.
- Identifiez chaque ensemble de données connexes avec une clé primaire
Deuxième forme normale = 1NF + pas de dépendances partielles, c'est-à-dire que tous les attributs non clés sont entièrement fonctionnels en fonction de la clé primaire.
Troisième forme normale = 2NF + pas de dépendances transitives, c'est-à-dire que tous les attributs non clés sont entièrement fonctionnels et dépendent DIRECTEMENT uniquement de la clé primaire.
La forme normale de Boyce – Codd (ou BCNF ou 3.5NF) est une version légèrement plus forte de la troisième forme normale (3NF).
Remarque: - Les formes normales Second, Third et Boyce – Codd concernent les dépendances fonctionnelles. Exemples
Quatrième forme normale = 3NF + supprimer les dépendances à valeurs multiples
Cinquième forme normale = 4NF + supprimer les dépendances de jointure