Attributes. Entity-Relationship Model (ERM) IV. Entity Relationship Modeling. Entities and Attributes: Chen and Crow s Foot

Size: px

Start display at page:

Download "Attributes. Entity-Relationship Model (ERM) IV. Entity Relationship Modeling. Entities and Attributes: Chen and Crow s Foot"

Chester Horn
5 years ago
Views:

Recall previous definitions Entity refers to the entity set and not a single entity occurrence 2 Entity-Relationship odel (ER) Entities and s: Chen and Crow s Foot E-R diagrams are the deliverables

1 Entity-Relationship odel (ER) IV. Entity Relationship odeling Basis of an Entity-Relationship Diagram (ERD) A design technique Diagrams entities sets (with attributes) and the relationship between the entity sets. Recall previous definitions Entity refers to the entity set and not a single entity occurrence 2 Entity-Relationship odel (ER) Entities and s: Chen and Crow s Foot E-R diagrams are the deliverables of the design phase of information system development Depicts conceptual DB as viewed by end user We create an ERD to get agreement on the conceptual view, then we translate the ERD into the relational model for implementation 3 4 s Identifier: Primary key Composite identifier: composed of more than one attribute Composite attribute: that can be subdivided to yield additional attributes Simple attribute: that cannot be subdivided Single-valued attribute: that has only a single value ultivalued attributes: s that have many values 5 ultivalued in an Entity 6

Representing s Composite attributes s should be atomic Simple attribute for each field Customer (accountid, lastname, firstname, street, city, state, zipcode) ulti-valued attributes Represent as

Representing s Represent as several new attributes, one for each component of the original multivalued attribute Customer (accountid, lastname, firstname, street, city, state,

Apopka FL 30458 Judy Breaux 04 Breaux Carroll 76 ain St. Apopka FL 30458 Cyrus Lambeaux 04 Breaux Carroll 76 ain St.

2 Representing s Composite attributes s should be atomic Simple attribute for each field Customer (accountid, lastname, firstname, street, city, state, zipcode) ulti-valued attributes Represent as single-valued attribute? What s the key? Representing s Represent as several new attributes, one for each component of the original multivalued attribute Customer (accountid, lastname, firstname, street, city, state, zipcode,spouseuser,siblinguser,childuser) Represent as a separate table accountid lastname firstname street city state zipcode otheruser 04 Breaux Carroll 76 ain St. Apopka FL Judy Breaux 04 Breaux Carroll 76 ain St. Apopka FL Cyrus Lambeaux 04 Breaux Carroll 76 ain St. Apopka FL Jean Deaux accountid otheruser 04 Judy Breaux 04 Cyrus Lambeaux 04 Jean Deaux 7 8 Derived s Advantages and Disadvantages of Storing Derived s Derived attribute: whose value is calculated from other attributes Derived using an algorithm 9 0 Relationships Connectivity and Cardinality in an ERD Associations between entities that always operate in both directions Participants: Entities that participate in a relationship Connectivity: Describes the relationship classification Cardinality: Expresses the minimum and maximum number of entity occurrences associated with one occurrence of related entity 2 2

Relationship Participation Crow s Foot Symbols Also called modality constraints Optional participation ( may ) One entity occurrence does not require a corresponding entity occurrence in a particular

andatory Relationship 5 6 Review Associative Entities 7 Also known as composite or bridge entities Used to represent an :N relationship between two or more entities In the relational model, not

3 Relationship Participation Crow s Foot Symbols Also called modality constraints Optional participation ( may ) One entity occurrence does not require a corresponding entity occurrence in a particular relationship andatory participation ( must ) One entity occurrence requires a corresponding entity occurrence in a particular relationship 3 4 CLASS is Optional to COURSE COURSE and CLASS in a andatory Relationship 5 6 Review Associative Entities 7 Also known as composite or bridge entities Used to represent an :N relationship between two or more entities In the relational model, not necessarily the ER Is in a : relationship with the parent entities Composed of the primary key attributes of each parent entity ay also contain additional attributes that play no role in connective process Intersection data 8 3

Representing a :N Relationship in the Relational odel A Composite Entity in an ERD 9 20 Relationship Degree Three Types of Relationship Degree in the ER Indicates

Relationship exists between occurrences of the same entity set Binary relationship: Two entities are associated Ternary relationship: Three entities are associated

several salespersons reporting to him. There is a one-to-many relationship within salespersons.

Taylor 8 992 439 86 Adams 5 200 98 Wang 20 990 267 204 Dickens 0 998 267 267 Perez 22 2000 285 285 Costello 0 996 323 cnamara 5 995 37 36 Carlyle 20 200 483 388

4 Representing a :N Relationship in the Relational odel A Composite Entity in an ERD 9 20 Relationship Degree Three Types of Relationship Degree in the ER Indicates the number of entities or participants associated with a relationship Unary relationship: Association is maintained within a single entity Recursive relationship: Relationship exists between occurrences of the same entity set Binary relationship: Two entities are associated Ternary relationship: Three entities are associated 2 22 Unary One-to-any Relationships A salesperson reports to exactly one sales manager, but each salesperson who does serve as a sales manager typically has several salespersons reporting to him. There is a one-to-many relationship within salespersons. (also a sales manager) 23 One-to-any Unary Relationship Number Name Commission Percentage Year Of Hire Sales anager Number 37 Baker Smith Taylor Adams Wang Dickens Perez Costello cnamara Carlyle Goldberg Davidson Warren Albert Jones SALESPERSON Relation Requires the addition of one column to the relation representing the single entity involved in the unary relationship. 24 4

General Hardware Company s Product Set odified Product Relation Wrench ode l A (#) Deluxe Wrench Set (#43) Wrench ode l B (#4 ) Supreme Tool Set (#53) Wrench ode l C (#7) aster Wrench Set (#44)

produ ct bill of materials. Tools and sets of tools are sold. any-to-many nature of products. Also: prerequisite example from Oracle lab 25 Product Number Product Name Unit Price Wrench odel A 2.

95 44 aster Wrench Set 35.00 48 Deluxe Hammer Set 5.00 53 Supreme Tool Set 00.00 56 Grand Tool Set 09.95 PRODUCT relation Product Numbers have been reduced to 2 digits for simplicity.

26 Unary any-to-any Relationship: New Relation Ternary Relationships Assembly Part 43 43 4 44 44 7 44 9 48 22 48 24 48 28 53 43 53 48 53 3 56 44 56 48 56 35 Just as a binary many-to-many relationship

5 General Hardware Company s Product Set odified Product Relation Wrench ode l A (#) Deluxe Wrench Set (#43) Wrench ode l B (#4 ) Supreme Tool Set (#53) Wrench ode l C (#7) aster Wrench Set (#44) Wrench ode l D (#9) Hammer odel A (#22) Grand Tool Hammer odel B (#24) Deluxe Hammer Set (#48) Set (#56) Hammer odel C (#28) Drill od el A (#3 ) Drill od el B (#35 ) Figure 6.5 General Hardware Co. produ ct bill of materials. Tools and sets of tools are sold. any-to-many nature of products. Also: prerequisite example from Oracle lab 25 Product Number Product Name Unit Price Wrench odel A Wrench odel B Wrench odel C.62 9 Wrench odel D Hammer odel A Hammer odel B Hammer odel C Drill odel A Drill odel B Deluxe Wrench Set aster Wrench Set Deluxe Hammer Set Supreme Tool Set Grand Tool Set PRODUCT relation Product Numbers have been reduced to 2 digits for simplicity. Every individual unit item and every set of tools has its own row in the relation because every item and set is available for sale. 26 Unary any-to-any Relationship: New Relation Ternary Relationships Assembly Part Just as a binary many-to-many relationship requires the creation of an additional relation in a relational database, so does a unary many-tomany relationship Both Assembly and Part are foreign keys linking to the Product Number column of the PRODUCT relation 27 Involves three different entity types. 28 General Hardware Co.: Ternary Relationship Number Name Commission Percentage Year Of Hire 37 Baker Adams Dickens Carlyle (a) SALESPERSON relation. Customer Customer Number Name HQ City 02 ain St. Hardware New York 0839 Jane s Stores Chicago 0933 ABC Home Stores Los Angeles 047 Acme Hardware Store Los Angeles 525 Fred s Tool Stores Atlanta 700 XYZ Stores Washington 826 City Hardware New York 298 Western Hardware New York 2267 Central Stores New York (b) CUSTOER relation Product Product Unit Number Name Price 6386 Wrench Hammer Drill Saw Pliers.50 (c) PRODUCT relation. Customer Product Number Number Number Date Quantity /2/ /27/ // // /2/ /7/ /2/ /03/ /7/ (d) SALES relation. 29 Existence Dependence Existence dependence Existence independence Entity exists in the Entity exists apart from database only when it all of its related entities is associated with Referred to as a strong another related entity entity or regular occurrence entity 30 5

Weak Entity Also called a dependent entity Conditions Existence-dependent Has a primary key that is partially or totally derived from parent entity in the

defined by relationship to owner class Customer Distinguished by a diagonal hash mark in each corner of its attribute area.

Hardware 37 New York 0839 Jane s Stores 86 Chicago 0933 ABC Home Stores 37 Los Angeles 047 Acme Hardware Store 37 Los Angeles 525 Fred s Tool Stores 36 Atlanta 700

Customer Employee Employee Number Number Name Title 02 27498 Smith Co-Owner 02 3044 Garcia Co-Owner 0933 25270 Chen VP Sales 0933 3044 Levy Sales anager 0933 48285

6 Weak Entity Also called a dependent entity Conditions Existence-dependent Has a primary key that is partially or totally derived from parent entity in the relationship Database designer determines whether an entity is weak based on business rules 3 odeling Weak Entities Customer Employee has no key of its own Is defined by relationship to owner class Customer Distinguished by a diagonal hash mark in each corner of its attribute area. Employee Number is a discriminator, or partial key Implementing Weak Entities Another Example Customer Customer Number Name Number HQ City 02 ain St. Hardware 37 New York 0839 Jane s Stores 86 Chicago 0933 ABC Home Stores 37 Los Angeles 047 Acme Hardware Store 37 Los Angeles 525 Fred s Tool Stores 36 Atlanta 700 XYZ Stores 36 Washington 826 City Hardware 37 New York 298 Western Hardware 204 New York 2267 Central Stores 86 New York CUSTOER relation. Customer Employee Employee Number Number Name Title Smith Co-Owner Garcia Co-Owner Chen VP Sales Levy Sales anager orton President Baker Sales anager Smith President Jones VP Sales Garcia VP Personnel Kaplan Senior Accountant CUSTOER EPLOYEE relation. Customer Customer Employee In the Relational odel Good Reading Bookstores

Good Reading Bookstores Publisher Year Name City Country Telephone Founded PUBLISHER Relation World usic Association Author Author Year Year Number Name Born Died AUTHOR Relation Book Book

Number Number Date Price Quantity SALE Relation 37 38 World usic Association Orchestra usic Name City Country Director ORCHESTRA Relation Lucky Rent-A-Car usician usician Annual Orchestra Number Name

Relation Orchestra Composition Composer Name Name Name Year Price RECORDING Relation 39 40 Lucky Rent-A-Car anufacturer anufacturer Sales Rep Sales Rep Name Country Name Telephone ANUFACTURER

7 Good Reading Bookstores Publisher Year Name City Country Telephone Founded PUBLISHER Relation World usic Association Author Author Year Year Number Name Born Died AUTHOR Relation Book Book Publication Publisher Number Name Year Pages Name BOOK Relation Customer Customer Number Name Street City State Country CUSTOER Relation Book Author Number Number WRITING Relation Book Customer Number Number Date Price Quantity SALE Relation World usic Association Orchestra usic Name City Country Director ORCHESTRA Relation Lucky Rent-A-Car usician usician Annual Orchestra Number Name Instrument Salary Name USICIAN Relation usician Number Degree University Year DEGREE Relation Composer Date Of Name Country Birth COPOSER Relation Composition Composer Name Name Year COPOSITION Relation Orchestra Composition Composer Name Name Name Year Price RECORDING Relation Lucky Rent-A-Car anufacturer anufacturer Sales Rep Sales Rep Name Country Name Telephone ANUFACTURER Relation Car Serial anufacturer Number odel Year Class Name CAR Relation Repair Car Serial Repair Number Number Date Procedure ileage Time AINTENANCE Relation Customer Customer Customer Customer Number Name Address Telephone CUSTOER Relation Car Serial Customer Number Number RENTAL Relation Rental Date Return Date Total Cost 4 Developing an ER Diagram Create a detailed narrative of the organization s description of operations Identify business rules based on the descriptions Identify main entities and relationships from the business rules Develop the initial ERD Identify the attributes and primary keys that adequately describe entities Revise and review ERD 42 7

8 Partial DVD Store ER model Design issue lastname balance otherusers ulti-valued firstname Customer Relationship Type accountid Rents Key videotapeid title genre Entity Class Videotape Should Rental be an entity class? instead of relationship type Rents A rental entity represents the possession of a DVD by a customer numberrentals address datedue cost date rating Acquired daterented length street zipcode Cardinality Derived Composite Constraint city state Customer Has Rental Has Videotape datedue daterented cost Subtleties in eaning PurchaseOrder Orders Videotape quantity Id date linenumber PurchaseOrder PurchaseOrder Has quantity Detail unitcost Buys Orders From videoid movieid Is Supplier title ovie Copy Of genre name address date length rating Acquired date Acquired Videotape 45 ore design issues Entity set vs. attribute E.g., telephones, dependents vs. relationship type E.g., customer/account Entity set vs. relationship type E.g., loans, rentals Faithfulness to real world data E.g., purchase order, many more 46 8

Relational Database Model. III. Introduction to the Relational Database Model. Relational Database Model. Relational Terminology.

Relational Database Model. III. Introduction to the Relational Database Model. Relational Database Model. Relational Terminology. III. Introduction to the Relational Database Model Relational Database Model In 1970, E. F. Codd published A Relational Model of Data for Large Shared Data Banks in CACM. In the early 1980s, commercially