Chapter 3.1 and 3.

2:
The Logical Relational
Data Model
DATABASE MANAGEMENT AND DESIGN
Physical Database Models
Physical data addresses
Limitations:
Pointers
◦Two records related only if
Indexes
there were existing
Student and Grade Pointer Index
Student Address Assignment Addr Grade Address
pointers
0354A8FB23 0128FE83BA 129183AFD9 ◦Vulnerable to changes in
the physical environment
Student Assign Grade ◦ New drives
File File File
◦ Additional columns in files
◦ Insertions of rows in the files
Relational Database Model
Codd, 1970
Based on logical instead of physical relationships in data
◦ Overcomes limitations of physical designs
◦ Logical design allows the user (and applications) to be
unconcerned with the physical structure of the data
◦ Allowed for structured languages to provide more flexible and
robust access to manipulating data (SQL)
 Relations
Relation
◦ Mathematical term
◦ A simple two dimensional table
Attribute
◦ Column of the relation
◦ Order does not matter
◦ Column names must be unique

Domain
◦ Set of all possible values for an attribute
◦ Two attributes with the same domain can have different names

Tuple
◦ Row of the relation
◦ Order does not matter
◦ No two tuples can have identical sets of values

Null Values
◦ Unknown data
◦ Not blank or 0

Student (StudentID, StudentNumber, FirstName, LastName,

StreetAddress, City, CellPhone)
Relation
Relations
◦ Mathematical term
◦ A simple two dimensional table

Attribute
◦ Column of the relation
◦ Order does not matter
◦ Column names must be unique
Domain
◦ Set of all possible values for an attribute
◦ Two attributes with the same domain can have different names

Tuple
◦ Row of the relation
◦ Order does not matter
◦ No two tuples can have identical sets of values

Null Values
◦ Unknown data
◦ Not blank or 0

Student (StudentID, StudentNumber, FirstName, LastName,

StreetAddress, City, CellPhone)
Relation
Relations
◦ Mathematical term
◦ A simple two dimensional table

Attribute
◦ Column of the relation
◦ Order does not matter
◦ Column names must be unique

Domain
◦ Set of all possible values for an attribute
◦ Two attributes with the same domain can have
different names
Tuple
◦ Row of the relation
◦ Order does not matter
◦ No two tuples can have identical sets of values

Null Values
◦ Unknown data
◦ Not blank or 0

Student (StudentID, StudentNumber, FirstName, LastName,

StreetAddress, City, CellPhone)
 Relations
Relation
◦ Mathematical term
◦ A simple two dimensional table

Attribute
◦ Column of the relation
◦ Order does not matter
◦ Column names must be unique

Domain
◦ Set of all possible values for an attribute
◦ Two attributes with the same domain can have different names

Tuple
◦ Row of the relation
◦ Order does not matter
◦ No two tuples can have identical sets of values
Null Values
◦ Unknown data
◦ Not blank or 0

Student (StudentID, StudentNumber, FirstName, LastName,

StreetAddress, City, CellPhone)
 Relations
Relation
◦ Mathematical term
◦ A simple two dimensional table

Attribute
◦ Column of the relation
◦ Order does not matter
◦ Column names must be unique

Domain
◦ Set of all possible values for an attribute
◦ Two attributes with the same domain can have different names

Tuple
◦ Row of the relation
◦ Order does not matter
◦ No two tuples can have identical sets of values

Null Values
◦ Unknown data
◦ Not blank or 0
Student (StudentID, StudentNumber, FirstName, LastName,
StreetAddress, City, CellPhone)
Relation
Relations
◦ Mathematical term
◦ A simple two dimensional table

Attribute
◦ Column of the relation
◦ Order does not matter
◦ Column names must be unique

Domain
◦ Set of all possible values for an attribute
A common textual notation used to represent a relation
◦ Two attributes with the same domain can have different names
Student:
Tuple Student (StudentID, StudentNumber, FirstName, LastName,
◦ Row of the relation StreetAddress, City, CellPhone)
◦ Order does not matter
◦ No two tuples can have identical sets of values

Null Values
◦ Unknown data
◦ Not blank or 0
 Relation (Primary) Keys
Database rows (see Course table to the right)
◦ Contain information about instance courses
◦ Each course is represented by exactly 1 row
◦ Rows have identifiers to ensure that:
◦ Data for each course exists on only 1 row of the relation
◦ Each row contains only data for 1 course
◦ CourseID fills this role, thus each value of CourseID must be unique

Course (CourseID, Department,

CourseNumber, CourseTitle,
CreditHours)
Relation (Primary) Keys- Vocabulary
◦ Candidate Key: any attribute that could uniquely identify a row in a relation
◦ Primary Key: the candidate key chosen as the key for the relation
◦ Composite Key: two attributes working together as the primary key
◦ Surrogate Key (internal object identifier): primary key that has no meaning outside of the computer system (CourseID)
◦ External Key: primary key that have real-world meaning (Social Security Number)
 Foreign Keys
Notice that StudentID and CourseID exist in
more than 1 one relation
Foreign keys
◦ A primary key attribute from one relation that
exists in another relation (can also be the same
relation)
◦ Used to define connections (relationships)
between two relations
◦ Must refer to a “full” primary key
Revised Database Schema:
Student (StudentID, StudentNumber, FirstName,
LastName, StreetAddress, City, CellPhone)
Course (CourseID, Department, CourseNumber,
CourseTitle, CreditHours)
GradeInCourse (StudentID, CourseID, Grade)
Foreign Key: StudentID references Student
Foreign Key: CourseID references Course
Recursive Foreign Key
Employee (EmployeeID, EmpName, SSN, Phone, ManagerID)
Foreign Key: ManagerID references Employee
Integrity Constraints
Entity integrity: because the primary key uniquely identifies
instances (rows) of the relation, it cannot contain NULL values

Referential integrity: every foreign key must either be null or must be

an actual value of a key in the referenced relation
Employee Example
Employee
EmployeeID EmployeeName LocationID
EmployeeAddress PositionID
EmployeePosition

Position
PositionID PositionTitle DegreeRequired

Location
LocationID City State LocationPhone

Identify Primary and Foreign Keys

Create a Schema for the Relations
Employee Schema
Employee
EmployeeID EmployeeName LocationID PositionID
Employee (EmployeeID, EmployeeName, EmployeePhone, PositionID, LocationID)
Foreign Key PositionID references Position
Foreign Key LocationID references Location

Position
PositionID PositionTitle DegreeRequired
Position (PositionID, PositionTitle, EducationRequired)

Location
LocationID City State LocationPhone

Location (LocationID, City, State, LocationPhone)

Class Schedule Example
A university database tracks information about students (ID,
Name, Major, and PhoneNumber), professors (ID, Name,
Degree, Department, Rank), Courses (ID, Number, Title,
Department), Sections (ID, CourseID, SectionNumber,
Professor), and which students are registered for each
section.
Create a set of relations for this database and a schema for
the relations you build.
Class Schedule Relations
Student
StudentID StudentName StudentMajor StudentPhone

Professor
ProfessorID ProfessorName ProfessorDegree ProfessorDepartment ProfessorRank

Course
CourseID CourseNumber CourseTitle CourseDepartment

Section
SectionID CourseID SectionNumber
Class Schedule Relations
Student
StudentID StudentName StudentMajor StudentPhone

Professor
ProfessorID ProfessorName ProfessorDegree ProfessorDepartment ProfessorRank

Course
CourseID CourseNumber CourseTitle CourseDepartment

Section
SectionID CourseID SectionNumber ProfessorID

Enrollment
SectionID StudentID
Class Schedule Schema
Student (StudentID, StudentName, StudentMajor, StudentPhone)
Professor (ProfessorID, ProfessorName, ProfessorDegree, ProfessorDepartment, ProfessorRank)
Course (CourseID, CourseNumber, CourseTitle, CourseDepartment)
Section (SectionID, CourseID, SectionNumber, ProfessorID)
◦ Foreign Key CourseID references Course
◦ Foreign Key ProfessorID references Professor

Enrollment (SectionID, StudentID)

◦ Foreign Key SectionID references Section
◦ Foreign Key StudentID references Student
Don’s Donuts
Don’s Donuts orders several products from various
vendors. They have a contact person at each vendor site,
along with all address information. Each purchase order
has the order number, date, tax, and total. Product
information includes stock number, description and price.
Don’s Donuts sends a check for payment and records the
check date.
Create a set of relations for this database and a schema
for the relations you build.
Don’s Donuts Relations
Vendor
VendorNumber VendorName VendorAddress VendorPhone VendorContact

Order
OrderNumber Tax Total OrderDate

Product
StockNumber Description Price

Payment
CheckNumber Date
Don’s Donuts Relations with Keys
Vendor
VendorNumber VendorName VendorAddress VendorPhone VendorContact

Order
OrderNumber Tax Total OrderDate VendorNumber CheckNumber

Product
StockNumber Description Price

ProductOrder Payment
OrderNumber StockNumber Quantity CheckNumber Date
Don’s Donuts Schema
Vendor (VendorNumber, VendorName, VendorAddress, VendorPhone, VendorContact)
Order (OrderNumber, Tax, Total, OrderDate, VendorNumber, CheckNumber)
◦ Foreign Key VendorNumber references Vendor
◦ Foreign Key CheckNumber reference Payment

Product (StockNumber, Description, Price)

ProductOrder (OrderNumber, StockNumber, Quantity)
◦ Foreign Key OrderNumber references Order
◦ Foreign Key StockNumber references Product

Payment (CheckNumber, CheckDate)