Université Ibn Zouhr - Agadir

Ecole Supérieure de Technologie

Agadir

DUT Techniques Communication et de Commercialisation

Semestre 3 / Module 11:

Bases de Données et Outils de Gestion

Année universitaire 2020/2021 V 2.0

Le Modèle Conceptuel de Données (MCD)
Contraintes d’intégrité |dépendance fonctionnelle
Les dépendances fonctionnelles expriment la relation qui existent entre les propriétés. On dit
qu’une propriété B d’une entité E2 dépend fonctionnellement d’une propriété (ou groupe de
propriétés) A d’une autre entité E1, si pour chaque valeur A détermine une et une seule
valeur de B
On note conventionnellement :
Détermine
A B
B Dépend fonctionnellement de A
A Détermine B
 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.
Le Modèle Conceptuel de Données (MCD)
Contraintes d’intégrité |dépendance fonctionnelle

Formalisme :
A B : 1 source , 1 but
( A, B, …) X : plusieurs sources , 1 but
A ( X, Y, …) : 1 source , plusieurs buts
Exemples :
N° Client Nom Client , Prénom , Adresse , Tél DF intra - entité

Nom Client N° Client ( pas de DF )

Prénom Client N° Client ( pas de DF )

Réf-prod , N° Commande Qté prod. commandée DF intra - relation

Réf-prod ( Libellé prod. , Prix unit. Prod. )

Le Modèle Conceptuel de Données (MCD)
Contraintes d’intégrité |dépendance fonctionnelle
• Rôle des dépendances fonctionnelles ?
Les dépendances fonctionnelles sont une technique qui permet de vérifier la validité d’un
modèle entité association (modèle conceptuel de données en Merise).
Pour cela, il faut respecter deux règles
 Règle 1:
Une propriété non identifiant d’une entité (d’une association) doit dépendre
fonctionnellement de l’identifiant. Toutes les propriétés de l’entité doivent dépendre
fonctionnellement de l’identifiant de celle-ci
Client Client
N° de client N° de client
Nom du client Nom du client
Adresse client Adresse client
Ville client Ville client
N° de commande
N° de commande
Le Modèle Conceptuel de Données (MCD)
Contraintes d’intégrité |dépendance fonctionnelle
• Rôle des dépendances fonctionnelles ?
 Règle 2:
Une propriété dans une RELATION doit dépendre fonctionnellement des identifiants des
entités qui participent à la relation.

Commande Produit
Avoir 0,n
N° de commande 1,n Réf du produit
Date commande Quantité commandée Prix du produit
Date livraison Quantité en stock

Les cardinalités:
Une commande peut avoir un seul produit, peut avoir plusieurs produit n.
Un produit peut ne pas être commandé 0 peut être commandé plusieurs fois dans
différentes commande
N° de commande Quantité commandée N° de commande
Quantité commandée
Réf du produit
Réf du produit Quantité commandée
Le Modèle Conceptuel de Données (MCD)
Contraintes d’intégrité |Contrainte d’intégrité fonctionnelle (ou dépendance fonctionnelle)
• Graphe de dépendances fonctionnelles

Une représentation graphique de toutes les dépendances qui existent entre les données
prises en charge dans l’étude

Exemple
Le Modèle Conceptuel de Données (MCD)
Contraintes d’intégrité |dépendance fonctionnelle
• Transformation du GDF en MCD
 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
Le Modèle Conceptuel de Données (MCD)
Contraintes d’intégrité |Contrainte d’intégrité fonctionnelle (ou dépendance fonctionnelle)
• Transformation du GDF en MCD
 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.
Le Modèle Conceptuel de Données (MCD)
Contraintes d’intégrité |dépendance fonctionnelle
• Transformation du GDF en MCD
 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
Le Modèle Conceptuel de Données (MCD)
Les étapes pour la construction d'un MCD

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).
Le Modèle Conceptuel de Données (MCD)
Les étapes pour 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
Le Modèle Conceptuel de Données (MCD)
Mise en œuvre des étapes de réalisation d'un modèle conceptuel de données
Etude de cas: TD1
On considère le Système d'Information suivant :
« Un abonné est inscrit à une ou plusieurs rubrique. Chaque rubrique
envoie une NewsLetter chaque semaine aux abonnés de la rubrique
correspondant. Un abonné a une motivation d'inscription parmi
plusieurs possibles. »
T.A.F:
(1) Identifier les entités présentes
(2) Lister les propriétés des entités
(3) Identifier de manière unique chaque occurrence
(4) Etablir les relations entre les différentes entités
(5) Identifier les cardinalités
Le Modèle Conceptuel de Données (MCD)
Etude de cas: TD1
(1) Identifier les entités présentes
Généralement, une entité est crée dans le Système d'Information si elle possède au moins 2
occurrences. Chaque élément d'une entité est appelé une occurrence de l'entité
• L'entité ABONNES représente l'ensemble des abonnés.
• L'entité RUBRIQUES représente l'ensemble des rubriques auxquelles l'abonné peux
s'inscrire.
• L'entité NEWSLETTERS représente les newsletters envoyées,
• L'entité MOTIVATIONS représente l'ensemble des motivations d'inscriptions des
abonnés.
Le Modèle Conceptuel de Données (MCD)
Etude de cas: TD1
(2) Lister les propriétés des entité
☞ Un Abonné est caractérisé par son nom, son prénom, son âge, son sexe, sa profession, sa rue, son
code postal, sa ville, son pays, son téléphone et son email.
☞Une Newsletter est caractérisée par son sujet, sa date d'envoi et son contenu.
☞Une Motivation est caractérisée par son intitulé.
☞Une Rubrique est caractérisée par son nom.
Le Modèle Conceptuel de Données (MCD)
Etude de cas: TD1
(3) Identifier de manière unique chaque occurrence
Imaginons que nous ayons deux abonnés qui s'appellent ‘Ahmed’ : il est nécessaire de les distinguer
sous peine de les confondre. On rajoute alors une propriété qui permettra d'identifier de manière
unique chaque occurrence. Cette propriété est appelé l' identifiant de l'entité. Cela peut être une
référence interne, un code, ou plus généralement un nombre entier. Cette propriété est soulignée
afin de mettre en évidence son rôle d'identifiant.
Le Modèle Conceptuel de Données (MCD)
Etude de cas: TD1
(4) Etablir les relations entre les différentes entités
Reprenons notre texte initial : "Un Abonné a une Motivation. Un Abonné s'inscrit à une ou
plusieurs Rubriques. Chaque Rubrique envoie une NewsLetter."
Le Modèle Conceptuel de Données (MCD)
Etude de cas: TD1
(5) Identifier les cardinalités
☞ Un Abonné a ici une et une seule Motivation d'inscription, le marketing ayant imposé un champ
obligatoire afin d'avoir cette valeur. On a donc 1 minimum, et 1 maximum. D'où la cardinalité (1;1).
☞ Une Motivation donnée concerne 0 ou plusieurs Abonnés. On a donc 0 minimum, et n en
maximum. D'où la cardinalité (0;n).
☞ De même, un Abonné s'inscrit à une ou plusieurs Rubriques : (1;n),
☞ Et une Rubrique possède 0 ou plusieurs Abonnés : (0;n). Enfin, une Rubrique envoie 0 ou
plusieurs Newsletters : (0;n),
☞ Et une Newsletter appartient à une et une seule Newsletter : (1;1)
Le Modèle Conceptuel de Données (MCD)
Etude de cas: TD1
(5) Identifier les cardinalités
Le Modèle Logique de Données (MLD)
Définition:
formalisme des tables logiques basé sur un MCD
Un MLD est essentiellement composé de tables logiques reliées entre elles par des flèches.

Ex.
Le Modèle Logique de Données (MLD)
Les règles de transformation du MCD au MLD
Passage MCD au MLD est basé sur notions suivantes:
 Toute entité est transformée en table.
 Les propriétés de l'entité deviennent les attributs de la table.
 L'identifiant de l'entité devient la clé primaire de la table.
Table Colonnes
Entité
Ex.

Id_empl Nom Prenom age fonction

Employé
Id-employé
nom
Prénom
age
fonction

Employé (id_emp, nom, prenom, age, fonction)

Propriétés
Le Modèle Logique de Données (MLD)
Transformation des relations binaires de type (x,1) – (x,1):
Nous devons distinguer plusieurs cas. Sachant qu'une relation binaire du type (1,1)-(1,1) ne
doit pas exister il nous reste les 2 cas suivants:
 Relation binaire (0,1)-(1,1)
 Relation binaire (0,1)-(0,1)

 Relation binaire (0,1)-(1,1)

On duplique la clé de la table basée sur l'entité à cardinalité (0,1) dans la table basée sur
l'entité à cardinalité (1,1).
Le No_Client, qui est
clé primaire de la
table Client, devient
clé étrangère dans la
table Carte_Membre
Le Modèle Logique de Données (MLD)
Transformation des relations binaires de type (x,1) – (x,n):
 Une association de type (1:n) (c’est à dire qui a les cardinalités maximales positionnées à «
1 » d’une côté de l’association et à « n » de l’autre côté) se traduit par la création d’une clé
étrangère dans la relation correspondante à l’entité côté « 1 ».
 Cette clé étrangère référence la clé primaire de la relation correspondant à l’autre entité.

Commande
Client
0,n 1,1 Num_commande
Num_client
passer Date_commande
nom
Prénom
adresse

Client Commande
Num_client
Num_commande
nom Date_commande
Prénom #Num_client
adresse
Le Modèle Logique de Données (MLD)
Transformation des relations binaires de type (x,n) – (x,n):

On crée une table supplémentaire ayant comme clé primaire une clé composée des clés
primaires des 2 tables. Lorsque la relation contient elle-même des propriétés, celles-ci
deviennent attributs de la table supplémentaire. Une propriété de la relation qui est
soulignée devra appartenir à la clé primaire composée de la table supplémentaire.
Le Modèle Logique de Données (MLD)
Transformation des relations Ternaires
On crée une table supplémentaire ayant comme clé primaire une clé composée des clés
primaires de toutes les tables reliées. Cette règle s'applique de façon indépendante des
différentes cardinalités. Lorsque la relation contient elle-même des propriétés, celles-ci
deviennent attributs de la table supplémentaire. Une propriété de la relation qui est soulignée
devra appartenir à la clé primaire composée de la table supplémentaire.