170. Transformation du modèle conceptuel de données en modèle logique relationnel MCD MLD. Table des matières

Transcription

1 Modélisation de logiciels de gestion 170. Transformation du modèle conceptuel de données en modèle logique relationnel MCD MLD Table des matières 1 Préambule Première règle Deuxième règle Troisième règle Table associative Produit cartésien Conventions d écriture Transformation d une entité associative Transformation d une entité dépendante Conventions d écriture Identifiants naturels d'entités Associations identifiantes Association identifiante de composition Association identifiante naturelle Multiples associations entre entités Préambule Nous avons expliqué la démarche de réalisation de modèles conceptuels de données dans le chapitre «Modélisation conceptuelle des données Aspects macroscopiques» ; dans le chapitre «Modélisation logique des données Aspects macroscopiques» nous avons présenté les concepts du modèle relationnel de Codd. Dans ce chapitre nous présenterons les règles qui permettent de transformer les modèles conceptuels en modèles logiques relationnels. Ces règles, au nombre de trois, permettent d effectuer la transformation automatiquement et sans appauvrissement de la sémantique du modèle conceptuel. De nombreux ateliers de génie logiciels (AGL) contiennent des fonctionnalités logicielles qui effectuent cette transformation sans intervention du concepteur. 1/16

2 2 Première règle Une entité est transformée en une table. Les attributs de l entité deviennent des colonnes de la table. L identifiant naturel, si il existe, est transformé en une clé secondaire unique et non nulle. La ou les attributs de clé primaire d entité, si ils existent, deviennent des colonnes de clé primaire de la table. Si aucun attribut de clé primaire n existe, une colonne de clé primaire est créée au niveau logique. 2/16

3 3 Deuxième règle Chaque association binaire dont au moins une de ses cardinalités maximales vaut 1 est transformée en une relation (dépendance fonctionnelle). 3/16

4 Le choix de la table source, respectivement de la table cible de la relation est effectué en fonction des cardinalités de l association selon les règles ci-après : Si une des cardinalités maximales vaut n La table issue de l entité dont la cardinalité maximale vaut n devient la source de la relation. Exemple : 4/16

5 Si les deux cardinalités maximales valent 1 o Si une des deux cardinalité minimales vaut 0 La table issue de l entité dont la cardinalité minimale vaut 1 devient la cible de la relation. Exemple : Il est important que la clé étrangère soit dans l entité qui a le lien obligatoire (1..1) pour simplifier les transactions et la gestion des droits. En effet, et pour notre exemple : La création d une livraison se fait sans établir lien sur une facture. La création d une facture se fait en référençant obligatoirement une facture ; ainsi, dans la même opération l on créée une facture et on établit la référence sur la livraison. Si la clé étrangère se trouvait dans la table Livraisons, il faudrait mettre à jour la livraison lors de chaque ajout de facture ; ceci compliquerait la transaction et de plus, il n est pas sûr que le service qui crée des factures ait le droit de mettre à jour des livraisons. 5/16

6 o Si les deux cardinalités minimales valent 0 Chacune des deux tables peut devenir indifféremment source ou cible de la relation. Exemple : La clé étrangère est mise indifféremment dans l une des deux tables. Par contre, il est important qu elle soit dans une seule des deux tables pour éviter toute redondance. 6/16

7 4 Troisième règle Chaque association dont les deux cardinalités maximales valent n est transformée en une table associative. Une table associative permet de créer des relations abstraites de degré n:n en s appuyant sur deux relations 1:n; chacune des deux tables participant à la relation de degré n:n devient la source d une relation dont la table associative est à chaque fois la cible. La clé primaire d une table associative est formée de la concaténation des colonnes de clés étrangères des tables sources. 7/16

8 Remarque : Une table associative peut matérialiser des relations n-aires ; en ce qui nous concerne, nous travaillons toujours, au niveau conceptuel, avec des associations binaires. 5 Table associative 5.1 Produit cartésien Une table associative représente le produit cartésien des deux tables sources des relations. Enfants et Jours sont deux ensembles, Enfants X Jours est le produit cartésien de Enfants par Jours. Le produit cartésien Enfants X Jours forme un nouvel ensemble matérialisé par une table associative que nous avons nommée Présences dans le diagramme précédent. L ensemble Présence est formé des couples (e,j) tels que e appartient à Enfants et j appartient à Jours. Dès lors, la présence d une occurrence de chacune des deux tables sources est impérative et est représentée par la cardinalité UML 1..1 ou 1. 8/16

9 5.2 Conventions d écriture Le nom des relations 1 peut être omis car les modèles sont suffisamment lisibles ; toutefois, les relations sont enrichies du stéréotype «PK» pour bien montrer leur caractère identifiant. Les colonnes de clés étrangères référant les tables sources du produit cartésien sont enrichies du stéréotype «PFK» pour mettre en évidence leur double caractère de constituant de clé primaire d une part et de clé étrangère d autre part. 1 Pour rappel, nous parlons d une relation selon notre terminologie de modèle logique de données ; toutefois, cette relation que nous représentons dans un modèle de classe UML est une association lorsque nous utilisons un AGL s appuyant sur le langage UML. 9/16

10 6 Transformation d une entité associative Chaque entité associative dont les deux cardinalités maximales valent n est transformée en une table associative. Remarque : La transformation s effectue selon la description de la troisième règle. Les attributs de l entité associative deviennent des colonnes de la table associative. Si l entité associative participe à des associations avec d autres entités, la table associative peut à son tour être source ou cible de relations avec les autres tables. 10/16

11 7 Transformation d une entité dépendante L association identifiante (de composition) d une entité dépendante est transformée en une relation identifiante de composition. Remarques : L entité dépendante est transformée en table dépendante selon la description de la première règle. La transformation de l association identifiante de composition s effectue selon la description de la deuxième règle. 11/16

12 La clé primaire d une table dépendante est formée de la concaténation de la colonne ( ou des colonnes) de clé étrangère de la table source et de la colonne NumeroDep de clé primaire. Remarque : Une entité dépendante peut dépendre de plus d un parent ; donc, une table dépendante peut être la cible de plus d une table source. 7.1 Conventions d écriture La colonne (ou les colonnes) de clé étrangère de la table source de la dépendance est toujours positionnée avant la colonne (ou les colonnes) de clé primaire propre à la table dépendante. Egalement comme nous l avons défini pour la table associative, la colonne (ou les colonnes) de clé étrangère de la table source de la dépendance est enrichie du stéréotype «PFK» pour mettre en évidence son double caractère de constituant de clé primaire d une part et de clé étrangère d autre part. Tout comme nous l avons défini pour la table associative, la relation identifiante est enrichie du stéréotype «PK» pour bien montrer son caractère identifiant. De plus, nous spécialisons le stéréotype, «PKC» ou PKS», en fonction de la contrainte de suppression des occurrences d enfants que nous avons définie au chapitre «Modélisation conceptuelle des données Aspects macroscopiques». Pour l exemple de notre ticket et de ses lignes, l indication de suppression en cascade «PKC» est pertinente. Toutefois, dans de nombreuses autres situations la présence d enregistrements dans une table dépendante doit empêcher la suppression de l enregistrement parent dans la table source ; il s agit du concept d intégrité référentielle stricte que nous avons vu dans le chapitre «Modélisation logique des données Aspects macroscopiques». L intégrité référentielle stricte se définit avec le stéréotype «PKS». 12/16

13 8 Identifiants naturels d'entités Tout identifiant naturel, qu'il soit composé d'un ou de plusieurs attributs est transformé en une clé secondaire unique et non nulle; la clé secondaire devient un index lors du passage au niveau du modèle physique. Les clés secondaires uniques et non nulles sont mises en évidence à l'aide des stéréotypes «UID» ou «UID-i» en appliquant les mêmes règles que celles énoncées pour le modèle conceptuel. 13/16

14 9 Associations identifiantes 9.1 Association identifiante de composition Veuillez vous référer au chapitre Association identifiante naturelle L'association identifiante naturelle se transforme de manière habituelle [Voir 170. Transformation du MCD en MLD relationnel, deuxième règle] en une relation (contrainte de clé étrangère); nous rajoutons à cette relation le stéréotype d'identifiant naturel 2 «UID». Comme vu au précédemment [Chapitre 8], le ou les identifiants sont transformées en clés secondaires uniques et non nulles. Comme pour toute clé secondaire, il faut créer un index unique pour la matérialiser au niveau physique; la construction de cet ou ces index doit se faire en concaténant la clé étrangère du parent à la ou les colonnes 3 servant de clé secondaire unique et non nulle. Pour notre exemple, l'index pour la table Courses est construit par la concaténation de: Annee_Numero + Nom 2 Ou de clé secondaire unique et non nulle dans le vocabulaire du modèle logique de données relationnel. 3 Si la clé secondaire est basée sur plusieurs colonnes, il faut évidemment concaténer toutes ces colonnes. 14/16

15 10 Multiples associations entre entités Lorsque plusieurs associations existent entre deux entités, il faudra veiller à ce que les noms des colonnes de clés étrangères matérialisant ces associations ne prêtent à confusion. Dans l'exemple ci-dessous, nous avons deux associations entre Tour (en bateau) et Personnel; une des associations montre qu'un membre du personnel est requis comme pilote et la deuxième association montre qu'un copilote peut être requis. Déjà au niveau du MCD, nous conseillons de mettre des rôles aux deux extrémités de chaque association pour bien les différencier. 15/16

16 Lors de la transformation, il faut nommer les colonnes de clés étrangères en intégrant le rôle joué par l'entité parent en plus de son nom. Nous préconisons de préfixer les noms de colonnes de clés étrangères du nom (ou d'un raccourci) de la table parent et du nom (ou d'un raccourci) du rôle joué par la table parent. Important: Dans un souci de maintenabilité et surtout d'évolutivité d'une structure de base de données relationnelle, nous recommandons de toujours préfixer les noms de colonne de clé étrangère du nom et du rôle joué par la table parent de la relation. 16/16