Database Chapter 2

COURSE LEARNING OUTCOME (CLO) : • CLO1 – Explain the basic concepts of database model using entity-relationship diagram and translating completed data models by applying normalization technique in logical database designs. (C4)

At the end of this chapter, students should be able to :

Define an entity.

Identify the entity types and sets of entity.

Explain the attribute.

Explain E-R model.

Explain the following relationship types in E-R model:

1:1 (one to one)

1:M (one to many)

M:N (many to many)

Draw E-R model based on a given situation. ec601 database system 2

LESSON LEARNING OBJECTIVES (LLO)

E-R model is widely accepted and adapted graphical tool for data modeling.

Peter Chen first introduced the E-R data model in 1976.

The E-R Model yielded a graphical representation of entities and their relationships in a database structure.

The E-R model complemented the relational data model concepts.

3 ec601 database system

E-R Model are normally represented in an Entity Relationship Diagram (ERD), which uses graphic representations to model the database components.

The E-R modeling process identifies three basic elements :

ENTITIES

ATTRIBUTES

RELATIONSHIPS


ENTITY An object or concept that can be uniquely identified.

Usually, a database contain many different types of entities.

Entities can be classified into types :

Strong Entity

Weak Entity.


The term entity type refers to a number of related items.

The term Entity = Entity Type.

Entity Instance refers to a single occurrence of an entity type.

Example : employee no 123-456

Entity Set = Set of all entities of the same type


STRONG ENTITY an entity referred to as a strong entity if its existence is not dependent on the existence of another entity.

Strong entity sometimes referred to as the parent entity, owner or dominant.

Each strong entity shown in the shape of a square and labeled with the name of the entity.

Examples : Staff and Branch


PAINTER

WEAK ENTITY weak entity depends on the existence of another entity.

They can not exist in the model if a member does not exist in corresponds to other entities.

Weak entity represents by a square with two lines

Weak entities sometimes called child entity, dependent or subordinate.

Examples : next of kin (staff)


NEXT_OF_KIN

WEAK ENTITY can be identified when one that meets this two conditions :

It is existence-dependent it cannot exist without the entity with which it has a relationship

It has a primary key that is partially or totally derived from the parent entity in the relationship.


An Entity is represented in the ERD by a rectangle, also known as an entity box.

The name of the entity, a noun is written in the center of the rectangle.

The entity name is written in CAPITAL LETTERS and is written in the singular : PAINTER rather than PAINTERS.

Each entity is described by a set of attributes that describe particular characteristics of the entity.


ATTRIBUTES Characteristics of Entities.

In the Chen Model, attributes are represented by ovals and are connected to the entity with a line.

stu_fname

stu_lname

stu_initial

stu_email

stu_phone

STUDENT


Attributes can be classified into :

Composite / Simple (Atomic)

Single Value / Multi Value

Derived



COMPOSITE

• Attribute that can be further subdivided to additional attributes

• Example : ADDRESS can be subdivided into street, city, state and zip code

SIMPLE / ATOMIC

• Attribute that cannot be subdivided.

• Example : AGE, GENDER, MARITAL STATUS


SINGLE VALUE

•Attribute that can have only a single value.

•Example : IC, MATRIX NO

MULTI VALUE

• Attribute that can have multi value. • In Chen Model, multi valued attributes are shown by a double line oval connecting the attribute to the entity. •Example : CAR COLOR

color CAR color


DERIVED

•Attribute whose value may be calculated from other attributes.

• It need not be physically stored within the database, instead, it can be derived by using an algorithm.

•Example : EMP_AGE can be calculated with EMP_DOB

Ic_no

ec601 database system 16

TEACHER

ic_no

Single Value Attribute

TEACHER

address

street state

p_code

Composite Attribute

TEACHER

subjects

Multivalued Attribute

CIRCLE

area

Derived Attribute

radius

Attributes have a domain.

A DOMAIN is the attributes set of possible values.

Domains for attributes = Value Set

Attributes may share a domain.

Examples :

ATTRIBUTES DOMAIN

GPA (0,4) 0 low, 4 highest

GENDER M or F


PRIMARY KEYS (PK) is an attribute that uniquely identifies any given entity (row).

Also known as key attributes.

Cannot contain null entries.

Examples :

Students name would not be a good primary key because it is possible to find several students who has a same name.


Primary keys are underlined in the ER diagram.

Primary keys are also underlined in a frequently used table structure using the format : TABLE NAME (PRIMARY KEY, ATTRIBUTE 1, ATTRIBUTE 2,

…, ATTRIBUTE K)

STUDENT (IDNO, NAME, GENDER, AGE)


RELATIONSHIPS Describe associations among data.

Degree of a Relationship the number of entities involved in the relationship.

3 Relationship Degrees :

Unary Relationship (Recursive Relationship)

Binary Relationship

Ternary Relationship

N-ary Relationship 20 ec601 database system

•A relationship involving a single entity.

UNARY RELATIONSHIP (RECURSIVE)

•A relationship between two entities.

BINARY RELATIONSHIP

•A relationship between three entities.

TERNARY RELATIONSHIP

•A relationship that involve more than three entities

N-ARY RELATIONSHIP



supervision

EMPLOYEE

Unary/Recursive Relationship

PROFESSOR teaches CLASS

Binary Relationship

CONTRIBUTOR CFR RECIPIENT

Ternary Relationship

FUND

TWO types of strength :

Strong Relationship

Weak Relationship



• Also known as an identifying relationship

• Exists when the related entities are existence-dependent.

• In database design perspective, a strong relationship between two entities exists whenever the primary key of the related entity contains a primary key component of the parent entity.

• Example :

• COURSE (CRS_CODE, DEPT_CODE, CRS_CREDIT)

• CLASS (CRS_CODE, CLASS_SECTION, CLASS_TIME)

• #: The CRS_CODE in CLASS is also a foreign key to the COURSE entity.

STRONG RELATIONSHIP


•Also known as an non-identifying relationship

•If one entity is not existence-independent on another entity, the relationship between them is described as a weak relationship.

•In database design perspective, a weak relationship exists if the primary key of the related entity does not contain a primary key component of the parent entity.

•Example :

•COURSE (CRS_CODE, DEPT_CODE, CRS_CREDIT)

•CLASS (CLASS_CODE, CRS_CODE, CLASS_TIME)

•#: The CLASS primary key did not inherit the primary key component from the COURSE entity.

WEAK RELATIONSHIP

Relationships are represented by a diamond connected to the related entities through a relationship line.

The name of the relationship, an active or passive verb, is written inside the diamond.


Strong relationship

Weak relationship

The ERD shown is based on the Chen Model.

Although the relationships are shown in a horizontal format, they also may be oriented in vertically.

PAINTER PAINTING paints 1 M


Optional Relationship

If one entity occurrence does not require a corresponding entity occurrence in a particular relationship

The existence of an optional indicates that the minimum cardinality is 0 for the optional entity.

An optional relationship between entities is shown by drawing a small circle (o) on the side of the optional entity.

Mandatory Relationship

If one entity occurrence requires a corresponding entity occurrence in a particular relationship.

The existence of an mandatory indicates that the minimum cardinality is 1 for the optional entity.

Example :

Optional Relationship

An Employee may or may not be assigned to a Department

A Patient may or may not be assigned to a Bed

Mandatory Relationship

Every Course must be taught by at least one Teacher

Every mother have at least a Child

PROFESSOR CLASS teaches 1 M

Example : Suppose that Tiny College employs some professors who conduct research without teaching classes. If we examine the “PROFESSOR teaches CLASS” relationship, it is quit possible for a PROFESSOR not to teach a CLASS. Therefore, CLASS is optional to PROFESSOR. On the other hand, a CLASS must be taught by a PROFESSOR. Therefore PROFESSOR is mandatory to CLASS.

optional mandatory

1:1 (one to one)

• In this relationship, one entity can be related to only one other entity.

1:M (one to many)

• In this relationship, one entity can be related to many entity.

M:N (many to many)

• In this relationship, many entity can be related to many other entity.


Cardinality Constraints

Express the number of entities to which another entity can be associated via a relationship set.

Cardinality Constraints - the number of instances of one entity that can or must be associated with each instance of another entity.

Minimum Cardinality If zero, then optional

If one or more, then mandatory

Maximum Cardinality The maximum number

Example :

PROFESSOR CLASS teaches

1 M

(1,4) (1,1)

CONNECTIVITIES

CARDINALITIES


CHECK THE MODEL

DETERMINE

CARDINA

LITIES

MODEL RELATION

SHIP

CHOOSE PRIMARY

KEYS

MODEL ENTITIES &

ATTRIBUTES

A Simple Example

A company has several departments. Each department has a supervisor and at least one employee. Employees must be assigned to at least one, but possibly more departments. At least one employee is assigned to a project, but an employee may be on vacation and not assigned to any projects. The important data fields are the names of the departments, projects, supervisors and employees, as well as the supervisor and employee number and a unique project number.

Identify entities

One approach to this is to work through the information and highlight those

words which you think correspond to entities.

A company has several departments. Each department has a supervisor and at least one employee. Employees must be assigned to at least one, but possibly more departments. At least one employee is assigned to a project, but an employee may be on vacation and not assigned to any projects. The important data fields are the names of the departments, projects, supervisors and employees, as well as the supervisor and employee number and a unique project number.

Identify entities

EMPLOYEE

PROJECT DEPARTMENT

SUPERVISOR

Identify Attributes

PROJECT DEPARTMENT

department_name project_name project_no

EMPLOYEE

employee_ name

employee_no

SUPERVISOR

supervisor_ name

supervisor_ no

Identify Primary Keys

PROJECT DEPARTMENT

department_name project_name project_no

EMPLOYEE

employee_ name

employee_no

SUPERVISOR

supervisor_ name

supervisor_ no

Identified Relationships

Names placed in the cells are meant to capture/describe the relationships. So you can use them like this

A Department is assigned by an employee

A Department is run by a supervisor

An employee works on a project

A supervisor runs a department

Draw Rough ERD

Draw a diagram and:

Place all the entities in rectangles

Use diamonds and lines to represent the relationships between entities.

Drawing Rough ERD (Contd.)

EMPLOYEE works

on PROJECT

DEPARTMENT run by SUPERVISOR

DEPARTMENT is

assign EMPLOYEE



is assign

works on

EMPLOYEE PROJECTS

Drawing Rough ERD (Contd.)

Identify Cardinality

Supervisor

Each department has one supervisor.

Department

Each supervisor has one department.

Each employee can belong to one or more departments

Employee

Each department must have one or more employees

Each project must have one or more employees

Project

Each employee can have 0 or more projects.



is assign

works on

EMPLOYEE PROJECTS

(1,1) (1,1) (1,N)

(1,N) (1,N) (0,N)

ERD with cardinality



is assign

works on

EMPLOYEE PROJECTS

(1,1) (1,1) (1,N)

(1,N) (1,N) (0,N)

ERD Diagram

Departmentname

Employee no

Supervisor no

Project no

Supervisor name

project_ name

employee_ name


SUMMARY of ER DIAGRAM NOTATION

ENTITY/ ENTITY TYPE

SYMBOL MEANING

WEAK ENTITY TYPE

RELATIONSHIP TYPE

WEAK RELATIONSHIP TYPE


SUMMARY of ER DIAGRAM NOTATION

ATTRIBUTE

SYMBOL MEANING

KEY ATTRIBUTE

MULTIVALUED ATTRIBUTE

DERIVED ATTRIBUTE

COMPOSITE ATTRIBUTE

Database Chapter 2

Documents

strong entity weak entity

entity types

parent entity

child entity

entity instance

entity box

ec601 database system

kin weak entity