Discussion :

[ngwiamfr]

Bonjour A tous.

Je suis sur un projet ou je veux utiliser l'héritage, mais j'ésite sur la méthode de transformation MCD-MLD à choisir.
quelqu'un pourrait-il me donner des détails sur les avantages et les inconvénients de chacune des solutions de transformation de l'héritage du MCD au MLD?

Merci d'avance!

A partir, par exemple, du MCD suivant


Il existe 4 possibilités de transformation.
1) Duplication de la clé primaire


2) Duplication complète du contenu du sur-type dans les sous-types


3) Suppression du sur-type et migration complète dans les sous-types


4) Suppression des sous-types et migration complète dans le sur-type


Chacune des solutions a des avantages et des inconvéniernts dépendant
- de l'existence d'autres relations sur le sur-type ou les sous-types
- du nombre de propriétés dans le sur-type ou les sous-types
- de l'activité en mise à jour / consultation

[fsmrel]

Solution 1

Pas de redondance inutile de données, ce qui est précieux quand les tables commencent à atteindre des volumétries respectables.

Regroupement en un lieu unique des données communes (ce qui facilite la mise en œuvre des développements). Ceci vaut non seulement pour le contenu de la table ASSURE elle-même, mais aussi pour les tables satellites : Si un assuré peut avoir plusieurs adresses, vous serez amené à mettre en œuvre une entité-type faible ADRESSE_ASSURE (identifiée relativement à ASSURE, car propriété multivaluée de celle-ci). On aura donc une seule table ADRESSE_ASSURE.

Des problèmes de contention peuvent se produire si les mises à jour de la table ASSURE (voire ADRESSE_ASSURE) sont importantes pour la partie commune.

Solution 2

Redondance inutile de données : cette redondance est à contrôler, ce qui nécessite du développement, des ressources pour rien et conduit à une validité aléatoire du contenu de la base de données. Si les volumétries sont importantes et si vous voulez vous fâcher avec la Production, allez-y. Attention aussi à la duplication des traitements.

Les problèmes de contention sont accrus.

Solution 3

Comme dans le cas de la solution 1, pas de redondance de données. Qui plus est, concernant les données communes (nom, adresses, téléphones) la volumétrie de la table PARTICULIER et celle de la table ENTREPRISE ne se cumulent pas : table spaces et index moins volumineux (contrairement à ce qui se passe avec la solution 1). Si l’on n’a pas à traiter ensemble les données PARTICULIER et ENTREPRISE (transactions différentes), la séparation devient intéressante.

Si comme dans le cas de la solution 1, on est amené à mettre en œuvre des entités-types pour les adresses et autres, on multiplie cette fois-ci le nombre de tables : ADRESSE_ASSURE se dédouble en ADRESSE_PARTICULIER et ADRESSE_ENTREPRISE, même chose au besoin pour les téléphones, etc.

Les problèmes de contention pouvant de produire avec la solution 1 sont plus réduits, dans la mesure où ils pourraient concerner des particuliers entrant en collision avec des entreprises partageant les mêmes pages physiques.

Solution 4

A exclure. On produit un big mac, un gros pâté hétérogène où se complait l’ennemi, à savoir les valeurs nulles. Vu par le petit bout de la lorgnette, le seul avantage est que les jointures n’ont plus lieu d’être : l’opérateur de jointure est quand même l’opérateur relationnel par excellence et ne pose pas de problème particulier.


Conclusion

Personnellement, j’ai toujours appliqué soit la solution 1, soit la solution 3. La première parce que la gestion des données communes est plus simple et le maillage des données mieux maitrisable. La troisième parce que les tables sont unitairement moins volumineuses et sont moins sujettes à contention. J’oublie sans doute d’autres paramètres, mais d’aucuns réviseront et complèteront ce premier jet, espérons-le.

[ngwiamfr]

Merci fsmrel,

Excuse moi pour le temps mis à répondre, mais j'étais un peu bousculé.

L'une de mes préoccupations se situe au niveau de l'utilisation pratique de l'héritage. Prenons l'exemple suivant:

http://www.developpez.net/forums/att...1&d=1173199322

Si je veux opter pour la solution 1 ("ID Structure" sera dupliqué dans les tables enfants "SANTE","SECURITE" et "EDUCATION":

Comment faire pour retrouver, à partir d'un élément de la table "MATERIEL", la structure correspondante? Comment savoir dans quelle table enfant chercher?

Je ne sais pas si je me fait bien comprendre?
En fait je n'arrive pas encore à bien me représenter l'utilisation pratique de l'héritage.

Please help!

[ngwiamfr]

PS: Comment faire pour intégrer directement des images dans mes réponses?

[fsmrel]

Hello ngwiamfr,


L’héritage a de nombreux avantages et quelques défauts... En l’occurrence, le problème que vous posez est celui de l’asymétrie : une classe de requêtes est favorisée par rapport à une autre.

Autant il est facile de connaître les matériels pour une structure donnée (par exemple un dispensaire), autant l’affaire se corse (chef-lieu Ajaccio) quand il s’agit de répondre à des questions du genre de celle que vous posez : quelle structure possède telle imprimante. Il est fréquent d’injecter une redondance au niveau du surtype (à savoir STRUCTURE) pour justement connaître la nature du sous-type concerné.

Selon ce scenario, on ajoute une propriété Type_Structure dans l’entité-type STRUCTURE, propriété pouvant prendre une des valeurs 1, 2, 3 (ou tout autre triplet de valeurs que vous voulez) pour connaître le type de structure : SANTE, SECURITE, EDUCATION.

Du fait de cette redondance, la solution est moyennement satisfaisante : on prend le risque de confondre SANTE et SECURITE. En outre, les traitements se font en deux temps.