Database Systems: Design, Implementation, and Management 13 Edition

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 24

Database Systems:

Design, Implementation, and


Management
13th Edition
CHAPTER 3
THE RELATIONAL DATABASE MODEL

DATABASE SYSTEMS, 13TH EDITION


Previous Lectures
Course Learning Outcomes
• CLO1: Discuss the importance and basic
concepts of Database Management
Systems.
– Affiliated with Lifelong Learning PLO.
• CLO2: Analyze and Compare different
Data Models.
– Affiliated with Problem Analysis PLO.
Topics/Concepts to be covered in 7th Week
• Relational Database Keys
• Functional dependence
• Full Functional Dependence
• Entity Integrity and Null value
• Controlled Redundancy
• Relational Schema
• Foreign Key (FK) and Referential Integrity
• Integrity Rules
• Flags
• Other Integrity Rules
For the Lectures 7th Week onwards...
• CLO 3: Design ERM with Normalization
• PLO 3: Design/Development of Solutions
Predicate logic and Set Theory
The relational model, introduced by E. F. Codd in
1970, is based on predicate logic and set theory.
Predicate logic: provides a framework in which
an assertion (statement of fact) can be verified as
either true or false.
Set theory: a mathematical science that deals
with sets, or groups of things, and is used as the
basis for data manipulation in the relational model.

DATABASE SYSTEMS, 13TH EDITION 5


Objectives
In this chapter, students will learn:
That the relational database model offers a
logical view of data
About the relational model’s basic component:
relations
That relations are logical constructs composed
of rows (tuples) and columns (attributes)
That relations are implemented as tables in a
relational DBMS

DATABASE SYSTEMS, 13TH EDITION 6


Objectives
About relational database operators, the data
dictionary, and the system catalog
How data redundancy is handled in the
relational database model
Why indexing is important

DATABASE SYSTEMS, 13TH EDITION 7


A Logical View of Data
Relational model
View data logically rather than physically
Table
Structural and data independence
Resembles a file conceptually
Relational database model is easier to
understand than hierarchical and network
models

DATABASE SYSTEMS, 13TH EDITION 8


Tables and Their Characteristics
Logical view of relational database is
based on relation
Relation thought of as a table
Table: two-dimensional structure
composed of rows and columns
Persistent representation of logical relation
Contains group of related entities (entity
set)

DATABASE SYSTEMS, 13TH EDITION 9


DATABASE SYSTEMS, 13TH EDITION 10
DATABASE SYSTEMS, 13TH EDITION 11
Relational Database Keys
• In the relational model, keys are important because they are used
to ensure that each row in a table is uniquely identifiable.
• Consists of one or more attributes that determine other attributes.
• Primary key (PK) is an attribute (or a combination of attributes)
that uniquely identifies any given tuple of an entity (row).
• Key’s role is based on determination
• If you know the value of attribute A, you can look up (determine) the
value of attribute B
• STU_NUM → STU_LNAME
• STU_NUM → STU_LNAME, STU_FNAME, STU_INIT
• STU_NUM→STU_LNAME,STU_FNAME,STU_INIT,STU_DOB, STU_TRANSFER
Example Tables
Relational Database Keys (Cont’d)
Super Key:
– Any key that uniquely identifies each entity
• In the STUDENT table, the super key could be any of the
following:
• STU_NUM
• STU_NUM, STU_LNAME
• STU_NUM, STU_LNAME, STU_INIT
• In fact, STU_NUM, with or without additional attributes,
can be a super key even when the additional attributes are
redundant.
Example Tables
Relational Database Keys (Cont’d)
• Candidate key
– A super key without redundancies
– A candidate key can be described as a minimal super key.
– STU_SSN and STU_NUM
• STU_LNAME, STU_FNAME, STU_INIT, STU_PHONE
• might also be a candidate key, as long as you discount the possibility that two students
share the same last name, first name, initial, and phone number.

• Composite key
– Composed of more than one attribute
• STU_LNAME, STU_FNAME, STU_INIT, STU_PHONE → STU_HRS, STU_CLASS
or
• STU_LNAME,STU_FNAME, STU_INIT, STU_PHONE → STU_HRS, STU_CLASS, STU_GPA
or
• STU_LNAME,STU_FNAME, STU_INIT, STU_PHONE → STU_HRS, STU_CLASS, STU_GPA, STU_DOB
Example Tables
Relational Database Keys (Cont’d)

• Foreign key (FK)


– An attribute whose values match primary key values in
the related table.

• Secondary key
– Key used strictly for data retrieval purposes.
Simple Relational Database
Functional dependence
• The term functional dependence can be
defined most easily this way: the attribute B
is functionally dependent on A if A
determines B.
More precisely:
• The attribute B is functionally dependent
on the attribute A if each value in column
A determines one and only one value in
column B.
Functional dependence
• STU_PHONE is functionally dependent on
STU_NUM.
– For example, the STU_NUM value 321452
determines the STU_PHONE value 2134.
• On the other hand, STU_NUM is not
functionally dependent on STU_PHONE
– because the STU_PHONE value 2267 is
associated with two STU_NUM values: 324274
and 324291.(hostel situation)
Full Functional Dependence
• The notion of functional dependence can
be further refined by specifying full
functional dependence:
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).
Full Functional Dependence:
Examples:
• STU_LNAME, STU_FNAME, STU_INIT, STU_PHONE → STU_HRS, STU_CLASS
or
• STU_LNAME,STU_FNAME, STU_INIT, STU_PHONE → STU_HRS, STU_CLASS, STU_GPA
or
• STU_LNAME,STU_FNAME, STU_INIT, STU_PHONE → STU_HRS, STU_CLASS, STU_GPA, STU_DOB

You might also like