Unit Reading Assignment

Lecture 3

1Dr. Nawaz Khan; Email: [email protected]

BIS4435 – Industrial Data Management

Lecture: Entity-Relationship Modeling

Dr. Nawaz KhanSchool of Computing ScienceE-mail: [email protected]

Duty time: Wednesdays : 2:30-4:30 pm

Lecture 3

2Dr. Nawaz Khan; Email: [email protected] BIS4229 – Industrial Data Management Technologies

Unit Reading Assignment

Unit 3: Entity Relationship Modelling: A Traditional vs. Object Oriented Approach

Reading Suggestion:

Connolly, T.M., and Begg, C.E., Database Systems: A Practical Approach to Design, Implementation and Management, Addison-Wesley, 4th Edition, ISBN: 0321210255(chapters 11, 13 and 25)

More Reading:

Fundamentals of Database Systems. R. Elmasri and S. B. Navathe,

4th Edition, 2004, Addison-Wesley, ISBN 0-321-12226-7 (Chapters 3, 7)

Lecture 3

3Dr. Nawaz Khan; Email: [email protected] BIS4229 – Industrial Data Management Technologies

NOTE: !!!!!

This unit is the basis of the STAGE I CW Portfolio.

In particular, it helps you understand the Structured Query Language (SQL) discussed in unit 4 and Normalisation discussed in unit 5

Lecture 3


Unit Learning Outcome

At the end of this unit you should be able to: Analyse cases to identify the entities and their

relationships involved Apply Entity Relationship modelling to represent entities,

their relationships and extend it further by identifying attributes for each entity

Transform the model into relations suitable for Relational database implementation

Identify the need of object oriented approach for semantic data modelling

Apply Unified modelling language to model database objects

Lecture 3


Lecture Outline What is the ER modeling? And why?

Example Database Application (COMPANY) ER model concepts

Entities and AttributesEntity Types, Value Sets, and Key AttributesRelationships and Relationship TypesWeak Entity Types

More about relationships Structural constraints: cardinality ratio, membership class Recursive relationships Subtype and generalization of subtype

ER diagram Transformation ER model -> relational database schema

EER and UML for data modeling

Lecture 3


Entity-Relationship ModelingLab Notes

JobID CompanyID JobTitle Salary …. JobList

CompanyID CompanyName Address ...Company

CompanyID duplicates in Joblist table: No: 1-1 relationship Yes: 1-N relationship (N side: Joblist)

Lecture 3


Entity-Relationship Modeling What is the ER modeling? And why?

Database approach: Where is ER modeling?

ExternalSchema 1

ExternalSchema 2

ExternalSchema N

InternalSchema

Interface betweenconceptual schemaand internal schema

Interface betweenconceptual schema and

external schemas

ConceptualSchema

Databasephysically storedin files on disks

Lecture 3


Entity-Relationship Modeling What is the ER modeling? And why?

ER modelling is a logical organisation of data within a database system

ER modelling technique is based on relational data model Why use ER data modelling:

User requirements can be specified formally & unambiguously

The conceptual data model is independent of any particular DBMS

It does not involve any physical or implemental details It can be easily understood by ordinary users. It provides an effective bridge between informal user

requirements and logical database design and implementation

Lecture 3


Entity-Relationship Modeling Example Database Application (COMPANY)

Requirements of the Company (oversimplified for illustrative purposes) The company is organized into DEPARTMENTs. Each

department has a name, number and an employee who manages the department. We keep track of the start date of the department manager

Each department controls a number of PROJECTs. Each project has a name, number and is located at a single location

We store each EMPLOYEE’s social security number, address, salary, sex, and birthdate. Each employee works for one department but may work on several projects. We keep track of the number of hours per week that an employee currently works on each project. We also keep track of the direct supervisor of each employee

Each employee may have a number of DEPENDENTs. For each dependent, we keep track of their name, sex, birthdate, and relationship to employee

Lecture 3


Summary of ER diagram notation

Meaning

ENTITY TYPE

WEAK ENTITY TYPE

RELATIONSHIP TYPE

IDENTIFYING RELATIONSHIP TYPE

ATTRIBUTE

KEY ATTRIBUTE

MULTIVALUED ATTRIBUTE

COMPOSITE ATTRIBUTE

DERIVED ATTRIBUTE

TOTAL PARTICIPATION OF E2 IN R

CARDINALITY RATIO 1:N FOR E1:E2 IN R

STRUCTURAL CONSTRAINT (min, max) ON PARTICIPATION OF E IN R

Symbol

E1 R E2

E1 R E2

R(min,max)

E

N

Lecture 3


Entity-Relationship Modeling ER diagram for the COMPANY database

Lecture 3


Entity-Relationship Modeling ER model concepts

Entities and Attributes Entities are specific objects or things in the mini-world that

are represented in the database; for example, the EMPLOYEE John Smith, the Research DEPARTMENT, the ProductX PROJECT

Attributes are properties used to describe an entity; for example, an EMPLOYEE entity may have a Name, SSN, Address, Sex, BirthDate

A specific entity will have a value for each of its attributes; for example, a specific employee entity may have Name=‘John Smith’, SSN=‘123456789’, Address=‘731 Fondren, Houston, TX’, Sex=‘M’, BirthDate=‘09-JAN-55’

Lecture 3



Types of attributes Simple: Each entity has a single atomic value for the

attribute; for example SSN or Sex Composite: The attribute may be composed of several

components; for example, Address (Apt#, House#, Street, City, State, ZipCode, Country) or Name(FirstName, MiddleName, LastName). Composition may form a hierarchy where some components are themselves composite

Multi-valued: An entity may have multiple values for that attribute; for example, Color of a CAR or PreviousDegrees of a STUDENT. Denoted as {Color} or {PreviousDegrees}

In general, composite and multi-valued attributes may be nested arbitrarily to any number of levels although this is rare. For example, PreviousDegrees of a STUDENT is a composite multi-valued attribute denoted by {PreviousDegrees(College, Year, Degree, Field)}

Lecture 3



Entity Types, Value Sets, and Key Attributes Entities with the same basic attributes are grouped or typed

into an entity type. For example, the EMPLOYEE entity type or the PROJECT entity type

An attribute of an entity type for which each entity must have a unique value is called a key attribute of the entity type. For example, SSN of EMPLOYEE

A key attribute may be composite. For example, VehicleTagNumber is a key of the CAR entity type with components (Number, State)

An entity type may have more than one key: choose one arbitrarily as the primary key

Lecture 3



Relationships and Relationship Types A relationship relates two or more distinct entities with a specific

meaning; for example, EMPLOYEE John Smith works on the ProductX PROJECT or EMPLOYEE Franklin Wong manages the Research DEPARTMENT

Relationships of the same type are grouped or typed into a relationship type. For example, the WORKS_ON relationship type in which EMPLOYEEs and PROJECTs participate, or the MANAGES relationship type in which EMPLOYEEs and DEPARTMENTs participate

The degree of a relationship type is the number of participating entity types. Both MANAGES and WORKS_ON are binary relationships

More than one relationship type can exist with the same participating entity types; for examples, MANAGES and WORKS_FOR are distinct relationships between EMPLOYEE and DEPARTMENT participate

Lecture 3



Weak Entity Types An entity that does not have a key attribute A weak entity must participate in an identifying relationship

type with an owner or identifying entity type Entities are identified by the combination of:

A partial key of the weak entity typeThe particular entity they are related to in the

identifying entity type Example: a DEPENDENT entity is identified by the

dependent’s first name (unique wrt. each EMPLOYEE) and the specific EMPLOYEE that the dependent is related to. DEPENDENT is a weak entity type with EMPLOYEE as its identifying entity type via the identifying relationship type DEPENDENT_OF

Lecture 3



Lecture 3


Entity-Relationship Modeling More about relationships

Structural constraints: one way to express semantics of relationship: cardinality ratio and membership class

Cardinality ratio (functionality): It specifies the number of relationship instances that an entity can participate in a binary relationship one-to-one (1:1) one-to-many (1:M) or many-to-one (M:1) many-to-many (M:N)

An example of a 1:1 binary relationship is MANAGES which relates a department entity to the employee who manages that department. This represents the miniworld constraints that an employee can manage only one department and that a department has only one manager

Relationship types of degree 2 are called binary. Relationship types of degree 3 are called ternary and of degree n are called n-ary. In general, an n-ary relationship is not equivalent to n binary relationships (reading suggestion !!)

Lecture 3


One-to-many(1:N) or Many-to-one (N:1) RELATIONSHIP

e1

e2

e3

e4

e5

e6

e7

EMPLOYEE

r1

r2

r3

r4

r5

r6

r7

WORKS_FOR

d1

d2

d3

DEPARTMENT

Lecture 3


MANY-TO-MANY(M:N)RELATIONSHIP

e1

e2

e3

e4

e5

e6

e7

r1

r2

r3

r4

r5

r6

r7

p1

p2

p3

r8

r9

EMPLOYEE WORKS_ON PROJECT

Lecture 3



Membership class (participation constraint): Mandatory (total participation) - every instance of a participating

entity type must participate in the relationship. Example: ATTEND relationship between STUDENTS and COURSE

Optional (partial participation) - not every instance of a participating entity type must participate in the relationship. Example: OFFER relationship between SCHOOL and MODULE is optional for SCHOOL but mandatory for MODULE

Notation: Cardinality ratio (of a binary relationship): 1:1, 1:N, N:1, or M:N

SHOWN BY PLACING APPROPRIATE NUMBER ON THE LINK

Participation constraint (on each participating entity type): total (called existence dependency) or partial.

IN ER DIAGRAMS, TOTAL PARTICIPATION IS DISPLAYED AS A DOUBLE LINE CONNECTING THE PARTICIPATING ENTITY

TYPE TO THE RELATIONSHIP, WHEREAS PARTIAL PARTICIPATION IS REPRESENTED BY A SINGLE LINE

Lecture 3



Lecture 3



Recursive relationships (involuted relationship): relationship among different instances of the same entity

PERSON MARRY

1

1

EMPLOYEE SUPERVISE

N

1

PART COMPRISE

M

N

Lecture 3


Entity-Relationship Modeling ER diagram

An ER model can be expressed in the form of the ER diagram

An entity type is represented by a rectangular box A relationship is represented by a diamond-shaped box Relationships are linked to their constituent entity types by

arcs The functionality of a relationship is indicated on the arc Attributes of entity types/relationships, and membership

classes of entity types are listed separately from the diagram

The key attribute(s) is underlined

Lecture 3



Example: The university database maintains records of its departments, lecturers, course modules, and students

The requirements are summarised as follows: The university consists of departments. Each department

has a unique name and some other descriptive attributes A department must also have a number of lecturers, one of

which is the head of department All lecturers have different names (we assume so anyway).

They must teach one or more modules. A lecturer can only belong to one department

Modules are offered by departments and taught by lecturers. They must also be attended by some students. Each module has a unique module number.

Students must enrol for a number of modules. Each student is given a unique student number.

Lecture 3


OFFER

DEPARTMENT

MODULE LECTURER

HEAD_OF IS_IN

TEACH

1 1

1

N

M

1 N

1

STUDENT

N

M

ENROL

Lecture 3



Entity types and their attributes: DEPARTMENT: DNAME, LOCATION, FACULTY, … MODULE: MDL-NUMBER, TITLE, TERM, … STUDENT: SNUMBER,SNAME,ADDRESS,SEX,DOB, … LECTURER: LNAME, ROOMNUMBER, PHONE, ...

Lecture 3



Relationships: HEAD_OF:

1:1 between LECTURER and DEPARTMENT Membership: Mandatory for DEPARTMENT

IS_IN: 1:N between DEPARTMENT and LECTURER Membership: Mandatory for both

OFFER: 1:N between DEPARTMENT and MODULE Membership: Mandatory for MODULE

ENROL: M:N between STUDENT and MODULE Membership: Mandatory for both Attribute: DATE (date of enrolment)

TEACH: 1:M between LECTURER and MODULE Membership: Mandatory for both

Do complete the ER Diagram !!

Lecture 3


Entity-Relationship Modeling Transformation ER model --> relational database

schema

Transformation of entity types Entity --> Relation Attribute of entity --> Attribute of relation Primary key of entity --> Primary key of relation

Transformation of binary relationships - depends on functionality of relationship and membership class of participating entity types

Lecture 3



schema

Mandatory membership class For two entity types E1 and E2: If E2 is a mandatory

member of an N:1 (or 1:1) relationship with E1, then the relation for E2 will include the prime attributes of E1 as a foreign key to represent the relationship

For a 1:1 relationship: If the membership class for E1 and E2 are both mandatory, a foreign key can be used in either relation

For an N:1 relationship: If the membership class of E2, which is at the N-side of the relationship, is optional (i.e. partial), then the above guideline is not applicable

Lecture 3



schema

DEPARTMENT OFFER MODULE1 N

Assume, every module must be offered by a department,then the entity type MODULE is a mandatory member of the relationship OFFER. The relation for MODULE is:

MODULE(MDL-NUMBER, TITLE, TERM, ..., DNAME)

Lecture 3



schema

Optional membership classes If entity type E2 is an optional member of the N:1

relationship with entity type E1 (i.e. E2 is at the N-side of the relationship), then the relationship is usually represented by a new relation containing the prime attributes of E1 and E2, together with any attributes of the relationship. The key of the entity type at the N-side (i.e. E2) will become the key of the new relation

If both entity types in a 1:1 relationship have the optional membership, a new relation is created which contains the prime attributes of both entity types, together with any attributes of the relationship. The prime attribute(s) of either entity type will be the key of the new relation.

Lecture 3



schema

One possible representation of the relationship:BORROWER(BNUMBER, NAME, ADDRESS, ...)BOOK(ISBN, TITLE, ..., BNUMBER)

A better alternative:BORROWER(BNUMBER, NAME, ADDRESS, ...)BOOK(ISBN, TITLE, ...)ON_LOAN(ISBN, BNUMBER)

ON_LOAN BORROWER BOOK 1

N

Lecture 3



schema

N:M binary relationships: An N:M relationship is always represented by a new relation

which consists of the prime attributes of both participating entity types together with any attributes of the relationship

The combination of the prime attributes will form the primary key of the new relation

Example: ENROL is an M:N relationship between STUDENT and MODULE. To represent the relationship, we have a new relation:

ENROL(SNUMBER, MDL-NUMBER, DATE)

Lecture 3



schema

Transformation of recursive/involuted relationships: The name(s) of the prime attribute(s) needs to be changed to reflect the role each entity plays in the relationship

Example 1: 1:1 involuted relationship, in which the memberships for both entities are optional

PERSON(ID, NAME, ADDRESS, ...)

MARRIAGE(HUSBAND-ID, WIFE_ID, DATE_OF_MARRIAGE)

Lecture 3



Recursive relationships (involuted relationship): relationship among different instances of the same entity

PERSON MARRY

1

1

EMPLOYEE SUPERVISE

N

1

PART COMPRISE

M

N

Lecture 3



schema

Example 2: 1:M involuted relationship. If the relationship is mandatory or almost mandatory:

EMPLOYEE(ID, ENAME, ..., SUPERVISOR_ID) If the relationship is optional:

EMPLOYEE(ID, ENAME, ...)

SUPERVISE(ID, START_DATE, ..., SUPERVISOR_ID)

Example 3: N:M involuted relationship

PART(PNUMBER, DESCRIPTION, ...)

COMPRISE( MAJOR-PNUMBER, MINOR-PNUMBER, QUANTITY)

Lecture 3



schema

Transformation of subtypes: The transformation of a type hierarchy results in a separate

relation for the root entity type and each subtype The key of each relation is the key of the root type The relation for each subtype also contains its specific

attributes in addition to the key

Example:PERSON(ID, NAME, ADDRESS, ...)

STUDENT(ID, <attributes specific to students>)

LECTURER(ID, <attributes specific to lecturers>)

PROFESSOR(ID, <attributes specific to professors>)

Lecture 3


Extended E-R Modeling

Generalisation: is a process where an entity is constructed from two or more existing entities based on the similarities they have. For example, an entity Employee is constructed from two entities, Part-Time Employee and Full-Time Employee. Therefore it can be said that the generalisation process is a bottom up approach.

Aggregation: is a process where an entity is constructed from two or more existing entities that are the essential components of the entitiy that is being defined. For example, entity Employee consists of Name, Address and DateOfBirth entities. The Name, Address and DateOfBirth entities are essential components of entity Employee.

Association: is a process where an entity is constructed from the relationships that are defined between two entities. For example, an entity Emplyee-Department is constructed from two entities Employee and Department to show the departments that are assigned to each employee.

Lecture 3


Example: EER Modelling

Employee

Part-timeEmployee

Full-timeEmployee

Monthly salary

Address

Name

Employee ID

Hourly Rate salary

Date of Birth

Lecture 3


EER Modelling: When?

The choice of using EER modelling technique depends on the following factors:

some entities share common attributes with others but not with all

an entity type that shares common attributes with others, has very specific relationship and that is unique to that entity type

specific business rules/constraints need to be applied an entity has an especial relationship with its own

instances, in other words when entities demonstrate recursive relationships

if ‘is a’ and ‘has a’ relationships are identified, for example, a Truck is a Vehicle and Truck has a Part.

Lecture 3


UML Notations: Class and Association

Class

Association

Employee

EIDNameAddressDateOfBirth.

CalcHour()CalcAmount()AssignJob(Job)

Class Name

Operations

Attributes

Employee Job0..1 AssignJob 0..1

Employee Job1 AssignJob 1..*

Employee Job* AssignJob *

Lecture 3


UML Notations: Generalisation

Employee


AssignJob(Job)

FullTimeEmployee

SalaryGrade

CalcPension()

PartTimeEmployee

HourRate

CalcWeeklyAmount()

employeeType

Lecture 3


UML Notation: Generalisation and Aggregation

Employee


AssignJob(Job)

FullTimeEmployee

SalaryGrade

CalcPension()

PartTimeEmployee

HourRate

CalcWeeklyAmount()

employeeType

StudentCourse

School

1..* 1..*1..*

1

Lecture 3


Activity Week3

Draw an ER diagram for a Bank. Each bank can have multiple branches, and each branch can have multiple accounts and loans. List the entities Identify PK What modification you need if you like to include customer in

the schema

Unit Reading Assignment

Documents

Transcript of Unit Reading Assignment