Chapter 3

The Relational Database Model

Database Systems: Design, Implementation, and Management

Peter Rob & Carlos Coronel

 In this chapter, you will learn:
 That the relational database model takes a logical view of
data
 That the relational database model’s basic components are
entities and their attributes, and relationships among
entities
 How entities and their attributes are organized into tables
 About relational database operators, the data dictionary,
and the system catalog
 How data redundancy is handled in the relational database
model
 Why indexes are important
 Logical View of Data
 Relational Database
 Designer focuses on logical rather than physical representation
 Use of table advantageous
 Structural and data independence
 Related records stored in independent tables
 Logical simplicity
 Allows for more effective design strategies
 The use of logically independent tables is easier to understand.

 Logical simplicity yields simpler and more effective database design

methodologies.
 Logical View of Data (con’t.)
 Entities and Attributes
 Entity is a person, place, event, or thing about which data is collected
 University -- Students, Faculty Members, Courses, Sections
 Airline -- Pilots, Aircrafts, Routes, Suppliers, Airports
 Attributes are characteristics of the entity
 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
 Logical View of Data (con’t.)
 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 .
 Tables
 Comprised of rows and columns.
 Holds related entities or entity set..
 Also called relations.
 Simple Relational Table
Database name: Ch03_TinyCollege
Table name: STUDENT

STUDENT table,
continued
 Table Characteristics
• Perceived as a two-dimensional structure with rows and columns
• Each row (tuple) represents single entity occurrence
• Each column represents an attribute, each column has a distinct
name
• Each row/column intersection represents single value
• All values in a column have same data format
• Each column has range of values called attribute domain
 Table Characteristics (con’t.)
• Order of the rows and columns is immaterial to the DBMS
• Each table must have an attribute (or combination of attributes) that
uniquely identify each row – known as the primary key
 Example Table Single value

Same data format

Columns Attributes
Distinct name
Attribute domain
Primary Key

Rows
(Tuples)

STU_NUM  STU_LNAME, STU_FNAME, STU_INIT,…., STU_GPA, STU_TRANSFER, DEPT_CODE, STU_PHONE, PROF_NUM

 Keys
 A key helps define entity relationships.
 One or more attributes that determine the value of other attributes
 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.
 A multi-attribute key is known as a composite key.
 An attribute that is part of a key is known as a key attribute.
 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).
 Keys
 Superkey – attribute(s) that identifies each entity uniquely.
 STU_NUM
 STU_LNAME, STU_FNAME, STU_INIT
 STU_NUM, STU_LNAME, STU_INIT

 Candidate Key – superkey w/o redundancies

 STU_NUM
 STU_LNAME, STU_FNAME, STU_INIT, STU_PHONE

 Primary Key – the chosen candidate key.

 STU_NUM
 Keys
 Foreign 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.
 The foreign key is an attribute (or combination of attributes) in one table
whose value matches other table’s primary key values or is null.
 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 referential
integrity.
 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 another table
 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:
 UNION, INTERSECT, DIFFERENCE (Union Compatible),
 PRODUCT, SELECT, PROJECT,
 JOIN
 and DIVIDE.
 Relational Database Operators
 UNION combines all rows from two tables. The
two tables must be union compatible.

UNION

yields
 Relational Database Operators
 INTERSECT produces a listing that contains only
the rows that appear in both tables. The two
tables must be union compatible.

yields
INTERSECT
 Relational Database Operators
 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.

yields
DIFFERENCE
 Relational Database Operators
 PRODUCT produces a list of all possible pairs of
rows from two tables.

PRODUCT

yields
 Relational Database Operators
 SELECT yields values for all attributes found in a
table. It yields a horizontal subset of a table.

Original table New table or list

SELECT ALL will yield

SELECT only PRICE less than $2.00 yields

SELECT only P_CODE = 311452 yields

 Relational Database Operators
 PROJECT produces a list of all values for selected
attributes. It yields a vertical subset of a table.
Original table New table or list

PROJECT PRICE yields

PROJECT P_DESCRIPT and PRICE yields

PROJECT P_CODE and PRICE yields

 Relational Database Operators
 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.

Table name: CUSTOMER Table name: AGENT

Relational Database Operators
 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:
1) A PRODUCT of the tables is created. (Figure 2.12)
2) A SELECT is performed on the output of the first
step to yield only the rows for which the common
attribute values match. (Figure 2.13)
3) A PROJECT is performed to yield a single copy of
each attribute, thereby eliminating the duplicate
column. (Figure 2.14)
Natural Join, Step 1: PRODUCT
Figure 2.13 Natural Join, Step 2: SELECT

Figure 2.14 Natural Join, Step 3: PROJECT

Relational Database Operators
 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 JOIN 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 blank or null.
Left Outer Join

Right Outer Join

 Relational Database Operators
 DIVIDE requires the use of one single-column
table and one two-column table.

yields
DIVIDE
 The Data Dictionary and the
System Catalog
 The relational model stores metadata (data about data)
within special tables in the database.
 Data dictionary contains metadata to provide detailed
accounting of all end-user 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.
 System catalog automatically produces database
documentation.
 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.
Table name: PROFESSOR
Primary key: EMP_NUM Database name: Ch03_TinyCollege
Foreign key: DEPT_CODE

Table name: DEPARTMENT

Primary key: DEPT_CODE
Foreign key: EMP_NUM
CRS_CODE, CLASS_SECTION
Candidate Key
• Unique Values
• No Nulls
Wrong Representation of M:M Relationship
 Data Redundancy Revisited
 Proper use of foreign keys is crucial to exercising data
redundancy control.

 Database designers must reconcile three often

contradictory requirements: design elegance (integrity),
processing speed, and information requirements.

 Always meet information requirements, but should you go

for data integrity or speed? What is more important? Data
integrity…

 Proper data warehousing design even requires carefully

defined and controlled data redundancies, to function
properly. (Chapter 13)
 Redundant?

Redundancy is defined as having the same data stored in multiple

different places unnecessarily.

If LINE_PRICE = PROD_PRICE, then LINE_PRICE is redundant!

Test: Eliminating LINE_PRICE,

Do we loose any meaningful information? Yes or No.
Questions: Over time, is the price of a product constant?
Table name: CUSTOMER
Primary key: CUS_CODE Database name: Ch03_SaleCo
Foreign key: none

Table name: INVOICE

Primary key: INV_NUMBER
Foreign key: CUS_CODE

Table name: LINE

Primary key: INV_NUMBER + LINE_NUMBER
Foreign keys: INV_NUMBER, PROD_CODE

Table name: PRODUCT

Primary key: PROD_CODE
Foreign key: none
The managed-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.
 Indexes
 An index is an orderly arrangement of keys and pointers
used to logically access data in a a table (and to speed end-
user data access).
 An index composed of an index key and a set of pointers.
 Indexes
 Each index key represents the
“search” or “lookup” values
commonly used to order or
access the end-user data. i.e.
painter number, product number,
student ID, VIN, course ID, call
no., etc.
 The pointers are physical
addresses pointing to the location
of the end-user data rows in
permanent storage.
 A composite index is an index in
which the index key can be
composed of multiple attributes.
i.e. course id + section number
(INFS4790-01)
 An unique index is an index in
which the index key can have only
one pointer value associated with
it. i.e. there can be only one row in
which the product number is
12432.
 Indexes
 A table can have multiple indexes
 Indexes are used by the DBMS in many ways:
 Logically order data in a table for reporting purposes
 Retrieve data more efficiently
 Lookup up a given row instead of reading all rows of a table
 Enforce database uniqueness constraints
 Primary key constraints
– There can not be two courses with the same id.
– There can not be two students with the same student id.
 Unique values
– There cannot be two products with the same name.
– There cannot be two students with the same first name,
middle name and last name.