Le MCD exprime l'aspect conceptuel d'un système d'information.
Le Modèle Relationnel (MR) le niveau logique ou organique (dans le sens organisation).
Il contient le Séma Relationnel des Données : SRD (appelé courament MR, par abus de langage)

Pour créer le MR il existe différentes techniques :
Passer du MCD au MR avec les règles de transposition,
Utiliser les dépendances fonctionnelles (tableau ou graphe de DF) pour créer le MR

Retour index

1.1 Graphe des DF

Les dépendances fonctionnelles expriment la dépendance des données entre-elles.
(Cf. document : cgo121.html : DD et GDF)
Le graphe est représenté sous la forme :

1.2 SCD : Schéma conceptuel des données ou schéma entité/association (MEA)

Le schéma conceptuel représente, sous forme graphique, la totalité des données gérées et une partie des règles de gestion
(Cf. documents : cgo122.html : le MCD et cgo123.html : du GDF au MCD)

1.3 SRD : Schéma Relationnel des Données

Le schéma relationnel des données expose les données et la façon dont elles sont en reliées, sous forme de relations.
A la fin de cette étape, on complète le DD en précisant le type et la longeur de chaque donnée.

1.4 MPD : modèle physique des données

Le SPD expose clairement comment sont implémentées les tables de la base de données et prépare le travail du codeur pour effectuer les requêtes SQL ou l'écriture des tables dans le SGBD.

Remarquez que nous sommes encore en langue française, mais que nous aurions pu écrire directement les requêtes de création de table. Cependant, tous les SGBDR ne nécessitent pas le SQL pour créer les tables et ont des assistants performants (MS-Access).

1.6 Identifier chaque ligne : la clé primaire

Dans une entité, nous avons une propriété qui identifie de façon unique chaque occurrence de l'entité.
Cet identifiant est transformé en attribut (champ ou "colonne" dans la table physiquement implantée dans la base).
Cet attribut joue alors un rôle particulier, il identifie chaque tuple (enregistrement ou ligne) dans la relation.
On l'appelle clé primaire.

Si la clé primaire est composée de plusieurs attributs, c'est l'ensemble qui doit être unique.

1.6 Clé étrangère, Ques Aquo ?

Domaine

L'ensemble des valeurs que peut prendre un attribut s'appelle le domaine (de valeurs) de cet attribut.
Ainsi, le domaine de valeurs du taux de TVA, en france, est {5.5, 19.6, 33.3}. Il n'y a pas d'autre valeur.

Référencement

Lorsqu'un attribut est clé étrangère, il fait référence à un attribut qui se trouve dans une autre table.
Son domaine de valeur n'est donc pas libre. Dans ce cas, on marque cette dépendance (fonctionnelle!) en ajoutant une ligne qui l'exprime :
Ou, dans l'ancien formalisme, en marquant l'attribut par un caractère # collé au nom : codeTVA#
(cependant, on perd l'infomation de quel champ est référencé dans quelle table)

Cas où des champs de la clé primaire sont aussi clé étrangère.
Certains de mes collègues ne demandent pas de signaler qu'un attribut soit clé étrangère si celui-ci fait partie de la clé primaire (comme dans la relation Acheter ci-dessus).
En fait, il faut le faire car sinon, on perd l'information du fait que le contenu (les valeurs autorisées, le domaine) n'est pas libre mais provient d'un attribut d'une autre table.
Les notions de clé primaire et de clé étrangère sont totalement indépendantes, même si une clé étrangère référence (presque) toujours un attribut clé primaire.

Retour index

Le passage du MCD au MR est direct, par l'application des règles suivantes

2.1 Règles sur les entités

Règle 1 : Toute entité devient une relation
Règle 2 : Les propriétés de l'entité deviennent des attributs de la relation.
Règle 3 : L'identifiant de l'entité devient la clé primaire.

2.2 Règles sur les associations

Note : x,n représente, indifféremment, une cardinalité 0,n ou 1,n

Règle	C1	C2	Règle
R4	x,1	x,n	Apparition d'une clé étrangère. Toute association hiérarchique (ou CIF), provenant d'une dépendance fonctionnelle entre deux entités, disparaît. L'identifiant de l'entité de cardinalité 2 est ajouté à la relation de cardinalité 1 et devient une clé étrangère. Ajouter la mention : < nomCléEtrangère > référence < nomCléPrimaireRéférencée > dans < nomTableRéférencée > Les éventuelles propriétés de l'association deviennent des attributs de la relation. Attention, si on a la cardinalité 0,1 spécifier que la clé étrangère peut être nulle. E1(id1, propr1,, id2, proprA) Clé primaire : id1 Clé étrangère : id2 référence id2 dans E2
R5	x,n	x,n	Association transformée en table. Toute association non hiérarchique (ou CIM) est transposée en une relation. Elle est porteuse de tous les identifiants des associations participantes qui deviennent une seule clé primaire de la relation. Les propriétés de l'association deviennent des attributs de la relation Asso(id1, id2, proprA) Clé primaire : id1, id2 Clé étrangère : id1 référence id1 dans E1 Clé étrangère : id2 référence id2 dans E2
R6 (Rare)	x,1	0,1	Cas rare et difficile à transposer Cas général : L'association est non porteuse de propriétés : Ce type de relation se comporte comme pour la règle 4 E1(id1, propr1,, id2) Clé primaire : id1 Clé étrangère : id2 référence id2 dans E2 Cas particulier : L'association est porteuse de propriétés : Si le nombre d'occurrences de la relation est faible, alors, Se reporter à la règle 5 : trois relations. Asso(id1, id2, proprA) Clé primaire : id1, id2 Clé étrangère : id1 référence id1 dans E1 Clé étrangère : id2 référence id2 dans E2 Sinon, comme à la règle 4, on rapatrie les attributs dans la relation qui aura la clé étrangère. E1(id1, propr1,, id2, proprA) Clé primaire : id1 Clé étrangère : id2 référence id2 dans E2
R7	(x,1)	x,n	Entité faible ou dépendante : clé étrangère qui fait partie de la clé primaire L'identifiant est aussi appelé identifiant relatif. pour être absolu, il faut connaître la valeur de la clé étrangère dont il dépend. Clé étrangère et propriétés : idem règle 4 La clé étrangère devient le premier attribut de la clé primaire, composée de la clé étrangère et de l'identifiant de l'entité faible. E1(id2, id1, propr1,, proprA) Clé primaire : id2, id1 Clé étrangère : id2 référence id2 dans E2

Remarque :
Une association 1,1 <-> 1,1 est impossible, il y a une erreur dans le MCD !!!
Les deux entités devraient fusionner

Retour index

3.1 Noms des attibuts

Lors du choix du nom d'une propriété, d'un attribut ou d'un champ de base de données, ne pas utiliser de caractères spéciaux dans les noms (accent autorisés pour propriétés et attributs) et coller les mots en mettant une majuscule entre chaque mot mais pas au début. Exemples : nomClient, codArt.
Réservez les noms commençant par une majuscule aux entités et relations.

Dans le modèle physique, vous chasserez les accents de tout nom.

3.2 Ecriture du SRD

Il existe deux formalismes pour représenter les relations. Mais depuis peu, les directives imposent la représentation explicite dans le schéma relationnel.

a) La relation est suivie de la liste des attributs, séparés par une virgule, entre parenthèse.
b) Les attributs de la clé primaire sont (tous) indiqués dans la mention 'clé primaire', sous la relation.
c) Les clés étrangères sont indiquées dans une mention par 'clé étrangère', sous l'indication 'clé primaire'.
Si des champs de la clé primaire qui sont aussi clé étrangère.
Certains de mes collègues ne demandent pas de mettre de # à un attribut clé étrangère, si celui-ci fait partie de la clé primaire (comme dans la relation Acheter ci-dessus).
En fait, il faut le mettre car, ce n'est plus un avatar d'une erreur d'interprêtation comme à l'origine, mais c'est une marque pour dire que cet attribut est une clé étrangère (il référence un attribut d'une autre relation).
Si on ne le marque pas, on perd l'information du fait que le contenu (les valeurs autorisées, le domaine) n'est pas libre mais provient d'un attribut d'une autre table.
Les notions de clé primaire et de clé étrangère sont indépendantes.

Retour index

4.1 Règle 4 : 1->n

Si la cardinalité est 0,1, indiquer : "avec #code… admettant des valeurs "nulles""

4.2 Règle 5 : n->n

Note : dans 'acheté', codeArt et codeFou sont souliné par un seul trait (la virgule aussi).
Cela exprime que la clé complète intègre tous les attribut soulignés.
Le prix reste dans la nouvelle relation.

4.3 Règle 6

4.4 R4 bis

Retour index

Elaborez les MR ou MCD suivants :
Note : Les corrigés sont fournis. Essayez tout de même de résoudre les exo avant de voir les corrigés...

5.1 Adjugé, Vendu !

5.2 Horaires de trains

5.3 Quel chantier !

A partir du SR ci-dessous, reconstruire le SCD associé.
On n'a pas dit que c'est facile ...

Retour index

Soit la spécialisation suivante :
L'entreprise gère deux types d'articles, ceux qui sont achetés et ceux qui sont vendus.
Les articles sont définis par un code, une description, un poids.
Les articles achetés ont en plus un prix d'achat.
Les articles fabriqués ont une matière de base.

Le modèle étendu (merise 2) nous donne :

Rappel des contraintes de spécialisation : X=exclusion : une occurrence appartenant a l'une des deux entité spécialisée ne peut appartenir à l'autre. T=totalité : la somme des occurrences des entités spécialisées représente toutes les occurrences de l'ensemble des entités. Ici : un article acheté ne peut pas être produit, tout article est soit acheté, soit produit

Comment transformer ceci en modèle relationnel ?

Deux méthodes :

a) théorique merise 1

La spécialisation se traduit par la codification d'un type effectuant la spécialisation :
c'est un peu bancal car il faut indiquer explicitement qu'un article acheté n'a pas de matière de base et vis versa.

b) théorique merise 2

La spécialisation donne lieu à trois tables (selon la contrainte de spécialisation, ici XT=exclusion et Totalité : un article est soit acheté soit fabriqué, mais pas les deux en même temps ni aucun des deux).
Ici, plus de problème de modélisation, il restera une légère complication pour l'implémentation, celle de garder en cohérence les tables spécialisées avec la table générique.

Retour index

Passer du SCD au schéma relationnel de base doit être une formalité, à ceci près qu'il faut, en toute circonstances effectuer un retour au texte descriptif de l'organisation (le sujet), pour vérifier que notre SR est toujours cohérent.

Le cours sur l'analyse se poursuit en seconde année par les extensions au modèle conceptuel (voir ce cours).
En prmière année, le cours se poursuit par l'extraction des données de la base à l'aide de langages structurés (algèbre relationnelle, SQL)

En attendant, allez donc voir l'exercice d'application associé à ce dossier : cliquez ici

Retour index page - Retour index général