Comment déterminer jusqu’où normaliser une base de données ?

Question

Lors de la création d’une structure de base de données, quelles sont les bonnes lignes directrices à suivre ou les bons moyens de déterminer dans quelle mesure une base de données doit être normalisée ?Devriez-vous créer une base de données non normalisée et la diviser au fur et à mesure de l'avancement du projet ?Devriez-vous le créer entièrement normalisé et combiner les tables selon les besoins des performances ?

Answer 1

Vous souhaitez commencer à concevoir une base de données normalisée jusqu'à la 3ème forme normale.Au fur et à mesure que vous développez la couche de logique métier, vous pouvez décider de dénormaliser un peu, mais jamais jamais allez en dessous du 3ème formulaire.Gardez toujours les 1e et 2e formulaires conformes.Vous souhaitez dénormaliser pour la simplicité du code, pas pour les performances.Utilisez des index et des procédures stockées pour cela :)

La raison pour laquelle vous ne « normalisez pas au fur et à mesure » est que vous devrez modifier le code que vous avez déjà écrit à chaque fois que vous modifiez la conception de la base de données.

Il y a quelques bons articles :

http://www.agiledata.org/essays/dataNormalization.html

Answer 2

@GrizzlyGuru Un sage m'a dit un jour "normaliser jusqu'à ce que ça fasse mal, dénormaliser jusqu'à ce que ça marche".

Cela ne m'a pas encore échoué :)

Je ne suis pas d'accord sur le fait de commencer avec une forme non normalisée. Cependant, d'après mon expérience, il a été plus facile d'adapter votre application pour gérer une base de données moins normalisée qu'une base de données plus normalisée.Cela pourrait également conduire à des situations où cela fonctionne « assez bien » pour que vous ne parveniez jamais à le normaliser (jusqu'à ce qu'il soit trop tard !)

Answer 3

La normalisation signifie éliminer les données redondantes.En d’autres termes, une base de données non normalisée ou dénormalisée est une base de données dans laquelle les mêmes informations seront répétées à plusieurs endroits différents.Cela signifie que vous devez écrire une instruction de mise à jour plus complexe pour garantir que vous mettez à jour les mêmes données partout, sinon vous obtenez des données incohérentes, ce qui signifie que le résultat des requêtes n'est pas fiable.

C’est un problème assez énorme, donc je dirais que la dénormalisation fait mal, et non l’inverse.

Dans certains cas, vous pouvez délibérément décider de dénormaliser des parties spécifiques d'une base de données, si vous estimez que les avantages l'emportent sur le travail supplémentaire lié à la mise à jour des données et sur le risque de corruption des données.Par exemple avec les entrepôts de données, où les données sont agrégées pour des raisons de performances, et les données si elles ne sont souvent pas mises à jour après la saisie initiale, ce qui réduit le risque d'incohérences.

Mais en général, méfiez-vous de la dénormalisation pour la performance.Par exemple, l'avantage en termes de performances d'une jointure dénormalisée peut généralement être obtenu en utilisant vue matérialisée (aussi appelé vue indexée), ce qui sera aussi rapide que l'interrogation d'une table dénormalisée, mais protège toujours la cohérence des données.

Answer 4

Jeff a un assez bon aperçu de sa philosophie sur son blog : Peut-être que la normalisation n'est pas normale.L'essentiel est :n'exagérez pas la normalisation.Mais je pense qu’un point encore plus important à retenir est que cela n’a probablement pas trop d’importance.À moins que vous n'utilisiez le prochain Google, vous ne remarquerez probablement pas beaucoup de différence jusqu'à ce que votre application se développe.

Answer 5

Je considère que la normalisation des bases de données est une forme d'art.

Vous ne voulez pas trop normaliser votre base de données, car vous aurez trop de tables et vos requêtes sur des objets, même simples, prendront plus de temps qu'elles ne le devraient.

Une bonne règle de base que je suis est de normaliser les mêmes informations répétées encore et encore.

Par exemple, si vous créez une application de gestion de contacts, il serait logique d'avoir une adresse (rue, ville, état, code postal, etc..) comme sa propre table.

Cependant si vous n’avez que 2 types de contacts, Professionnels ou Personnels, avez-vous besoin d’un tableau de types de contacts si vous savez que vous n’en aurez que 2 ?Pour moi non.

Je commencerais par déterminer les types de données dont vous avez besoin.Utilisez un programme de modélisation pour vous aider comme Visio.Vous ne voulez pas commencer avec une base de données non normalisée, car vous finirez par la normaliser.Commencez par placer les objets dans des groupements logiques, lorsque vous voyez des données répétées, placez ces données dans une nouvelle table.Je suivrais ce processus jusqu'à ce que vous sentiez que la base de données est conçue.

Laissez les tests vous indiquer si vous devez combiner des tables.Une requête bien écrite peut couvrir toute normalisation excessive.

Answer 6

Je pense que commencer avec une base de données non normalisée et évoluer vers une base de données normalisée au fur et à mesure de votre progression est généralement le plus facile à démarrer.Quant à la question de savoir jusqu’où normaliser, ma philosophie est de normaliser jusqu’à ce que cela commence à faire mal.Cela peut paraître un peu désinvolte, mais c’est généralement un bon moyen d’évaluer jusqu’où aller.

Answer 7

Avoir une base de données normalisée vous offrira la plus grande flexibilité et la maintenance la plus simple.Je commence toujours avec une base de données normalisée, puis je ne la normalise que lorsqu'il y a un problème réel à résoudre.

Je vois cela de la même manière que les performances du code, c'est-à-direécrivez du code flexible et maintenable et faites des compromis en termes de performances lorsque vous savoir qu'il y a un problème de performances.

Answer 8

L'affiche originale n'a jamais décrit dans quelle situation la base de données sera utilisée.S'il s'agit de n'importe quel type de projet d'entreposage de données pour lequel, à un moment donné, vous aurez besoin de cubes (OLAP) traitant des données pour certains front-end, il serait plus sage de commencer avec un schéma en étoile (tables de faits + dimension) plutôt que d'examiner normalisation.Les livres de Kimball seront d’une grande aide dans ce cas.

Answer 9

Je suis d'accord qu'il est généralement préférable de commencer avec une base de données normalisée, puis de la dénormaliser pour résoudre des problèmes très spécifiques, mais je commencerais probablement par Forme normale de Boyce-Codd au lieu de la 3ème Forme Normale.

Answer 10

La vérité est que «cela dépend». Cela dépend de nombreux facteurs, notamment:

• Code (codé manuellement ou piloté par un outil (comme les packages ETL))
• Application principale (traitement des transactions, entreposage de données, reporting)
• Type de base de données (MySQL, DB/2, Oracle, Netezza, etc.)
• Architecture de base de données (tableau, colonne)
• Qualité DBA (proactive, réactive, inactive)
• Qualité des données attendue (souhaitez-vous appliquer la qualité des données au niveau de l'application ou au niveau de la base de données ?)

Answer 11

Je suis d'accord que vous devriez normaliser autant que possible et dénormaliser uniquement si cela est absolument nécessaire pour la performance.Et avec les vues matérialisées ou les systèmes de mise en cache, cela n'est souvent pas nécessaire.

La chose à garder à l'esprit est qu'en normalisant votre modèle, vous donnez à la base de données plus d'informations sur la façon de contraindre vos données afin que vous puissiez supprimer le risque d'anomalies de mise à jour qui peuvent survenir dans des modèles incomplètement normalisés.

Si vous dénormalisez, vous devez soit vivre avec le fait que vous pouvez obtenir des anomalies de mise à jour, soit implémenter vous-même la validation de contrainte dans votre code d'application.Cela enlève beaucoup des avantages de l'utilisation d'un SGBD qui vous permet de définir ces contraintes de manière déclarative.

Donc, en supposant la même qualité de code, la dénormalisation peut ne pas vous offrir de meilleures performances.

Une autre chose à mentionner est que le matériel est bon marché de nos jours, il est donc souvent plus rentable d'investir dans une puissance de traitement supplémentaire pour résoudre le problème que d'accepter les coûts potentiels liés au nettoyage des données corrompues.

Answer 12

Souvent, si vous normalisez autant que votre autre logiciel vous le permet, vous aurez terminé.

Par exemple, lorsque vous utilisez la technologie de mappage objet-relationnel, vous disposerez d’un riche ensemble de sémantiques pour diverses relations plusieurs-à-un et plusieurs-à-plusieurs.Sous le capot, cela fournira des tables de jointure avec effectivement 2 clés primaires.Bien que relativement rare, la véritable normalisation vous donne souvent des relations avec 3 clés primaires ou plus.Dans des cas comme celui-ci, je préfère m'en tenir à l'O/R et lancer mon propre code pour éviter les diverses anomalies de la base de données.

Answer 13

Essayez simplement de faire preuve de bon sens.

Certains disent également - et je dois être d'accord avec eux - que, si vous vous retrouvez à joindre 6 tables (le nombre magique) ensemble dans la plupart de vos requêtes - sans compter celles liées aux rapports -, vous pourriez envisager de dénormaliser un peu.

Answer 14

N'oublie pas La mère de tous les débats sur la normalisation des bases de données sur Coding Horror (résumé sur le blog High Scalability).