+ All Categories
Home > Documents > 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Date post: 04-Jan-2016
Category:
Upload: quentin-melton
View: 216 times
Download: 1 times
Share this document with a friend
32
3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3
Transcript
Page 1: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

3 & 4

1

Chapters 3 and 4Drawing ERDs

October 16, 2006

Week 3

Page 2: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

2

Practice … (correction)

• Each of the MegaCo Corporation’s divisions is composed of many departments. Each of those departments has many employees assigned to it, but each employee works for only one department. Each department is managed by one employee, and each of those managers can manage only one department at a time.

EMPLOYEE

is assigned to

M

1DEPARTMENT

manages

1

1

DIVISION1M

is composed of

Page 3: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

3

A little from Chapters 3 and 4

• Good design begins by identifying appropriate entities and attributes and the relationships among the entities

• Chapter 3: Section 3.2 Keys (pages 64-69)

• Chapter 4 All

Page 4: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

4

The Entity Relationship Diagram (ERD)

• ERD represents the conceptual database as viewed by end user

• ERDs depict the ER model’s three main components:

– Entities - anything about which data are to be collected and stored (i.e. people, events)

– Attributes - characteristics of an entity

– Relationships - describe an association among (two or more) entities (1:1, 1:M, M:N)

Page 5: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

5

Tables and Keys

• Tables are basic building blocks of a relational database

• Keys are central to the use of relational tables

Page 6: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

6

Tables and Their Characteristics

Page 7: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

7

Keys

• Consists of one or more attributes that determine other attributes

• Primary key (PK) is an attribute (or a combination of attributes) that uniquely identifies any given row– Composite key - Composed of more than one attribute

• Foreign key (FK) – An attribute whose values match primary key values in

the related table

• Key’s role is based on determination– If you know the value of attribute A, you can look up

(determine) the value of attribute B

Page 8: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

8

Keys (continued)

Page 9: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

9

Keys (continued)• Nulls:

– No data entry– Not permitted in primary key– Should be avoided in other attributes– Can represent

• An unknown attribute value• A known, but missing, attribute value• A “not applicable” condition

– Can create problems when functions such as COUNT, AVERAGE, and SUM are used

– Can create logical problems when relational tables are linked

Page 10: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

10

Keys (continued)

Page 11: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

11

Entities and Instances

• Each entity ultimately becomes a table in a database implementation

• Each instance of an entity is a record or a row in a table in a database

• Entity name, a noun, is usually written in capital letters

STUDENT

Page 12: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

12

Attributes

• Attributes ultimately become the fields in a database implementation

• Attributes are represented by ovals and are connected to entity rectangle with a line

• Primary Key is underlined in the ERD

Page 13: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

13

Types of Attributes

• Key attribute is a unique identifier

• Composite attribute can be subdivided

• Simple attribute cannot be subdivided

• Single-value attribute can have only a single value

• Multivalued attributes can have many values– A student may have more that one phone number; a home-

phone number and a mobile-phone number

• Derived attribute’s value may be calculated (derived) from other attributes– Need not be physically stored in a database

Page 14: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

14

Multivalued Attributes

Represented by a double line

Page 15: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

15

Resolving Multivalued Attribute Problems

• Although conceptual model can handle M:N relationships and multivalued attributes, you should not implement them in relational DBMS– Within original entity, create several new

attributes, one for each of the original multivalued attribute’s components

• Can lead to major structural problems in table

– Create new entity composed of original multivalued attribute’s components

Page 16: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

16

Resolving Multivalued Attribute Problems (continued)

Page 17: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

17

Derived Attributes (continued)

Represented by a dashed line

Page 18: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

18

Connectivity and Cardinality

• Connectivity– Used to describe the relationship classification

(based on participation)

• Cardinality – Expresses minimum and maximum number of

entity occurrences associated with one occurrence of related entity

• Established by very concise statements known as business rules

Page 19: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

19

EMPLOYEE is assigned to PROJECT

M N

Cardinality

Connectivity

Page 20: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

20

Relationship Participation

• Optional participation– One entity occurrence does not require

corresponding entity occurrence in particular relationship

• Mandatory participation– One entity occurrence requires corresponding

entity occurrence in particular relationship

Page 21: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

21

Relationship Strength

• Weak (non-identifying) relationships– Exists if PK of related entity does not contain

PK component of parent entity

• Strong (Identifying) Relationships– Exists when PK of related entity contains PK

component of parent entity

Page 22: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

22

Weak (Non-Identifying) Relationships

Page 23: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

23

Strong (Identifying) Relationships

Page 24: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

24

Weak Entities

• Weak entity meets two conditions– Existence-dependent

• Cannot exist without entity with which it has a relationship

– Has primary key that is partially or totally derived from parent entity in relationship

• Database designer usually determines whether an entity can be described as weak based on business rules

Page 25: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

25

Weak Entities (continued)

Page 26: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

26

Relationship Degree

• Indicates number of entities or participants associated with a relationship

• Unary relationship– Association is maintained within single entity

• Binary relationship – Two entities are associated

• Ternary relationship – Three entities are associated

Page 27: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

27

Relationship Degree (continued)

Page 28: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

28

Composite Entities

• Also known as bridge entities

• Composed of primary keys of each of the entities to be connected

• May also contain additional attributes that play no role in connective process

• Used to resolve M:N relationships

Page 29: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

29Source: http://io.uwinnipeg.ca/~rmcfadye/2914/ERD/images/1entit4.gif

Mandatory participation

1, N, M

Page 30: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

30

Practice ...

• An airplane has a registration number, type, number of economy class seats, number of business class seats and the year of production

Page 31: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

31

Practice ...

• Each text book has a unique ISBN (International Standard Book Number), and contains several chapters. Each chapter has a chapter number (unique within a book), the number of pages and the number of references. A chapter covers a single topic, but the same topic may be covered in various books.

Page 32: 3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

3 & 4

32

Practice ...

• Sometimes students work in groups. Each group has a unique number and students have their student ids. A student who works in a group has a specific role within that group. The student may have different roles in various groups he/she belongs to.


Recommended