Le Mod

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

• Chapitre 2

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 opérations ont des prérequis de
  performance critiques?
• Design conceptuel Utilise le résultat de lAP
  pour développer une description (sémantique) de
  haut niveau pour les données à stocker, ensemble
  avec leurs contraintes. 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 dintegrité qui
  sont valides?
• 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 Bases de Données
(Suite)

• décomposition du schéma Analyse le schéma
  logique, identifie les problèmes potentiels et
  résoud ces derniers en décomposant les schémas
  logiques à laide des formes normales.
• Design physique Considère la charge de travail
  attendue que la BD supportera afin de décomposer
  davantage le design en vue de la performance
  desirée.
• Design des applications et de la sécurité
  Considère des aspects du design qui vont audelà
  de la BD elle-même. Les méthodologies complète de
  design telles que UML sont utiles ici.
• Quelles sont les utilisateurs et les processus
  impliqués dans lapplication?
• Quelles sont les rôles des utilisateurs
  impliqués?
• Quelles parties de la BD doivent être accessible
  à chaque rôle et et quelles autres parties ne le
  doivent pas?

4
Design Conceptuel de la Base de Donnees

• Design conceptuel (Le Model ER est utilise a
  cette étape.)
• Quelles sont les entités and relations dans
  lenterprise?
• Quelles informations doivent être stockées dans
  le 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
  representé par une figure diagrammatique
  (diagrammes ER).
• Un diagramme ER peut être traduit en un schéma
  relationel.

5
Eléments de Base du Modèle ER

• entité Object du monde réel qui est distinct des
  autres objets. Une entitée est décrite en base de
  données en utilisant 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. (Du moins tant que les
  hiérarchies ISA ne sont pas encore considerées!)
• Chaque ensemble dentités a une clé, c.a.d un
  ensemble minimal dattributs dont les valeurs
  détermine exactement une entité de lensemble
  dentités.
• Chaque attribut a un domaine, c.a.d. un ensemble
  de valeurs possibles.

6
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

• 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.
• Une relation n-aire R relie n ensembles dentités
  E1 ... En Chaque relation dans 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.

7
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éespeuvent jouer des rôles
  différents p.ex. emp1 fait rapport a un employe
  emp2 qui est son manager. Des indicateurs de rôle
  soulignent cette difference de rôles joues.
• Si un ensemble dentités a des entités qui jouent
  plus dun rôle, on obtient des attributs
  nonambigus pour lensemble des relations en
  concatenant lindicateur avec les attributs de
  lensemble dentités.

8
Contraintes de Clé
budget
did

• Considérez 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, selon la contrainte de clé (Voir la
  fleche dans la figure)

Departments
1-to-1
1-to Many
Many-to-1
Many-to-Many
9
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 la table Departments doit
  apparaitre dans une ligne de la table Manages
  (avec une valeur ssn non-nulle!)
• Ci-dessous ligne grasse lt-gt participation
  totale
• ligne fine lt-gt partielle

since
since
name
dname
name
dname
ssn
lot
budget
did
budget
did
Departments
Employees
Manages
Works_In
since
10
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 diamants à contour épais.
• Un ensemble dentités faibles a une clé partielle
  (Voir ligne hachée).

name
cost
pname
age
ssn
lot
Dependents
Policy
Employees
11
Hiérarchies ISA (is a)
name
ssn
lot
Employees
Comme en C, ou dautres languages, les
attributs sont herités. Si nous disons que A ISA
B, toute entité de A est aussi consideré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 Des 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.

12
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
• -- Surveille une relation distincte avec
• un attribut descriptif.
• -- Permet de dire que chaque relation est
• surveillée par au plus un employé.

13
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.

14
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).

15
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é Nou voulons
  enregistrer plusieurs valeurs de lattribut
  descriptif pour chaque relation. Cela est
  accomplis par lintroduction dun nouvel ensemble
  dentités appele Duration.

budget
Departments
Works_In4
name
ssn
lot
Works_In4
Departments
Employees
16
Entité vs. Relation

• Le premier diagramme ER est correct si un manager
  reçoit un budget discretionaire séparé pour
  chaque dept.
• Si par contre un manager reçoit un budget
  discretionaire 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ésoud le problème!
Managers
dbudget
17
Relations Binaires vs. Ternaires
pname
age

• Si chaque police dassurance est possedée par
  exactement un employé, et que chaque parent
  dépendant est lié à ladite police, le premier
  diagramme est imprécis.
• Quelles contraintes additionnelles y-a-t-il dans
  le 2ème diagramme?

Dependents
Covers
Mauvais design
pname
age
Dependents
Purchaser
Meilleur design
18
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 qty. 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 qty? Il semble
  impossible de le représenter de manière precises
  avec ces relations binaires.

19
Résumé

• Le design conceptual design 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 !
• Eléments de bases entités, relations
  (association) et attributs.
• Quelques éléments additionnels faibles entités,
  hiérarchies ISA et agrégation.
• Note Il y a beaucoup de variations notationelles
  du modèle ER.

20
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épendences
  fonctionelles) 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.

21
Résumé (Suite)

• Le design en modèle ER est subjectif. Il y a
  souvent plusieurs manières de modeler un scenario
  donné. Lanalyse des alternatives peut être plein
  dastuces à maitriser, 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égation.
• Un bon design conceptuel résulte en un schéma
  relationel qui sera analysé et décomposé plutard.
  Les info sur les FDs et les techniques de
  normalisation sont particulièrement utiles ici.