CS 220 Databases Entity/Relationship Model Part 2

Transcription

1 CS 220 Databases Entity/Relationship Model Part 2

2 An Example: E/R Data Model Design Issue #3: Relationship Cardinalities Customer? Borrows? Loan Variations on Borrows: 1. Can a customer hold multiple loans? 2. Can a loan be jointly held by more than 1 customer? 1.2

3 E/R Data Model Design Issue #3: Relationship Cardinalities Customer? Borrows? Loan Cardinalities of Borrows: Type Illustrated Multiple Loans? Joint Loans? One-to-One (1:1) Borrows No No Many-to-one (n:1) Borrows No Yes One-to-many (1:n) Borrows Yes No Many-to-many (n:m) Borrows Yes Yes 1.3

4 E/R Data Model Design Issue #3: Relationship Cardinalities (cont) In general... 1:1 n:1 1:n n:m 1.4

5 An Example: Works_At E/R Data Model Design Issue #4: N-ary vs Binary Relationship Sets Ternary: Binary: Employee Works_at Branch Dept vs (Joe, Moody, Acct) Works_At Employee WA E WA WA B Branch Choose n-ary when possible! (Avoids redundancy, update anomalies) WA D Dept (Joe, w 3 ) WA E (Moody, w 3 ) WA B (Acct, w 3 ) WA D 1.5

6 E/R Data Model Keys Key = set of attributes identifying individual entities or relationships Employee essn ename eaddress ephone A. Superkey: any attribute set that distinguishes identities e.g., {essn}, {essn, ename, eaddress} B. Candidate Key: minimal superkey (can t remove attributes and preserve keyness ) e.g., {essn}, {ename, eaddress} C. Primary Key: candidate key chosen as the key by a DBA e.g., {essn} (denoted by underline) 1.6

7 E/R Data Model Relationship Set Keys Employee essn ename... Works_At since Branch bname bcity... Q: What attributes needed to represent relationships in Works_At? e 2 e 1 e 3 b 2 b 1 A: {essn, bname, since} 1.7

8 E/R Data Model Relationship Set Keys (cont.) Employee essn ename... Works_At since Branch bname bcity... Q: What are the candidate keys of Works_At? e 2 e 1 e 3 b 2 b 1 A: {essn} 1.8

9 E/R Data Model Relationship Set Keys (cont.) Employee essn ename... Works_At since Branch bname bcity... Q: What are the candidate keys if Works_At is...? a. 1:n b. n:m A: {bname} A: {essn, bname} Assumption: employees have <= 1 record per branch c. 1:1 A: {essn}, {bname} 1.9

10 Relationship Types, Relationship Sets, Roles, and Structural Constraints Relationship When an attribute of one entity type refers to another entity type Represent references as relationships not attributes Copyright 2011 Ramez Elmasri and Shamkant Navathe

11 Relationship Types, Sets, and Instances Relationship type R among n entity types E 1, E 2,..., E n Defines a set of associations among entities from these entity types Relationship instances r i Each r i associates n individual entities (e 1, e 2,..., e n ) Each entity e j in r i is a member of entity set E j Copyright 2011 Ramez Elmasri and Shamkant Navathe

12 Relationship Degree Degree of a relationship type Number of participating entity types Binary, ternary Relationships as attributes Think of a binary relationship type in terms of attributes Copyright 2011 Ramez Elmasri and Shamkant Navathe

13 Copyright 2011 Ramez Elmasri and Shamkant Navathe

14 Role Names and Recursive Relationships Role names and recursive relationships Role name signifies role that a participating entity plays in each relationship instance Recursive relationships Same entity type participates more than once in a relationship type in different roles Must specify role name Copyright 2011 Ramez Elmasri and Shamkant Navathe

15 Copyright 2011 Ramez Elmasri and Shamkant Navathe

16 Constraints on Binary Relationship Types Cardinality ratio for a binary relationship Specifies maximum number of relationship instances that entity can participate in Participation constraint Specifies whether existence of entity depends on its being related to another entity Types: total and partial Copyright 2011 Ramez Elmasri and Shamkant Navathe

17 Attributes of Relationship Types Attributes of 1:1 or 1:N relationship types can be migrated to one entity type For a 1:N relationship type Relationship attribute can be migrated only to entity type on N-side of relationship For M:N relationship types Some attributes may be determined by combination of participating entities Must be specified as relationship attributes Copyright 2011 Ramez Elmasri and Shamkant Navathe

18 Idea: E/R Data Model Existence Dependencies and Weak Entity Sets Existence of one entity depends on another Example: Loans and Loan Payments Loan Loan_Pmt Payment lno lamt pno pdate pamt Weak Entity Set Identifying Relationship Total Participation 1.18

19 E/R Data Model Existence Dependencies and Weak Entity Sets Loan Loan_Pmt Payment lno lamt pno pdate pamt Weak Entity Sets existence of payments depends upon loans have no superkeys: different payment records (for different loans) can be identical instead of keys, discriminators: discriminate between payments for given loan (e.g., pno) 1.19

20 E/R Data Model Existence Dependencies and Weak Entity Sets Loan Loan_Pmt Payment lno lamt pno pdate pamt Identifying Relationships We say: Loan is identifying owner in Loan_Pmt Payment is weak entity set in Loan_Pmt Payment is existence dependent on Loan 1.20

21 E/R Data Model Existence Dependencies and Weak Entity Sets Loan Loan_Pmt Payment lno lamt pno pdate pamt Total Participation All elements of Payment appear in Loan_Pmt 1.21

22 E/R Data Model Existence Dependencies and Weak Entity Sets E 1 R E 2 att a1... att am att b1... att bn Q. Is {att b1,, att bn } a superkey of E 2? A: No Q. Name a candidate key of E 2 A: {att a1, att b1 } 1.22

23 E/R Data Model Extensions to the Model: Specialization and Generalization An Example: Customers can have checking and savings accts Checking ~ Savings (many of the same attributes) Old Way: Customer Has 1 Savings Acct acct_no balance interest Has2 Checking Acct acct_no balance overdraft 1.23

24 E/R Data Model Extensions to the Model: Specialization and Generalization An Example: Customers can have checking and savings accts Checking ~ Savings (many of the same attributes) New Way: acct_no balance Customer Has Account superclass Isa Savings Acct Checking Acct interest overdraft 1.24 subclasses

25 E/R Data Model Extensions to the Model: Specialization and Generalization Subclass Distinctions: 1. User-Defined vs. Condition-Defined User: Membership in subclasses explicitly determined (e.g., Employee, Manager < Person) Condition: Membership predicate associated with subclasses - e.g: Person Isa Child Adult Senior age < 18 age 18 age

26 E/R Data Model Extensions to the Model: Specialization and Generalization Subclass Distinctions: 2. Overlapping vs. Disjoint Overlapping: Entities can belong to >1 entity set (e.g., Adult, Senior) Disjoint: Entities belong to exactly 1 entity set (e.g., Child) Person Isa Child Adult Senior age < 18 age 18 age

27 E/R Data Model Extensions to the Model: Specialization and Generalization Subclass Distinctions: 3. Total vs. Partial Membership Total: Every entity of superclass belongs to a subclass e.g., Person Isa Child Adult Senior age < 18 age 18 age 65 Partial: Some entities of superclass do not belong to any subclass (e.g., if Adults condition is age 21 ) 1.27

28 E/R Data Model Extensions to the Model: Aggregation E/R: No relationships between relationships E.g.: Associate loan officers with Borrows relationship set Customer Borrows? Loan_Officer Loan Employee Associate Loan Officer with Loan? What if we want a loan officer for every (customer, loan) pair? 1.28

29 E/R Data Model Extensions to the Model: Aggregation E/R: No relationships between relationships E.g.: Associate loan officers with Borrows relationship set Customer Borrows Loan Loan_Officer Employee Associate Loan Officer with Borrows? Must First Aggregate 1.29

30 Weak Entity Types Do not have key attributes of their own Identified by being related to specific entities from another entity type Identifying relationship Relates a weak entity type to its owner Always has a total participation constraint Copyright 2011 Ramez Elmasri and Shamkant Navathe

31 Refining the ER Design for the COMPANY Database Change attributes that represent relationships into relationship types Determine cardinality ratio and participation constraint of each relationship type Copyright 2011 Ramez Elmasri and Shamkant Navathe

32 ER Diagrams, Naming Conventions, and Design Issues Copyright 2011 Ramez Elmasri and Shamkant Navathe

33 Proper Naming of Schema Constructs Choose names that convey meanings attached to different constructs in schema Nouns give rise to entity type names Verbs indicate names of relationship types Choose binary relationship names to make ER diagram readable from left to right and from top to bottom Copyright 2011 Ramez Elmasri and Shamkant Navathe

34 Design Choices for ER Conceptual Design Model concept first as an attribute Refined into a relationship if attribute is a reference to another entity type Attribute that exists in several entity types may be elevated to an independent entity type Can also be applied in the inverse Copyright 2011 Ramez Elmasri and Shamkant Navathe

35 Alternative Notations for ER Diagrams Specify structural constraints on relationships Replaces cardinality ratio (1:1, 1:N, M:N) and single/double line notation for participation constraints Associate a pair of integer numbers (min, max) with each participation of an entity type E in a relationship type R, where 0 min max and max 1 Copyright 2011 Ramez Elmasri and Shamkant Navathe

36 Copyright 2011 Ramez Elmasri and Shamkant Navathe

37 Example of Other Notation: UML Class Diagrams UML methodology Used extensively in software design Many types of diagrams for various software design purposes UML class diagrams Entity in ER corresponds to an object in UML Copyright 2011 Ramez Elmasri and Shamkant Navathe

38 Copyright 2011 Ramez Elmasri and Shamkant Navathe

39 Example of Other Notation: UML Class Diagrams (cont d.) Class includes three sections: Top section gives the class name Middle section includes the attributes; Last section includes operations that can be applied to individual objects Copyright 2011 Ramez Elmasri and Shamkant Navathe

40 Example of Other Notation: UML Class Diagrams (cont d.) Associations: relationship types Relationship instances: links Binary association Represented as a line connecting participating classes May optionally have a name Link attribute Placed in a box connected to the association s line by a dashed line Copyright 2011 Ramez Elmasri and Shamkant Navathe

41 Example of Other Notation: UML Class Diagrams (cont d.) Multiplicities: min..max, asterisk (*) indicates no maximum limit on participation Types of relationships: association and aggregation Distinguish between unidirectional and bidirectional associations Model weak entities using qualified association Copyright 2011 Ramez Elmasri and Shamkant Navathe

42 Relationship Types of Degree Higher than Two Degree of a relationship type Number of participating entity types Binary Relationship type of degree two Ternary Relationship type of degree three Copyright 2011 Ramez Elmasri and Shamkant Navathe

43 Choosing between Binary and Ternary (or Higher-Degree) Relationships Some database design tools permit only binary relationships Ternary relationship must be represented as a weak entity type No partial key and three identifying relationships Represent ternary relationship as a regular entity type By introducing an artificial or surrogate key Copyright 2011 Ramez Elmasri and Shamkant Navathe

44 Copyright 2011 Ramez Elmasri and Shamkant Navathe

45 Constraints on Ternary (or Higher-Degree) Relationships Notations for specifying structural constraints on n-ary relationships Should both be used if it is important to fully specify structural constraints Copyright 2011 Ramez Elmasri and Shamkant Navathe

46 Summary Basic ER model concepts of entities and their attributes Different types of attributes Structural constraints on relationships ER diagrams represent E-R schemas UML class diagrams relate to ER modeling concepts Copyright 2011 Ramez Elmasri and Shamkant Navathe

47 E/R Data Model Summary Entities, Relationships (sets) Both can have attributes (simple, multivalued, derived, composite) Cardinality or relationship sets (1:1, n:1, n:m) Keys: superkeys, candidate keys, primary key DBA chooses primary key for entity sets Automatically determined for relationship sets Weak Entity Sets, Existence Dependence, Total/Partial Participation Specialization and Generalization (E/R + inheritance) Aggregation (E/R + higher-order relationships) 1.47

48 These things get pretty hairy! Many E-R diagrams cover entire walls! A modest example: 1.48

49 A Cadastral E-R Diagram cadastral: showing or recording property boundaries, subdivision lines, buildings, and related details Source: US Dept. Interior Bureau of Land Management, Federal Geographic Data Committee Cadastral Subcommittee

50 Group Activity (4-5 Each) + HW Consider the following set of requirements for a UNIVERSITY database that is used to keep track of students transcripts.this is similar but not identical to the database shown in Figure 1.2 See book for detailed requirements: Design an ER schema for this application, and draw an ER diagram for the schema. Specify key attributes of each entity type, and structural constraints on each relationship type. Note any unspecified requirements, and make appropriate assumptions to make the specification complete. HW 2: 2 parts - Group: Turn in your solution to Individually: Exercise 7.23 (page 237) Submit in class next week or via Moodle 1.50