Lecture 6.

Relational Algebra,
Functional Dependencies and
Normalization
(Chapter 8 and 14)
[email protected]
Connection to previous lectures
ER/EER Relational Model How good is your model?

Lecture 3 ER and EER Lecture 4 Relation Lecture 5 Lecture 6

Conceptual models Model SQL

• High –level data • Medium-level • Low-level • Functional

abstraction using data abstraction abstraction Dependencies
Entity Relation using Relational • SQL standard • Normalization:
(ER) and Models language to 1NF, 2NF,3 NF
Enhanced Entity • From ER to create and • Relational Algebra
Relation (EER) Relational Model manipulate the Operations
models database

2(44)
Outline
• Functional Dependencies
• Normalization: 1NF,2NF,3NF
• Break 10 min
• Relational Algebra Operations

3(44)
Informal Guidelines for Relation Databases

• Guideline1. Making sure that the Bad design

Example:
semantics of attributes is clear in
the schema: Do not combine
attributes from multiple entities Employee_Department
and relationships into a single
table. If a relation schema
corresponds to one entity or one
relation, it is straightforward to
explain its meaning. But if the Employee Entity Department Entity
relationship corresponds to a
mixture of multiple entities (non-
binary relationships), the relation Employee_Project
can not be easily explained.

Employee Entity Project Entity

4(44)
A simplified COMPANY relational
database schema.

Better design according the Guideline 1

5(44)
Informal Guidelines for Relation Databases
Example
Employee_Department

• Guideline 2. Reducing the

redundant information in tuples:
design the relation
schema/database so that no
Employee_Project
insertion, deletion, or modification
anomalies are present in the
entities/tables. If anomalies are
present, note them clearly and
make sure that the programs (e.g.,
Python program) that updates the
database will operate correctly.
6(44)
Informal Guidelines for Relation Databases
• Guidelines 3: Reducing NULL values in tuples/rows: As far as
possible, avoid placing attributes in a base relation whose values may
frequently be NULL. If NULL are unavoidable, make sure that they
apply in exceptional cases only and do not apply to a majority of
tuples/rows in the table.
• For example:
• if only 15% of employees have individual offices, there is little justification for
including an attribute Office_number in the EMPLOYEE table; an additional
table Employee_Offices (Essn,Office_number) can be created to include
rows/tuples for only the employees with individual offices.

7(44)
 Informal Guidelines for Relation
Databases Example 1 No Spurious Rows

Original Entity After join operation

• Guideline 4. Disallowing the possibility of generating
spurious tuples/rows in table:
• Spurious tuples/rows are those rows in a table, which
occur as a result of natural joining two tables in wrong
manner (more rows than the original sat of rows). They
are extra (rows) which might not be required. Natural Geeks=Geeks (primary key)
join is implicit join statement on the common columns
with the same names in the two tables being joined.
• Design relation tables so that they can be joined with Example 2 Generated Spurious Rows
equality conditions on attributes that are appropriately
related (primary key, foreign key) pairs in a way that
guarantees that no spurious rows are generated
• Avoid tables that contain matching attributes that are
not (foreign key, primary key) combinations because
joining on such attributes may produce spurious rows.
• Solution: the equality condition on primary key or foreign keys
should be applied.

for=for ( not primary

Image taken from: https://www.geeksforgeeks.org/spurious- key/foreign key)
8(44)
tuples-in-dbms/
 Functional Dependencies (1)
• A functional dependency (FD) is a relationship between two attributes, typically between the primary key
(PK) and other non-key attributes within a table.
• For any relation R (or table), attribute Y is functionally dependent on attribute X (usually the PK), if for every
valid instance of X, that value of X uniquely determines the value of Y. This relationship is indicated by the
representation below :
• X →Y
• The left side (X) is called the determinant, and the right side (Y) is the dependent.
• Example using Employee_Project table (on slide 6):
Example Explanation
Ssn → Ename The value of an employee’s social security number (Ssn) uniquely determines
the employee name (Ename)
Pnumber →{Pname, Plocation} The values of a project’s number (Pnumber) uniquely determines the project
name (Pname) and location (Plocation)
{Ssn,Pnumber} → Hours A combination of Ssn and Pnumber values uniquely determines the number of
hours the employee currently works on the project per week (Hours) 9(44)
Functional Dependencies (2)
• A functional dependency is a property of Example. A table R(A,B,S,D) at particular state r1
the relation table R, not of a particular
table state r of R.
• Therefore, an FD cannot be inferred
automatically from a given relation state r
but must be defined explicitly by someone
who knows the semantics of the attributes
of R. All we can say is that a certain FD
may exist if it holds in that particular state
r.
FD may hold:
• Hence, we can identify a certain FD which B → C; C →B; {A,B} → C; {A,B} → D
does not hold if there are rows which show FD do not hold:
the violation of such an FD. A →B (rows 1 and 1 violates this constrain);
B →A (rows 2 and 3 violate this constrain);
D → C (roes 3 and 4 violate it) 10(44)
Functional Dependencies (3)
• FD can be displayed on the diagram as follow:

FD1: {Snn, Pnumber} → Hours

FD2: Snn → Ename
FD3: Pnumber → {Pname,Plocation}

11(44)
Methodology for testing and improving
Relation Database
• Using the Normalization of Relations
• The normalization process take a relation database (or schema) through a
series of tests to certify whether it satisfies a certain normal form.
• All the tables in a database can be in one of the normal forms.
• There are six normal forms, but we will look at the first three, which are:
• First normal norm (1NF)
• Second normal norm (2NF)
• Third normal norm (3NF)
• The normal form of a table refers to the highest normal form condition
that it meets, and hence indicates the degree to which it has been
normalized

12(44)
 Department table is not in 1NF

First Normal Form( 1NF)

Sample state of table DEPARTMENT
• 1NF disallows relations within relations, or
relations as attribute values within rows.
The only attribute values permitted by 1NF
are single atomic (or indivisible) values.
• Example:
• The domain of Dlocation attrobite
contains atomic values or single- DEPARTMENT is not in 1NF version with redundancy
valued (e.g., Houston), but some rows
can have a set o these values (when
one department has several
locations). In this case, Dlocation is
not functionally dependent on the
primary key Dnumber.
• Normalization to 1NF: remove the
attribute Dlocations that violates 1NF
and place it in a separate table called
DEPT_LOCATIONS with primary key
Dnumber of DEPARTMENT. The
primary key of this newly formed
table is the combination
{Dnumber,Dlocation}
DEPARTMENT and DEPT_LOCATIONS in 1NF form

13(44)
 Normalizing nested relations to 1NF

Normalizing nested relations into 1NF.

(a)Schema of the EMP_PROJ relation with a nested
relation attribute PROJS.
(b) Sample extension of the EMP_PROJ relation
showing nested relations within each tuple.
(c)Decomposition of EMP_PROJ into relations
EMP_PROJ1 and EMP_PROJ2 by propagating the
primary key.

14(44)
Second Normal Form( 2NF)
Normalizing EMP_PROJ into 2NF relations
• A database (relation schema) R is in 2NF if every
nonprime attribute A in R is fully functionally
dependent on the primary key of R.
• Fully functionally dependent means PK are single-
valued attribute or is a composite PK, then each
non-key attribute must be fully dependent on the
entire PK and not on a subset of the PK (i.e., there
must be no partial dependency).
• Normalization to 2NF:
• The relation must first be in 1NF. We can not
jump from non 1NF to 2NF without first to
normalize to 1NF. So, non NF → 1NF →2NF
• Decompose and set up a new table for each
partial key with its dependent attribute(s).

15(44)
Third Normal Form (3NF)
Example: EMP_DEPT in 2NF form.
Hence it has non-key attributes FDs. Non-key attribute
• A database (relation schema) R is in 3NF if it Dnumber uniquely identifies other non-key attributes
satisfies 2NF and no noprime attribute of R is Dname and Dmgr_snn. Thus violate the 3NF constrain
transitively dependent on the primary key.
• More precisely: a non-key attribute may not be
functionally dependent on another non-key
attribute.
• Normalization to 3NF:
• The relation must first be in 2NF. We can
not jump from non 1NF to 3NF without first
to normalize to 2NF. So, non NF → 1NF
→2NF →3NF ED1 table have single-valued primary key Ssn which uniquely
• Decompose and set up a relation that identifies all other attributes. No FDs between non-key
includes the nonkey attribute(s) that Attributes
functionally determine(s) other nonkey
Same for ED2
attribute(s).

16(44)
Summary of Three Normal Forms

17(44)
Break 10 min

18(44)
Relational Algebra
• Relational algebra is the basic set of operations for the relational model
• These operations enable a user to specify basic retrieval requests (or queries)
• The result of an operation is a new relation, which may have been formed
from one or more input relations
• The algebra operations thus produce new relations
• These can be further manipulated using operations of the same algebra
• A sequence of relational algebra operations forms a relational algebra
expression
• The result of a relational algebra expression is also a relation that represents the
result of a database query (or retrieval request)
• Relation (formal name) means table (informal name)

19(44)
Relational Algebra Overview
• Relational Algebra consists of several groups of operations
• Unary Relational Operations
• SELECT (symbol: s (sigma))
• PROJECT (symbol: p (pi))
• RENAME (symbol: r (rho))
• Relational Algebra Operations From Set Theory
• UNION ( È ), INTERSECTION ( Ç ), DIFFERENCE (or MINUS, – )
• CARTESIAN PRODUCT ( x )
• Binary Relational Operations
• JOIN (several variations of JOIN exist)
• DIVISION
• Additional Relational Operations
• OUTER JOINS, OUTER UNION
• AGGREGATE FUNCTIONS (These compute summary of information: for example, SUM, COUNT,
AVG, MIN, MAX)

20(44)
Company Schema

21(44)
Unary Relational Operations: SELECT
• The SELECT operation (denoted by s (sigma)) is used to select a subset of the tuples from a
relation based on a selection condition.
• The selection condition acts as a filter
• Keeps only those tuples that satisfy the qualifying condition
• Tuples satisfying the condition are selected whereas the other tuples are discarded
(filtered out)
• Examples:
• Select the EMPLOYEE tuples whose department number is 4:
s DNO = 4 (EMPLOYEE)
• Select the employee tuples whose salary is greater than $30,000:
s SALARY > 30,000 (EMPLOYEE)
22(44)
Unary Relational Operations: SELECT
• In general, the select operation is denoted by s <selection condition>(R)
where
• the symbol s (sigma) is used to denote the select operator
• the selection condition is a Boolean (conditional) expression specified on the attributes
of relation R
• tuples that make the condition true are selected
• appear in the result of the operation
• tuples that make the condition false are filtered out
• discarded from the result of the operation

23(44)
Unary Relational Operations: PROJECT
• PROJECT Operation is denoted by p (pi)
• This operation keeps certain columns (attributes) from a relation and
discards the other columns.
• PROJECT creates a vertical partitioning
• The list of specified columns (attributes) is kept in each tuple
• The other attributes in each tuple are discarded
• Example: To list each employee’s first and last name and salary, the
following is used:
pLNAME, FNAME,SALARY(EMPLOYEE)

24(44)
Unary Relational Operations: PROJECT (cont.)
• The general form of the project operation is:
p<attribute list>(R)
• p (pi) is the symbol used to represent the project operation
• <attribute list> is the desired list of attributes from relation R.
• The project operation removes any duplicate tuples
• This is because the result of the project operation must be a set of tuples
• Mathematical sets do not allow duplicate elements.
• PROJECT Operation Properties
• The number of tuples in the result of projection p<list>(R) is always less or equal to the
number of tuples in R
• If the list of attributes includes a key of R, then the number of tuples in the result of PROJECT
is equal to the number of tuples in R
• PROJECT is not commutative
• p <list1> (p <list2> (R) ) = p <list1> (R) as long as <list2> contains the attributes in <list1>

25(44)
Examples of applying SELECT and PROJECT
operations

26(44)
Relational Algebra Expressions
• We may want to apply several relational algebra operations one after
the other
• Either we can write the operations as a single relational algebra expression
by nesting the operations, or
• We can apply one operation at a time and create intermediate result
relations.
• In the latter case, we must give names to the relations that hold
the intermediate results.

27(44)
Single expression versus sequence of
relational operations (Example)
• 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
• We can write a single relational algebra expression as follows:
• pFNAME, LNAME, SALARY(s DNO=5(EMPLOYEE))
• OR We can explicitly show the sequence of operations, giving a name to each
intermediate relation:
• DEP5_EMPS ¬ s DNO=5(EMPLOYEE)
• RESULT ¬ p FNAME, LNAME, SALARY (DEP5_EMPS)

28(44)
Unary Relational Operations: RENAME
• The RENAME operator is denoted by r (rho)
• In some cases, we may want to rename the attributes of a relation or the relation
name or both
• Useful when a query requires multiple operations
• Necessary in some cases (see JOIN operation later)
• The general RENAME operation r can be expressed by any of the following forms:
• rS (B1, B2, …, Bn )(R) changes both:
• the relation name to S, and
• the column (attribute) names to B1, B1, …..Bn
• rS(R) changes:
• the relation name only to S
• r(B1, B2, …, Bn )(R) changes:
• the column (attribute) names only to B1, B1, …..Bn

29(44)
Unary Relational Operations: RENAME
(continued)
• For convenience, we also use a shorthand for renaming attributes in
an intermediate relation:
• If we write:
• RESULT ¬ p FNAME, LNAME, SALARY (DEP5_EMPS)
• RESULT will have the same attribute names as DEP5_EMPS (same
attributes as EMPLOYEE)
• If we write:
• RESULT (F, M, L, S, B, A, SX, SAL, SU, DNO)¬ r RESULT (F.M.L.S.B,A,SX,SAL,SU,
DNO)(DEP5_EMPS)
• The 10 attributes of DEP5_EMPS are renamed to F, M, L, S, B, A, SX,
SAL, SU, DNO, respectively
Note: the ¬ symbol is an assignment operator

30(44)
Relational Algebra Operations from
Set Theory: UNION
• UNION Operation
• Binary operation, denoted by È
• The result of R È S, is a relation that includes all tuples that are either in R or
in S or in both R and S
• Duplicate tuples are eliminated
• The two operand relations R and S must be “type compatible” (or UNION
compatible)
• R and S must have same number of attributes
• Each pair of corresponding attributes must be type compatible (have same or
compatible domains)

31(44)
Relational Algebra Operations from
Set Theory: UNION
• Example:
• To retrieve the social security
numbers of all employees who either
work in department 5 (RESULT1
below) or directly supervise an
employee who works in department 5
(RESULT2 below)
• We can use the UNION operation as
follows:
DEP5_EMPS ¬ sDNO=5 (EMPLOYEE)
RESULT1 ¬ p SSN(DEP5_EMPS)
RESULT2(SSN) ¬ pSUPERSSN(DEP5_EMPS)
RESULT ¬ RESULT1 È RESULT2
• The union operation produces the
tuples that are in either RESULT1 or
RESULT2 or both

32(44)
Relational Algebra Operations from Set
Theory: INTERSECTION
• INTERSECTION is denoted by Ç
• The result of the operation R Ç S, is a relation that includes
all tuples that are in both R and S
• The attribute names in the result will be the same as the
attribute names in R
• The two operand relations R and S must be “type
compatible”

33(44)
Example to illustrate the result of UNION,
INTERSECT, and DIFFERENCE

34(44)
Key terms (for Exam)
• A functional dependency(FD) is a constraint between two sets of attributes
from the database.
• A normalization is a process to determining how much redundancy exists
in a database. This process involves analysis of relational schema based on
their functional dependencies and primary key to minimizing redundancy,
insertions, edition, and update anomalies.
• The normal form of a relation/table refers to the highest normal form
condition that is meets, and indicates the degree to which it has been
normalized.
• There are six normal forms, but only three most commonly used are: 1NF,
2NF, and 3NF
• Th content and understanding of table 14.1 (slide 17)

35(44)