En termes de bases de données, est de "Normaliser l'exactitude de l'éliminer pour la performance" d'un droit mantra?

Question

La normalisation conduit à de nombreux essentielles et les caractéristiques souhaitables, y compris de plaisir esthétique. En outre, il est également théoriquement "correct". Dans ce contexte, la dénormalisation est appliqué comme un compromis, une correction d'atteindre la performance. Est-il une raison autre que les performances d'une base de données pourrait être dénormalisé?

Answer 1

Les deux raisons les plus courantes pour dénormaliser sont:

1. Performance
2. L'Ignorance

La première doit être vérifiée avec le profilage, tandis que le second devrait être corrigé avec un journal roulé ;-)

Je dirais une meilleure mantra serait "normaliser l'exactitude de l'éliminer pour la vitesse et seulement quand c'est nécessaire"

Answer 2

Pour comprendre pleinement l'importation de la question d'origine, vous devez comprendre quelque chose au sujet de la dynamique de l'équipe dans le développement des systèmes, et le genre de comportement (ou d'inconduite) les différents rôles de / sortes de gens sont prédisposés. La normalisation est important, car il n'est pas juste un débat dépassionné de modèles de conception -- elle a aussi beaucoup à voir avec la façon dont les systèmes sont conçus et gérés au fil du temps.

Base de données de personnes sont formées que l'intégrité des données est une question primordiale. Nous aimons à penser en termes de 100% l'exactitude des données, de sorte qu'une fois les données dans la base de données, vous n'avez pas à penser ou à faire face avec elle jamais être logiquement faux. Cette école de pensée, une valeur élevée à la normalisation, car il provoque (forces) une équipe pour venir à bout de la logique sous-jacente des données et du système. À considérer un exemple trivial -- les clients ont un seul nom et l'adresse, ou pourrait-il avoir plusieurs? Quelqu'un doit décider, et le système ne dépend que de la règle appliquée de façon uniforme. Qui sonne comme une simple question, mais multipliez cette question par l'500x comme la conception d'un raisonnablement système complexe et vous verrez le problème, les règles ne pouvez tout simplement pas exister sur le papier, ils doivent être appliquées. Une base de données normalisée (avec l'aide supplémentaire de l'unicité contraintes de clés étrangères, vérifier les valeurs, la logique de l'application de déclencheurs etc.) peut vous aider à bien définir la base de données modèle de données et de l'exactitude des règles, ce qui est vraiment important si vous souhaitez que le système fonctionne comme prévu lorsque plusieurs personnes travaillent sur les différentes parties du système (applications différentes, les rapports, peu importe) et les différentes personnes travaillent sur le système au fil du temps. Ou pour le dire d'une autre manière-si vous n'avez pas un moyen de définir et opérationnel appliquer un noyau solide modèle de données, votre système va sucer.

D'autres personnes (souvent, les développeurs moins expérimentés) ne le voient pas de cette façon. Ils voient la base de données comme un outil asservis à la demande de développement, ou, au pire, une bureaucratie à éviter. (Notez que je dis "moins connu" les développeurs. Un bon développeur aura la même prise de conscience de la nécessité d'un solide modèle de données et la validité des données comme une base de données de la personne. Elles peuvent différer sur la meilleure façon d'y parvenir, mais dans mon expérience, sont raisonnablement faire les choses dans un DB couche aussi longtemps que la DB équipe sait ce qu'ils font et peuvent être à l'écoute des développeurs). Ces moins expérimentés, les gens sont souvent ceux qui poussent pour la dénormalisation, comme plus ou moins une excuse pour faire un rapide et sale travail de conception et de gestion du modèle de données. C'est la façon dont vous finissez par perdre tables de base de données, qui sont de 1:1 avec des écrans de l'application et des rapports, chacune reflétant un autre développeur hypothèses de conception, et une absence totale de bon sens / de la cohérence entre les tables. J'ai vécu cela plusieurs fois dans ma carrière. C'est décourageant et profondément façon improductive au point d'un système.

Ainsi, l'une des raisons que les gens ont un fort sentiment au sujet de la normalisation, c'est que le problème est un stand-in pour les autres questions qu'ils se préoccupent vivement. Si vous êtes aspiré dans un débat sur la normalisation, de réfléchir sur les sous-jacents (non-technique) de la motivation que les parties peuvent apporter au débat.

Cela dit, ici, est une réponse directe à la question d'origine :)

Il est utile de penser à votre base de données composée d'une conception de base qui est aussi proche que possible d'une logique de conception -- normalisé et contraint, -- et l'extension de la conception que les adresses d'autres problèmes comme stable interfaces d'application et de performance.

Vous devriez vouloir contraindre et de normaliser votre modèle de données central, en raison de ne pas faire des compromis fondamentaux de l'intégrité des données et de toutes les règles / les hypothèses votre système est en train d'être construite. Si vous laissez ces questions s'éloigner de vous, de votre système de merde assez rapide. Test de base de votre modèle de données, par rapport aux exigences du monde réel et des données, et l'itération comme un fou jusqu'à ce qu'il fonctionne. Cette étape va se sentir beaucoup plus comme la clarification des exigences de la construction d'une solution, et il se doit. Utiliser la base du modèle de données comme une fonction de forçage pour obtenir des réponses claires sur ces questions de conception pour toutes les personnes impliquées.

Compléter votre base de données de modèle avant de passer à l'étendue du modèle de données. L'utiliser et de voir jusqu'où vous pouvez obtenir avec elle. En fonction de la quantité de données, le nombre d'utilisateurs et les modes d'utilisation, vous ne pouvez jamais besoin d'une extension du modèle de données. Voir jusqu'où vous pouvez obtenir avec une indexation plus les 1.001 liées à la performance des boutons que vous pouvez activer dans votre SGBD.

Si vous appuyez sur la performance, des capacités de gestion de vos bases de données, alors vous devez regarder à l'extension de votre modèle de données d'une manière qui ajoute la dénormalisation. Remarque ce n'est pas sur la dénormalisation de base de votre modèle de données, mais plutôt d'en ajouter de nouvelles ressources pour gérer la denorm de données. Par exemple, si il y a un peu énorme de requêtes qui écrasent les performances de votre, vous pouvez ajouter un peu de tableaux qui précalculer les données de ces requêtes produirait-pour l'essentiel, avant l'exécution de la requête. Il est important de le faire d'une manière qui maintient la cohérence de la dénormalisée de données avec la base (normalisée) des données. Par exemple, dans le SGBD est qui les prennent en charge, vous pouvez utiliser une VUE MATÉRIALISÉE pour faire l'entretien de la denorm de données automatique. Si votre SGBD n'ont pas cette option, alors peut-être que vous pouvez le faire par la création de déclencheurs sur les tables où les données sous-jacentes existe.

Il y a un monde de différence entre sélectivement la dénormalisation une base de données cohérente , de manière à traiter avec un portrait réaliste de la performance défi contre seulement d'avoir une faiblesse des données de conception et de l'utilisation de la performance comme une justification.

Quand je travaille avec de faible à moyen connu de la base de données des personnes et des développeurs, j'insiste sur le fait qu'ils produisent absolument normalisé de conception ... puis plus tard peut impliquer un petit nombre de personnes plus expérimentées dans une discussion sélective de la dénormalisation. La dénormalisation est plus ou moins toujours de mauvais dans votre base de données modèle. À l'extérieur de la base, il n'y a rien de mal avec la dénormalisation si vous le faites dans une et de manière cohérente.

En d'autres termes, la dénormalisation à partir d'une conception normale pour celle qui en préserve la normale tout en ajoutant un certain nombres dénormalisés -- qui traite de la réalité physique de vos données tout en préservant l'essentiel de sa logique -- c'est bien. Des dessins qui n'ont pas de base de la conception normale -- qui ne devrait même pas être appelé de-normalisée, parce qu'ils n'ont jamais été normalisé en premier lieu, parce qu'ils n'ont jamais été consciemment conçu de façon disciplinée, ne sont pas beaux.

Ne pas accepter la terminologie qui un faible, indisciplinés, le design est un "anormale" de la conception. Je crois que la confusion entre intentionnellement / soigneusement dénormalisée de données vs plaine vieux de merde conception de base de données que les résultats des nombres dénormalisés de données parce que le concepteur était un imprudente idiot est à l'origine de nombreux débats au sujet de la dénormalisation.

Answer 3

Dénormalisation de l'signifie normalement une certaine amélioration dans la recherche de l'efficacité (sinon, pourquoi le faire à tout), mais à un coût énorme dans la complexité de la validation des données en cours de modification (insert, update, parfois même de les supprimer) des opérations. Le plus souvent, le supplément de complexité est ignoré (parce que c'est trop damnés dur à décrire), conduisant à de fausses données dans la base de données, ce qui n'est souvent pas détectée jusqu'à ce que plus tard - comme quand quelqu'un est d'essayer de déterminer pourquoi l'entreprise a fait faillite et il s'avère que les données ont été auto-incompatible, car il était anormale.

Je pense que le mantra devrait aller "normaliser l'exactitude de l'éliminer seulement lorsque la haute direction propose de donner à votre travail à quelqu'un d'autre", à quel point vous devez accepter l'occasion d'aller à de nouveaux pâturages, puisque le travail risque de ne pas survivre aussi longtemps que vous le souhaitez.

Ou de "dénormaliser seulement lorsque la direction vous envoie un courriel qui vous exonère de la pagaille qui sera créé".

Bien sûr, cela suppose que vous êtes sûr de vos capacités et de la valeur à la société.

Answer 4

Les Mantras presque toujours trop simplifier la question. C'est un cas au point.

Les avantages de la normalisation sont plus que purement théorique ou esthétique. Pour tout départ à partir d'une forme normale pour 2FN et au-delà, il y a une mise à jour de l'anomalie qui se produit lorsque vous ne suivez pas la forme normale et qui s'en va lorsque vous suivez bien la forme normale. Départ de 1FN est une toute autre boîte de pandore, et je ne vais pas traiter ici.

Ces anomalies de mise à jour tombent généralement dans l'insertion de nouvelles données, la mise à jour de données existantes, et la suppression de lignes. Généralement, vous pouvez travailler votre chemin autour de ces anomalies par clever, difficile de programmation. La question est alors a l'avantage de l'utilisation habile, rusé programmation vaut le coût. Parfois, le coût est de bogues. Parfois, le coût de la perte de la capacité d'adaptation. Parfois, le coût est en fait, croyez-le ou pas, les mauvaises performances.

Si vous apprenez les différentes formes normales, vous devez tenir compte de votre apprentissage incomplet jusqu'à ce que vous comprenez l'accompagnement de la mise à jour de l'anomalie.

Le problème avec "dénormaliser" comme ligne directrice, c'est qu'il n'a pas à vous dire quoi faire. Il ya des myriades de façons d'éliminer une base de données. La plupart d'entre eux sont malheureux, et c'est de la mettre charitablement. L'un des plus bête des moyens est de simplement éliminer une étape à la fois, à chaque fois que vous voulez accélérer certains requête particulière. Vous vous retrouvez avec un fou méli mosh qui ne peut être compris sans connaître l'historique de l'application.

Beaucoup de dénormalisation des mesures qui "semblait être une bonne idée à l'époque" la plus tard pour être de très mauvais coups.

Voici une meilleure solution, lorsque vous décidez de ne pas normaliser pleinement: adopter une conception de la discipline qui donne certains avantages, même lorsque cette discipline de conception s'écarte de la normalisation. Comme un exemple, il y a conception de schéma en étoile, largement utilisé dans les entrepôts de données et data marts. C'est beaucoup plus cohérente et la discipline de l'approche que de se contenter de la dénormalisation par la fantaisie. Il y a des avantages spécifiques que vous allez sortir d'une conception de schéma en étoile, et vous pouvez les comparer avec la mise à jour des anomalies vous allez souffrir parce que la conception de schéma en étoile contredit normalisé de conception.

En général, beaucoup de gens qui conçoivent des schémas en étoile, sont la construction d'une base de données secondaire, celui qui n'a pas d'interagir avec la OLTP les programmes d'application. L'un des plus difficiles problèmes dans le maintien d'une telle base de données actuelle est ce qu'on appelle ETL (extraction, Transformation et Chargement) de traitement. La bonne nouvelle, c'est que tous ce traitement peut être recueillie dans un certain nombre de programmes, et les programmeurs d'applications qui traitent avec le normalisé de données OLTP n'avez pas à apprendre ce genre de choses. Il existe des outils pour aider avec l'ETL, et la copie de données à partir d'un normalisée de données OLTP à un schéma en étoile de données du magasin ou de l'entrepôt est bien entendu le cas.

Une fois que vous avez construit un schéma en étoile, et si vous avez choisi vos dimensions bien, nommée vos colonnes à bon escient, et en particulier choisi votre granularité bien, à l'aide de ce schéma en étoile avec un outil OLAP comme Cognos ou Business Objects s'avère être presque aussi facile que de jouer à un jeu vidéo. Cela permet à votre analystes de données pour se concentrer sur l'analyse des données au lieu d'apprendre comment le conteneur de données fonctionne.

Il existe d'autres modèles d'ailleurs schéma en étoile qui partent de la normalisation, mais le schéma en étoile mérite une mention spéciale.

Answer 5

Entrepôts de données dans un modèle dimensionnel sont souvent modélisées dans un (dénormalisé) schéma en étoile. Ces types de schémas sont pas (normalement) utilisé pour la production en ligne ou des systèmes transactionnels.

La raison sous-jacente est de la performance, mais le fait/dimensions du modèle permet également un certain nombre de caractéristiques temporelles comme les dimensions à évolution lente, qui sont réalisables dans la traditionnelle ER-style les modèles, mais peut être incroyablement complexe et lent (dates d'entrée en vigueur, tables d'archive, les enregistrements actifs, etc).