Exemple de transformation d'une relation d'héritage
Exemple :
Soit le modèle UML suivant :
Il existe trois façons de traduire la relation d'héritage : par référence, par absorption par les classes filles, par absorption par la classe mère.
Remarque : Type d'héritage
L'héritage n'est pas complet, puisque l'on observe que les thèses et les livres ont des attributs qui ne sont pas communs (la discipline pour la thèse et l'éditeur pour le livre). Mais l'on peut considérer qu'il est presque complet, car il n'y a qu'un attribut par classe fille de différence et pas d'association associée aux classes filles.
La classe mère est abstraite, on ne gère que des livre ou des thèses, pas d'autres documents.
La meilleure solution est donc ici un héritage par les classes filles, mais un héritage par la classe mère reste un bon choix. En revanche l'héritage par référence est un mauvais choix, car il conduit à une solution inutilement complexe.
Observons néanmoins les avantages et inconvénients que chacun des trois choix porterait.
Héritage représenté par une référence
Document(#Titre:Chaîne, Auteur:Chaîne) avec Document AND (These OR Livre)
These(#Titre=>Document, Discipline:Chaîne)
Livre(#Titre=>Document, Editeur:Chaîne)
Complément :
vThese = Jointure (Document, These, Document.Titre=These.Titre)
vLivre = Jointure (Document, Livre, Document.Titre=Livre.Titre)
Contraintes : PROJ(Document,Titre) IN (PROJ(These,Titre) UNION PROJ(Livre,Titre))
Remarque : Avantages du choix
Il n'y a ni redondance ni valeur nulle inutile dans les relations These et Livre.
Remarque : Inconvénients du choix
Il est relativement lourd de devoir créer un tuple dans Document pour chaque tuple dans These ou Livre, alors que la relation Document ce porte que l'information concernant l'auteur, juste pour assurer les cas, par ailleurs plutôt rare dans la réalité, où les thèses sont publiées sous forme de livres.
De plus la classe Document étant abstraite, il ne devra jamais y avoir de tuple dans document qui n'a pas de tuple correspondant dans Livre ou These. Ceci n'est pas contrôlable directement en relationnel et devra donc être vérifié au niveau applicatif (ou bien la classe ne devra plus être considérée comme abstraite).
Héritage absorbé par les classes filles
These(#Titre, Discipline:Chaîne, Auteur:Chaîne)
Livre(#Titre, Editeur:Chaîne, Auteur:Chaîne)
Remarque : Avantages du choix
Il est plus simple que le précédent, puisque la représentation d'une thèse ou d'un livre ne nécessite plus que d'ajouter un seul tuple. Il évite donc les clés étrangères, toujours plus délicates à gérer d'un point de vue applicatif.
Remarque : Inconvénient du choix
Si l'héritage est exclusif ce modèle n'a aucun inconvénient.
Si l'héritage n'est pas exclusif et qu'une thèse est aussi un livre, alors une information sera dupliquée (l'auteur), ce qui introduit de la redondance.
Héritage absorbé par la classe mère
Document(#Titre, Discipline:Chaîne, Editeur:Chaîne, Auteur:Chaîne, Type:{These|Livre})Complément :
vThese = Projection (Restriction (Document, Type='These'), Titre, Discipline, Auteur)
vLivre = Projection (Restriction (Document, Type='Livre'), Titre, Editeur, Auteur)
Remarque : Avantages du choix
Il est plus simple que le premier, puisque la représentation d'une thèse ou d'un livre ne nécessite plus que d'ajouter un seul tuple. Il évite donc les clés étrangères..
Remarque : Inconvénient du choix
Les tuples de Document contiendront systématiquement une valeur nulle soit pour l'éditeur soit pour la discipline.
Il faut vérifier l'adéquation entre la valeur de Type et le fait que Discipline ou Auteur n'est pas valué.
Si l'héritage est exclusif (ce qui est le cas par défaut), alors les tuples de la relation Document contiendront systématiquement une valeur nulle soit pour l'éditeur soit pour la discipline.
Il faudra pour être rigoureux vérifier l'adéquation entre la valeur de Type et le fait que Discipline ou Auteur n'est pas valué (si Type='These' alors Editeur=Null et si Type='Livre' alors Discipline=Null ).