Republic of the Philippines

NUEVA VIZCAYA STATE UNIVERSITY

Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023

College : College of Engineering

Campus : Bambang Campus

DEGREE PROGRAM BSCPE COURSE NO. CPE6

SPECIALIZATION Information Sys. COURSE TITLE Database Management System
YEAR LEVEL 2nd Year TIME FRAME 3hrs WK NO. 4 - 5 IM NO. 04

I. UNIT TITLE/CHAPTER TITLE

Entity Relationship Diagram
II. LESSON TITLE
1. Data Modeling
2. Describing and Storing Data in Database
3. Data Model Basic Building Blocks
4. Business Rules
5. Evolution of Data Models
6. Degrees of Data Abstraction
III. LESSON OVERVIEW
Data modeling is the first step in the database design journey, serving as a bridge between real-world
objects and the database that resides in the computer. One of the most vexing problems of database
design is that designers, programmers, and end users see data in different ways. Consequently, different
views of the same data can lead to database designs that do not reflect an organization’s actual
operation, failing to meet end-user needs and data efficiency requirements. To avoid such failures,
database designers must obtain a precise description of the nature of the data and of the many uses of
that data within the organization. Communication among database designers, programmers, and end
users should be frequent and clear. Data modeling clarifies such communication by reducing the
complexities of database design to more easily understood abstractions that define entities and the
relations among them.
IV. DESIRED LEARNING OUTCOMES
At the end of the lessons students are able to:
1. Differentiate Concisely define each of the following key terms: business rule, term, fact, entity-
relationship model (E-R model), entity-relationship diagram (E-R diagram), entity, entity type, entity
instance, strong entity type, weak entity type, identifying owner, identifying relationship, attribute,
required attribute, optional attribute, composite attribute, simple attribute, multivalued attribute,
derived attribute, identifier, composite identifier, relationship type, relationship instance, associative
entity, degree, unary relationship, binary relationship, ternary relationship, cardinality constraint,
minimum cardinality, maximum cardinality, and time stamp.
2. State reasons why many system developers believe that data modeling is the most important part of
the systems development process.
3. Write good names and definitions for entities, relationships, and attributes.
4. Distinguish unary, binary, and ternary relationships and give a common example of each.
5. Model each of the following constructs in an E-R diagram: composite attribute, multivalued attribute,
derived attribute, associative entity, identifying relationship, and minimum and maximum cardinality
constraints.
6. Draw an E-R diagram to represent common business situations.
7. Convert a many-to-many relationship to an associative entity type.
8. Model simple time-dependent data using time stamps and relationships in an E-R diagram.

NVSU-FR-ICD-05-00 (081220) Page 1 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023
V. LESSON CONTENT
1. Introduction Overview of database design

You have already been introduced to modeling data and the entity-relationship model in previous
chapter. In this chapter we formalize data modeling based on the powerful concept of business rules
and we describe the entity-relationship (ER) data model in detail. Business rules are derived from
policies, procedures, events, functions, and other business objects, and state constraints on the
organization. Business rules are important in data modeling because they govern how data are
handled and stored. Basic business rules are data names and definitions.

After some years of use, E-R model remains the mainstream approach for conceptual data modeling.
Its popularity stems from factors such as relative ease of use, widespread CASE tool support, and
the belief that entities and relationships are natural modeling concepts in the real world.

The E-R model is most often used as a tool for communications between database designers and
end users during the analysis phase of database development. The E-R model is used to construct
a conceptual data model, which is a representation of the structure and constraints of a database that
is independent of the software and its associated data model that will be used to implement the
database.

The entity-relationship model was introduced in a key article by Chen (1976), in which he described
the main constructs of the E-R model – entities and relationships – and their associated attributes.
The model has subsequently been extended to include additional constructs by Chen and others; for
example, Teorey, Yang, and Fry (1986) and Storey(1991). The E-R model continues to evolve, but
unfortunately there is not yet a standard notation for E-R modeling. Song, Evans, and Park(1995)
present a side-by-side comparison of 10 different E-R modeling notations, explaining the major
advantages of each approach.

Many systems developers believe that data modeling is the most important part of the systems
development process. This belief is based on three important reasons (Hoffer, George, and Valacich,
2002).

a) The characteristics of data captured during data modeling are crucial in the design of databases,
programs, and other system components. The facts and rules captured during the process of data
modeling are essential in assuring data integrity in an information system.

b) Data rather than processes are the most complex aspects of many modern information systems
and hence require a central role in structuring system requirements. Often the goal is to provide
a rich data resource that might support any type of information inquiry, analysis, and summary.

c) Data tend to be more stable than the business processes that use that data. Thus an information
system design that is based on a data orientation should have longer useful life than one based
on a process orientation.

The database design process can be divided into six steps. The ER model is most relevant to the first
three steps.

a) Requirements Analysis: The very first step in designing a database application is to understand
what data is to be stored in the database, what applications must be built on top of it, and what
operations are most frequent and subject to performance requirements. In other words, we must
find out what the users want from the database.

This is usually an informal process that involves discussions with user groups, a study of the
current operating environment and how it is expected to change, analysis of any available
documentation on existing applications that are expected to be replaced or complemented by the
database, and so on. Several methodologies have been proposed for organizing and presenting
the information gathered in this step, and some automated tools have been developed to support
this process.

NVSU-FR-ICD-05-00 (081220) Page 2 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023
b) Conceptual Database Design: The information gathered in the requirements analysis step is
used to develop a high-level description of the data to be stored in the database, along with the
constraints that are known to hold over this data. This step is often carried out using the ER model,
or a similar high-level data model.

c) Logical Database Design: We must choose a DBMS to implement our database design, and
convert the conceptual database design into a database schema in the data model of the chosen
DBMS. We will only consider relational DBMS’s, and therefore, the task in the logical design step
is to convert an ER schema into a relational database schema. The result is a conceptual schema,
sometimes called the logical schema, in the relational data model.

d) Schema Refinement: The fourth step in database design is to analyze the collection of relations
in our relational database schema to identify potential problems, and to refine it. In contrast to the
requirements analysis and conceptual design steps, which are essentially subjective, schema
refinement can be guided by some elegant and powerful theory. (Normalization)

e) Physical Database Design: In this step we must consider typical expected workloads that our
database must support and further refine the database design to ensure that it meets desired
performance criteria. This step may simply involve building indexes on some tables and clustering
some tables, or it may involve a substantial redesign of parts of the database schema obtained
from the earlier design steps.

f) Security Design: In this step, we identify different user groups and different roles played by
various users (e.g., the development team for a product, the customer support representatives,
the product manager). For each role and user group, we must identify the parts of the database
that they must be able to access and the parts of the database that they should not be allowed to
access, and take steps to ensure that they can access only the necessary parts.

*In reality, the six steps are insufficient in creating a complete database system. Implementation
and maintenance of the database system must be included. Some steps are also expected to be
reiterated during the database design until the design is satisfied.

2. The entity relationship (ER) data model

An entity-relationship model (or E-R model) is a detailed, logical representation of the data for an
organization or for a business area. The E-R model is expressed in terms of entities in the business
environment, the relationships (or associations) among those entities, and the attributes (or
properties) of both the entities and their relationships. An E-R model is normally expressed as an
entity-relationship diagram (or E-R diagram), which is a graphical representation of an E-R model.

In E-R model, it allows us to describe the data involved in a real-world enterprise in terms of objects
and their relationships and is widely used to develop an initial database design. It is important
primarily for its role in database design. It provides useful concepts that allow us to move from an
informal description of what users want from their database to a more detailed and precise,
description that can be implemented in a DBMS. It was developed by Peter Chen in the year 1976.

3. Entities, attributes, and domain

The basic constructs of the entity-relationship model are entities, relationships, and attributes.

A. ENTITY
An entity is represented by a rectangle in the ER Diagram. A person, a place, an object, an event,
or a concept in the user environment about which the organization wishes to maintain data.

Person: EMPLOYEE, STUDENT, PATIENT

Place: STORE, WAREHOUSE, STATE
Object: MACHINE, BUILDING, AUTOMOBILE
Event: SALE, REGISTRATION, RENEWAL
Concept: ACCOUNT, COURSE, WORK CENTER

NVSU-FR-ICD-05-00 (081220) Page 3 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023
Tips of identifying entity:
 Nouns and verbs used will be candidate entities
Example: “Customer buys products. Employee sells products. Suppliers sell us products.”
 The Nouns: “Customer, Products, Employees, and Suppliers” are all clearly entities.
 The Verb: “buy and sell” are also entities.
 Input forms, reports and procedures manual are also good sources of candidate entities.
 A review for completeness and consistency must be done after identifying your initial
entities. You need to find for duplicates and distinct entities that are masquerading as the
same entity.

Entity Type (Entity set) An entity set is a set of entities of the same type that share the same
properties, or attributes. The set of all persons who are customers at a given bank, for example, can
be defined as the entity set customer. Similarly, the entity set loan might represent the set of all
loans awarded by a particular bank

Entity Instance – is a single occurrence of an entity type.

Example: A collection of toy department employees and the collection of appliance department
employees may both contain John Doe who happens to work in both departments. We could
also define an entity set called Employee that contains both the toy and appliance department
employee sets.

B. ATTRIBUTES

An attribute is represented by an ellipse in the ER Diagram.

An entity is represented by a set of attributes. Attributes are descriptive properties possessed by

each member of an entity set. An attribute is a property or characteristic of an entity type that is
of interest to the organization.

The designation of an attribute for an entity set expresses that the database stores similar
information concerning each entity in the entity set; however, each entity may have its own value
for each attribute. Possible attributes of the customer entity set are customer-id, customer-name,
customerstreet, and customer-city. In real life, there would be further attributes, such as street
number, apartment number, state, postal code, and country, but we omit them to keep our
examples simple. Possible attributes of the loan entity set are loan-number and amount.

Each entity has a value for each of its attributes. For instance, a particular customer entity may
have the value 321-12-3123 for customer-id, the value Jones for customername, the value Main
for customer-street, and the value Harrison for customer-city.

The customer-id attribute is used to uniquely identify customers, since there may be more than
one customer with the same name, street, and city. In general, the enterprise would have to create
and assign a unique identifier for each customer. In a University student database StudentID is
used to uniquely identify every student because many students may have the same name.

NVSU-FR-ICD-05-00 (081220) Page 4 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023

STUDENT (Student ID, Student Name, Home Address, Phone Number, Major)
AUTOMOBILE (Vehicle ID, Color, Weight, Horsepower)
EMPLOYEE (Employee ID, Employee Name, Payroll Address, Skill)

TIPS OF IDENTIFYING ATTRIBUTES:

 Think of anything that would describe the entity. Items that describe the entity and that need
to be stored.
 Think of the data flows passed by the external entities
 Start with the result and do not make the design more complex that it needs to be.
 Find exceptions – it is important to identify all the exceptions: you must design the system to
handle as many exceptions as you can without confusing users.
 NOTE: Attributes do not have to be recognized and defined during the early stages of entity
definition. Entity definition is an iterative process, and it is unlikely that a completely
satisfactory Entity-Relationship Model will be obtained on the first iteration.

CATEGORIES OF ATTRIBUTES:
 Descriptive Attributes – provide facts intrinsic to each instance of the entity. For example,
the Salary of Employee or the Address of Customer.

 Naming Attributes – provide facts about arbitrary labels and names carried by each instance
of an entity. For example, the Employee Name of Employee or the Employee ID of
Employee.

 Referential Attributes (Foreign keys) – provide facts which tie an instance of one entity to an
instance of another entity. For example, the Department Number of the Department to which
an Employee is assigned ties the Employee to the Department.

TYPES OF ATTRIBUTE:

 Simple and composite attributes. In our examples thus far, the attributes have been simple;
that is, they are not divided into subparts.

Sex is a simple attribute because it can no longer be broken into sub parts.

 Composite attributes, on the other hand, can be divided into subparts (that is, other
attributes). For example, an attribute name could be structured as a composite attribute
consisting of first-name, middle-initial, and last-name. Using composite attributes in a design
schema is a good choice if a user will wish to refer to an entire attribute on some occasions,
and to only a component of the attribute on other occasions. Composite attributes help us to
group together related attributes, making the modeling cleaner.

Name is a composite attribute because it can be broken into or composed of Firstname, Middle
Initial and Lastname.

Note also that a composite attribute may appear as a hierarchy. In the composite attribute address,
its component attribute street can be further divided into street-number, street-name, and
apartment-number

NVSU-FR-ICD-05-00 (081220) Page 5 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023

 Single-valued, Null and multi-valued attributes – Single-valued attribute has only one value
while a Null might have a zero value and multi valued has more than one values. The attributes
in our examples all have a single value for a particular entity. For instance, the loan-number
attribute for a specific loan entity refers to only one loan number. Such attributes are said to
be single valued. There may be instances where an attribute has a set of values for a specific
entity. Consider an employee entity set with the attribute phone-number. An employee may
have zero, one, or several phone numbers, and different employees may have different
numbers of phones. This type of attribute is said to be multivalued.

• Birthdate for instance is a single valued attribute because there can only be one date of birth by
an individual for a moment of time.
• Job if for instance an individual is not yet employed or has no work yet then the value of job
for an entity maybe set to null or nothing.
• MobileNo is considered to be multi-valued attribute because for an individual he may have
more than one mobile number at a given time.

 Derived attribute – are attributes that can be derived from the values of other related
attributes or entities using calculations, algorithms or procedures.

Age is a said to be a derived attribute because given the birthdate of an individual you can compute
the value for the age.

C. DOMAIN

Each attribute must have a domain. Specifies the kind of data represented by the attribute. It is a
set of all possible values that an attribute may validly contain.

Example:
Age: range 0 to 120,
Sex: character with values ‘M’ or ‘F’
DataOfBirth: Date,
FirstName: 50 characters string
name of employee might be the set of 20 character strings
age is set to 2-digit number (such value of age is from 01 – 99)
 It might be a combination of data type and validation rule. But domain is for logical schema
while data type is for the physical schema and validation rule is a part of data integrity.
 We can easily define a domain for an attribute by considering the following below:
 List all possible values (e.g., for an attribute named color, possible values are red, green,
blue, etc).
 Identify source (e.g., procedures manual) that contains the valid values.
 List an acceptable range of values for the domain (e.g., for an attribute named weight,
possible values range from one to five pounds)
 Define a business rule that permits determination of validity of a value assigned to an
attribute (e.g., discount greater than five percent only apply to commercial customers)

NVSU-FR-ICD-05-00 (081220) Page 6 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023
4. Relationships and relationship sets

A relationship is an association among several entities. For example, we can define a relationship
that associates customer Hayes with loan L-15. This relationship specifies that Hayes is a customer
with loan number L-15. A relationship set is a set of relationships of the same type.

Consider the two entity sets customer and loan. We define the relationship set borrower to denote
the association between customers and the bank loans that the customers have.

The association between entity sets is referred to as participation; that is, the entity sets E1, E2,...,En
participate in relationship set R. A relationship instance in an E-R schema represents an association
between the named entities in the real-world enterprise that is being modeled.
A relationship may also have attributes called descriptive attributes.

The number of entity sets that participate in a relationship set is also the degree of the relationship
set. A binary relationship set is of degree 2; a ternary relationship set is of degree 3. In an instance
that an entity is directly related to itself is called a unary relationship.

5. Constraints

An E-R enterprise schema may define certain constraints to which the contents of a database must
conform. In this section, we examine mapping cardinalities and participation constraints, which are
two of the most important types of constraints.

1. Mapping Cardinalities

Mapping cardinalities, or cardinality ratios, express the number of entities to which another
entity can be associated via a relationship set.

Mapping cardinalities are most useful in describing binary relationship sets, although they can
contribute to the description of relationship sets that involve more than two entity sets. In this
section, we shall concentrate on only binary relationship sets.

For a binary relationship set R between entity sets A and B, the mapping cardinality must be
one of the following:

 One to one. An entity in A is associated with at most one entity in B, and an entity in B is
associated with at most one entity in A.
 One to many. An entity in A is associated with any number (zero or more) of entities in B. An
entity in B, however, can be associated with at most one entity in A.
 Many to one. An entity in A is associated with at most one entity in B. An entity in B, however,
can be associated with any number (zero or more) of entities in A.
 Many to many. An entity in A is associated with any number (zero or more) of entities in B,
and an entity in B is associated with any number (zero or more) of entities in A.

(a) One to one (b) One to Many

NVSU-FR-ICD-05-00 (081220) Page 7 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023

The appropriate mapping cardinality for a particular relationship set obviously depends on the real-world
situation that the relationship set is modeling.

(a) Many to one (b) Many to Many

2. Participation Constraints

The participation of an entity set E in a relationship set R is said to be total or mandatory if every
entity in E participates in at least one relationship in R. If only some entities in E participate in
relationships in R, the participation of entity set E in relationship R is said to be partial or optional.
For example, we expect every loan entity to be related to at least one customer through the
borrower relationship. Therefore; the participation of loan in the relationship set borrower is total.
In contrast, an individual can be a bank customer whether or not she has a loan with the bank.
Hence, it is possible that only some of the customer entities are related to the loan entity set
through the borrower relationship, and the participation of customer in the borrower relationship
set is therefore partial.

6. Keys

We must have a way to specify how entities within a given entity set are distinguished. Conceptually,
individual entities are distinct; from a database perspective, however, the difference among them
must be expressed in terms of their attributes. Therefore, the values of the attribute values of an entity
must be such that they can uniquely identify the entity. In other words, no two entities in an entity set
are allowed to have exactly the same value for all attributes. A key allows us to identify a set of
attributes that suffice to distinguish entities from each other. Keys also help uniquely identify
relationships, and thus distinguish relationships from each other.

A. Superkey
A superkey is a set of one or more attributes that, taken collectively, allow us to identify uniquely an
entity in the entity set. For example, the customer-id attribute of the entity set customer is sufficient
to distinguish one customer entity from another. Thus, customer-id is a superkey. Similarly, the
combination of customer-name and customer-id is a superkey for the entity set customer. The
customer-name attribute of customer is not a superkey, because several people might have the same
name.

B. Candicate Key
It is possible that several distinct sets of attributes could serve as a candidate key. Suppose that a
combination of customer-name and customer-street is sufficient to distinguish among members of
the customer entity set. Then, both {customer-id} and {customer-name, customer-street} are
candidate keys. Although the attributes customerid and customer-name together can distinguish
customer entities, their combination does not form a candidate key, since the attribute customer-id
alone is a candidate key.

NVSU-FR-ICD-05-00 (081220) Page 8 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023
C. Primary Key
We shall use the term primary key to denote a candidate key that is chosen by the database designer
as the principal means of identifying entities within an entity set. A key (primary, candidate, and super)
is a property of the entity set, rather than of the individual entities. Any two individual entities in the
set are prohibited from having the same value on the key attributes at the same time. The designation
of a key represents a constraint in the real-world enterprise being modeled.

7. Entity-relationship diagram

An E-R diagram can express the overall logical structure of a database graphically. E-R diagrams
are simple and clear—qualities that may well account in large part for the widespread use of the E-
R model. Such a diagram consists of the following major components:

 Rectangles, which represent entity sets

 Ellipses, which represent attributes
 Diamonds, which represent relationship sets
 Lines, which link attributes to entity sets and entity sets to relationship sets
 Double ellipses, which represent multivalued attributes
 Dashed ellipses, which denote derived attributes
 Double lines, which indicate total participation of an entity in a relationship set
 Double rectangles, which represent weak entity sets

Symbols used in the ER Diagram

NVSU-FR-ICD-05-00 (081220) Page 9 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023

Martin Style: An alternative ER notations

Information Engineering Notations: An alternative ER notations

Note: The choice of using ER notations depends on you are most familiar or comfortable
with. Consistency is what matters and that different notations from differing styles should not
mixed up.

NVSU-FR-ICD-05-00 (081220) Page 10 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023

A. MODELING RELATIONSHIPS
Relationships are the glue that holds together the various components of an E-R model. Intuitively,
a relationship is an association representing an interaction among the instances of one or more
entity types that is of interest to the organization. Thus, a relationship has a verb phrase name.
Relationships and their characteristics (degree and cardinality) represent business rules, and
usually relationships represent the most complex business rules shown in an ERD. In other words,
this is where data modeling gets really interesting and fun, as well as crucial for controlling the
integrity of a database.

A relationship type is a meaningful association between (or among) entity types. The phrase
meaningful association implies that the relationship allows us to answer questions that could not
be answered given only the entity types. A relationship type is denoted by a line labeled with
the name of the relationship, as in the example shown in figure below. We suggest you use a
short, descriptive verb phrase that is meaningful to the user in naming the relationship.
A relationship instance is an association between (or among) entity instances, where each
relationship instance associates exactly one entity instance from each participating entity type
(Elmasri and Navathe, 1994). For example, in figure below, each of the 10 lines in the figure
represents a relationship instance between one employee and one course, indicating that the
employee has completed that course. For example, the line between Employee Ritchie to Course
Perl is one relationship instance.

Relationship Type

Relationship Instance

NVSU-FR-ICD-05-00 (081220) Page 11 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023

B. DEGREE OF RELATIONSHIP
The degree of a relationship is the number of entity types that participate in that relationship.
The three most common relationship degrees in E-R models are unary (degree 1), binary
(degree 2), and ternary (degree 3). Higher degree relationships are possible, but they are rarely
encountered in practice, so we restrict our discussion to these three cases. Examples of unary,
binary, and ternary relationships appear in figure below. (Attributes are not shown in some figures
for simplicity.)

A unary relationship is a relationship between the instances of a single entity type. (Unary
relationships are also called recursive relationships.) Three examples are shown in. In the first
example, Is Married To is shown as a one-to-one relationship between instances of the PERSON
entity type.

A binary relationship is a relationship between the instances of two entity types and is the most
common type of relationship encountered in data modeling.

NVSU-FR-ICD-05-00 (081220) Page 12 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023

A ternary relationship is a simultaneous relationship among the instances of three entity types.
A typical business situation that leads to a ternary relationship is shown in figure below. In this
example, vendors can supply various parts to warehouses. The relationship Supplies is used to
record the specific parts that are supplied by a given vendor to a particular warehouse.

Consider the entity-relationship diagram shown below, which consists of two entity sets, customer
and loan, related through a binary relationship set borrower. The attributes associated with
customer are customer-id, customer-name, customer-street, and customer-city. The attributes
associated with loan are loan-number and amount.

Attributes of an entity set that are members of the primary key are underlined. The relationship
set borrower may be many-to-many, one-to-many, many-to-one, or one-to-one. To distinguish
among these types, we draw either a directed line (→) or an undirected line (—) between the
relationship set and the entity set in question

An ER Diagram corresponds to customer and loan

If the relationship set borrower were one-to-many, from customer to loan, then the line from
borrower to customer would be directed, with an arrow pointing to the customer entity set as
shown on the next page. Similarly, if the relationship set borrower were many-to-one from
customer to loan, then the line from borrower to loan would have an arrow pointing to the loan
entity set. Finally, if the relationship set borrower were one-to-one, then both lines from borrower
would have arrows:

NVSU-FR-ICD-05-00 (081220) Page 13 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023

Relationships. (a) one to many. (b) many to one. (c) one-to-one.

If a relationship set has also some attributes associated with it, then we link these attributes to
that relationship set. For example, we have the accessdate descriptive attribute attached to the
relationship set depositor to specify the most recent date on which a customer accessed that
account.

Relationship with attribute

The next figure shows how composite attributes can be represented in the E-R notation. Here, a
composite attribute name, with component attributes first-name, middle-initial, and last-name
replaces the simple attribute customer-name of customer. Also, a composite attribute address,
whose component attributes are street, city, state, and zip-code replaces the attributes customer-
street and customer-city of customer. The attribute street is itself a composite attribute whose
component attributes are street-number, street-name, and apartment number. The figure also
illustrates a multivalued attribute phone-number, depicted by a double ellipse, and a derived
attribute age, depicted by a dashed ellipse.

NVSU-FR-ICD-05-00 (081220) Page 14 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023

E-R diagram with composite, multivalued, and derived attributes.

We indicate roles in E-R diagrams by labeling the lines that connect diamonds to rectangles. The
figure below shows the role indicators manager and worker between the employee entity set and
the works-for relationship set. The figure also demonstrates a unary relationship.

E-R diagram a unary relationship with role indicators.

E-R diagram with a ternary relationship

Total participation of an entity set in a relationship set.

NVSU-FR-ICD-05-00 (081220) Page 15 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023

Cardinality limits on relationship sets.

C. WEAK ENTITY SETS

An entity set may not have sufficient attributes to form a primary key. Such an entity set is termed
a weak entity set. An entity set that has a primary key is termed a strong entity set.

As an illustration, consider the entity set payment, which has the three attributes: payment-
number, payment-date, and payment-amount. Payment numbers are typically sequential
numbers, starting from 1, generated separately for each loan. Thus, although each payment entity
is distinct, payments for different loans may share the same payment number. Thus, this entity
set does not have a primary key; it is a weak entity set.

For a weak entity set to be meaningful, it must be associated with another entity set, called the
identifying or owner entity set. Every weak entity must be associated with an identifying entity;
that is, the weak entity set is said to be existence dependent on the identifying entity set. The
identifying entity set is said to own the weak entity set that it identifies. The relationship associating
the weak entity set with the identifying entity set is called the identifying relationship. The
identifying relationship is many to one from the weak entity set to the identifying entity set, and
the participation of the weak entity set in the relationship is total.

Although a weak entity set does not have a primary key, we nevertheless need a means of
distinguishing among all those entities in the weak entity set that depend on one particular strong
entity. The discriminator of a weak entity set is a set of attributes that allows this distinction to
be made. The discriminator of a weak entity set is also called the partial key of the entity set.

The primary key of a weak entity set is formed by the primary key of the identifying entity set, plus
the weak entity set’s discriminator. In the case of the entity set payment, its primary key is {loan-
number, payment-number}, where loan-number is the primary key of the identifying entity set,
namely loan, and payment-number distinguishes payment entities within the same loan.

E-R diagram with a weak entity set

Note: All multi-valued attribute shall be converted to a weak entity set mapped into its parent entity.

NVSU-FR-ICD-05-00 (081220) Page 16 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023
D. EXTENDED ER FEATURES

Although the basic E-R concepts can model most database features, some aspects of a database may be
more aptly expressed by certain extensions to the basic E-R model. In this section, we discuss the extended
E-R features of specialization, generalization, higher- and lower-level entity sets, attribute inheritance, and
aggregation.

a. Specialization

An entity set may include subgroupings of entities that are distinct in some way from other
entities in the set. For instance, a subset of entities within an entity set may have attributes
that are not shared by all the entities in the entity set. The E-R model provides a means for
representing these distinctive entity groupings.

Consider an entity set person, with attributes name, street, and city. A person may be further
classified as one of the following:

 customer
 employee

Each of these person types is described by a set of attributes that includes all the attributes
of entity set person plus possibly additional attributes. For example, customer entities may be
described further by the attribute customer-id, whereas employee entities may be described
further by the attributes employee-id and salary.

The process of designating subgroupings within an entity set is called specialization. The
specialization of person allows us to distinguish among persons according to whether they
are employees or customers.

b. Generalization

The refinement from an initial entity set into successive levels of entity subgroupings
represents a top-down design process in which distinctions are made explicit. The design
process may also proceed in a bottom-up manner, in which multiple entity sets are
synthesized into a higher-level entity set on the basis of common features. The database
designer may have first identified a customer entity set with the attributes name, street, city,
and customer-id, and an employee entity set with the attributes name, street, city, employee-
id, and salary.

There are similarities between the customer entity set and the employee entity set in the sense
that they have several attributes in common. This commonality can be expressed by
generalization, which is a containment relationship that exists between a higher-level entity
set and one or more lower-level entity sets. In our example, person is the higher-level entity
set and customer and employee are lower-level entity sets. Higher- and lower-level entity sets
also may be designated by the terms superclass and subclass, respectively. The person entity
set is the superclass of the customer and employee subclasses.

For all practical purposes, generalization is a simple inversion of specialization.

In terms of an E-R diagram, specialization is depicted by a triangle component labeled ISA,

as the figure below shows. The label ISA stands for “is a” and represents, for example, that a
customer “is a” person. The ISA relationship may also be referred to as a superclass-subclass
relationship. Higher- and lower-level entity sets are depicted as regular entity sets—that is, as
rectangles containing the name of the entity set.

NVSU-FR-ICD-05-00 (081220) Page 17 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023

Specialization and generalization

c. Attribute Inheritance

A crucial property of the higher- and lower-level entities created by specialization and generalization
is attribute inheritance. The attributes of the higher-level entity sets are said to be inherited by the lower-
level entity sets. For example, customer and employee inherit the attributes of person. Thus, customer
is described by its name, street, and city attributes, and additionally a customer-id attribute; employee
is described by its name, street, and city attributes, and additionally employee-id and salary attributes.
A lower-level entity set (or subclass) also inherits participation in the relationship sets in which its
higher-level entity (or superclass) participates. The officer, teller, and secretary entity sets can
participate in the works-for relationship set, since the superclass employee participates in the works-
for relationship. Attribute inheritance applies through all tiers of lower-level entity sets. The above
entity sets can participate in any relationships in which the person entity set participates. Whether a
given portion of an E-R model was arrived at by specialization or generalization, the outcome is
basically the same:

 A higher-level entity set with attributes and relationships that apply to all of its lower-level entity
sets
 Lower-level entity sets with distinctive features that apply only within a particular lower-level
entity set

NVSU-FR-ICD-05-00 (081220) Page 18 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023
d. Aggregation

One limitation of the E-R model is that it cannot express relationships among relationships.
To illustrate the need for such a construct, consider the ternary relationship works-on, which
we saw earlier, between an employee, branch, and job shown on the next figure. Now,
suppose we want to record managers for tasks performed by an employee at a branch; that
is, we want to record managers for (employee, branch, job) combinations. Let us assume that
there is an entity set manager.

One alternative for representing this relationship is to create a quaternary relationship

manages between employee, branch, job, and manager. (A quaternary relationship is
required—a binary relationship between manager and employee would not permit us to
represent which (branch, job) combinations of an employee are managed by which manager.)
Using the basic E-R modeling constructs, we obtain the E-R diagram on the next figure. (We
have omitted the attributes of the entity sets, for simplicity.)

E-R diagram with redundant relationships E-R diagram with aggregation

NVSU-FR-ICD-05-00 (081220) Page 19 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023

ER diagram for a banking enterprise.

Tips for Effective ER Diagrams:

1. Make sure that each entity only appears once per diagram.
2. Name every entity, relationship, and attribute on your diagram.
3. Examine relationships between entities closely. Are they necessary? Are there
any relationships missing? Eliminate any redundant relationships. Don't connect
relationships to each other.
4. Use colors to highlight important portions of your diagram

NVSU-FR-ICD-05-00 (081220) Page 20 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023

Sample Problem

UPS prides itself on having up-to-date information on the processing and current location
of each shipped item. To do this, UPS relies on a company-wide information system. Shipped
items are the heart of the UPS product tracking information system. Shipped items can be
characterized by item number (unique), weight, dimensions, insurance amount, destination, and
final delivery date. Shipped items are received into the UPS system at a single retail center. Retail
centers are characterized by their type, uniqueID, and address. Shipped items make their way to
their destination via one or more standard UPS transportation events (i.e., flights, truck deliveries).
These transportation events are characterized by a unique scheduleNumber, a type (e.g, flight,
truck), and a deliveryRoute.

Please create an Entity Relationship diagram that captures this information about the UPS
system. Be certain to indicate identifiers and cardinality constraints.

Solution:

8. Relational Model

In this lesson, we describe logical database design, with special emphasis on the relational data
model. Logical database design is the process of transforming the conceptual data model into a
logical data model— one that is consistent and compatible with a specific type of database
technology. An experienced database designer often will do logical database design in parallel with
conceptual data modeling if he or she knows the type of database technology that will be used. It is,
however, important to treat these as separate steps so that you concentrate on each important part
of database development. Conceptual data modeling is about understanding the organization—
getting the right requirements. Logical database design is about creating stable database structures—
correctly expressing the requirements in a technical language. Both are important steps that must be
performed carefully

NVSU-FR-ICD-05-00 (081220) Page 21 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023

The relational data model was first introduced in 1970 by E. F. Codd, then of IBM (Codd, 1970). Two
early research projects were launched to prove the feasibility of the relational model and to develop
prototype systems. The first of these, at IBM’s San Jose Research Laboratory, led to the development
of System R (a prototype relational DBMS [RDBMS]) during the late 1970s. The second, at the
University of California at Berkeley, led to the development of Ingres, an academically oriented
RDBMS. Commercial RDBMS products from numerous vendors started to appear about 1980. (See
the Web site for this book for links to RDBMS and other DBMS vendors.) Today RDBMSs have
become the dominant technology for database management, and there are literally hundreds of
RDBMS products for computers ranging from smartphones and personal computers to mainframes

Basic Definitions

1. Data structure - Data are organized in the form of tables, with rows and columns.
2. Data manipulation - Powerful operations (using the SQL language) are used to manipulate data
stored in the relations.
3. Data integrity - The model includes mechanisms to specify business rules that maintain the
integrity of data when they are manipulated.

EMPLOYEE1 relation with sample data

RELATIONAL DATA STRUCTURE

A relation is a named, two-dimensional table of data. Each relation (or table) consists of a set of
named columns and an arbitrary number of unnamed rows. An attribute, is a named column of a
relation. Each row of a relation corresponds to a record that contains data (attribute) values for a
single entity. The above figure shows an example of a relation named EMPLOYEE1. This relation
contains the following attributes describing employees: EmpID, Name, DeptName, and Salary. The
five rows of the table correspond to five employees. It is important to understand that the sample data
are intended to illustrate the structure of the EMPLOYEE1 relation; they are not part of the relation
itself. Even if we add another row of data to the figure or change any of the data in the existing rows,
it is still the same EMPLOYEE1 relation. Nor does deleting a row change the relation. In fact, we
could delete all of the rows shown in figure, and the EMPLOYEE1 relation would still exist. In other
words, the figure is an instance of the EMPLOYEE1 relation.

We can express the structure of a relation by using a shorthand notation in which the name of the
relation is followed (in parentheses) by the names of the attributes in that relation. For EMPLOYEE1
we would have:

A primary key is an attribute or a combination of attributes that uniquely identifies each row in a
relation. We designate a primary key by underlining the attribute name(s). For example, the primary
key for the relation EMPLOYEE1 is EmpID.

NVSU-FR-ICD-05-00 (081220) Page 22 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023
A composite key is a primary key that consists of more than one attribute. For example, the primary
key for a relation DEPENDENT would likely consist of the combination EmpID and DependentName.

A foreign key is an attribute (possibly composite) in a relation that serves as the primary key of
another relation. For example, consider the relations EMPLOYEE1 and DEPARTMENT:

The attribute DeptName is a foreign key in EMPLOYEE1. It allows a user to associate any employee
with the department to which he or she is assigned. Some authors emphasize the fact that an attribute
is a foreign key by using a dashed underline, like this:

INTEGRITY CONSTRAINTS

The relational data model includes several types of constraints, or rules limiting acceptable values
and actions, whose purpose is to facilitate maintaining the accuracy and integrity of data in the
database. The major types of integrity constraints are domain constraints, entity integrity, and
referential integrity.

Domain Constraints - All of the values that appear in a column of a relation must be from the same
domain. A domain is the set of values that may be assigned to an attribute. A domain definition usually
consists of the following components: domain name, meaning, data type, size (or length), and
allowable values or allowable range (if applicable).

Entity Integrity - The entity integrity rule is designed to ensure that every relation has a primary key
and that the data values for that primary key are all valid. In particular, it guarantees that every primary
key attribute is non-null.

Referential Integrity - In the relational data model, associations between tables are defined through
the use of foreign keys. For example, the association between the CUSTOMER and ORDER tables
is defined by including the CustomerID attribute as a foreign key in ORDER. This of course implies
that before we insert a new row in the ORDER table, the customer for that order must already exist
in the CUSTOMER table. A referential integrity constraint is a rule that maintains consistency
among the rows of two relations. The rule states that if there is a foreign key in one relation, either
each foreign key value must match a primary key value in another relation or the foreign key value
must be null.

Conversion of ER Diagrams to Table or Relation

Transforming tables consist of two steps: represent entities and represent relationships.

NVSU-FR-ICD-05-00 (081220) Page 23 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023
 Represent Entities: Entity type in an ER diagram is transformed into a relation. The primary key of
the entity type becomes the primary key of the corresponding relation. Each non-key attribute of the
entity type becomes a non-key attribute of the relation. The relations that are formed form entity types
may be modified as relationships are represented.
 Represent Relationship: The procedure for representing relationships depends on both the degree
of the relationship and the cardinalities of the relationship.

Transforming ER diagram into Relations - During logical design, you transform the E-R (and EER)
diagrams that were developed during conceptual design into relational database schemas. The inputs
to this process are the entity-relationship (and enhanced E-R) diagrams. The outputs are the
relational schemas described in the first two sections of this chapter

In transforming or converting ER Diagrams to the overall schema or database structure follows the
transformation rules.

The transformation rules will tell or guide as to what attributes your relation table will consist and hold.

Multi-Valued Attributes shall be converted as a Weak Entity mapped to its parent entity having a
One-to-many Relationship.

The following rules illustrate different cases, consider the following definitions:

A. One-to-One Relationship

NVSU-FR-ICD-05-00 (081220) Page 24 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023

B. One-to-Many Relationship

NVSU-FR-ICD-05-00 (081220) Page 25 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023
C. Many-to-Many Relationship

There will always be three tables/relations in all cases.

Illustrative Example

NVSU-FR-ICD-05-00 (081220) Page 26 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023

Generalization or Specialization hierarchy - depicts the parent-child relationship between

a higher-level supertype entity and a lower-level subtype entity in the hierarchical database
model.

Supertype – contains the shared attributes

Subtype – contains the unique attributes.

Note: Transformation of Generalization and Specialization follows the One-to-One

Transformation rules

NVSU-FR-ICD-05-00 (081220) Page 27 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”
 Republic of the Philippines
NUEVA VIZCAYA STATE UNIVERSITY
Bambang, Nueva Vizcaya
INSTRUCTIONAL MODULE
IM No.04: CPE6-1S-2022-2023
VI. EVALUATION (Note: Not to be included in the student’s copy of the IM)

VII. LEARNING ACTIVITIES: For the following narratives draw an E-R diagram that indicates the entity sets
and their attributes. Identify and label significant relationship sets between pairs of entities, the degree of
relationship sets and the cardinality and participation constraints. Handwritten in a long bond paper
(Deadline: To be posted)

1. Pocket Book Readers World maintains information about its day to day operations. The business is
maintaining pocket books being borrowed by its registered members. Anyone who would like to
borrow pocket books needed to be registered. Once a member is registered he or she can at any
time borrow one to any number of available books. In every instance where a borrower would takeout
item/s a sales clerk who is an employee has to record this transaction

2. A Farmland to Subdivisions Development Inc. has set of Home Owners each of whom owns one or
more houses. Each house has at least one to any number of residents. Derive attributes where
possible. Construct an initial entity relationship diagram. Transform the ER diagram to the overall
database structure.

VIII. ASSIGNMENT: draw an E-R diagram that indicates the entity sets and their attributes. Identify and label
significant relationship sets between pairs of entities, the degree of relationship sets and the cardinality
and participation constraintsHandwritten in a long bond paper (Deadline: To be posted)
1. Book Printing Database
Information needs to be stored about books. Each book is uniquely identified by its ISBN. Other
information about a book includes its title and publication date. In addition to book information
there is also information stored about the book’s publisher. This includes a unique publisher
identifier, publisher name, and publishers address. A book can only be published by a single
publisher. Information on the authors of a book is also stored. This information includes the
author’s social security number, name and address. Any single book can be written by either a
single author or several authors. When the book is printed, it is sent to printer. Information about
the printer includes a unique printer identifier, printer name, and address. A contract is written that
indicates the number of books the printer will print and the printing deadline the printer needs to
meet. At times, a single book might be contracted to several printers if the quantity required to be
printed exceeds the printer’s production capacity.
2. REFERENCES
Books
Begg, C., Connolly, T. (2015). Database Systems: A Practical Approach to Design, Implementation, and
Management. Pearson Education Limited.
Churcher, C. (2014). Beginning Database Design: From Novice to Professional., Apress Publishing.
Coronel, M., Coronel R. (2011). Database Systems: Design Implementation and Management, Cengage Learning.
Online References:
Frisendal, T. (2018). History of Data Modeling. Retrieved from http://graphdatamodeling.com/
GraphDataModeling/History.html

DBMS Tutorial (n.d.). Retrieved from https://www.w3schools.in/dbms/

DBMS Tutorial (n.d.). Retrieved from https://www.javatpoint.com/dbms-tutorial

Ultimate Entity Relationship Diagram Tutorial (ER Diagrams). Retrieved from https://creately.com/blog
/diagrams/er-diagrams-tutorial/

ER Diagram Tutorial in DBMS (with Example). (n.d). Retrived from https://www.guru99.com/er-

diagram-tutorial-dbms.html

NVSU-FR-ICD-05-00 (081220) Page 28 of 28

“In accordance with Section 185, Fair Use of Copyrighted Work of
Republic Act 8293, the copyrighted works included in this material may
be reproduced for educational purposes only and not for commercial distribution”