RELATIONAL DATA MODEL

OVERVIEW
Among the different database management systems, the relational data model is one which is
the most used and most dominant. It has gained popularity because of its simplicity,
robustness, performance, and scalability. Its query language is also easy to use and is almost
compatible with the different types of RDBMS in the market.

LEARNING OUTCOMES:
At the end of this module, the student is expected to :
➢ Demonstrate a thorough understanding of a relational data model
➢ Explain the different relational keys
➢ Explain the use and importance of integrity constraints
➢ Apply the concept of normalization and its importance in database design
➢ Create fully normalized relations

COURSE MATERIALS
Relational Data Model
▪ Represent data in the form of tables
▪ A named, two-dimensional table is called a relation
▪ Each relation consists of named columns and an arbitrary number of unnamed rows
▪ A named column is called an attribute
▪ Each row of a relation corresponds to a record that contains data

Properties of a Relation
1. It has a unique name
2. No multivalued attributes are allowed in a relation
3. Each row is unique
4. Each attribute has a unique name
5. The sequence of columns as well as of rows is insignificant

Classification of Attributes
▪ Required vs. Optional Attributes
o Required – must have a value
o Optional – may not have a value
▪ Simple vs. Composite Attributes
o Simple (or atomic) - cannot be broken down into smaller components
o Composite – has meaningful component parts
▪ Single-valued vs. Multivalued Attributes
o Single-valued – attribute which has only one value
o Multivalued Attributes – attribute that may take on more than one value
 ▪ Stored vs. Derived Attributes
o Stored – value is provided by user
o Derived – value is computed or derived from another attribute/s
▪ Identifier – an attribute or combination of attribute whose value distinguishes instances
of an entity type
o Must not change in value
o Must not be null
o Must be unique

Examples : Classification of Attributes (for a given form for an insurance application)

▪ Required vs. Optional Attributes
o Required – medical condition, attributes pertaining to co-morbidities
o Optional – provincial address
▪ Simple vs. Composite Attributes
o Simple (or atomic) - Age
o Composite – Name, can be broken down into first name, middle and last name
▪ Single-valued vs. Multivalued Attributes
o Single-valued – Birthdate
o Multivalued Attributes – Contact number (may have more than 1 phone number)
▪ Stored vs. Derived Attributes
o Stored – Name
o Derived – Age (can be derived from birthdate)
▪ Identifier – an attribute or combination of attribute whose value distinguishes instances
of an entity type - Account number (assigned by the insurance company)

Relation Employee with the attributes inside the parenthesis, empid, name, depname,
employstatus
EMPLOYEE(EmpID, Name, DeptName, EmployStatus)

Relational Keys
Primary Key – an attribute or a combination of attributes that uniquely identifies each row in a
relation
Composite key – a primary key that consists of more than one attribute
Foreign Key – attribute used to establish the relationship between two tables. A foreign key in a
table/relation always point to the primary key of another table/relation
Cust_ID is a foreign key in ORDER_T. It allows an order to be associated with a particular
customer in the CUSTOMER_T table.

Integrity Constraints - Rules limiting acceptable values and actions, to facilitate maintaining
the accuracy and integrity of data
▪ Domain Constraints – Domain is a set of values that can be assigned to an attribute ; a
domain definition consists of domain name, meaning, data type, size and allowable
values for the domain values
▪ Entity Integrity– ensures that every relation has a valid primary key
▪ Referential Integrity -rule that maintains consistency among the rows of two relations.
The rule states that if there is a foreign key, either each foreign key value must match a
primary key value or the foreign key value must be null.

Database Normalization
Definition
▪ Optimizing table structures
▪ Removing duplicate data entries
▪ Process of efficiently organizing data in the DB.
▪ A technique for producing a set of relations with desirable properties, given the data
requirements of an enterprise.
▪ a formal method that identifies relations based on their primary key and the functional
dependencies among their attributes.

Why Normalize?
▪ Improved speed
▪ More efficient use of space (Eliminate redundant data in a DB)
▪ Ensure data dependencies make sense
▪ Increased data integrity - decreased chance that data can get messed up due to
maintenance
 (prevent possible corruption of DB stemming from update anomalies -insertion, deletion,
modification).
Tables that are not normalized are susceptible to experiencing modification anomalies
o Insertion Anomaly - occurs when certain attributes cannot be inserted into
the database without the presence of other attributes
o Update Anomaly - exists when one or more instances of duplicated data is
updated, but not all
o Deletion Anomaly - exists when certain attributes are lost because of
the deletion of other attributes

Terminologies
Functional dependency: Describes the relationship between attributes in a relation.
If A and B are attributes of a relation R, B is functionally dependent on A, if each value of A in R
is associated with exactly one value of B in R.
B is functionally dependent on A
A B

Example : Given an ISBN, one would know the title of a book, Title is functionally dependent
on ISBN
ISBN Title
Determinant: attribute or set of attributes on the left hand side of the arrow. ISBN is the
determinant for the given example.
Unnormalized form (UNF): A table that contains one or more repeating groups.

Repeating group: an attribute or group of attributes within a table that occurs with multiple
values for a single occurrence of the nominated key attributes of that table.
Example of a table in unnormalized form (see figure below). ProdID, ProductDescription,
ProdFinish, UnitPrice, OrderedQty are multivalued attributes. They have more than one value
in the table. In this example, 1 order ID (1006) has 3 products (product IDs 7, 5, and 4).
 PROCESS OF NORMALIZATION

First normal form (1NF): A relation in which the intersection of each row and column contains one
and only one value, meaning there are no repeating groups.

First normal form (UNF → 1NF): Remove repeating groups:

Enter appropriate data in the empty columns of rows.
Place repeating data along with a copy of the original key attribute in a separate relation.
Identifying a primary key for each of the new relations.

In the UNF example above, below is the table in the 1NF, repeating groups removed, each of
the products are now in different records

Second normal form (1NF -> 2NF): A relation that is in 1NF and with no partial dependencies.
Remove partial functional dependencies.

1NF → 2NF: the partial functionally dependent attributes are removed from the relation by
placing them in a new relation along with a copy of their determinant.

Identify the candidate key for a relation: recognise the attribute (group of attributes) that
uniquely identifies each row in a relation. All of the attributes that are not part of the primary key
(non-primary key attributes) should be functionally dependent on the key.
In the example, the attributes that will uniquely identify each row in the relation is a combination
of order id and prod id. So the PK is a composite key.

Partial functional dependency is when a nonkey attribute is functionally dependent on part (but
not all) of the primary key
In the example above, order date, custid and customer name are nonkey attributes which are
partially dependent on the PK since they are only functionally dependent on part of the PK, the
order ID. So we can break this down into one whole relation (see figure below, ORDER_T).
Likewise, product description, prod finish, unit price are also partially dependent on the PK since
they are only functionally dependent on part of the PK, the prod id. So we can also break this
down into another relation (see figure below, PRODUCT_T).
Full functional dependency: when a nonkey attribute is functionally dependent on the primary key.

In the example above, only the ordered qty is fully dependent on the PK (order id, prod id). So
this is the full functional dependency. (see figure below, ORDER_DETAIL_T).

Primary keys underlined.

Third normal form (3NF): A relation that is in 1NF and 2NF, and in which no non-primary key
attribute is transitively dependent on the primary key. Remove transitive dependencies.

Transitive dependency: A condition where A, B and C are attributes of a relation such that if A
→ B and B → C, then C is transitively dependent on A via B (provided that A is not functionally
dependent on B or C).

2NF → 3NF: the transitively dependent attributes are removed from the relation by placing
them in a new relation along with a copy of their determinant
From the example above, there are no transitive dependencies in tables PRODUCT_T and
ORDER_DETAIL_T. In ORDER_T, customer name and customer address are transitively
dependent on order id via the customer id. This is transitive dependency and should be moved
to a different table.
Reference / Reading Material :
Modern Database Management, 11th Ed
Hoffer , Ramesh, Topi

Assessment
1. Give your own examples (3 examples) of functional dependencies between attributes. Use
line with arrow to show the determinant and the dependent attributes
2. Give you own example (1) of record with multi-valued attributes. Show all attribute names
and give data for each attribute highlighting the multi-valued attributes
3. Give other examples (3) of attributes which can be derived (any record).
Activity
Normalization Problem
Table of Attributes for ‘Weekly Employee Assignment and Hours Rendered’ (with sample
data)
EmpID Emp Agency Hourly Company Company Hours Year-
Name Rate Code Name Rendered Week
E1 Cruz A1 50 C1 Makati Inn 16 2019-W1
C2 Golden Inn 24 2019-W1
C3 Shang Inn 8 2019-W1
E2 David A1 45 C1 Makati Inn 8 2019-W1
C3 Shang Inn 32 2019-W1
E3 Ramos A2 60 C1 Makati Inn 40 2019-W1

Business Rule
1. An employee can work in several companies in a week depending upon where his agency
assigns him.

Create the following. Make sure to provide name for each table
1. Schema for 1NF
1.1 Underline the PK in the 1NF
1.2 Show partial dependencies (if any) and full dependencies
2. Schema for 2NF
3. Schema for 3NF
3.1 Underline all relational keys in 3NF
3.2 Show relationships between tables using lines with arrow

Normalization Problem –Given below are the attributes about Customer and their record club
purchases. Normalize the given problem.

Data stored about customers and their record club purchases.

• {Cust-No + Name + Addr + Interest-Code + Interest-Desc +{Rec-Id + Title + Performer + Price +
Date-Ordered}}

Assume the following:

• Rec-Id and Interest-Code are unique.
• If you know the Interest-Code you can determine Interest-Desc.
• If you know the Rec-Id you can determine Title, Performer.
• All customers pay the same price if ordered on the same day.
• Prices vary from day to day.
• A customer may order the same record more than once but not on the same day