Discussion :

[informer]

Bonjour à tous,

Pour illustrer ma question l'exemple suivant

Une personne peut être prospect ou client -> exclusivité totale

On pourrait donc créer l'entité personne et deux autres entités filles
Prospect
Client
Qui hériteraient de personne.

Donc un fine dans le MPD, il y aurait 3 entités

L'alternative ne pourrait-elle pas être une entité personne et une entité typeClient avec pour cet exemple deux itérations
Prospect
Client

Merci par avance pour toute contribution

[fsmrel]

Bonsoir informer,

L’héritage, ou plutôt la spécialisation / généralisation des entités-types permet de doter telle sous-entité-type d’attributs (propriétés) qui lui sont propres, et d’entretenir avec d’autres entités-types des relations sans objet pour toute autre sous-entité-type soeur. Ainsi, CLIENT a des propriétés telles que les conditions tarifaires, la date de signature du contrat, etc. que n’a pas sa sœur PROSPECT, et elle entretient avec COMMANDE, FACTURE, etc. des relations qui ne concernent pas PROSPECT. De même, si PROSPECT est en relation avec MODE_DE_PROSPECTON, il est évident que c’est sans objet pour CLIENT.

Au stade SQL, mieux vaut trois tables propres, avec des colonnes NOT NULL, qu’une seule table bien engraissée de NULL nuisibles (notamment dans le cas des clés étrangères !) ou de « blancs » inutiles et coûteux.

[informer]

Bonjour fsmrel

Merci pour ta réponse.

Tu pointes les limites de la deuxième solution. Mais imaginons maintenant le cas suivant concernant une entité générique matériel et ses entités filles
Clavier
Écran
Souris
Si je modélise avec un héritage j'ai donc 4 tables.

Quels sont les impacts sur le code SQL si je dois ajouter une nouvelle entité pour clé wifi par exemple et à chaque fois que j'ajoute un matériel?

Dans le cas 2 d'une table bien dodue, certes elle deviendra encore plus dodue mais fondamentalement les requêtes ne changeront pas puisqu'il y a simple ajout d'une valeur pour l'attribut de typage pour chaque nouveau matériel et d'attributs particuliers à chaque matériel dans la même table, la bien nommée dodue?
Dans ce cas la 2FN n'est effectivement pas respectée

Pour le cas avec un héritage, il aura création d'autant de tables que de matériel et ça peut vite devenir lourd (centaines de tables) et je subodore que cela sera beaucoup plus impactant sur les requêtes SQL?

Encore une question, comment modéliser un relation réflexive avec un héritage ? Cas d'un matériel composé d'autres matériels ?

Merci pour ta réponse

[escartefigue]

Dans le cas où les déclinaisons de sous-type sont nombreuses, et le nombre d'attributs communs au sur-type faible, il est préférable d'envisager une métamodélisation

Voyez ICI

[informer]

Merci beaucoup escartefigue pour ce lien dont l'exemple est très didactique et qui illustre les limites de l'héritage dans un SGBDR.

Pour clore le post voici ce que Power*AMC apporte comme réponses. On notera que la dernière solution correspond à celle du typage (dite table dodue)

[informer]

Continuons sur l’exemple de la personne prospect ou client qui est traitée par un héritage

Si j’ai bien compris il y aura 3 tables mais cela ne complexifie-t-il pas les traitements SQL?

Par exemple pour connaître le statut de la personne, ne faut-il par obligatoirement pas

• des jointures entre la table père et les deux fils
• du traitement dans le SQL voire des procs stocks

Ce n’entraîne pas

• Du code source d’erreur
• Des jointures source de temps machine

Merci

[fsmrel]

Bonsoir informer,

Continuons sur l’exemple de la personne prospect ou client qui est traitée par un héritage
Si j’ai bien compris il y aura 3 tables mais cela ne complexifie-t-il pas les traitements SQL?

Non. Faites une vue PERSONNE_CLIENT et une vue PERSONNE_PROSPECT, voire une vue PERSONNE_CLIENT_PROSPECT pour encapsuler les jointures (ou les unions), vous pourrez ainsi manipuler des tables virtuelles structurellement simples, tout comme si c’était des tables réelles.

Par exemple pour connaître le statut de la personne, ne faut-il par obligatoirement pas

• des jointures entre la table père et les deux fils
• du traitement dans le SQL voire des procs stocks

Utilisez les vues évoquées ci-dessus.

Ce n’entraîne pas

• Du code source d’erreur

Une fois de plus, utilisez les vues.

Ce n’entraîne pas

• Des jointures source de temps machine

J’ai une vue de 90 jointures (internes/externes), la table principale — appelons-la MOUVEMENT — comportant 100 000 lignes : 250 ms pour accéder aux données via la vue et récupérer une centaine de lignes (mouvements et données jointes). J’utilise PostgreSQL sur mon modeste PC. Il y a trente ans, même sur un mainframe hébergeant DB2, je n’aurais pas osé, mais on n'est plus en 1988...

Je vous engage à vous retrousser les manches et effectuer vos propres tests (en utilisant l’identification relative au stade conceptuel et en plaçant correctement les index sur les tables en jeu).

[fsmrel]

Bonsoir à nouveau, informer,

Pour clore le post voici ce que Power*AMC apporte comme réponses.

PowerAMC (sans astérisque) a apporté ces réponses il y a au moins 25 ans, du temps où l’AGL était français (SDP, 8, allée de l’ancien Pont - 92150 Suresnes) et était nommé AMC*Designor (avec astérisque cette fois-ci).

Photo de la couverture de la version 4 (copyright 1990-1993) :

Comme sur la couverture ça n’est pas très lisible, voici la partie du MCD qui nous concerne :

Quand PowerSoft a racheté l’AGL (1995) on a eu droit à un Guide de l’utilisateur version papier, épais (plus de 500 pages), qui m’est toujours utile, parce que c’est quand même plus confortable de tourner les pages d’un bouquin doté d'un bon index que de crapahuter dans la toile.

Bien entendu, sont décrits dans ce guide (en 1995, je le rappelle) les différents modes de génération des tables auxquels vous faites allusion (1, 2, ou 3 tables) :

Mais les auteurs de Merise avaient déjà décrit tout ça dans les années quatre-vingts. Voyez par exemple d’A. Rochfeld et J. Morejon, La Méthode MERISE. Tome 3. Gamme opératoire (Les Éditions d'organisation, 1989), pages 194-197.

On notera que la dernière solution correspond à celle du typage (dite table dodue)

Vous avez bien raison, c’est un fait qu’il serait absurde de tout fourrer dans une seule table car, entre autres inconvénients (tendance à l’obésité par exemple), le bonhomme NULL se régalerait et, ce que l’on sait moins, il démolit le théorème de Heath et inhibe l’optimiseur des SGBD relationnels.

Ne générer que les tables dérivées des sous-entités-types (CLIENT et FOURNISSEUR pour reprendre l’exemple ci-dessus, avec absorption des attributs de l’entité-type générique ORGANISME) peut se défendre quand elles sont exclusives l’une de l’autre, mais au prix du doublement des associations branchées sur l’entité-type générique.

Clairement, dans la majorité des cas, générer une table pour l’entité-type générique (ORGANISME) et une table par sous-entité-type (CLIENT, FOURNISSEUR) s’impose. Le bonhomme NULL ne pourra pas ficher la patouille, et au moyen de vues, il est possible de reproduire les deux cas précédents, sans altérer les tables.

[fsmrel]

A titre de complément :

Héritage ou pas héritage ?

[informer]

Merci fsmrel pour toute ces informations.

Il n’y a pas de lois gravées dans le marbre mais bien des stratégies possibles en fonction d’un besoin.