Transcript Document 7924086

Le Modèle Entité-Relation
(Entité-Association)
Chapitre 2
1
Objectifs

Survol de la conception des base de données


Analyse des prérequis, design conceptuel, design logique,
normalisation et design physique
Modèle entité-relation (ER)

Éléments de base:
•
•
•

Éléments avancés:
•
•
•
•

Entités
Relations
Attributs
Contraintes
Entités faibles
Hiérarchies ISA
Agrégation
Design conceptuel utilisant le modèle ER
2
Survol de la Conception des Bases de Données

Analyse des prérequis: Trouver ce que les utilisateurs veulent faire
avec la BD.




Quelles données doivent être stockées?
Quelles applications doivent être programmées pour ces données?
Quelles sont les opérations dont la performance est critique?
Design conceptuel: Utiliser le résultat de l’AP afin de développer une
description (sémantique) de haut niveau pour les données à stocker,
ainsi que les contraintes typiques de ces données. Le résultat de cet
étape est habituellement un diagramme ER.
Quelles sont les entités et les relations du domaine?
 Quelles sont les contraintes d’intégrité qui sont valides?
Le résultat de cette étape est le schéma conceptuel des données.


Design logique: Choisir un SGBD et traduire le schéma du design
conceptuel (diagramme ER) dans le modèle des données du SGBD.
Le résultat de cette étape est le schéma logique des données.
3
Survol de la Conception des BDs (Suite)



Décomposition du schéma: Analyser le schéma logique, identifier les
problèmes potentiels et résoudre ces derniers en décomposant les
schémas logiques à l’aide des formes normales.
Design physique: Considérer la charge de travail attendue que la BD
supportera afin de décomposer davantage le design en vue de la
performance désirée.
Design des applications et de la sécurité: Considère des aspects du design
qui vont au delà de la BD elle-même. Les méthodologies complètes de
design telles que UML sont utiles ici.



Quels sont les utilisateurs et les processus impliqués dans l’application?
Quels sont les rôles des utilisateurs impliqués?
Quelles parties de la BD doivent être accessibles à chaque rôle et et quelles
autres parties ne le doivent pas?
4
Conception des BDs: Résumé
Analyse des
prérequis
Domaine
Prerequis
Design conceptuel
Diagramme ER
Design logique
Schéma logique
Normalisation
Formes normales
Design physique
Schéma physique
5
Design Conceptuel de la Base de Données

Design conceptuel: (Le Model ER est utilisé à cette étape.)





Quelles sont les entités and relations du domaine?
Quelles informations à stocker dans la BD au sujet de ces
entités et relations?
Quelles sont les contraintes d’integrité de la BD?
Un `schéma’ de la BD dans le modèle ER peut être
représenté par un diagramme (diagrammes ER).
Le diagramme ER sera traduit en un schéma relationnel à
l’étape suivante du design.
6
Eléments de Base
du Modèle ER
ssn
name
lot
Employees


Entité: Objet du monde réel, distinct des autres objets.
Une entité est décrite par un ensemble d’attributs.
Ensemble d’entités: Une collection d’entités similaires.
P.ex. Tous les employés d’une entreprise.



Toutes les entités d’un ensemble d’entités ont les mêmes attributs.
(Exception: hiérarchies ISA – voir plus loin)
Chaque ensemble d’entités a une clé, c.à.d un ensemble minimal
d’attributs dont les valeurs identifient exactement une entité de
l’ensemble d’entités.
Chaque attribut a un domaine, c.à.d. un ensemble de valeurs
possibles.
7
Eléments de Base
du Modèle ER (Suite)
since
name
ssn
lot
Employees


did
Works_In
budget
Departments
Relation (association): Association entre deux ou plusieurs
entités. P.ex., Joe travaille dans le département de Pharmacie.
Ensemble de relations: Collection de relations similaires.


dname
Un ensemble de relations n-aires R relie n ensembles d’entités E1 ...
En; Chaque relation de R implique des entités e1 de E1, ..., en de En.
Attributs descriptifs: Attributs d’une relation; enregistrent de l’
info au sujet de la relation.
8
name
Eléments de Base
du modèle ER (Suite)
ssn
Employees
since
name
ssn
Employees

dname
lot
did
Works_In
lot
budget
Departments
supervisor
subordinate
Reports_To
Le même ensemble d’entités pourrait participer à des
ensembles de relations différents, ou à différents “rôles”
dans le même ensemble de relations:


Les entités reliées peuvent jouer des rôles différents; p.ex. emp1 fait
rapport à un employé emp2 (le manager). Des indicateurs de rôle
soulignent cette différence de rôles joués.
Si un ensemble d’entités a des entités qui jouent plus d’un rôle, on
obtient des attributs non ambigus pour l’ensemble des relations en
concaténant l’indicateur avec les attributs de l’ensemble d’entités.
9
Contraintes de Clé
since
name


Dans la relation
Works_In, un
employé peut
travailler dans
plusieurs depts; et
un dept peut avoir
plusieurs employés.
Par contre chaque
dept a tout au plus
un seul manager;
cela s’appelle la
contrainte de clé
(Voir la flèche dans
la figure ci-haut)
ssn
dname
lot
Employees
1-to-1
1-to Many
did
Manages
Many-to-1
budget
Departments
Many-to-Many
10
Contraintes de Participation

Chaque département a-t-il un manager?

Si oui, ceci est une contrainte de participation: La participation de
Departments dans Manages est dite être totale (vs. partielle).
• Chaque valeur did dans Departments doit être en relation avec
Manages
• Ci-dessous: une ligne grasse (fine) signifie participation totale
(partielle)
since
name
ssn
dname
did
lot
Employees
Manages
budget
Departments
Works_In
since
11
Entités Faibles (“Weak Entities”)

Une entité faible peut être identifiée uniquement seulement si l’on
considère la clé primaire d’une autre entité dite propriétaire identifiante.




L’ensemble d’entités propriétaires et l’ensemble d’entités faibles doivent
participer dans un ensemble de relations one-to-many (une propriétaire, de
multiples entités).
L’ensemble d’entités faibles doit avoir une participation totale dans cet
ensemble de relations; celle-ci est appelée ensemble de relations identifiantes.
Voir exemple ci-bas: des employés possèdent des polices d’assurance pour
leurs parents. L’ensemble d’entités faibles et son ensemble de relations
identifiantes sont indiqués par des rectangles et losanges à contour épais.
Un ensemble d’entités faibles a une clé partielle (Voir ligne hachée).
name
ssn
lot
Employees
cost
Policy
pname
age
Dependents
12
name
ssn
Hiérarchies ISA (`is a’)
Comme en C++, ou Java, les
hourly_wages
attributs sont hérités.
Si nous disons que A ISA B, toute
entité de A est aussi considérée
comme une entité de B.



lot
Employees
hours_worked
ISA
contractid
Hourly_Emps
Contract_Emps
Contraintes de superposition: Deux classes peuvent-elles se superposer?
P.ex., Joe peut-il être à la fois une entité de Hourly_Emps et de
Contract_Emps? (permis/nonpermis)
Contraintes de couverture: Les entités des sousclasses contiennent-elles
toutes les entités de la superclasse? P.ex., chaque entité de Employees
doit-elle aussi être une entité de Hourly_Emps ou Contract_Emps?
(oui/non)
Raisons d’utiliser ISA (par spécialisation/généralisation):
 Ajouter des attributs descriptifs à une sousclasse spécifique.
 Identifier des entités qui participe à une relation (Voir page 16).
13
name
ssn
Agrégation

Sert à modeller une
relation entre
ensemble d’entités et
ensemble de relation.


lot
Employees
Monitors
until
since
started_on
L’agrégation permet de
dname
traiter un ensemble
pid
pbudget
did
budget
de relations comme
un ensemble d’entités
Sponsors
Departments
Projects
afin d’établir une
relation entre eux.
* agrégation vs. relation ternaire:
Notation: une case
-- Surveiller une relation distincte avec
pointillée.
un attribut descriptif est ainsi possible.
-- Permet de dire que chaque relation est
surveillée par au plus un employé.
14
Design Conceptuel Utilisant le Modèle ER

Choix de design:




Devrait-on modeler un concept comme entité ou comme
attribut?
Devrait-on modeler un concept comme entité ou comme
relation?
Identification des relations: Binaire ou ternaire …?
agrégation?
Contraintes du modèle ER:


Beaucoup d’aspects de la sémantique des données
devrait être capturés.
Cependant quelques contraintes ne peuvent pas être
capturées dans ce modèle ER.
15
Entité vs. Attribut


Devrait-on exprimer l’adresse comme un attribut de
Employees ou comme un ensemble d’entités (connectés a
Employees par un ensemble de relations)?
Cela dépend de l’usage que nous voulons faire de l’info
stockée dans l’adresse, ainsi que de la sémantique des
données:
• Si nous avons plusieurs adresses par employé, address doit alors
être une entité (car les attributs ne peuvent pas avoir des
ensemble comme valeurs – ne sont pas “set-valued”).
• Si la structure (city, street, etc.) est importante (p.ex. Nous
voulons être capable d’extraire les employés d’une cité donnée),
address doit dans ce cas être modelée comme une entité (car les
valeurs d’un attribut sont atomiques).
16
Entité vs. Attribut (Suite)
name


from
to
dname
lot
did
La relation Works_In4 ne ssn
budget
permet pas à un employé
Departments
de travailler dans un
Works_In4
Employees
département pour 2 ou
plusieurs périodes de
temps.
Ce problème est similaire à
celui de plusieurs adresses
pour le même employé:
name
dname
Nous voulons enregistrer
ssn
lot
did
budget
plusieurs valeurs de l’attribut
descriptif pour chaque
Works_In4
Departments
Employees
relation. Cela est accompli
par l’introduction d’un
nouvel ensemble d’entités
Duration
to
from
appelé Duration.
17
Entité vs. Relation


Le premier diagramme ER
est correct si un manager
reçoit un budget
discrétionnaire séparé pour
chaque dept.
Si par contre un manager
reçoit un budget
discrétionnaire qui couvre
tous les depts gérés par lui,
on aura


Redondance: dbudget stocké
pour chaque dept géré par
le manager.
Info trompeuse: Suggère
que dbudget est associé avec
l’ensemble de relations
Manages alors que ce n’est
pas le cas !
since
name
ssn
dbudget
lot
Employees
dname
did
budget
Departments
Manages2
name
ssn
lot
dname
since
did
Employees
ISA
Managers
Manages2
dbudget
budget
Departments
Ceci résout le
problème!
18
Relations Binaires vs. Ternaires
name
ssn
Employees
age
Dependents
Covers
Mauvais design par rapports
aux prérequis ci-bas
Policies
policyid

pname
lot
cost
Ce diagramme ER n’exprime pas les requis suivants:
 Une police ne peut être couverte par deux personnes en même temps.
 Chaque police doit être couverte par quelqu’un.
 Dependents est un ensemble d’entités faibles avec “pname” comme
clé partielle et identifiées par la clé primaire de Policies.


Qu’est ce que ce diagramme exprime?
Quelles contraintes additionnelles résoudraient notre
problème?
19
Relations Binaires vs. Ternaires (Suite)


Solution: introduire deux relations binaires à la place de Covers, à
savoir Purchaser et Beneficiary.
Ensuite ajouter les contraintes suivantes:
 Contrainte de clé sur Policies par rapport à Purchaser
 Contrainte de participation totale sur Policies par rapport à Purchaser
 Contraintes appropriées sur l’ensemble d’entités faibles Dependents

Quid si nous n’ajoutons qu’une contrainte de clé sur Policies par
rapport à Covers?
name
ssn
pname
lot
age
Dependents
Employees
Purchaser
Beneficiary
Meilleur design
Policies
policyid
cost
20
Relation Binaires vs. Ternaires (Suite)


Les exemples précédents ont illustré le cas dans lequel
deux relations binaires valaient mieux qu’une relation
ternaire.
Un exemple dans l’autre direction: Une relation ternaire
Contracts relie l’ensemble d’entités Parts, Departments et
Suppliers, et a un attribut descriptif quantity. Aucune
combinaison de relations binaires n’est reélément
adéquate pour cette situation:


S “can-supply” P, D “needs” P, et D “deals-with” S n’impliquent
pas que D a accepté d’acheter P de S.
Comment pouvons nous enregistrer quantity? Il semble impossible
de le représenter de manière précise avec ces relations binaires.
21
Résumé

Le design conceptuel vient après l’analyse des prérequis.


Le modèle ER est populaire dans le design conceptuel.





On obtient ici une description de haut niveau (“high-level”) des
données à stocker.
Les éléments du modèle sont expressifs et proches de la manière dont
les gens pensent au sujet de leurs applications.
C’est un modèle sémantique !
Éléments de bases: entités, relations (associations) et attributs.
Quelques éléments additionnels: entités faibles, hiérarchies ISA
et agrégation.
Note: Il y a beaucoup de variations notationnelles du modèle
ER.
22
Résumé (Suite)

Plusieurs sortes de contraintes d’intégrité peuvent
être exprimées dans le modèle ER: Contraintes clé,
contraintes de participation et contraintes de
superposition/couverture pour les hiérarchies ISA.
Quelques contraintes de clés étrangères sont aussi
implicites dans la définition de l’ensemble de
relations.


Quelques contraintes (dont les dépendances fonctionnelles) ne
peuvent être exprimées dans le modèle ER.
Les contraintes jouent un rôle important dans la
détermination du meilleur design de base de données pour
une entreprise.
23
Résumé (Suite)

Le design en modèle ER est subjectif. Il y a souvent
plusieurs manières de modeler un scénario donné.
L’analyse des alternatives peut être plein d’astuces à
maîtriser, surtout pour les larges entreprises. Souvent un
choix est à faire:


entité vs. attribut, entité vs. relation, binaire vs n-aire, utilisation
possibles des hiérarchies ISA et des agrégations.
Un bon design conceptuel résulte en un schéma relationnel
qui sera analysé et décomposé plutard. Les info sur les FDs
et les techniques de normalisation sont particulièrement
utiles ici.
24