Database Conceptual Design using Entity Relationship Diagram

J.G. ZhengFeb 2010

CIS 8040Database Management Systems

2

Overview

Conceptual modeling/design

Using Entity Relationship Diagram (ERD) Basic Extended

Design/modeling considerations

Data dictionary

Three Level Database Design

Conceptual design Using Entity Relationship Diagram

(ERD) to represent the reality and business data requirements

Logical designPhysical design

3

Conceptual design

Conceptual modeling/data modelingUsually using diagram to visually represent the model ERD

4

5

Entity-Relationship Model

Proposed by Dr. Peter Chen in 1970s http://en.wikipedia.org/wiki/Peter_Che

n

ERD is a conceptual model

Major elements Entity (with attributes and identifier) Relationship

6

Entity and Attribute

Entity Entity class (entity set) Entity instance

Attribute

Identifier

7

Entity Notation in ERD

Note: there are several variations of ERD notations. Any one is fine – just be consistent.

Modeling Consideration 1

Attribute, attributes or entity? “Person Name” “Transaction Date” “Address” “ZIP” “State” “Department” “Skill”

8

Modeling Consideration 2

Attribute or attribute values?

How to model the following scenario? Contacts

An sales person can be contacted by “Fax Number”, “Cell Phone Number”, “Home Phone Number”, “Work Phone Number”, “Work Email”, etc.

Advising Hours Faculty members have specific advising hours on 5 week

days: “Monday”, “Tuesday”, etc.

Entity-attribute-value model http://en.wikipedia.org/wiki/Entity-attribute-value_model

9

10

ERD Exercise 1Draw a ERD (only entities and attributes) about movies

Sample dataMovie: Mission ImpossibleDirector: Brian De PalmaRelease Date: 22 May 1996Genre: ActionProduction: Paramount Pictures (USA)Actor/ess: Tom Cruise (male), Jon Voight

(male)

11

Relationship

Degree of relationship How many entities are

involved?

Binary (two entities) relationship is most common

Books Publisherspublishes

Unary Relationship

Unary (recursive) – only 1 entity

Employee Customer

Supervises Refers

12

ForumPost

replies

Ternary Relationship

Ternary – 3 entities

13

N’ary Relationship

4 entitiesPhysician

OperatesPatient Nurse

Supplies

14

Modeling Consideration 3

Multiple independent relationships?

Faculty StudentTeaches

Advises

Employee MentorsSupervises

15

Modeling Consideration 4

3 binary relationships or a ternary one?

Database Modeling and Design: Logical Design, 4th Edition by Toby J. Teorey, Sam S. Lightstone, and Tom Nadeau, 2005

16

Modeling Consideration 4 (continued)

3 binary relationships or a ternary one?

Movie Actor/essAct in

Characterhas Act as

17

Movie Actor/essAct as … in …

Character

18

Types of Relationship (1)

One-to-One (1:1) A single entity instance in one entity class is

related to a single entity instance in another entity class

ER Notation (Crow’s foot)

Governor Stategoverns

19

Types of Relationship (2)

One-to-Many (1:N) A single entity instance in one entity class

(parent) is related to multiple entity instances in another entity class (child)

ER Notation (Crow’s foot)

Books Publisherspublish

20

Types of Relationship (3)

Many-to-Many (N:M) Each entity instance in one entity class is

related to multiple entity instances in another entity class; and vice versa

ER Notation (Crow’s foot)

Books Authorswrite

21

CardinalityCardinality Describes participation in the relationship

Maximum cardinalities (types of relationships)

Minimum cardinalities describes the minimum number of instances that

must participate in a relationship Optional (zero) or Mandatory (one)

Certificates Programmershave

22

ERD Exercise 2Movie data continued …

Let’s only consider the following entities and their attributes

Perfomers: PerformerID, FirstName, LastName, Gender

Movies: MovieID, Title, Maker, Year MovieMakers(companies): MakerID, Name

Assumptions (business rules) A movie has at least one actor/actress An actor/actress does not have to be in any movie A company does not have to make any movie A movie does not have to be made by a company

23

Modeling Consideration 5

Attributes of a relationship?

Relationship as an entity?

Modeling Consideration 6

Movie Actor/essActs in

Movie Actor/essCast

24

25

ERD Exercise 3

Movie data continued …

Now considering this Tom Cruise acts as Ethan Hunt in “Mission

Impossible”.

Let’s consider more information about “Ethan Hunt” “Ethan Hunt”: male, fiction figure, agent,

etc.

ERD: Extended

More on entity Strong vs. weak entity

More on relationship Generalization

26

Weak Entity

The existence of such entity has no real business (logical) meaning without another entity (owning entity) Requires the participation from the owning entity

(minimum cardinality is 1)

27

Employee hasDependen

t

Building has Room

ID Dependency

Weak entity’s identifier relies on its owning entity (or indentifying entity)’s identifier

28

Building Id hasBuilding Id

Room Number

Building Room

Modeling Consideration 7

Weak entity or not? Many argues that weak entity is not

important in database modeling

29

Building Id hasBuilding Id

Room Number

Building Room

Building Id has Room Number

Building Room

Super and Sub Types

A Sub-type is a special case, or a category, of a Super-type Student : Graduates, Undergraduates Employee : full-time, part-time, contractor Customer : individual, company, non-profit

30

Sub-Type Completeness

Completeness Do all super type instances appear in

any sub-type entities?

31

Participant

Organization Individual

Employee

Student Employee

Sub-Type Disjointness

Disjointness: does any instance appear in multiple subtype entities? Yes: Overlap (Inclusive) No: Disjoint (Exclusive)

32

Modeling Consideration 8

When to use sub-type (specification)? There are attributes that apply to some (but not all) of

the instances of an entity type

33

Modeling Consideration 8 (continued)

When to use (specification)? The instances of a subtype participate in a

relationship unique to that subtype

34

Modeling Consideration 9

When to use super-type (generalization)? When several entities have same major attributes,

see if they are constantly treated together. Faculty, staff, student assistant Employee, customer, business partner (or, supplier)

Multiple entities participate in the same relationship with the same entity (also see modeling trap 3)

35

Donation OrganizationMade by

IndividualMade by

ERD Exercise 4

Type of people in GSU Student: full time, part time, graduate,

undergraduate, current, prospective, etc. Student employee: student assistant, GRA,

GTA, etc. Faculty: tenured, tenure track, visiting, PTI,

non-teaching Staff: full time, part time, admin Alumni Other: parents, family member, emergency

contact, etc.36

Modeling Trap 1

Avoid the Fan Trap

Ambiguous (broken) relationship between Department and Staff

37

Modeling Trap 2

Avoid the Chasm Trap See modeling consideration 3

Ambiguous (broken) relationship between Branch and Property

38

Modeling Consideration 10

Redundant relationship? A relationship is redundant if it is

represented by alternate transitive relationships

Department Studentadmits

Programoffers admits

39

Modeling Consideration 10 (continued)

From: Database Modeling and Design: Logical Design, 4th Edition by Toby J. Teorey, Sam S. Lightstone, and Tom Nadeau, 2005

40

Modeling Trap 3*

Avoid the same (identical) relationship with multiple entities See modeling consideration 10

41

Donation OrganizationMade by

IndividualMade by

Analysis and Modeling Tips

Modeling is an iterative refinement process Start with basic and obvious facts or concepts; then let entities,

attributes, and relationships eventually emerge. Identify binary relationships and maximum cardinality first. Identify minimum cardinality and check for common modeling traps;

consider n’ery relationships if necessary; check for redundant relationships and missing relationships.

Add, combine, or split entities and attributes as needed. Check relationships and constraints after changes.

Start with specific function areas (user views) and integrate them later

View integration

Ensure the consistency between requirements, ERD and the data dictionary

42

Data Dictionary

A document that records detailed descriptions of data requirements and all ERD elements

Practically, it should include: Definitions (detailed description) for entities,

attributes and relationships Business rules (constraints, assumptions or other

requirements) and justifications that support the design of entities, attributes and relationships Data type, domain values, etc. – see database project

deliverable #1

43

Key Concepts

ERDEntity Strong vs. weak entity

Attribute and identifierRelationship 1:1, 1:N, N:M Degree

Unary, binary, ternary, etc. Cardinality Super- and sub-types

Completeness and disjointness

Data dictionary44

45

Summary of Modeling Guidelines

Modeling considerations1. Attribute(s) or entity?2. Attributes or attribute values?3. Multiple independent relationships?4. Ternary or multiple binary relationships?5. Attributes of a relationship?6. Relationship or entity?7. Weak entity or not?8. Sub-type or not?9. Super-type or not?10. Redundant relationships?

Modeling traps1. Fan trap 2. Chasm trap3. Same relationship with other multiple entities