Chapter 3

The Relational Model

Transparencies

© Pearson Education Limited 1995, 2005

Chapter 3 - Objectives
 Terminology of relational model.
 How tables are used to represent data.
 Relations in the relational model.
 Properties of database relations.
 How to identify CK, PK, and FKs.
 Meaning of entity integrity and referential
integrity.
 Purpose and advantages of views.

2
© Pearson Education Limited 1995, 2005
Relational Model Terminology
 A relation is a table with columns and rows.
– An RDBMS requires only that database be
perceived by the user as tables. This perception
applies only to logical structure of the database not
the physical structure.
 Attribute is a named column of a relation.
– Example, the information of students are
represented by the Student Relation, with
columns for attributes studentNo, sFname,
sLname, sCourse, sYear, sAddress
3
© Pearson Education Limited 1995, 2005
Relational Model Terminology
 Domain is the set of allowable values for one or
more attributes.
– Every attribute in a relation is define on a
domain. It may be distinct for each attribute.
Example to student relation:
Attribute Domain Name Meaning Domain Definition
sNo StudentNumber The set of all possible Character: size 5
student number Range: S0001-S9999
sLname StudentLastname Possible lastname Character:
size15
sDOB DateofBirth Possible values of Date range: 01-01-
20
student birthdates
© Pearson format
Education Limited 1995, 2005 dd-mm-yyyy 4
Examples of Attribute Domains

5
© Pearson Education Limited 1995, 2005
Relational Model Terminology
 Tuple is a row of a relation.
 In Branch relation, each row/tuple contains four
values, one for each attribute. Tuple can appear
in any order.

6
© Pearson Education Limited 1995, 2005
Relational Model Terminology
 Degree is the number of attributes in a relation.
This means that each row of the table is a four-
tuple, containing four values. A relation with only
one attribute would have degree one and called
unary relation or one tuple. Two attributes called
binary, three attribute is called ternary and after
that the term n-nary is usually used.

7
© Pearson Education Limited 1995, 2005
Relational Model Terminology
 Cardinality is the number of tuples in a relation.
This changes as tuples are added or deleted.
 Relational Database is a collection of normalized
relations with distinct relation names.

8
© Pearson Education Limited 1995, 2005
Instances/Examples of Branch and Staff
Relations

© Pearson Education Limited 1995, 2005

Alternative Terminology for Relational Model

10
© Pearson Education Limited 1995, 2005
Database Relations
 Relation schema
– A named relation defined by a set of
attribute and domain name pairs (sets).
– a representation of relation (file/table) in the
form of model.

 Relational database schema

– Set of relation schemas, each with a distinct
name.
11
© Pearson Education Limited 1995, 2005
Properties of Relations
 Relation name is distinct from all other relation
names in relational schema.
 Each cell of relation contains exactly one atomic
(single) value.
 Each attribute has a distinct name.
 Values of an attribute are all from the same
domain (field/area).

12
© Pearson Education Limited 1995, 2005
Properties of Relations
 Each tuple is distinct; there are no duplicate
tuples.

 Order of attributes has no significance.

 Order of tuples has no significance, theoretically.

13
© Pearson Education Limited 1995, 2005
Properties of Relations
 In branch relation, cell contains
only one value, it is illegal to store
2 postcodes for a single branch
office in a single cell.
 The column names listed at the
tops of columns correspond to the
attributes of the relation. The
values in the branchNo attribute
are all from the Branch Number
domain; we should not allow a
postcode to appear in this column.
 There can be no duplicate tuples in
a relation. 14
Properties of Relations
 We can interchange columns, the
table would represent same
relation if we were to put the city
after the postcode, although for
readability, it makes sense to keep
the address elements in the normal
order.
 Similarly, with tuples can be
interchange, records of branch
B005 and B004 can be switched
and the relation will still be the
same.
15
© Pearson Education Limited 1995, 2005
Relational Keys
 As stated earlier, there are no duplicate tuples within the
relation. Therefore, we need to be able to identify one or
more attributes (called relational keys) that uniquely
identifies each tuple in a relation.
 Superkey
– An attribute, or set of attributes, that uniquely
identifies a tuple within a relation.
 Candidate Key
– A Superkey (K) such that no proper subset (subgroup)
is a superkey within the relation.
– A candidate key K for a relation R has two properties
» In each tuple of R, values of K uniquely identify that tuple
(uniqueness).
» No proper subset of K has the uniqueness property (irreducibility).
16
Relational Keys
 There are several candidate keys for a relation. When a
key consist of more than one attribute is called composite
key.

 In this table, given a value of city, we can determine

several branch office (for example, London has two
branch office). This attribute cannot be a candidate key.
On the other hand, because DreamHome allocates each
branch office a unique branch number, given a branch
number value, branchNo, we can determine at most one
tuple, so that branchNo is a candidate key. Similarly,
postcode is also candidate key. 17
 Relational Keys
 Consider the relation Viewing, which contains information
relating to properties viewed by the clients. The relation
comprises a client number (clientNo), a property number
(propertyNo), a date of viewing (viewDate) and, optionally, a
comment (comment). Given a client number, clientNo, there
maybe several corresponding viewings for the different
properties. Similarly, given a property number, propertyNo,
there may be several clients who viewed this property.
Therefore, clientNo by itself or propertyNo by itself cannot be
selected as a candidate key. However the combination of
clientNo and propertyNo together form a (composite) candidate
key. If we need to take into account the possibility that the client
may view property more than once, then we could add viewDate
to the composite key. However we assume that this is not
necessary. 18
Relational Keys
 Primary Key
– Candidate key selected to identify tuples uniquely
within relation.
– A relation always has a primary key. In the worst
case, the entire set of attributes could serve as the
primary key.
 Alternate Keys
– Candidate keys that are not selected to be primary
key.
 For branch relation, if we choose branchNo as primary key,
postcode could be an alternative key.
 For Viewing relation, there in only one candidate key, comprising
clientNo and propertyNo, so these attributes would automatically
form the primary key.
19
 Relational Keys

 Foreign Key
– Attribute, or set of attributes, within one relation that
matches candidate key of some (possibly same) relation.
– When an attribute appears in more than one relation, its
appearance usually represents a relationship between tuples
of the two relations. For example, the inclusion of branchNo
in both Branch and Staff relations, is quite deliberate and
links each branch to the details of staff working at the
branch. In the Branch relation, branchNo is a the primary
key. However, in the Staff relation, branchNo attribute exist
to match staff to the branch office they work in. In the Staff
relation, branchNo is a foreign key. We say that the attribute
branchNo in the Staff relation targets the primary key 20

attribute branchNo in the home relation Branch.

 Representing Relational Database Schemas
 A relational database consist of any number of
normalized relations. The relational schema for part of
the DreamHome case study is:
Branch(branchNo, street, city, postcode)
Staff(staffNo, fName, lName, position, sex, DOB, salary, branchNo)
PropertyForRent(propertyNo, street, city, postcode, type, rooms,
rent, ownerNo, staffNo, branchNo)
Client(clientNo, fName, lName, telNo, prefType, maxRent, eMail)
PrivateOwner(ownerNo, fName, lName, address, telNo, email,
password)
Viewing(clientNo, propertyNo, viewDate, comment)
Registration(clientNo, branchNo, staffNo, dateJoined) 21
Representing Relational Database Schemas
 The common convention for representing a relation
schema is to give the name of the relation followed
by the attribute names in parenthesis. Normally the
primary key is underline.
 The conceptual model or conceptual schema, is the
set of all such schema for the database.
 The instances of this relational schema will be in
the next slide.

22
23
Integrity Constraints
 Null
– Represents value for an attribute that is currently
unknown or not applicable for tuple.
– Deals with incomplete or exceptional (special)
data.
– Represents the absence of a value and is not the
same as zero or spaces, which are values.
– For example, in the viewing relation, the comment
attribute may be undefined until the potential
renter has visited the property and returned his or
her comment to the agency.
24
Integrity Constraints
 Null
– Without Nulls, it becomes necessary to introduce
false data to represent this state or to add
additional attributes that may not be meaningful
to the user. In our example, we try to represent the
a null comment with the value of -1.
– Alternatively, we may add a new attribute
hasCommentBeenSupplied to the viewing relation,
which contain a Y(Yes) if a comment has been
supplied and N(No) otherwise. Both these
approaches can be confusing to the user.
25
Integrity Constraints
 Entity Integrity
– In a base relation, no attribute of a primary key
can be null.
 Example, branchNo is the primary key of Branch
relation, we should not be able to insert a tuple into the
Branch relation with a null for the branchNo attribute.
 Consider the composite primary key of the Viewing
relation, comprising the client number (clientNo) and
the property number (propertyNo). We should not able
to insert a tuple into the viewing realtion with a null for
clientNo attribute or a null for the propertyNo attribute
or null for both attributes.
26
Integrity Constraints
 Referential Integrity
– If foreign key exists in a relation, either foreign key value
must match a candidate key value of some tuple in its
home relation or foreign key value must be wholly null.
– Example, branchNo in the Staff relation is a foreign key
targeting the branchNo attribute in the home relation
(Branch). It should not be possible to create a staff
record with branch number B025, for example, unless
there is already a record for branch number B025 in the
Branch relation. However, we should be able to create a
new staff record with a null branch number to allow for
the situation where a new member of staff has joined the
company but has not yet been assigned to a particular
branch office. 27
Integrity Constraints
 General Constraints
– Additional rules specified by users or database
administrators that define or constrain some
aspect of the enterprise.
– Example, if an upper limit of 20 has been placed upon the
number of staff that may work at a branch office, then the
user must able to specify this general constraint and
expect the DBMS to enforce it. In case, it should not
possible to add new member of staff at a given branch to a
Staff relation if the number of staff currently assigned to
branch is 20.
28
Views
 In the three-level ANSI-SPAC architecture,
describes the external view as a structure of the
database as it appears to a particular user.
 A view is a virtual or derived relation: a
relation that does not necessary exist in its own
right, but dynamically derived from one or
more based relations. Thus , an external model
can consist of both base (conceptual-level)
relations and views derived from the base
relation.

29
© Pearson Education Limited 1995, 2005
Views Terminology
 Base Relation
– Named relation corresponding to an entity in
conceptual schema, whose tuples are physically
stored in database.
 View
– Dynamic result of one or more relational
operations operating on base relations to
produce another relation.
– A view is a virtual relation that does not
necessarily exist in the database but can
produced upon request by a particular, at the
time of request. 30
Views
 Contents of a view are defined as a query on one
or more base relations. Any operations on the
view are automatically translated into operations
on the relations from which it is derived.

 Views are dynamic, meaning that changes made

to base relations that affect view attributes are
immediately reflected in the view. When a user
make permitted changes to the view, these
changes are made to the underlying(original)
relations.
31
Purpose of Views
 Provides powerful and flexible security mechanism
by hiding parts of database from certain users.
User are not aware of the existence of any
attributes or tuples that are missing from the view.
 Permits users to access data in a customized way, so
that same data can be seen by different users in
different ways, at same time.
 Can simplify complex operations on base relation.
For example, if a view is defined as combination
(join) of two relations, user may now perform more
simple operations on the view, which will be
translate by the DBMS into equivalent operations
on the join.
32
Updating Views
 All updates to a base relation should be
immediately reflected in all views that
reference that base relation.
 If view is updated, underlying base relation
should reflect change.
 However, there are restrictions on the types of
modification that can be made through views,
summary on the next slide.

33
Updating Views
 There are restrictions on types of modifications
that can be made through views:
– Updates are allowed if query involves a single
base relation and contains a candidate key of
base relation.
– Updates are not allowed involving multiple base
relations.
– Updates are not allowed involving aggregation
or grouping operations.

34