Le Mod

1
Le Modèle Entité-Relation
(Entité-Association)

• Chapitre 2

2
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
• Entités
• Relations
• Attributs
• Éléments avancés
• Contraintes
• Entités faibles
• Hiérarchies ISA
• Agrégation
• Design conceptuel utilisant le modèle ER

3
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 lAP
  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 dinté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.

4
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 à laide 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 lapplication?
• 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?

5
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
6
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 dintegrité 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.

7
Eléments de Base du Modèle ER

• Entité Objet du monde réel, distinct des autres
  objets. Une entité est décrite par un ensemble
  dattributs.
• Ensemble dentités Une collection dentités
  similaires. P.ex. Tous les employés dune
  entreprise.
• Toutes les entités dun ensemble dentités ont
  les mêmes attributs. (Exception hiérarchies ISA
  voir plus loin)
• Chaque ensemble dentités a une clé, c.à.d un
  ensemble minimal dattributs dont les valeurs
  identifient exactement une entité de lensemble
  dentités.
• Chaque attribut a un domaine, c.à.d. un ensemble
  de valeurs possibles.

8
Eléments de Base du Modèle ER (Suite)
since
name
dname
budget
ssn
lot
did
Works_In
Departments
Employees

• 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.
• Un ensemble de relations n-aires R relie n
  ensembles dentités E1 ... En Chaque relation
  de R implique des entités e1 de E1, ..., en de
  En.
• Attributs descriptifs Attributs dune relation
  enregistrent de l info au sujet de la relation.

9
Eléments de Base du modèle ER (Suite)
name
ssn
lot
Employees
since
name
dname
super-visor
subor-dinate
budget
ssn
lot
did
Reports_To
Works_In
Departments
Employees

• Le même ensemble dentité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 dentités a des entités qui jouent
  plus dun rôle, on obtient des attributs non
  ambigus pour lensemble des relations en
  concaténant lindicateur avec les attributs de
  lensemble dentités.

10
Contraintes de Clé
budget
did

• 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 sappelle la contrainte de clé
  (Voir la flèche dans la figure ci-haut)

Departments
1-to-1
1-to Many
Many-to-1
Many-to-Many
11
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
since
name
dname
name
dname
ssn
lot
budget
did
budget
did
Departments
Employees
Manages
Works_In
since
12
Entités Faibles (Weak Entities)

• Une entité faible peut être identifiée uniquement
  seulement si lon considère la clé primaire dune
  autre entité dite propriétaire identifiante.
• Lensemble dentités propriétaires et lensemble
  dentités faibles doivent participer dans un
  ensemble de relations one-to-many (une
  propriétaire, de multiples entités).
• Lensemble dentité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 dassurance pour leurs parents.
  Lensemble dentités faibles et son ensemble de
  relations identifiantes sont indiqués par des
  rectangles et losanges à contour épais.
• Un ensemble dentités faibles a une clé partielle
  (Voir ligne hachée).

name
cost
pname
age
ssn
lot
Dependents
Policy
Employees
13
Hiérarchies ISA (is a)
name
ssn
lot
Employees
Comme en C, ou Java, les 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.
hours_worked
hourly_wages
ISA
contractid
Contract_Emps
Hourly_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 dutiliser ISA (par spécialisation/généra
  lisation)
• Ajouter des attributs descriptifs à une
  sousclasse spécifique.
• Identifier des entités qui participe à une
  relation (Voir page 16).

14
Agrégation
name
lot
ssn

• Sert à modeller une relation entre ensemble
  dentités et ensemble de relation.
• Lagrégation permet de traiter un ensemble de
  relations comme un ensemble dentités afin
  détablir une relation entre eux.
• Notation une case pointillée.

Monitors
until
since
started_on
dname
pid
pbudget
did
budget
Sponsors
Departments
Projects

• agrégation vs. relation ternaire
• -- Surveiller une relation distincte avec
• un attribut descriptif est ainsi possible.
• -- Permet de dire que chaque relation est
• surveillée par au plus un employé.

15
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 daspects 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.

16
Entité vs. Attribut

• Devrait-on exprimer ladresse comme un attribut
  de Employees ou comme un ensemble dentités
  (connectés a Employees par un ensemble de
  relations)?
• Cela dépend de lusage que nous voulons faire de
  linfo stockée dans ladresse, 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
  dextraire les employés dune cité donnée),
  address doit dans ce cas être modelée comme une
  entité (car les valeurs dun attribut sont
  atomiques).

17
Entité vs. Attribut (Suite)
to
from

• La relation Works_In4 ne permet pas à un employé
  de travailler dans un département pour 2 ou
  plusieurs périodes de temps.
• Ce problème est similaire à celui de plusieurs
  adresses pour le même employé Nous voulons
  enregistrer plusieurs valeurs de lattribut
  descriptif pour chaque relation. Cela est
  accompli par lintroduction dun nouvel ensemble
  dentités appelé Duration.

budget
Departments
Works_In4
name
ssn
lot
Works_In4
Departments
Employees
18
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 lensemble de relations Manages alors que
  ce nest pas le cas !

since
dbudget
name
dname
ssn
did
lot
budget
Employees
Departments
Manages2
name
ssn
lot
dname
since
did
budget
Employees
Departments
Manages2
ISA
Ceci résout le problème!
Managers
dbudget
19
Relations Binaires vs. Ternaires
pname
age
Dependents
Covers
Mauvais design par rapports aux prérequis ci-bas

• Ce diagramme ER nexprime pas les requis
  suivants
• Une police ne peut être couverte par deux
  personnes en même temps.
• Chaque police doit être couverte par quelquun.
• Dependents est un ensemble dentités faibles avec
  pname comme clé partielle et identifiées par la
  clé primaire de Policies.
• Quest ce que ce diagramme exprime?
• Quelles contraintes additionnelles résoudraient
  notre problème?

20
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 lensemble dentités
  faibles Dependents
• Quid si nous najoutons quune contrainte de clé
  sur Policies par rapport à Covers?

pname
age
Dependents
Purchaser
Meilleur design
21
Relation Binaires vs. Ternaires (Suite)

• Les exemples précédents ont illustré le cas dans
  lequel deux relations binaires valaient mieux
  quune relation ternaire.
• Un exemple dans lautre direction Une relation
  ternaire Contracts relie lensemble dentités
  Parts, Departments et Suppliers, et a un attribut
  descriptif quantity. Aucune combinaison de
  relations binaires nest reélément adéquate pour
  cette situation
• S can-supply P, D needs P, et D
  deals-with S nimpliquent pas que D a accepté
  dacheter P de S.
• Comment pouvons nous enregistrer quantity? Il
  semble impossible de le représenter de manière
  précise avec ces relations binaires.

22
Résumé

• Le design conceptuel vient après lanalyse des
  prérequis.
• On obtient ici une description de haut niveau
  (high-level) des données à stocker.
• Le modèle ER est populaire dans le design
  conceptuel.
• Les éléments du modèle sont expressifs et proches
  de la manière dont les gens pensent au sujet de
  leurs applications.
• Cest 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.

23
Résumé (Suite)

• Plusieurs sortes de contraintes dinté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 lensemble 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.

24
Résumé (Suite)

• Le design en modèle ER est subjectif. Il y a
  souvent plusieurs manières de modeler un scénario
  donné. Lanalyse des alternatives peut être plein
  dastuces à 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.