Qu'est-ce que la normalisation (ou normalisation)?
Réponses:
La normalisation consiste essentiellement à concevoir un schéma de base de données de manière à éviter les données dupliquées et redondantes. Si une donnée est dupliquée à plusieurs endroits dans la base de données, il y a un risque qu'elle soit mise à 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 séparée par voiture:
UserId | Car
---------------------
1 | Toyota
2 | Ford
2 | Cadillac
Le problème avec le fait d'avoir plusieurs valeurs dans une cellule est qu'elle est délicate à mettre à jour, difficile à interroger, et 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 UserId. Cela permet théoriquement de changer le nom de Sue sur une ligne et pas 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 ayons encore des données redondantes parce que 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. Puisque les données «vivent pour toujours», il est très difficile de se débarrasser des données corrompues lorsqu'elles sont entrées pour la première fois dans la base de données.
N'ayez pas peur de la normalisation . Les définitions techniques officielles des niveaux de normalisation sont assez obtuses. Cela donne l'impression que la normalisation est un processus mathématique compliqué. Cependant, la normalisation relève essentiellement du 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 y a un certain nombre d'idées fausses autour de la normalisation:
certains pensent que les bases de données normalisées sont plus lentes et que la dénormalisation améliore les performances. Ceci 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 arrêter". Mais en fait, les niveaux de normalisation décrivent simplement différents problèmes spécifiques. Les problèmes résolus par les formes normales au-dessus de la 3e NF sont des problèmes assez rares en premier lieu, il est donc probable que votre schéma soit déjà en 5NF.
S'applique-t-il à quoi que ce soit en dehors des bases de données? Pas directement, non. Les principes de normalisation sont assez spécifiques pour les 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é à grande échelle. C'est fondamentalement le principe DRY .
Les règles de normalisation (source: inconnue)
... Alors aidez-moi Codd.
Plus important encore, il sert à 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, déplacez le nom vers une table séparée et référencez-le partout ailleurs. De cette façon, si vous avez besoin de changer le nom de la personne plus tard, vous ne devez le changer qu'à un seul endroit.
Il est crucial pour une bonne conception de la base de données et en théorie, vous devez l'utiliser autant que possible pour préserver l'intégrité de vos données. Cependant, lorsque vous récupérez des informations à partir de nombreuses tables, vous perdez des performances et c'est pourquoi vous pouvez parfois voir des tables de base de données dénormalisées (également appelées aplaties) utilisées dans des applications critiques en termes de performances.
Mon conseil est de commencer par un bon degré de normalisation et de ne faire la dénormalisation que lorsque cela est vraiment nécessaire
PS consultez également cet article: http://en.wikipedia.org/wiki/Database_normalization pour en savoir plus sur le sujet et sur les formes dites normales
Normalisation une 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) Normaliser signifie changer le schéma (souvent partitionner les tables) de manière réversible, donnant un modèle qui est 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 le Wikipedia http://en.wikipedia.org/wiki/Database_normalization
Je vais donner un exemple un 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 de famille
ID, address
27 123 Main St.
La normalisation presque complète (BCNF) n'est généralement pas utilisée en production, mais constitue une étape intermédiaire. Une fois que vous avez placé la base de données dans BCNF, l'étape suivante consiste généralement à la dé -normaliser de manière logique pour accélérer les requêtes et réduire la complexité de certains insertions courantes. Cependant, vous ne pouvez pas bien le faire sans le normaliser correctement au préalable.
L'idée étant que les informations redondantes sont réduites à une seule entrée. Ceci est particulièrement utile dans les champs tels que 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îtrait 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, à isoler ces champs dans une autre table avec des identifiants uniques et à remplacer les éléments répétés par une clé primaire référençant la nouvelle table.
Citant CJ Date: La théorie est pratique.
Les écarts par rapport à la normalisation entraîneront certaines anomalies dans votre base de données.
Les écarts par rapport au premier formulaire normal 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", comme indiqué par une réponse précédente, et que vous recherchez toutes les occurrences de "Ford", vous allez devoir ouvrir la chaîne et regarder le sous-chaînes. Ceci, dans une certaine mesure, 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 le moment. Si vous concevez vos tables SQL à l'aide du modèle de données relationnelles, 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 stocker 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 supprimez 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 par une programmation minutieuse. Parfois (souvent), il est préférable de prévenir les problèmes en premier lieu en adhérant aux formes normales.
Nonobstant 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 au moins conforme à 3NF. Dans de nombreux cas, la conception sera entièrement normalisée.
Là où vous voudrez peut-être vraiment appliquer les concepts enseignés dans le cadre de la normalisation, c'est lorsque vous recevez des données héritées, issues d'une base de données héritée ou de fichiers constitués d'enregistrements, et que les données ont été conçues dans l'ignorance totale des formes normales et des conséquences d'un 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 offense à Codd. (petit jeu de mots là-bas). N'achetez pas ça. Lorsque vous apprenez 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 sur l'autre.
Dans les bases de données signifie spécifiquement que deux (ou plus) tables ne contiennent pas les mêmes données, c'est-à-dire n'ont pas de redondance.
A première vue c'est vraiment bien car vos chances de faire quelques problèmes de synchronisation sont proches de zéro, vous savez toujours où se trouvent vos données, etc. Mais, probablement, votre nombre de tables va augmenter et vous aurez des problèmes pour croiser les données et pour obtenir des résultats sommaires.
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 possibles de normalisation).
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 à minimiser à la fois la redondance des données et les anomalies de mise à jour .
Courtoisie du processus de normalisation
Première forme normale si et seulement si le domaine de chaque attribut contient uniquement des valeurs atomiques (une valeur atomique est une valeur qui ne peut pas être divisée), et que la valeur de chaque attribut ne contient qu'une seule valeur de ce domaine (exemple: - domaine pour le la colonne de 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 associées avec une clé primaire
Deuxième forme normale = 1NF + pas de dépendances partielles, c'est-à-dire que tous les attributs non clés dépendent entièrement 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 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 de deuxième, troisième et Boyce – Codd concernent les dépendances fonctionnelles. Exemples
Quatrième forme normale = 3NF + supprimer les dépendances à plusieurs valeurs
Cinquième forme normale = 4NF + supprimer les dépendances de jointure
Comme le dit Martin Kleppman dans son livre Designing Data Intensive Applications:
La littérature sur le modèle relationnel distingue plusieurs formes normales différentes, mais les distinctions sont de peu d'intérêt pratique. En règle générale, si vous dupliquez des valeurs qui pourraient être stockées à un seul endroit, le schéma n'est pas normalisé.
Cela permet d'éviter les données en double (et pire encore, en conflit).
Cela peut avoir un impact négatif sur les performances.