Version imprimable
Bonjour,
Je vous propose un article traitant de la modélisation des données, d’une part selon notre approche classique E/R, c’est-à-dire en partant d’un MCD, et d’autre part selon l’approche de certains théoriciens du relationnel (relation universelle). Je compare et conclus en faveur du MCD. ;)
Maintenant, on peut débattre...
L’article est ici :
Modélisation Entité-Relation vs Relation universelle
N’hésitez pas à faire vos commentaires...
A bientôt,
François
Bonjour François, bonjour à tous.
En toute impartialité :D, je dis excellent travail :ccool:, merci François !
Et je partage la conclusion, le MCD a ma préférence !
Le MCD est d'un formalisme simple, efficace et applicable dans toutes les situations, je le trouve également plus facile à lire que le modèle UML par trop brouillon.
Ave Capitaine,
Grand merci à toi !
Certes, nos MCD ont notre préférence. Il est quand même intéressant de savoir ce qu’il y a derrière le miroir et à l’autre bord de la rivière...Citation:
Envoyé par escartefigue
Le MCD est quand même parfois un peu compliqué (pas trop quand même ;)), comme ici (cf. la discussion « Quel logiciel télécharger pour réaliser un MCD », le post , Figure 4) :
https://www.fsmwarden.com/loo/course...umero_cif4.jpg
Bonjour,
Cela ne vous surprendra pas si je vous signifie ma préférence pour les MCD !!! ;)
J'ai d'alleurs beaucoup travaillé sur les CIF et en particulier sur les CIF à unicité incomplète comme dans l'exemple des courses hippiques que nous propose François.
En m'appuyant sur les travaux de Ullman et Dale, et sur mes recherches personnelles, j'ai établi mon propre théorème permettant de déterminer de manière formelle les clés candidates dans le cadre d'une association n-aires avec d'éventuelles CIF, quelque soit leur complétude (et ce en limitant au maximum l'usage de l'algorithme du seau).
Cela ne fonctionnait que partiellement dans l'actuelle version 4 de Looping, mais c'est parfaitement au point dans la version 4.1 à venir :lun: !
Et pour l'exemple de François, nous avons donc les clés candidates suivantes :
- CourseId, ChevalId
- CourseId, JockeyId
- CourseId, Numéro
En tout cas, bravo à François pour cette remarquable étude... et pour sa préférence en faveur de nos MCD ! :hola:
Bonjour Paprick
il me vient une suggestion pour une prochaine version de Looping : ajouter la possibilité de modifier la couleur de tel ou tel lien (au moyen d'un clic droit et d'une fenêtre contextuelle par exemple), de sorte à faciliter la lecture du MCD dans les cas tels que celui présenté par François où les connexions se croisent.
On pourrait même étendre cette possibilité à tous les types d'objets ;)
Sorry Query Language ? J'ai ri :lol:
Bravo pour l'article !
Bonjour les lève-tôt,
Préférence ? Certes, car qui plus est, modéliser avec Looping apporte vraiment une grande satisfaction :hola: A consommer sans modération...;)Citation:
Envoyé par Paprick
Quoique... Le diagramme ULM n’est pas toujours brouillon :P :Citation:
Envoyé par Cap’taine
https://www.fsmwarden.com/images/cou...cif_4(uml).png
Merci Shepard.Citation:
Envoyé par Shepard
Une variante du Sorry Query Language, le Askew Wall, toujours par Hugh Darwen (alias Andrew Warden), in Relational Database Writings 1989-1991 :
https://www.fsmwarden.com/images/askew wall.jpg
En passant, une saine et profitable lecture : The Askew Wall par Hugh.
Au plaisir de vous revoir,
François
La modélisation Merise est orientée transactions, performance des mise à jour des données de nombreuses transactions simultanées. La modélisation Ullman, apparemment inspirée par Codd, me fait penser à la modélisation en étoile des entrepôts de données qui serait "vue" en une seule table, qui pourrait d'ailleurs être directement implémentée dans une base à stockage en colonnes comme Sybase IQ, stockage dénormalisé par essence. Je le suis complètement quand il dit que cette table (logique, conceptuelle) devient la base de données.
La relation universelle de Ullman correspond à la table de faits augmentée des dimensions (sauf que le modèle de l'exemple n'implémente pas les jours (mois, années absolus) du cours d'école, ce qui appauvrit les analyses possibles).
À noter d'ailleurs que l'exemple du cours d'école ne donne pas lieu dans la pratique à modifier les données après leur création, comme le serait une quantité de produits dans une facture ou une commande.
Cet exemple me parait bancal car on ne sait pas bien quel système fonctionnel est modélisé.
Et si c'est un système historique (puisqu'il y a la composante S de l'étudiant), les heures et les jours devraient à mon sens être deux concepts différents car les cardinalités ne sont pas les mêmes et cela surchargerait inutilement un concept unique "Temps" (dans un planning, l'heure est bien un concept, éventuellement un jour de semaine ou un numéro de jour dans le mois ou jour férié, qui sont des jours relatifs, mais pas un jour au sens date de naissance ou jour où le cour a eu lieu, qui est un jour absolu).
Pour élaborer le planning, l'étudiant ne sera pas utilisé, car un planning est agnostique de l'étudiant lorsqu'il est en train d'être élaboré. De même, la date est juste informative dans un modèle orienté transaction (bien que légalement et techniquement obligatoire), elle n'est pas conceptuellement utile, c'est pourquoi les systèmes transactionnels ne la modélisent pas en tant qu'entité mais en tant qu'attribut.
Tandis que pour un système historique, la date (absolue) devient conceptuelle, c'est pourquoi elle devient une entité et une dimension d'analyse.
C'est là la grande différence entre les modèles transactionnels et les modèles historiques : les concepts (entités conceptuelles) sont différents, et les modèles logiques MCD seront eux aussi différents. Dans un modèle de système historique au niveau logique (MCD), le fait élémentaire de l'historique (la donnée atomique indivisible) est une relation n-n et les valeurs des propriétés de la relation, d'où l'implémentation en tables dans les MPD.
J'ai vu beaucoup de concepteurs de bases de données ne pas avoir compris ceci. Résultat : ils ne font que le modèle physique MPD !
Et là, beaucoup de possibilités des logiciels comme PowerAMC pour générer des scripts de création et surtout de mise à jour sont perdues. Car la modification d'un modèle entraine la mise à jour des tables ET la migration des données présentes dans la base. De mémoire, la génération des scripts de migration des données n'est possible qu'avec un MCD (et j'ai passé pas mal de temps à comprendre ce pourquoi du comment).
Contrairement à l'idée reçue, un schéma étoile (historique) est tout aussi 3NF qu'un modèle transactionnel, simplement, les concepts sont différents.
J'ai bon ?
Bonjour Michka1111,
Merci de vous être intéressé à l’article.
Dans son exemple, Ullman limite l’univers du discours à l’agenda de l’année en cours : il ne cherche pas à modéliser un historique. En l’occurrence, c’est le principe du rasoir d’Ockham qui s’appliquerait (« Pluralitas non est ponenda sine necessitate »). Ne pas oublier que chez les théoriciens de l’époque, Ullman n’était pas seul à prendre cet exemple. Voyez An Integrated Approach to Logical Design of Relational Database Schemes de Catriel Beeri.Citation:
Envoyé par Michka1111
Les données peuvent avoir à être modifiées, cas par exemple de la table CHR, quand il y aurait bilocation des professeurs (ou des étudiants), si un trigger tel que CHR_MAJ_TRIGGER ne l’interdisait pas (situation à l’époque). Il est évident que si l’on étendait les règles de gestion, par exemple qu’un professeur puisse être remplacé en cours d’année, on commencerait à rentrer dans le problème (pas trivial !) de la prise en compte de l’historique, et là on pourrait aller très loin et s’éclater (cf. la normalisation en 6NF).Citation:
Envoyé par Michka1111
Adressez-vous à Ullman. Quant à moi, je ne me permettrai pas de toucher à ses règles de gestion !Citation:
Envoyé par Michka1111
On n’est pas ici dans un « système historique ». Je rappelle que l’univers du discours décrit par Ullman n’est pas concerné par le temps. Au demeurant, rien ne vous empêche de votre côté de faire évoluer cet univers, en prenant en compte l’aspect temporel (bien entendu dans le strict respect de la 6NF) et de proposer un article en ce sens.Citation:
Envoyé par Michka1111
Le professeur n’est pas plus concerné. Je vous renvoie à structure de la table CHR.Citation:
Envoyé par Michka1111
Dans l’article, je traite de la modélisation conceptuelle des données. Ainsi, il y a un modèle conceptuel des données (MCD), dérivable en modèle logique des données (MLD) impliquant donc le MCD, dérivable à son tour en modèle physique des données (MPD), impliquant le MLD, donc le MCD (voyez l’excellent Looping) du Professeur Bergougnoux. D’un point de vue théorique, l’aspect historique est parfaitement pris en compte par C. J. Date, Hugh Darwen et Nikos Lorentzos dans le cadre du modèle relationnel de données, mieux que je ne le ferais. Voyez leur ouvrage Temporal Data and The Relational Model, ainsi que la synthèse de Hugh Darwen : Temporal Data and The Relational Model.Citation:
Envoyé par Michka1111
Un article (rédigé en 2005) à méditer (faisant qu’à l’époque la commission SQL de l’ISO recala les propositions d’extension du langage SQL qui lui avaient été soumises) :
An Overview and Analysis of Proposals Based on the TSQL2 Approach.
Qu’ils se mettent au diapason, à la modélisation conceptuelle avec Looping !Citation:
Envoyé par Michka1111
Merci d’en fournir la démonstration. En outre, la prise en compte des données temporelles (historiques) impose de viser plus haut (6NF) !Citation:
Envoyé par Michka1111
Bon courage,
François
Citation:
Envoyé par fsmrel
Bonsoir,
Merci encore.Citation:
Envoyé par Michka1111
Ullman précise bien qu’il s’agit de faciliter, simplifier les requêtes de lecture (le terme vue universelle serait plus approprié que celui de relation universelle), et que les mises à jour se font sous le capot (là où sont les tables de base). Si la relation universelle est comme une étoile, elle est quand même singulièrement dépourvue de branches...Citation:
Envoyé par Michka1111
A vue humaine les règles sont peut-être triviales, mais certainement pas du point de vue du SGBD : on doit lui mettre les points sur les i, d’où la nécessité de commencer par la rédaction des règles de gestion aussi naïves peuvent-elles paraître, qu’on transpose ensuite dans le MCD sous forme de contraintes (identité, unicité, inclusion, exclusion, totalité, CIF, etc.). Ces règles sont là aussi pour qu’on puisse mettre en évidence les dépendances fonctionnelles (sans oublier les dépendances multivaluées, de jointure) nécessaires pour s’assurer de la normalisation. Ceci fait, on demandera à l’AGL (par exemple Looping) de traduire ces contraintes sous forme de contraintes SQL. Si le SGBD ne propose pas l’instruction CREATE ASSERTION, on se rattrapera avec des triggers (voyez les triggers CHR_MAJ_TRIGGER, CHS_MAJ_TRIGGER), quand bien même sont-ils laborieux. A défaut, la base de données sera inévitablement truffée d’erreurs dont bien sûr l’ubiquité : qu’elles tombent sous le sens, la rédaction des règles de gestion n’en reste pas moins essentielle, et comme dit mon voisin, Scripta manent, verba volant.Citation:
Envoyé par Michka1111
Cette relation universelle n’est jamais qu’une vue (au sens relationnel et SQL), cf. § 4.2 de l’article.Citation:
Envoyé par Michka1111
Dans son ouvrage auquel je fais référence, Ullman ne fait aucunement référence aux mots « star », « fact », « dimension » et autres termes connotés data warehouse : je ne vois pas en quoi sa relation universelle serait issue de la modélisation en étoile.
Certes, mais ça n’est pas l’objet de la table CHR que j’évoquais. Son prédicat est le suivant : Le cours C sera donné à l’heure H dans la salle R.Citation:
Envoyé par Michka1111
En relationnel, on modélise l’historisation des données, sous le contrôle de la 6NF, point barre.Citation:
Envoyé par Michka1111
Je vous renvoie à l’ouvrage de référence Temporal Data and The Relational Model. Remember Pluralitas non est ponenda sine necessitate.
J’ai retrouvé dans mes archives le PDF de la version 2 de l’ouvrage.Citation:
Envoyé par Michka1111
Je cite (page 9) :
Plutôt que jumeaux, autant parler de triplés. Kimball oublie le troisième élément de la bande, l’intégrité des données. A quoi bon seulement les « twin goals » si on mouline des données pourries, conséquences par exemple de la dénormalisation ? Quoi qu’il en soit, en plus de quarante ans de modélisation (MCD, MLD, MPD), j’ai toujours préconisé (quand SQL est arrivé), l’encapsulation des requêtes complexes dans des vues (qui ne sont après tout que des tables virtuelles), en sorte que celles-ci soient understandable pour les développeurs et autres utilisateurs.Citation:
Envoyé par Ralf Kimball
Quant à la performance, sujet dont j’ai eu le souci depuis près de soixante ans (ben oui), Kimball me fait l’effet de prêcher sur le mode incantatoire. De mon côté, je suis toujours resté dans les clous de la théorie relationnelle de Codd du jour où j’ai découvert celle-ci. Cela m’a permis de m’engager auprès de mes clients sur la performance des applications suite bien entendu à prototypage à mort. En matière de performance je ne crois qu’aux mesures qu’on en a faites (voyez par exemple ici). Quand les chiffres ne sont pas bons, on optimise, mais sans remettre en cause la modélisation si elle est correcte. Quand elle a été faite en dépit du bon sens, en toute incompétence, je la fais mettre à la poubelle et je prends ma casquette de concepteur pour piloter ceux qui referont les MCD.
Où sont les chiffres justifiant les allégations de Kimball ? En leur absence, je ne peux qu’être d’un total scepticisme.
Je cite encore :
Page 21 :
Et page 56Citation:
Envoyé par Ralf Kimball
Là encore, c’est le mode incantatoire qui est de mise. Depuis tout ce temps où chez mes nombreux clients (tous des grands comptes, banque, assurance, industrie, distribution, transport ferroviaire, mutuelles, etc.), j’ai modélisé, audité, soigné les bases de données mal en point, je n’ai jamais eu à violer la normalisation (3NF), ou plutôt j’ai fait normaliser les tables qui ne l’étaient pas, justement pour des raisons d’intégrité des données, voire de performance.Citation:
Envoyé par Ralf Kimball
Au fait, Kimball parle de la troisième forme normale (3NF), mais sans en donner la définition. Etrange ! (On trouvera cette définition dans mon article, mais peut-être que Kimball et moi ne parlons pas de la même chose...). Non seulement la 3NF est mise à mal, mais c’est très vraisemblablement le cas de la 2NF (pour Kimball, une table dénormalisée est forcément en 2NF ! c’est magique !) C’est certainement aussi le cas de la 1NF sur laquelle Kimball jette manifestement un voile pudique, en omettant tout simplement d’en parler, alors qu’il s’agit d’un point capital. Pour Codd (inventeur de la théorie relationnelle), une relation est dénormalisée si elle viole la 1NF (Further normalization of the data base relational model)...
Je rappelle la définition de la 1NF (cf. Database Design and Relational Theory Normal Forms and All That Jazz) :
Let relation r have attributes A1, ..., An, of types T1, ..., Tn, respectively. Then r is in first normal form (1NF) if and only if, for all tuples t appearing in r, the value of attribute Ai in t is of type Ti (i = 1, ..., n).
Je rappelle aussi qu’une une relation est une valeur de variable relationnelle (relvar).
Page 111 :
On s’en sort très bien même avec SQL, voyez ici. Si les requêtes paraissent complexes, alors, comme d’habitude, encapsulons-les dans des vues.Citation:
Envoyé par Ralf Kimball
Je suis désolé, mais je pourrais poursuivre ad nauseam la litanie de mes observations en tant que concepteur et DBA...
Bonjour,
Je ne reprendrai pas l'ensemble des arguments de Fsmrel auxquels je souscris totalement sans réserve.
Au sujet de la dénormalisation, je donnerai juste un exemple concret que j'ai vécu à de nombreuses reprises dans le monde bancaire : celui de la fusion bancaire.
Il s'agit d'une opération courante dans laquelle un banque en absorbe une autre. En ce moment, c'est le Crédit du Nord qui fusionne avec la Société Générale.
Dans un monde dénormalisé, les redondances sont légion et on retrouve le code banque dans de nombreuses tables, non seulement à sa place, dans la table des banques, mais aussi dans celles des agences, des comptes, voire des mouvements sur compte...
Et là, c'est le drame, à l'occasion d'une fusion il faut renuméroter des millions voire des milliards de lignes, là où, avec un modèle normalisé, seule une ligne dans la table des banques aurait été impactée.
On a donc non seulement de la redondance (coût de stockage et de mise à jour augmenté, risque d'incohérence), de la performance dégradée (nombre de mises à jour augmenté en très forte proportion), de la complexité augmentée (pour la même raison) et des coûts humain considérables lors des fusions ou d'opérations similaires de modification en masse.
On pourrait reprendre cet argumentaire avec la propagation des SIRET, chose assez courante elle aussi, dans le modèle de données ou tout autre cas de redondance.
Les SGBD en colonne implémentent directement et nativement la relation universelle. Les branches apparaissent comme par magie avec un MCD (ou assimilé) lorsque l'historique est modélisé en 3NF en se limitant au Faits et Dimensions d'analyse, avec le fait en relation n-n avec toutes et chacune des dimensions, comportant un enregistrement "Undefined" plutôt que NULL dans la relation. Pour ma part, je n'ai jamais vu d'intérêt à modéliser en flocon en raison du surcoût magistral que cela implique, pour un gain quasi minime pour l'utilesateur final.Citation:
Envoyé par fsmrel
Parce que j'y vois des similitudes flagrantes.Citation:
Cette relation universelle n’est jamais qu’une vue (au sens relationnel et SQL), cf. § 4.2 de l’article.
Dans son ouvrage auquel je fais référence, Ullman ne fait aucunement référence aux mots « star », « fact », « dimension » et autres termes connotés data warehouse : je ne vois pas en quoi sa relation universelle serait issue de la modélisation en étoile.
Et parce qu'il y a des plateformes "Data warehouses logiques" qui l'implémentent, par exemple chez SAP, avec ses datamarts (plus ou moins) automatiques sur les modules de gestion SAP R/3, sans parler des déjà citées SGBD en colonnes.
Effectivement, abstraction est faite des professeurs et élèves ;-)Citation:
Certes, mais ça n’est pas l’objet de la table CHR que j’évoquais. Son prédicat est le suivant : Le cours C sera donné à l’heure H dans la salle R.
Oui chef, c'est bien pourquoi les systèmes des séries temporelles ont des moteurs de technologies différentes.Citation:
En relationnel, on modélise l’historisation des données, sous le contrôle de la 6NF, point barre.
Si par historisation vous entendez star schéma, mon père disait : «*'on', pronom imbécile, qualifie celui qui l'emploie…». En effet, comme le souligne fort à propos Dr. Ralph Kimball, que gagnerez-vous à modéliser les dimensions en 6NF ? Hmm ? Juste que votre client vous fustigera parce que non seulement vous lui facturerez du temps perdu, mais surtout parce que vous aurez tous ses utilisateurs sur le dos, ainsi que tous les gens du support…
Vous avez déjà vu un éléphant caché derrière une fraise des bois ? Non ? C'était parce qu'il était bien caché ! :mouarf:
Haha, ce n'est pas parce qu'une donnée est dénormalisée qu'elle est pourrie :mrgreen: C'est seulement le modèle qu'un puriste des formes normales peut putréfier ;-)Citation:
Plutôt que jumeaux, autant parler de triplés. Kimball oublie le troisième élément de la bande, l’intégrité des données. A quoi bon seulement les « twin goals » si on mouline des données pourries, conséquences par exemple de la dénormalisation ? Quoi qu’il en soit, en plus de quarante ans de modélisation (MCD, MLD, MPD), j’ai toujours préconisé (quand SQL est arrivé), l’encapsulation des requêtes complexes dans des vues (qui ne sont après tout que des tables virtuelles), en sorte que celles-ci soient understandable pour les développeurs et autres utilisateurs.
Un schéma étoile / requête universelle respecte parfaitement l'intégrité des données, et il a l'avantage de mettre en lumière la qualité des données qui, bien que respectant l'intégrité conceptuelle des formes normales lors des transactions, vient juste fausser les statistiques ! Ex. un changement de statut social, la récente réorganisation des régions administratives…Pour corriger ces "erreurs" statistiques, des "astuces" de modélisation, tout aussi respectueuses de l'intégrité conceptuelles, sont introduites, par exemple les variations lentes des dimensions, ou les regroupements de dimensions. Là, ce n'est pas pour un simple respect de formes normal, tout aussi justifié soit-il, mais pour avoir des statistiques correctes, c'est-à-dire… crédibles et vérifiables.
Dr. Ralph Kimbal est un pionnier mondialement reconnu qui m'a changé la vie, a décuplé ma passion pour les systèmes informatique en général (la souris, c'est lui, à Palo Alto), et l'a fait naitre pour la Business Intelligence et la modélisation étoile grâce à une mission de veilleur technologique à EDF dans les années 90, renforcée par les chaudes querelles de clochers avec Dr. Bill Inmon et d'autres tout aussi reconnus, Tout comme Codd, d'ailleurs, mais je n'ai pratiqué ce dernier que pour mieux faire la BI, alors voir que vous le jettiez à la poubelle pour incompétence parce qu'il l'a pas poussé les formes normales jusqu'aux dimensions m'indiffère totalement, libre à vous.Citation:
Quant à la performance, sujet dont j’ai eu le souci depuis près de soixante ans (ben oui), Kimball me fait l’effet de prêcher sur le mode incantatoire. De mon côté, je suis toujours resté dans les clous de la théorie relationnelle de Codd du jour où j’ai découvert celle-ci. Cela m’a permis de m’engager auprès de mes clients sur la performance des applications suite bien entendu à prototypage à mort. En matière de performance je ne crois qu’aux mesures qu’on en a faites (voyez par exemple ici). Quand les chiffres ne sont pas bons, on optimise, mais sans remettre en cause la modélisation si elle est correcte. Quand elle a été faite en dépit du bon sens, en toute incompétence, je la fais mettre à la poubelle et je prends ma casquette de concepteur pour piloter ceux qui referont les MCD.
1°/ Le nombre d'exemplaires vendus de ses ouvrages sur la durée, donc au delà de l'effet de mode marketingCitation:
Où sont les chiffres justifiant les allégations de Kimball ? En leur absence, je ne peux qu’être d’un total scepticisme.
2°/ Le CA de sa société de consulting
3°/ Le nombre de CV d'experts qui se réclament de lui
4°/ Le nombre de systèmes informatiques ayant été en production reposant sur son modèle d'architecture et leur durée de maintient en condition opérationnelle
5°/ Le nombre d'éditeurs offrant des spécificités en relation avec ladite architecture et leur "notoriété" dans les domaines SGBD (même Teradata a fini par s'y mettre), ETL, Modélisation, Bussiness Intelligence (même Microsoft le cite expressément, mais c'est plus récent, je n'ai pas l'info de savoir lequel est allé chercher l'autre)
Vous avez dans ses propos la réponse…Citation:
Là encore, c’est le mode incantatoire qui est de mise. Depuis tout ce temps où chez mes nombreux clients (tous des grands comptes, banque, assurance, industrie, distribution, transport ferroviaire, mutuelles, etc.), j’ai modélisé, audité, soigné les bases de données mal en point, je n’ai jamais eu à violer la normalisation (3NF), ou plutôt j’ai fait normaliser les tables qui ne l’étaient pas, justement pour des raisons d’intégrité des données, voire de performance.
J'ai fait de même chez mes clients, de la mission de trois jours à trois ans et 50 projets sur 18 ans de bons et loyaux services en missions BI facturées, et hors l'activité de support transverse y compris auprès des commerciaux (qui ont vite compris qu'un projet BI au forfait ne se vend pas de la même manière qu'un OLTP), DP, managers N1 et N2 (en partant du haut) et bien sûr des consultants en mission ou en formation et hors l'activité de veille techno active auprès des éditeurs dont Teradata, MS, Oracle, IBM (qui m'invitaient à leurs POT), Sybase (mes killers-questions ont laissé des traces jusqu'à avoir des réponses dans les versions ultérieures, parfois des années plus tard, un manager Teradata m'a offert son livre…) dans une ENS majeure, et croyez-moi, si une modélisation R-OLAP est mal foutue, ça se voit tout de suite.
Oseriez-vous lui faire cette remarque en face-à-face ?Citation:
Au fait, Kimball parle de la troisième forme normale (3NF), mais sans en donner la définition. Etrange ! (On trouvera cette définition dans mon article, mais peut-être que Kimball et moi ne parlons pas de la même chose...).
Ouillouillouille :PCitation:
Non seulement la 3NF est mise à mal,
Tout ça parce que vous avez extrait trois phrases de cet excellent ouvrage :PCitation:
Je suis désolé, mais je pourrais poursuivre ad nauseam la litanie de mes observations en tant que concepteur et DBA...
Vous avez à mon avis raté d'œuvrer sur un projet --et un modèle de donné-- de (BUSSINESS) INTELLIGENCE :zoubi: mais si ça vous arrive, surtout faites un grand flush sur le modèle et les bonnes pratiques existants, et repartez d'une feuille blanche, faites vous vos propres bonnes pratiques, ça vaudra mieux, mais pas sûr que votre client appréciera :P
:mrgreen:Citation:
Envoyé par escartefigue
Et bien vous allez rire, c'est un problème qui n'a pas beaucoup d'impact sur le modèle d'un star schéma correctement modélisé dans les règles de l'art !!BI!! ;-) car cela juste ajoute 1/ des faits (un pacson !) 2/ des enregistrements dans les dimensions 3/ des enregistrements dans les groupements de dimensions éventuels 4/ quelques colonnes parci-parlà pour unifier les labels, gérer les hiérarchies. Avec l'ajout d'enregistrement, le modèle ne bouge pas. Seulement l'ajout de colonnes.Citation:
Au sujet de la dénormalisation, je donnerai juste un exemple concret que j'ai vécu à de nombreuses reprises dans le monde bancaire : celui de la fusion bancaire.
Il s'agit d'une opération courante dans laquelle un banque en absorbe une autre. En ce moment, c'est le Crédit du Nord qui fusionne avec la Société Générale.
Dans un monde dénormalisé, les redondances sont légion et on retrouve le code banque dans de nombreuses tables, non seulement à sa place, dans la table des banques, mais aussi dans celles des agences, des comptes, voire des mouvements sur compte...
Et là, c'est le drame, à l'occasion d'une fusion il faut renuméroter des millions voire des milliards de lignes, là où, avec un modèle normalisé, seule une ligne dans la table des banques aurait été impactée.
On a donc non seulement de la redondance (coût de stockage et de mise à jour augmenté, risque d'incohérence), de la performance dégradée (nombre de mises à jour augmenté en très forte proportion), de la complexité augmentée (pour la même raison) et des coûts humain considérables lors des fusions ou d'opérations similaires de modification en masse.
On pourrait reprendre cet argumentaire avec la propagation des SIRET, chose assez courante elle aussi, dans le modèle de données ou tout autre cas de redondance.
Et vous savez pourquoi ? Je vous le donne en mille : il n'y a qu'une seule colonne dans une seule dimension qui contient une donnée conceptuelle de filtrage ou d'affichage !!!!
Parce que en amont il y a les traitements de l'alimentation ETL qui font que la moindre redondance d'information couterait des fortunes !!!! Et puis ce ne serait pas accepté par les CP Alimentation. Et puis cela choquerait les designers des restitutions de masse, si d'aventure ça passait chez les concepteurs des univers BO ou des microcubes, les plus proches du modèle relationnel !!!!
Le gros du travail est en amont dans l'ETL mais les règles de mise en correspondances sont assez simples (c'est juste fastidieux car répétitif).
De même, puisque le modèle reste peu impacté, les restitutions, applis OLAP, Data Mining, Reporting de masse continueront d'être produits avec les nouvelles données mixées avec les autres.
C'est d'ailleurs pour cela qu'il y a des offres commerciales de datamart préconçus, notamment en RH.
On est loin du bug de l'an 2000, qui avait fait les choux gras des ENS.
Le principal est de trouver l'expression formelle du Grain des Faits qui correspond exactement, sine qua non. Mais ça, c'est un travail d'ouverture d'esprit et assorti d'un peu d'expérience, c'est accessible.
Bonsoir,
Tu réveilles en moi un vieux souvenir. Ça se passait à la SNCF, en 1993, alors que j’auditais le MCD du projet Aristote. Je croise Max, qui de son côté s’occupait de maintenir Socrate, et qui soudain gueule : « 0C7 ! Ça n’et pas possible ! » Il est vrai que c’était un garçon particulièrement méticuleux, pas un perdreau de l’année, et pourtant... Il a évidemment examiné les données (les titres de transport) et trouvé deux enregistrements dont la clé avait même valeur. Pourquoi 0C7 ? Je ne sais plus, peu importe, mais il faut déjà dire que le logiciel utilisé pour Socrate était l’antique Sabre des années cinquante, acheté à American Airlines pour qui ce fut une bouffée d’oxygène financière substantielle. Bref, il s’est trouvé qu’à un moment donné il avait été décidé d’enrichir les fichiers en y enregistrant des titres de transport créés par l’homologue anglais de la SNCF et ce fut ce qui provoqua le problème des clés en double. Que faire ? Ne plus utiliser de clés ? Heureusement, non ! (d’autres auraient été moins regardants...). Le champ clé en cause (j’ai bien dit « champ ») fut enrichi d’un octet pour accueillir une lettre, disons « S », pour SNCF et « B » pour le partenaire anglais. Et en avant pour un long travail de reprise et de validation, tu vois ce que je veux dire... En tout cas, une fois identifiée la cause de l’erreur, cela nous incita à aller écluser un demi bien mérité. https://fsmrel.developpez.com/basesr...mages/chin.pngCitation:
Envoyé par escartefigue
Bonsoir,
Oui, vous nous avez expliqué cela en long et en large. Nous sommes patients, mais le sujet concerne la théorie relationnelle (cf. le chapitre 7 de l’ouvrage de Ullman), avec la modélisation ullmanienne aboutissant à une vue universelle, à confronter avec la modélisation E/R. Les data warehouses et leurs modèles sont donc ici hors sujet.Citation:
Envoyé par Michka1111
Bis repetita non placent. Sachez que la table CHR n’a aucune raison d’être dotée d’attributs supplémentaires, sous peine d’être dénormalisée (horresco referens!) Si l’on veut par exemple faire intervenir les professeurs, le prédicat est le suivant :Citation:
Envoyé par Michka1111
Le professeur P donne le cours C à l’heure H dans la salle R.
Ce qui donne lieu à la jointure COURS https://fsmrel.developpez.com/basesr...mages/join.png CHR (encapsulée dan la vue THR_V).
De même, si l’on veut faire intervenir les étudiants, le prédicat est le suivant :
L’étudiant E suit le cours C à l’heure H dans la salle R.
Ce qui donne lieu à la jointure SHR https://fsmrel.developpez.com/basesr...mages/join.png CHR https://fsmrel.developpez.com/basesr...mages/join.png ETUDIANT (encapsulée dans la vue CHS_V).
De la même façon, on peut aussi mettre en oeuvre le prédicat :
L’étudiant E suit le cours C donné par le professeur P à l’heure H dans la salle R.
Etc.
Vous nous lassez avec votre bavardage. Appliquez la proposition numéro 7 du Tractatus de Wittgenstein et étudiez la 6NF puisque vous l’évoquez.Citation:
Envoyé par Michka1111
Grotesque et puéril.Citation:
Envoyé par Michka1111
Je ne dis pas que Kimball est incompétent, je dis qu’il n’apporte pas la moindre preuve quant à ses affirmations :Citation:
Envoyé par Michka1111
« The normalized structures must be off -limits to user queries because they defeat the twin goals of understandability and performance. »
Ce qui relève donc de l’incantation.
Quand on affirme, il faut étayer. Comme je l’ai précédemment signalé, voyez par exemple ici.
Je reprends ce que ‘ai précédemment écrit :
Et vous répondez :Citation:
Envoyé par fsmrel
Citation:
Envoyé par Michka1111
Je vous parle de la performance des bases de données, exemple : CPU Time = 00:32:23 ; I/O Time = 20:50:17.
Et pour vous la performance se mesure en nombre de livres vendus et au CA de la société ! :koi:
Par ailleurs j’ai évoqué le volet « intégrité des données », et ça n’est pas le moindre. Deux exemples parmi d’autres :
Le DI d’une grande société d’assurance me disait que si sa base de données n’était pas intègre, ça se serait su. J’ai néanmoins expertisé cette base de données, et au résultat, preuves à l’appui : 30% d’erreur... Ses équipes ont passé un an pour corriger ça...
Un autre exemple : chez une mutuelle qui nous paye nos compléments de retraite. Opération lourde, à savoir la migration de l’ancien au nouveau système. Je fis observer que l’intégrité référentielle n’avait pas été prévue, mais on me rétorqua que les contrôles avaient été prévus dans les programmes, donc pas de souci à se faire. Une fois l’opération effectuée, vous connaissez mon scepticisme, j'ai vérifié et constaté la perte de 800 000 périodes de carrière. Dommage pour les futurs retraités ainsi lésés... Panique à bord et décision fut prise de recommencer avec mise en oeuvre de cette fameuse intégrité référentielle...
Dans les deux cas, cela n’empêche certainement pas de faire de la BI, on n’est pas à 800 000 périodes de carrière près, mais mettez-vous à la place des futurs retraités...
Citation:
Envoyé par Michka1111
Bien sûr ! Une anecdote : j’ai déjà débattu de la normalisation avec l’Université. Par exemple, dans les années quatre-vingts, un de ses professeurs avait créé un système expert pour la conception des bases de données (thèse de doctorat). Ce système fut commercialisé et j’en fis l’acquisition. Dans le titre de l’ouvrage l’accompagnant, il était précisé que le système permettait de normaliser en 4NF. J’avais alors constaté que les dépendances multivaluées étaient passées sous silence, or elles interviennent dans la définition de la 4NF (voyez le paragraphe 1-3-6-6 de l’article). Je conçus un modèle où la 4NF état violée. J’en fis la démonstration lors d’une présentation du système au public : la thésarde qui m’avait pris en charge paniqua... Dans la version suivante, le terme « 4NF » fut remplacé par celui de « BCNF ». Le père du système ne m’en voulut évidemment pas et nous devînmes amis. Qui plus est, par la suite il prenait ma défense quand, par exemple un auteur contestait mes positions : « Si François te l’a dit, prends en compte ses remarques ».
Pour vos autres commentaires, sachez que j’en reste à mes acquits. Que les applications OLAP et compagnie exploitent une base de données du type gigo (garbage in, garbage out), allez vanter leurs avantages à l’assureur et à la mutuelle dont j’ai parlé (qui ne sont pas les seuls ayant dû nettoyer à grands frais leurs base de données), escartefigue me comprendra.
Pour faire court : je confirme en tous points !Citation:
Envoyé par fsmrel
Citation:
Envoyé par escartefigue
Merci Capitaine ! :P