ER Modeling Part II

Lecture 5

1
Learning Outcomes
 In this chapter, you will learn:
 The main characteristics of entity relationship
components
 How relationships between entities are defined,
refined, and incorporated into the database design
process
 How ERD components affect database design and
implementation
 That real-world database design often requires the
reconciliation of conflicting goals
 Mapping ER Model to Relational Model

2
Developing an ER Diagram
 The process of database design is an
iterative rather than a linear or sequential
process.
 It usually begins with a general narrative of
the organization’s operations and procedures.
 The process is repeated until the end users
and designers agree that the ER diagram is a
fair representation of the organization’s
activities and functions.

3
Developing an ER Diagram
 Building an ERD usually involves the following
activities:
 Create detailed narrative of organization’s
description of operations
 Identify business rules based on description of
operations
 Identify main entities and relationships from
business rules
 Develop initial ERD
 Identify attributes and primary keys that
adequately describe entities
 Revise and review ERD

4
Developing an ER Diagram
 Example: Tiny College Database (1)
 Tiny College (TC) is divided into several schools.
 Each school is administered by a dean who is a professor.
 A professor can be the dean of only one school, and a
professor is not required to be the dean of any school.

Simple business rules:

Each school is administered by a dean.
Each dean administers a school.
5
Developing an ER Diagram
 Tiny College Database (2)
 Each school is composed of several departments.
 The smallest number of departments operated by a
school is one, and the largest number of
departments is indeterminate (N).
 Each department belongs to only a single school.

6
Developing an ER Diagram
 Tiny College Database (3)
 Each department may offer several courses. And a
course must be offered by a department.

7
Developing an ER Diagram
 Tiny College Database (4)
 A department may offer several classes (sections)
of the same course, and a class is open for a
course.

8
Developing an ER Diagram
 Tiny College Database (5)
 Each department should have one or more
professors assigned to it. One and only one of
those professors chairs the department.

9
Developing an ER Diagram
 Tiny College Database (6)
 Each professor may teach up to four classes, each
class is a section of a course.
 A professor may also be on a research contract
and teach no classes at all.

10
Developing an ER Diagram
 Tiny College Database (7)
 A student may enroll in several classes, but takes
each class only once during any given enrollment
period.
 Each student may enroll in up to six classes, and
each class may have up to 35 students in it.
enroll
(0,35) (0, 6)

11
Developing an ER Diagram
 Tiny College Database (8)
 Each department has several students whose
major is offered by that department, however
each student has only a single major and
associated with a single department.
 It is possible for a student not to declare a major
field study. Such a student would not be
associated with a department.

12
Developing an ER Diagram
 Tiny College Database (9)
 Each student has an advisor in his or her
department; each advisor counsels several
students.
 An advisor is also a professor, but not all
professors advise students.

13
Components of the ER Model

14
Complete ER Diagram

15
Mapping ER Model to Relational Model
 Mapping an ER model (conceptual model) into
a relational model (logical/internal model)
 Five mapping steps involved:
 Strong entities
 Create one relation for each strong entity
 Supertype/subtype relationships
 Weak entities
 Include the primary key of the parent table (strong
entity) in the weak entity.
 Binary relationships
 Create foreign key as necessary for 1:1, 1:M and M:N
(composite entity) relationships
 Higher degree relationships (ternary)
16
Mapping ER Model to Relational Model
 Example: ARTIST Database
 A painter paint many paintings, each painting is
painted by one (and only one) painter.
 A painting might (or might not) be exhibited in a
gallery; a gallery place at least one painting.

17
Mapping ER Model to Relational Model
 Relations for ARTIST database:
PAINTER(PRT_NUM, PRT_LASTNAME,
PRT_FIRSTNAME, PRT_INITIAL, PTR_AREACODE,
PRT_PHONE)

GALLERY(GAL_NUM, GAL_OWNER, GAL_AREACODE,

GAL_PHONE, GAL_RATE)

PAINTING(PNTG_NUM, PNTG_TITLE, PNTG_PRICE,

PTR_NUM, GAL_NUM)

18
Data Dictionary of ARTIST Database

19
Creating Tables for ARTIST database
 SQL Commands to Create the PAINTER Table

 CREATE TABLE PAINTER (

PTR_NUM CHAR(4) NOT NULL UNIQUE,
PRT_LASTNAME CHAR(15) NOT NULL,
PTR_FIRSTNAME CHAR(15),
PTR_INITIAL CHAR(1),
PTR_AREACODE CHAR(3),
PTR_PHONE CHAR(8),
PRIMARY KEY(PTR_NUM));

20
Creating Tables
 SQL Commands to Create the GALLERY Table

 CREATE TABLE GALLERY (

GAL_NUM CHAR(4) NOT NULL UNIQUE,
GAL_OWNER CHAR(35),
GAL_AREACODE CHAR(3) NOT NULL,
GAL_PHONE CHAR(8) NOT NULL,
GAL_RATE DECIMAL(4,2),
PRIMARY KEY(GAL_NUM));

21
Creating Tables
 SQL Commands to Create the PAINTING Table

 CREATE TABLE PAINTING (

PNTG_NUM CHAR(4) NOT NULL UNIQUE,
PNTG_TITLE CHAR(35),
PNTG_PRICE DECIMAL(9,2),
PTR_NUM CHAR(4) NOT NULL,
GAL_NUM CHAR(4),
PRIMARY KEY(PNTG_NUM)
FOREIGN KEY(PTR_NUM) RERERENCES
PAINTER(PTR_NUM)
ON DELETE RESTRICT
ON UPDATE CASCADE,
FOREIGN KEY(GAL_NUM) REFERENCES
GALLERY(GAL_NUM)
ON DELETE RESTRICT
ON UPDATE CASCADE);
22
Tables for Artist Database

23
Mapping ER Model to Relational Model
 General Rules Governing Relationships among
Tables
 All primary keys must be defined as NOT NULL.
 Define all foreign keys to conform to the following
requirements for binary relationships.
 1:M Relationship
 Weak Entity
 M:N Relationship
 1:1 Relationship

24
Mapping ER Model to Relational Model
 1:M Relationships
 Create the foreign key by putting the primary key
of the “one” (parent) in the table of the “many”
(dependent).
 Foreign Key Rules:
Null On Delete On Update
If both sides are NOT NULL RESTRICT CASCADE
MANDATORY

If both sides are NULL SET NULL CASCADE

OPTIONAL ALLOWED

If one side is NULL SET NULL CASCADE

OPTIONAL and ALLOWED or
the other RESTRICT
MANDATORY

25
Mapping ER Model to Relational Model
 Weak Entity
 Put the key of the parent table (strong entity) in
the weak entity.
 The weak entity relationship conforms to the same
rules as the 1:M relationship, except foreign key
restrictions:
 NOT NULL
 ON DELETE CASCADE
 ON UPDATE CASCADE

26
Mapping ER Model to Relational Model
 M:N Relationship
 Convert the M:N relationship to a composite
(bridge) entity consisting of (at least) the parent
tables’ primary keys.

 1:1 Relationships
 If both entities are in mandatory participation in
the relationship and they do not participate in
other relationships, it is most likely that the two
entities should be part of the same entity.

27
Mapping ER Model to Relational Model
 CASE 1: M:N, Both Sides MANDATORY

Rules: A student can enroll in many

class. A class is enrolled by many
students.

28
Mapping ER Model to Relational Model
 CASE 2: M:N, Both Sides OPTIONAL

Rules: A student may enroll in many

classes. A class may enroll by
many students.

29
Mapping ER Model to Relational Model
 CASE 3: M:N, One Side OPTIONAL

Rules: A student can enroll in many

class. A class may enroll by many
students.

30
Mapping ER Model to Relational Model
 CASE 4: 1:M, Both Sides MANDATORY

31
Mapping ER Model to Relational Model
 CASE 5: 1:M, Both Sides OPTIONAL

32
Mapping ER Model to Relational Model
 CASE 6: 1:M, Many Side OPTIONAL, One Side
MANDATORY

33
Mapping ER Model to Relational Model
 CASE 7: 1:M, One Side OPTIONAL, One Side
MANDATORY

34
Mapping ER Model to Relational Model
 CASE 8: 1:1, Both Sides MANDATORY

35
Mapping ER Model to Relational Model
 CASE 9: 1:1, Both Sides OPTIONAL

36
Mapping ER Model to Relational Model
 CASE 10: 1:1, One Side OPTIONAL, One Side
MANDATORY

37
Mapping ER Model to Relational Model
 CASE 11: Weak Entity
(Foreign key located in weak entity)

38
Mapping ER Model to Relational Model
 CASE 12: Multivalued Attributes

CAR ( CAR_NUM, CAR_REG, CAR_OWNER)

COLOUR (COLOUR_ID, COLOUR_DESC, CAR_NUM)

39
Database Design Challenges:
Conflicting Goals
 Database designers must make design
compromises
 Conflicting goals: design standards, processing
speed, information requirements
 Important to meet logical requirements and
design conventions
 Design is of little value unless it delivers all
specified query and reporting requirements
 Some design and implementation problems do
not yield “clean” solutions

40
41
Exercise:
 Suppliers
 Books are purchased from various suppliers. However, none of the
supplier is selling books with similar title. Each supplier has a unique
number. The data stored on supplier includes supplier id, supplier
name, name of contact person, mobile number, office number,
email, and address.
 Books
 The store has various kinds of books. It has English books, Chinese
books and Malay books. The target audience of books ranged from
age 2 to 99. Some of the book categories are Art, Travel, Agriculture,
Medical, Music, Fiction, Computer, Social Science, and Travel. Each
book is identified through the ISBN. The data stored on book are:
ISBN, title, authors, year of publish, price (cost), price (selling),
quantity on hand, publisher, category and language.
 Based on the information above, how will you
describe the operation by using business rules?
 Please illustrate the ERD based on your business

42rules.