Actualites  Archives

The domain name sam-mag.com is available for sale!

 Inscription | Plan du site | 8  visiteurs actifs  
  
     A la Une
  Actualités
  Dossiers
  Coin Technique
  Annonces Web
  Référencement

     Diagnostic
  Popularité Site Web
  Positionnement Moteur
  WebPage Alerte
  Positionnement Google

     Archives
  Sélection
  Expérience qui parle
  Internet quotidien
  Tous les dossiers

     Services
  Communiqués de Presse

     Contact
  Nous contacter
  La protection des données personnelles

     Technique
  Merise

     Login
   
    
Inscription

Mot de passe oublié?

 Merise


Merise : 2ème partie
Après avoir conçu le Modèle Conceptuel de Donnée (MCD), il est maintenant temps de le transposer en Modèle Logique de Données Relationnelles (MLDR). Ce MLDR est en fait le dernier pas vers le Modèle Physique de donnée(MPD), c'est à dire la description de la base qui va être crée. Et là, deux solutions s'ouvrent à vous : soit vous laissez à un programme le soin de transformer votre MCD, soit vous le faîtes vous-même. Dans les deux cas, il est utile d'avoir un minimum de connaissance théorique sur le sujet. Après avoir définis les notions de clé primaire et de clé étrangère, nous étudierons plus particulièrement aujourd'hui les 6 règles strictes, nécessaires et suffisantes pour passer d'un MCD à un MLDR, et nous les appliquerons ensuite au schéma de Newsletter que nous avons écris la dernière fois.

Préliminaires : le Modèle Logique de Donnée (MLD)

Il s'agit du passage entre le Modèle Conceptuel de Donnée et l'implémentation physique de la base. Le MLD est lui aussi indépendant du matériel et du logiciel, il ne fait que prendre en compte l'organisation des données. C'est d'ailleurs le point primordial de la modélisation : si l'organisation des données est relationnelle (si elles sont "liées" entre elles), alors le MLD est Relationnel et devient le MLDR, ou Modèle Logique de Donnée Relationnel. Pour la petite histoire, le MLDR a été inventé par Codd en 1970, et repose sur la Théorie Ensembliste...

Un peu de vocabulaire : Les données sont stockées dans des relations. Une relation est un ensemble de T-uple, et un T-uple est définis par un ou plusieurs attributs. Dans la pratique, la relation est en fait la table, un
T-uple
est une ligne (ou enregistrement), et les attributs sont les colonnes.

Exemple de la table NEWSLETTER :



Cette table est décrite par :
NEWSLETTER (id_newsletter, Sujet, DateEnvoie, Contenu, #id_rubrique)

Chaque enregistrement doit être identifié de manière unique (voir la notion d'identifiant abordée dans l'article précédent). L'attribut qui permet d'identifier de façon unique chaque ligne est appelée la Clé Primaire. Elle peut être composée, c'est à dire comprendre plusieurs attributs. Ici, il s'agit de l'attribut id_newsletter.

La table Newsletter comprend un attribut provenant de la table RUBRIQUES, l'attribut id_rubrique. Cet attribut est appelé Clé Etrangère.

Dans le formalisme, la clé primaire est soulignée, et la clé étrangère est précédée du signe #. D'où l'écriture définitive :

MATABLE (Cle_Primaire, Colonne1, Colonne2, #Cle_Etrangere)

Dans notre exemple :

Rubrique (id_rubrique, Nom)
Newsletter (id_newsletter, Sujet, DateEnvoie, Contenu, #id_rubrique)

Ici, id_rubrique est la Clé Primaire de la table RUBRIQUE, et est une Clé Etrangère dans la table NEWSLETTER.

Une fois assimilée ces notions de clés primaires et de clés étrangères, nous pouvons maintenant énoncer les règles suivantes :

1 : Une entité se transforme en une relation (table)

Toute entité du MCD devient une relation du MLDR, et donc une table de la Base de Donnée. Chaque propriété de l'entité devient un attribut de cette relation, et dont une colonne de la table correspondante. L'identifiant de l'entité devient la Clé Primaire de la relation (elle est donc soulignée), et donc la Clé Primaire de la table correspondante.

<==> CLIENT (id_client, Nom_Client, Tel_client)

2 : Relation binaire aux cardinalités (X,1) - (X,n), X=0 ou X=1

La Clé Primaire de la table à la cardinalité (X,n) devient une Clé Etrangère dans la table à la cardinalité (X,1) :

Exemple de Système d'Information (SI) :

Un employé a une et une seule société. Une société a 1 ou n employés.

Modèle Conceptuel de Donnée (MCD) :


Modèle Logique de Donnée Relationnelle (MLDR) :

EMPLOYE (id_Employe, Nom_Employe, #id_Societe)
SOCIETE (id_Societe, Nom_Societe)

Modèle Physique de Donnée (MPD), ou schéma de base :

3 : Relation binaire aux cardinalités (X,n) - (X,n), X=0 ou X=1

Il y a création d'une table supplémentaire ayant comme Clé Primaire une clé composée des identifiants des 2 entités. On dit que la Clé Primaire de la nouvelle table est la concaténation des Clés Primaires des deux autres tables.
Si la relation est porteuse de donnée, celles ci deviennent des attributs pour la nouvelle table.

S.I. :

Une commande est composée de 1 ou n produits distincts en certaine quantité. Un produit est présent dans 0 ou n commandes en certaine quantité.

MCD :


MLDR :

COMMANDE (id_Commande, Date_commande)
PRODUIT (id_Produit, libelle)
COMPOSE (id_Commande, id_Produit, qantité)

MPD :

4 : Relation n-aire (quelles que soient les cardinalités).

Il y a création d'une table supplémentaire ayant comme Clé Primaire la concaténation des identifiants des entités participant à la relation.
Si la relation est porteuse de donnée, celles ci deviennent des attributs pour la nouvelle table.

S.I. :

Un étudiant parle une ou plusieurs langues avec un niveau. Chaque langue est donc parlée par 0 ou n étudiants avec un niveau. Pour chaque niveau, il y a 0 ou plusieurs étudiants qui parlent une langue.

MCD :

MLDR :

ETUDIANT (id_Etudiant, Nom_Etudiant)
NIVEAU (id_Niveau, Nom_Niveau)
LANGUE (id_Langue, Nom_Langue)
PARLE (id_Etudiant, id_Niveau, id_Langue)

MPD :

5 : Association Réflexive.

  • Premier cas : cardinalité (X,1) - (X,n), avec X=0 ou X=1.


  • La Clé Primaire de l'entité se dédouble et devient une Clé Etrangère dans la relation ou nouvelle table. Exactement comme si l'entité se dédoublait et était reliée par une relation binaire (X,1) - (X,n) (Cf règle 2).

    S.I. :

    Prenons l'exemple d'une société organisée de manière pyramidale : chaque employé a 0 ou 1 supérieur hiérarchique direct. Simultanément, chaque employé est le supérieur hiérarchique direct de 0 ou plusieurs employés.

    MCD :


    MLDR :

    EMPLOYE (id_Employe, Nom_Employe, #id_Sup_Hierarchique)

    #id_Sup_Hierarchique est l'identifiant (id_Employe) du supérieur hiérarchique direct de l'employé considéré.

    MPD :



  • Deuxième cas : cardinalité (X,n) - (X,n), avec X=0 ou X=1.


  • De même, tout se passe exactement comme si l'entité se dédoublait et était reliée par une relation binaire (X,n) - (X,n) (Cf règle 3). Il y a donc création d'une nouvelle table.

    S.I. :

    Prenons cette fois l'exemple d'une organisation de type familiale : chaque personne a 0 ou n descendants directs (enfants), et a aussi 0 ou n descendants directs (enfants).

    MCD :


    MLDR :

    PERSONNE (id_Personne, Nom_Personne)
    PARENTE (#id_Parent, #id_Enfant)

    #id_Parent est l'identifiant (id_Personne) d'un ascendant direct de la personne. #id_Enfant est l'identifiant (id_Personne) d'un descendant direct de la personne.
    La table PARENTE sera en fait l'ensemble des couples (parents-enfants) présent dans cette famille.

    MPD :

6 : Relation binaire aux cardinalités (0,1) - (1,1).

La Clé Primaire de la table à la cardinalité (0,1) devient une Clé Etrangère dans la table à la cardinalité (1,1) :

S.I. :

Dans ce centre de vacances, Chaque animateur encadre en solo 0 ou 1 groupe, chaque groupe étant encadré par un et un seul animateur.

MCD :


MLDR :

ANIMATEUR (id_Animateur, Nom_Animateur)
GROUPE (id_Groupe, Nom_Groupe, #id_animateur)

MPD :

CONCLUSION

Ces 6 règles représentent TOUS les cas que vous pourrez rencontrer. Il ne faut surtout pas se laisser impressionner par le nombre de schémas, ni se laisser intimider par le coté inhabituel du processus de modélisation. Il est très simple à acquérir. En fait, au bout de quelques modélisations et d'un ou deux développements, vous vous rendrez compte que finalement tout ceci est très logique et d'une évidence rare... Et surtout, surtout, votre base de donnée correspondra EXACTEMENT au système d'information décris dans le cahier des charges. De plus, écrire le MCD, le valider avec votre client, puis en déduire le MLDR et donc le Modèle Physique vous fera rentrer complètement dans le chantier. Vous irez ensuite beaucoup plus vite, avec très peu de risque d'être hors sujet. Après, la majorité du travail restant ne sera plus qu'une question de requètes, de mise en forme et d'ergonomie, avec une bonne gestion d'Entrée/Sortie de l'information...

Allez, si vous êtes encore avec moi, vous avez bien mérité la fin de l'analyse de notre Newsletter du mois de décembre :


Entraîne le MLDR suivant :

MOTIVATIONS ( id_Motivation, Intitule)
ABONNES ( id_Abonne, #id_Motivation, Nom, Prenom, Age, Sexe, Profession, Rue, CodePostal, Ville, Telephone, Email)
S_INSCRIT ( id_Abonne, id_Rubrique)
RUBRIQUES ( id_Rubrique, Nom_Rubrique)
NEWSLETTERS ( id_Newsletters, #id_Rubrique, Sujet, DateEnvoie, Contenu)


Qui nous mène au Modèle Physique de Donnée (MPD) ou schéma de la
Base :


<<Lire la 1ère partie  

Stéphane Lambert
http://www.vediovis.fr/

Spécialisé dans le développement Web, Stéphane LAMBERT
a fondé VEDIOVIS PRODUCTIONS en Mai 2000.
Son expérience couvre essentiellement les sites à fortes audiences,
institutionnels ou audiovisuels.

Tous droits réservés - Reproduction même partielle interdite sans autorisation préalable

 Imprimer Donner votre avis

 
 

Sam-Mag - Un site du réseau ACORUS 1996-2007
© Copyright ACORUS All rights reserved.- Mentions légales

Ce site respecte la loi Informatique et Libertés. Pour en savoir plus sur la protection des données personnelles, cliquez

 
Webmaster