Héritage

[laowantong]

Syntaxe

La syntaxe est celle des associations, avec comme seule différence que le libellé est flanqué des délimiteurs "/" et "\" (qui évoquent un triangle). Du fait que les héritages sont des boîtes comme les autres, il n'y a pas de traitement particulier pour le plongement.

/contrainte\, cp PARENT, c1 ENFANT 1, c2 ENFANT 2: suppléments

Avec:

• contrainte: la chaîne qui apparaîtra dans le triangle, a priori élément de l'ensemble {"", "X", "T", "XT"}.
• cp, c1, c2: une cardinalité, ou plutôt une chaîne de deux symboles exprimant le « point de vue de la source »:
  • le premier est "0" si l'entité disparaît, et "1" sinon.
  • le second est "0" si l'entité n'exporte rien du tout, "1" si elle exporte son identifiant et "N" si elle exporte tout son contenu.
• suppléments: liste d'attributs à ajouter au passage de la ou des exportations.

%%mocodo
:
PARENT: id, attributs
:

RIRI: riri 1, riri 2
/XT\, 10 PARENT, 0N RIRI, 0N FIFI, 0N LOULOU: supplément 1, supplément 2
FIFI: fifi 1, fifi 2

:
LOULOU: loulou 1, loulou 2
:

Remarques.

• Les « cardinalités » de l'héritage n'apparaissent pas sur le MCD.
• Les attributs supplémentaires de l'héritage n'apparaissent pas non plus, sauf éventuellement au survol (non implanté).
• La flèche est ajoutée par défaut.
• On peut éventuellement alléger la syntaxe si l'on décide que les enfants n'ont jamais d'identifiant : dans ce cas le préfixe _ devient implicite. Je les laisse ici pour montrer les différences de traitement entre identifiants et attributs normaux lors de la conversion.
• La cardinalité "10" était considérée comme une typo et automatiquement corrigée jusqu'à maintenant. J'ai pour l'instant supprimé cette correction automatique pour permettre cette extension syntaxique. On peut éventuellement traiter au cas par cas.

Sémantique du passage au relationnel

Elle est spécifiée par les valeurs des « cardinalités », telles qu'expliquées plus haut. Dans la suite, on passe en revue les cas standard. Seule la clause de définition de l'héritage change dans les différents textes sources.

Conversion montante

• Le parent se maintient et n'exporte rien.
• Les enfants disparaissent et exportent tout leur contenu.

%%mocodo --mld --no_mcd
:
PARENT: id, attributs
:

RIRI: riri 1, riri 2
/XT\, 10 PARENT, 0N RIRI, 0N FIFI, 0N LOULOU: supplément 1, supplément 2
FIFI: fifi 1, fifi 2

:
LOULOU: loulou 1, loulou 2
:

PARENT (id, attributs, supplément 1, supplément 2, riri 1, riri 2, fifi 1, fifi 2, loulou 1, loulou 2)

Remarques.

• Les attributs supplémentaires de l'association (en général, type) peuvent être omis. Bien entendu, ils ne migrent qu'une fois, et non pas autant de fois qu'il y a d'enfants.
• Les relations « disparues » sont toujours présentes dans le texte source de la sortie, mais en commentaires. Même traitement que pour la suppression des tables réduites à une seule colonne.

Conversion stationnaire

• Le parent se maintient et exporte son identifiant.
• Les enfants se maintiennent et n'exportent rien.

%%mocodo --mld --no_mcd
:
PARENT: id, attributs
:

RIRI: riri 1, riri 2
/XT\, 11 PARENT, 10 RIRI, 10 FIFI, 10 LOULOU: supplément 1, supplément 2
FIFI: fifi 1, fifi 2

:
LOULOU: loulou 1, loulou 2
:

PARENT (id, attributs)
RIRI (id, supplément 1, supplément 2, riri 1, riri 2)
FIFI (id, supplément 1, supplément 2, fifi 1, fifi 2)
LOULOU (id, supplément 1, supplément 2, loulou 1, loulou 2)

Remarque.

• Les suppléments se retrouvent dupliqués dans chacun des enfants.

Conversion descendante

• Le parent se maintient et exporte tout son contenu.
• Les enfants se maintiennent et n'exportent rien.

%%mocodo --mld --no_mcd
:
PARENT: id, attributs
:

RIRI: riri 1, riri 2
/XT\, 1N PARENT, 10 RIRI, 10 FIFI, 10 LOULOU: supplément 1, supplément 2
FIFI: fifi 1, fifi 2

:
LOULOU: loulou 1, loulou 2
:

PARENT (id, attributs)
RIRI (id, attributs, supplément 1, supplément 2, riri 1, riri 2)
FIFI (id, attributs, supplément 1, supplément 2, fifi 1, fifi 2)
LOULOU (id, attributs, supplément 1, supplément 2, loulou 1, loulou 2)

Conversion descendante (en cas de partition)

• Idem, sauf que le parent disparaît.

%%mocodo --mld --no_mcd
:
PARENT: id, attributs
:

RIRI: riri 1, riri 2
/XT\, 0N PARENT, 10 RIRI, 10 FIFI, 10 LOULOU: supplément 1, supplément 2
FIFI: fifi 1, fifi 2

:
LOULOU: loulou 1, loulou 2
:

RIRI (id, attributs, supplément 1, supplément 2, riri 1, riri 2)
FIFI (id, attributs, supplément 1, supplément 2, fifi 1, fifi 2)
LOULOU (id, attributs, supplément 1, supplément 2, loulou 1, loulou 2)

Cas non standard

On peut facilement exprimer des conversions non standard. J'ai a priori une préférence pour ce genre d'approche, plutôt que lever des erreurs en restreignant arbitrairement la généralisation de mécanismes existants.

Conversion hétérogène

• Chaque enfant peut décider indépendamment des autres ce qu'il exporte et s'il se maintient ou non.

%%mocodo --mld --no_mcd
:
PARENT: id, attributs
:

RIRI: riri 1, riri 2
/XT\, 10 PARENT, 0N RIRI, 1N FIFI, 11 LOULOU: supplément 1, supplément 2
FIFI: fifi 1, fifi 2

:
LOULOU: loulou 1, loulou 2
:

PARENT (id, attributs, supplément 1, supplément 2, riri 1, riri 2, fifi 1, fifi 2, loulou 1)
FIFI (fifi 1, fifi 2)
LOULOU (loulou 1, loulou 2)

Migrations bidirectionnelles

• Chaque entité se maintient et exporte tout son contenu.

%%mocodo --mld --no_mcd
:
PARENT: id, attributs
:

RIRI: riri 1, riri 2
/XT\, 1N PARENT, 1N RIRI, 1N FIFI, 1N LOULOU: supplément 1, supplément 2
FIFI: fifi 1, fifi 2

:
LOULOU: loulou 1, loulou 2
:

PARENT (id, attributs, supplément 1, supplément 2, id.1, attributs.1, supplément 1.1, supplément 2.1, riri 1, riri 2, id.2, attributs.2, supplément 1.2, supplément 2.2, fifi 1, fifi 2, id.3, attributs.3, supplément 1.3, supplément 2.3, loulou 1, loulou 2)
RIRI (id, attributs, supplément 1, supplément 2, riri 1, riri 2)
FIFI (id, attributs, supplément 1, supplément 2, fifi 1, fifi 2)
LOULOU (id, attributs, supplément 1, supplément 2, loulou 1, loulou 2)

Problèmes et questions

Ordre des attributs

J'ai opté pour un ordre qui me paraissait pertinent : certains attributs migrants sont ajoutés à la fin de ceux existants, d'autres viennent s'insérer en début de liste. Quelles sont les conventions ?

Suppression d'un parent lié à d'autres entités

Je n'ai pas spécialement prévu ce cas, mais son traitement par Mocodo me semble raisonnable à première vue.

%%mocodo --mld
BIZZ: bizz
BUZZ: buzz
BAZZ: bazz

ASSOCIZZ, 11 BIZZ, 1N PARENT
ASSOCUZZ, 1N BUZZ, 11 PARENT
ASSOCAZZ, 1N BAZZ, 1N PARENT

:
PARENT: id, attributs
:

RIRI: riri 1, riri 2
/XT\, 0N PARENT, 10 RIRI, 10 FIFI, 10 LOULOU
FIFI: fifi 1, fifi 2

:
LOULOU: loulou 1, loulou 2
:

BIZZ (bizz, id)
ASSOCAZZ (bazz, id)
RIRI (id, attributs, buzz, riri 1, riri 2)
FIFI (id, attributs, buzz, fifi 1, fifi 2)
LOULOU (id, attributs, buzz, loulou 1, loulou 2)

Suppression d'un enfant lié à d'autres entités

Ce cas me paraît plus douteux, il requiert en tout cas l'existence d'un identifiant dans les enfants concernés.

%%mocodo --mld
:
PARENT: id, attributs
:

RIRI: riri 1, riri 2
/XT\, 10 PARENT, 0N RIRI, 0N FIFI, 0N LOULOU: type
FIFI: fifi 1, fifi 2

:
LOULOU: loulou 1, loulou 2
:

ASSOCIZZ, 11 BIZZ, 1N RIRI
ASSOCUZZ, 1N BUZZ, 11 LOULOU
ASSOCAZZ, 1N BAZZ, 1N FIFI

BIZZ: bizz
BUZZ: buzz
BAZZ: bazz

PARENT (id, attributs, type, riri 1, riri 2, fifi 1, fifi 2, loulou 1, loulou 2)
ASSOCAZZ (bazz, fifi 1)
BIZZ (bizz, riri 1)

[feragon]

Issue associée: #16

[fduchatea]

L'ajout de l'héritage dans (la branche main) de Mocodo serait un plus. En général, les enfants n'ont pas d'identifiant (ce que la syntaxe du _ permet de faire).

Dans la conversion stationnaire, on peut aussi simplement laisser les relations enfants avec une clé primaire composée uniquement de celle de leur entité. Exemple :
RIRI (riri1, supplément 1, supplément 2, riri 2)

Pour l'ordre des attributs : pas sûr qu'il y ait une convention. Dans ce que j'ai rencontré, soit on ajoute les attributs de l'enfant à la fin, soit on ajoute l'identifiant au début et le reste des attributs à la fin.

Pour la Suppression d'un parent lié à d'autres entités, on peut considérer que c'est un cas atypique (ça semble peu pertinent de supprimer le parent dans l'exemple indiqué, mais autant ne pas limiter). Pour les relations BIZZ et ASSOCAZ, c'est étonnant de ne référencer que id, qui n'est qu'une partie de la clé primaire dans les relations enfants : deux instances enfants pourraient avoir la même valeur pour l'attribut id (et des valeurs différentes pour l'autre attribut composant la clé primaire). Dans ce cas, ça peut poser un souci.

Pour le dernier cas (Suppression d'un ENFANT lié à d'autres entités) : En relationnel, le parent ne devrait-il pas récupérer buzz aussi ? Les relations ASSOCAZZ et BIZZ possèdent un attribut (fifi1 et riri1) qui n'est pas clé primaire d'une table. Ca peut poser problème lors de la génération du code SQL pour certains SGBD (ex, PostgreSQL). Ces 2 relations devraient plutôt utiliser id qui est la clé primaire restante (à voir si c'est réalisable facilement ans Mocodo).