© 2002 by Prentice Hall 1

The Relational Model

David

M.

Kro

enke

Database Concepts 1e Chapter 2

2

© 2002 by Prentice Hall 2

Chapter Objectives

• Learn the conceptual foundation of the relational model

• Understand how relations differ from nonrelational tables

• Learn basic relational terminology• Learn the meaning and importance

of keys, foreign keys, and related terminology

© 2002 by Prentice Hall 3

Chapter Objectives (continued)

• Understand how foreign keys represent relationships

• Learn the purpose and use of surrogate keys

• Learn the meaning of functional dependencies

• Understand two basic relational design principles

© 2002 by Prentice Hall 4

A Relation

• A relation is a two-dimensional table that has specific characteristics

• The table dimensions, like a matrix, consist of rows and columns

© 2002 by Prentice Hall 5

Characteristics of a Relation

• Rows contain data about an entity• Columns contain data about attributes of

the entity• Cells of the table hold a single value• All entries in a column are of the same kind• Each column has a unique name• The order of the columns is unimportant• The order of the rows is unimportant• No two rows may be identical

© 2002 by Prentice Hall 6

A Sample Relation

EmployeeNumber

FirstName LastName

100 Mary Abermany

700 Jerry Caldera

300 Alea Copley

40 Murugan Jacksoni

© 2002 by Prentice Hall 7

A Nonrelation Example

EmployeeNumber

Phone LastName

100 335-6421,454-9744

Abermany

700 215-7789 Caldera

300 610-9850 Copley

40 299-9090 Jacksoni

Cells of the table hold a single value

© 2002 by Prentice Hall 8

EmployeeNumber

Phone LastName

100 335-6421 Abermany

700 215-7789 Caldera

300 610-9850 Copley

100 335-6421 Abermany

40 299-9090 Jacksoni

No two rows may be identical

A Nonrelation Example

© 2002 by Prentice Hall 9

Terminology

Table Row Column

File or Datafile

Record Field

Relation Tuple Attribute

Synonyms…

© 2002 by Prentice Hall 10

A Key

• A key is one or more columns of a relation that is used to identify a row

© 2002 by Prentice Hall 11

Uniqueness of Keys

Unique Key Nonunique Key

Data value is unique for each row. Consequently, the key will uniquely identify a row.

Data value may be shared among several rows.Consequently, the key will identify a set of rows.

© 2002 by Prentice Hall 12

A Composite Key

• A composite key is a key that contains two or more attributes

• For a key to be unique, often it must become a composite key

© 2002 by Prentice Hall 13

Composite Key Example

• To identify a family member, you need to know a FamilyID, a FirstName, and a Suffix (e.g., Jr.)

• The composite key is: FamilyID, FirstName, Suffix

• One needs to know the value of all three columns to uniquely identify an individual

© 2002 by Prentice Hall 14

A Candidate Key

• A candidate key is called “candidate” because it is a candidate to become the primary key

• A candidate key is a unique key

© 2002 by Prentice Hall 15

A Primary Key

• A primary key is one chosen candidate key

• If you know the value of the primary key, you will be able to uniquely identify a single row

© 2002 by Prentice Hall 16

Table Relationships

• A table may be related to other tables

• For example– An Employee works in a Department– A Manager controls a Project

© 2002 by Prentice Hall 17

A Foreign Key

• To preserve relationships, you may need to create a foreign key

• A foreign key is a primary key from one table placed into another table

• The key is called a foreign key in the table that received the key

© 2002 by Prentice Hall 18

Foreign Key Example

Project

ProjID

ProjName

MgrID

Manager

MgrID

MgrName

Foreign Key

Primary Key

© 2002 by Prentice Hall 19

Foreign Key Example

Department

DeptID

DeptName

Location

Employee

EmpID

DeptID

EmpName

Foreign Key

Primary Key

© 2002 by Prentice Hall 20

Referential Integrity

• Referential integrity states that every value of a foreign key must match a value of the primary key

• For example– If EmpID = 4 has a DeptID = 7 (a

foreign key). A Department with DeptID = 7 must exist and no other Department may have DeptID = 7

© 2002 by Prentice Hall 21

Referential Integrity

• Another perspective… (The value of the Foreign Key

EmployeeID) in EQUIPMENT must exist in

(as a Primary Key value EmployeeID) in EMPLOYEE

© 2002 by Prentice Hall 22

A Surrogate Key

• A Surrogate Key is a new key that takes the place of the Primary Key

• A Surrogate Key is typically used in place of a composite primary key

• It is clearer and easier to deal with one column, rather than a set of columns

© 2002 by Prentice Hall 23

Surrogate Key Example• Family Member Primary Key is FamilyID,

FirstName, Suffix. It is easier to create a surrogate key of FamMemberID. This would be a unique key

• Referential Integrity… (FamilyID, FirstName, Suffix) in School

must exist in (FamilyID, FirstName, Suffix) in FamilyMember

Alternatively… (FamMemberID) in School must exist in

(FamMemberID) in FamilyMember

© 2002 by Prentice Hall 24

Functional Dependency

• The value of one column may determine the value of another column in the same table

• Illustration…– The price of one cookie can

determine the price of a box of 12 cookies

(CookiePrice, Qty) BillAmount

© 2002 by Prentice Hall 25

Candidate/Primary Keys and Functional Dependency

• By definition…A candidate key of a relation will functionally determine all other columns in the row

• Likewise, by definition…A primary key of a relation will functionally determine all other columns in the row

© 2002 by Prentice Hall 26

Primary Key and Functional Dependency Example

(EmployeeID)(EmpLastName, EmpAddr,EmpPhone)

(ProjectID) (ProjectName, StartDate)

© 2002 by Prentice Hall 27

Normalization

• Normalization is a process of analyzing a relation to ensure it is well formed

• More specifically, if a relation is normalized, rows can be added, removed, or updated without creating exceptions

© 2002 by Prentice Hall 28

Stages of Normalization• Relations are tested for various

conditions to ensure normalization• At the conclusion of specific sets of tests,

a relation is said to be in a “Normal Form”

• There are several Normal Forms– First Normal Form, Second Normal Form,

Third Normal Form, Boyce-Codd Normal Form, Fourth Normal Form, Fifth Normal Form, and Domain/Key Normal Form

© 2002 by Prentice Hall 29

Un-Normalized Example

(StudentID)(StudentName, DormName, DormCost)

(DormName) (DormCost) Then DormCost should be placed into its own relation

However, if…

(StudentID) (StudentName, DormName)

Resulting in…

(DormName) (DormCost)

© 2002 by Prentice Hall 30

Un-Normalized Example

(AttorneyID,ClientID)

(ClientName, MeetingDate, Duration)

(ClientID) (ClientName) Then ClientName should be placed into its own relation

However, if…

Resulting in…

(ClientID) (ClientName)

(AttorneyID,ClientID) (MeetingDate, Duration)

© 2002 by Prentice Hall 31

The Null Value

• A Null value means that no data was entered

• This is different from a zero, space character, or tab character

© 2002 by Prentice Hall 32

The Problem of Null Values

• A Null is often ambiguous. It could mean…– The column value is not appropriate

for the specific row– The column value is not decided– The column value is unknown

• Each may have entirely different implications

© 2002 by Prentice Hall 33

The Relational Model

David

M.

Kro

enke

Database Concepts 1e Chapter 2

2