Actualites  Archives
 Inscription | Plan du site | 9  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

Les réactions


j'en fait un article d'un memoire de fin d'etude
par [16.08.2004 17:30 - Sake]
j'etais en train d'ecrire un memoire de fin d'etude BAC 2 et cet article m'a servi à decrire la methode que j'utilise.Que dire, c exelent!

Excellent !
par [09.07.2004 01:30 - albikom]
Un grand Merci pour ce petit cours Merise qui nous a permis de regler le pb des assos reflexives !
felicitations
tchuss

slambert@vediovis.fr
par [25.06.2004 00:56 - Stéphane LAMBERT] non non, une relation (0,n) <=> (0,n) n'est pas inutile. Elle tombe sous le coup de la règle (x,n) <=> (x,n) avec x=0 OU x=1, qui entraine la création ulèrieure d'une table de lien. A propos, pour ceux qui le voudraient : les supports de cours utilisée pour la licence professionelle de Paris V , avec exercices et anales, sont disponibles ici : www.vediovis.net/licence_pro/ Bon courage à tous. Stéphane LAMBERT

Reponse à Alphyfredard@yahoo.fr
par [24.05.2004 08:12 - Solidus]
Ben voilà tu demandais ce qu'il falait faire dans le cas d'une relation (0,n) (0,n).

il me semble que ce type de relation n'a pas lieu d'etre c'est un peu comme un relation (1,1)(1,1) qui ne sert a rien...En effet min 1, max 1 n'est pas utile , Donc tu ne dois faire qu'une seule entité...

Voilà

Merci pour ce cours!!!

tu a merdé
par [13.05.2004 11:39 - abouda] le dernier schemas du cours merise 2 est faux et ca m'a couté du temps (bonjour le retards) , un etudiant qui vous remerci commeme pour le reste du cours ------------------ | 0.1-------1.1 | ------------------ va donné des cles etrangéres dans les deux sens * <------ FK2 =PK1 et FK1 = PK2 ----> *

Beautiful
par [05.05.2004 11:35 - minelathi]
Simple, clair et precis :C'st un tres bon cours
si tous les cours etaient presentes de cette maniere ce serait tres interessant Merci
felicitations et bonne continuation!

Exellent
par [03.05.2004 11:53 - Moulay]
Bravo!par [5.5.2004 11:49 - Moulay]
Ce site est très intéressant et m'a appris rapidement ce que je voulais savoir. Avant cela, il m'avait été difficile de trouver des explications claires et accessibles à tous (toutes surtout!) ,cependant dont l'étape 4 dans quelle entité on doit stocker le tolal facture et la tva?
Merci

manque
par [01.04.2004 11:43 - michel]
Intéressant et concis, mais manque le plus important pour le MCD, les règles de vérification et de normalisation du modèle.

Bravo!
par [15.03.2004 16:29 - Sandrine]
Ce site est très intéressant et m'a appris rapidement ce que je voulais savoir. Avant cela, il m'avait été difficile de trouver des explications claires et accessibles à tous (toutes surtout!)

Clair
par [04.02.2004 10:58 - bob]
Ce cour a oute les qualités d'un vrai cour : il est clair, concis et précis. Il va à l'essentiel. On trouve peu d'infos comme ça avec des schémas qui explique bien ce qui doit ête expliqué. Le lecteur ne se noira pas dans un flot de mots pas toujours facile à assimiler. Bravo!

c'est bien
par [30.01.2004 17:37 - dina safa]
Nous sommes 2 étudiantes en système d'information,
nous avons apprécié la manière dont vous expliquez cette méthode. Bravo, continuez!!

no comment
par [13.01.2004 01:20 - momo]
ke dire dotre ke merci professeur pour ce cours.

Trés bien fait !
par [12.01.2004 14:22 - Popoleguen]
Merci pour ce cours,

je suis en 2em année de BTS informatique de gestion, et je suis un fumiste professionel, merci d'avoir éclairer les quelques points sombre que j'avais concernant l'analyse.


:p

Sympa!
par [20.12.2003 00:57 - Flora]
Merci, vous m'avez beaucoup aider comme pas mal d'autres personnes apparrement...
Je me souviendrai de ce site, tres clair et bien organisé.
A ciao bonsoir.

HE JE SUIS PAS D ACCORD
par [11.12.2003 16:22 - cams]
le mld et le mldr c pas pareil !
ce qui est présenté, c'est un mld...
le mldr est réparti suivant des sites ou des acteurs.

A méditer...

merçi beaucoup
par [13.11.2003 16:18 - marlon]
ce cours m'a permis d'éclairer les points sombres que j'avais concernant la méthode merise merçi beaucoup

MERCI
par [30.10.2003 23:50 - MAINA]
MERCI POUR VOTRE AIDE

question
par [22.07.2003 11:08 - al]
j'ai apprecié le cours merise 2eme partie mais j'aimerai savoir, au cas où nous avons une relation (0,1) - (0,1), que faut il faire pour la transformation en MLD.
Alphyfredard@yahoo.fr

Encouragement
par [26.06.2003 19:55 - benbekkouyoucef@yahoo.fr]
Merci beaucoup!
je trouve ce cours riche et facile à comprendre son contenu.
explication très simple sur la conception des systèmes d'information, surtout dans l'étape du passage du MCD vers le MLD relationnel ensuite au Modél physique de données qui es implimentable sur la machine.
toutes mes félicitaion encore pour votre travail.

congratulation
par [20.05.2003 04:13 - rab]
Bien que ce cour soit court et concis, je le trouve très clair et très interressant. Il offre une introduction à la conception de base de donnée très bénéfique notament pour les jeunes débutans et permet ainsi d'apréhender de manière seraine des problèmes plus complexes.

Merci

Vous êtes un sauveur!
par [25.02.2003 14:18 - PatriceDeSettat]
Cours clair et précis.Il m'a beaucoups aidé.Merci.

tres bon cours
par [27.01.2003 16:14 - xavier]
merci pour ce cours tres tres bien fait, je commence enfin à comprendre quelque chose.
J'ai reperé une petite erreur:

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).

je pense que pour la deuxieme il s'agit de 0 ou n parents (vivants sous entendu) non?


avis sur l'article
par [20.01.2003 15:10 - fatiha]
Je trouve cet article excellent car contrairement aux autres articles, il détaille chaque type de relation et ce du MCD jusqu'au modèle physique de données.

Merci
par [08.01.2003 09:47 - eliseafpa]
Merci pour cette magnifique synthèse pédagogique.
Je l'ai conseillé à mes stgiaires (futurs Webmasters...)
J'espère toute fois qu'il restera en ligne, car déontologiquement pour l'instant je me refuse à l'aspirer. Laissons à César..

remerciements
par [24.12.2002 15:53 - aniya]
je tiens à vous remercier pour ce support de cours que je compte utiliser pour actualiser mes enseignements au futurs techniciens superieurs en informatique.

tres bonne presentation
par [23.12.2002 09:50 - Slayer]
Juste un petit message de félicitation pour ce petit cours sur MERISE.Encore Merci

Conception
par [13.12.2002 18:49 - moonsmileparis]
Felicitation pour ce cours, vraiment clair.
Il faudrait aussi dire au neophytes pour eviter de faire des betises:
1) Toute clef doit etre unique.
2) Tout Attribut (non clef) ne doit dependre que de la clef (Et jamais d'une partie de cette derniere ou d'un autre attribut).

l'age
par [30.10.2002 18:28 - chipo]
Bonjour
tout d'abord je souhaite vous féliciter pour ce cours.
Je souhaite aussi apporter une remarque concernant la partie 1, l'entité ABONNES :
Vous y mettez l'attribut "age". chaque année, pour obtenir l'age exacte d'un abonné, il va falloir ajouter 1 a tt les ages des abonnés.
Ne serait-il pas plus judicieux d'y mettre la date de naissance ?

 
 

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