COMP.6212 Data Management
Relations (Tables)
Relational Data Model
Represents data in the form of tables
 Uses Structured Query Language (SQL)
to create tables and manipulates data
within tables
 Implements business rules in a way
that preserves the integrity of data
when they are manipulated.

Definition of a Relation (Table)
A relation is a named, two-dimensional
table of data that corresponds to an entity
in an ERD.
 Table consists of rows (records) and
columns (attribute or field)

CUSTOMER
CustomerID
Customer
Name
Customer
Address
City
state
Postal
Code
011
Peter
----
--
---
---
014
John
----
--
---
---
340
Jane
---
--
---
---
Properties of a Relation






Each relation in a database has a unique
name
Each cell in a table contains a single value
(atomic)
Each row is unique (can’t have two rows
with exactly the same values)
Each columns in a table has a unique name
The order of rows irrelevant
The order of columns irrelevant
Correspondence with ER Model
Relations (tables) correspond with entity
types and with many-to-many relationship
types (associative entities)
 Rows correspond with entity instances
 Columns correspond with attributes

NOTE:
The word relation (in relational databases)
is NOT the same as the word relationship
(in ER model)
Key Fields

There are two types of keys:
 Primary key is a unique identifier of a row in a
relation and as such can not be null.
 Foreign key is an identifier that enables a child
relation (on the many side of a relationship) to
refer to its parent relation (on the one side of
the relationship)

Keys can be:
 Simple (made of a single field)
 Composite (made of more than one field)
Integrity Constraints

Domain Constraints
 Related to the attribute values
 Range / Set of value assigned to an
attribute
 All the values in a column must belong to
the same domain.
 A definition of domain consists of:
 Domain name
 Description
 Data type
 Length
 Range of value
Integrity Constraints
StudentID
1
Student
Name
Peter
age domain
age
20
23
20
2
John
30
3
Jane
17
30
4
Jack
59
17
5
Singh
23
59
Age <60 and age >16
Integrity Constraints

Entity Integrity (Primary Key Integrity)
◦ Related to a primary key
◦ Entity Integrity Rule:
 A primary key value must be unique and a
primary key value, or a part of it, if
composite, can not be null.
◦ NULL values represent missing unknown
data.
Example that violate Entity Integrity rule
CUSTOMER
CustomerID
Customer
Name
Customer
Address
City
state
Postal
Code
011
Peter
----
--
---
---
014
John
----
--
---
---
340
Jane
---
--
---
---
011
Jack
---
--
---
---
011
Singh
---
---
--
---
Violation of EI
rule
Integrity Constraints

Referential Integrity
◦ Related to foreign keys
◦ Maintain consistency between two relations
(tables).

Referential Integrity Rule:
◦ Each foreign key value must match a primary
key value in another relation, or be null.
Referential Integrity
Referential
integrity
constraints are
enforced using
foreign keys
Referential Integrity Constraints - Example
CUSTOMER
CustomerID
Customer
Name
011
Peter
014
John
340
Jane
Customer
Address
City
state
Postal
Code
Violation of RI
rule
ORDER
Order ID
Order_Date
CustomerID
0001
12/10/2012
011
2001
10/03/2013
014
2300
19/03/2013
500
A Relation with redundant data
Employee
ID
Employee
Name
Department
CityID
City
011
Peter
Accounts
001
Auckland
014
Pat
Accounts
001
Auckland
340
Jane
Administration
005
Rotorua
012
John
Accounts
003
Tokorua
121
Sam
Administration
001
Auckland
200
Janet
Accounts
002
Hamilton
013
Harry
Administation
002
Hamilton
312
Singh
Accounts
001
Auckland
400
Saab
Administration
005
Rotorua
Redundant data
Well-Structured Relations

Well-structured relations:
◦ Contain minimal data redundancy
◦ Allow users to change the data without causing
inconsistencies
Relation Design

Goal is to avoid anomalies:
◦ Insertion Anomaly – adding new rows forces
user to create duplicated data
◦ Deletion Anomaly – deleting rows may cause
a loss of data that may be needed later
◦ Modification Anomaly – changing data in a
row forces changes to other rows because of
duplication
Example of a Table
STUDENT_COURSE
Student_ID
Last_Name
First_Name
Phone_
Number
Course_Title
Course_Fee
00001
Sims
June
123 4567 Accounting
NZ$1000.00
00001
Sims
June
123 4567 Computing
NZ$1250.00
00002
Ox
Fred
232 2412 Accounting
NZ$1000.00
00002
Ox
Fred
232 2412 Business
NZ$1500.00
What’s the primary key?
Composite: StudentID, CourseTitle
13
Insertion Anomaly
Cannot enter a new student without having
the student take a course.
◦ Example: Bill Smith (ID 00003, Phone 434 2244)
Insertion Anomaly
STUDENT_COURSE
Student_ID
Last_Name
First_Name
Phone_
Number
Course_Title
Course_Fee
00001
Sims
June
123 4567 Accounting
NZ$1000.00
00001
Sims
June
123 4567 Computing
NZ$1250.00
00002
Ox
Fred
232 2412 Accounting
NZ$1000.00
00002
Ox
Fred
232 2412 Business
NZ$1500.00
00003
Smith
Bill
434 2244 ?
?
Deletion Anomaly
Removing student 00002 from the relation
causes loss of information about the
Business
Course.
Deletion Anomaly
STUDENT_COURSE
Student_ID
Last_Name
First_Name
Phone_
Number
Course_Title
Course_Fee
00001
Sims
June
123 4567
Accounting
NZ$1000.00
00001
Sims
June
123 4567
Computing
NZ$1250.00
00002
Ox
Fred
232 2412
Accounting
NZ$1000.00
00002
Ox
Fred
232 2412
Business
NZ$1500.00
Modification Anomaly
If student with StudentID of 00001 changes
her
phone number to 444 5656, then update of
multiple
records is required.
Modification Anomaly
STUDENT_COURSE
Student_ID
Last_Name
First_Name
Phone_
Number
Course_Title
Course_Fee
00001
Sims
June
123 4567 Accounting
NZ$1000.00
00001
Sims
June
123 4567 Computing
NZ$1250.00
00002
Ox
Fred
232 2412 Accounting
NZ$1000.00
00002
Ox
Fred
232 2412 Business
NZ$1500.00
Why do these anomalies exist?
Cause
We have combined two themes (entity types)
into one relation.
Consequence
Data duplication and unnecessary dependencies
between the entities.
General rule
A relation (table) should pertain to ONE entity
type only.
Improved Solution
STUDENT
StudentI_D
Last_Name
First_Name
Phone_
Number
00001
Sims
June
123 4567
00002
Ox
Fred
232 2412
STUDENT_COURSE
StudentI_D*
Course_Title*
COURSE
Course_Title
Course_Fee
00001
Accounting
00001
Computing
Accounting
NZ$1000.00
00002
Accounting
Computing
NZ$1250.00
00002
Business
Business
NZ$1500.00
Standard Relation Notation
STUDENT(Student_ID, Last_Name, First_Name,
Phone_Number)
COURSE(Course_Title, Course_Fee)
STUDENT_COURSE(Student_ID*, Course_Title*)
Note:
Primary key attributes are underlined
Foreign key attributes are marked with an *