Syllabus

Unit-2
• Relational Model and Relational Algebra
• Mapping Conceptual Design into a Logical Design
The Relational Data Model and Relational Database Constraints

Relational Model Concepts

 The relational model represents the database as a collection of
relations.
 When a relation is thought of as a table of values, each row in the
table represents a collection of related data values.
 In the formal relational model terminology, a row is called a tuple,
a column header is called an attribute, and the table is called a
relation.
 The data type describing the types of values that can appear in
each column is represented by a domain of possible values.
 Domains, Attributes, Tuples, and Relations

A domain D is a set of atomic values.

Example: Names: The set of character strings that represent names of
persons.
A data type or format is also specified for each domain.
Example: The data type for Employee_ages is an integer number
between 15 and 80.
A relation schema R, denoted by R(A1, A2, ...,An) is made up of a
relation name R and a list of attributes A1, A2, ...,An. A relation
schema is used to describe a relation; R is called the name of this
relation.
The degree of a relation is the number of attributes n of its relation
schema.
Example: STUDENT(Name, USN, phone, Address, Age, CGPA)
A relation (or relation state) r of the relation schema R(A1, A2, ...,
An), also denoted by r(R), is a set of n-tuples r = {t1, t2, ..., tm}.
 Characteristics of Relations
1. Ordering of Tuples in a Relation.
2. Ordering of Values within a Tuple and an Alternative Definition of
a Relation.
3. Values and NULLs in the Tuples.
4. Interpretation (Meaning) of a Relation.
Ordering of Tuples in a Relation
 Tuples in a relation do not have any particular order. There is no
preference for one ordering over another.

Ordering of Values within a Tuple and an Alternative Definition of

a Relation.
 The order of attributes and their values is not that important as long
as the correspondence between attributes and values is maintained.
Values and NULLs in the Tuples.

 Each value in a tuple is an atomic value; that is, it is not divisible.

Hence, composite and multivalued attributes are not allowed.
 Example: STUDENT tuples have NULL for their office phones
because they do not have an office .
Interpretation (Meaning) of a Relation
 Each tuple in the relation can be interpreted as a fact or a particular
instance of the assertion.
 For example, a STUDENT relation whose Name is Benjamin
Bayer, Ssn is 305-61-2435, Age is 19, and so on.
 Relations may represent facts about entities, whereas other relations
may represent facts about relationships.
 For example, a relation schema MAJORS (Student_ssn,
Department_code) asserts that students major in academic
disciplines.
 Relational Model Constraints
Constraints on databases can generally be divided into three main
categories :
Inherent model-based constraints or implicit constraints
 The constraint that a relation cannot have duplicate tuples is an inherent
constraint
Application-based or semantic constraints or business rules
 The salary of an employee should not exceed the salary of the employee‘s
supervisor and the maximum number of hours an employee can work on all
projects per week is 56.
Schema-based constraints or explicit constraints
 The schema-based constraints include domain constraints, key constraints,
constraints on NULLs, entity integrity constraints, and referential
integrity constraints.
Schema-based constraints:
Domain Constraints:
• Each attribute value must be either null (which is really a non-
value) or drawn from the domain of that attribute. Note that some
DBMS's allow you to impose the not null constraint upon an
attribute, which is to say that no tuple (in the relevant relation) is
allowed to have the (non-)value null in that attribute.
Key Constraints:
• A relation is a set of tuples, and each tuple's "identity" is given by
the values of its attributes. That is, no two tuples may have the
same combination of values in their attributes.
• The subsets of attributes of a relation schema R with the property
that no two tuples in any relation state r of R should have the same
combination of values for these attributes. Any such set of
attributes SK is called a superkey of the relation schema R.
•
• A key K of a relation schema R is a superkey of R with the
additional property that removing any attribute A from K
leaves a set of attributes K that is not a superkey of R any
more.
• Consider the STUDENT relation. The attribute set {Usn} is a
key of STUDENT because no two student tuples can have the
same value for Usn.
• Any set of attributes that includes Usn for example, {Ssn,
Name, Age}—is a superkey. However, the superkey {Ssn,
Name, Age} is not a key of STUDENT because removing
Name or Age or both from the set still leaves us with a
superkey.
In general, a relation schema may have more than one key. In this
case, each of the keys is called a candidate key. For example, the
CAR relation in Figure above has two candidate keys:
License_number and Engine_serial_number. It is common to
designate one of the candidate keys as the primary key of the
relation. This is the candidate key whose values are used to identify
tuples in the relation. The other candidate keys are designated as
unique keys, and are not underlined.
Primary key: A key which is used to uniquely identify each record is
known as primary key. From above Candidate keys any one can be the
primary key.

Relational Databases and Relational Database Schemas

Entity Integrity, Referential Integrity, and Foreign Keys

Entity Integrity Constraint:

• No primary key value can be NULL.
• For example, if two or more tuples had NULL for their primary
keys, we may not be able to distinguish them if we try to reference
them from other relations.
Referential Integrity Constraint:
• The referential integrity constraint states that a tuple in one relation
that refers to another relation must refer to an existing tuple in that
relation.
• For example, The attribute Dno of EMPLOYEE gives the
department number for which each employee works; hence, its
value in every EMPLOYEE tuple must match the Dnumber value
of some tuple in the DEPARTMENT relation.
.
 Update Operations, Transactions & Dealing with Constraint
Violations
There are three basic operations that can change the states of relations in
the database: Insert, Delete, and Update.
The Insert Operation
The Insert operation provides a list of attribute values for a new tuple t
that is to be inserted into a relation R.
Insert can violate any of the four types of constraints.
1. Domain constraints can be violated if an attribute value is given that
does not appear in the corresponding domain or is not of the appropriate
data type.
2. Key constraints can be violated if a key value in the new tuple t
already exists in another tuple in the relation r(R).
3. Entity integrity can be violated if any part of the primary key of the
new tuple t is NULL.
4. Referential integrity can be violated if the value of any foreign key in
t refers to a tuple that does not exist in the referenced relation.
The Delete Operation
The Delete operation can violate only referential integrity. This
occurs if the tuple being deleted is referenced by foreign keys from
other tuples in the database.

Several options are available if a deletion operation causes a

violation.
The first option, called restrict, is to reject the deletion.
The second option, called cascade, is to attempt to cascade (or
propagate) the deletion by deleting tuples that reference the tuple
that is being deleted.
A third option, called set null or set default, is to modify the
referencing attribute values that cause the violation; each such value
is either set to NULL or changed to reference another default valid
tuple.
The Update Operation
The Update (or Modify) operation is used to change the values of one
or more attributes in a tuple (or tuples) of some relation R.
Ex: Update the salary of the EMPLOYEE tuple with
Ssn = 999887777‘ to 28000.

The Transaction Concept

A transaction is an executing program that includes some database
operations, such as reading from the database, or applying insertions,
deletions, or updates to the database. At the end of the transaction, it
must leave the database in a valid or consistent state that satisfies all
the constraints specified on the database schema.
 The Relational Algebra
The relational algebra is very important for several reasons.
 provides a formal foundation for relational model operations.
 Used as a basis for implementing and optimizing queries in the
query processing and optimization modules.
 Unary Relational Operations: SELECT and
PROJECT
The SELECT Operation
The SELECT operation is used to choose a subset of the tuples from a
relation that satisfies a selection condition.
The PROJECT Operation
The SELECT operation chooses some of the rows from the table while
discarding other rows. The PROJECT operation, on the other hand,
selects certain columns from the table and discards the other columns.
For example, to list each employee‘s first and last name and salary, we
can use the PROJECT operation as follows:

For Ex: consider the following PROJECT operation:

Пgender, Salary (Employee)

In SQL, the PROJECT attribute list is specified in the SELECT clause
of a query.
SELECT gender, Salary FROM EMPLOYEE
Sequences of Operations and the RENAME Operation
To retrieve the first name, last name, and salary of all employees who
work in department number 5, we must apply a SELECT and a
PROJECT operation.

RENAME
The general RENAME operation when applied to a relation R of
degree n is denoted by any of the following three forms:

where the symbol ρ (rho) is used to denote the RENAME operator,

S is the new relation name, and B1, B2, ..., Bn are the new attribute
names.
SELECT E.Fname AS First_name, E.Lname AS Last_name, E.Salary
AS Salary FROM EMPLOYEE AS E WHERE E.Dno=5.
Relational Algebra Operations from Set Theory
The UNION, INTERSECTION, and MINUS Operations
For example, To retrieve the Social Security numbers of all
employees who either work in department 5 or directly supervise an
employee who works in department 5.
The CARTESIAN PRODUCT (CROSS PRODUCT) Operation
Suppose that we want to retrieve a list of names of each female
employee‘s dependents.
 Binary Relational Operations: JOIN and DIVISION

The JOIN Operation

To illustrate JOIN, suppose that we want to retrieve the name of the
manager of each department. To get the manager‘s name, we need to
combine each department tuple with the employee tuple whose Ssn
value matches the Mgr_ssn value in the department tuple.
Consider the earlier example illustrating CARTESIAN PRODUCT,
which included the following sequence of operations:
Variations of JOIN: The EQUIJOIN and NATURAL JOIN
The JOIN operation where the only comparison operator used is = in join
condition is called an EQUIJOIN.
EQUIJOIN always have one or more pairs of attributes that have
identical values in every tuple.
For example, in Figure below, the values of the attributes Mgr_ssn and
Ssn are identical in every tuple of DEPT_MGR (the EQUIJOIN result)
because the equality join condition specified on these two attributes
requires the values to be identical in every tuple in the result.
• To get rid of the second (superfluous) attribute in an EQUIJOIN
condition, a new operation called NATURAL JOIN denoted by *
was created.
• Suppose we want to combine each PROJECT tuple with the
DEPARTMENT tuple that controls the project. In the following
example, first we rename the Dnumber attribute of DEPARTMENT
to Dnum so that it has the same name as the Dnum attribute in
PROJECT and then we apply NATURAL JOIN:
The DIVISION Operation
The division operator is an interesting operator that is useful in
answering queries that involve “for all” statements.
The DIVISION operation, denoted by ÷, is useful for a special kind of
query that sometimes occurs in database applications.
An example is Retrieve the names of employees who works for all the
projects that ‘John Smith’ works on. To express this query using the
DIVISION operation, proceed as follows. First, retrieve the list of
project numbers that ‘John Smith’ works on in the intermediate
relation SMITH_PNOS:
List of the various basic relational algebra operations
 Additional Relational Operations
Generalized Projection
Consider the relation EMPLOYEE (Ssn, Salary, Deduction,
Years_service)
A report may be required to show
Net Salary = Salary – Deduction,
Bonus = 2000 * Years_service,
and Tax = 0.25 * Salary.

Then a generalized projection combined with renaming may be used

as follows:
Aggregate Functions and Grouping
Aggregate functions are used in simple statistical queries that
summarize information from the database tuples. Some of the
aggregate functions are SUM, AVERAGE, MAXIMUM, and
MINIMUM. The COUNT function is used for counting tuples or
values.
Recursive Closure Operations
 OUTER JOIN Operations
• A NATURAL JOIN operation R * S, only tuples from R that have
matching tuples in S and vice versa appear in the result. Hence,
tuples without a matching tuple are eliminated from the JOIN
result. Tuples with NULL values in the join attributes are also
eliminated. This type of join, where tuples with no match are
eliminated, is known as an inner Join.
• A set of operations, called outer joins, is the case where the user
wants to keep all the tuples in R, or all those in S, or all those in
both relations in the result of the JOIN,
There are three types of outer join operations: left outer join, right
outer join, and full outer join.
1. Left Outer Join (R ⋈ S)
All the tuples from the Left relation, R, are included in the resulting
relation. If there are tuples in R without any matching tuple in the
Right relation S, then the S-attributes of the resulting relation are
made NULL.
1. Right Outer Join: (R ⋈ S)
All the tuples from the Right relation, S, are included in the resulting
relation. If there are tuples in S without any matching tuple in R, then the
R-attributes of resulting relation are made NULL.
Full Outer Join: (R ⋈ S)
All the tuples from both participating relations are included in the
resulting relation. If there are no matching tuples for both relations, their
respective unmatched attributes are made NULL.
 Examples of Queries in Relational Algebra
Query 1. Retrieve the name and address of all employees who work
for the ‘Research’ department.
Query 2. For every project located in ‘Stafford’, list the project
number, the controlling department number, and the department
manager’s last name, address, and birth date.
Query 3. Find the names of employees who work on all the projects
controlled by department number 5.
Query 4. Make a list of project numbers for projects that involve an
employee whose last name is ‘Smith’, either as a worker or as a
manager of the department that controls the project.
Query 5. List the names of all employees with two or more
dependents.
Query 6. Retrieve the names of employees who have no dependents.
Query 7. List the names of managers who have at least one
dependent.
LOGICAL DATABASE DESIGN: ER TO RELATIONAL
The following steps show how to translate an ER diagram into a
collection of tables with associated constraints.
1. Entity Sets to Tables.
2. Relationship Sets (without Constraints) to Tables.
3. Translating Relationship Sets with Key Constraint
4. Translating Relationship Sets with Participation Constraints
5. Translating Weak Entity Sets
6. Translating class Hierarchies
7. Translating ER Diagrams with Aggregation
1. Entity sets to tables
2. Relationship Sets (without Constraints) to Tables
3. Translating Relationship Sets with Key Constraint
If a relationship set involves n entity sets and some m of them are
linked via arrows in the ER diagram, the key of these m entity sets
constitutes a key for the relation to which the relationship set is
mapped. Hence we have m candidate keys, and one of these should
be designated as the primary key.
4. Translating Relationship Sets with Participation Constraints
The NO ACTION specification, which is the default and need not be
explicitly specified, ensures that an Employees tuple cannot be
deleted while it is pointed to by a Dept_Mgr tuple. If we wish to
delete such an Employees tuple, we must first change the Dept_Mgr
tuple to have a new employee as manager.
5. Translating Weak Entity Sets
6. Translating class Hierarchies
7. Translating ER Diagrams with Aggregation
Give me 5 Questions which you predict
to be an important one!!!