The

The Relational
Relational Model
Model

Instructor: Maqsood Ahmad

Department of Information Security
IUB

1
 Queries

•The relational model was first proposed by E. F. Codd in his

seminal paper “A relational model of data for large shared data banks”
(Codd, 1970).
Objectives of RM
•To allow a high degree of data independence. Application programs
must not be affected by modifications to the internal data
representation, particularly by changes to file organizations, record
orderings, or access paths.
•To provide substantial grounds for dealing with data semantics,
consistency, and redundancy problems. In particular, Codd’s paper
introduced the concept of normalized relations, that is, relations that
have no repeating groups.
•To enable the expansion of set-oriented data manipulation languages.
 R Project

• IBM’s San José Research Laboratory in California, was the prototype relational
DBMS System R, which was developed during the late 1970s (Astrahan et al.,
1976).
• This project was designed to prove the practicality of the relational model
by providing an implementation of its data structures and operations
• It also proved to be an excellent source of information about
implementation concerns such as transaction management, concurrency
control, recovery techniques, query optimization, data security and
integrity, human factors, and user interfaces, and led to the publication of
many research papers and to the development of other prototypes.
• Development of a structured query language called SQL
• Production of various commercial relational DBMS products DB2 and
SQL/DS from IBM and Oracle from Oracle Corporation
 INGRES

• The second project to have been significant in the

development of the relational model was the INGRES
(Interactive Graphics Retrieval System) project at the
University of California at Berkeley
• With same overall objectives as the System R project.
• This research led to an academic version of INGRES
 Peterlee Relational Test Vehicle

• The third project was the Peterlee Relational Test

Vehicle at the IBM UK Scientific Centre in
Peterlee (Todd, 1976).
• This project had a more theoretical orientation
than the System R and INGRES projects and was
significant, principally for research into such issues
as query processing and optimization as well as
functional extension.
 Terminology

The relational model is based on the mathematical

concept of a relation, which is physically represented as
a table. Codd, a trained mathematician, used
terminology taken from mathematics
•Relation A relation is a table with columns and rows.
An RDBMS requires only that the database be perceived by
the user as tables.
Note: however, that this perception applies only to the
logical structure of the database: that is, the external and
conceptual levels of the ANSI-SPARC architecture
•Attribute An attribute is a named column of a relation.
• In the relational model, relations are used to hold
information about the objects to be represented in
the database.
• A relation is represented as a two-dimensional table
in which the rows (tuple) of the table correspond to
individual records and the table columns (attributes).
• The tuples are called the extension (or state) of a
relation, which changes over time.
 Domain
Domain A domain is the set of allowable values for one
or more attributes.
Every attribute in a relation is defined on a domain.
Domains may be distinct for each attribute, or two or more
attributes may be defined on the same domain
Degree: The degree of a relation is the number of
attributes it contains.

A relation with only one attribute would have degree one and be
called a unary relation or one-tuple.

A relation with two attributes is called binary, one with

three attributes is called ternary, and after that the term n-ary is
usually used.
Cardinality: The cardinality of a relation is the number of
tuples it contains.

The number of tuples is called the cardinality of the relation and

this changes as tuples are added or deleted.

The cardinality is a property of the extension of the relation and is

determined from the particular instance of the relation at any
given moment.
Relational database A collection of normalized relations with
distinct relation names.

A relational database consists of relations that are appropriately

structured. We refer to this appropriateness as normalization.
 Alternative terminology
The terminology for the relational model can be quite confusing.
In fact, a third set of terms is sometimes used: a relation may be
referred to as a file, the tuples as records, and the attributes as
fields.
This terminology stems from the fact that, physically, the
RDBMS may store each relation in a file
Relational database schema:
A set of relation schemas, each with a distinct name.
If R 1 , R 2 , . . . , R n are a set of relation schemas, then we can
write the relational database schema, or simply relational
schema, R, as:
R = {R 1 , R 2 , . . . , R n }
 Properties of
Relations
A relation has the following properties:
•The relation has a name that is distinct from all other relation
names in the relational schema;
•Each cell of the relation contains exactly one atomic (single)
value;
•Each attribute has a distinct name;
•The values of an attribute are all from the same domain;
•Each tuple is distinct; there are no duplicate tuples;
•The order of attributes has no significance;
•The order of tuples has no significance, theoretically. (However,
in practice, the order may affect the efficiency of accessing
tuples.)
 Relational Keys
There are no duplicate tuples within a relation. Therefore, we need
to be able to identify one or more attributes (called relational keys)
that uniquely identifies each tuple in a relation.

Super key
Candidate Key
Primary Key
Foreign Key
 Super Key
A Super Key is a set of one or more attributes (columns) that
can uniquely identify a record in a table. A super key may
contain additional attributes that are not necessary for unique
identification.
Example: Consider a table named Employees
 Candidate Key
A Candidate Key is a minimal super key, meaning it is a super
key with no unnecessary attributes. In other words, a candidate
key is the minimal set of attributes that can uniquely identify a
record.
Example: In the Employees table:
{EmployeeID} is a Candidate Key because it uniquely identifies each
employee, and removing any attribute would prevent it from being
unique.
{Email} could also be a Candidate Key if we assume that each
employee has a unique email.

When a key consists of

more than one attribute,
we call it a composite
key.
 Primary Key
A Primary Key is a candidate key chosen by the database
designer to uniquely identify records in a table. There can be
multiple candidate keys, but only one primary key can be
selected for a table.
Example: In the Employees table:
{EmployeeID} is often chosen as the Primary Key because
it is unique and simple. It ensures that each employee can be
uniquely identified without ambiguity.
A Unique Key is similar to a Primary Key in
that it must contain unique values for each
record. However, unlike the primary key, a
table can have multiple unique keys, and they
can contain null values (though values must
still be unique).
 Primary Key
A Foreign Key is an attribute or a set of attributes in one table
that is used to establish a link between the data in two tables. It
acts as a reference to the Primary Key of another table. Foreign
keys are used to maintain referential integrity between tables.
In the Employees table:DeptID is a Foreign Key that references the DeptID
in the Departments table. This relationship ensures that each employee is
assigned to a valid department.
 Surrogate Key vs Natural Key
Surrogate Key
A Surrogate Key is an artificial key assigned to a table to
uniquely identify each record, typically used when no natural
primary key is available. It usually takes the form of an auto-
incremented integer.

Natural Key
A Natural Key is a key that has a real-world meaning and is
derived from existing data. For example, a Social Security
Number or Email can be used as a natural key to uniquely
identify individuals.
 Terminology
Attribute names

Name Price Category Manufacturer

gizmo $19.99 gadgets GizmoWorks

Power gizmo $29.99 gadgets GizmoWorks

SingleTouch $149.99 photography Canon

MultiTouch $203.99 household Hitachi

tuples
 Integrity Constraints

Set of integrity constraints, which ensure that the data is accurate.

Null:
Represents a value for an attribute that is currently unknown or is not
applicable for this tuple.
A null can be taken to mean the logical value “unknown.” It can mean that
a value is not applicable to a particular tuple, or it could merely mean that
no value has yet been supplied. Nulls are a way to deal with
incomplete or exceptional data.
However, a null is not the same as a zero numeric value or a text string
filled with spaces; zeros and spaces are values, but a null represents the
absence of a value
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.
 Integrity Constraints

Entity Integrity:

The first integrity rule applies to the primary keys of base relations
By definition, a primary key is a minimal identifier that is used to identify
tuples uniquely.
This means that no subset of the primary key is sufficient to provide
unique identification of tuples. If we allow a null for any part of a primary key,
we are implying that not all the attributes are needed to distinguish between
tuples, which contradicts the definition of the primary key.

For example, as branchNo is the primary key of the Branch

relation, we should not be able to insert a tuple into the Branch
relation with a null for the branchNo attribute.
 Integrity Constraints
Referential Integrity:
If a foreign key exists in a relation, either the foreign key value must match a
candidate key value of some tuple in its home relation or the foreign key value
must be wholly null.
For 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, unless there
is already a record for branch number
B025 in the Branch relation.
 Integrity Constraints
General Constraints:
Additional rules specified by the users or database administrators
of a database that define or constrain some aspect of the enterprise.

For 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 be able to specify this
general constraint and expect the DBMS to enforce it.

In this case, it should not be possible to add a new member of staff at a given
branch to the Staff relation if the number of staff currently assigned to that
branch is 20.
 Views
In the three-level ANSI-SPARC architecture, we described an
external view as the structure of the database as it appears to a
particular user.

In the relational model, the word “view” has a slightly different

meaning. Rather than being the entire external model of a user’s
view, a view is a virtual or derived relation: a relation that
does not necessarily exist in its own right, but may be
dynamically derived from one or more base relations.
The dynamic result of one or more relational operations operating on
the base relations to produce another relation. A view is a virtual relation
that does not necessarily exist in the database but can be produced upon
request by a particular user, at the time of request.
 Purpose of Views
• It provides a powerful and flexible security mechanism by hiding parts of the
database from certain users. Users are not aware of the existence of any attributes or
tuples that are missing from the view.
• It permits users to access data in a way that is customized to their needs, so that the
same data can be seen by different users in different ways, at the same time.
• It can simplify complex operations on the base relations. For example, if a view is
defined as a combination (join) of two relations (see Section 5.1), users may now
perform more simple operations on the view, which will be translated by the DBMS
into equivalent operations on the join.
• A user might need Branch tuples that contain the names of managers as well
as the other attributes already in Branch. This view is created by combining the
• Branch relation with a restricted form of the Staff relation where the staff position is
“Manager.”
• Some members of staff should see Staff tuples without the salary attribute.
• Attributes may be renamed or the order of attributes changed. For example, the user
accustomed to calling the branchNo attribute of branches by the full name
Branch Number may see that column heading.
• Some members of staff should see property records only for those properties that they
manage.
 Study the DreamHome case study presented in Section
11.4 and Appendix A.
 More Terminology

Every attribute has an atomic type.

Relation Schema: relation name + attribute names + attribute types

Relation instance: a set of tuples. Only one copy of any tuple!

Database Schema: a set of relation schemas.

Database instance: a relation instance for every relation in the schema.

 From E/R Diagrams to Relational
Schema
Easier than ODL (using a liberal interpretation of the word “easy”)

- relationships are already independent entities

- only atomic types exist in the E/R model.

Entity sets relations

Relationships relations

Special care for weak entity sets.

 name category
name

price
makes Company
Product

Stock price

buys employs

Person

address name ssn

 Entity Sets to Relations
name category

price

Product

Product:

Name Category Price

gizmo gadgets $19.99

 Relationships to Relations
name category Start Year
name

makes Company
Product

Stock price
Relation MAKES (watch out for attribute name conflicts)

Product-name Product-Category Company-name Starting-year

gizmo gadgets gizmoWorks 1963

 Handling Weak Entity Sets

Team affiliation University

sport number name

Relation TEAM:

Sport Number University-name

mud wrestling 15 Montezuma State U.

- need all the attributes that contribute to the key of Team

- don’t need a separate relation for Affiliation.
 Modeling Subclass Structure

Product
Platforms
required memory ageGroup
topic
Software Educational
Product Product

Educ-software Educational-method
Product
 Option #1: the ODL Approach

4 tables: each object can only belong to a single class

Product(name, price, category, manufacturer)

EducationalProduct( name, price, category, manufacturer, ageGroup,

topic)

SoftwareProduct( name, price, category, manufacturer, platforms,

requiredMemory)

EducationalSoftwareProduct( name, price, category, manufacturer,

ageGroup, topic, platforms,
requiredMemory)
 Option #2: the E/R Approach

Product(name, price, category, manufacturer)

EducationalProduct( name, ageGroup, topic)

SoftwareProduct( name, platforms, requiredMemory)

No need for a relation EducationalSoftwareProduct

Unless, it has a specialized attribute:

EducationalSoftwareProduct(name, educational-method)
 Option #3: The Null Value
Approach

Have one table:

Product ( name, price, manufacturer, age-group, topic, platforms,

required-memory, educational-method)

Some values in the table will be NULL, meaning that the attribute
not make sense for the specific product.

How many more meanings will NULL have??