Discussion :

[fsmrel]

Bonjour Paprick,

C’est encore moi avec mes problèmes de ON DELETE CASCADE...
C’est bon pour les associations entre classes. Mais il y a le cas des sur-types (cf. page 238 de ton ouvrage) : quand je supprime une personne, qu’il s'agisse d’un administratif ou d’un enseignant, je ne la supprime pas qu’à moitié : le métabolisme doit pouvoir s’exprimer pleinement, en une seule fois, donc une case à cocher sur le lien porteur de la flèche serait la bienvenue...

[Paprick]

Bonsoir,

C’est encore moi avec mes problèmes de ON DELETE CASCADE...
C’est bon pour les associations entre classes. Mais il y a le cas des sur-types (cf. page 238 de ton ouvrage) : quand je supprime une personne, qu’il s'agisse d’un administratif ou d’un enseignant, je ne la supprime pas qu’à moitié : le métabolisme doit pouvoir s’exprimer pleinement, en une seule fois, donc une case à cocher sur le lien porteur de la flèche serait la bienvenue...

Actuellement, l'option est proposée au niveau des liens des sous-types, mais il est vrai que l'on a du mal à imaginer que l'on puisse garder une des classes fille si la la classe mère est supprimée...
Et si je respecte la logique de décomposition d'un héritage (cf. pages 217 et 220 du livre), l'option doit effectivement être prise côté classe mère...
Certes, on arrive au même résultat, surtout si l'on prend l'option de valider par défaut les CASCADE dans les propriétés, mais je suis d'accord que c'est plutôt le lien vers la classe mère qui doit centraliser le choix...
Modif en perspective pour la version 4.1 !

[escartefigue]

Bonjour à tous

Une suggestion de confort : faciliter le redimensionnement des blocs de texte libre.

Je m'explique : j'ai pour habitude d'ajouter une zone de texte dans mes MCD pour y inclure l'URL du fil de discussion quand il s'agit d'une discussion issue du site developpez.net. Mais, quel que soit le zoom utilisé, j'ai beaucoup de mal à positionner la souris pour que le pointeur change de forme signifiant l'activation du redimensionnement. Le moindre mouvement fait perdre cette possibilité.

[fsmrel]

Bonjour Paprick,

Dans le MCD ci-dessous, on traite de marchandises selon des règles de gestion dont celles qui m’intéressent sont les suivantes :

RG01 – Une marchandise relève d’une famille de marchandises et une seule.
RG02 – Il y a quatre familles de marchandises : Produits d’origine animale, Végétaux et produits végétaux, Produits destinés à l'alimentation animale, Animaux vivants.
RG03 – Chaque marchandise est composée de lots, lesquels relèvent tous donc d’une seule famille, celle de la marchandise qu’ils composent.
RG04 – Chaque lot fait référence à une (occurrence de) nomenclature.
RG05 – Chaque (occurrence de) nomenclature fait référence à une des quatre familles ci-dessus.
RG06 – La famille dont relève un lot et la famille de la nomenclature référencée par ce lot doivent être la même.

Dans mes tentatives de modélisation avec Looping, j’avais notamment pensé au MCD suivant, mais il l’a invalidé...:



Ainsi, Looping accepte qu'un sous-type soit identifié relativement à une nomenclature, mais refuse que l'identifiant du lot participe à la clé primaire de la table inférée du sous-type :  

LotViande = (#NomenclatureId, ***CLE_INCOMPLETE***, #(#MarchandiseId, LotId));
LotVegetal = (#NomenclatureId, ***CLE_INCOMPLETE***, Etat, #(#MarchandiseId, LotId));
LotAnimalVivant = (#EspeceId, ***CLE_INCOMPLETE***, Puce, Sexe, #(#MarchandiseId, LotId));
LotOrigineAnimale = (#NomenclatureId, ***CLE_INCOMPLETE***, #(#MarchandiseId, LotId));

Par curiosité j’ai récupéré dans mon grenier une vieille version de PowerAMC et lui ai proposé le même MCD. Sans sourciller, comme clé primaire SQL d’un lot il propose le triplet : {MarchandiseId, LotId, NomenclatureId}.

Qui a raison ? Looping ? AMC ? A y regarder de près, sémantiquement et ontologiquement parlant (pardon pour ces gros mots), un lot spécialisé reste un lot et un sous-type n’est pas une association entre surtype et nomenclature.

Avantage donc à Looping ! Mais alors que faire pour qu’il ne rouspète plus ? J’ai finalement monté la barre d’un cran, en procédant du coup à la généralisation des nomenclatures et en établissant l’association non plus entre un sous-type de lot et « sa » nomenclature, mais carrément entre les surtypes Lot et Nomenclature. Je ne sais pas si j’ai bien fait, mais je trouve en tout cas que le montage est cohérent :

Pièce jointe 632721

Paprick, ton avis ?  

Discussion à l’origine de ce message : Demande d’aide modélisation héritage. 

A noter que la règle de gestion RG06 fait l’objet d’un trigger de validation cf. post #25 de la même discussion.

A noter encore que pour contrôler la contrainte d’exclusion entre sous-types, il y a d’autres triggers à pondre. A titre d’exemple, j’en ai codé un (cf. à nouveau le post #25), mais ce trigger est un bourrin et il y a certainement beaucoup mieux. Si un spécialiste SQL passe par ici...

En tout cas, merci à Looping de m’avoir fait prendre conscience que j’étais sémantiquement à côté de la plaque (tout comme AMC)...

Et en route pour Looping 4.1 !

[Paprick]

Bonjour François,

Sacré cas d'école que tu nous poses là !
Sur un plan sémantique, je te rejoints totalement et je pense que AMC a une façon bien cavalière d'établir cette clé primaire.
Je vais pour ma part me positionner sur un plan purement conceptuel.
En terme d'héritage, il existe 2 façons de modéliser les choses : spécialisation ou généralisation.

SPECIALISATION
Les sous-types viennent compléter les informations du sur-type dont ils récupèrent l'identifiant ; par conséquent, ils n'ont pas leur propre identifiant et c'est à ça qu'on les reconnait.
Dans ton exemple, les sous-types ont leur propre identifiant récupéré via l'identification relative : Looping ne va donc pas considérer dans la clé primaire les identifiants du sur-type et va les laisser en simple clé étrangère.

GENERALISATION
Les sous-types ont leur propre existence, et les informations du sur-type viennent compléter celles du sous-type ; par conséquent, ils ont leur propre identifiant et c'est à ça qu'on les reconnait.
Comme indiqué ci-dessus, c'est le cas dans ton exemple.

AMC fait une sorte de mélange des deux en considérant que la clé primaire est composée des identifiants du sur-type et du sous-type... Conceptuellement, c'est très ambigu et cette ambiguïté se retrouve au niveau sémantique comme tu l'as très bien signalé. Par ailleurs, ce faisant, AMC ne distingue pas les notions de spécialisation et de généralisation.

Revenons donc à nos moutons (en l'occurence, ton exemple) : nous sommes donc dans le cas d'une généralisation. Les sous-types ont leur propre identifiant, et si cet identifiant se limite à l'identifiant relatif, il n'est plus unique (compte-tenu de la cardinalité 0,n qu'il y a de l'autre côté de l'association). Par conséquent, Looping considère la clé comme incomplète.

Alors, Looping peut obtenir le même résultat que AMC (si c'est vraiment ce que l'on veut) : il faut alors décomposer l'héritage avec des associations 0,1--(asso)---1,1(R), et là on voit bien que sémantiquement, ça devient contestable, et l'héritage est très ambigu...

Certes, on pourrait aussi imaginer l'équivalent d'un (R) sur le lien du sous-type dans le cas d'une généralisation... techniquement, c'est facile à faire (simple case à cocher), mais ça ne me plait pas...
Mais après tout, ça reste la responsabilité du concepteur... Looping n'est que l'exécutant !

Qu'en penses-tu ?

[fsmrel]

Ave Paprick,

Sur un plan sémantique, je te rejoints totalement et je pense que AMC a une façon bien cavalière d'établir cette clé primaire.

On est bien en phase.

Revenons donc à nos moutons (en l'occurence, ton exemple) : nous sommes donc dans le cas d'une généralisation. Les sous-types ont leur propre identifiant, et si cet identifiant se limite à l'identifiant relatif, il n'est plus unique (compte-tenu de la cardinalité 0,n qu'il y a de l'autre côté de l'association). Par conséquent, Looping considère la clé comme incomplète.

On est toujours d’accord et comme je l’ai précédemment souligné, étant donné Looping se positionne au niveau sémantique, la seule conclusion qui s’impose est qu’il a totalement raison.

Alors, Looping peut obtenir le même résultat que AMC (si c'est vraiment ce que l'on veut) : il faut alors décomposer l'héritage avec des associations 0,1--(asso)---1,1(R), et là on voit bien que sémantiquement, ça devient contestable, et l'héritage est très ambigu.

Clairement, on passerait de la bonne logique à une tambouille où l’on mélangerait ketchup et chantilly, beurk ! 

A propos de tambouille, en fouillant encore dans mes archives, j’ai récupéré une discussion dans laquelle PostgreSQL traite de l’héritage et confond allègrement être et avoir, c’est-à-dire que si pour nous une ellipse peut être un cercle (et un cercle est une ellipse), PostgreSQL considère qu’une ellipse peut avoir un cercle (et un cercle appartenir à une ellipse), ce qui sémantiquement n’est quand même pas pareil… Soit dit en passant, je me rends compte que, tant bien que mal, j’avais réussi à me servir de ce SGBD (y-compris pour faire de la vraie spécialisation)...

Certes, on pourrait aussi imaginer l'équivalent d'un (R) sur le lien du sous-type dans le cas d'une généralisation... techniquement, c'est facile à faire (simple case à cocher), mais ça ne me plait pas...

Ça ne me plaît pas non plus ! Ne touche à rien ! C’est cette histoire de clé incomplète qui m’a troublé et forcé à réfléchir pour en arriver au MCD que j’estime cette fois-ci aller dans le bon sens, en procédant à la généralisation des nomenclatures et en établissant un lien classique entre Lot et Nomenclature. Si tu avais mis en oeuvre la case à cocher que tu évoques, je n’en serais pas arrivé à ce dernier MCD (qui reste encore à valider à partir de l’ensemble des règles de gestion) :



J’en conclus, que Looping est loin devant AMC et PostgreSQL quant à la prise en compte des aspects sémantiques et ontologiques et qu’il ne doit surtout pas régresser. On trouvera toujours des pinailleurs, des esprits chagrins pour (tenter de) démontrer que tu as tort, mais peu importe les sophismes dont ils devront faire usage. Fermez le ban !