Envoyé par
YoniBlond
Je comprends mieux comment appliquer l'héritage merci !
Cependant je ne vois toujours pas l'intérêt de cette méthode, on gagne un peu de temps et on simplifie la création de la base d'accord (quoiqu'avec la gestion des vues, ça se vaut). Mais au niveau utilisation même si les performances restent acceptables, je ne vois pas en quoi c'est un avantage ?
Je ne sais pas ce que vous voulez dire par « gagner un peu de temps ». Quoi qu’il en soit, quand on modélise les données, on ne cherche pas à gagner du temps. S’il s’agit du temps passé à modéliser, l’argument est sans objet. Mieux vaut réfléchir un peu plus lors de la conception plutôt qu’avoir à rattraper le coup une fois la base de données en production. S’il s’agit de la performance des applications, CInephil vous a expliqué que la jointure (opération relationnelle par excellence) était l’objet de tous les soins de la part des SGBDR. Si elle n’avait pas été rendue performante, ça fait trente ans que ces SGBD seraient passés à trappe. De même, quand vous dites « même si les performances restent acceptables », il s’agit là d’une appréciation subjective le plus souvent démentie par une observation objective des performances de la base de données, sous réserve bien sûr ce que ces performances aient été optimisées à l'occasion d'un prototypage ad-hoc soigné.
Maintenant, je récapépète : deux scénarios sont en compétition :
1) Mise en œuvre d’une table unique Produit, dont un sous-ensemble E1 des attributs est commun à tous les types de produits, un sous-ensemble E2 de ces attributs est spécifique à une catégorie de produits (films) et un sous-ensemble E3 est spécifique à une autre catégorie de produits (CD).
2) Mise en œuvre d’une table Produit dont les attributs sont ceux du sous-ensemble E1, accompagnée d’une table Film dont les attributs sont ceux du sous-ensemble E2 et d’une table CD dont les attributs sont ceux du sous-ensemble E3. Les tables Film et CD sont issues d’une spécialisation de l’entité-type Produit au niveau conceptuel.
Je pense que vous avez compris l’intérêt des vues construite à partir de ces tables : indépendance vis-à-vis du modèle sous-jacent. Que vous persistiez dans votre vision mono-table ou que vous vous rangiez à l’avis de CinePhil, dans les deux cas vous mettez en œuvre une vue ProduitFilm pour que l’utilisateur (programme ou terminaliste) ait une vision « Film » des produits et une vue ProduitCD pour que ce même donc utilisateur ait une vision « CD ». Sous le capot, dans le premier cas, les vues correspondent à une projection/restriction (SELECT attr1, attr2, ... WHERE IdType = type) alors que dans le 2e cas, il s’agit d’une jointure naturelle entre les tables Produit et Film d’une part, Produit et CD d’autre part).
D’un point de vue fonctionnel, grâce au vues, il n’y a donc pas de différence, tant mieux pour l’utilisateur final. Si l’on passe au niveau physique, la différence est pour le moins radicale, et seul un prototypage des performances permettra de comparer la rapidité d’exécution des requêtes (sans oublier que certaines d’entre elles peuvent ne concerner que la partie spécifique des produits, auquel cas le système n’aura pas besoin d’effecteur de jointure). Mais un problème préoccupant apparaît quand on utilise une seule table Produit dans laquelle sont mélangés films et CD : à moins d’utiliser des valeurs par défaut du type « sans objet » quand tels sous-ensembles d'attributs (à savoir E2 ou E3) ne sont pertinents que pour tel type de produit, les marques « NULL » vont envahir la table Produit et à chaque instant on risque l’accident, car la présence du bonhomme NULL peut nous faire prendre des vessies pour des lanternes. En plus, NULL ne permet pas aux optimiseurs des SGBDR de s’exprimer pleinement.
Au niveau physique, il y a aussi le problème de la volumétrie, qui a une incidence en termes d’organisation et de coût financier. En ce sens, prenons l’exemple d’un organisme qui suit les entreprises et leurs salariés. Supposons que l’on ait un million d’entreprises (table Entreprise) pour dix millions d’individus (table Individu). Supposons que le nombre d’octets nécessaire soit le même pour constituer une ligne Entreprise ou une ligne Individu, disons 200 octets, dont une quarantaine correspondent aux attributs communs. A peu de choses près, la consommation en espace est de l’ordre de 4 gigaoctets si l’on n’utilise qu’une table et 2,2 gigaoctets, soit près de deux fois moins si l’on a trois tables. Est-ce intuitif ? L’écart peut devenir plus important quand le nombre d’octets spécifiques est plus important dans le cas des entreprises. Il faut aussi tenir compte de l’occupation des index, etc., etc.
Vous me direz que 4 GO ou 2 GO, ça n’est pas grand-chose. Mai si on utilise plusieurs fois le même scénario dans la base de données, ça peut devenir préoccupant. Et puis les productions informatiques — qui courent après le temps — préfèrent gérer plusieurs petites tables qu’une grosse (parallélisation des tâches de service, telles que sauvegardes et réorganisations).En vrac, sont encore à prendre en compte certains effet secondaires, tels que les phénomènes de contention (verrouillage) plus fréquents avec une table unique.
Mais bon, ce ne sont que des considérations d’ordre physique et vous préférerez en revenir au niveau sémantique. Vous observerez dans le MCD ci-dessous, que la version dans laquelle l’entité-type Personne est « repliée » (version « Sans héritage », souffre de certains défauts par rapport à la version dans laquelle Entreprise et Individu sont mis en évidence (version « Héritage »). Par exemple, comment prendre en compte le fait qu’une entreprise emploie au moins un individu ? Qu’un individu est nécessairement employé par une entreprise ? Qu’un individu a au moins un élément de paye ? Et au niveau tabulaire, ça devient de moins en moins jojo (par exemple, clés étrangères dont les colonnes sont marquées NULL) sans parler de la surcharge de programmation...
Both.jpg)
A vous de voir.
Héritage : utilité et performances
Répondre avec citation
.
Partager