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