Mise en place d'une base de données pour la gestion des carrières des agents dans une entreprise publique.

II.3.3.Passage du MCD au MLDB (Passage sur les objets et les Relations)

Dans cette partie, nous allons voir comment établir une modélisation des données au niveau logique (ou relationnel) à partir d'un modèle conceptuel.

A cet effet, la description conceptuelle a permis de représenter le plus fidèlement les réalités de l'univers à informatiser. Mais cette représentation ne peut pas être directement manipulée et acceptée par un système informatique.

70

Il est donc nécessaire de passer du niveau conceptuel à un second niveau plus proche de capacités des systèmes informatiques.

Ce niveau, appelé «niveau logique», consiste à choisir l'un des trois modèles suivants :

? Modèle Hiérarchique ; ? Modèle Réseau ;

? Ou modèle Relation.

Chacun de ces modèles repose sur des techniques d'organisation des données particulières que les logiciels seront capables de gérer.

Le passage du MCD au MLDB est conditionné par certaines règles de conversion que nous devons bien respecter afin de permettre à notre système à se conformer à la réalité.

Voici ci -dessous les quatre règles qui nous permettent de convertir notre Modèle Conceptuel de Données (MCD) au Modèle Logique de Données Brut (MLDB) :

Règle 1 : Conversion d'une entité.

? Toute entité du MCD devient une relation dont la clef est l'identifiant de cette entité ;

? Chaque propriété de l'entité devient un attribut de la relation correspondante.¹⁹

Règle 2 : Conversion d'association n'ayant que des cardinalités de type 0, 1, N.

Une association ayant des cardinalités 0,N ou 1,N de part et d'autre devient une relation dont la clef est composée des identifiants des entités reliées par cette association ; ces identifiants seront donc également des clefs étrangères respectives, on parle alors de «relation associative».

Les cardinalités plus respectives (Comme 2.3.1.7...) seront perçues comme des cardinalités de types 0, 1, N également (il s'agit en effet des sous ensembles). Cependant, les règles de gestion qui ne seront plus satisfaites par cette modélisation logique devront l'être par des traitements supplémentaires (via le code de l'application qui exploite la base de données ou encore par des triggers (déclencheurs) si le SGBD est suffisamment robuste.

¹⁹ Idriss NEUMANN, Cours initiation à la conception de bases de données relationnelle avec MERISE, http :// www.développez.Com

71

Dans le cas d'association porteuse des données, les données portées deviennent des attributs de la relation correspondante.²⁰

Règle 3: Conversion des associations ayant au moins une cardinalité de type 1,1.

Plusieurs possibilités s'offrent à nous pour ce cas de figure. La règle de conversion la plus répandue aujourd'hui est d'ajouter une clé étrangère dans la relation qui correspond à l'entité reliée par l'association. Lorsque l'on applique cette règle de conversion, deux restrictions s'imposent :

L'association ne peut être porteuse de données ; les données portées sont en dépendance fonctionnelle directe avec l'identifiant de l'entité dont la clé correspondante sera référencée par une clef étrangère dans une autre relation.

L'association doit être binaire (c'est -à -dire relier uniquement deux entités et pas plus). Lorsque deux entités sont toutes deux reliées avec une cardinalité 1,1 par une même association, on peut placer la clef étrangère n'importe quel coté. Par convention, on choisit de la placer du coté de la relation correspondant à l'entité ayant le plus de liaisons avec les autres. Certaines considèrent d'ailleurs que deux entités étant reliées par une association ayant une cardinalité 1,1 de deux côtés, doivent obligatoirement se fusionner. Cette règle s'appuie encore une fois sur la notion de dépendance fonctionnelle directe, mais n'est pas toujours respectée, (Il est parfois sémantiquement préférable de garder une distinction entre deux entités).

Une autre solution (moins rependue) consiste à créer une relation associative dont la clef est cette fois composée uniquement de la clef étrangère qui fait référence à l'identifiant de l'entité du coté opposé à la cardinalité 1,1.

Dans ce cas, l'association peut être porteuse de données, ces dernières deviendront donc des attributs de la relation associative comme dans le cas de cardinalité 0, 1, N.

Il va sans dire que la première solution est aujourd'hui préférable à cette dernière en termes d'optimisation et de simplification des requêtes.²¹

²⁰ Idem.

²¹ Idriss NEUMANN, Opcit

72

Règle 4 : Conversion des associations ayant au moins une cardinalité de type 0,1 (et dont les autres cardinalités sont de types 0, 1, N.)

De même que pour les cardinalités 1,1, une association ayant une cardinalité 0,1 doit être binaire, et par là deux possibilités s'offrent à nous :

1) Créer la clef étrangère dans la relation correspondant à l'entité du coté de la cardinalité 0, 1.

Rappelons que dans ce cas, l'association ne peut pas être porteuse de données.

2) Créer une relation associative qui serait identifiée de la même façon que pour une cardinalité 1, 1.

Cependant, dans le cadre d'une cardinalité 0, 1, nous verrons qu'il n'est pas toujours préférable de privilégier la première méthode comme c'est le cas pour une cardinalité 1, 1.

Certains diront que toutes les associations binaires de types père - fils ayant des cardinalités 1, N/ 0, N - 1, 1 / 0, 1 sont caractérisées par l'existence d'une dépendance fonctionnelle entre l'identifiant de l'entité père et l'entité fils.

La pertinence de l'une ou de l'autre méthode varie en fonction du nombre d'occurrences caractérisées par la cardinalité 0 ou la cardinalité 1.

En effet, lorsque les occurrences avec la cardinalité 1 sont plus nombreuses que les occurrences avec la cardinalité 0, la première méthode est plus préférable. Dans le cas contraire, c'est la seconde méthode qui est la plus adaptée.

Enfin, dans le cas où une association binaire possède à la fois une cardinalité 0,1 et une cardinalité 1,1 (ce qui est rarement le cas), il est préférable que la clef étrangère soit du coté de la relation correspondant à l'entité située du coté de la cardinalité 1,1.²²

²² Idriss NEUMANN, Opcit

73