M44 - Chapitre-2 - BD Relationnelles Et SGBD MySQL

Université Abdelmalek Essaâdi
Faculté des Sciences et Techniques d’Al-Hoceima

Département de Physique
Année universitaire : 2022 - 2023
MST : Systèmes Embarqués et Robotique (MST-SER) – S2
Cours du Module M44 : « Bases de données avancées »
Chapitre 2 : BD relationnelles et SGBD MySQL
Pr. A. El Mhouti FSTH

Plan du chapitre 2 : BD relationnelles et SGBD MySQL
 Modèle Entité-Association (modèle EA ou MCD)

 Présentation
 Concepts manipulés Niveau conceptuel
 Règles de Gestion (RG)
 Dictionnaire de Données (DD)
 Normalisation du modèle EA (ou MCD)

 Règles générales relative au MCD
 Dépendances Fonctionnelles (DF)
 Formes Normales (FN)
 Modèle relationnel ( ou MLD)

 Introduction
 Principaux concepts Niveau logique
 Intégrité référentielle
 Règles de passage du modèle EA au modèle relationnel
Pr. A. El Mhouti 2 FSTH

Rappel : méthodologie de conception d'une BDR
Niveaux de conception
 Externe : sous-schéma conceptuels

 Conceptuel : représenter le problème à l'aide de représentations graphiques et
partiellement formelles. Formalismes utilisés : modèle EA (MCD), UML, …
 Logique : Schéma logique. Exemples de formalismes utilisés : Relationnel (MLD),
Objet, Relationnel-Objet, …
 Physique : Implémentation à l’aide d’un SGBD : MySQL, Oracle, PostgreSQL, ….
La modélisation conceptuelle des BD relationnelle est faite avec le formalisme EA

(Entité-Association) de la méthode MERISE.
Rappel : méthodologie de conception d'une BDR
Niveaux conceptuel
 Au niveau conceptuel, il s'agit de l'élaboration du Modèle Conceptuel des

Données (MCD) qui est une représentation graphique et structurée des
informations mémorisées par un SI.
 Le MCD est basé sur deux notions principales : les entités et les associations,
d'où sa seconde appellation : le schéma Entité/Association.
 L'élaboration du MCD passe par la :

 la mise en place de règles de gestion (si celles-ci ne vous sont pas données) ;
 l'élaboration du dictionnaire des données ;
 la recherche des dépendances fonctionnelles entre ces données ;
 l'élaboration du MCD (création des entités puis des associations puis ajout
des cardinalités).

Modèle Entité-Association (EA)

Modèle EA
Présentation
 Le modèle EA est un modèle conceptuel conçu par Chen en 1976.
 Le but de ce modèle est de permettre la description conceptuelle des données

d’une application : création d’un MCD à l'aide de représentations graphiques et
partiellement formelles.
 Il correspond au niveau conceptuel de la méthode MERISE.
 Les concepts de base qui correspondent aux concepts d’abstraction de la réalité

sont : Entité
◼ Objet  entité Association
◼ Lien association
◼ Propriété  attribut
Attribut

Modèle EA
Entité
 Définition :
 Une entité est la représentation dans la BD d’un objet concret ou abstrait
(matériel ou immatériel) du monde réel.
 Exemples :
 Dans la BD d’une société, on peut identifier les entités suivantes :
◼ Client
◼ Voiture
◼ Produit
◼ Daignostic
◼ ….

Modèle EA
Association
 Définition :
 Une association est une représentation d'un lien sémantique non orienté
entre plusieurs entités (qui jouent un rôle déterminé).

 Il est souhaitable de limiter la dimension des associations à deux
(associations binaire).
 Plus la dimension d’une relation est grande, plus la relation devient
complexe et difficile à gérer.

 Exemple :
 Association “Conduire” entre les entités : “Conducteurs” et “Voiture” :
Conduire est une association entre un Conducteur et une Voiture.

Modèle EA
Association
 Rôles d’une association :

 Dans une association, chaque entité joue un rôle déterminé.
 Association binaire ➔ deux rôles :

Modèle EA
Association
 Dimension d’une association :

 La dimension d’une association est le nombre d’entités qu’elle relie :
◼ Association binaire : reliant deux entités.
◼ Association n-aires : reliant plusieurs entités (avec n > 2)
◼ Association cyclique (réflexive) : qui associe les occurrences d’une

même entité.
◼ Association plurielle : deux mêmes entités peuvent être plusieurs fois

en association.
Modèle EA
Association
 Association cyclique (réflexive) :

 C’est une association branchée plusieurs fois (plusieurs rôles) à la même
entité.
 Exemple :
➢Tout employé est dirigé par un autre employé
(sauf le directeur général)
➢« Diriger » est une association entre un
« Employé » et un autre « Employé »
 Remarque : pour faciliter la lecture, on doit spécifier le rôle de chaque entité.

 Exemple : association cyclique avec rôles nommés :
« marié à » est une association entre une personne (femme) et une autre personne (mari).

Modèle EA
Association
 Association n-aire :
 Exemple 1: une association ternaire (lie 3 entités):
« Assurer » est une association (ternaire) entre un Enseignant, une Matière et un Groupe
 Exemple 2: Association ternaire cyclique :

Modèle EA
Association
 Association plurielle :
 Elle permet de relier deux mêmes entités plusieurs fois en association.
 Exemple :

Modèle EA
Association
 Il est utile parfois d’ajouter des rôles pour faciliter la lecture de l’association.
 Exemple :

Modèle EA
Propriétés
 Définition :
 La propriété (ou attribut) représente la plus petite quantité d’informations
caractérisant une entité ou une association.
 La propriété peut être utilisée d’une manière autonome et présente un intérêt pour
le domaine à étudier.
 Exemples :
 L’entité Clients est caractérisée par les propriétés : N° client, nom, prénom, adresse.
 L’association Commander est caractérisé par les propriétés : Quantité, Date.
 Une propriété se décrit par son nom, une description, son type, sa longueur.
Modèle EA
Propriétés
 Une propriété peut être :

 simple (atomique) : non décomposable (il ne peut prendre qu'une seule valeur).
◼ Exemples : jour, prénom
 complexe : décomposé en d'autres attributs
◼ Exemple : l’attribut « date » peut être décomposée en jour, mois, année
 Obligatoire : une valeur au moins par occurrence.

◼ Exemples : nom, prénoms
 Facultative : peut ne pas prendre de valeur.

◼ Exemples : salaire, téléphones
 monovaluée : une seule valeur par occurrence.

◼ Exemples: date de naissance, numéro sécurité
 multivaluée : plusieurs valeurs par occurrence.
◼ Exemples: prénoms, téléphones

Modèle EA
Identifiant (id)
 Un identifiant est une Propriété spéciale (d’une entité ou d’une association) permettant
d’identifier de manière unique chaque occurrence d’un type d’entités (d’associations).
 Un identifiant est constitué d’un ensemble minimal de propriétés permettant de
distinguer sans ambiguïté une occurrence de l’entité.
 Toute entité doit avoir un identifiant.
 MERISE propose de souligner l’identifiant ou de le précéder par le caractère #.
 Exemple :
 L’id de l’entité Clients est N° Client car 2 clients ne peuvent pas avoir le même N°.
 L’id de l’entité Articles est N° Article car 2 articles ne peuvent pas avoir le même N°.

Modèle EA
Identifiant
 Un identifiant peut être :

 simple : quand il est constitué d’une seule propriété.
 composé : quand il est constitué de plusieurs propriétés.
 Exemple : soit l’entité Clients suivante :
 Dans cet entité, deux identifiants possible :

◼ N°client : identifiant simple
◼ nom+prénoms : identifiant composé
 Remarque : Si une entité est identifiable par plusieurs identifiants, l’un d’eux est choisi
comme clé primaire.
Modèle EA
Identifiant d’une Association
 L’identifiant d’une association peut être construit selon les possibilités suivantes :
 1ère possibilité : attribut(s) propre(s) :
L’identifiant de l’association commande est : N°commande
 2ème possibilité : identifiant construit des identifiants des entités liées :
L’identifiant de l’association Inscrit est : Etudiant.N°carte + Cours.N°cours

Modèle EA
Identifiant d’une Association
 3ème possibilité : identifiant construit des identifiants des entités liés + attribut(s)
propre(s) :
(Un client peut commander le même produit plusieurs fois à des dates différentes)
L’identifiant de l’association Commande est : Client.N°client + Produit.N°produit +date
 4ème possibilité : Tout rôle mono-valué induit un identifiant de l’association

(l’identifiant de l’entité liée est aussi identifiant de l’association)
l’identifiant de l’association Assure est :

Voiture.N°imm

Modèle EA
Cardinalités
 La cardinalité d'une association indique le nombre d'occurrences (minimales et

maximales) de chaque entité qui sont autorisées à participer à l’association.
 La cardinalité est définie pour les deux sens de l’association.
 Elle est notée sous la forme (min,max), où :
◼ min est le nombre minimum d’occurrences de l’entité1 relié à l’entité2.
◼ max est le nombre maximum d’occurrences de l’entité1 relié à l’entité2.
(min,max) (min,max)
 Les valeurs possibles d'une cardinalité minimale sont 0 ou 1.

 Les valeurs possibles d'une cardinalité maximale sont 1 ou n.

Modèle EA
Cardinalités
 Exemple : Dans la relation « Commander » suivante :
◼ Combien d’articles minimum un Client peut-il commander ?
◼ Combien d’articles maxmum un Client peut-il commander ?
 → un client peut commander 1 ou plusieurs Articles

→ un article peut être commandé par 0 ou plusieurs clients

Modèle EA
Cardinalités
 Dans la pratique on gère les cardinalités suivantes :

 0,1 : Chaque occurrence de l’entité est relié à au plus une occurrence de
l’association.
◼ Exemple : Un employé est responsable d’au plus un service.
 1,1 : Chaque occurrence de l’entité est relié exactement à une occurrence de

l’association.
◼ Exemple : Un compte bancaire appartient à un client et un seul.
 0,N : Chaque occurrence de l’entité est relié à un nombre quelconque d’occurrence

de l’association.
◼ Exemple : Une personne possède 0 ou N voitures.
 1,N : Chaque occurrence de l’entité est relié à au moins une occurrence de

l’association.
◼ Exemple : Un enseignant assure au moins un cours.

Modèle EA
Cardinalités
 Dans le cas des relations binaires, ce qui est fréquent est résumé dans le
tableau suivant :
Entité1/Entité2 0-1 1-1 0-N 1-N
0-1 ? ? ✓ ✓
1-1 ? * ✓ ✓
0-N ✓ ✓ ✓ ✓
1-N ✓ ✓ ✓ ✓
 ? : il faut se demander si l’une des entités n’est pas propriété d’une autre.
 • : à éviter car il traduit souvent une erreur de conception.

Modèle EA
Cardinalités et associations
 Lorsque autour d’une entité, toutes les associations ont pour cardinalités maximales 1
au centre et n à l’extérieur, cette entité est candidate pour être remplacée par une
association branchée à toutes les entités voisines avec des cardinalités identiques 0,n.
 Exemple : soit la BD de gestion d’un cinéma suivante :

Modèle EA
Cardinalités et associations
 Remarques :
 La difficulté de concevoir une association n-aire directement est d’établir les bonnes
cardinalités.
 Il est donc conseillé d’en passer par un schéma EA dans lequel on ne trouve que des
associations binaires, puis de repérer les entités remplaçables par des associations.
 Cette règle permet d’éviter d’introduire une association ternaire abusive.
 Contre exemple :

Modèle EA
Occurrence : Occurrence d’une propriété
 Toute valeur prise par la propriété définit une occurrence de la propriété.

 Exemple :
 Considérons l’entité Etudiant caractérisée par les propriétés suivantes :
Numéro Nom Prénom Date_naiss Note_Arabe Note_Anglais

001 SLAOUI Amine 28/10/93 12,05 10,46
002 BENMOUSSA Latifa 08/10/92 8,81 10,44
003 HAJAMA Mohamed 23/01/94 10,31 11,09
004 FARAH Adil 02/09/92 9,30 13,09
005 KABAJ Ilham 26/07/91 0,00 0,00
 Dans ce tableau, on trouve les valeurs prises par les différentes propriétés.
 La propriété Prénom prend les valeurs (donc les occurrences !) : Amine, Latifa,
Mohamed, Adil, Ilham.
Modèle EA
Occurrence : Occurrence d’une entité
 L’ensemble de valeurs prises par les propriétés d’une entité définit l’occurrence de
l’entité.
Etudiant
 Exemple : soit l’entité Etudiant suivante :
Numéro
Nom
Prénom
Dans le tableau suivant, l’entité étudiant a 5 occurrences. Date_naiss
(Chaque ligne du tableau est une occurrence de l’entité). Note_Arabe
Note_Anglais
Numéro Nom Prénom Date_naiss Note_Arabe Note_Anglais

001 SLAOUI Amine 28/10/93 12,05 10,46
002 BENMOUSSA Latifa 08/10/92 8,81 10,44
003 HAJAMA Mohamed 23/01/94 10,31 11,09
004 FARAH Adil 02/09/92 9,30 13,09
005 KABAJ Ilham 26/07/91 0,00 0,00

Modèle EA
Occurrence : Occurrence d’une association
 Une occurrence d’une association est l’ensemble de valeurs prises par les propriétés de
l’association générée par des occurrences des entités impliquées dans l’association.
 Exemple : soit l’association « commander » suivante :
Occurrence

Modèle EA
Formalisme de représentation graphique
 La méthode Merise propose des représentations graphiques pour la plupart de notions

qu’elle utilise.
 Une entité est représentée par un rectangle dans lequel apparaissent son nom et ses
propriétés. L’identifiant est soulignée.
 Une association par une ellipse dans lequel apparaissent son nom et ses propriétés
éventuelles.
 Exemple :

Contraintes d’Intégrité (CI)
(ou règles de gestion)

Contraintes d’intégrité
Présentation
 Les règles de gestion du MCD précisent les contraintes qui doivent être respectées par la
base de données.
 Ce règles expriment les Contraintes d’Intégrité.
 Exemple : Dans le MCD d‘une école, les règles de gestion peuvent être les suivantes :
◼ RG1 : tout professeur enseigne en principe au moins une matière.
◼ RG2 : certains professeurs peuvent être dispensés d‘enseignement en raison de
leurs travaux de recherche.
◼ RG3 : toute matière est enseignée dans au moins une classe.
◼ RG4 : toute classe a au moins trois enseignants.
◼ …

Présentation
 Le MCD décrit les données ainsi que les CI.
 Les CI sont des règles définissant les états (CI statiques) et les transitions d'état (CI
dynamiques) possibles de la BD.
 Une BD est cohérente si toutes les CI définies sont respectées par les valeurs de la BD.
 A chaque insertion, modification ou suppression, les CI sont vérifiées automatiquement.
 Les CI doivent être décrites explicitement (avec un langage approprié) si elles ne

peuvent pas être décrites avec les concepts du modèle de données (MCD, MLD, …).

CI statiques
Il existe différents types de CI statiques :
 CI sur une propriété :
◼ type, liste des valeurs possibles, valeur par défaut …
 CI sur les propriétés d’une même entité :

◼ heure d’arrivée doit être supérieure à heure de départ Opération
N° opération
Libellé
 CI sur les propriétés d’occurrences distinctes d’une entité : Montant
Débit
◼ La somme des montants des opérations de Débit
Crédit
doit être égale à celle des opérations de Crédit.
 CI sur des propriétés d’entités différentes :

◼ date-achat doit être inférieure à la date-emprunt.
 …

CI dynamiques
 CI dynamiques :
 Permettent d’exprimer le fait que les valeurs des données d’un état
dépendent d’un des états précédents.
 Exemples :
◼ Le salaire d’un employé ne peut pas diminuer.

◼ Le nouvel âge d’un employé doit être supérieur à l’ancien.
Employé
N° employé
Salaire
Age

Dictionnaire de données
(DD)

Présentation
 Le Dictionnaire de Données (DD) est un document qui regroupe toutes les

données utiles à la base de données (et qui figureront donc dans le MCD).
 Le DD distingue les types de données suivants :

 donnée paramétrée: prend toujours la même valeur.
 donnée calculée: information qui pourra être retrouvée par le biais d’un
calcul grâce aux données élémentaires et paramétrées.
 donnée élémentaire : cette information pourra prendre plusieurs valeurs.
 Dans la conception de la Base de Données, on ne retiendra que les données

élémentaires.

Objectif
 Le DD à pour but de définir la liste de toutes les propriétés.

 Le DD contient pour chaque propriété tout ou partie des éléments suivants : son nom,
son type et sa longueur, sa nature, sa description et contrainte ou remarques, ….
 Exemple : DD d’une base de données décrivant l’entité « Client » :
Nom Type Nature Description Remarque Contrainte

Numéro Identifiant, ne
NumCli Num(15) Elémentaire
client peut être modifié
NomCli Char(15) Elémentaire Nom client
PrenomCli Char(15) Elémentaire Prénom client
… … … … … …

Principe
 Une propriété définie dans le DD doit être :

◼ Pertinente : présente un intérêt pour le domaine étudié.
◼ Unique : deux ou plusieurs entités ne peuvent jamais avoir une même
propriété.
◼ Brut : non calculée.
◼ Atomique: nom décomposable.
◼ A une seule signification :
◼ Exemple :
◼ « Date » est une propriété de l’entité « Produit » qui peut représenter la
« date de la commande client » et la « date de livraison ».
◼ Dans cet exemple, il faut utiliser deux propriétés pour représenter
chacune des deux dates : « DateCom » pour la date de la commande et
« DateLiv » pour la date de livraison.

Normalisation :
❑ Règles générales relatives au MCD
❑ Dépendances Fonctionnelles (DF)
❑ Formes Normales (FN)

Normalisation
Introduction
 La normalisation est une approche de conception de BD destinée à concevoir un bon
schéma d’une BD sans redondance d’information et sans risques d'anomalie.
 Exemple : l’entité « ACHAT» suivante contient une redondance de données :
Nom_Produit Quantité Couleur Nom_Fournisseur Adresse_Fournisseur
parapluie 110 rouge Alaoui Tanger
chapeau 50 vert Soulami Tétouan
sac à main 65 noir Karimi Kénitra
parasol 15 jeune Alaoui Tanger
ombrelle 5 rouge Alaoui Tanger
sac à main 65 noir Ramssi Tétouan
 Cette entité est redondante car les informations concernant les fournisseurs sont
redondantes.
 Si on veut modifier l'adresse du fournisseur « Alaoui », il faut absolument vérifier que
toutes les adresses de Alaoui sont modifiées: La BD devenaient incohérente.
 → L'objectif de la normalisation du MCD (et du MLD) est de construire une BD
cohérente (sans anomalie).
Normalisation
Introduction
 Les principales techniques de normalisation sont :
◼ Les Dépendances Fonctionnelles (DF) : traduisent des contraintes sur les
données.
◼ La Décomposition progressive des relations.
◼ Les Formes Normales (FN) : définissent des relations bien conçues.

Règles générales de normalisation relative au
MCD
Règles générales de normalisation
Normalisation des noms
 le nom d’une entité, d’une association ou d’un attribut doit être unique.
 Pour les entités, utiliser un nom commun au pluriel (ex: clients)
 Pour les associations, utiliser un verbe à l’infinitif ( ex: effectuer)
 Pour les attributs, utiliser un nom commun singulier (ex: nom de client, N°Client).
 Normalisation des identifiants : chaque entité doit posséder un identifiant.

◼ Éviter les identifiants composés de plusieurs attributs.
◼ L’identifiant est généralement un entier.
Normalisation des attributs
 Remplacer les attributs en plusieurs exemplaires par des entités avec des
associations supplémentaires de cardinalités maximales n.
 Ne pas ajouter d’attribut calculable à partir d’autres attributs.

Normalisation des associations
 Il faut éliminer les associations fantômes (toutes les cardinalités sont à 1,1).
Les cardinalités sont toutes 1,1 donc c’est une association fantôme.

Normalisation des associations
 Il faut éliminer les associations en plusieurs exemplaires.
Une association suffit pour remplacer les 4 associations « participer en tant que ».
Normalisation des cardinalités
 Une cardinalité minimale est généralement 0 ou 1 (et pas 2, 3 ou n)
 Une cardinalité maximale est généralement 1 ou n ( et pas 2, 3, ..).
 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.

Normalisation :

Dépendances fonctionnelles
(DF)
Définition
 La recherche de dépendances fonctionnelles (DF) est une technique de normalisation

qui vise à s'assurer que la base de données est correctement construite.
 Considérons la relation « Achats » suivante :
sac à main 65 noir Karimi Kénitra
sac à main 65 noir Ramssi Tétouan
 Cette relation est mal construite : les informations concernant les fournisseurs sont
redondantes.
 S'il faut modifier l'adresse du fournisseur « Alaoui », il faut absolument vérifier que
toutes les adresses de « Alaoui » sont modifiées. La BD est incohérente.

Définition
 Pour établir efficacement un MCD bien normalisé, on peut étudier/rechercher 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 :
◼ A1 détermine A2.
◼ A2 est fonctionnellement dépendant de A1.
◼ A1 est la source de la DF.

◼ A2 est le but de la DF.
 Exemple : Soit l’entité Voiture suivante :

Exemples de DF : NUMERO → COULEUR
TYPE → MARQUE
TYPE → PUISSANCE
(MARQUE, TYPE) → PUISSANCE
Objectif
 Une DF est une propriété sémantique, elle correspond à une contrainte supposée
toujours vrai du monde réel.
 De plus l'identification des DF est indispensable pour diminuer la redondance.
 Exemple : Soit l’entité »Enseignant » suivante :
 On peut déterminer les DF suivantes pour cette relation :

◼ numéro → Nom, Grade, Echelon, Salaire
◼ Grade, Echelon →Salaire
 la DF : Grade, Echelon →Salaire signifie que tout salaire dépend d’un grade et d’un
échelon.
Exemple
 Exemple 2 : On considère la BD suivante composée des relations: Etudiant, Notes et

Matiere:
Etudiant Notes Matière

 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
 La DF: NumEtud → Note est fausse.
 En effet, connaissant un NumEtud, on peut connaître les notes qu'il a obtenu dans
chaque matière.
 La connaissance du NumEtud ne permet donc pas de connaitre une note
particulière et il n'y a donc pas de DF.
 Remarque : Dans une relation, tout attribut est en DF avec la clé primaire.
Comment trouver les DF ?
 Une DF traduit une certaine perception de la réalité.

 Ainsi, la DF (MARQUE, TYPE) → PUISSANCE signifie qu’un type d’une marque
de voiture ne peut avoir qu’une seule puissance fiscale.
 La seule manière de déterminer une DF est donc de comprendre ce que

signifient les attributs et de trouver les contraintes qui les lient dans le monde
réel.
 C'est une propriété qui doit être extraite de la connaissance que l'on a de
l'application à modéliser.

Caractéristiques
 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é (table) dont la source est la clé et dont les
propriétés sont constituées par le but de la DF.
 Exemple: Soit l’entité : ETUDIANT (NumEtud, NomEtud, DatNais, CdSexe).

NumEtud → (NumEtud, NomEtud) est une DF simple.

Caractéristiques
 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 (tables) dont la source
est la clé et dont les propriétés sont constituées par le but de la DF.
 Exemple: Soit la relation : NOTE (NumEtud, NumMat, Note)

(NumEtud, NumMat) → Note est une DF composée.

Propriétés des DF
 Soient W, X, Y, Z et W des ensembles d'attributs non vides d'une relation

(entité) R. Voici quelques propriétés remarquables :
◼ Réflexivité : si Y ⊆ X alors X → Y
◼ Augmentation : si X → Y alors X ∪ Z → Y ∪ Z
◼ Transitivité : si X → Y et Y → Z alors X → Z
◼ Union : si X → Y et X → Z alors X → Y ∪ Z
◼ Pseudo-transitivité : si X → Y et Y ∪ W → Z alors X ∪ W → Z
◼ Décomposition : si X → Y et Z ⊆ Y alors X →Z

Types de DF
 DF élémentaire (DFE) :
 Une DF X → Y est dite élémentaire si :
◼ Y est un attribut unique non inclus dans X.
◼ il n’existe pas de X’ inclus dans X tel que X’ → Y (c à d: Y ne dépend pas
d’une partie de X).
 Exemple:
Soit l’entité Fournisseur suivante :
Cette entité comporte la DF élémentaire :
No_Four, No_Piece ➔ 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 No_Four ➔ Quantite.
 De la même façon, il n'existe pas de DF No_Piece➔ Quantite.
Types de DF
 DF élémentaire directe :
 X → Y est directe si elle est élémentaire et si 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:
◼ DF1 : No_Etudiant → No_Filère
◼ DF2: No_ Filère → Nom_ Filère
◼ DF3 : No_Etudiant → Nom_ Filère n’est pas directe
 DF triviale :
 Une DF X → Y est triviale si Y ⊆ X.
 DF canonique :
 Une DF X → Y est canonique si sa partie droite ne comporte qu’un seul
attribut.
DF et identifiants
 Un attribut ou une liste d’attributs X est une clé pour la relation R(X,Y,Z) si X → Y ∪ Z.
 X est une clé minimale si X → Y ∪ Z est élémentaire.

Graphe de DF
 Graphe de DF est une représentation graphiques des DF entre les attributs.

 Dans ce graphe :
◼ Les Noeuds représentent les attributs.
◼ Les Arcs représentent les DF.
 Exemple : soit la relation Voiture suivante :
GDF correspondant :

Graphe de DF : Démarche de construction
 Démarche de construction du GDF :
 Etablir la liste de toute les DF.

 Si un attribut reste isolé, alors il faut chercher des DF conduisant vers cet attribut et
dont la source est une composition de 2 ou plusieurs attributs.
 S’il existe 2 ou plusieurs attributs isolés et on ne trouve aucune DF de partie droite

composée, et si un lien sémantique regroupe ces attributs, dans tel cas il faut ajouter
une clé dont la valeur dépendre fonctionnellement les attributs isolés.
 On obtient alors une entité isolée.
 Le GDF obtenu doit ensuite être vérifié pour ne pas négliger certaines DF et ne pas
avoir des redondances de DF.
 Pour cela, il faut tout d’abord traiter les éventuels cycles existants en éliminant l’une
des DF.

Graphe de DF : Démarche de construction
 Exemple :

Graphe de DF
 Fermeture transitive (F+) :

 Soit F un ensemble de DF.
 La fermeture transitive de F, noté F+, est obtenue en ajoutant à F toutes les

DF transitives.
 Exemple :
Soit l’ensemble de DF :

Graphe de DF
 Couverture minimale (F*) : la couverture minimale d’un ensemble de DF est un sous

ensemble de DF élémentaires et directes.
 Soit F un ensemble de DF. On dira que F* est une couverture minimale de F ssi la F+
obtenue à partir de F, est égale à la F+ obtenue à partir F*.
 Une F* d’un ensemble F de DF est donc une représentation alternative, avec d’autres DF,
mais véhiculant une sémantique équivalente : au final, c’est exactement le même
ensemble de DF qui est implicite.
 En représentant tous les attributs et toutes les DF élémentaires directes entre eux, nous
obtenons un réseau appelé graphe de couverture minimale (GCM).
 Toutes les DF du graphe doivent partir d’un identifiant.

Traduction GCM vers un schéma EA
 A partir du GCM, le schéma EA normalisé correspondant apparaît naturellement, en

suivant les étapes suivantes:
 Recherche des identifiants : il faut repérer et souligner les identifiants.
 Recherche des entités : tous les attributs non identifiant qui dépendant directement
d’un identifiant et d’un seul, forment une entité avec l’identifiant.
 Recherche des associations :

◼ Une source de DF constituée d'au moins 2 identifiants donne une association entre
les entités correspondant aux identifiants (Dimension = nombre d'identifiants).
◼ Un identifiant but d'une DF donne une association entre l'identifiant source et
l'identifiant but de la DF
 Recherche des propriétés : enfin, les attributs (non identifiants) qui dépendent de
plusieurs identifiants sont les attributs d’une association supplémentaire dont les
cardinalités maximales sont toutes n.
Traduction GCM vers un schéma EA
 Exemple :

Normalisation par décomposition
Rappel : élaboration du MCD
 L'élaboration du MCD passe par la :

1. la mise en place de règles de gestion
2. l'élaboration du dictionnaire des données ;
3. La normalisation :
❑ Normalisation par décomposition
4. l'élaboration du MCD (entités puis associations puis cardinalités).

Normalisation
 L'objectif de la décomposition est de "casser" (diviser) une entité en entités plus
petites afin d'en éliminer les redondances.
 Exemple : dans l’entité « Achats » suivante, les informations concernant les
fournisseurs sont redondantes.
 Solution : décomposer l’entité « Achats » en deux autres entités:

Entité « Produit » Entité « Fournisseur »
parasol 15 jeune Karimi Kénitra
ombrelle 5 rouge
Normalisation
 Une entité R(A, B, C) est décomposable selon (A, B) et (A,C) s’il existe R1 et R2 telles que :
 R1=πA,B(R) (R1 est la projection sur les colonnes A et B)
 R2= πA,C (R) (R2 est la projection sur les colonnes A et C) R
 R=R1*R2 (il est possible de reconstruire R par des opérations
relationnelles de jointure sur R1 et R2)
R1 R2
 La décomposition en sous-entités doit vérifier deux critères fondamentaux :

◼ 1. être sans perte d’information
◼ 2. préserve les DF.

Normalisation
 1. Décomposition sans perte d’information :

 Une décomposition est sans perte d’information si la jointure naturelle
(concaténation) des 2 relations donne exactement toutes les occurrences de la
relation initiale.
 Exemple :
Soit la relation Etudiant :
avec les DF :
Etudiant est décomposée en 2 relations :

Normalisation
 1. Décomposition avec préservation des DF :

 Une décomposition d'une relation R en relations R1, R2,…Rn, préserve les DF si la F+
des DF de R est la même que la F+ de l'union des DF de R1, R2,…Rn.
 F+= Fermeture transitive = DF élémentaires de R + DF élémentaires obtenues par
transitivité.
 Exemple : Fermeture transitive :
◼ Soit T(A, B, C, D, E), avec les DF :
◼ F = { E → A, E → B, E → C, C → D},
◼ F+ = F ∪ { E → D }.
R
 Exemple : Décomposition sans préservation des DF :

◼ Soit la relation R(A,B,C,D) avec les DF : A→ B,C ; C→ D ; D→ B.
◼ La décomposition de la relation R(A,B,C,D) en R1(A, B, C) et R2(A,D) est sans perte
d’information mais avec perte de la DF (D → B).
(D → B) ne peut pas se retrouver sur l’union des DF de R1 et R2.
Formes normales
Formes normales
Introduction
 Les formes normales (théorèmes de CODD) sont des propriétés que doivent vérifier les
schémas de bases de données pour éviter la redondance et les anomalies.
 Ces formes normales s’appuient sur la décomposition des schémas relationnels, tout en
préservant les DF et sans perdre d'informations.
 On peut recenser les 6 formes normales suivantes : 1FN, 2FN, 3FN, FNBC, 4FN, 5FN
 La 3ème FN est généralement reconnue comme la plus importante à respecter.
 La BCNF est la plus simple à établir.

Formes normales
Introduction
 Il existe une hiérarchie dans les 4 règles de normalisation :

◼ une relation en 2ème FN est forcément en 1ère FN
◼ une relation en FN de Boyce-Codd est forcément en 3ème FN
◼ etc.
Entités non normalisées
1ère FN ☺ décomposition du schéma relationnel
2ème FN sans perte d’information
☺ normalisation souvent suffisante
3ème FN
☺ détection de plus d’incohérence
FN de Boyce-Codd (FNBC)  décomposition avec perte possible
d’information de dépendance

Formes normales (FN)
1ère FN (1FN)
 Une entité est en 1FN si, et seulement si,

1. elle possède une clé (qui identifie formellement chaque occurrence)
2. chaque attribut dépend fonctionnellement de la clé
3. 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 l’entité ELEVES en :
◼ ELEVES (no-elv, nom, prenom)
◼ NOTES (no-elv, no-matiere, note)

Formes normales
2ème 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é;
 Conséquence : toutes les entités qui n'ont qu'un seul attribut clé, sont en 2FN si elles
sont en 1FN.
 Solution : décomposition de la relation en deux relations;
 Exemple: une entité en 1FN qui n'est pas en 2FN :
COMMANDES (date, no-cli, no-prod, quantité, prixUHT)
 elle n'est pas en 2FN car la clé est : (date, no-cli, no-prod), et le prixUHT ne dépend
que de no-prod.
 Décomposition
▪ COMMANDES (date, no-cli, no-pro, quantité)
▪ PRODUITS (no-pro, nom_prod, prixUHT)
Formes normales
3ème FN (3FN)
 Une entité est en 3FN si :

1. la relation est en 2FN;
2. tout attribut qui n’appartient pas à la clé ne dépend pas d’un autre attribut non clé
(aucun attribut ne doit dépendre de la clé par transitivité).
 objectif : rechercher la redondance d’information dans une relation;
 solution : décomposition de la relation en deux relations;
 Exemple : une relation en 2FN qui n'est pas en 3FN :

CLIENTS (code_client, nom_client, code_categ, nom_categ)
Cette relation n‘est pas en 3FN car la DF code_client →nom_categ n‘est pas directe du fait
de la transitivité code_client → code_categ → nom_categ
 Décomposition :
▪ CLIENTS (code_client, nom_client)
▪ CATEGORIES (code_categ, nom_categ)

Formes normales
Remarque
 Il existe d‘autres formes normales mais on admet couramment que ces 3 premières
formes normales sont suffisantes pour permettre de construire des modèles fiables et
cohérents.
 Parmi ces formes normales , la forme normale de BOYCE-CODD (FNBC).

X → Y est dite élémentaire si :
Formes normales •Y est un attribut unique non inclus dans X
•Y ne dépend pas d’une partie de X
FN de BOYCE-CODD (FNBC)
 Une entité est en FNBC ssi les seules DF élémentaires sont celles dans lesquelles une clé
détermine un attribut non-clé.
 ➔tout attribut qui n'appartient pas à une clé n'est pas source d'une DF vers une partie
d'une clé,
 La FNBC impose que toutes les parties gauches des DF sont des clés.
 Exemple : une entité en 3FN qui n'est pas FNBC :

Ville, Rue→ CodePostal
l’entité ADRESSE (Ville, Rue, CodePostal) avec les DF suivantes : CodePostal →Ville
 Cette relation n’est pas en BCNF car l’attribut ‘’Ville’’ (qui fait partie de la clé) dépend
fonctionnellement de CodePostal (qui est un attribut non membre de la clé).
 Décomposition :
◼ CODES_Ville(CodePostal, Ville)
◼ CODES_Rues(CodePostal, Rue)
 NB: Une décomposition en BCNF ne préserve pas toujours les DF.

Pr.
 A. El Mhouti 82 FSTH
Modèle Relationnel
(MLD : Modèle Logique de Données)

Modèle relationnel
Rappel
 Externe : sous-schéma conceptuels

 Conceptuel : représentations graphiques partiellement formelles. Formalismes
utilisés : modèle EA (MCD), UML, …
 Logique : décrire la structure d'une BD au moyen d'un langage formel. Exemples
de formalismes utilisés : Relationnel (MLD), Objet, Relationnel-Objet, …
 Physique : Implémentation à l’aide d’un SGBD : MySQL, Oracle, PostgreSQL, ….
La modélisation logique des BD relationnelle est faite avec le Modèle Logique De

Données (MLD) relationnel .
Modèle relationnel
Rappel
 Après avoir conçu le MCD, l’étape suivante est de le transposer en MLD.

 Le MLD est en fait le dernier pas vers le MPD implanté à l’aide d’un SGBD.
MCD MLD MPD

Modèle relationnel
Présentation
 Le modèle relationnel est proposé par le mathématicien Ted Codd en 1970.
 Ce modèle s’inspire du concept mathématique de relation. Il est fondé sur :
◼ la logique mathématique;
◼ la théorie mathématique des ensembles;
◼ la notion de base qui lui est rattachée : la relation représentée comme un tableau.
 Objectif : création d’un Modèle Logique de Données Relationnel (MLD Relationnel).

Principaux concepts

Principaux concepts
Domaine
 Le domaine Di d’un attribut est un type de données, il est définit par l’ensemble de ses
valeurs admissibles.
 Exemples :
◼ nom : chaîne de caractères de longueur 30.
◼ num : entiers compris entre 1 et 10000.
◼ couleurs :{″blanc″, ″bleu″, ″vert″, ″jaune″, ″rouge″ }
◼ age : entiers compris entre 1 et 100.
◼ date : [01 :31] / [01 :12] / [1920 :2011]

Principaux concepts
Relation
 Une relation est un sous ensemble du produit cartésien de n domaines

d’attributs.
 Une relation est représentée sous la forme d’une table dans lequel les n
attributs sont les titres des n colonnes.
 Exemple :
Relation « Eleve »
Entité « Eleve »
 Un élément appartenant à une telle relation sera appelé n-uplet ou tuple ou

occurrence.
Principaux concepts
Schéma de relation
 Un schéma de relation est le nom de la relation suivi de la liste des attributs avec leurs
domaines (types).
 Exemple :
 Entité :
 Relation sous forme tabulaire :
 Schéma de relation :
Eleve (N°: Entier ; Nom: chaine; Prenom: chaine; Age:[0, 20]; Sexe: {M,F})
Principaux concepts
Clé primaire
 Une clé primaire est un ensemble d’attributs K vérifiant :

◼ Unicité : les valeurs des clés primaires permettent d’identifier un tuple.
◼ Minimalité : comportant un minimum d’attributs.
 Les autres étant appelés clés candidates.
 Exemple : Soit la relation Voiture suivante :
La clé primaire est N_Immat.

 Remarques :
 Dans le schéma d’une relation, on souligne la clé primaire.
 Si une entité est identifiable par plusieurs identifiants, l’un d’eux est choisi comme clé primaire.

Principaux concepts
Clé étrangère
 La clé étrangère d’une relation est un attribut (ou groupe d’attributs) qui apparaît
comme clé primaire dans une autre relation référencée.
 Exemple :
 NumCli est une clé étrangère de la relation Commande (apparaît comme clé
primaire dans la relation Client).
Référence une clé primaire
Client Commande
Ainsi :
 le client numéro 3 (Nicolas Jacques) a passé une commande de trois tubes de colle.
 le client numéro 2 (Marie Malherbe) a passé 2 commandes (papier et ciseaux).

Principaux concepts
Schéma relationnel
 Le schéma relationnel est constitué par l’ensemble des schémas des relations avec les
clés primaires, les clés étrangères et éventuellement d’autres contraintes d’intégrité.
 Exemple de schéma relationnel :

 Etudiant(Numéro étudiant : entier, Nom: chaine, Age : entier ).
 Module(Numéro module : entier, Intitulé : chaine, Volume horaire : entier, Semestre : enier).
 Inscription(#Numéro étudiant : entier, #Numéro module : entier, Date inscription : date).
 Enseignant(Numéro enseignent: entier, Nom: chaine, Statut: chaine, Tel: entier, Compte:
entier).
 Cours(Nom cours : chaine, #Numéro enseignant : entier, Salle : entier).

Intégrité référentielle

Définition
 Les clés étrangères ont pour fonction principale la vérification de l'intégrité référentielle
de la BD.
 Le mécanisme d'intégrité référentielle impose que chaque valeur d'une clé
étrangère existe comme valeur de la clé primaire dans la table référencée.
 Exemple :
Soit les deux tables ETUDIANT et PROMOTION :
Dans cette BD :
➢ aucune valeur de la clé primaire _Promo ne
viole l'intégrité référentielle.
➢ Mais l’ajout d’un étudiant "0005, Ali, MIP"
serait rejetée car la clé primaire de la table
PROMOTION ne contient pas la valeur «
MIP ».

Caractéristiques
 Que se passe-t-il si l'on supprime ou si l'on modifie une valeur de la clé primaire dont
dépendent d'autres valeurs dans une clé étrangère ?
 Plusieurs stratégies sont possibles :
➢ la suppression (mise à jour) interdite : l'opération est

tout simplement refusée.
➢ Exemple :
o La suppression de la ligne "MEEA, Maîtrise EEA" est
impossible car des tuples d'ETUDIANT y font
référence.

Caractéristiques
➢ la suppression (ou la mise à jour) en cascade :

o si un tuple de la table référencée est supprimé
(modifié), tous les tuples dépendants sont
supprimés (modifiés).
 Exemples:
 la suppression du tuple "MEEA, Maîtrise EEA"
entraîne celle des étudiants portant les numéros
0001 et 0003 ;
 le changement de clé "MEEA" en "MIP" affecte de la
même façon les valeurs de la clé étrangère pour ces
étudiants.

Caractéristiques
➢ la suppression avec initialisation : toutes les clés étrangères égales à la clé primaire
supprimée sont mises à la valeur nulle.
➢ Exemple :
La suppression du tuple "MEEA, Maîtrise EEA" entraîne la mise à NULL de l'attribut _Promo
des étudiants portant les numéros 0001 et 0003.

Règles de passage du MCD au MLD

Passage du modèle EA au modèle relationnel
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 BD.
 Chaque propriété de l'entité devient un attribut de cette relation, et donc une colonne
de la table correspondante.
 L'identifiant de l'entité devient la Clé Primaire de la relation (elle est donc soulignée).

Règle 2: Association de type simple-complexe : (X,1) - (X,n), X= {0 ou 1}
 La Clé Primaire de la table qui se situe du côté "complexe" devient une Clé
Etrangère dans la table qui se situe du côté "simple" ,
 Une association de type simple-complexe disparait.
 Si l’association est porteuse de propriétés, elles migrent également.
 Exemple :
 → MLD :
◼ Client (Nclient, Société, Contact, Fonction, Ville)
◼ Commande (NCommande, DateCommande, #Nclient)

Règle 3 : Association de type simple-simple
 Une association de type simple-simple (par exemple, (1,1)-(0,1)) se traite de la même

façon, en choisissant en principe d'introduire la clé étrangère dans la table située du
côté (1,1) de l'association.
 Exemple:
 → MLD:
◼ Animateur (idAnimateur, NomAnimateur)
◼ Groupe (idGroupe, NomGroupe, #idAnimateur)

Règle 4 : Association de type complexe-complexe (X,n) - (X,n), X= {0 ou 1}
 Une association de type complexe-complexe se transforme en une table ayant

comme Clé Primaire une clé composée des identifiants des 2 entités.
 Si l’association est porteuse de propriétés, celles ci deviennent des attributs pour la
nouvelle table.
 Exemple :
 → MLD :
◼ Commande (NCommande, DateCommande)
◼ Produit (Nproduit, NomProduit)
◼ DétailCom (NCommande, Nproduit, quantité, PrixUnitaire)

Règle 5 : Association n-aire (quelles que soient les cardinalités)
 Une association de dimension supérieure à 2 se réécrit selon la règle 4 : Il y a création

d'une table supplémentaire ayant comme Clé Primaire la concaténation des identifiants
des entités participant à la relation.
 Si la relation est porteuse de donnée, celles ci deviennent des attributs pour la nouvelle
table.
 Exemple :
→ MLD :
Etudiant (NEtudiant, NomEtudiant)
Niveau (NumNiv, NomNiv)
Langue (NLangue, NomLangue)
Parle (NEtudiant, NumNiv, NLangue)

Association Réflexive
 Premier cas : cardinalité (X,1) - (X,n), avec X={0 ou 1} :

 La Clé Primaire de l'entité se dédouble et devient une Clé Etrangère dans la nouvelle
table.
 Exactement comme si l'entité se dédoublait et était reliée par une relation binaire
(X,1) - (X,n) (règle 2).
 Cela nécessite de renommer les attributs afin d’éviter les noms identiques.
 Exemple : une société est organisée de manière hiérarchique :
◼ 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.
◼ → MLD:
◼ Employé (idEmploye, NomEmploye, #idSup)
◼ idSup correspond à l'identifiant (idEmploye) du supérieur hiérarchique direct de
l'employé considéré.
Association Réflexive
 Deuxième cas : cardinalité (X,n) - (X,n), avec X={0 ou 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) (règle 3).
 Il y a donc création d'une nouvelle table dont la clé primaire est composée des deux
attributs clés étrangères, référant respectivement à la clé primaire de la table.
 Ces attributs sont suffixés (ou renommés) par chacun des rôles correspondants.
 Exemple :
◼ Une personne a 0 ou n frères, et il est aussi frère de 0 ou n personnes.
 → MLD :
◼ PIECE(codePiece ,libellePiece)
◼ COMPOSITION (#pieceComposee , #pieceComposante)

Modèle Physique de Données (MPD) et SGBD
MySQL

Modèle Physique de Données (MPD)
Présentation
 Un modèle physique de données est l'implémentation particulière du modèle

logique de données par un logiciel.
 Le MPD précise notamment le stockage de chaque donnée à travers son type et
sa taille
 La traduction d'un MLD (relationnel) en un MPD consiste en la création d'une
base de données hébergée par un SGBD relationnel (Oracle, SQL Server, Access,
MySQL, …).

Comment créer un MPD
 Dans un MPD, on crée les tables (nom dans l’en-tête), on répertorie l’ensemble
des champs qu’elles contiennent (souligner les clés primaires et mettre un “#”
devant les clés étrangères).
 Pour les clés étrangères ce n’est pas tout, il faut montrer, à l’aide d’une flèche
vers quel champ fait référence la clé étrangère.
 Exemple :
MCD
MLD
MPD

Implémenter la base de données dans le SGBD MySQL
 MySQL est un SGBD relationnel (https://www.mysql.com).

 MySQL est un logiciel assurant la structuration, le stockage, la maintenance, la
mise à jour, la recherche, la confidentialité et le contrôle de l’intégrité des
données dans une base de données.
 MySQL permet la création de la base de données en utilisation une interface
graphique ou en utilisant le langage SQL.

M44 - Chapitre-2 - BD Relationnelles Et SGBD MySQL

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

M44 - Chapitre-2 - BD Relationnelles Et SGBD MySQL

Transféré par

Droits d'auteur :

Formats disponibles

Université Abdelmalek Essaâdi

Faculté des Sciences et Techniques d’Al-Hoceima

Cours du Module M44 : « Bases de données avancées »

Chapitre 2 : BD relationnelles et SGBD MySQL

Pr. A. El Mhouti FSTH

 Modèle Entité-Association (modèle EA ou MCD)

 Normalisation du modèle EA (ou MCD)

 Modèle relationnel ( ou MLD)

Pr. A. El Mhouti 2 FSTH

 Externe : sous-schéma conceptuels

La modélisation conceptuelle des BD relationnelle est faite avec le formalisme EA

 Au niveau conceptuel, il s'agit de l'élaboration du Modèle Conceptuel des

 L'élaboration du MCD passe par la :

 l'élaboration du dictionnaire des données ;

 la recherche des dépendances fonctionnelles entre ces données ;

Pr. A. El Mhouti 4 FSTH

Pr. A. El Mhouti 5 FSTH

 Le modèle EA est un modèle conceptuel conçu par Chen en 1976.

 Le but de ce modèle est de permettre la description conceptuelle des données

 Les concepts de base qui correspondent aux concepts d’abstraction de la réalité

Pr. A. El Mhouti 6 FSTH

Pr. A. El Mhouti 7 FSTH

entre plusieurs entités (qui jouent un rôle déterminé).

complexe et difficile à gérer.

Conduire est une association entre un Conducteur et une Voiture.

 Rôles d’une association :

Pr. A. El Mhouti 9 FSTH

 Dimension d’une association :

◼ Association n-aires : reliant plusieurs entités (avec n > 2)

◼ Association cyclique (réflexive) : qui associe les occurrences d’une

◼ Association plurielle : deux mêmes entités peuvent être plusieurs fois

 Association cyclique (réflexive) :

 Remarque : pour faciliter la lecture, on doit spécifier le rôle de chaque entité.

Pr. A. El Mhouti 11 FSTH

 Exemple 2: Association ternaire cyclique :

Pr. A. El Mhouti 12 FSTH

Pr. A. El Mhouti 13 FSTH

Pr. A. El Mhouti 14 FSTH

 Une propriété peut être :

 Obligatoire : une valeur au moins par occurrence.

 Facultative : peut ne pas prendre de valeur.

 monovaluée : une seule valeur par occurrence.

Pr. A. El Mhouti 16 FSTH

Pr. A. El Mhouti 17 FSTH

 Un identifiant peut être :

 Dans cet entité, deux identifiants possible :

L’identifiant de l’association commande est : N°commande

 2ème possibilité : identifiant construit des identifiants des entités liées :

L’identifiant de l’association Inscrit est : Etudiant.N°carte + Cours.N°cours

 4ème possibilité : Tout rôle mono-valué induit un identifiant de l’association

l’identifiant de l’association Assure est :

Pr. A. El Mhouti 20 FSTH

 La cardinalité d'une association indique le nombre d'occurrences (minimales et

 Les valeurs possibles d'une cardinalité minimale sont 0 ou 1.

Pr. A. El Mhouti 21 FSTH

 → un client peut commander 1 ou plusieurs Articles

Pr. A. El Mhouti 22 FSTH

 Dans la pratique on gère les cardinalités suivantes :

 1,1 : Chaque occurrence de l’entité est relié exactement à une occurrence de

 0,N : Chaque occurrence de l’entité est relié à un nombre quelconque d’occurrence

 1,N : Chaque occurrence de l’entité est relié à au moins une occurrence de

Pr. A. El Mhouti 23 FSTH

Pr. A. El Mhouti 24 FSTH