E-R Diagram

Bagian I

Entity Concept

Database Desain

Conceptual

perspective

User’s perspective

Database

Requirements

Logical

Schema

(Relational)

Conceptual

Design

The Entity

Relationalship (ER)

Model is one of the

most widely used

mthod for

conceptual design

Logical

Design

(Mapping)

Conceptual

Schema

(ER)

The Relational Model

is the basic for

several commercial

DBMSs

Internal

Schema

Phases of Database Design

• First step of the design process is to identify the “Universe of Discourse” (UoD)

• The database to be built will not model everything in the world, but rather some “mini-world” or “Universe of Discourse”.

• The UoD is the relevant portion of the real world to be modeled by the database

3

Universe

of Discourse

Phases of Database Design

• Functional Analysis consists of specifying operations (retrievals, updates) that will be applied to the database

• Various techniques for software design exist, such as sequence diagrams, flowcharts, DFDs, etc.

• Refer to Software Engineering Texts

4

Universe

of Discourse

REQUIREMENTS

COLLECTION

AND ANALYSIS

FUNCTIONAL

ANALYSIS

APPLICATION

PROGRAM

DESIGN

..

.

Phases of Database Design

• Description of the data requirements of users

• Expressed using a high level model such as ENTITY-RELATIONSHIP (ER)

• A database schema in the ER Model can be represented pictorially (ER diagrams)

• ER Model contains detailed descriptions of:

What are the entities and relationships in the enterprise?

What information about these entities and relationships should we store in the database?

What are the integrity constraints or business rules that hold?

5

Universe

of Discourse

REQUIREMENTS

COLLECTION

AND ANALYSIS

FUNCTIONAL

ANALYSIS

APPLICATION

PROGRAM

DESIGN

..

.

CONCEPTUAL

DESIGN

Phases of Database Design

• Actual implementation of the database, using a commercial DBMS

• Depends on the logical/implementation model of the DBMS, for example Relational Database Model, Object Oriented Database Model.

• Conceptual Model (ER) is mapped to the implementation model (Relational) in this phase

6

Universe

of Discourse

REQUIREMENTS

COLLECTION

AND ANALYSIS

FUNCTIONAL

ANALYSIS

APPLICATION

PROGRAM

DESIGN

..

.

CONCEPTUAL

DESIGN

LOGICAL

DESIGN

Phases of Database Design

• Database is tuned for storage and performance

• Includes specification of storage structures, access paths, file organization etc.

7

Universe

of Discourse

REQUIREMENTS

COLLECTION

AND ANALYSIS

FUNCTIONAL

ANALYSIS

APPLICATION

PROGRAM

DESIGN

..

.

CONCEPTUAL

DESIGN

LOGICAL

DESIGN

PHYSICAL

DESIGN

Phases of Database Design

• Data Structures and Operations are closely linked

• Design of the two is done in parallel and subsequent implementation in interdependent

8

Universe

of Discourse

REQUIREMENTS

COLLECTION

AND ANALYSIS

FUNCTIONAL

ANALYSIS

APPLICATION

PROGRAM

DESIGN

..

.

CONCEPTUAL

DESIGN

LOGICAL

DESIGN

PHYSICAL

DESIGN

Conceptual Design

9

Universe

of Discourse

REQUIREMENTS

COLLECTION

AND ANALYSIS

FUNCTIONAL

ANALYSIS

APPLICATION

PROGRAM

DESIGN

..

.

CONCEPTUAL

DESIGN

LOGICAL

DESIGN

PHYSICAL

DESIGN

CONCEPTUAL

DESIGN

Database

Requirements

Conceptual Schema

(High Level Data Model,

e.g. ER, NIAM, SDM)

Defines the UoD,

and captures

semantics &

constraints of the

UoD

Serves as a

medium for

communicating

the UoD

Focus of

this lecture

Contents

The Entity-Relationship Model

• Conceptual Design and how conceptual design relates to the database design process

• Entity-Relationship (ER) Conceptual Design Method

• Notation Guide

• Example Illustrations

10

ER Model Basics

• Entities– Entities, Entity Sets and Entity Types– Attributes, Keys and Value Sets

• Relationships– Relationship Types and Sets– Relationship Degree– Roles and Recursive Relationships– Relationship Constraints– Attributes of Relationship Types

11

ER Diagram Basics

12

Relationship

Attributes

Entity

Product

Keeps

Store

descrip

qty

price

pname

manager

Locations

sname

13

PROJECT

EMPLOYEE

Fname

Minit

Name

Lname

Bdate

Ssn

Sex

SalaryAddress

DEPENDENT

Name Number

DEPARTMENT

MANAGES

WORKS_FOR

WORK_ON

CONTROLS

SUPERVISIONN

Relationship

Name

BirthDateSex

Name

Number Location

Number Of

Employee

StartDate

supervisor

supervise

1

N

N

N M

N

1

1

1

1

1

Hours

Example

ER Model:

Company

Database

DEPENDENTS_OF

Locations

Entities

• Entity

• Entity Sets

• Entity Type

• Attributes (Types, Keys and Value Sets)

14

EntityReal-world object distinguishable from other objects

(e.g a student, car, job, subject, building ...)

• An entity is described using a set of attributes

• The same entity may have different prominence in different UoDs

– In the Company database, an employee’s car is of

lesser importance

– In the Department of Transportation’s registration

database, cars may be the most important concept

– In both cases, cars will be represented as entities;

but with different levels of detail

15

Entity Sets

A collection of similar entities (e.g. all employees)

• All entities in an entity set have the same set of attributes

• Each entity set has a key

• Each attribute has a domain

• Can map entity set to a relation easily

SSN NAME SAL

321-23-3241 Kim 23,000

645-56-7895 Jones 45,000

16

CREATE TABLE Employees (ssn CHAR(11), name CHAR(20), sal INTEGER, PRIMARY KEY (ssn))

EMPLOYEES

Entity TypeDefines set of entities that have the

same attributes (e.g. EMPLOYEE) Each Entity Type is described by

its NAME and attributes The Entity Type describes the

“Schema” or “Intension” for a set of entities

Collection of all entities of a particular entity type at a given point in time is called the “Entity Set” or “Extension” of an Entity Type

Entity Type and Entity Set are customarily referred to by the same name

17

EMPLOYEE

salSSN

name

Notation

Attributes

• Key Attributes

• Value Sets of Attributes

• Null Valued Attributes

• Attribute Types

– Composite Vs. Simple Attributes

– Single-valued Vs. Multi-valued Attributes

– Derived Vs. Stored Attributes

18

Notation

Key Attributes• Key (or uniqueness) constraints are

applied to entity types

• Key attribute’s values are distinct for each individual entity in the entity set

• A key attribute has its name underlined inside the oval

• Key must hold for every possible extension of the entity type

• Multiple keys are possible

19

EMPLOYEE

SSN

Value Sets of Attributes• Value sets specify the set of values that may be

assigned to a particular attribute of an entity

– Employee Age: Integers between 21 & 65

– Vehicle Registration Number: String of 3

alphabets followed by 3 integers

• Value sets map to relational domains

• Value sets are not displayed on the ER diagram

20

Null Valued Attributes

• A particular entity may not have an applicable value for an attribute– Tertiary-Degree: Not applicable for a person

with no university education– Home-Phone: Not known if it exists– Height: Not known at present time

• Type of Null Values– Not Applicable– Unknown– Missing

21

Composite Vs. Simple AttributesComposite attributes can be divided into smaller

parts which represent simple attributes with independent meaning

Simple Attribute: Aircraft-Type

Complex Attribute: Aircraft-Location which is comprised of :

Aircraft-Latitude

Aircraft-Longitude

Aircraft-Altitude

22

Notation

… There is no formal concept of “compositeattribute” in the relational model

Single Vs. Multivalued Attributes

Simple attributes can either be single-valuedor multi-valued• Single-valued: Gender = F

Notation

• Multivalued: Degree = {BSc, MInfTech}Notation

… An “attribute” in the relational model is alwayssingle valued - Values are atomic!

23

Derived Vs. Stored Attributes

Some attribute values can be derived from

related attribute values:

• Age ® Date - B-day

• Y-Sal ® 12 * M-Sal

24

EMPLOYEE

M-sal

B-days Y-sal

Age

Notation

Derived Vs. Stored Attributes

• Some attribute values can be derived from attributed values of related entities

• total-value ® sum (qty * price)

25

Order

Item price

qty

Total-Value

Representing Attributes

• Parenthesis ( ) for composite attributes

• Brackets { } for multi-valued attributesAssume a person can have more than one residence and each residence can have multiple telephones

{AddressPhone

({ Phone ( AreaCode,PhoneNum ) },

Address (StreetAddresss (Number, Street, AptNo),

City,State,PostalCode) ) }

26

Formally ... An attribute A is defined as function

A | A:E _P(V)

where E is the Entity Type

V is the Value Set

P(V) is the Power Set (set of all subsets) of V

Value of attribute A for entity e is A(e)

where e is an entity of type E

27

Formally ...• A is a Simple Attribute where A(e) is

– A singleton (set with one element) for single-valuedattributes

– A set with multiple elements for multi-valuedattributes

– An empty set for null valued attributes

• A is a Composite Attribute when the value setV is the Cartesian product of setsP(V1), P(V2),...,P(Vn) where V1,V2,...,Vn arevalue sets for the simple component attributesthat form A: V = P(V1) X P(V2) X ... X P(Vn)

28

ER Model Basics

• Entities– Entities, Entity Sets and Entity Types– Attributes, Keys and Value Sets

• Relationships– Relationship Types and Sets– Relationship Degree– Roles and Recursive Relationships– Relationship Constraints– Attributes of Relationship Types

29