DU DIAGRAMME DE CLASSES UML VERS UN SCHEMA RELATIONNEL
Nous donnons ci‐après quatre règles (de R1 à R4) pour traduire un schéma conceptuel UML en un
schéma relationnel équivalent. Il existe d’autres solutions de transformation, mais ces règles sont les
plus simples et les plus opérationnelles.
Transformation des classes
R1 Chaque classe du diagramme UML devient une relation. Chaque attribut de la classe devient attribut
de la relation. Il faut choisir un attribut de la classe pouvant jouer le rôle d’identifiant.
Si aucun attribut ne convient en tant qu’identifiant, il faut en ajouter un de telle sorte que la relation
dispose d’une clé primaire (les outils proposent l’ajout de tels attributs). Exemple :
Transformation des associations
Les règles de transformation des associations dépendent des cardinalités/multiplicités maximales des
associations. Nous distinguons trois familles d’associations :
− un‐à‐plusieurs ;
− plusieurs‐à‐plusieurs ou classes‐associations, et n‐aires ;
− un‐à‐un.
1/6
Associations un à plusieurs
R2 Il faut ajouter un attribut de type clé étrangère dans la relation Avion. L’attribut porte le nom de la
clé primaire de la relation Compagnie.
Associations plusieurs à plusieurs et naires
R3 La classe‐association devient une relation dont la clé primaire est composée par la concaténation des
identifiants des classes connectés à l’association. Les attributs de la classe‐association doivent être
ajoutés à la nouvelle relation.
2/6
Associations un à un
R4 La règle est la suivante, elle permet d’éviter les valeurs NULL dans la base de données.
Il faut ajouter un attribut clé étrangère dans la relation dérivée de la classe ayant la multiplicité minimale
égale à un. L’attribut porte le nom de la clé primaire de la relation dérivée de la classe connectée à
l’association.
Si les deux cardinalités (multiplicités) minimales sont à zéro, le choix est donné entre les deux relations
dérivées de la règle R1. Si les deux cardinalités minimales sont à un, il est sans doute préférable de
fusionner les deux classes en une seule.
3/6
Transformation de l’héritage
Trois décompositions sont possibles pour traduire une relation d’héritage en
fonction des contraintes existantes :
− décomposition par distinction ;
− décomposition descendante (push‐down). S’il existe une contrainte de totalité ou de partition sur
l’association d’héritage, il y aura deux cas possibles de décomposition ;
− décomposition ascendante (push‐up).
Décomposition par distinction
Il faut transformer chaque sous‐classe en une relation. La clé primaire de la sur‐classe migre dans la
(les) relation(s) issue(s) de la (des) sous-classe(s) et devient à la fois clé primaire et clé étrangère.
4/6
Décomposition descendante (pushdown)
Deux cas sont possibles :
− S’il existe une contrainte de totalité ou de partition sur l’association, il est possible de ne pas traduire
la relation issue de la sur‐classe. Il faut alors faire migrer tous ses attributs dans la (les) relation(s)
issue(s) de la (des) sous‐classe(s).
− Dans le cas contraire, il faut faire migrer tous ses attributs dans la ou les relation(s) issue(s) de la (des)
sous‐classe(s) dans la (les) relation(s) issue(s) de la (des) sous‐classe(s).
Décomposition ascendante (pushup)
Il faut supprimer la (les) relation(s) issue(s) de la (des) sous‐classe(s) et faire migrer les attributs dans la
relation issue de la sur‐classe.
5/6
Transformation d’une composition
Alors que l’agrégation partagée de UML se traduit au niveau logique comme une simple association, il
n’en est pas de même pour la composition
6/6
