Modélisation E/A , MCD et UML

Objectifs de la Modélisation
• Permettre une meilleure compréhension
• Le monde réel est trop complexes
• Abstraction des aspects cruciaux du problème
• Omission des détails
• Permettre une conception progressive
• Abstractions et raffinements successifs
• Possibilité de prototypage rapide
• Découpage en modules ou packages
• Génération des structures de données (et de traitements)
La notion de modèle
• Un modèle est une représentation abstraite d’un système. C’est un
outil majeur de communication entre les différents intervenants au
sein d’un projet. Le modèle présente notamment l’atout de faciliter la
traçabilité du système, à savoir la possibilité de partir d’un de ses
éléments et de suivre ses interactions et liens avec d’autres parties du
modèle. Un modèle est juste une simplification de la réalité. Il est
construit pour répondre à des questions spécifiques sur le système
réel.
Étape de la conception d’une BD
• Analyse de l’existant et capture des besoins
• Création des modèles conceptuels pour représenter tous les aspects
important du problème
• Traduction des modèles conceptuels en modèle logique
• Implémentation d'une base de données dans un SGBD à partir du
modèle logique
 Modélisation à plusieurs niveaux

Réel

Indépendant du
Modèle modèle de données
Indépendant du
conceptuel SGBD Médecin effectue Visite

Dépendant du
Modèle modèle de données
Codasyl Relationnel Objet XML
Indépendant du
logique SGBD

Dépendant du  Organisation physique des données

Modèle modèle de données
 Structures de stockage des données
Dépendant du
Physique SGBD  Structures accélératrices (index)
5
Générations de méthodes
• Méthodes d'analyse et de décomposition hiérarchiques
• 1e génération basée sur des arbres fonctionnels
• Diviser pour régner (Problème --> Sous-problème)
• Warnier, SADT, Jackson, De Marco
• Méthodes d'analyse et de représentation systémiques
• 2e génération basée sur entité-association
• Séparation des données et traitements
• Merise, Axial, SSADM
• Méthodes d'analyse et de conception orientées objets
• 3e génération basée sur les objets
• Réconciliation données et traitements
• Réutilisation de composants

6
Objectifs des méthodes
• Réduire la distance sémantique entre le langage des utilisateurs et le langage des
concepteurs
• meilleure communication entre utilisateurs et concepteurs
• abstraction du réel perçu en termes compréhensibles et visibles
• Regrouper l'analyse des données et des traitements
• meilleure compréhension des choses
• plus grande cohérence entre l'aspect statique et l'aspect dynamique
• Simplification des transformations entre niveau conceptuel et niveau interne
• implémentation directe éventuelle du schéma conceptuel
• établissement possible de règles de transformations automatisées

7
2. Le Modèle Entité – Association (E/R Model)
• Ensemble de concepts pour modéliser les données d'une application
(d'une entreprise)
• Ensemble de symboles graphiques associés
• Formalisé en 1976 par P. Chen
• Etendu vers E/R généralisé puis vers l'objet

8
Exemple de modèle E/R

9
Le Modèle Entité – Association (E/R Model)
• Les concepts de base (correspondent aux concepts d’abstraction de
la réalité):
• objet <=> entité
• lien <=> association
• propriété <=> attribut
Entités et types d’entités
❑Entité:
Représentation d’un objet du monde réel ayant une existence propre
❑Type d'entité (TE) ou encore classe d’entité:
représentation d'un ensemble d'entités perçues comme similaires et ayant les
mêmes caractéristiques
Représentées par un rectangle contenant le nom du type de l'entité

Personne
 Représentation
• Rectangle avec attributs accrochés Rectangle avec attributs (Mesrise)
(E/R) Voitures
Etudiant

Vitesse Km
Matricule
Nveh Type Marque
Nom,
Prénom,
Adresse,
Datenaiss
Voitures Nom
• RectangleType:
avec
Nveh: Int attributs (UML)
String
Marque: String Attribut : Type
Vitesse: Int
Km : Int
Exemple d'instance

• Exemple d’instance du type d’entité voiture

Voiture
Nveh: 75AB75
Voitures Type: Mégane
Nveh: Int Marque: Renault
Type: String Vitesse: 120
Marque: String Km : 54000
Vitesse: Int
Km : Int

Voiture
Nveh: 850VV94
Type: 407
Marque: Peugeot
Vitesse: 0
Km : 4000
Associations et types d’associations
• Association:
Représentation d'un lien non orienté entre plusieurs entités (qui jouent chacune
un rôle déterminé)
• Type d'association (TA):
Représentation d'un ensemble d'associations ayant la même sémantique et
décrites par les mêmes caractéristiques

Client Passe Commande

Association
• Les entités sont reliées ensemble par des associations
• Entre instances: par exemple 1 véhicule est associé à 1 personne
• Entre classes: abstraction des associations entre instances
• Une association peut avoir des attributs (propriétés)
• Elle peut relier plusieurs entités ensemble
• Il est possible de distinguer le rôle d'une entité (elle peut en avoir
plusieurs)

15
Les identifiants
• IDENTIFIANT D'ENTITE :
• Propriété PARTICULIERE de l'entité telle que pour chacune des valeurs de cette propriété, il
existe une occurrence UNIQUE de l'entité.
• Remarque :
Si l'on ne sait pas trouver d'identifiant à une entité, c'est qu'elle n'a peut être pas
d'existence propre. Il pourrait donc s'agir d'une association.
• Présentation :
L'identifiant est inscrit en tête de la liste des propriétés et souligné.
Dans les modèles très denses il peut suffire à résumer les autres propriétés, pour
faciliter la lecture.

Maria Berger - Maîtrise d'AES 16

Les identifiants

Maria Berger - Maîtrise d'AES 17

Les identifiants
• IDENTIFIANT D'ASSOCIATION :
• Une association N'A PAS D'IDENTIFIANT explicite : l'association dépend des
entités qu'elle relie.
Son identifiant se déduit par calcul du produit cartésien des identifiants des
entités associées.
• Exemple :
• Pour l'association CONCERNE qui relie COMMANDE à PRODUIT, l'identifiant
est le produit cartésien de N° Commande et N°Produit.

Maria Berger - Maîtrise d'AES 18

Dimensions d'une association
• On appelle DIMENSION d'une association le nombre d'entités qu'elle
relie. On dit souvent : son nombre de "pattes".
• Remarques :
• Il n'existe pas de limite au nombre de pattes d'une association. Cependant, un nombre
de pattes élevé est un indice que l'étude a été superficielle et approximative.
• Une association "réflexive" est une association qui lie des occurrences d'une même
entité entre elles (c'est un cas particulier de la dimension 2) .

Maria Berger - Maîtrise d'AES 19

Dimension supérieure à 2 d'une association et
cardinalités
• Supposons une société immobilière dont l'activité consiste à louer des locaux
commerciaux
• Remplacer les points d'interrogation par des cardinalités :

Maria Berger - Maîtrise d'AES 20

Association: quelques définitions
• Association (Association)
• Une relation entre des instances de deux (ou plus) classes
• Lien (Link)
• Une instance d'association
• Rôle (Role)
• Une extrémité d'une association
• Attribut de lien (Link attribute)
• Un attribut de l'association instancié pour chaque lien
• Cardinalité (Multiplicity)
• Le nombre d'instance d'une entité pour chaque instance de l'autre

21
 Représentation
UM
L E/R
Personne Voiture
Possède
Propriétaire Possédée Personne Voiture
Possède
Propriétaire Possédée

Date
Prix Date Prix

Merise
CLIENT PRODUIT

nocli, 1,n commande 0,n noprod,

nomcli désignation

22
Degré d'une association

M# Nom …

Pièces I# Nom … Modè le

Composant Composé
Ingénie ur Suivi

Date Pièce
Composée_de Rôle
…
P# Des . …
• La plupart des associations sont de degré 2 (binaires)

23
Cardinalité d'une association
• 1:1
Personne Habite Adresse
• 1:N
Personne Possède Voiture

• N:M
Vendeur Vend Produit

24
Cardinalités min et max
• Cardinalité maximum
• Indique le nombre maximum d'instances d'une classe d'entité participant à
une association
• Cardinalité minimum
• Indique le nombre minimum d'instances d'une classe d'entité participant à
une association
[1,N] [1,n]
Produit Faire partie Commande

25
Difficultés : choix entre entité
et association ?
1) Solution avec association
CLIENT PRODUIT

nocli, 1,n commande 0,n noprod,

nomcli désignation

Dans cette première solution la commande n’est pas

une entité gérée pour elle même. Elle existe tant que le
client et le produit existent.
Ce peut être le SI du domaine ‘fabrication’ : on a juste
besoin de savoir que les produits sont destinés à des
clients.
Difficultés : choix entre entité
et association ?
2) Solution avec entité
PRODUIT
CLIENT
noprod,
nocli, désignation
nomcli
COMMANDE
1,n 1,1 1,n 0,n
passe nocde porte
datecde

Dans cette seconde solution, les commandes sont identifiées

(identifiant nocde) et décrites : on les gère en tant que telles.
Ce peut être le SI du domaine financier.
Difficultés : choix des cardinalités
0, n ou 0, n ou
CLIENT 1, n ? 0,1 ? LOCAL

LOCATION

Un client peut il avoir 0 location ? Est-ce encore un client ?

Un local peut il être loué plusieurs fois ? Non si la base représente une situation
instantanée et si le local n’est pas partageable. Oui si on gère un historique ou si le
local est partageable.
Les cardinalités sont élément essentiel pour définir la sémantique des données, pas
une « décoration » accessoire. Derrière cette notion on trouvera des contrôles (par le
SGBD ou les programmes).
QUESTIONS
Donner le modèle E/R de l’application suivante
• 1- Chaque usine a un id unique
• 2- Une usine peut être situé dans une ville
• 3- Chaque produit a un numéro id unique
• 4- Chaque produit a une couleur
• 5- Une usine peut produire plusieurs Articles
• 6- Un produit peut être fabriqué par une seul usine
• 7-Une usine produit une quantité fixe de chaque produit
• Diagramme E/R

1,1 1,n
Usine Fabrique Produit

Id Ville NumP Couleur

Qté
 Soit le modèle conceptuel de données suivant,
représentant des visites dans un centre médical
Chercher par exemple si un patient peut effectuer plusieurs visites, si un
médecin peut recevoir plusieurs patients pendant la même consultation, si un
médecin peut prescrire plusieurs médicaments lors d'une même consultation, s
deux médecins différents peuvent prescrire le même médicament
• Analyser le schéma de la diapositive précédente et discuter ses
cardinalités. etc.
• Exemple 1 : dimension = 2 → association binaire :
Elève
Matière
◼ N° SS élève
◼ Nom
Avoir pour note
◼Siglematière
◼ Prénom
◼Désignation
◼ Date naissance note
◼etc.
◼ Adresse
◼ Année d’étude

Exemple 2 : dimension = 3 → association ternaire :

Professeur
…
Matière Enseigner Classe
… •Nbre d’heure
…
33
Règles de gestion

• Les règles de gestion du MCD précisent les contraintes d'intégrité

qui doivent être respectées par le modèle.
• Exemple : le MCD d’une école peut avoir les règles de gestion
suivantes :
• R6 : un professeur fait au moins un enseignement.
• R7 : une classe a au moins un enseignant.
• R2 (rappel) : chaque matière est enseignée par un et un seul professeur.
• Le MCD sera
Professeur
…
Matière 1,1 Enseigner 1,n Classe
•Nbre_heures
… …
34
 Elève
◼ N° SS élève Matière
◼ Nom_élève (0,n) Avoir pour note (0,n) ◼Siglematière
◼ Prénom _élève ◼Désignation_mat
Note
◼ Date_naissance
◼ Adresse
◼ Année_étude

(0,1)
(1,1)
Appartenir

Professeur
(1,n)
Classe
(1,n) (1,n) ◼ Code_prof.
Enseigner
◼ Code Classe ◼ Nom_prof.
•Nbre_heures
◼ Désignation_classe ◼ Prénom_prof
◼ N° salle ◼ Statut_prof
35
Contraintes d’intégrité syntaxiques

• Elles portent sur un attribut et peuvent concerner soit

son format, soit son domaine.
• Exemples:
• Prix d’un produit doit être un nombre réel positif.
• Une date doit prendre le format JJ/MM/AA.

36
 Contrainte d’intégrité fonctionnelle
(ou dépendance fonctionnelle)
Définitions
• En mathématiques, la notion de DF entre deux ensemble A et B exprime le
fait qu'à chaque élément a de A correspond un seul élément b de B.
A → B
• En Modélisation Conceptuelle des Données sous MERISE, cette notion de
DF, appelée parfois Contrainte d'Intégrité Fonctionnelle (CIF), s'applique
dans les cas suivants :
 DF intra-entité : il s'agit d'une DF entre l'identifiant d'une entité et les
autres attributs de l'entité.
 DF intra-relation : il existe une DF entre l'identifiant obtenu par
concaténation des identifiants des entités de la collection d'une association
et les éventuels attributs de l'association.
• Il existe des "DF triviales" entre l'identifiant de l'association et les
identifiants des entités qu'elle relie.
• On appelle collection d'une association la liste des entités liées.
37
 Contrainte d’intégrité fonctionnelle
(ou dépendance fonctionnelle)
On dit qu’il existe une DF (dépendance fonctionnelle) entre deux entités ou
attributs A et B, on note A → B, si toute occurrence de A détermine une
seule occurrence de B.
DF entre attributs :
• Exemples
• Code_client → Nom_client.
• N°bon_de_cde+Réf_prod → Qté commandée.
• La DF a → b est dite élémentaire si aucune partie de a ne détermine b.
• La DF a → b est dite directe (ou non transitivité) s’il n’existe pas d’attribut c tel
que a → c et c → b.
DF entre entités ou Contrainte d’Intégrité Fonctionnelle :
• Exemple : un élève appartient toujours à une et une classe :

Elève 1,1 Appartenir 1,n Classe

… …

38
DF
 Contrainte d’intégrité fonctionnelle
(ou dépendance fonctionnelle)
DF inter-entités via une association binaire
• Il existe des DF inter-entités si l'une des cardinalité maximum
de l'association est égale à 1. Dans ce cas, il est possible
d'orienter le lien entre les entités et de remplacer l'association
par une DF.
• On parle de DF forte (resp. DF faible) lorsque la cardinalité
minimum de l'entité source de la DF est égale à 1 (resp. 0).
• Exemple : enfant (moins de 16 ans) et classe
ENFANT
N° SS DF CLASSE
Nom 1,1 0,n
N° Classe
Prénom Nom établissement

ENFANT
N° SS DF CLASSE
Nom 0,1 0,n
N° Classe
Prénom Nom établissement 39
 Contrainte d’intégrité fonctionnelle
(ou dépendance fonctionnelle)
• Lorsqu'il existe de part et d'autre d'une association binaire des
cardinalités maximales égales à 1, une règle de modélisation
stipule que l'entité source de la DF est celle dont les occurrences
apparaissent postérieurement.
• Exemple : appel de cotisation et le règlement correspondant.

REGLEMENT
APPEL COT ISAT ION
N° règlement DF
1,1 0,1 N° Classe
Date règlement
Nom établissement

• Une DF liant deux entités est également appelée CIF (Contrainte

d’Intégrité Fonctionnelle)
REGLEMENT
APPEL COT ISAT ION
N° règlement CIF
1,1 0,1 N° Classe
Date règlement
Nom établissement
40
 Contrainte d’intégrité fonctionnelle
(ou dépendance fonctionnelle)
• Une DF ou une CIF est un lien non porteur de propriété. Une association binaire
ayant une cardinalité maximale de 1, porteuse de propriété peut toujours être
remplacée par une DF ou une CIF.

CONT RAT SOUSCRIPT EUR

SOUSCRIRE
N° contrat 1,1 0,n N° souscripteur
Date souscri ption

• Les DF sous-jacentes sont les suivantes :

N° contrat → N° souscripteur
N° contrat, N° souscripteur → Date souscription

• La propriété de pseudo-transitivité permet de déduire la DF suivante :

N° contrat → Date souscription
CONTRAT CIF SOUSCRIPTEUR
N° contrat 1,1 0,n N° souscripteur
Date souscri ption

41
Caractéristiques des DF

• Réflexivité : a→a.
Exemple : Réf →Réf.
• Projection : a →b+c  a →b et a →c.
Exemple : Réf → Design+PU  Réf → Design et Réf → PU.
• Augmentation : a → b  c: a+c → b.
Exemple : Réf → PU  Réf+Design → PU.
• Additivité : a → b et a → c  a → b+c.
Exemple : Réf → PU et Réf → Design  Réf → Design+PU.
• Transitivité : a → b et b → c  a → c.
Exemple : Réf → Code_TVA et Code_TVA → Taux_TVA
 Réf → Taux_TVA.
• Pseudo-transitivité : a → b et b+c → d  a+c →d.
Exemple : Réf → Code_TVA et Code_TVA+PU → Taux_TVA
 Réf+PU → Taux_TVA.
42
Les dépendances fonctionnelles
• Le Graphe des dépendances fonctionnelles
• Le graphe des dépendances est une étape intéressante car il épure le dictionnaire en ne
retenant que les données non déduites et élémentaires et permet une représentation
spatiale de ce que sera le futur MCD.
Numéro adhérent

Nom adhérent prénom adresse CP VILLE

Email
 Règles relatives au MCD pour sa mise au
propre
• La mise au propre du MCD s'effectue à travers 3 opérations :
 la vérification,
 la normalisation,
 la décomposition.

44
La vérification
• Règle de non-répétitivité : à toute occurrence de l'entité ou de
l'association correspond au plus une valeur de tout attribut qui
lui est associé.
• Règle d'homogénéité : les attributs rattachés à une entité ou à
une association doivent avoir un sens pour toutes les
occurrences de l'entité ou de la association.
• Règle de distinguabilité : les occurrences d'une entité doivent
être distinguables. Cela induit la compréhension de l'entité et
se traduit par le choix de l'identifiant.
• Règle de normalisation d'une relation : chaque attribut d'une
association doit dépendre fonctionnellement de la totalité des
entités formant la collection de l'association .
• Respect des règles de gestion : les règles de gestion relatives
aux données, dégagées lors de l'étude de l'existant, doivent
avoir été traduites dans le MCD (cardinalités, etc.).
45
 Quelques erreurs de modélisation
• Cas 1 : Attribut répétitif

Professeur
Matricule
Nom
Matière
L'attribut "Matière" peut prendre plusieurs valeurs si le prof. peut
enseigner plusieurs matières.
Solution

Professeur Matière
1,n Enseigner
Matricule 1,n Code
Nom Matière

46
 Quelques erreurs de modélisation
• Cas 2 : Attribut sans signification
Personnel
Matricule
Nom
Matière
L'attribut "Matière" ne prend pas de valeur pour une secrétaire
ou un surveillant.
Solution

Personnel
Matricule
Nom

47
 Quelques erreurs de modélisation
• Cas 3 : Dépendance incomplète
Commande Produit
1,n Concerner
N° Bon 1,n Réf
Qté Date
Désign.
P.U.
L'attribut "Date" ne dépend pas du produit et l'attribut "Qté" peut prendre
plusieurs valeurs.
Solution

Commande Produit
1,n Concerner
N° Bon 1,n Réf
Date Qté Désign.
P.U.
48
 La normalisation du MCD

• 1ère Forme Normale (1FN) : élémentarité des attributs et

existence de l'identifiant.
Tous les attributs doivent être élémentaires par rapport au
choix de gestion et il doit y avoir un identifiant à chaque entité.

ETUDIANT ET UDIANT
Nom n'est pas 1FN
N° étudiant
est 1FN
Prénom Nom
Age Prénom
Adresse Age

49
• 2ème Forme Normale (2FN) : DF élémentaire de l'identifiant.
Tout attribut d'une entité doit dépendre de l'identifiant de
cette entité par une dépendance fonctionnelle élémentaire.

ETUDIANT
Code_Option, N°_étudiant n'est pas 2FN
Nom
Prénom
Nom option

ETUDIANT
N°_étudiant
Nom 0,n
SUIVRE
0,n
OPTION
Code_option
est 2FN
Prénom Nom option

50
• 3ème Forme Normale (3FN) : DF élémentaire et directe.
Tout attribut d'une entité doit dépendre de l'identifiant
par une DF élémentaire et directe.
ETUDIANT

Code_étudiant n'est pas 3FN

Nom
Prénom
Code_option
Nom_option

ETUDIANT
N°_étudiant SUIVRE OPTION
Nom
Prénom
0,n 0,n
Code_option est 3FN
Nom_option

51
• 4ème Forme Normale (4FN) : DF complète (cas de
l'identifiant concaténé).
Si une entité a un identifiant concaténé, un des attributs
composant l'identifiant ne doit pas dépendre d'un autre
attribut.
Exemple :
RG1 : tout prof enseigne une et une seule matière.
RG2 : toute classe n'a qu'un seul prof par matière.

COURS
Matière, N° classe n'est pas 4FN
N° prof

COURS CLASSE
N° prof
0,n
ENSEIGNER DANS
0,n N° classe est 4FN
Mati ère N° prof

52
 5ème Forme Normale (5FN)

les cardinalités sont toutes 1,1 donc c’est une association fantôme
1FN : élémentarité des attributs et existence de l'identifiant.

2FN : DF élémentaire de l'identifiant.

3FN : DF directe de l'identifiant.

4FN : DF complète de l'identifiant : si l'identifiant
est concaténé, un composant ne doit pas être en
DF avec un autre attribut.
5FN : il faut éliminer les associations fantômes
redondantes ou en plusieurs exemplaires

54
Les étapes pour la construction d'un MCD
L'étude de l'existant

• Interview de la direction (Système de Pilotage).

• Objectifs principaux.
• Liste des postes de travail.
• Délimiter le champs de l’étude.
• Interview des postes de travail (Système Opérant) .
• Recenser et décrire les tâches exécutées.
• Observer la circulation des informations.
• Apprendre le langage de l’entreprise.
• Etablissement d’une liste des règles de gestion.
• Construction d’un dictionnaire de données (DD).
55
Autres étapes de la construction d'un MCD

• Epuration du dictionnaire des données (DD) en enlevant

• les synonymes (les données identifiées différemment et ayant le même
sens);
• les polysèmes (les données utilisant les mêmes orthographes mais
décrivant des réalités différentes) : il faut leur attribuer des noms
différents.
• Construction du GDF (Graphe des Dépendances Fonctionnelles).
• Extraire du DD la liste des attributs qui ne sont ni concaténés, ni calculés.
• Ne pas considérer les DF transitives pour obtenir un GDF avec une
couverture minimale (répondant à la 3FN).
• Transformation du GDF en MCD.
• Mise au propre du MCD.

56
Informatisation du SI d’une société de vente

Une société de vente souhaite informatiser son SI actuel

(manuel) qui contient essentiellement des données figurant
sur des bons de commande ou factures du type :

N°Bon …………………… Date ……………………

Nom client ………………………………………………………………
Adresse ………………………………………………………………………
………………………………………………………………………………….

Nom représentant …………………………………………

Réf. Design. Qté PU Montant

………… ………… …… ……… …………
………… ………… …… ……… …………

Total …………
57
 En utilisant le schéma de construction détaillé précédemment,
établir le MCD de leur nouvelle base de données. On suppose
que certaines opérations ont déjà été effectuées :
• Recueil des informations (interview du SI existant)
• R1 : un client peut passer une ou plusieurs commandes ou ne passer
aucune commande;
• R2 : une commande concerner au moins un produit;
• R3 : une commande concerne un et un seul client;
• R4 : une commande est assurée par un et un seul représentant qui n’est
pas toujours le même pour un client donné.
• Construction d'un dictionnaire de données (DD) : établissement de
la liste des attributs à partir des informations recueillies. Comme le SI actuel
est manuel, il n’existe pas nécessairement des codifications, on imaginera qu’il
existe des codes pour identifier les entités évidentes …
Par exemple, « Cocli » pour CLIENT et « Corep » pour REPRESENTANT seront
créées, on les marquera d’un (*) pour signifier qu’elles n’existent pas encore.

58
 • Le dictionnaire des données (DD)
SIGNIFICATION TYPE (1) LONGUEUR NATURE REGLE DE CALCUL
(2) (3) OU INTEGRITE (4)

NoBon N° de bon de Cde N 4 E M

Date Date Cde N 6 E M Forme jj/mm/aa (5)

*CoCli Code client ? ? E SIG A créer

NomCli Nom client A 30 E SIG
Adresse Adresse client AN 60 CON SIG Rue + Ville
RueCli Rue client AN 30 E SIG
Vilcli Ville client A 30 E SIG
*CoRep Code représentant ? ? E SIG A créer
NomRep Nom représentant A 30 E SIG
Réf Réf. de produit AN 5 E SIG 1 lettre + 3 chiffres
Désign Désignation produit A 30 E SIG
Qté Quantité commandée N 3 E M Entier > 0
PU Prix unitaire N 7 E SIG Forme : 9999,99
Montant Montant ligne N 8 CAL M PU  Qté
Total Total commande N 9 CAL M Somme des montants

(1) A(lphanumérique) N(umérique) A(lpha)N(umérique)

(2) E(lémentaire) CON(caténé) CAL(culé)
(3) M(ouvement) SIG(nalétique) SIT(uation)
(4) Règle de calcul pour les attributs calculés ou contraintes d’intégrité syntaxique éventuelles
(5) jj : 01 à 31, mm : 01 à 12, aa : 00 à 99.
59
• Epuration du dictionnaire des données
• Les données à ne pas prendre en compte dans un MCD
sont, en général, les données calculées et concaténées.
• Seront supprimées : Adresse, Montant et Total.

60
• Le graphe des dépendances fonctionnelles

Ref NoBon

Design PU Date
Qté

CoRep CoCli

NomRep NomCli RueCli VilleCli

61
• Le graphe des dépendances fonctionnelles

Ref NoBon

Design PU Date
Qté

CoRep CoCli

NomRep NomCli RueCli VilleCli

62
• Transformation du GDF en MCD
Règles de transformation

• R1 : les données sources d'au moins une DF (celles qui sont

soulignées sur le GDF) représentent les identifiants des
entités dont les attributs sont les cibles de ces DF.
• R2 : Les flèches restantes deviennent des associations. Les
données déterminées par une DF conjointe deviennent des
attributs portés par l’association.
• R3 : Les règles de gestion doivent permettre de trouver les
cardinalités.

63
 Application de la 1ère règle (R1)

PRODUIT COMMANDE

Ref NoBon
Design Date
PU Qté

CLIENT
REPRESENTANT
CoCli
CoRep NomCli
NomRep RueCli
VilleCli

64
 Application des règles R2 et R3

PRODUIT COMMANDE
0,n CONCERNER 1,n
Ref NoBon
Design
Qté Date
PU

1,1
1,1
OBTENIR PASSER

0,n
0,n
CLIENT
REPRESENTANT
CoCli
CoRep NomCli
NomRep RueCli
VilleCli
65
Extension du modèle E/A Généralisation/
Spécialisation

Mettre en place une hiérarchie afin de

factoriser les propriétés communes
Généralisation/ Spécialisation

• Généraliser: C’est l’opération qui consiste à regrouper dans une

entité plus générale ( dite entité générique) les propriétés communes
présentes dans des entités différentes mais semblables.
• Spécialiser: C’est l’opération qui consiste à prendre en compte les
caractéristiques particulières de certaines entités ( dites entités
spécifiques)
Exemple de hiérarchie
MAISON • Généralisation/spécialisation
CLIENT Entité
numClient générique
Nomclient
posséder louer adrClient

Propriétaire Locataire
idProprio idLocataire
nomProprio nomLoc
adrProprio Propriétaire Locataire
adrLoc
typeProprio revenusLocat
revenusLocat typeProprio
Entités spécifiques
 Généralisation/ Spécialisation

• La relation « est un » : similitude

LOCATAIRE CLIENT PROPRIETAIRE

 Généralisation/ Spécialisation

• Un autobus est un véhicule

• Une voiture est un véhicule

VEHICULE

Autobus Voiture

Une hiérarchie
 Généralisation/ Spécialisation
Mécanisme d’héritage
➢L’héritage des propriétés:
Les entités spécialisées héritent des propriétés des entités génériques ; elles ont:
▪ leurs caractéristiques propres
▪ les caractéristiques communes.
➢L’identifiant:
Les entités spécialisées héritent de l’identifiant de l’entité générique.
➢Les associations:
▪ Les entités spécialisées hérite des associations auxquelles participe l’entité générique.
▪ Elle participent à des associations spécifiques.
Exemple d’héritage

Nom
PERSONNE prénom
adresse

HOPITAL
HOMME FEMME

nombreGrossesses accoucher
Exemple d’héritage

EMPLOYE
affecter SERVICE
Nom
adresse

SECRETAIRE
CADRE

Vitesse de frappe
prime
responsable PROJET
Hiérarchie double

Num
VEHICULE
Constructeur
proprio

Voiture Poids lourd vitesselimitée

nbrePlaces

Autobus nbreMaxPlaces
tonnage Camion
 MLD: Schémas relationnels

On peut représenter les tables d’une base de données relationnelle par un

schéma relationnel dans lequel les tables sont appelées relations et les liens
entre les clés étrangères et leur clé primaire est symbolisé par un
connecteur
 MLD: Traduction d’un MCD en un MLDR

Pour traduire un MCD en un MLDR, il suffit d’appliquer cinq règles.

Notations : on dit qu’une association binaire (entre deux entités ou réflexive) est
de type :
– 1 : 1 (un à un) si aucune des deux cardinalités maximales n’est n ;
– 1 : n (un à plusieurs) si une des deux cardinalités maximales est n ;
– n : m (plusieurs `a plusieurs) si les deux cardinalités maximales sont n.
 MLD: Traduction d’un MCD en un MLDR

Règle 1 : toute entité devient une table dans laquelle les attributs deviennent les
colonnes. L’identifiant de l’entité constitue alors la clé primaire de la table.

Règle 2 : une association binaire de type 1 : n disparait, au profit d’une clé étrangère
dans la table côté.
 MLD: Traduction d’un MCD en un MLDR
Règle 3 : une association binaire de type n : m devient une table supplémentaire
 MLD: Traduction d’un MCD en un MLDR
Règle 4 : une association binaire de type 1 : 1 est traduite comme une association binaire
de type 1 : n sauf que la clé étrangère se voit imposer une contrainte d’unicité en plus
d’une éventuelle contrainte de non vacuité
 MLD: Traduction d’un MCD en un MLDR
Règle 5 : une association non binaire est traduite par une table supplémentaire
dont la clé primaire est composée d’autant de clés étrangères que d’entités en
association