Module 24 : Système d’information et base de données

Chapitre 2 :
Modèle Entité-Association EA
(ou Modèle conceptuel de données (MCD))
Partie 2

Pr. YOUNES RABIA Parcours : MIP S4

Pr. LAMYAA CHIHAB
1
 Plan du chapitre 2 : Modèle entité-association (MCD) (Partie 2 )

 Modèle Entité-Association (EA) : Présentation

 Concepts manipulés :
• Entité
• Association
PARTIE 1 • Propriétés
• Identifiant
• Cardinalités
• Occurrence
 Règles de gestion (Contraintes d’Intégrité)
 Dictionnaire de données
 Principes de normalisation :
PARTIE 2 o Règles générales relative au MCD
o Dépendances Fonctionnelles (DF)
o Formes Normales (FN) 2
4  Dictionnaire de données

3
 Dictionnaire de données

Présentation
 Un dictionnaire de données (DD) est une collection de données de référence nécessaire à la conception d'une BD.

 Le DD a une importance stratégique particulière, car il est le vocabulaire commun de l’entreprise .

 La liste de toutes les propriétés des entités est définie dans le DD.

 Le DD contient pour chaque propriété tout ou partie des éléments suivants :

o Nom, type et sa longueur, nature, description, contrainte ou remarques, ….

4
 Dictionnaire de données

Exemple

5
 Dictionnaire de données

Caractéristiques
 Une propriété définie dans le DD doit être :

o Pertinente : présente un intérêt pour le domaine étudié.

o Unique dans le modèle : deux ou plusieurs entités ne peuvent jamais avoir une même propriété.

 Exemple :

si NFACT (numéro de facture) est défini comme propriété dans l’entité Facture, celle-ci ne peut pas être définie dans l’entité Client.

6
 Dictionnaire de données

Caractéristiques
 Une propriété définie dans le DD doit être (suite) :

 Brut : non calculée.

o Exemple : la propriété MTTC (Montant Toute Taxe Comprise) est calculée à partir de MHT (montant hors taxe) et TVA.

 Atomique: non décomposable (cette décomposition est relative à son exploitation dans la BD.

o Exemple : adresse est une propriété décomposable (contient : rue, num, ville …).

 A une seule signification : n’a pas plusieurs sens.

o Exemple :

 Date est une propriété qui peut représenter la date de la commande client et la date de livraison.

 Dans ce cas, il faut utiliser deux propriétés : DateCmde pour la date de la commande et DateLiv pour la date de

livraison. 7
5  Normalisation

 Règles générales relative au MCD

 Dépendances Fonctionnelles (DF)
 Formes Normales (FN)

8
 Normalisation

Introduction
 L'objectif de la normalisation est de construire un schéma de BD cohérent : concevoir un bon schéma d’une BD sans risques
d'anomalie.
 La normalisation est utile pour :
o limiter les redondances de données
o limiter les pertes de données
o limiter les incohérences au sein des données
o améliorer les performances des traitements.

 La normalisation de BD se fait à l’aide de plusieurs mécanismes :

o Les Dépendances Fonctionnelles (DF) : elles traduisent des contraintes sur les données.
o La Décomposition progressive des relations.
o Les Formes Normales (FN) : elles définissent des relations bien conçues.
o …
9
5.1  Règles générales relatives au MCD

10
 Normalisation

5.1 Règles générales relative au MCD

Un bon schéma EA doit répondre aux règles de normalisation suivantes :

 Normalisation des entités: toutes les entités qui sont remplaçables par une association doivent être remplacées.
 Normalisation des noms: le nom d’une entité, d’une association ou d’un attribut doit être unique.

o Pour les entités, utiliser un nom commun au pluriel (ex: clients)

o Pour les associations, utiliser un verbe à l’infinitif ( ex: effectuer)

o Pour les attributs, utiliser un nom commun singulier (ex: nom de client, N°Client).

 Normalisation des identifiants : chaque entité doit posséder un identifiant.

o Éviter les identifiants composés de plusieurs attributs

o L’identifiant est généralement un entier

11
 Normalisation

5.1 Règles générales relative au MCD

• Normalisation des attributs :

o Remplacer les attributs en plusieurs exemplaires en une association supplémentaire de cardinalités maximales n.

o Ne pas ajouter d’attribut calculable à partir d’autres attributs

12
 Normalisation

5.1 Règles générales relative au MCD

• Normalisation des attributs des associations :

o Une entité avec une cardinalité de 1,1 ou 0,1 aspire les attributs de l’association.

13
 Normalisation

5.1 Règles générales relative au MCD

• Normalisation des associations :

o Il faut éliminer les associations fantômes.

Les cardinalités sont toutes 1,1 donc c’est une association fantôme.
14
 Normalisation

5.1 Règles générales relative au MCD

• Normalisation des associations :

o Il faut éliminer les associations redondantes.

 Si le client ne peut pas régler la facture d’un autre client, alors l’association payer est inutile et doit être

supprimée (dans le cas contraire, l’association payer doit être maintenue).

15
 Normalisation

5.1 Règles générales relative au MCD

• Normalisation des associations :

o Il faut éliminer les associations en plusieurs exemplaires.

 Une association suffit pour remplacer les 4 associations participer en tant que …
16
 Normalisation

5.1 Règles générales relative au MCD

 Normalisation des cardinalités :

o Une cardinalité minimale est toujours 0 ou 1 ( et pas 2, 3 ou n)

o Une cardinalité maximale est toujours 1 ou n ( et pas 2, 3, ..).

o Si une cardinalité maximale vaut 2, 3 ou plus, alors nous considérons quand même qu’elle est indéterminée et

vaut n.

o Avec une cardinalité maximale de 0, l’association n’aurait aucune signification

17
5.2  Dépendances Fonctionnelles (DF)

18
 Normalisation

5.2 Dépendances Fonctionnelles (DF) : Définition

 Pour établir efficacement un MCD bien normalisé, on peut étudier au préalable les DF entre les attributs.

 La notion de DF est introduite par Codd en 1970.

 On dit qu'il existe une DF entre un attribut A1 et un attribut A2, si connaissant une valeur de A1, on ne peut lui associer qu'une seule valeur de A2.

on note : A1 → A2

 On dit aussi que :

o A1 détermine A2.

o A2 est fonctionnellement dépendant de A1.

o A1 est la source de la DF.

o A2 le but de la DF.

 Objectif:

o La recherche des DF permet d’identifier les clés primaires et les clés étrangères des entités
19
 Normalisation

5.2 Dépendances Fonctionnelles (DF) : Exemple

• Exemple 1

o On considère la BD suivante composée des relations: Etudiant, Notes et Matière :

Etudiant Notes Matière

o Connaissant un NumEtud, on connaît de manière unique le nom de cet étudiant et, entre autres, sa DatNaiss. On a donc la

DF:

NumEtud → NomEtud, DatNaiss

o Dans la table Notes, la DF : NumEtud → Note est fausse.

o En effet, connaissant un NumEtud, on peut connaître les notes qu'il a obtenu dans chaque matière.

o La connaissance du NumEtud ne permet donc pas de connaitre une note particulière et il n'y a donc pas de DF. 20
 Normalisation

5.2 Dépendances Fonctionnelles (DF) : Exemple

 Exemple 2

 Soit la table Anniversaire suivante :

numéro amie ville cadeau

1 Sylvie Dupont Nice Fleurs
2 Sylvie Dupont Nice Collier
4 Corinne Durand Menton Fleurs
12 Juliette Dubois Nice Livre
14 Corinne Durand Menton Livre

 On peut déterminer les DF suivantes pour cette table :

o numéro → amie, ville, cadeau

o amie → ville
21
 Normalisation

5.2 Dépendances Fonctionnelles (DF) : Caractéristique

 DF simple :

• Une DF est simple si sa source n'est composée que d'un seul attribut.

• Une DF simple caractérise une entité dont la source est la clé et dont le but est constitué des propriétés de l’entité.

• Exemple: Soit la relation : PRODUIT (no_prod, nom, prixUHT).

no_prod → (nom, prixUHT) est une DF simple.

 DF composée :

• Une DF est composée si sa source est composée de plusieurs attributs.

• Une DF composée caractérise une association entre entités dont la source est la clé et dont le but est constitué des

propriétés de l’association.

• Exemple: Soit la relation : Notes (Num_Etud, Num_Mat, Note)

(Num_Etud, Num_Mat) → Note est une DF composée. 22

 Normalisation

5.2 Dépendances Fonctionnelles (DF) : Type

 DF simple :

• Une DF X  Y est dite élémentaire si :

o Y est un attribut unique non inclus dans X.

o il n’existe pas de X’ inclus dans X tel que X’  Y (Y ne dépend pas d’une partie de X)

o Exemple:

Soit la table Fournisseur suivante :

Fournisseur comporte la DF élémentaire:

Four_No, Piece_No ➔ Quantite

 En effet, une quantité de pièces n'a de sens que pour un fournisseur et un type de pièce donnés : pour un

fournisseur on peut avoir différentes quantités de pièces et il n'existe donc pas de DF Four_No ➔ Quantite. 23
 Normalisation

5.2 Dépendances Fonctionnelles (DF) : Type

 DF élémentaire directe :
 X → Y est directe si :
o elle est élémentaire.
o Y ne dépend pas transitivement de X (il n'existe pas d'ensemble d'attributs Z tel que X→ Z et Z →Y).
 Contre exemple:
o numéro-étudiant → numéro-section
o numéro-section → nom-section
o numéro-étudiant → nom-section n’est pas directe

 DF triviale :

 Une DF X → Y est triviale si Y ⊆ X.(inclus , est un sous ensemble de )

Exemple : {Employee_ID, Employee_Name} → Employee_ID est également une dépendance fonctionnelle triviale depuis
Employee_ID est un sous-ensemble de {Employee_ID, Employee_Name} .

 DF canonique :
24
 Une DF X → Y est canonique si sa partie droite ne comporte qu’un seul attribut.
 Normalisation

5.2 Dépendances Fonctionnelles (DF) : Type

 Un attribut ou une liste d’attributs X est une clé pour l’entité R(X,Y,Z) si X → Y ∪ Z.

 Exemple :

o Soit l’entité PRODUIT (NumProd, NomProd, PrixProd)

o Le NumProd permet d’identifier de manière unique tous les produits de l’entreprise.

o NumProd est donc la Clé primaire

 L’attribut (ou liste d’attributs) X est une clé minimale si X → Y ∪ Z est élémentaire.

25
 Normalisation

5.2 Dépendances Fonctionnelles (DF) : Cas « Vente par correspondance »

26
27
Listes des dépendances fonctionnelles :
RefArticle StockArticle Propriétés

NumColis DateExp
IndicateurColis

RefPointDis

RefCommande RefClient

NumColis RefCommande

NumColis RefClient ( Dépendance par transitivité )

RefArticle,RefCommande QteCommande

RefArticle,NumColis QteExp

RefArticle,NumColis QteAcceptee 28
5.3  Formes Normales (FN)

29
 Normalisation

5.3 Formes Normales : Introduction

 Pour qu’un MCD soit normalisé, il faut qu’il respecte certaines contraintes appelées les formes normales.

 Les formes normales (théorèmes de CODD) sont différents stades de qualité qui permettent d’éviter la

redondance dans les BD.

 Les formes normales s’appuient sur les dépendances fonctionnelles entre attributs.

 Le mécanisme de normalisation est fondé sur les notions de clé et de dépendances entre données.

30
 Normalisation

5.3 Formes Normales : Introduction

 Il existe une hiérarchie dans les 4 règles de normalisation :

o une relation en 2ème FN est forcément en 1ère FN

o une relation en 3ème FN est forcément en 2ème FN

o une relation en FN de Boyce-Codd est forcément en 3ème FN

o etc.

31
 Normalisation

5.3 Formes Normales : 1ere FN (1FN)

 Une entité est en 1FN si, et seulement si,

1. elle possède une clé.
2. tout attribut contient une valeur atomique (non multiples, non composées).
 Objectif : permettre de vérifier les DF.
 Solution : décomposition de l’attribut en plusieurs attributs ou décomposition de la relation en deux relations.
 Exemple:
 Soit l’entité ELEVES suivante :
 ELEVES (no-elv, nom, prenom, liste_notes)
 L’entité n’est pas en 1FN car un attribut ne peut pas être un ensemble de valeurs.
 Solution : décomposer en l’entité ELEVES en :
 ELEVES (no-elv, nom, prenom)
 NOTES (no-elv, no-matiere, note)

32
 Normalisation

5.3 Formes Normales : 2eme FN (2FN)

 Une entité est en 2FN si :

1. la relation est en 1FN.
2. tout attribut qui n’appartient pas à la clé ne dépend pas d’une partie de la clé ( tout attribut doit dépendre de la clé par une
DFE).
 Objectif : rechercher la redondance d’information dans une entité;
 Corollaire: Une entité ayant une clé formée d'un seul attribut est donc en 2FN.
 Solution : décomposition de la relation en deux relations.
o Exemple: une entité en 1FN qui n'est pas en 2FN :
COMMANDES (date, no-cli, no-prod, qte, prixUHT):
• elle n'est pas en 2FN car la clé est (date, no-cli, no-prod), mais on a la DF suivante : no-prod → prixUHT.
• Décomposition
• COMMANDES( date, no-cli, no-pro, qte)
• PRODUITS( no-pro, nom_prod, prixUHT)
33
 Normalisation

5.3 Formes Normales : 3eme FN (3FN)

 Une entité est en 3FN si :

1. la relation est en 2FN.
2. Il n’existe aucune DF entre attributs non clé (aucun attribut ne doit dépendre de la clé par transitivité).
 objectif : élimination des redondances dues aux DF déduites par transitivité.
 solution : décomposition de la relation en deux relations.
 Corollaire : Une entité en 2FN ayant un seul attribut n'appartenant pas à la clé est en 3FN.
o Exemple : une relation en 2FN qui n'est pas en 3FN :
CLIENTS (code_client, nom_client, code_categorie, nom_categorie)
Cette relation n’est pas en 3FN car la DF code_client → nom_categorie n’est pas directe du fait de la transitivité:
code_client → code_categorie → nom_categorie
• Décomposition :
 CLIENTS (code_client, nom_client)
 CATEGORIES (code_categ, nom_categ)
34
 Normalisation

5.3 Formes Normales : FN de BOYCE-CODD (FNBC)

 Le respect de la 3FN ne garantit pas une absence de redondance des données d'où la forme normale de BOYCE-CODD (FNBC).
 Une entité est en FNBC si :
1. Il est en 3FN
2. tous les attributs non-clé ne sont pas source de DF vers une partie de la clé.
 La FNBC impose que toutes les parties gauches des DF sont des clés.
 Objectif : la FNBC permet de renforcer certaines lacunes de la 3FN.
o Exemple : une entité en 3FN qui n'est pas FNBC : CODEPOSTALS (ville, rue, code)
elle n'est pas en BCNF, car la clé est (ville, rue), et on a la DF : code → ville.
 Décomposition :
 CODES_Ville(code, ville)
 CODES_Rues(code, rue)

NB : Le non-respect de la 2FN, 3FN et la FNBC entraîne de la redondance, une même donnée étant répétée un nombre
35
considérable de fois
 Etude de cas: Agence immobilière

1. Base de données initiale:

• On a les attributs Num_Client , Nom_client , ne contiennent pas une valeur atomique (non multiples, non composées).
• il faux donc faire la décomposition de l’attribut en plusieurs attributs pour obtenir un schéma en 1er forme normal
36 :
Etude de cas: Agence immobilière

2. Base de données en 1ère forme normale (FN1)

37
Etude de cas: Agence immobilière

3. Dépendances fonctionnelles et clé:

Dépendances fonctionnelles
Num_Client -----> Nom_Client ;
Num_Client ,Num_App -> DateD_Loc , DateF_Loc
Num_App ----> Adr_App, Montant, Num_Prop ,Nom_Prop ;
Num_Prop -----> Nom_Prop;

Clé :
(Num_Client ,Num_App) détermine tous les attributs de la relation

38
Etude de cas: Agence immobilière

4. Mise en 2ème forme normale (FN2)

 Supposons qu’on veut modifier ou corriger l’adresse d’un appartement apparaissant plusieurs fois dans la table (différents
locataires à différentes périodes) => il faut modifier plusieurs n-uplets !
 Ceci est du au fait que certains attributs ne dépendent pas pleinement de la clé, et qu’il existe donc des dépendances partielles.

 Il faut donc décomposer R pour obtenir un schéma en 2ème forme normale :

39
Etude de cas: Agence immobilière
4. Mise en 2ème forme normale (FN2)

40
Etude de cas: Agence immobilière

5. Mise en 3ème forme normale (FN3)

 Supposons qu’on veut modifier ou corriger le nom d’un propriétaire apparaissant plusieurs fois dans la table
(propriétaire de plusieurs appartements) => il faut modifier plusieurs n-uplets !

 Ceci est du au fait qu’il existe une dépendance transitive entre Num_App, Num_Prop et Nom_Prop (cf.
schéma précédent).

 Il faut donc décomposer R2 pour obtenir un schéma en 3ème forme normale :

41
Etude de cas: Agence immobilière
5. Mise en 3ème forme normale (FN3)

42
 Récapitulatif

43
 Construction du MCD
Récapitulatif

Généralement, la démarche à suivre pour la conception et la réalisation d’un MCD est constituée des étapes suivantes:
1. Recueil des informations :
 Interview de la direction (Système de Pilotage):
o objectifs principaux
o liste des postes de travail
o délimiter le champs de l’étude
 Interview des postes de travail (Système Opérant):
o Recenser et décrire les tâches exécutées
o Observer la circulation des informations
o Apprendre le langage de l’entreprise
2. Etablissement d’une liste des règles de gestion (CI)
3. Construction d’un dictionnaire de données (DD).
 Construction du MCD
Récapitulatif

4. Construction des Dépendances Fonctionnelles :

 Identification des entités, des associations, des attributs, des cardinalités.
 Extraire du DD la liste des attributs qui ne sont ni concaténés, ni calculés.
 Normalisation : appliquer les formes normales, élimer toutes les transitivités, …
5. Transformation du graphe des DF en MCD.
6. Mise au propre du MCD :
 En résumé, on peut vérifier le MCD obtenu en appliquant les règles suivantes :
o Règle1 : touts les Propriétés doivent être élémentaires.
o Règle2 : chaque entité doit posséder un identifiant et un seule.
o Règle3 : l’identifiant détermine d’une manière unique touts les Propriétés de l’entité.
o Règle4 : une Propriété ne peut qualifier qu’une seule entité ou qu’une seule association.
o Règle5 : les Propriétés d’une association doivent dépendre de la totalité des identifiants des entités participantes.
MERCI

46