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:
- Pourquoi certaines bases de données dans la nature ne sont - elles pas normalisées?
- Pourquoi / quand une base de données normalisée doit-elle être dénormalisée ?
- 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.