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

Lire la 3ème 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