Vous êtes sur la page 1sur 9

3.

3 Le modèle Entité / Relation ou Entité / Association

C’est un modèle conçu dans les années 70. Dans un système réel, les données sont divisées en
catégories discrètes ou entités. Un modèle E/R est la représentation des diverses entités qui
existent au sein d’une société et leur inter action. Un modèle E/R est issue de règles de gestion
ou compte rendu d’interview et est conçu au cours de la phase d’analyse du cycle de vie du
système.

Les composantes clés de la modélisation E/R sont : l’entité, la propriété ou information et le


lien association

3.3.1. Entité et propriétés

A Entité

C’est un élément concret ou abstrait et identifiable d’une organisation ; il est porteur


d’information et important pour l’activité considérée.

Exemples :

Dans une organisation "COLLEGE", on trouvera les entités ÉLÈVE, CLASSE, MATIÈRE,
PROFESSEUR.

Dans une entreprise, on trouvera les entités PRODUIT, CLIENT, FOURNISSEUR,


COMMANDE, LIVRAISON, etc.

B Propriété

C’est un élément qui décrit ou qualifie une entité. Chaque entité est caractérisée par un ensemble
de propriétés. Leur nombre et leur type dépendront de l'entité étudiée. Il existe des propriétés
simples, des propriétés composées et des propriétés dérivées. Une propriété composée est
subdivisée en propriétés simples. La valeur d’une propriété dérivée est calculée sur la base de
la valeur d’une autre propriété.

Exemple :

Pour l'entité ÉLÈVE, nous aurons comme propriétés Numéro, Nom, Prénom, Date de naissance,
rue, Ville, Code postal.

Un domaine est un ensemble de valeurs que peut prendre une propriété.

15
3.3.2 Types et occurrences

Un type est un ensemble d’éléments ayant les mêmes caractéristiques. Une occurrence d’un
type est un élément particulier appartenant à cet ensemble.

Une occurrence d’entité est une entité particulière appartenant à ce type.

Exemple1 :

CLIENT est une entité type

CLIENT Diop et CLIENT Fall sont des occurrences de l’entité type CLIENT

A Identifiant

Parmi les différentes propriétés, il y en a une, l'identifiant, qui sert à différencier sans
ambiguïté chaque occurrence de l'entité, c'est à dire qu'à une valeur donnée de l'identifiant ne
peut correspondre qu'une seule occurrence. Souvent on utilisera comme identifiant un code,
un numéro, une référence, afin de respecter le principe de l'identifiant.

Par exemple un nom de famille peut être présent plusieurs fois dans l'ensemble des
occurrences de l'entité ÉLÈVE, on choisira donc un numéro d'élève ou un code afin d'éviter
les homonymes.

Exemple :

Le code client est l’identifiant (la clé) de l’entité type client. Les clients de code A01 et A02
constituent des occurrences distinctes de CLIENT.

L’élève de code 1200 constitue une occurrence d’élève.

B Représentation d’une entité :

On représente (par convention) une entité dans un rectangle surmonté du nom de l'entité,
listant l'ensemble des propriétés.
L'identifiant sera mis en évidence par un soulignement (là aussi par convention).

16
3.3.3 Notion de relation

A Définition

Une relation est une association définie sur une collection de n objets. Le nombre de n objets
associés définit la dimension de la relation. Ainsi une relation binaire relie deux objets, une
relation ternaire relie trois objets et une relation n-aire en relie n..

B Représentation

Dans le modèle entité-association, une relation se symbolise par une ellipse entourant son
nom. Cette ellipse est reliée par un trait à tous les objets concernés par la relation.

VENDRE
LINE VERS LINE VERS
UN OBJET UN OBJET

Nom de la relation

Représentation d’une relation non porteuse de données

Si la relation est porteuse de données (cas de données dépendantes des objets de la relation),
l’ellipse et séparée en deux par un trait horizontal et les données sont indiquées sous ce trait.

Nom de la relation

VENDRE
LINE VERS
LINE VERS
Quantité UN OBJET
UN OBJET

Nom des données


portées

17
Représentation d’une relation porteuse de données

Convention de notation
Les objets sont baptisés du nom habituel ou naturel qu’ils portent dans l’organisation
considérée ex : auteur, dépôt, personne…

Dans une relation, le sens de lecture de la relation influe sur le terme à employer. Ainsi, on
peut dire « un fournisseur fournit un article » ou « un article est fourni par un fournisseur » ;
afin de ne pas lier la relation à un sens unique de lecture, il est préférable d’utiliser un verbe à
l’infinitif (ex : fournir).

L'association sera représentée dans un "cartouche", avec en haut le nom de l'association, et en


bas les propriétés dont elle pourrait être porteuse.

La collection est la liste des entités-types qui participent à cette relation.

3.3.3.1Les cardinalités

A Définition

Les cardinalités d’une entité dans une association expriment le nombre de fois qu’une
occurrence de cette entité est impliquée dans l’association, au minimum et au maximum.
Les quatre couples de cardinalités possibles sont :
• 0,1 : au moins zéro, au plus un (unicité sans obligation)
• 1,n : au moins un, au plus n (obligation sans unicité)
• 1,1 : au moins 1, au plus 1 : (obligation et unicité)
• 0,n : au mois zéro, au plus n (pas d’obligation, pas d’unicité)

Dans chacune des différentes notations, le premier chiffre représente la cardinalité minimale,
tandis que le second représente la cardinalité maximale. Les contraintes représentées par les
cardinalités ont un caractère obligatoire ou facultatif, unique ou multiple des occurrences des
entités.

Exemple de cardinalité minimale :

Pour la cardinalité mini entre client et commander il faut se poser la question :


Pour un client donné, combien de fois au minimum il commande ?
Si la réponse est « tout client doit passer au moins une commande sinon ce n’est pas un
client » on met la cardinalité mini à 1

18
Mais on peut très bien imaginer que l’entreprise veut aussi mémoriser les clients potentiels
(prospects), qui n’ont encore rien commandé. Dans ce cas, un client peut très bien ne pas
avoir encore commandé, et on met la cardinalité mini à 0.

Exemple de cardinalité maximale

Elle traduit combien de fois au maximum l’entité peut être en relation avec l’association. Cela
peut être plusieurs fois (si c’est un nombre indéterminé, on indique la valeur n) ou une seule
fois.
On répond à la question : Combien au maximum l’entité peut participer à l’association ?
Si la réponse est « au plus une fois », la cardinalité maximale prend pour valeur 1.
Si la réponse est « plusieurs », la cardinalité maximale prend la valeur N.

Exemple 1

REGLES DE GESTION

Un salarié est affecté au plus à un seul service. Dans un service sont affectés plusieurs salariés

Exemple 2

REGLE DE GESTION :

Un élève doit suivre au minimum une option et au maximum 3 options.

19
CHAPITRE IV LE MODELE LOGIQUE DE DONNEES

Au terme de la validation du MCD, le modèle obtenu est clair pour l’œil mais on ne peut
l’implanter encore sur une machine. Il va falloir préciser comment accéder aux informations
On passe du modèle conceptuel au modèle logique par une opération de TRADUCTION

4.1 Les relations


Au niveau conceptuel, dans le modèle entité relation, on entend par relation une association
d’entités. Mais dans le modèle relationnel, la notion de relation (appelée aussi table) exprime
une association de d’attributs.
Les données sont stockées dans des relations, Une relation est un ensemble de T-uple, et un
T-uple est défini 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.
Clé primaire Attributs

c
a Numvol Type_avion Matricule_av Equipe Escale_dori Heure_
r ion ment gine arrivée
d
i 2187 B727 FY413 G154 JFK 03h04
n T uple 3283 A310 FF997 H698 DK 04H13
a 2983 B747 FN412 F458 JFK 06H04
l
i 2987 B747 FN419 F457 NY 10H55
t 4258 A320 HJ564 F147 CDG 14H25
e
8874 F900 OS257 F459 JFK 15H33
6

Domaine

Degré 6

Chaque enregistrement doit être identifié de manière unique (voir la notion d'identifiant).
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.
4.2 Passage au modèle logique relationnel

Cinq règles de base sont à suivre pour le passage du MCD au MLD

Règle 1 :

Une entité se transforme en une relation (table)


Toute entité du MCD devient une relation du MLD, 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.

20
Exemple :

Règle 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 :

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)

Regle n° 3 : 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) :

Exemple

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 :

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

Règle n°4 : 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
Cles primaires des 2 tables. 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ées, celles ci deviennent des attributs pour la nouvelle table.

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

MLDR :

COMMANDE (id_Commande, Date_commande)


PRODUIT (id_Produit, libelle)
COMPOSE (#id_Commande, #id_Produit, qantité)

Regle n° 5 : Association Réflexive.

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

La Clé Primaire de la table 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).
Exemple :

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

22
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.
Eexemple
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.

23

Vous aimerez peut-être aussi