Chapter 2

The Relational Database

Model
 Entities & Attributes
• Entities and Attributes
– An entity is a person, place, event, or thing
for which we intend to collect data.
• University -- Students, Faculty Members,
Courses
• Airlines -- Pilots, Aircraft, Routes, Suppliers

– Each entity has certain characteristics known

as attributes.
• Student -- Student Number, Name, GPA,
Date of Enrollment, Data of Birth, Home
Address, Phone Number, Major
• Aircraft -- Aircraft Number, Date of Last
Maintenance, Total Hours Flown, Hours
Flown since Last Maintenance
 Entities & Attributes
• Entities and Attributes
– A grouping of related entities becomes an
entity set.
• The STUDENT entity set contains all
student entities.
• The FACULTY entity set contains all
faculty entities.
• The AIRCRAFT entity set contains all
aircraft entities.
 Entities & Attributes
• Tables and Their Characteristics
– A table contains a group of related
entities -- i.e. an entity set.
– The terms entity set and table are often
used interchangeably.
– A table is also called a relation.
Common Data
Elements
Student File Attribute

Id No. Name Faculty Major

1100 Ali FIT SE
1200 Bobby FIT MIS Entity Occurrence
1300 Clement FCM MM
1400 David FCM MM
1500 Evelyn FOE CE

Conceptual data modeling notation

Entity Class
Common Data
Elements
Student File Attribute
Fiel
Id No. Name Faculty Major d
1100 Ali FIT SE
1200 Bobby FIT MIS Entity Occurrence
1300 Clement FCM MM Record
1400 David FCM MM
1500 Evelyn FOE CE

Conceptual data modeling notation

Entity Class File processing Notation
File
Common Data
Elements
Student File Attribute
Fiel
Id No. Name Faculty Major Column
d
1100 Ali FIT SE
1200 Bobby FIT MIS Entity Occurrence
1300 Clement FCM MM Record
1400 David FCM MM
Row
1500 Evelyn FOE CE

Conceptual data modeling notation

Entity Class File processing Notation
File Relational Table Notation
Table
Student Table
 Keys
• Controlled redundancy (shared common
attributes) makes the relational database
work.

• The primary key of one table appears

again as the link (foreign key) in another
table.

• If the foreign key contains either matching

values or nulls, the table(s) that make use
of such a foreign key are said to exhibit
A Simple Relational Database
The Relational Schema
 Keys
– A key helps define entity relationships.
– The key’s role is based on a concept known as
determination, which is used in the definition of
functional dependence.
• The attribute B is functionally dependent on A
if A determines B.
• An attribute that is part of a key is known as a
key attribute.
• A multi-attribute key is known as a composite
key.
• If the attribute (B) is functionally dependent on
a composite key (A) but not on any subset of
that composite key, the attribute (B) is fully
functionally dependent on (A).
Relational Database Keys

• Superkey
– Uniquely identifies each entity
– STU_NUM
– STU_NUM, STU_LNAME
– STU_NUM, STU_LNAME, STU_INIT
• Candidate key
– Minimal superkey
– STU_NUM
– STU_LNAME, STU_FNAME, STU_INIT,
STU_PHONE
Relational Database Keys

• Secondary key
– Used only for data retrieval
• Foreign key
– Values must match primary key in
another table
Integrity Rules

• Entity integrity
– Ensures all entities are unique
– Each entity has unique key
• Referential integrity
– Foreign key must have null value or
match primary key values
– Makes it impossible to delete row
whose primary key has mandatory
matching foreign key values in
An Illustration of Integrity
Rules
Relational Database Operators

• The degree of relational

completeness can be defined by the
extent to which relational algebra is
supported.

• Relational algebra defines the

theoretical way of manipulating
table contents using the eight
relational functions: SELECT,
PROJECT, JOIN, INTERSECT, UNION,
DIFFERENCE, PRODUCT, and DIVIDE.
 UNION
• UNION combines all rows from two tables.
The two tables must be union compatible
(same attribute characteristics)
 INTERSECT
• INTERSECT produces a listing that contains
only the rows that appear in both tables.
The two tables must be union compatible.
 DIFFERENCE
• DIFFERENCE yields all rows in one table
that are not found in the other table; i.e.,
it subtracts one table from the other. The
tables must be union compatible.
 PRODUCT
• PRODUCT produces a list of all possible
pairs of rows from two tables.
 SELECT
• SELECT yields values for all attributes
found in a table. It yields a horizontal
subset of a table.
 PROJECT
• PROJECT produces a list of all values for
selected attributes. It yields a vertical
subset of a table.
 JOIN
• JOIN allows us to combine information from
two or more tables. JOIN is the real power
behind the relational database, allowing
the use of independent tables linked by
common attributes.
 Natural JOIN
– Natural JOIN links tables by selecting
only the rows with common values in
their common attribute(s). It is the
result of a three-stage process:
• A PRODUCT of the tables is created.
(Figure 3.12)
• A SELECT is performed on the output
of the first step to yield only the rows
for which the common attribute
values match. (Figure 3.13)
• A PROJECT is performed to yield a
single copy of each attribute, thereby
eliminating the duplicate column.
Natural Join, Step 1: PRODUCT
Step 2: SELECT
Step 3: PROJECT
EquiJOIN & Theta JOIN
– EquiJOIN links tables based on an equality
condition that compares specified
columns of each table. The outcome of
the EquiJOIN does not eliminate duplicate
columns and the condition or criteria to
join the tables must be explicitly defined.

– Theta JOIN is an equiJOIN that compares

specified columns of each table using a
comparison operator other than the
equality comparison operator.

– In an Outer JOIN, the unmatched pairs

would be retained and the values for the
unmatched other tables would be left
 OUTER JOIN
– In outer join for tables CUSTOMER and
AGENT, two scenarios are possible.
- Left outer join
Yields all rows in CUSTOMER table,
including those
that do not have a matching values in
the AGENT table
 OUTER JOIN
- Right outer join
Yields all rows in AGENT table, including
those
that do not have a matching values in
the CUSTOMER table
 DIVIDE
• DIVIDE requires the use of one single-
column table and one two-column table.
 The Data Dictionary and the
System Catalog
• Data dictionary contains metadata to
provide detailed accounting of all tables
within the database.

• System catalog is a very detailed system

data dictionary that describes all objects
within the database.
– System catalog is a system-created
database whose tables store the
database characteristics and contents.
– System catalog tables can be queried just
like any other tables.
A Sample Data Dictionary
Relationships within the
Relational Database
• E-R Diagram (ERD)
– Rectangles are used to represent
entities.
– Entity names are nouns and capitalized.
– Diamonds are used to represent the
relationship(s) between the entities.
– The number 1 is used to represent the
“1” side of the relationship.
– The letter M is used to represent the
“many” sides of the relationship.
 Relationships within the
Relational Database
• 1:M relationship
- Relational modeling ideal
- Should be the norm in any relational
database design

• M:N relationship
- Must be avoided because they lead to data
redundancies

• 1:1 relationship
- Should be rare in any relational database
design
The 1:M Relationship Between
Painter and Painting
1:M Relationship
The M:N Relationship Between
Student and Class
Sample Student Enrollment Data
A Many-to-Many Relationship
Between Student and Class
Changing the M:N
Relationship to Two 1:M
Relationships
The Expanded
Entity
Relationship
Model
The Relational Schema for the
Entity Relationship Diagram
Data Redundancy Revisited

• Data redundancy leads to data

anomalies, such anomalies can
destroy database effectiveness.

• Foreign keys – control redundancies

by using common attributes shared
by tables

• Sometimes, data redundancy is

necessary
 The Relational Schema for
the Invoicing System

The redundancy is crucial to the system’s success.

Copying the product price from the PRODUCT table to
the LINE table means that it is possible to maintain the
historical accuracy of the transactions.
 References

• ROB, P. AND CORONEL, C., 2004, Database

Systems. 6th Ed., Thomson Course Technology