Modèle entité-relation de Chen - Informatique

Transcription

Modèle entité-relation de Chen - Informatique
Chapter 3
Le modèle entité-association
Synonyme d’entité-association : entité-relation hhentity-relationship ii
3.1
Définition des concepts
entité : c’est un objet qui permet à une application de fournir l’information désirée par
l’utilisateur du système. Il peut être physique, virtuel, conceptuel, imaginaire, artificiel,
etc. Le seul critère qui permet de juger de la pertinence d’une entité dans un modèle
est son utilité pour l’utilisateur.
Exemple: un livre, un étudiant, un dieu de la mythologie grecque, etc
type d’entité : c’est la collection de toutes les entités de même structure.
Exemple: L’ensemble de tous les étudiants que l’on pourrait potentiellement stocker
dans un système
Exemple: L’ensemble de tous les livres publiés et qui pourront être publiés dans toute
l’histoire de l’Humanité.
ensemble d’entité : c’est l’ensemble des entités contenues dans un système à un moment
donné.
Exemple: L’ensemble de tous les étudiants inscrits à l’Université de Sherbrooke en
janvier 2004.
Exemple: L’ensemble de tous les livres contenus dans le catalogue de la bibliothèque
de l’Université de Sherbrooke en décembre 2003.
Remarque: Il est courant d’entendre les expressions “entité” et “instance” au lieu
de “type d’entité” et “entité”. C’est une confusion fort malheureuse, à laquelle nous
n’échapperons pas.
attribut : c’est une fonction A qui associe une valeur v ∈ V à une entité E.
A:E→V
Exemple: Le nom d’un étudiant est un attribut d’un étudiant.
30
type d’un attribut : c’est le domaine de la valeur d’un attribut; donc, c’est le codomaine
de la fonction A, c’est-à-dire V ).
Voici quelques catégories de types d’attribut
• atomique (synonyme : univalent)
• composé (agrégat)
• plurivalent (synonyme : multivalent)
• dérivé
• mémorisé
clé d’un type d’entité : attribut injectif.
Soit K un attribut. Alors K est une clé ssi
K : E → P(V )
et (K est injective)
K(e1 ) = K(e2 ) ⇒ e1 = e2
ou bien
K ◦ K −1 = Id
type d’association hhrelationship type ii : un type d’association de degré n > 1 met en
relation n types d’entité E1 , . . . , En . C’est donc une relation mathématique R définie
par le produit cartésien E1 × . . . × En .
instance d’association : c’est un tuple (e1 , . . . , en ) de E1 × . . . × En .
ensemble d’association : c’est l’ensemble des instances (e1 , . . . , en ) contenus dans un
système à un moment donné. Chaque tuple associe n entités e1 , . . . , en .
Remarque: On dit qu’une association est récursive si E1 = E2 .
cardinalité d’un type d’association : Elle indique le nombre d’instances auxquelles une
entité peut participer. Il existe deux manières de représenter ces contraintes.
1. La première consiste à spécifier une borne maximale; elle ne s’applique qu’aux
associations binaires. Il y a donc trois cas de figure : 1:1, 1:N, M:N.
• 1:1 — une entité de E1 est reliée à au plus une entité de E2 ; de plus, une
entité de E2 est reliée à au plus une entité de E1 .
• 1:N — une entité E1 est reliée à un nombre arbitraire d’entités de E2 (donc,
il n’y a pas de maximum); de plus, une entité de E2 est reliée à au plus une
entité de E1 .
• M:N — une entité E1 est reliée à un nombre arbitraire d’entités de E2 (donc,
il n’y a pas de maximum); une entité E2 est reliée à un nombre arbitraire
d’entités de E1 (donc, il n’y a pas de maximum).
31
2. La deuxième manière consiste à spécifier un couple (min, max) pour chaque composante E du type d’association. Soit ke le nombre d’instances où l’entité e
apparaı̂t. Alors la condition min ≤ ke ≤ max doit être satisfaite pour tout e appartenant à un ensemble d’entités E. Cette notation s’applique à une association
de degré arbitraire (c-à-d, pas seulement les binaires).
Remarque: La notation UML utilise malheureusement de manière inappropriée
cette notation définie par Jean-Raymond Abrial en 1974. En UML, le couple
(min, max) est spécifié sur le côté opposé de l’association, ce qui fait qu’il ne peut
s’appliquer qu’aux associations binaires, en plus d’introduire une autre confusion
dont la communauté informatique se passerait bien :-).
type d’entité faible :
• un type d’entité faible dépend d’un ou plusieurs type d’entités propriétaires (pères);
• les entités propriétaires doivent exister avant que l’entité faible existe;
• il existe une relation d’identification entre l’entité faible et les entités propriétaires;
• cette relation est totale.
• une entité faible ne possède pas une clé complète, seulement d’une clé partielle;
• une entité faible doit hériter des clés de ses entités propriétaires pour former une
clé complète;
3.2
Notation
Voir figure elmasri 3.14
3.3
Convention nominative
• type d’entité : nom
• association : verbe
• disposition : lecture des associations de gauche à droite et de haut en bas (si possible)
3.4
3.4.1
Exemples
Système de gestion d’une bibliothèque
Voici une liste de fonctions pour un système de gestion de la bibliothèque
1. Acquerir(IdLivre, Titre, Auteur, Date)
2. Preter(IdLivre, IdMembre, Date)
32
3. Renouveler(IdLivre, Date)
4. Reserver(IdReservation, IdLivre, IdMembre, Date)
5. PrendreRes(IdReservation, Date)
6. Retourner(IdLivre, Date) : (IdLivre, Titre, Date, IdMembre)
7. AnnulerRes(IdReservation)
8. Vendre(IdLivre)
9. Eliminer(IdLivre)
10. Inscrire(IdMembre, Name, Telephone, LimitePrêt)
11. Modifier(IdMembre, Telephone, Limite)
12. Desinscrire(IdMembre)
13. AfficherDescr(IdLivre) : (IdLivre, Titre, Auteur)
14. AfficherLivreAuteur(Auteur) : (Titre, NbDePrets, DuréeMoyennePret)
15. AfficherLivreTitre(Titre):(IdLivre)
16. AfficherLivresenRetard(Date) : (IdMembre, IdLivre)
17. AfficherNouvelleAcquisition(Date) : (Titre, Auteur, IdLivre)
18. AfficherReservationsLivre(IdLivre) : (IdMembre, Name, Telephone, IdReservation)
19. AfficherReservationsforLivreRetard(Date) : (IdMembre, Name, Telephone, IdLivre,
Titre)
33
Miniworld
Functional Requirements
Database Requirements
FUNCTIONAL ANALYSIS
CONCEPTUAL DESIGN
High-level Transaction
Specification
Conceptual Schema
(In a high-level data model)
DBMS-independent
LOGICAL DESIGN
(DATA MODEL MAPPING)
DBMS-specific
Logical (Conceptual) Schema
(In the data model of a specific DBMS)
APPLICATION PROGRAM
DESIGN
PHYSICAL DESIGN
TRANSACTION
IMPLEMENTATION
Application Programs
Internal Schema
Figure 3.1 A simplified diagram to illustrate
the main phases of database design.
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition
REQUIREMENTS
COLLECTION AND
ANALYSIS
Figure 3.2
Fname
Minit
ER
schema diagram for the company database.
Lname
Number
Address
Name
Sex
1
N
WORKS_FOR
Name
Locations
Salary
Ssn
___
DEPARTMENT
NumberOfEmployees
StartDate
EMPLOYEE
Bdate
1
1
1
MANAGES
CONTROLS
N
Hours
supervisor
supervisee
N
WORKS_ON
1
SUPERVISION
PROJECT
1
N
Name
Location
Number
______
DEPENDENTS_OF
N
DEPENDENT
Name
Sex
BirthDate
Relationship
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition
Figure 3.3
Two entities, an employee e1 and a company c1,
and their attribute values.
Name = Sunco Oil
Name = John Smith
e1
Address = 2311 Kirby,
Houston, Texas 77001
c1
Headquarters = Houston
Age = 55
HomePhone = 713-749-2630
President = John Smith
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition
Figure 3.4 A hierarchy of composite attributes; the
StreetAddress component of an Address is further composed
of Number, Street, and ApartmentNumber.
Address
StreetAddress
Number
Street
City
State
ApartmentNumber
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition
Zip
Figure 3.5 A complex attribute AddressPhone with
multivalued and composite components.
{AddressPhone( {Phone(AreaCode,PhoneNumber)},
Address(StreetAddress(Number,Street,ApartmentNumber),
City,State,Zip) ) }
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition
Figure 3.6 Two entity types named EMPLOYEE and COMPANY,
and some of the member entities in the collection of entities
(or entity set) of each type.
ENTITY TYPE NAME:
EMPLOYEE
Name, Age, Salary
ENTITY SET:
(EXTENSION)
COMPANY
Name, Headquarters, President
e1
c1
(John Smith, 55, 80k)
(Sunco Oil, Houston, John Smith)
e2
c2
(Fred Brown, 40, 30K)
(Fast Computer, Dallas, Bob King)
e3
(Judy Clark, 25, 20K)
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition
Figure 3.7 The CAR entity type, with two key attributes Registration and
VehicleID. Multivalued attributes are shown between set braces {}.
Components of a composite attribute are shown between parentheses ().
CAR
Registration(RegistrationNumber, State), VehicleID, Make, Model, Year, {Color}
car1
((ABC 123, TEXAS), TK629, Ford Mustang, convertible, 1998, {red, black})
car2
((ABC 123, NEW YORK), WP9872, Nissan Maxima, 4-door, 1999, {blue})
car3
((VSY 720, TEXAS), TD729, Chrysler LeBaron, 4-door, 1995, {white, blue})
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition
Figure 3.8
Preliminary design of entity types for the COMPANY database
whose requirements are described in Section 3.2.
DEPARTMENT
Name, Number, {Locations}, Manager, ManagerStartDate
PROJECT
Name, Number, Location, ControllingDepartment
EMPLOYEE
Name (FName, MInit, LName), SSN, Sex, Address, Salary,
BirthDate, Department, Supervisor, {WorksOn (Project, Hours)}
DEPENDENT
Employee, DependentName, Sex, BirthDate, Relationship
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition
Figure 3.9 Some instances of the WORKS_FOR
relationship between EMPLOYEE and DEPARTMENT.
EMPLOYEE
WORKS_FOR
DEPARTMENT
r1
e1
e2
e3
r2
r3
e4
r4
e5
e6
e7
r5
r6
r7
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition
d1
d2
d3
Figure 3.10 Some relationship instances
of a ternary relationship SUPPLY.
SUPPLIER
SUPPLY
PROJECT
s1
s2
r1
r2
r3
r4
PART
r5
p1
p2
p3
r6
r7
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition
j1
j2
j3
Figure 3.11 The recursive relationship SUPERVISION, where the EMPLOYEE
entity type plays the two roles of supervisor (1) and supervisee (2).
SUPERVISION
EMPLOYEE
r1
2
e1
1
e2
r2
2
1
e3
1
e4
2
2
e5
r4
1
1
2
e6
r3
r5
e7
2
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition
r6
Figure 3.12 The 1:1 relationship MANAGES, with partial
participation of employee and total participation of DEPARTMENT.
EMPLOYEE
MANAGES
e1
DEPARTMENT
r1
d1
e2
e3
e4
r2
r3
e5
e6
e7
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition
d2
d3
Figure 3.13 The M:N relationship WORKS_ON
between EMPLOYEE and PROJECT.
WORKS_ON
EMPLOYEE
r1
PROJECT
e1
e2
e3
r2
r3
p1
p2
e4
r4
r5
r6
r7
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition
p3
p4
Symbol
Meaning
ENTITY TYPE
WEAK ENTITY TYPE
IDENTIFYING RELATIONSHIP TYPE
KEY ATTRIBUTE
MULTIVALUED ATTRIBUTE
...
COMPOSITE ATTRIBUTE
DERIVED ATTRIBUTE
R
E1
1
E1
E2
TOTAL PARTICIPATION OF E2 IN R
E2
CARDINALITY RATIO 1: N FOR E1:E2 IN R
EE
STRUCTURAL CONSTRAINT (min, max)
ON PARTICIPATION OF E IN R
N
R
R
(MIN, MAX)
Summary of ER diagram notation.
ATTRIBUTE
Figure 3.14
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition
RELATIONSHIP TYPE
Figure 3.15 ER diagram for the COMPANY schema, with all role
names included and with structural constraints on relationships
specified using the alternate notation (min, max).
Fname
Minit
Name
Lname
Sex
Number
Address
Salary
WORKS_FOR
(1,1)
(4,N)
Name
department
employee
Ssn
DEPARTMENT
NumberOfEmployees
EMPLOYEE
Locations
StartDate
(0,1)
Bdate
(1,1)
manager
departmentmanaged
MANAGES
(0,N)
controllingdepartment
(1,N)
(0,N)
(0,1)
supervisor
worker
supervisee
Hours
CONTROLS
SUPERVISION
(0,N)
WORKS_ON
employee
(1,N)
controlledproject
project
(1,1)
PROJECT
Name
DEPENDENTS_OF
Number
Location
dependent
(1,1)
DEPENDENT
Relationship
Name
Sex
BirthDate
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition
AirportCode
Figure 3.16
City
State
1
N
DEPARTURE
AIRPORT
LegNo
AIRPORT
FLIGHT LEG
ScheduledArrTime
1
ARRIVAL
AIRPORT
N
M
N
CAN
LAND
instances
LEGS
N
1
Weekdays
INSTANCE
OF
TypeName
Number
Max-seats
N
AIRPLANE
TYPE
Airline
Company
FLIGHT
1
ArrTime
DEPARTS
1
1
DepTime
N
FARES
ARRIVES
Code
N
N
1
FARE
TYPE
Restrictions
N
AirplaneId
Amount
Date
Total-no-of-seats
No-of-avail
seats
AIRPLANE
1
LEG
INSTANCE
N
ASSIGNED
CustomerName
NOTES:
(1) A LEG (SEGMENT) IS A NONSTOP PORTION OF A FLIGHT
(2) A LEG INSTANCE IS A PARTICULAR OCCURRENCE
OF A LEG ON A PARTICULAR DATE
N
SeatNo
SEAT
CPhone
RESERVATION
1
An ER diagram for an airline database.
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition
Scheduled DepTime
Name
Figure 3.17
1
BANK
Code
Name
An ER diagram for a BANK database.
N
BANK-BRANCH
BRANCHES
Addr
Addr
BranchNo
1
1
ACCTS
LOANS
N
AcctNo
N
Balance
Type
ACCOUNT
LOAN
M
M
A-C
L-C
N
Phone
N
Name
SSN
CUSTOMER
Amount
LoanNo
Addr
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition
Type
Figure 3.18 An ER diagram for a database that keeps
track of company and employee phones.
EMPLOYEE
WORKS-IN
DEPARTMENT
CONTAINS
HAS-PHONE
PHONE
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition
Figure 3.19 An ER diagram for a database that
keeps track of textbooks used in courses.
INSTRUCTOR
TEACHES
COURSE
USES
TEXT
© Addison Wesley Longman, Inc. 2000, Elmasri/Navathe, Fundamentals of Database Systems, Third Edition