Modèle et outils de Base de

données

Master 1 RIM
IST
Enseignant : Dr Pengwendé ZONGO
 Plan
I. Généralité
II. Conception (MCD, MLD)
III. Modèle relationnel et algèbre
relationnelle (rap

2
I - Généralités

La compétitivité ou la réussite d'une entreprise

sont déterminées par plusieurs éléments.
On peut généralement regrouper ces éléments
en deux classes.
• Matériel (infrastructure, supports
financiers,…)
• Intellectuel (compétence et motivation des
employés, recueil et l'exploitation optimale
des informations utiles.
3
I - Généralités

Le développement rapide des TIC a donné aux

entreprises la possibilité d'utiliser des moyens
avancés et puissants pour gérer et exploiter de
très grands volumes de données.
La gestion informatique des données n’est plus
réservé uniquement aux informaticiens. Tous les
employés sont de plus en plus impliqués dans
les différents procédés liés à la gestion et
l'exploitation des données.

4
I - Généralités

D’où, un certain niveau de connaissance des

principes et des outils standard de
l'informatique requis pour la plupart des postes
disponibles dans les entreprises de nos jours.

5
I - Généralités

Définition de l'information
Une information est un élément qui permet de
compléter notre connaissance sur une
personne, un objet, un événement etc.
Exemple:
nom d'une personne (une information
concernant cette personne) ;
couleur d'une voiture.
6
I - Généralités

b- Définition du système d’information (SI)

Un système d'information est constitué par
l'ensemble des informations relatives à un domaine
bien défini.
Toutes les informations relatives à la gestion d'une
librairie constituent le système d'information de
cette librairie. Ce système peut couvrir le simple
stockage des livres, mais également la gestion des
commandes, des ventes et même des clients.
7
I - Généralités

b- Définition du système d’information

Un système d'information peut ne pas être
nécessairement informatisé. Bien que la plupart des
systèmes actuels se basent sur la technologie de
l'informatique.
Il existe encore des systèmes d'information où
l'information est stockée, manipulée et
communiquée à l'aide de moyens "traditionnels"
tels que armoires, classeurs, fiches sur papier, etc.
8
I - Généralités

c- Données, traitements et informations

Les deux termes "informations" et "données"
sont souvent utilisés comme synonymes, il
existe une différence entre eux.
Exemple: Dans une pharmacie, un client
demande au vendeur si le produit anti-palu
« Maloxine » est disponible en stock.

9
I - Généralités

c- Données, traitements et informations

Le vendeur consulte la base de données de la
pharmacie et confirme au client que le produit est
disponible. Il a donc donné au client l'information
que le produit est en stock. Afin de pouvoir donner
cette information, le vendeur a dû consulter les
données qui représentent le stock de la pharmacie.
Le fait de consulter le stock constitue un traitement
sur les données du stock.

10
I - Généralités

c- Données, traitements et informations

Un système d'information contient les données
et les traitements nécessaires pour assimiler et
stocker les informations entrantes et produire
les informations sortantes.
Dans le SI nous retrouvons généralement les
traitements suivants: Consultation des données,
Ajout de données, Suppression de données,
Modification de données.

11
I - Généralités
Utilisation des BD dans le quotidien
Utilisation implicite des BD:
• Regarder vos sms, email, compte bancaire
• Commander un article sur le web,
• Consulter le météo,
• …

12
I - Généralités
Pourquoi a-ton besoin d’utiliser une BD dans
nos SI?
Caractéristique d’une BD :
• Stocker une quantité importante
d’information (Téra octets)
• Stocker de manière organisée (structurée)
• Multi-utilisateur (dizaine de milliers)
• Temps de réponse (presque immédiate)

13
I - Généralités
Pourquoi a-ton besoin d’utiliser une BD dans nos
SI?
Le SGBD propose des interfaces de manipulation de
gestion et d’interrogation assez simple.
Des langages de haut niveau (Langage déclaratif)
Le SGBD stocke les BD sans limite de temps:
– Durabilité (panne de disques, panne électrique)
Accès sécurisé des données.
– Bien gérer en fonction des profils utilisateurs.
– Garantir que les valeurs sont correctes(salaires)
Pour toutes ses raisons on utilise les BD dans les SI
14
I - Généralités
Contexte technique
• Mémoire :
– accès rapide, mais volatif,
– petit volume de données)
• Fichier (stockage persistant sur disque, Gros
volume de données)
– Accès via des langage de programmation,
– dépendance des programmes avec la structure
des données)
– Contexte mono-utilisateur
– Pb de sécurité 15
I - Généralités
Contexte technique
• Bases de données
– Stockage persistant sur disque
– Très gros volume(Téra octets)
– Langage de requêtes de haut niveau (facile)
– Contexte multi-utilisateurs

Comment c’est fait ?

16
I - Généralités
Architecture ANSI/SPARC
• Cette architecture donne aux SGBD leur
fonctionnalités décrites précédemment.
• Proposé par Charles Bachman en 1965.(Turing
Award 1973)
• Mise en œuvre dans tous les SGBD.

17
I - Généralités
Architecture ANSI/SPARC
Organisée en 3 niveaux d’abstractions:

Comment les
donnée sont vues
par les utilisateurs

18
I - Généralités
Architecture ANSI/SPARC
Avantages:
• Indépendance physique (entre structure de
stockage et structure logique)
– Exemple: ajout d’index
• Indépendance logique (modifier le schéma
conceptuel sans modifier les programme
d’applications)
– Exemple ajout d’attribut

19
I - Généralités
Modélisation des données
Définition.
Un modèle de données est un ensemble :
1. de concepts pour décrire
– Les données du monde réel
– Les liens entre les données
– La sémantique des données
2. d’opération pour manipuler les données.

20
21
Modélisation des données
Modèle de conception :
• Entité-Association
• Diagramme de classe UML(Unified Modeling
Language )
Modèle d’implantation :
• Hiérarchique/réseau
• Relationnel
• Objet
• Relationnel- Objet
Modèle physique
• Mysql, PostgreSQL, Oracle, …
• Codasyl,…
22
I - Généralités

Modélisation des données

La démarche classique d'un projet informatique
comprend les étapes suivantes:
1. analyse de la situation existante et des besoins;
2. création d'une série de modèles, qui permettent
de représenter tous les aspects importants à
partir des modèles,
3. implémentation d'une base de données (sa mise
en œuvre sur ordinateur).

23
d-Méthode de modélisation des données

24
I - Généralités

Modélisation des données

Analyse des besoins;
La première étape consiste, a utiliser nos
connaissances de gestion d'une entreprise,
notre esprit ouvert pour analyser correctement
la situation existante et les besoins des
utilisateurs en partant d’une idée du client du
monde réel.

25
I - Généralités

Modélisation des données

Analyse des besoins;
Le résultat de l'analyse est généralement un
document appelé recueils des besoins et
l’analyse, qui contiennent les indications
principales sur le fonctionnement désiré du
système informatisé.
Base d’un contrat : entre le concepteur et le
client
26
I - Généralités
Avantage des BD
En résumé:
• Intégration (description unique et global des
données) ce qui évite
– redondances et
– incohérences
• Indépendance logique et physique
• Sécurité :
– Contrôle sémantique des données ,
– protection contre les accès non autorisées,
– protection contre les pannes.

27
I - Généralités
Avantage des BD
En résumé:
• Facilités pour l’utilisateur
– Partage des données facile
– Vision de haut niveau personnalisée des données
– Manipulation facile des données(SQL)
– ….

28
I - Généralités
Inconvénients des BD
Coût:
• Licences (très élevées)
• Ressources humaines (qui maitrisent les BD).

29
I - Généralités
Terminologie
Une Donnée a :
• une structure (exemple, chaine, tableau, ….)
• une sémantique est associée aux donnée.
(interprété l’information, donner un sens aux
données;
• un propriétaire qui crée , définit les règles et
donne les droits aux autres utilisateurs;
• Des utilisateurs.
30
I - Généralités
Terminologie
BD (Base de données)
Collection de données décrites selon un certain
modèle (par exemple relationnel, objet)
SGBD (Système de Gestion des Bases de
données)
Système logiciel gérant les données d’une BD,
selon le modèle fixé.

31
I - Généralités
Terminologie
Un SGBD doit permettre
• La définition
• La manipulation des données
• Le contrôle

32
I - Généralités
Terminologie
• Schéma (intention)
– Structure des données de la base
(selon un modèle)
– Statique
• Instance (extension)
– Collection des données de la base (écrite selon un
modèle)
– Dynamique
33
I - Généralités
Terminologie
• Contrainte d’intégrité
– Règle spécifiée sur les données pour définit un
état cohérent (Exemple le salaire > SMiC)
• Métabase (Dictionnaire de Données)
– Collection des données qui décrivent la BD.

34
I - Généralités
Acteurs

35
I - Généralités
Acteurs : Oracle, DB2 (IBM), SQL serveur
(Microsoft)

Partage du marché SGBD

• SGBD rélationnel = 80% du marché (24
Milliards en 2011)
• Oracle (50%) + DB2 + SQL serveur = 85%
SGBD libre
• (Mysql, PostgreSQL)
36
I - Généralités
Acteurs : Oracle, DB2 (IBM), SQL serveur
(Micrsoft)
Partage du marché

Sybase
5% Autres
10%

Microsoft Oracle
17% 48%

IBM
20%

37
38
II – Conception
Introduction
1. Schémas normalisés
Un schéma normalisé présente des
caractéristiques formelles et des règles qui nous
indiquent plus précisément les liens qui
caractérisent les données.
La normalisation nous garantit l’absence de
défaut (notamment de redondance) tout en
préservant l’intégralité de l’information
représentée.
39
II – Conception
Introduction
1. Schémas normalisés
L’objectif de la normalisation est de construire
un schéma de base de données cohérent.
Un modèle relationnel normalisé doit respecter
certaines contraintes appelées formes
normales.
Les formes normales se basent sur les
dépendances fonctionnelles entre attributs.
40
II – Conception
Introduction
2. Dépendances fonctionnelles
Définition
Soit R une relation, A et S des attributs de R.
On dit que A dépend fonctionnellement de S,
(notée 𝑆 → 𝐴) Si une valeur de l’attribut de S
induit une unique valeur de A. Autrement dit
Si t1[S]=t2[S] alors t1[A] = t2[A]
Si je connais S alors je connais A
41
II – Conception
Introduction
2. Dépendances fonctionnelles
Exemple
Etudiant(num,nom,adresse,age)
num -> nom : est une dépendance
fonctionnelle.
nom -> num n’est pas une dépendance
fonctionnelle.

42
 II- Conception
2. Dépendances fonctionnelles : rappel des axiomes
d’Armstrong
Soient X, Y, W et Z des ensembles d’attributs
• Réflexivité : X -> X
• Augmentation : X ->Y, => XZ -> YZ
• Transitivité : X -> Y et Y -> Z, => X -> Z
• Pseudo-transitivité : X -> Y et WY -> Z, => WX -> Z
• Union : X -> Y et X -> Z, => X -> YZ
• Décomposition : X -> YZ, => X -> Y et X -> Z

43
 II- Conception
Exercice
Considérons la relation suivante R(A, B, C, D, E, G, H) et
F l’ensemble des dépendances fonctionnelles de R,
F = {AB -> C; B -> D; CD -> E; CE -> GH; G -> A}. En
utilisant les axiomes d’Armstrong, montrer que l’on peut
déduire de F les dépendances fonctionnelles suivantes :
i. AB -> E;
ii. BG -> C;
iii. AB -> G

44
II – Conception
Introduction
2. Dépendances fonctionnelles
Transitivité
S->A et A-> T alors S -> T
Exemple
numCommande -> NumClient -> NomClient
On a alors NumCommande -> nomClient.

45
II – Conception
Introduction
2. Dépendances fonctionnelles
Définition
Une clé (d’une relation R) est un sous-ensemble
minimal C des attributs tel que tout attribut de R
dépend fonctionnellement de C.

46
II – Conception
Introduction
3. Normalisation
Première forme normale (1FN)
Une rélation est en 1FN si tous ses attributs sont
atomiques (mono-valués c’est-à-dire une valeur
par ligne). Aucun attribut n’est décomposable en
plusieurs attributs.
Elle possède une clé identifiant de manière
unique chaque tuple.
47
II – Conception
Introduction
3. Normalisation
Première forme normale (1FN)
Employe(nom, diplôme)

48
II – Conception
3. Normalisation
Deuxième forme normale (2FN)
Une relation est en 2 FN si et seulement si:
• Elle est 1FN
• Tout attribut n’appartenant pas à la clé
primaire est en dépendance totale avec la clé
primaire (Cas de clé primaire composée de
plusieurs attributs)

49
II – Conception
3. Normalisation
Deuxième forme normale (2FN)
Exemple
Commande(numCde, refProd, designProd,
Quantité)
1FN = OK,
2FN = NON, car refProd designProd , pas
besoin de connaitre numCde.
Commande(numCde,RefProd,Quantité)
Produit(refProd, designProd)
50
II – Conception
3. Normalisation
Deuxième forme normale (2FN)
• Séparation des attributs concernés par la
dépendance dans une autre relation.

• Une relation en 1 NF dont la clé est mono-

attribut est une 2 NF.

51
II – Conception
3. Normalisation
Deuxième forme normale (2FN)
Exemple
Enseignement(num, codeMat, nomEnseignant,
volumeHoraire).
Avec num NomEnseignant

Enseignement(num, codeMat, volumeHoraire).

Enseignant(num,nomEnseignant)
52
II – Conception
3. Normalisation
Troisième forme normale (3FN)
Une relation est en 3° forme normale si et
seulement si
• Elle est en 2FN,
• Elle ne contient pas de dépendance
fonctionnelle entre attributs non clé primaire.

53
II – Conception
3. Normalisation
Troisième forme normale (3FN)
Exemple
Enseignant(num, nom, catégorie, classe, salaire)
Catégorie, classe -> salaire;

• Isoler la DF transitive dans une nouvelle relation

Enseignant(num,nom,categorie,classe)
Salaire(categorie,classe,salaire).
54
II – Conception
Le Modèle Entité/Association
Proposé par Chen en 1976
• Simple
• Graphique
• Facilite le dialogue avec
les utilisateurs (concepteurs <->clients)
• Utilisé dans la plupart des méthodes de
Conception.

55
II – Conception
A - Le Modèle Conceptuel des Données (MCD)
Le modèle Entité/Association (E/A) propose
essentiellement une notation pour soutenir la
démarche de conception de schéma présentée
précédemment.
La notation E/A a pour caractéristiques d’être
simple et suffisamment pour modéliser des
structures relationnelles. De plus, elle repose sur
une représentation graphique qui facilite
considérablement sa compréhension.
Un inconvénient du modèle E/A est de mener à
certaines ambiguïtés pour des schémas complexes. 56
II – Conception
A - Le Modèle Conceptuel des Données (MCD)
• Le modèle conceptuel des données (MCD) a
pour but de représenter de façon structurée
les données qui seront utilisées par le SI.
• Le modèle conceptuel des données décrit la
sémantique c’est à dire le sens attaché à ces
données et à leurs rapports (non à l’utilisation
qui peut en être faite.)

57
II – Conception
A - Le Modèle Conceptuel des Données (MCD)
• On établit le MCD après avoir recensé et
donné un nom à l’ensemble des données du
domaine étudié.
• Ensuite on étudie les relations existantes entre
ces données, pour aboutir au MCD.

58
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
Le développement du MCD se fait par itérations
Quand on a stabilisé le MCD et qu’on a fait le
choix du SGBD pour le développement du SI, on
peut alors passer au MLD.
Dans ce cours nous nous intéressons à un
formalisme de modélisation conceptuelle des
données appelé Modèle Entité Association.

59
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
Il existe 4 concepts de base dans le formalisme
entité-association.
a) Entité
b) Association
c) Propriété ou attribut
d) Cardinalité.

60
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
a-Entité
Un objet concret ou abstrait du monde réel pour
lequel nous voulons conserver de l’information
(objet pertinent dans le contexte du SI étudié).
Une entité peut être:
• Une personne (employé, étudiant, client,…)
• Un endroit (bureau, ville, territoire, pays,…)
• Un événement (commande, livraison, …)
• Etc.
61
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
a-Entité
Les entités d’un MCD dépendent de l’application
pour laquelle le SI est développé.
Une entité représente un ensemble d’objets
ayant les mêmes caractéristiques et non pas une
occurrence de ces objets.
Exemple:
Entité ETUDIANT,
Occurrence: Michel Paré
62
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
a-Entité
Une entité est nommée en utilisant un nom.
Une entité est représentée de la façon suivante.

NomEntité

63
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
b-Association entre les entités
Une association représente une relation
générique qui existe entre deux (ou plusieurs)
entités.
Il est courant de nommer les associations en
utilisant des verbes.

64
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
b-Association entre les entités
Exemple : Un CLIENT passe une COMMANDE,
Une COMMANDE contient des PRODUITS.

65
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
c-Propriétés ou attributs d’une entité
• Une propriété est donnée élémentaire
utilisée pour décrire une entité ou une
association.
• Un attribut recevra une valeur précise pour
chaque occurrence de l’entité ou de
l’association.
• Une ou plusieurs propriétés peuvent jouer le
rôle d’identifiant de l’entité (cela deviendra la
clé d’une table au niveau MLD) 66
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
c-Propriétés d’une entité
L’identifiant d’une entité est une propriété ou un
ensemble de propriétés qui permettent de repérer
une occurrence de l’entité de façon unique.

! Toute entité doit être caractérisée par un

identifiant unique
67
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
Etude des associations
• Une association établit une relation entre
deux entités. La relation n’a pas de sens sans
les entités qu’elle relie.
• Dans l’exemple on voit que l’association
enseigner dépend à la fois de la Matière et de
Enseignant

68
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
Etude des associations
• On ne représente pas explicitement
d’identifiant pour une association. Cependant,
implicitement on peut considérer que la
concaténation des identifiants des entités
reliées joue le rôle d’identifiant pour
l’association (voir MCD -> MLD).

69
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
Divers types d’association
Une association binaire concerne
2 entités.

70
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
Divers types d’association
Une association peut relier plusieurs entité
On appelle association ternaire
une association qui relie
3 entités.

71
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
Divers types d’association
Une association réflexive est une association reliant des
occurrences de la même entité.
Pour lire une association réflexive, il faut connaitre le
rôle de chaque branche de l’association.

72
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
Divers types d’association
Une association réflexive
Quels rôles pour ce exemple?

73
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
Divers types d’association
Une association plurielle
Deux mêmes entités peuvent être liées par
plusieurs associations.

74
75
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
d-Cardinalités d’une association
• Les cardinalités donnent une information sur
le nombre d’occurrences possibles de chaque
entité impliquée dans une association.
• Exemples :
– Un client passe plusieurs commandes
– Une commande est passée par un seul client
– Un étudiant s’inscrit à plusieurs cours
– Un cours est pris par plusieurs étudiants

76
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
d-Cardinalités d’une association
• Identifier le nombre minimal d’occurrences (X)
que l’entité peut participer à l’association
Cardinalité minimale
• Identifier le nombre maximal d’occurrences
(Y) que l’entité peut participer à l’association
Cardinalité maximale

77
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
d-Cardinalités d’une association
La cardinalité est modélisée de la façon
suivante:

78
 A - Le Modèle Conceptuel des Données (MCD)
1 Concepts de base pour le MCD
d-Cardinalités d’une association
• Types de cardinalités possibles :
– 0,1
– 1,1
– 0,n
– 1,n

79
 A - Le Modèle Conceptuel des Données (MCD)
d-Cardinalités d’une association
Exemple
– Un produit doit être stocké dans un et un seul
dépôt
– Un dépôt doit contenir au moins un produit

• Un Produit participe une et une seule fois à

l’association stocker
• Un Dépôt participe une ou plusieurs fois à
l’association stocker
80
 A - Le Modèle Conceptuel des Données (MCD)
d-Cardinalités d’une association
Exemple
– Un produit peut ne pas être stocké dans un
dépôt
– Un produit ne peut être stocké que dans un
seul dépôt
– Un dépôt peut ou non contenir des produits

81
 A - Le Modèle Conceptuel des Données (MCD)
d-Cardinalités d’une association
Exemple:
Quelle cardinalité pour la polygamie et la
monogamie ?

82
 A - Le Modèle Conceptuel des Données (MCD)
d-Cardinalités d’une association
Exemple:
Un employé travaille pour une entreprise
Un employé peut diriger un département
Un département est dirigé par un employé.

83
 A - Le Modèle Conceptuel des Données (MCD)
d-Cardinalités d’une association
Exemple

84
 A - Le Modèle Conceptuel des Données (MCD)
d-Cardinalités d’une association
• Bonne pratique: En général on essaye d’éviter
d’utiliser des associations ternaires ou de arité
supérieure.

85
 A - Le Modèle Conceptuel des Données (MCD)
d-Cardinalités d’une association

86
 A - Le Modèle Conceptuel des Données (MCD)
e-Règles de normalisation
• Le nom d’une entité, d’une association ou
d’un attribut doit être unique.
• Un verbe à l’infinitif pour les associations
• Un nom au singulier pour les attributs
• Un nom commun pour les attributs

87
 A - Le Modèle Conceptuel des Données (MCD)
e-Règes de normalisation
• Remplacer les attributs en plusieurs
exemplaires en une association
supplémentaire de cardinalités maximales n

88
 A - Le Modèle Conceptuel des Données (MCD)
e-Règes de normalisation
• Ne pas ajouter d’attribut calculable à partir
d’autres attributs.

89
 A - Le Modèle Conceptuel des Données (MCD)
Exercice1
On souhaite modéliser le système d'information des livraisons
d'une entreprise. Les informations dont nous disposons sont
les suivantes:
Des camions, identifiés par un Numéro de camion et dont on
connaît par ailleurs le Poids total en charge et le volume de
charge en m3 livrent des produits dans des dépôts. Les
produits ont une référence, un libellé et un prix unitaire, les
dépôts possèdent un code de dépôt et une adresse.
Des entretiens menés avec les responsables ont permis de
mettre en évidence que les camions, les produits et les dépôts
sont indépendants.
Un camion peut livrer n'importe quel produit dans n'importe
quel dépôt. Pour chaque action de livraison, on note la date et
la quantité.
Question 1 : Proposer un Modèle Conceptuel des Données.
90
91
 A - Le Modèle Conceptuel des Données (MCD)
Exercice1
La pratique a permis de mettre en évidence
certains défauts dans l'organisation de l'entreprise
(de l’exercice 1). Il apparaît qu'il serait beaucoup
plus efficace d'affecter les camions aux dépôts
avec lesquels ils travaillent. Ainsi, un camion est
affecté à un dépôt donné. Chaque dépôt possède
de un à plusieurs camions.
Question 2 : Modifier le modèle précédent pour
prendre en charge cette nouvelle contrainte.

92
93
 A - Le Modèle Conceptuel des Données (MCD)
Exercice 2 (Université)
Le système informatique d'une université utilise les données
suivantes :
• Pour chaque étudiant : son numéro de matricule, son nom,
son prénom et son adresse (rue, numéro,
cp, ville).
• Pour chaque cours : le mnémonique, l'intitule et un petit
résume.
• Pour chaque professeur : son numéro de matricule, son
titre, son nom, son prénom, et son adresse.
De plus le système doit savoir quels sont les cours que chaque
étudiant suit, le professeur titulaire de
chaque cours, la filière choisie par chaque étudiant et pour
chaque filière (dont on retient le nom et le code) le professeur
la dirigeant.
Donner un modèle entité-association de ce système et
préciser les contraintes d'intégrité. 94
Exercice 3 (Mutuelle)
Le SI d’une mutuelle est la suivante :
• La mutuelle est constituée de plusieurs membres.
• Chaque membre a : un numéro, un nom, un prénom, une
adresse, la date d’entrée dans la mutuelle et une éventuelle
date de sortie.
• Chaque membre doit effectuer des prestations dans la
mutuelle.
• Chaque prestation effectuée est caractérisée par : un
numéro, une description et la date de prestation.
• Chaque prestation appartient à un type donnée.
• Le type de prestation est caractérisé par : un code, une
description et le montant de la prestation.
Proposer le modèle entité-association correspondante à ce SI
en indiquant les contraintes d’intégrité.

95
B - Le Modèle Logique des Données (MLD)
1 Introduction

96
 B - Le Modèle Logique des Données (MLD)
1 Introduction
Il s’agit de traduire le modèle E/A vers un
modèle d’implantation à choisir (modèle
relationnelle).

97
B - Le Modèle Logique des Données (MLD)
Principe de traduction
• La sémantique n’est complétement pas
préservée.
– Ajout de contrainte d’intégrité
• Règles automatisables (de nombreux outils
existent sur le marché)
– AMCDesignor, GraphMake, DBDesigner,…

98
B - Le Modèle Logique des Données (MLD)
1 Introduction
Le MCD a permis de modéliser les structures de
données indépendamment des choix techniques
d’implantation de la base de données (Choix du
SGBD).
L’étape suivante : traduire le MCD en un modèle
plus proche du SGBD: le modèle logique des
données (MLD). Nous considérons ici le cas où
le SGBD choisi est de type relationnel.

99
B - Le Modèle Logique des Données (MLD)
1 Introduction
Dans un MLD basé sur le modèle relationnel,
l’unique objet existant est la table.
Le passage du MCD au MLD est systématique
On applique les règles de passage du MCD au
MLD.

100
B - Le Modèle Logique des Données (MLD)
2-Passage du MCD au MLD
• Avec le formalisme Entité-Association, il faut
définir tout un ensemble de règles de passage
du MCD au MLD. Nous allons examiner les
principales dans les diapos suivantes.

101
2-Passage du MCD au MLD
Traitement des entités
 Chaque entité devient une table ou relation;
 Chaque propriété (non composite, non
calculé) d’une entité devient un attribut de la
table correspondante;
 L’identifiant d’une entité devient la clé
primaire de la table.

102
2-Passage du MCD au MLD
Traitement des entités

103
2-Passage du MCD au MLD
Traitement des associations
• Cas de l’association père-fils
Cardinalité de l’entité père : 0,n ou 1,n
Cardinalité de l’entité fils : 0,1 ou 1,1
De façon générale, l’une des cardinalités
maximales est 1.
Ce sont des associations binaires monovaluées.

104
2-Passage du MCD au MLD
Traitement des associations
Cas de l’association père-fils ( binaire
monovaluée)
• L’entité père devient la table « père »
• L’entité fils devient la table « fils »
• L’identifiant de l’entité père devient attribut
de la table « fils » (Clé étrangère).
• Les propriétés de l’association deviennent des
attributs de la table « fils »

105
2-Passage du MCD au MLD
Traitement des associations
• Cas de l’association père-fils(binaire
monovaluée)

106
2-Passage du MCD au MLD
Traitement des associations
• Cas de l’association père-fils(binaire
monovaluée)
Cette configuration correspond exactement au
cas où on a une dépendance fonctionnelle entre
l’entité fils et l’entité père. Si une propriété
apparaît dans l’association (ex. E), c’est qu’elle
n’était sûrement pas bien placée.

107
2-Passage du MCD au MLD
Traitement des associations
Exemple:

108
2-Passage du MCD au MLD
Traitement des associations
• Cas des associations 0/1 ,n – 0/1,n (binaires
multivaluées dans les 2 sens)
Règles :
–Chaque entité devient une table ayant comme
clé son identifiant;
– L’association devient une table;
– L’identifiant de l’association (composé des
identifiants des 2 entités) devient la clé de la
table correspondante.
109
2-Passage du MCD au MLD
Traitement des associations
• Cas des associations 0/1 ,n – 0/1,n (binaires
multivaluées dans les 2 sens)

110
2-Passage du MCD au MLD
Traitement des associations
• Cas des associations 0,n – 1,n

111
2-Passage du MCD au MLD
Traitement des associations
• Cas association n-aires (n>2) multivaluées
dans les 2 sens.
Le même principe s’applique:
• Création d’une nouvelle table correspondant à
l’association
• Les identifiants des entités auxquelles
l’association est reliée migrent dans la nouvelle
table et forme sa clé primaire
• Les propriétés de l’association sont gardées
dans la table correspondante.
112
2-Passage du MCD au MLD
Traitement des associations
• Cas association n-aires (n>2) multivaluées
dans les 2 sens.

113
2-Passage du MCD au MLD
Traitement des associations
• Cas association n-aires (n>2) multivaluées
dans les 2 sens.

114
2-Passage du MCD au MLD
Traitement des associations
• Cas des associations 1,1 – 1,1
Deux entités reliées par une association de types
1,1- 1,1 devraient être fusionnées en une seule
entité, ainsi que les propriétés des relations les
reliant.

115
2-Passage du MCD au MLD
Traitement des associations
• Cas des associations 0,1 – 1,1 (association
binaire monovaluée)

Même principe

116
2-Passage du MCD au MLD
Traitement des associations
• Cas spécial de plusieurs associations entre 2
entités. Les règles générales s’appliquent.

117
2-Passage du MCD au MLD
Traitement des associations
Cas spécial de relations réflexives : les règles
générales s’appliquent.

118
 Exercice
Proposer un MLDR pour chaque MCD des
exercices sur le MCD.

119
 Exercice
Traduire en MLD Relationnel ce MCD

120
III Le modèle relationnel
Introduction

121
III Le modèle relationnel
Introduction
• Modèle de référence +40 ans
• Simple et robuste
• Parfaitement maitrisé par l’industrie

122
III Le modèle relationnel
1 Concept
Notion de domaine
• Ensemble de valeurs
Définition des domaines
• Types de base : entier, réel, date
• Intervalle : [18-65]
• Valeurs : {“marie”, “celibataire”, “divorcé”}
• Valeurs nulles : NULL

123
III Le modèle relationnel
1 Concept
Produit cartésien
Le PC de D1, D2,….Dn est l’ensemble des n-uplets
<v1,…,vn> tel que vi  Di
Notation
D1xD2x….xDn
Exemple:
D1={“BD”, “POO”}
D2={“Pierre”, “Paul”}
124
III Le modèle relationnel
1 Concept
Relation
Un sous-ensemble du produit cartésien d’une
liste de domaine caractérisée par un nom
Exemle
D1 = codeUV
D2 = coord
D3 = entiers de 0 à 150
UV  D1xD2xD3
125
III Le modèle relationnel
1 Concept
Attribut et tuple
• Plus simplement, une relation est un tableau à
deux dimensions
• Une ligne est un n-uplet ou tuple
• attribut est un nom associé à chaque colonne
afin de la repérer indépendamment de l'ordre
– Prend ses valeurs dans un domaine

126
127
III Le modèle relationnel
1 Concept
Clé
• Une clé est un groupe minimum d'attributs qui
détermine un n-uplet unique dans une relation
(à tout instant)
Exemple
• Clé de Étudiant ?
• Clé de UV ?
• Clé de Inscrit ?

128
III Le modèle relationnel
1 Concept
Clé
Contrainte d'intégrité
• Toute relation doit posséder une clé
renseignée (sans valeur inconnue)

129
III Le modèle relationnel
1 Concept
Schéma d’une relation
Le schéma d'une relation décrit :
• Son nom
• La liste des attributs qu'elle comporte et des
domaines associés
• La liste des attributs composant la clé (la clé est
soulignée)
Exemple
•Étudiant(num : entier, nom : chaîne, adresse :
chaîne, age : entier de 18 à 35)
130
III Le modèle relationnel
1 Concept
Schéma d’une relation
Intention vs. Extension
•Schéma de relation : intention de la relation
•Table : extension
•Schéma d'une BD relationnelle : ensemble des
schémas des relations

131
III Le modèle relationnel
1 Concept
Clé étrangère
Une clé étrangère est un groupe d'attributs qui
apparaît comme clé dans une autre relation
• R1(A1, A2, .... , Ap, Ap+1, ...., An)
• R2(B1, B2, ......, Bn)
Rôle
Les clés étrangères définissent des contraintes
d'intégrité référentielle entre relations

132
133
III Le modèle relationnel
1 Concept
Clé étrangère
• Mises à jour et clés étrangères Insertion : la
valeur des attributs doit exister dans la
relation référencée.
– Insertion de (4, ‘BD’, 15) dans Inscrit ?
•Suppression dans la relation référencée; les n-
uplets référençant doivent disparaître.
– Suppression de l’étudiant 2 dans Étudiant ?

134
III Algèbre relationnelle
Définition
2 types de langage associés au modèle
relationnel:
• Langages de Définition de données (LDD)
– Définition/mise à jour des schémas de relations
• Langages de manipulation de données (LMD)
– Intérogation, Op. de AR
– mise à jour (suppr. Insertion, modif.)

135
III Algèbre relationnelle
Exemple
Schéma de base de données
Etudiant(num,nom,adresse,age)
UV(codeUV,nbH,coord)
Inscrit(numEtudiant, codeUV,note)

136
III Algèbre relationnelle
Principes Opérateurs
Tout résultat d’un opérateur est une relation
R -> Op -> R’
Opérateurs unaires et binaires
• Unaires: restriction, projection (sélection)
• Binaires : union, intersection, produit
cartésien , jointure.

137
III Algèbre relationnelle
Restriction
Permet de "sélectionner" des tuples
Réduit la taille de la relation verticalement
Contraintes
– Unaire
– Spécifier une condition
Notation
•Notation textuelle : T <- cond(R)
•Notation graphique :
T 138
III Algèbre relationnelle
Restriction
Exemple : Quelles sont les inscriptions au cours
Bases de Données ?
Etudiant(num,nom,adresse,age)
UV(codeUV,nbH,coord)
Inscrit(numEtudiant, codeUV,node)

Result <- codeuv=‘BD’(Inscrit)

139
III Algèbre relationnelle
Restriction
Exemple : Quelles sont les inscriptions au cours de
Bases de Données ?

Exemple: Quels sont les bons étudiants (note > =

15) inscrits au cours de Bases de Données ?

140
III Algèbre relationnelle
Projection
Permet de "sélectionner" des attributs
La projection réduit la taille de la relation
horizontalement
Contraintes
– Unaire
– Spécifier une liste d'attributs
Notation
– textuelle : T <- πattributs(R)
– graphique

141
III Algèbre relationnelle
Projection
Quelles sont les adresses des étudiants ?
Etudiant(num,nom,adresse,age)

Result <- πadresse(Etudiant)

142
III Algèbre relationnelle
Projection
Quels sont les codes et les nombres d’heures
des Uvs ?
UV(codeUV,nbH,coord)

143
III Algèbre relationnelle
Projection et restriction
Quels sont les numéros des bons étudiants
(note > = 15) inscrits en Bases de Données ?

144
III Algèbre relationnelle
Projection et restriction
Méthode :
• Analyse de la question pour identifier les
relations et attributs en jeu
– Limiter le nombre de relations en jeu
• Analyse de la question pour identifier les
opérateurs en jeu
-Quels sont les ..? => projection
-Qui respectent une condition => restriction

145
III Algèbre relationnelle
Produit cartesien
But
•Ensemble de tous les tuples obtenus par concaténation
de chaque tuple de R avec chaque tuple de S
Contraintes
Binaire
Schéma du résultat:
• R(a1, a2, ...., an), S(b1, b2, ..., bp)
• T <- R X S, T(a1, a2, ...., an, b1, b2, ..., bp)
• Card (R X S) = Card (R) * Card (S)
Notation
• Notation textuelle : T <- R X S
• Notation graphique :
146
III Algèbre relationnelle
Produit cartésien

147
 III Algèbre relationnelle
jointure
But
Permet d’établir le lien sémantique entre les
relations
Contraintes
• Binaire
• Schéma du résultat :
-R(a1, a2, ...., an), S(b1, b2, ..., bp)
-T <- R S, T(a1, a2, ...., an, b1, b2, ..., bp)
condition

Notation
• textuelle : T <- R S
• Graphique condition 148
III Algèbre relationnelle
jointure

149
III Algèbre relationnelle
jointure

150
III Algèbre relationnelle
Opérateur U (ensembliste)
But
• Permet de fusionner 2 relations
Contraintes
• Binaire
• Même schéma
Notation
• Notation textuelle : T <- R U S
• Notation graphique :
L’opérateur Union fait parti des plus
simples et moins utilisés.
151
III Algèbre relationnelle
Opérateur U (ensembliste)
• Quels sont les noms des personnes
(professeurs et étudiants) habilitées à entrer
sur le campus ?
• Utiliser la projection pour avoir les mêmes
attributs

152
III Algèbre relationnelle
Opérateur ∩ (ensembliste)
But
• Permet d’obtenir l’ensemble des tuples
appartenant à deux relations
Contraintes
• Binaire
• Même schéma
Notation
• Notation textuelle : T<- R ∩S
• Notation graphique :

153
III Algèbre relationnelle
Opérateur ∩ (ensembliste)
• Quels sont les noms portés par des
professeurs et des étudiants ?

154
III Algèbre relationnelle
Opérateur – (différence)
But
Obtenir l’ensemble des tuples d’une relation qui ne
figurent pas dans une autre
Contraintes
– Binaire
– Même schéma
– Non commutatif
Notation
– Notation textuelle : T = R -S
– Notation graphique :
155
III Algèbre relationnelle
Opérateur – (différence)
Quels sont les noms des étudiants qui NE sont
PAS des noms de professeurs ?

156
III Algèbre relationnelle
Synthèse

157
 Exemple de requête
Base de donnée : Vins
• Vins(num, cru, annee, degre)
• Recoltes(nvin, nprod, quantite)
• Producteurs(num, nom, prenom, region)
• Clients(num, nom, prenom, ville)
• Commandes(ncde, date, ncli, nvin, qte)
• Livraisons(ncde, no_ordre, qteLivree)

158
 Exemple de requête
Requête
• Temp <- annee=1995 (Vins)
• Resultat <- πnum(Temp)

• Resultat <- πnum(annee=1995(Vins))

A quelle requête correspond la réponse?

159
 Exemple de requête
Requête
Quels sont les noms des producteurs de
Muscadet (cru)?

Démarche
1. Identifier les attributs impliqués:
2. Identifier les opérateurs relationnels dont on
aura besoin.

160
 Exemple de requête
Requête
Quels sont les noms des producteurs de
Muscadet (cru)?
• Vins(num, cru, annee, degre) -> Cru
• Producteurs(num, nom, prenom, region) -
>nom des pruduction
• Recoltes(nvin, nprod, quantite) -> lien

161
 Exemple de requête
Requête
Quels sont les noms des producteurs de
Muscadet (cru)?
Muscadet (restriction)
Noms (projection)
Lien(jointure)
πnom producteurs num=nprod Recoltes nvin=num
cru=muscadet(vins)

162
 Exemple de requête
Requête
Quels sont les numéros des vins ne faisant l’objet
d’aucune commande.
Différence

163
III Algèbre relationnelle
Optimisation des requêtes
Requêtes
Noms et prénoms des clients habitant ouaga
ayant commandé du Mâcon 1995 avant le 01
janvier 2000
• Plusieurs réponses possibles
• Optimiser = choisir la meilleure combinaison
– Les bons opérateurs
– Dans le meilleur ordre

164
III Algèbre relationnelle
Optimisation des requêtes
Réponse 1

165
III Algèbre relationnelle
Optimisation des requêtes
Réponse 2 (ordre des jointures)

166
III Algèbre relationnelle
Optimisation des requêtes
Réponse 3

167
III Algèbre relationnelle
Optimisation des requêtes
Réponse 4

168
III Algèbre relationnelle
Optimisation des requêtes
Heuristique la plus employée
•Remonter les opérateurs unaires (restriction,
projection) => diminution de la taille des
relations
•Descendre les jointures

169
III Algèbre relationnelle
Optimisation des requêtes
Facteurs déterminants
•Ordre d'exécution des opérations algébriques
•Algorithme implantant de façon optimale les
opérations algébriques.
•Placement des données sur le disque
•Taille des relations intermédiaires
•Statistiques d’exécution de ces requêtes
….
Responsabilité du SGBD

170
 III Algèbre relationnelle
Exercices

171