The Relational Data Model

Relational Data Model

Core of majority of modern databases
Virtually all business relies
on some form of relational database
Solid theoretical/mathematical foundation
Simple but robust implementation

Models, Schemas and States

A data model defines the constructs
available for defining a schema
o defines possible schemas

A schema defines the constructs

available for storing the data
o defines database structure
o limits the possible database states

A database state (or instance) is all

the data at some point in time

the database content

Models, Schemas and States

data model
o fixed by the DBMS

schema
o defined by the DB designer
o generally fixed once defined *

database state
o changes over time due to user updates
* schema modifications are possible once the database
is populated, but this generally causes difficulties

The Relational Data Model

All data is stored in relations
o relations are sets, but generally viewed as 2D tables

DB schema = a set of relation specifications

o the specification of a particular relation is called a

relation schema

DB state = the data stored in the relations

o the data in a particular relation is called a relation state
(or relation instance or simply relation)
Principle of Uniform Representation:
The entire content of a relational database is represented in one and only
one way: namely, as attribute values within tuples within relations.

RDM Schemas

External View

relation
specifications

mapping from
relations to
storage layout (files)

External View

Conceptual Schema
Internal Schema

External View

Relational Data Definition

application
application
application
program(s)
application
program(s)
program(s)
program(s)

query processor
security manager
concurrency manager
index manager

database designer
enters the
definition of
relation schemas
SQL DDL = relation
definition language
(CREATE TABLE)

users of
the data

data
definition
processor

relation
schemas

relations

RELATION SCHEMAS
AND
RELATION INSTANCES

Relation Schemas
A relation is defined by
a name and
a set of attributes
Each attribute has a name and a domain
o a domain is a set of possible values
o types are domain names
o all domains are sets of atomic values
RDM does not allow complex data types
o domains may contain a special null value

Example Relation Schema

relation
name

set of
attributes

StockItem
Attribute
ItemID
Description
Price
Taxable
attribute
names

Domain
string(4)
string(50)
currency/dollars
boolean
attribute
domains

Definition: Relation Schema

Relation Schema
o R is the relation name
o A1 An are the attribute names
R(A1, A2, , An)

Domains are denoted by

dom(Ai)

degree = the number of attributes

Example Relation Schema

STOCKITEM(ItemId, Description, Price, Taxable)

dom(ItemId) = string(4)
dom(Description) = string(50)
dom(Price) = currency/dollars
dom(Taxable) = boolean
degree of STOCKITEM = 4

Definition: Relation
A relation is denoted by
r(R)
o R is the name of the relation schema for the
relation

A relation is a set of tuples

r(R) = (t1, t2, , tm)

Definition: Relation
Each tuple is an ordered list of n values
t = < v1, v2, , vn >
o n is the degree of R

Each value in the tuple must be

in the domain of the corresponding
attribute
vi

dom(Ai)

Alternate notations:
ith value of tupleort is also referred to as
vi

t[Ai]

vi

t.Ai

Example Relation
r(STOCKITEM) =
{ < I119, "Monopoly", $29.95, true >,
< I007, "Risk", $25.45, true >,
< I801, "Bazooka Gum", $0.25, false > }
t2 = < I007, "Risk", $25.45, true >
t2[Price] = t2.Price = $25.45

Characteristics of Relations
A relation is a set
o tuples are unordered
o no duplicate tuples

Attribute values within tuples are ordered

o values are matched to attributes by position
o alternate definition defines a tuple
as a set of (name, value) pairs,
which makes ordering of tuple unnecessary
(we wont use this definition)

Characteristics of Relations
Values in tuples are atomic
o atomic = non-structured
(similar to primitive types in C++)
o implication:
no nested relations or other complex data
structures

If domain includes null values,

null may have many interpretations
o "does not exist"
o "not applicable"
o "unknown"

Theory vs. Reality

The theoretical data model is
mathematical:
o a relation is a set of tuples
o this is Codd's definition

In the real-world, the model is practical:

o efficiency concerns
o excepted standard: SQL
o a relation is a table, not a set
o a relation may have order and duplicates

SQL: Relation States

A relation is viewed as a table
The attributes define the columns of the table
Each row in the table holds related
values for each attribute
o a row often represents a conceptual entity (object)

Values in each column must come

from the domain of the attribute
o the values are instances of the attribute type

Relation: Table Representation

Each row collects related attribute values
StockItem
ItemId

Description

Price

Taxable

I119

Monopoly

$29.95

True

I007

Risk

$25.45

True

I801

Bazooka Gum

$0.25

False

Column values all come from the same domain

Example Relation

Example Schema

Example
State

CONSTRAINTS

Constraints
Constraints are restrictions on legal relation
states
o they add further semantics to the schema

Domain constraints

o values for an attribute must be from

the domain associated with the attribute

Non-null constraints

o the domain of some attributes may not include

null, implying that a value for that attribute
is required for all tuples

Key Constraints
By definition, all tuples in a relation are
unique
Often, we want to restrict tuples further such
that some subset of the attributes is unique
for all tuples
Example: in the StockItem relation,
no ItemID should appear in more than one
tuple
o ItemID is called a key attribute

Keys and Superkeys

Any subset of attributes
that must be unique is called a superkey
If no subset of the attributes of a
superkey
must also be unique,
then that superkey is called a key
Example:

key

key

VEHICLE(LicenseNumber, SerialNumber, Model, Year)

superkey

Candidate and Primary Keys

If a relation has more than one key,
each key is called a candidate key
One candidate key must be chosen
to be the primary key
The primary key is the one that will be
used to identify tuples
If there is only one key, it is the primary key

Candidate and Primary Keys

Primary keys are indicated
by underlining the attributes that make up
that key
candidate key

candidate key

VEHICLE(LicenseNumber, VIN, Model, Year)

primary key

Example Keys
STOCKITEM( ItemId, Description, Price, Taxable )
superkeys:
(ItemId), (Description), (ItemId, Description)
keys:
(ItemId), (Description)
candidate keys:
(ItemId), (Description)
primary key:
(ItemId)

(assumes that
Description is
unique for all items)

Integrity Constraints
Entity integrity constraint
o no primary key value can be null
o the primary key is the tuple identifier

Referential integrity constraint

o references between relations must be valid
o the foreign key of a referencing relation
must exist as a primary key in the referenced
relation

Example: Referential Integrity

STOCKITEM( ItemId, Description, Price, Taxable )
STORESTOCK( StoreId, Item, Quantity )
STORESTOCK[Item] refers to STOCKITEM[ItemID]
STORESTOCK[Item] is a foreign key referencing
the primary key STOCKITEM[ItemID]
Any value appearing in STORESTOCK[Item]
must appear in STOCKITEM[ItemID]
It must be true that
dom(STORESTOCK[Item]) = dom(STOCKITEM[ItemID])

Referential Integrity
PK = primary key in R2
FK = foreign key in R1
dom(R1[FK]) = dom(R2[PK])

Example: Referential Integrity

STOCKITEM( ItemId, Description, Price, Taxable )
STORESTOCK( StoreId, Item, Quantity )
STORE( StoreID, Manager, Address, Phone )
(StoreId, Item) is the primary key of STORESTOCK
STORESTOCK[StoreId] is a foreign key referencing STORE
STORESTOCK[Item] is a foreign key referencing
STOCKITEM

Referential Integrity:
Diagrammatic Representation
STOCKITEM( ItemId, Description, Price, Taxable )
PK
FK
STORESTOCK( StoreId, Item, Quantity )
FK
PK
STORE( StoreID, Manager, Address, Phone )

Referential Integrity:
Textual Representation
STOCKITEM( ItemId, Description, Price, Taxable )
STORESTOCK( StoreId, Item, Quantity )
STORE( StoreID, Manager, Address, Phone )
constraints:
STORESTOCK[StoreId] refers to STORE[StoreID]
STORESTOCK[Item] refers to STOCKITEM[ItemId]

Referential Integrity:
Example State
r(STORESTOCK) =
< "S002", "I065", 120 >,
< "S047", "I954", 300 >,
< "S002", "I954", 198 >
StoreId is a foreign key but not a key
all values in FK exist in PK

r(STORE) =
< "S002", "Tom", "112 Main", "999-8888" >,
< "S047", "Sasha", "13 Pine", "777-6543" >

Referential Integrity:
Constraint Violation
r(STORESTOCK) =
< "S002", "I065", 120 >,
< "S047", "I954", 300 >,
< "S333", "I954", 198 >
StoreId S333 does not exist in PK:
this is an illegal database state

r(STORE) =
< "S002", "Tom", "112 Main", "999-8888" >,
< "S047", "Sasha", "13 Pine", "777-6543" >
Both relation states are legal, but the database state is illegal.

Schema with FKs

STATE CHANGE AND

CONSTRAINT ENFORCEMENT

Causes of Constraint Violations

What can cause a
referential integrity constraint violation?

o inserting a tuple in R1 with an illegal FK

o modifying a tuple in R1 to have an illegal FK
o deleting a tuple in R2 that had the PK referenced
by some FK in R1

How can a referential integrity constraint

be enforced?

o reject the operation that attempts to violate it

(may cause other operations to be rejected
transactions)
or
o repair the violation, by cascading inserts or deletes

Data Manipulation Operations

There are three ways to modify the value of a
relation:
Insert: add a new tuple to R
Delete: remove an existing tuple from R
Update:
change the value of an existing
tuple in R
Delete and Update both require some way
to identify an existing tuple (a selection)

Inserting Tuples

r1(STORESTOCK) =

< "S002", "I065", 120 >,

< "S047", "I954", 300 >,
< "S333", "I954", 198 >

insert < "S047", "I099", 267 >

r2(STORESTOCK) =

< "S002", "I065", 120 >,

< "S333", "I954", 198 >,
< "S047", "I099", 267 >,
< "S047", "I954", 300 >

any constraint violations?

Deleting Tuples

r2(STORESTOCK) =

< "S002", "I065", 120 >,

< "S333", "I954", 198 >,
< "S047", "I099", 267 >,
< "S047", "I954", 300 >

delete tuples with Item = "I954"

r3(STORESTOCK) =

< "S002", "I065", 120 >,

< "S047", "I099", 267 >

Updating Tuples

r3(STORESTOCK) =

< "S002", "I065", 120 >,

< "S047", "I099", 267 >

change the Quantity of tuples

with StoreID = "S002" and Item = "I954" to 250

r3(STORESTOCK) =

< "S002", "I065", 250 >,

< "S047", "I099", 267 >

Analyzing State Changes

Any update can be viewed as (delete and insert)
update: < "S002", "I065", 120 > to < "S002", "I065", 250 >
is equivalent to
delete: < "S002", "I065", 120 >
insert: < "S002", "I065", 250 >

Any database state change can be viewed

as a set of deletes and inserts on individual
relations
This makes the analysis of potential constraint
violations a well defined problem

Enforcing Constraints
constraint enforcement:
ensuring that no invalid database states can
exist
invalid state: a state in which a constraint is
violated
Possible ways to enforce constraints:
o reject any operation that causes a violation, or
o allow the violating operation and then attempt
to correct the database

Constraint Violating Operations

To automate constraint enforcement
the operations that can cause violations
need to be identified
insert

delete

update

domain, non-null

yes

no

yes

key

yes

no

yes

entity integrity

yes

no

yes

referential integrity

yes/FK

yes/PK

yes/FK/PK

Correcting Constraint Violations

violation

correction

domain, non-null

ask user to enter a valid value

or use a default value

key

ask user to enter a unique key

or generate a unique key

entity integrity

ask user to enter a unique key

or generate a unique key

referential integrity
FK insertion

force an insert in the PK

(may cascade)

referential integrity
PK deletion

propagate delete to FK
(may cascade)

Summary: Relational Schemas

A relational schema consists of
a set of relation schemas
and a set of constraints
Relation schema
o list of attributes: name and domain constraint
o superkeys: key constraints
o primary key: entity integrity constraint

Foreign keys: referential integrity constraints

o defined between relation schemas

Schema for
Airline
Database

NEXT UP
skip ahead to Chapter 7:
Translating ER Schemas to Relational
Schemas
then back to Chapter 6:
The Relational Algebra: operations on
relations

PREVIEW: ER to Relational