Master 2 C.G.A.O. - A.

Olivier

Analyse et conception d’une base de données - Cours 1 -

Organiser les données (1) - Le Modèle conceptuel des données

Un problème de gestion Un outil informatique

Un utilisateur doit décider, agir dans son organisation. Il a be- Logiciel de gestion de base
soin d’information pour résoudre un problème particulier. Il veut de données
automatiser certains traitements.
On distingue trois niveaux d’analyse :

Le niveau conceptuel : le Modèle Un modèle dit conceptuel permet de définir, à partir

Conceptuel des Données (cours 1) d’un problème de gestion les objectifs, les contraintes
Quoi faire? et les informations dont on a besoin.
Quelles informations? Le modèle conceptuel des données (MCD, ap-
pelé aussi modèle entité-association) est un outil for-
malisé d’aide à la conception d’une base de donées.

Le niveau logique ou l’organisa- Rendre le MCD exploitable par le logiciel de gestion

tion logique des données : le Schéma
Relationnel (cours 2)
Comment le faire?
Comment structurer les données?
de bases de données en transformant le M.C.D. en
schéma relationnel.
Le schéma relationnel décrit l’organisation des en-
tités, ainsi que les clés qui permettront de définir les
liens entre les entités.

Niveau physique : Où stocker les données?

Comment faire? Quel logiciel de gestion de base de données choisir?
(cours Access, cours Programmation et Quelles tables?
bases de données, etc.) Quels identifiants?
Quels index?
Quelles relations?
Un exemple de MCD : gestion (très) simplifiée de la base de données d’une compagnie aérienne.

figure 1
Nous trouvons dans ce modèle :
– Trois entités (Pilote, Vol et Avion), ayant chacune un identifiant (NuméroPilote pour l’entité Pilote
par exemple) ;
– Deux associations (Effectuer et Nécessiter ) définissant les relations entre les entités, chacune étant
dotée de cardinalités (1,1 ou 1,n ou O,n) précisant le type de la relation.
Revenons plus en détail sur le vocabulaire spécifique au M.C.D (paragraphe 1).
Puis nous verrons comment concevoir un M.C.D. (paragraphe 2).
Organiser les données - Le M.C.D. - Master 2 C.G.A.O. - A. Olivier 2

1 Le vocabulaire et les règles du MCD

1.1 L’entité
La connaissance de l’activité de l’organisation et des procédures de gestion, permet de définir les
ensembles de données nécessaires à la gestion : les entités.
Une entité un ensemble d’informations homogènes ou portant sur le même thème.
Les informations élémentaires qui décrivent une entité sont appelées attributs de l’entité (ou pro-
priétés).
Ces informations élémentaires suivent le principe de l’atomicité : l’information doit être divisée
jusqu’au niveau limite des traitements informatiques.
Chaque élément constitutif de l’entité (chaque “enregistrement”) est appelé une occurence.
Un attribut dont la valeur particulière permet d’identifier de façon unique une occurrence de l’entité
est l’identifiant de cette entité.
L’identifiant est aussi appelé clé primaire.
Les clés étrangères, c’est-à-dire les attributs permettant de faire le lien entre deux entités n’appa-
raissent pas dans les entités.

Exemple :

Adherents Sport Noms des entités

NomAdherent CodSport Identifiants ou Clés primaires
Deux adhérents ne peuvent avoir le même nom.
Deux sports ne peuvent avoir le même code.
Prenom Sport Liste des attributs pour chaque entité.
Age Cotisation
Niveau NomMoniteur
“Lefranc - Paul - 26 - 3” est une occurence de l’entité Adherents.
“05 - Tennis - 230 - Duchemin” est une occurence de l’entité Sport.
Remarque : l’attribut CodSport constituera le lien entre les deux entités
(à un adhérent sera attaché un CodSport). Il n’apparaı̂t cependant pas
dans l’entité Adherents.

1.2 L’association
Une association définit un type de lien, un type de relation, entre deux ou plusieurs entités.
Dans un système d’information, une association correspond à une ou plusieurs règles générales d’or-
ganisation ou de logique.
Le nom de l’association est en général un verbe.
Exemple 1 :
Encadrer représente la liaison entre l’entité Moniteurs et l’entité Stages.
Suivre représente la liaison entre l’entité Stages et l’entité Adhérents.

figure 2
Une association relie généralement deux entités (association binaire).
Elle peut aussi relier trois entités (association ternaire).
Organiser les données - Le M.C.D. - Master 2 C.G.A.O. - A. Olivier 3

Exemple 2 :

fig 3
L’association binaire est la plus fréquente. Dans l’exemple ci-dessus, elle peut se lire ainsi : un client
commande un ou plusieurs produits.
L’association ternaire est beaucoup plus rare, Dans notre exemple, cela donne : un client commande
un ou plusieurs produits commandés eux-mêmes à un fournisseur identifié.
Chaque occurrence (ou réalisation) d’une association correspond à la combinaison des occurences
des entités qui participent à cette association.
Par exemple, dans le cas de notre association binaire, une occurence de l’association Commande
(c’est-à-dire une commande) rassemble toutes les caractéristiques du client ET du produit associé à cette
commande.
Si cette commande regroupe plusieurs produits, elle correspondra à autant d’occurences qu’il y a de
produits.
La clé primaire (l’identifiant) d’une association est le couple constitué par les clés des identifiants
des entités qu’elle relie.
Les clés des associations ne sont pas notées dans la représentation de l’association.
A cet attribut double, on peut ajouter d’autres attributs. Une association peut, en effet, avoir des
attributs propres, outre les identifiants des entités associées.
Les attributs propres des associations sont notées sur le MCD.

Exemple 3 :

figure 4
Le binôme NuméroFournisseur - CodeProd constitue l’identifiant de l’association Catalogue.
Cela peut se traduire ainsi : une référence ou occurence du catalogue est identifiée de façon unique par
deux éléments : le numéro du fournisseur et le code produit qui lui sont associés.
Chaque référence (chaque ligne) du catalogue possède en outre un attribut propre : le prix.

1.3 Les cardinalités

Une cardinalité, dans une association, exprime le nombre de participations possibles d’une occurrence
de chaque entité à l’association.
Ce nombre pouvant varier, une cardinalité est en fait constituée d’un couple contenant un nombre
minimum et nombre maximum.
Une association étant reliée à deux (éventuellement trois) entités, elle sera dotée de deux (ou 3) couples
de cardinalités (un par entité).
Organiser les données - Le M.C.D. - Master 2 C.G.A.O. - A. Olivier 4

Couples de cardinalités possibles :

– 0,1 : au moins 0, au plus 1
– 1,1 : au moins 1, au plus 1
– 0,n : au moins 0, au plus n
– 1,n : au moins 1, au plus n

Exemple 1 : Exemple 2 :

figure 5 figure 6

Un ouvrage peut être associé à un auteur au mi- Un client peut commander a produits au mini-
nimum et 8 au maximum. mum et b au maximum.
Un auteur peut figurer sur un ouvrage au mini- Un produit peut être commandé par c clients au
mum et n au maximum. minimum et d au maximum.

Les couples de cardinalités les plus fréquents sont :

– 1,1 et 1,n - cette combinaison définit une association dite hiérarchique ;
– 1,n et 1,n - cette combinaison correspond à une association non hiérarchique.
On rencontre également parfois la double cardinalités 1,1 et 1,1.
Les cardinalités avec 0 comme valeur minimale font l’objet d’un traitement particulier. Nous y revien-
drons dans le cours 2.

1.4 L’association hiérarchique (cardinalité 1,1 - 1,n)

Une association entre deux entités est hiérarchique si la réalisation de l’une des entités détermine la
réalisation de la seconde. Elle est associée à une cardinalité 1,1 d’un côté et 1,n de l’autre.
On dit que cette association représente une contrainte d’intégrité fonctionnelle (CIF).

Exemple 1 : Exemple 2 :

figure 7 figure 8

L’existence d’une entité Classe dépend de celle L’existence d’une entité Editeurs dépend de celle
d’une entité Elève. d’une entité Ouvrages.
Un élève appartient à une seule classe. Un ouvrage est publié par un éditeur unique.
Une classe regroupe de 1 à n élèves. Un éditeur publie de 1 à n livres.

Elle est aussi appelée Relation père-fils :

Un fils n’a qu’un père ; un père a plusieurs fils.
Organiser les données - Le M.C.D. - Master 2 C.G.A.O. - A. Olivier 5

Les relations Père-Fils ont une cardinalité 1,1 (pour le Fils) et 1,n (pour le Père).
Une association hiérarchique ne peut PAS être porteuse de propriété (attribut) propre.

Remarque : La définition des cardinalités dépend du problème de gestion ou du cahier des charges.
Prenons quelques exemples :

– Figure 5 : le nombre maximal d’auteurs est fixé à 8 par les règles de gestion ; on exclut qu’un ouvrage
puisse être anomyme puisque le nombre d’auteurs minimal est de 1.
– Figure 7 : une classe peut n’avoir qu’un seul élève, ce qui correspond rarement à la réalité.
– Figure 8 : un ouvrage n’a qu’un seul éditeur, ce qui exclut les parutions en co-édition.

1.5 L’association non hiérarchique (cardinalité 1,n - 1,n)

A contrario, dans une association non hiérarchique, aucune des entités n’a besoin de l’autre pour
exister. Des deux côtés de l’association, la cardinalité est 1,n.
On dit que cette association représente une contrainte d’intégrité multiple (CIM).
Une association non hiérarchique peut être porteuse d’attributs propres
On rappelle que l’identifiant d’une association est constitué par le couple des identifiants des entités
participant à l’association. A cet identifiant double peuvent donc, dans ce cas, s’ajouter des propriétés
spécifiques à l’association.

Exemple : Nous pouvons compléter les cardinalités du MCD de la figure 4.

figure 9

L’association Catalogue est pourvue d’un double identifiant et d’un attribut propre, soit, au total de
3 attributs dont un seulement apparaı̂t sur le MCD.
Les cardinalités précisent :
Un produit peut être référencé par plusieurs fournisseurs.
Un fournisseur peut proposer plusieurs produits.
Par conséquent, voici les occurrences que nous rencontrerons, par exemple, dans cette association :

NumeroFourn CodeProd Prix

F0024 P567 2,55
F0024 P006 7,90
F0143 P006 12,35
F0067 P197 9,90
... ... ...

On peut rencontrer plusieurs fois le même numéro de fournisseur, et plusieurs fois un code produit
identique. Mais une seule fois un couple NumeroFournisseur - CodeProd.
Ces deux clés concaténées constituent, comme nous l’avons vu page 3, l’identifiant de l’association.
Organiser les données - Le M.C.D. - Master 2 C.G.A.O. - A. Olivier 6

1.6 Les cas particuliers d’associations

Certains types particuliers d’associations seront étudiés dans le cours 2. Il s’agit :
– des cardinalités 0,
– des associations réflexives (reliant une entité à elle-même) hiérarchiques,
– et des associations réflexives non hiérarchiques.

2 La méthode de construction d’un MCD

2.1 Les règles pour la définition des entités et des associations

Règle 1 - Respecter le principe de l’atomicité. l’information doit être divisée jusqu’au niveau limite des
traitements informatiques.
Par exemple, l’attribut Adresse n’est pas pertinent mais doit être découpé en plusieurs attributs :
numéro de rue, type de voie, nom de la voie, code postal, ville...
Règle 2 - Supprimer les synonymes ou termes différents désignant la même information.
Par exemple CodeClient et NumClient.
Règle 3 - Eviter les termes désignant ou pouvant désigner deux informations différentes.
Par exemple CodeProd utilisé deux fois, l’une pour les produits finis et l’autre pour les produits
intermédiaires.
Ou CodeProd lorsque l’on ne sait pas s’il désigne le produit fini ou le produit intermédiaire.
Règle 4 - Supprimer les données constantes, c’est-à-dire dont la valeur sera identique pour toutes les
occurences.
Exemple : le taux de TVA s’il est unique.
Règle 5 - Ne pas créer d’attributs calculés, c’est-à-dire que l’on pourra retrouver ultérieurement en effec-
tuant des calculs (dans une requête par exemple).
Exemple : montant total, coût total par produit, etc.
Règle 6 - Contrôler l’existence d’un identifiant pour chaque entité.
Cette règle permet d’aider le concepteur quand celui-ci hésite entre une entité ou une association
pour modéliser un concept.

Si un identifiant unique est attaché à un ensemble cohérent d’informations, alors il

faut modéliser cet élément par une entité. Sinon, c’est-à-dire s’il faut plus d’une clé
pour identifier chaque occurence de cet ensemble, il faut définir une association.

Exemple (figure 10) :

Si le cahier des charges exclut la création d’un Si l’on utilise un numéro de commande, alors
code ou numéro de commande, alors l’identi- celui-ci est l’identifiant de chaque commande.
fiant de la commande sera double : Numéro de Commande est une entité.
client et Code produit.
Commande est une association.
Organiser les données - Le M.C.D. - Master 2 C.G.A.O. - A. Olivier 7

Règle 7 - Tous les attributs autres que l’identifiant doivent être en dépendance directe de l’identifiant.
Si ce n’est pas le cas, alors l’entité peut être divisée en deux sous-ensembles, dont chaque
attributs respectera cette règle.
Exemple :

figure 11
Le numéro d’immatriculation permet d’identifier la couleur du véhicule, son modèle et, indi-
rectement, sa marque. L’attribut Marque ne dépend pas directement de l’immatriculation du
véhicule, mais de son modèle. C’est le modèle qui détermine directement la marque et non le
numéro d’immatriculation.
La solution 1 ne respecte pas la règle de dépendance directe.
Les deux attributs Marque et Modèle seront donc sortis de cette entité pour constituer un
nouvel ensemble, dont l’identifiant sera Modèle (solution 2).

2.2 Le dictionnaire des données

Le dictionnaire des données est un support du travail rassemblant les informations issues des règles
de gestion et du cahier des charges.
Il se présente sous la forme d’un tableau recensant toutes les informations nécessaires relatives aux
attributs : nom, type (numérique, alphabétique, logique), description de chaque attribut et de ses ca-
ractéristiques, et, le cas échéant, contraintes portant sur l’attribut.

Exemple : les éléments d’une base de données simplifiée rassemblant les informations relatives aux
fournisseurs et aux produits (un produit peut être référencé par plusieurs fournisseurs) :
Nom attribut Type de données Description, contraintes, propriétés
NumeroFourn Entier >0, Longueur maxi = 4
NomFourn Texte Longueur maxi = 20
AdresseFourn Texte Longueur maxi = 30
CPFourn Texte Longueur fixe = 5
VilleFourn Texte Longueur maxi = 20
CodeProd Entier >0,Longueur maxi = 20
NomProd Texte >0, Longueur maxi = 4
PrixProd Réel >=0
Chacun de ces éléments constitue un attribut.
L’étape suivante consiste à regrouper ces attributs en entités et asssociations, et donc, parallèlement
à définir les identifiants.

2.3 Les dépendances fonctionnelles

La mise en évidence des dépendances fonctionnelles va permettre de regrouper les attributs en entités
homogènes, de définir les identifiants et les associations du MCD.
Il existe une dépendance fonctionnelle entre un attribut A1 et un attribut A2 (noté A1− >A2)
si, en connaissant une valeur de A1, on ne peut lui associer qu’une seule valeur de A2.
Organiser les données - Le M.C.D. - Master 2 C.G.A.O. - A. Olivier 8

On dit que A1 détermine A2.

A1 est la source de la dépendance fonctionnelle et A2 le but.
On pourra pour ce faire s’aider d’un outil : la matrice des dépendances fonctionnelles.
Il s’agit d’un tableau à double entrée contenant en ligne et en colonne les attributs identifiés dans le
dictionnaire des données.

Exemple :
Source 1 2 3 4 5 6 7 8
But
1 NumeroFourn
2 NomFourn
3 AdresseFourn
4 CPFourn
5 VilleFourn
6 CodeProd
7 NomProd
8 PrixProd

La dépendance A1− >A2 est symbolisée par le Source 1 6

chiffre 1 à l’intersection de la source A1 et du but But
A2. 1 NumeroFourn
Une ligne ne doit contenir qu’un seul 1. 2 NomFourn 1
NumeroFourn détermine NomFourn, Adresse 3 AdresseFourn 1
Fourn, CPFourn et VilleFourn. 4 CPFourn 1
CodeProd détermine NomProd. 5 VilleFourn 1
La matrice peut être simplifiée par élimination 6 CodeProd
des colonnes vides et les identifiants (sources de 7 NomProd 1
dépendances fonctionnelles) sont soulignés 8 PrixProd

Les données ne possédant pas de 1 sur leur ligne sont soit des identifiants, soit des données attachées
à plusieurs identifiants.
L’attribut PrixProd ne dépend pas uniquement du NumeroFourn, mais aussi du CodeProd (il peut y
avoir plusieurs founisseurs et donc plusieurs prix pour un même produit).
Il appartient donc à une association non hiérarchique.

Nous pouvons donc schématiser ainsi les dépendances fonctionnelles (ce résumé des dépendances
peut remplacer la matrice des dépendances fonctionnelles) :

NumFourn − > NomFourn, AdresseFourn, CPFourn, VilleFourn

CodeProd − > NomProd
NumFourn, CodeProd − > PrixProd

Et représenter le modèle conceptuel des données résultant de cette analyse :