Pourquoi de nombreuses conceptions ignorent la normalisation dans le SGBDR?

J'ai pu voir de nombreuses conceptions que la normalisation n'était pas la première considération dans la phase de prise de décision.

Dans de nombreux cas, ces conceptions comprenaient plus de 30 colonnes, et l'approche principale était de "mettre tout au même endroit"

D'après ce dont je me souviens, la normalisation est l'une des premières choses les plus importantes, alors pourquoi est-elle parfois abandonnée si facilement?

Modifier:

Est-il vrai que les bons architectes et experts choisissent une conception dénormalisée tandis que les développeurs non expérimentés choisissent le contraire? Quels sont les arguments contre le démarrage de votre conception avec la normalisation à l'esprit?

Ce qui est intéressant à propos de ce fil de questions-réponses, c'est qu'il y a en fait 3 questions. Tout le monde a répondu à une question différente, et presque personne n'a répondu à la première:

1. Pourquoi certaines bases de données dans la nature ne sont - elles pas normalisées?
2. Pourquoi / quand une base de données normalisée doit-elle être dénormalisée ?
3. Dans quelles situations est-il dangereux ou inutile de normaliser en premier lieu?

Les lecteurs avertis noteront qu'il s'agit de questions très différentes et j'essaierai d'y répondre séparément tout en évitant trop de détails. Par «trop», je veux dire que je ne pense pas que ce soit le contexte approprié pour mener un débat prolongé sur le bien-fondé de divers arguments en faveur ou contre la normalisation; Je vais simplement expliquer quels sont ces arguments, peut-être énumérer quelques mises en garde et conserver la philosophie pour des questions plus spécifiques, si jamais elles se présentent.

De plus, dans cette réponse, je suppose que la "normalisation" implique "BCNF, 3NF ou au moins 2NF" , car c'est le niveau de normalisation que les concepteurs visent généralement à atteindre. Il est plus rare de voir des conceptions 4NF ou 5NF; Bien qu'ils ne soient certainement pas des objectifs impossibles, ils se préoccupent de la sémantique des relations plutôt que de leur représentation , ce qui nécessite beaucoup plus de connaissances sur le domaine.

Donc, en avant et en haut:

1. Pourquoi certaines bases de données dans la nature ne sont-elles pas normalisées?

La réponse à cela pourrait être "parce qu'ils ne devraient pas l'être", mais faire cette hypothèse tout de suite est un travail de détective assez pisse. Nous ne ferions pas beaucoup de progrès en tant que société si nous partions toujours du principe que quoi que ce soit devrait être.

Les vraies raisons pour lesquelles les bases de données ne sont pas normalisées en premier lieu sont plus compliquées. Voici le top 5 que j'ai rencontré:

• Les développeurs qui l'ont conçu ne savaient pas ou ne comprenaient pas comment normaliser. Des preuves solides de cela se présentent sous la forme de nombreux autres choix de conception associés, comme l' utilisation de colonnes varchar pour tout ou avoir un gâchis spaghetti de noms de table et de colonne sans signification . Et je vous assure que j'ai vu de "vraies" bases de données qui sont tout aussi mauvaises que celles des articles TDWTF.

• Les développeurs qui l'ont conçu s'en fichaient ou étaient activement opposés à la normalisation par principe . Remarque, je ne parle pas ici de cas où une décision délibérée a été prise de ne pas normaliser sur la base d'une analyse contextuelle, mais plutôt d'équipes ou d'entreprises où la normalisation est plus ou moins comprise mais simplement ignorée ou rejetée par habitude. Encore une fois, étonnamment commun.

• Le logiciel est / a été réalisé en tant que projet Brownfield . De nombreux puristes ignorent ce parfaitement légitime entreprise plutôt que technique raison de ne pas normaliser. Parfois, vous ne pouvez pas réellement concevoir une nouvelle base de données à partir de zéro, vous devez vous accrocher à un schéma existant, et tenter de normaliser à ce stade impliquerait beaucoup trop de douleur. 3NF n'a pas été inventé avant 1971, et certains systèmes - en particulier les systèmes financiers / comptables - ont leurs racines encore plus loin que cela!

• La base de données était à l'origine normalisée , mais une accumulation de petits changements sur une longue période de temps et / ou une équipe largement distribuée a introduit des formes subtiles de duplication et d'autres violations de la forme normale qui était à l'origine en place. En d'autres termes, la perte de normalisation a été accidentelle et trop peu de temps a été consacré à la refactorisation.

• Une décision commerciale délibérée a été prise de ne pas consacrer de temps à l'analyse commerciale ou à la conception de bases de données et de simplement «faire les choses». Il s'agit souvent d' une fausse économie qui devient en fin de compte une forme croissante de dette technique , mais est parfois une décision rationnelle, au moins fondée sur des informations connues à l'époque - par exemple, la base de données peut avoir été conçue comme un prototype, mais a fini par être promu à la production en raison de contraintes de temps ou de changements dans l'environnement des affaires.

2. Pourquoi / quand une base de données normalisée doit-elle être dénormalisée?

Cette discussion survient souvent lorsqu'une base de données est normalisée pour commencer. Soit les performances sont médiocres, soit il y a beaucoup de duplication dans les requêtes (jointures), et l'équipe sent, à tort ou à raison, qu'elle est allée aussi loin que possible avec la conception actuelle. Il est important de noter que la normalisation améliore les performances la plupart du temps, et il existe plusieurs options pour éliminer les jointures excessives lorsque la normalisation semble fonctionner contre vous, dont beaucoup sont moins invasives et risquées que de simplement passer à un modèle dénormalisé:

• Créez des vues indexées qui encapsulent les zones problématiques les plus courantes. Les SGBD modernes sont capables de les rendre insérables ou modifiables (par exemple les INSTEAD OFdéclencheurs SQL Server ). Cela a un léger coût pour les instructions DML sur les tables / index sous-jacents, mais c'est généralement la première option que vous devez essayer car il est presque impossible de bousiller et ne coûte presque rien à maintenir. Bien sûr, toutes les requêtes ne peuvent pas être transformées en une vue indexée - les requêtes agrégées sont les plus gênantes. Ce qui nous amène au point suivant ...

• Créez des tables d'agrégation dénormalisées qui sont automatiquement mises à jour par des déclencheurs. Ces tables existent en plus des tables normalisées et forment une sorte de modèle CQRS . Un autre modèle CQRS, plus populaire de nos jours, consiste à utiliser pub / sub pour mettre à jour les modèles de requête, ce qui donne l'avantage de l'asynchronie, bien que cela ne convienne pas dans de très rares cas où les données ne peuvent pas être périmées.

• Parfois, les vues indexées ne sont pas possibles, les taux de transaction et les volumes de données sont trop élevés pour admettre des déclencheurs avec des performances acceptables et les requêtes doivent toujours renvoyer des données en temps réel. Ces situations sont rares - j'imagine qu'elles pourraient s'appliquer à des choses comme le trading à haute fréquence ou les bases de données d'application de la loi / de renseignement - mais elles peuvent exister. Dans ces cas, vous n'avez vraiment pas d'autre choix que de dénormaliser les tables d'origine.

3. Dans quelles situations est-il préjudiciable ou inutile de normaliser en premier lieu?

Il y a, en fait, plusieurs bons exemples ici:

• Si la base de données est utilisée uniquement pour les rapports / analyses. Cela implique généralement qu'il existe une base de données normalisée supplémentaire utilisée pour OLTP, qui est périodiquement synchronisée avec la base de données d'analyse via ETL ou la messagerie.

• Lors de l'application d'un modèle normalisé, il faudrait une analyse inutilement complexe des données entrantes. Un exemple de ceci pourrait être un système qui doit stocker des numéros de téléphone qui sont collectés à partir de plusieurs systèmes ou bases de données externes. Vous pouvez dénormaliser l'indicatif d'appel et l'indicatif régional, mais vous devez tenir compte de tous les différents formats possibles, des numéros de téléphone invalides, des numéros de vanité (1-800-GET-STUFF), sans parler des différents paramètres régionaux. Cela pose généralement plus de problèmes que cela ne vaut, et les numéros de téléphone sont généralement insérés dans un seul champ, sauf si vous avez un besoin commercial spécifique pour l'indicatif régional à lui seul.

• Lorsque la base de données relationnelle est principalement là pour fournir un support transactionnel pour une base de données non relationnelle supplémentaire. Par exemple, vous pouvez utiliser la base de données relationnelle comme file d'attente de messages ou pour suivre le statut d'une transaction ou d'une saga, lorsque les données principales sont stockées dans Redis ou MongoDB ou autre. En d'autres termes, les données sont des "données de contrôle". Il est généralement inutile de normaliser des données qui ne sont pas réellement des données commerciales .

• Architectures orientées services qui partagent une base de données physique. C'est un peu étrange, mais dans une véritable architecture SOA, vous devrez parfois avoir des données physiquement dupliquées car les services ne sont pas autorisés à interroger directement les données les uns des autres. Si elles arrivent à partager la même base de données physique, les données ne semblent pas être normalisée - mais en général, les données appartenant à chaque service est toujours normalisé à moins l' un des autres facteurs atténuants est en place. Par exemple, un service de facturation peut être propriétaire de l'entité de facturation, mais le service de comptabilité doit recevoir et stocker la date et le montant de la facture afin de l'inclure dans les revenus de cette année.

Je suis sûr qu'il y a d'autres raisons que je n'ai pas énumérées; ce que je veux dire, en substance, c'est qu'ils sont assez spécifiques et seront assez évidents lorsqu'ils arriveront en pratique. Les bases de données OLAP sont censées utiliser des schémas en étoile, les SOA sont censés avoir une certaine duplication, etc. Si vous travaillez avec un modèle d'architecture bien connu qui ne fonctionne tout simplement pas avec la normalisation, alors vous ne normalisez pas; de manière générale, le modèle d'architecture prime sur le modèle de données.

Et pour répondre à la toute dernière question:

Est-il vrai que les bons architectes et experts choisissent une conception dénormalisée tandis que les développeurs non expérimentés choisissent le contraire? Quels sont les arguments contre le démarrage de votre conception avec la normalisation à l'esprit?

Non, c'est BS complet et absolu C'est aussi BS que les experts choisissent toujours une conception normalisée . Les experts ne se contentent pas de suivre un mantra. Ils recherchent, analysent, discutent, clarifient et réitèrent, puis ils choisissent l'approche qui convient le mieux à leur situation particulière.

La base de données 3NF ou BCNF est généralement un bon point de départ pour l'analyse car elle a fait ses preuves dans des dizaines de milliers de projets dans le monde, mais là encore, il en va de même pour C. Cela ne signifie pas que nous utilisons automatiquement C dans chaque nouveau projet. Les situations réelles peuvent nécessiter certaines modifications du modèle ou l'utilisation d'un modèle différent. Vous ne savez pas jusqu'à ce que vous soyez dans cette situation.

L'hypothèse intégrée à la question et dans certaines réponses est que la normalisation est également une bonne conception de base de données. Ce n'est en fait souvent pas le cas. La normalisation est un moyen d'atteindre un ensemble particulier d'objectifs de conception et une exigence si vous comptez beaucoup sur la base de données pour appliquer des "règles métier" sur les relations entre les éléments de données.

La normalisation vous offre quelques avantages clés:

1. Minimise la quantité de données redondantes.
2. Maximise la mesure dans laquelle les mécanismes d'intégrité intégrés de la base de données (contraintes de clé étrangère, contraintes d'unicité) peuvent être exploités pour garantir l'intégrité des données.
3. Réduit le nombre de colonnes par ligne, augmentant l'efficacité d'E / S dans certains cas. Les rangées larges prennent plus de temps à récupérer.

Cela dit, il existe de nombreuses raisons valables pour dénormaliser:

1. Les performances, en particulier pour l'analyse, peuvent être réduites à néant par la normalisation. Pour l'analyse par rapport aux bases de données relationnelles, les modèles dimensionnels dénormalisés sont l'approche standard.
2. L'avantage de l'application de l'intégrité des données à l'intérieur de la base de données commence à décliner. Comme le développement se concentre de plus en plus sur le niveau intermédiaire orienté objet qui applique souvent les règles métier, la dépendance aux contraintes relationnelles dans la base de données est moins importante.
3. Comme d'autres l'ont mentionné, la normalisation compliquera les requêtes nécessaires pour récupérer les données pertinentes.

Il n'est pas certain que la normalisation soit un signe de bonne conception. Dans certains cas, la normalisation est un artefact d'une époque où l'espace de stockage était limité et où une grande partie de la responsabilité du codage des règles métier résidait dans la base de données (pensez aux applications client-serveur à deux niveaux avec la plupart sinon la totalité de la logique métier dans procédures stockées). Il se pourrait bien que de nombreux projets s'éloignent de la normalisation basée sur de bonnes décisions architecturales plutôt que sur une mauvaise compréhension des principes de conception des bases de données.

L'article de Jeff Atwood référencé dans les commentaires ci-dessus fournit une bonne discussion détaillée - "Peut-être que normaliser n'est pas normal" .

1. Beaucoup de développeurs ne connaissent pas ou ne se soucient pas de la normalisation, ni de la modélisation des données ou de la base de données.
2. Pour certains emplois, ce n'est vraiment pas important.
3. Parfois, il y a une très bonne raison de dénormaliser, par exemple pour faire fonctionner une charge de travail particulièrement difficile.
4. Les concepts de bases de données relationnelles sont récemment moins à la mode qu'ils ne l'étaient dans les années 1990 et 2000. Les développeurs ont tendance à être influencés par la mode, même s'ils se disent très rationnels. Inutile de discuter du goût.

La normalisation est également, historiquement, un territoire de quasi-argumentation religieuse, j'hésite donc à en dire beaucoup plus.

Dans les grands projets, et spécialement dans les mainframes, ce n'est pas le cas. En fait, si vous recherchez des sites d'emploi, vous verrez plusieurs postes de modélisateurs de données. De plus, avoir plusieurs colonnes sur une même table ne va pas à l'encontre de la normalisation. Néanmoins, votre observation est valable pour certains projets.

La conception de bases de données est l'une des compétences requises pour construire des systèmes qualité. Cela dit, certains développeurs ne connaissent pas suffisamment la conception de bases de données et sont toujours affectés à la tâche de modélisation des données et de conception de bases de données. Certains projets ignorent même la modélisation des données. L'accent est mis sur de nombreux projets principalement sur le codage et la conception frontale.

Un autre facteur de mauvaise conception de la base de données est le fait que la normalisation n'est pas un sujet trivial spécialement quand il s'agit de 4e NF, 5e NF, etc. La plupart des livres que j'ai vus ne pouvaient pas bien expliquer clairement ces formes. Il y a généralement de mauvais exemples et trop de théorie. Cela rend le sujet moins populaire qu'il ne devrait.

Les erreurs dans la conception de la base de données sont difficiles à trouver, sauf si vous les recherchez ou si vous les rencontrez pendant les tests. Le fait de n'avoir aucun standard pour la qualité de conception de la base de données rend les erreurs plus probables.

Ajoutez à cela le fait que certains projets ne suivent pas une méthodologie de développement rigoureuse (qui favorise la conception de bases de données), en conséquence, les responsabilités se mélangent et les tâches se perdent entre l'analyste métier, les développeurs et les DBA. Les développeurs parlent en OO et UML où les DBA parlent en DD et certains en ERD et probablement beaucoup ne reçoivent pas UML ou OO. En bref, le manque de connaissances, le manque de bonnes ressources claires, le manque d'un langage unifié pour décrire les données et le manque de méthodologie sont tous à blâmer.