databaseim isu1 fundamentals of database systems chapter 3 data modeling using entity-relationship...

IM ISU 1Database

Fundamentals of Database Systems

Chapter 3

Data Modeling Using Entity-Relationship Model

IM ISU 2Database

Database Design Process

Two main activities: Database design Applications design

Focus in this chapter on database design To design the conceptual schema for a database

application

Applications design focuses on the programs and interfaces that access the database Generally considered part of software engineering

IM ISU 3Database

Database Design Process (cont.) Requirements collection and analysis

The database designers interview prospective database users

The result is data requirement

Functional analysis Specify the known functional requirements of

the application Consist of user-defined operations, such as

retrievals and updates

IM ISU 4Database

Database Design Process (cont.)

Conceptual design Specify concisely the data requirement of the users,

such as entity types, relationships, and constraints Use high-level conceptual data model, e.g., Entity-R

elationship model Used as a reference to communicate with nontechni

cal users Modifications to the conceptual schema can be intro

duced when some functional requirements cannot be specified

IM ISU 5Database

Database Design Process (cont.)

Logical design (data model mapping) Refer to the actual implementation of the

database using a commercial DBMS Need to transform the conceptual data model

into the implementation data model, e.g., relational model

Physical design Specify the internal storage structures, access

paths, and file organizations

IM ISU 6Database

IM ISU 7Database

Example Database

An COMPANY database The company is organized into departments Each department controls several projects Need to keep track all employee and their

working hours Need to keep track of the dependents of each

employee

IM ISU 8Database

Example Database (cont.)

IM ISU 9Database

ER Model Concepts

Entities and Attributes Entities are specific objects or things in the m

ini-world, e.g., EMPLOYEE John Smith Attributes are properties used to describe an

entity, e.g., Name, SSN, Address, Sex, BirthDate for EMPLOYEE

A specific entity will have a value for each of its attributes, e.g, Name = ‘John Smith’

IM ISU 10Database

ER Model Concepts (cont.)

Two example entities

IM ISU 11Database


Types of attributes Simple vs Composite

» Each entity has a single atomic value for the attribute, e.g., SSN

» Composite attributes may be composed of several components, e.g., address, and may form a hierarchy

Single-valued vs Multi-valued» Most attributes are single-valued, but some attrib

utes may have multiple values, e.g., Expert

IM ISU 12Database

ER Model Concepts (cont.) An example hierarchy of composite attributes

IM ISU 13Database


Stored vs Derived» In some case, two (or more) attributes are related» Age (derived attribute) can be derived from the B

irthDate attribute (stored attribute)

Complex » In general, composite and multi-valued attributes

may be nested arbitrarily » e.g., AddressPhone for a person

IM ISU 14Database


Entity Types and Key Attributes Entities with the same basic attributes are gro

uped or typed into an entity type, e.g, EMPLOYEE type

Key attribute» An attribute for which each entity must have a un

ique value, e.g, SSN for EMPLOYEE» A key attribute may be composite» An entity type may have more than one key attrib

utes, e.g, VehicleId, Registration

IM ISU 15Database


IM ISU 16Database


IM ISU 17Database

Displaying an Entity type

In ER diagrams, an entity type is displayed in a rectangular box

Attributes are displayed in ovals Each attribute is connected to its entity type Components of a composite attribute are connected

to the oval representing the composite attribute Each key attribute is underlined Multivalued attributes displayed in double ovals

IM ISU 18Database

Displaying an Entity type (cont.)

Example diagram for CAR entity type

IM ISU 19Database

Entity Set

Each entity type will have a collection of entities stored in the database Called the entity set e.g, entity set for CAR

Same name (CAR) used to refer to both the entity type and the entity set

Entity set is the current state of the entities of that type that are stored in the database

IM ISU 20Database

ER Model Concepts – Relationships

Relationships and Relationship Types A relationship relates two or more distinct ent

ities with a specific meaning » e.g, EMPLOYEE John Smith works on ProductX

PROJECT

Relationships of the same type are grouped or typed into a relationship type

IM ISU 21Database


(cont.)

IM ISU 22Database


(cont.) Degree of a relationship type: the number of

participating entity types» e.g., WORKS_FOR is a binary relationship,

SUPPLY is a ternary relationship

A relationship type can be represented as attributes» e.g., WORKS_FOR relationship =>

Department of EMPLOYEE or

Employees of DEPARTMENT

IM ISU 23Database


(cont.)

IM ISU 24Database


(cont.) Recursive relationships: A relationship relate t

wo entities of the same entity type (participates in different roles)» e.g., SUPERVISION: relates relates one EMPLO

YEE (in the role of supervisee) to another EMPLOYEE (in the role of supervisor)

A relationship type can have attributes» e.g., HoursPerWeek of WORKS_ON

IM ISU 25Database


(cont.)

IM ISU 26Database


(cont.) Structural constraints on relationships

Cardinality ratio (of a binary relationship)» Specify the number of relationship instances that an

entity can participate in» 1:1, 1:N, N:1, or M:N (e.g., WORKS_ON)

Participation constraint (on each participating entity type)

» Specifies whether the existence of an entity depends on another entity

» Two different types– Total (called existence dependency), e.g.,

EMPLOYEE in WORKS_FOR– Partial, e.g., EMPLOYEE in MANAGES

IM ISU 27Database


(cont.)

IM ISU 28Database


(cont.)

IM ISU 29Database


Weak entity types Entity types that does not have a key attribute Entity types that have a key attribute are

called regular (or strong) entity types A weak entity type must participate in an

identifying relationship type with an owner (identifying entity type)

A weak entity type always has a total participation constraint

IM ISU 30Database


Example» Suppose that a DEPENDENT entity is identified

by – the dependent's first name and birthdate

– the specific EMPLOYEE the dependent is related to

» DEPENDENT is a weak entity type– EMPLOYEE as its identifying entity type

– via the identifying relationship type DEPENDENT_OF

IM ISU 31Database

Notation Summary for ER Diagrams

IM ISU 32Database

Notation Summary for ER Diagrams (cont.)

IM ISU 33Database

Notation Summary for ER Diagrams (cont.)

IM ISU 34Database

Alternative Notation for ER Diagrams

Alternative notation for relationship structural constraints Associate (min, max) with each participation

of an entity type E in a relationship type R» Each entity e in E participates in at least (min)

and at most (max) relationship instances in R» Default (no constraint): min = 0, max = n» Must have 0 < min < max, max > 1» min = 0 implies partial, min > 0 implies total

IM ISU 35Database

Alternative Notation for ER Diagrams (cont.)

Read the min,max numbers next to the entity type and looking away from the entity type

IM ISU 36Database

Notation for ER Diagrams (cont.)

IM ISU 37Database

ER Conceptual Design Design Paradigm

Initial design» Identify all entity types and their attributes

Iterative refinement» Refine the attribute that are reference to another

entity into a relationship» An attribute in several entity types may be

refined into its own entity type – e.g., Department in STUDENT, INSTRUCTOR, and

COURSE» An inverse refinement to the previous case may

be applied

IM ISU 38Database

ER Conceptual Design (cont.)

Example: An company database Initial design

IM ISU 39Database

IM ISU 40Database

ER Conceptual Design (cont.) Refinement

We specify the following relationship types» MANAGES, 1:1 (EMPLOYEE:DEPARTMENT)» WORKS_FOR, 1:N (DEPARTMENT:

EMPLOYEE)» CONTROLS, 1:N (DEPARTMENT:PROJECT) » SUPERVISION, 1:N (EMPLOYEE:EMPLOYEE)» WORKS_ON, M:N (EMPLOYEE:PROJECT) » DEPENDENTS_OF, 1:N (EMPLOYEE:

DEPENDENT)

IM ISU 41Database

ER Conceptual Design (cont.) In the refined design, some attributes from the

initial entity types are refined into relationships: Manager of DEPARTMENT -> MANAGES Works_on of EMPLOYEE -> WORKS_ON Department of EMPLOYEE -> WORKS_FOR

In general, more than one relationship type can exist between the same participating entity types relationship types MANAGES and WORKS_FOR

between EMPLOYEE and DEPARTMENT

IM ISU 42Database

Higher Degree Relationship

Binary relationship vs ternary (or n-ary) relationship A ternary relationship type three binary relat

ionship types cp. Fig. 4.13, (s, p), (j, p), (s, j) (s, j, p) In general, a ternary relationship type represent

s more information than do three binary relationship types» e.g., quantity, supply date

IM ISU 43Database

Higher Degree Relationship (cont.)

IM ISU 44Database


In case that only binary relationships are permitted, a ternary relationship must be » represented as a weak entity type with no partial

key, and » with three identifying relationships

It is often tricky to decide when to use binary or n-degree relationship representation

IM ISU 45Database


IM ISU 46Database


» (i, c, s) => (i, c), (i, s), (c, s)» (i, c), (i, s), (c, s) (i, c, s)

IM ISU 47Database


Constraints on ternary (or n-ary) relationships Cardinality ratio Participation constraint

» Partial» Total

(min, max) notation

IM ISU 48Database

Chapter Summary

ER Model Concepts: Entities, attributes, relationships

Constraints in the ER model Using ER in step-by-step conceptual schema

design for the COMPANY database ER Diagrams - Notation Alternative Notations

databaseim isu1 fundamentals of database systems chapter 3 data modeling using entity-relationship...

Documents