Discussion :

[Invité]

Est-il possible qu'un héritage soient communs à deux tables ?

[CinePhil]

Ton schéma semble vouloir dire qu'un traducteur peut être une personne ou une structure. C'est le cas ?

Ne serait-ce pas plutôt qu'une personne peut être un traducteur et qu'elle appartient à une structure ?
Traducteur -(1,1)----Etre----0,1- Personne -1,1----Appartenir----0,n- Structure

Ou bien que lorsqu'une personne est un traducteur, elle appartient à une structure ?
Traducteur -(1,1)----Etre----0,1- Personne
|---------1,1----Appartenir----0,n- Structure

[Invité]

Effectivement, Traducteurs peut appartenir au deux.
La base comprend des personnes qui font de la traduction, comme des structures qui font aussi de la traduction.
Mais ma précédente question n'est pas applicable dans ce cas, car pour une personne il n'y a pas de date de création.
Faut-il dans ce cas envisager un héritage Traducteurs pour Personnes et un héritage Traduction pour Structures?

[CinePhil]

J'ai plutôt l'impression qu'il ne s'agit pas du tout d'un héritage !

Un héritage se justifie quand l'entité-type fille hérite des attributs de l'entité-type mère ou quand l'entité-type fille a des associations que n'ont pas forcément toutes les instances de l'entité-type mère. C'est une spécialisation issue d'une généralité.

Ici, on pourrait imaginer que Traducteur soit en association avec une entité-type Langue.
Traducteur -1,n----Peut_traduire----0,n- Langue

Mais avec ton dernier message, j'ai plutôt l'impression qu'il s'agit de deux associations distinctes :
Structure -0,n----Faire---0,n- Traduction -1,1----A_Traduire----0,n- Langue
Personne -0,n----Faire----0,n-------| |-------1,1----Traduire_en----0,n------|

Ce qui pourrait donner cette structure de tables :
Langue (l_id, l_nom...)
Personne (p_id, p_nom, p_prenom...)
Structure (s_id, s_nom...)
Traduction (t_id, t_id_langue_depart, t_id_langue_arrivée)
Personne_Traduction (pt_id_personne, pt_id_traduction...)
Structure_Traduction (st_id_structure, st_id_traduction....)

Ou plus simplement :
Langue -0,n-(De)----Traduire----0,n- Structure
|------------0,n-(À)------------|

Langue -0,n-(De)----Traduire----0,n- Personne
|------------0,n-(À)------------|

Ce qui donnerait les tables :
Langue (l_id, l_nom...)
Personne (p_id, p_nom, p_prenom...)
Structure (s_id, s_nom...)
Personne_Traduire_Langue (ptl_id_personne, ptl_id_langue_depart, ptl_id_langue_arrivee)
Structure_Traduire_Langue (stl_id_structure, stl_id_langue_depart, stl_id_langue_arrivee)

Soit une table de moins. À toi de voir si mes schémas correspondent à ce que tu veux modéliser. Sinon donne nous les règles de gestion.

[Invité]

Oui c'est ca, mais avec un héritage. Il est pourtant correct d'utiliser un héritage sans attributs. On peut toujours envisagé que des attributs seront ajoutés par la suite.

[CinePhil]

Oui c'est ca, mais avec un héritage.

Qu'est-ce qui justifie absolument que tu doives utiliser un héritage ?
Donne nous tes règles de gestion.

Il est pourtant correct d'utiliser un héritage sans attributs.

Oui. Je travaille justement sur un de ces cas que j'ai exposé récemment. L'héritage y est justifié par le fait que mes étudiants ont des associations différentes des autres utilisateurs, ainsi que des attributs supplémentaires. Il est possible que dans le futur l'application serve à d'autres catégories d'utilisateurs qui auront elles aussi leurs propres attributs et/ou associations mais comme je n'en sais rien aujourd'hui, je ne le modélise pas.

On peut toujours envisager que des attributs seront ajoutés par la suite.

Pendant que tu y es, tu peux envisager que dans le futur le traducteur pourra être un Twileck ou un droïde de protocole !

Modélise correctement l'univers actuel ! Il sera toujours temps de faire un héritage plus tard quand ce sera nécessaire.

[pfortin]

Bonjour,

Il m'est arrivé de créer ce type de d'entités pour mutualiser des associations indépendamment de la spécialisation.

Par exemple, une adresse et des coordonnées peuvent être associées à un tiers.
Ce tiers sera de sous-type Personne Physique ou Personne Morale avec aucune caractéristique en commun.
J'appelle cela, à tort ou à raison, un héritage de services (ici services d'adresse et de coordonnées).

On pourrait tout aussi bien créer autant de d'associations que de sous-types (qui n'en seraient plus, du coup).
Mais je ne sais pas trancher objectivement. Je suis perplexe, là.

[JPhi33]

Bonsoir,

Est-il possible qu'un héritage soient communs à deux tables ?

Oui, c'est possible. En tout cas, certains auteurs se sont aventurés jusque là.

En se repositionnant au bon niveau d'abstraction (tu présentes un MCD mais tu parles de tables...) on dit qu'une entité peut être la spécialisation de plusieurs entités générales. On parle alors de généralisation composée.

Ce terme générique se décline en plusieurs types selon les règles d'intersection entre les 3 entités : les deux entités générale, G1 et G2 (par exemple) et l'entité spécialisée S. On parle de :
- généralisation alternative lorsque S est-un G1 ou bien un G2 (ou exclusif)
- généralisation multiple lorsque S est-un G1 et un G2 (et)
- généralisation sélective lorsque S est-un G1, un G2 ou les deux (ou inclusif)

D'après les précédents échanges, il semble que l'on se trouve dans le cas d'une généralisation alternative (ouf ! c'est la moins complexe) :

Un TRADUCTEUR est soit une PERSONNE soit une STRUCTURE (et donc pas les deux à la fois).

Dans ce cas, l'entité spécialisée TRADUCTEUR hérite des propriétés et des associations communes aux deux entités générales PERSONNE et STRUCTURE. Par propriétés communes, on entend celles qui ont même domaine sémantique dans les deux entités générales. En effet, on ne s'attend pas à ce qu'il existe les mêmes propriétés stricto sensu dans PERSONNE et STRUCTURE, ce serait une erreur de modélisation (dans un MCD, une propriété est unique).
Corollaire : TRADUCTEUR n'hérite pas des propriétés de domaine sémantique différent dans les entités générales.

(Rappel : L'héritage ne se manifeste qu'au niveau logique. Au niveau conceptuel, il est seulement implicite.)

Exemple : nom_de_personne dans PERSONNE et désignation_structure dans STRUCTURE ont même domaine sémantique. TRADUCTEUR peut hériter de cette propriété, qu'il sera judicieux de renommer (en désignation_traducteur, par exemple).


Bien entendu, la spécialisation en TRADUCTEUR doit être justifiée. Cette entité doit détenir des propriétés ou des associations spécifiques.