Team Dosen UMN

ER Modelling

Connolly BookChapter 12-13

Team Dosen UMN

Objectives

• Fundamental of ER Concept• Enhanced ER Concept

Team Dosen UMN

Fundamental of ER Concept

Team Dosen UMN

Entities

• Entity type is a group of objects with the same properties, which are identified by the enterprise as having an independent existence.

• Object is something that is or is capable of being seen, touched, or otherwise sensed, and about which users store data and associate behavior.

• Entity has two types of existences:– Object with a physical (real) existence

– Example: Customer, Staff, Property– Object with a conceptual (abstract) existence

– Example: Sales, Inspection

• Diagrammatic:– Entity is drawn to be a box.– First letter is Uppercase

Staff Branch

Team Dosen UMN

Entity Occurrences

• Entity Occurrence or Entity Instance or Entity: a uniquely identifiable object of an entity types

Student ID

Last Name

First Name

2144 Arnold Betty

3122 Taylor John

3843 Simmons Lisa

9844 Macy Bill

2837 Leath Heather

2293 Wrench Tim

Entity occurrence

Entity: student

Team Dosen UMN

Relationship Type

• Relationship type is a set of meaningful associations among entity types

• Relationship Occurrence: a uniquely identifiable association that includes one occurrence from each participating entity types

• Diagrammatic:– A relationship is drawn to be a line connecting the associated entity types and

labeled with the name of relationship with its direction– A relationship is named as a verb (i.e. has) or phrase with a verb. First letter is

Uppercase (i.e. LeasedBy)– Relationship is for one direction only

StaffBranchHas >

Team Dosen UMN

Semantic Net

Team Dosen UMN

Degree of Relationship

• Degree of Relationship is the number of participating entity types in a relationship

• For the degree is two, the relationship is called binary relationship

• for the degree is three, the relationship is called ternary relationship

StaffBranch Has

StaffBranch Has

Car

“Branch has staff”

“Branch has staff and car”

Team Dosen UMN

Degree of Relationship

• For the degree is four, the relationship is called quaternary relationship

StaffCustomer Has

Car

Branch

“Branch has customer, staff, and car”

Team Dosen UMN

Recursive Relationship

• Recursive Relationship is a relationship which has more than one different roles in the same entity

• Example :both Melinda and Rose are employees• Melinda’s role is the supervisor, whilst Rose’s role is supervisee• Melinda supervises Rose or you can say Rose Supervisees Melinda• Q: Can you make more examples of recursive relationships?

Employee

Supervises>

Supervisor

Supervisee

Role 1

Role 2

Team Dosen UMN

Role Names

• Role names are also used when two entities are associated through more than one relationship.

StaffBranch

Has>

<Manages

Branch Office Member of Staff

Branch Office Manager

Team Dosen UMN

Attributes

• Attribute is a property of an entity or a relationship type• Example : staffNo, name, position, and salary are the attributes of Staff

entity.• Attribute Domain is a set allowable values for one or more attributes.• Example for attribute room the attribute domain is between 1 to 15.

• According to their composition , attributes have two types: – A Simple Attribute or Atomic Attribute is an attribute composed of a

single component with an independent existence.Example position, salary in the Staff entity

– A Composite Attribute is an attributed composed of multiple components, where each component is an independent existence.Example: address attribute in Branch entity is composed of street, city, and postcode attributes.

Team Dosen UMN

Attributes

• According their values, attributes have two types:– A single-valued attribute is an attribute that holds a single value for

each occurrence of an entity type.Example: branchCode attribute in the Branch Entity as one branch has one code only.

– A multi-valued attribute is an attribute that holds multiple values for each occurrence of an entity type.Example: telpNo attribute in the Branch Entity as one branch may have two or more phones.

• Derived attribute is an attribute that represents a value that derivable from the value of a related attribute of a set of attributes, not necessarily in the same entity type.Example: duration attribute are calculated from rentStart and rentFinish attributes that are in the same Lease entity.

Team Dosen UMN

Diagrammatic attributes

• Entity is drawn as a box• Inside the Box, the uppercase part is the Entity name and the lowercase

parts are attributes.• See how to draw simple, composite, single-valued, multi-valued, and

derived attributes • Tags– {PK} Primary Key– {PPK} a member of Composite Primary Keys– {AK} Alternate key

Staff

staffNo {PK}namepositionsalary/totalStaffaddress street city postcodetelp{1..3}

Team Dosen UMN

Diagrammatic attributes

Team Dosen UMN

Strong and Weak Entity

• Strong Entity is an entity type that is not existence-dependent on some other entity typesExample: Customer

• Weak Entity is an entity hat is existence-dependent on some other entity typeExample: CustomerFamily

• Strong Entities are called parent, owner, or dominant entities whilst Weak Entities are called child, dependent, or subordinate entities.

• Strong Entity is drawn as a single border-lined box and Weak Entity is drawn as a double border-lined box

Customer

name fname lnametelp {1..3}eMail

CustomerFamily

name fname lname relation

has

Team Dosen UMN

Multiplicity

• Multiplicity is the number of possible occurrences of an entity type that may relate to a single occurrence of an associate entity type through a particular relationship

Team Dosen UMN

Staff Manages Branch

Staff

staffNo

Branch

branchCode

Manages>

0..1

A member of staff can managezero or one branch

?

Team Dosen UMN

Find Multiplicity of Staff Oversees PropertyForRent

Team Dosen UMN

Staff Oversees PropertyForRent

Team Dosen UMN

Find Multiplicity for Newspaper Advertises PropertyForRent

Team Dosen UMN

Newspaper Advertises PropertyForRent

Team Dosen UMN

Cardinality and Participation Constraints

• Cardinality describes the maximum number of possible relationship occurrences for an entity participating in a given relationship type.

• Participation determines whether all or only some entity occurrences participate in a relationship.

• There two type of participation which are mandatory participation (minimum value=1) and optional participation (minimum value=0)

Team Dosen UMN

Cardinality and Participation

Team Dosen UMN

Multiplicity Constraints

Multiplicity0..11..1 (or simply 1)0..* (or just *)1..*5..10 0,3,6-8

MeaningZero or one entity occurrenceExactly one entity occurrenceZero or many entity occurrenceOne or many entity occurrenceMinimum of 5 up to amaximum of 10 entityoccurrencesZero or three or six, seven, or

eight entity occurrences

Cardinality?????

?

Participation?????

?

Team Dosen UMN

Multiplicity in Complex Relationship

• Multiplicity (for complex relationship) is the number or range of possible occurrences of an entity type in an n-ary relationship when the other (n-1) values are fixed.

• Example multiplicity for ternary relationship represents the potential range of entity occurrences of a particular entity in the relationship when the other two values represent in the other two entities are fixed.

Team Dosen UMN

Example of Multiplicity for Complex Relationship

Team Dosen UMN

Multiplicity for Complex Relationship

0..*

Team Dosen UMN

Multiplicity for Complex Relationship

CR56/B003

CR57/B003

CR62/B003

CR84/B003

CR91/B003

r1

r2

r3

r4

r5

SG37

SG5

SG14

Registered byClient/Branch Staff

1..1

Team Dosen UMN

Multiplicity for Complex Relationship

CR56/SG37CR74/SG37CR62/SG14CR84/SG14CR91/SG14

Client/Staff Register at

B003

Branch

1..1

Team Dosen UMN

Multiplicity for Complex Relationship

Team Dosen UMN

Problems with ER models

• There are two main problems, which are Fan Traps and Chasm Traps.

• Fan Traps happen where a model represents a relationship between entity types, but the pathway between certain entity occurrence is ambiguous.

Student Faculty StudyProgram<Has Operates>

1..*1..11..11..*

Student StudyProgram? ?

?

Team Dosen UMN

Fan Traps Solution 1

• Draw semantic net of original ER model

Ali

Bryan

Calvin

Dee

Eddy

Studentsentity

Economy

ICT

Facultyentity

Mgmt

SK

TI

SI

StudyProgramentity

Hasrelationship

Operatesrelationship

Team Dosen UMN

Fan Traps Solution 2

• Examine occurrences of the relationships

Ali

Bryan

Calvin

Dee

Eddy

Studentsentity

Economy

ICT

Facultyentity

Mgmt

SK

TI

SI

StudyProgramentity

Operatesrelationship

Hasrelationship

Team Dosen UMN

Fan Traps Solution Result

• Restructure the ER model

Faculty StudyProgram StudentOperates> Has>

1..*1..11..1 1..*

Team Dosen UMN

Chasm Traps

• Chasm Traps happen where a model suggests the existence of a relationship between entity types, but the pathway does not exist certain entity occurrences

• It may occur when one or more relationships with optional participations(minimum multiplicity=0)

Branch Staff PropertyHas> Oversees>0..*0..11..*1..1

Branch Property?

??

Team Dosen UMN

Chasm Traps Solution

• Identify the missing relationship, and make a new relationship

Branch Staff PropertyHas> Oversees>0..*0..11..*1..1

Offers>

1..1 1..*

Team Dosen UMN

Enhanced ER Modeling

Team Dosen UMN

Entity Types

• Superclass is an entity type that includes one or more distinct subgroupings of its occurrences, which must be represented in a data model.

• Subclass is a distinct subgrouping of occurrences of an entity type, which must be represented in a data model.

• Example: Staff entity may be classified as Manager, SalesPersonnel, Secretary. In other words:– Staff entity is the superclass of Manager, SalesPersonnel, Secretary.– Manager, SalesPersonnel, Secretary is the subclasses of Staff entity.

Team Dosen UMN

Superclass/Subclass Relationship

• Each member of subclass is also a member of superclass • The relationship between a superclass and subclass is one-to-one (1:1).• Not every member of superclass is necessarily a member of a subclass.• Example Staff entity has overlapping subclasses Manager, SalesPersonel, and Secretary.

staffno name position salary mgrstartdate bonus salesArea carAllowance typingSpeedSL21 John manager 30000 1/2/1995 2000SG37 Ann assistant 12000SG66 Matinez sales manager 27000 SA1A 5000SA9 Howe assistant 9000SL89 Suart secretary 8500 100SL31 Robert snr sales asst 17000 SA2B 3700SG5 Susan manager 24000 1/6/1991 2350

Attributes appropriate for all staff

Attributes appropriate for managers

Attributes appropriate

for Sales Personnel

Attributes appropriate for Secretary

Team Dosen UMN

Attribute Inheritance

• One subclass may have one or more subclasses. • An entity and its subclasses and their subclasses is called a type hierarchy.• Type hierarchy that accords to specialization of the entity is called

specialization hierarchy.Example: Manager is specialization of Staff.

• Type hierarchy that accords to generalization of the entity is called generalization hierarchy.Example: Staff is generalization of Manager

• Type hierarchy that accords to a member of the entity is called IS-A hierarchy.Example: Manager is a member of staff

• A subclasses with more than two superclasses is called shared subclasses.• Attributes of the superclasses are inherited by the shared subclass. This

process is called multiple inhertance.

Team Dosen UMN

Specialization Process

• Specialization process is the process of maximizing the differences between members of an entity by identifying their distinguishing characteristics.

• Steps:– 1. Identify a set of subclasses of an Entity– 2. Associate attributes specific to each subclass (if applicable)– 3. Identify any relationship between each subclass and other entity types

or sub classes (if applicable).

Team Dosen UMN

Example of Specialization of the Staff into subclasses representing job roles

Staff

staffNo {PK}namepositionsalary

Manager

mgrStartDatebonus

SalesPersonnel

salesAreacarAllowence

Secretary

typingSpeed

subclasses

superclass

Specialization/generalization {Optional, And}

participationconstraint

disjointconstraint

Team Dosen UMN

Example of Specialization of the Staff into subclasses representing contract of employment

Staff

staffNo {PK}namepositionsalary

FulltimePermanent

salaryScaleholidayAllowance

PartTimeTemporary

hourlyRate

subclasses

superclass

Specialization/generalization {Mandatory, Or}

participationconstraint

disjointconstraint

Team Dosen UMN

Example of Specialization

Manager

mgrStartDatebonus

SalesPersonnel

salesAreacarAllowence

Secretary

typingSpeed

SalesManager

salesTarget

AssistantScretary

startDate

{Optional}{Optional}{Optional}

Sharedsubclasses

Participationconstraints

Team Dosen UMN

Constraints of Specialization/Generalization

• Participation Constraint determines whether every member in the superclass must participate as a member of a subclass

• Disjoint Constraints describes the relationship between members of the subclasses and indicates whether it is possible for a member of a superclass to be a member of one or more subclasses.

Team Dosen UMN

Aggregation

• Aggregation represents a has-a or is-part-of relationship between entity types, where one represents the whole and the other the part.

• Example: Has relationship from Branch entity (the whole) to the Staff entity (the part).

Branch

branchNo

Staff

staffNo

Has>

1..1 1..*

aggregation

The Entity representingpart in Has relationship

The Entity representingwhole in Has relationship

Team Dosen UMN

Composition

• Composition is a specific form of aggregation that represents an association between entities, where there is a strong ownership and coincidental lifetime between the whole and the part. (Booch et al, 1998).

• In a composite the whole is responsible for disposition of the parts meanings it manages the creation and destruction of its parts.

Newspaper AdvertDisplays>

1..1 1..*

composition

The Entity representingpart in Display relationship

The Entity representingwhole in Display relationship

Team Dosen UMN

Workshop

• We have a guest describing his/her point of view about one new database system requirement.

• Use your interview techniques to ask her as necessary and make:• 1. Mission Statement• 2. Mission Objectives• 3. Project Scope & Boundaries• 4. E-R Diagram