DBMS

Unit-3
Relational Model: Relation - Super keys - Candidate keys - Primary keys and foreign key for the
Relations - Integrity rules: Entity integrity, Referential integrity rule; Normalization: First,
Second, Third & BCNF Normal; Relational Algebra;
Relational Model in DBMS
• The relational model uses a collection of tables to represent both data and the
relationships among those data.
• Each table has multiple columns, and each column has a unique name.
• Tables are also known as relations.
• The relational model is an example of a record-based model. Record-based models
are so named because the database is structured in fixed-format records of several
types.
• Each table contains records of a particular type. Each record type defines a fixed
number of fields, or attributes. The columns of the table correspond to the
attributes of the record type.
• The relational data model is the most widely used data model, and a vast majority
of current database systems are based on the relational model
Relational model
• The relational model represents how data is stored in Relational Databases.
• A relational database consists of a collection of tables, each of which is assigned a
unique name.
• Consider a relation STUDENT with attributes ROLL_NO, NAME, ADDRESS, PHONE,
and AGE shown in the table.
• Table Student ROLL_NO NAME ADDRESS PHONE AGE

1 RAM DELHI 9455123451 18

2 RAMESH GURGAON 9652431543 18

3 SUJIT ROHTAK 9156253131 20

4 SURESH DELHI 18
Keys
• KEYS in DBMS is an attribute or set of attributes which helps you
to identify a row(tuple) in a relation(table).
• They allow you to find the relation between two tables.
• Keys help you uniquely identify a row in a table by a combination
of one or more columns in that table.
• Key is also helpful for finding unique record or row from the table.
• It is used to uniquely identify any record or row of data from the
table.
• It is also used to establish and identify relationships between
tables.
• For example, ID is used as a key in the Student table because it is
unique for each student. In the PERSON table, passport_number,
license_number, SSN are keys since they are unique for each
person.
Types of keys:
• Super key
• Candidate key
• Primary key
• Alternate key
• Foreign key
• Partial key
• Composite key
• Unique key
• Surrogate key
• Secondary key
Super Key-
• A super key is a set of attributes that can identify each tuple uniquely in the given relation.
• A super key is not restricted to have any specific number of attributes.
• Thus, a super key may consist of any number of attributes.
• Example-Consider the following Student schema-
Student ( roll , name , sex , age , address , class , section )
Given below are the examples of super keys since each set can uniquely identify each student in
the Student table-
( roll , name , sex , age , address , class , section )
( class , section , roll )
(class , section , roll , sex )
( name , address )
• NOTE- All the attributes in a super key are definitely sufficient to identify each tuple uniquely
in the given relation but all of them may not be necessary.
Candidate Key-
• A minimal super key is called as a candidate key. OR
• A set of minimal attribute(s) that can identify each tuple uniquely in the given relation is called as a candidate key.
• Example- Consider the following Student schema-
Student ( roll , name , sex , age , address , class , section )
Given below are the examples of candidate keys since each set consists of minimal attributes required to identify each student uniquely
in the Student table-
( roll )
( name , address )
• NOTES-
• All the attributes in a candidate key are sufficient as well as necessary to identify each tuple uniquely.
• Removing any attribute from the candidate key fails in identifying each tuple uniquely.
• The value of candidate key must always be unique.
• The value of candidate key can never be NULL.
• It is possible to have multiple candidate keys in a relation.
• Those attributes which appears in some candidate key are called as prime attributes.
Primary Key-
• A primary key is a candidate key that the database designer selects while
designing the database. OR
• Candidate key that the database designer implements is called as a primary
key.
• NOTES-
• The value of primary key can never be NULL.
• The value of primary key must always be unique.
• The values of primary key can never be changed i.e. no updation is
possible.
• The value of primary key must be assigned when inserting a record.
• A relation is allowed to have only one primary key.
Relationship among super key, candidate key and
primary key
Alternate Key-

• Candidate keys that are left unimplemented or unused after

implementing the primary key are called as alternate keys.
OR
• Unimplemented candidate keys are called as alternate keys.
Foreign Key-
• An attribute ‘X’ is called as a foreign key to some other attribute ‘Y’
when its values are dependent on the values of attribute ‘Y’.
• The attribute ‘X’ can assume only those values which are assumed by
the attribute ‘Y’.
• Here, the relation in which attribute ‘Y’ is present is called as
the referenced relation.
• The relation in which attribute ‘X’ is present is called as
the referencing relation.
• The attribute ‘Y’ might be present in the same table or in some other
table.
Example of foreign key
• Consider the following two schemas-

• Here, t_dept can take only those values which are present in dept_no
in Department table since only those departments actually exist.
Properties of Foreign Key
• Foreign key references the primary key of the table.
• Foreign key can take only those values which are present in the primary key
of the referenced relation.
• Foreign key may have a name other than that of a primary key.
• Foreign key can take the NULL value.
• There is no restriction on a foreign key to be unique.
• In fact, foreign key is not unique most of the time.
• Referenced relation may also be called as the master table or primary table.
• Referencing relation may also be called as the foreign table.
 Partial Key-
Emp_no
Dependent
name
Relation • Partial key is a key using which all the records of
the table can not be identified uniquely.
E1 Suman Mother
• However, a bunch of related tuples can be
E1 Ajay Father selected from the table using the partial key.
• Example-
E2 Vijay Father
• Consider the following schema-
E2 Ankush Son Department ( Emp_no , Dependent_name , Relation )
• Here, using partial key Emp_no, we can not
identify a tuple uniquely but we can select a
bunch of tuples from the table.
Composite Key-
• A primary key comprising of multiple attributes and not just a single
attribute is called as a composite key.
Unique Key-
Unique key is a key with the following properties-
• It is unique for all the records of the table.
• Once assigned, its value can not be changed i.e. it is non-updatable.
• It may have a NULL value.
• Example-
• The best example of unique key is Adhaar Card Numbers.
• The Adhaar Card Number is unique for all the citizens (tuples) of India (table).
• If it gets lost and another duplicate copy is issued, then the duplicate copy always
has the same number as before.
• Thus, it is non-updatable.
• Few citizens may not have got their Adhaar cards, so for them its value is NULL
Surrogate Key-
• Surrogate key is a key with the following properties-
• It is unique for all the records of the table.
• It is updatable.
• It can not be NULL i.e. it must have some value.
• Example-
• Mobile Number of students in a class where every student owns a
mobile phone.
Secondary Key-
• Secondary key is required for the indexing purpose for better and
faster searching.
Integrity Constraints
• Integrity constraints are a set of rules. It is used to maintain the
quality of information.
• Integrity constraints ensure that the data insertion, updating, and
other processes have to be performed in such a way that data
integrity is not affected.
• Thus, integrity constraint is used to guard against accidental damage
to the database.
Types of Integrity Constraint
Domain constraints
• Domain constraints can be defined as the definition of a valid set of
values for an attribute.
• The data type of domain includes string, character, integer, time, date,
currency, etc. The value of the attribute must be available in the
corresponding domain.
Entity integrity constraints
• The entity integrity constraint states that primary key value can't be null.
• This is because the primary key value is used to identify individual rows in relation
and if the primary key has a null value, then we can't identify those rows.
• A table can contain a null value other than the primary key field.
Referential Integrity Constraints
• A referential integrity
constraint is specified
between two tables.
• In the Referential
integrity constraints, if a
foreign key in Table 1
refers to the Primary Key
of Table 2, then every
value of the Foreign Key
in Table 1 must be null or
be available in Table 2.
Key constraints
• Keys are the entity set that is used to identify an entity within its
entity set uniquely.
• An entity set can have multiple keys, but out of which one key will be
the primary key. A primary key can contain a unique and null value in
the relational table.
Finding Candidate Keys
We can determine the candidate keys of a given relation using the
following steps-
Step-01:
• Determine all essential attributes of the given relation.
• Essential attributes are those attributes which are not present on RHS of any
functional dependency.
• Essential attributes are always a part of every candidate key.
• This is because they can not be determined by other attributes.
Example
• Let R(A, B, C, D, E, F) be a relation scheme with the following
functional dependencies-
A→B
C→D
D→E
• Here, the attributes which are not present on RHS of any functional
dependency are A, C and F.
• So, essential attributes are- A, C and F.
Finding Candidate Keys
Step-02:
• The remaining attributes of the relation are non-essential attributes.
• This is because they can be determined by using essential attributes.
Now, following two cases are possible-
Case-01:
• If all essential attributes together can determine all remaining non-essential attributes, then-
• The combination of essential attributes is the candidate key.
• It is the only possible candidate key.
Case-02:
• If all essential attributes together can not determine all remaining non-essential attributes, then-
•The set of essential attributes and some non-essential attributes will be the candidate key(s).
•In this case, multiple candidate keys are possible.
•To find the candidate keys, we check different combinations of essential and non-essential
attributes.
PRACTICE PROBLEMS BASED ON FINDING
CANDIDATE KEYS- 01

• Let R = (A, B, C, D, E) be a relation scheme with the following dependencies-

AB → C
C→D
B→E
Determine the total number of candidate keys.
• Essential attributes of the relation are- A and B.
• find the closure of AB : { AB }+
={A,B}
={A,B,C} ( Using AB → C )
={A,B,C,D} ( Using C → D )
={A,B,C,D,E} ( Using B → E )
• We conclude that AB can determine all the attributes of the given relation.
• Thus, AB is the only possible candidate key of the relation.
PRACTICE PROBLEMS BASED ON FINDING
CANDIDATE KEYS- 02

• Let R = (A, B, C, D, E, F) be a relation scheme with the following

dependencies-
C→F
E→A
EC → D
A→B
Find candidate keys?
solution
• Essential attributes of the relation are- C and E.
• Now, We will check if the essential attributes together can determine all remaining
non-essential attributes.
• To check, we find the closure of CE.
• { CE }+
• ={C,E}
• ={C,E,F} ( Using C → F )
• ={A,C,E,F} ( Using E → A )
• ={A,C,D,E,F} ( Using EC → D )
• ={A,B,C,D,E,F} ( Using A → B )
• We conclude that CE can determine all the attributes of the given relation.
• So, CE is the only possible candidate key of the relation.
PRACTICE PROBLEMS BASED ON FINDING
CANDIDATE KEYS- 03
• Consider the relation scheme R(A, B, C, D, E, H) and the set of
functional dependencies-
A→B
BC → D
E→C
D→A
What are the candidate keys of R?

• Candidate keys are AEH, BEH, DEH

Normalization
Functional Dependency
• If α and β are the two sets of attributes in a relational table R where-
α⊆R
β⊆R
Then, for a functional dependency to exist from α to β,
If t1[α] = t2[α],
then t1[β] = t2[β]
α Β

t1[α] t1[β]

t2[α] t2[β]

……. …….

fd : α → β
Inference Rules-
• Reflexivity-
If B is a subset of A, then A → B always holds.
• Transitivity-
If A → B and B → C, then A → C always holds.
• Augmentation-
If A → B, then AC → BC always holds.
• Decomposition-
If A → BC, then A → B and A → C always holds.
• Composition-
If A → B and C → D, then AC → BD always holds.
• Additive-
If A → B and A → C, then A → BC always holds.
Rules for Functional Dependency-
Rule-01: A functional dependency X → Y will always hold if all the values of X are
unique (different) irrespective of the values of Y.
Example-Consider the following table-
The following functional dependencies will always hold since all the values of attribute ‘A’
are unique-
•A → B
•A → BC
•A → CD
•A → BCD
•A → DE
•A → BCDE

In general, we can say following functional dependency will always hold-

NOTE: A → Any combination of attributes A, B, C, D, E
Rules for Functional Dependency-
Rule-02:
A functional dependency X → Y will always hold if all the values of Y are same irrespective of the
values of X.
Example- Consider the following table-
The following functional dependencies will always hold since all the values of attribute ‘C’ are same-
A→C A B C D E

5 4 3 2 2
AB → C
8 5 3 2 1
ABDE → C
1 9 3 3 5
DE → C
4 7 3 3 8
AE → C
In general, we can say following functional dependency will always hold true-
Any combination of attributes A, B, C, D, E → C
Combining Rule-01 and Rule-02 we
can say-
• In general, a functional dependency α → β always holds-
• If either all values of α are unique or
• if all values of β are same or both.
Rules for Functional Dependency-
Rule-03:
For a functional dependency X → Y to hold, if two tuples in the table
agree on the value of attribute X, then they must also agree on the
value of attribute Y.

Rule-04:
For a functional dependency X → Y, violation will occur only when for
two or more same values of X, the corresponding Y values are different.
Data modification anomalies
Data modification anomalies can be categorized into three types:
• Insertion Anomaly: Insertion Anomaly refers to when one cannot
insert a new tuple into a relationship due to lack of data.
• Deletion Anomaly: The delete anomaly refers to the situation where
the deletion of data results in the unintended loss of some other
important data.
• Updation Anomaly: The update anomaly is when an update of a
single data value requires multiple rows of data to be updated.
Types of Normal Forms
Normal Form Description
1NF A relation is in 1NF if it contains an atomic value.
2NF A relation will be in 2NF if it is in 1NF and all non-key attributes are
fully functional dependent on the primary key.

3NF A relation will be in 3NF if it is in 2NF and no transition

dependency exists.
BCNF A stronger definition of 3NF is known as Boyce Codd's normal
form.
4NF A relation will be in 4NF if it is in Boyce Codd's normal form and
has no multi-valued dependency.
5NF A relation is in 5NF. If it is in 4NF and does not contain any join
dependency, joining should be lossless.
 First Normal Form (1NF)
• A relation will be 1NF if it contains an atomic value.
• It states that an attribute of a table cannot hold multiple values. It must hold only single-valued attribute.
• First normal form disallows the multi-valued attribute, composite attribute, and their combinations.
• Example: Relation EMPLOYEE is not in 1NF because of multi-valued attribute EMP_PHONE.
• EMPLOYEE table: The decomposition of the EMPLOYEE table into 1NF has been shown
below:
EMP_ID EMP_NAME EMP_PHONE EMP_STATE EMP_I EMP_NAME EMP_PHONE EMP_STATE
D

14 John 7272826385, UP 14 John 7272826385 UP

9064738238
14 John 9064738238 UP

20 Harry 8574783832 Bihar 20 Harry 8574783832 Bihar

12 Sam 7390372389, Punjab 12 Sam 7390372389 Punjab
8589830302
12 Sam 8589830302 Punjab
Second Normal Form (2NF)
• In the 2NF, relational must be in 1NF.
• In the second normal form, all non-key attributes are fully functional dependent on the primary key
• Example: Let's assume, a school can store the data of teachers and the subjects they teach. In a school, a
teacher can teach more than one subject.
• TEACHER table TEACHER_ID SUBJECT TEACHER_AGE

25 Chemistry 30

25 Biology 30

47 English 35

83 Math 38

83 Computer 38

In the given table, non-prime attribute TEACHER_AGE is dependent on TEACHER_ID which

is a proper subset of a candidate key. That's why it violates the rule for 2NF.
To convert the given table into 2NF, we decompose it into two tables:
Second Normal Form (2NF) cont..
TEACHER_DETAIL table: TEACHER_ID TEACHER_AGE

25 30

47 35

83 38

TEACHER_SUBJECT table: TEACHER_ID SUBJECT

25 Chemistry

25 Biology

47 English

83 Math

83 Computer
Third Normal Form (3NF)
• A relation will be in 3NF if it is in 2NF and not contain any transitive
partial dependency.
• 3NF is used to reduce the data duplication. It is also used to achieve
the data integrity.
• If there is no transitive dependency for non-prime attributes, then the
relation must be in third normal form.
• A relation is in third normal form if it holds atleast one of the
following conditions for every non-trivial function dependency X → Y.
• X is a super key.
• Y is a prime attribute, i.e., each element of Y is part of some candidate key.
Third Normal Form (3NF) cont…
EMPLOYEE_DETAIL table: EMP_ID EMP_NAME EMP_ZIP EMP_STATE EMP_CITY

222 Harry 201010 UP Noida

333 Stephan 02228 US Boston

444 Lan 60007 US Chicago

555 Katharine 06389 UK Norwich

666 John 462007 MP Bhopal

Super key in the table above:

{EMP_ID}, {EMP_ID, EMP_NAME}, {EMP_ID, EMP_NAME, EMP_ZIP}....so on
Candidate key: {EMP_ID}
Non-prime attributes: In the given table, all attributes except EMP_ID are non-prime.
Here, EMP_STATE & EMP_CITY dependent on EMP_ZIP and EMP_ZIP dependent on EMP_ID. The non-prime
attributes (EMP_STATE, EMP_CITY) transitively dependent on super key(EMP_ID). It violates the rule of third
normal form.
That's why we need to move the EMP_CITY and EMP_STATE to the new <EMPLOYEE_ZIP> table, with EMP_ZIP as a
Primary key.
 Third Normal Form (3NF) cont…
EMPLOYEE table: EMP_ID EMP_NAME EMP_ZIP

222 Harry 201010

333 Stephan 02228

444 Lan 60007

555 Katharine 06389

666 John 462007

EMPLOYEE_ZIP table:
EMP_ZIP EMP_STATE EMP_CITY

201010 UP Noida

02228 US Boston

60007 US Chicago

06389 UK Norwich

462007 MP Bhopal
Boyce Codd normal form (BCNF)
• BCNF is the advance version of 3NF. It is stricter than 3NF.
• A table is in BCNF if every functional dependency X → Y, X is the super key of the table.
• For BCNF, the table should be in 3NF, and for every FD, LHS is super key.
• Example: Let's assume there is a company where employees work in more than one department
• EMPLOYEE table: EMP_ID EMP_COUNTRY EMP_DEPT DEPT_TYPE EMP_DEPT_NO

264 India Designing D394 283

264 India Testing D394 300

364 UK Stores D283 232

364 UK Developing D283 549

In the above table Functional dependencies are as follows:

EMP_ID → EMP_COUNTRY
EMP_DEPT → {DEPT_TYPE, EMP_DEPT_NO}
Candidate key: {EMP-ID, EMP-DEPT}
The table is not in BCNF because neither EMP_DEPT nor EMP_ID alone are keys.
To convert the given table into BCNF, we decompose it into three tables:
 Boyce Codd normal form (BCNF)
EMP_COUNTRY table: EMP_DEPT table:
EMP_ID EMP_COUNTRY EMP_DEPT DEPT_TYPE EMP_DEPT_NO

264 India Designing D394 283

264 India Testing D394 300

Stores D283 232

EMP_DEPT_MAPPING table: Developing D283 549

EMP_ID EMP_DEPT Functional dependencies:

EMP_ID → EMP_COUNTRY
D394 283
EMP_DEPT → {DEPT_TYPE, EMP_DEPT_NO}
D394 300 Candidate keys:
D283 232 For the first table: EMP_ID
For the second table: EMP_DEPT
D283 549
For the third table: {EMP_ID, EMP_DEPT}
Now, this is in BCNF because left side part of both the functional dependencies is a key.
Fourth normal form (4NF)
• A relation will be in 4NF if it is in Boyce Codd normal form and has no multi-valued dependency.
• For a dependency A → B, if for a single value of A, multiple values of B exists, then the relation
will be a multi-valued dependency. STU_ID COURSE HOBBY
• Example: STUDENT 21 Computer Dancing

21 Math Singing

34 Chemistry Dancing

74 Biology Cricket

59 Physics Hockey

• The given STUDENT table is in 3NF, but the COURSE and HOBBY are two independent entity.
Hence, there is no relationship between COURSE and HOBBY.
• In the STUDENT relation, a student with STU_ID, 21 contains two
courses, Computer and Math and two hobbies, Dancing and Singing. So there is a Multi-valued
dependency on STU_ID, which leads to unnecessary repetition of data.
• So to make the above table into 4NF, we can decompose it into two tables:
Fourth normal form (4NF) Cont…
STUDENT_COURSE STU_ID COURSE

21 Computer

21 Math

34 Chemistry

74 Biology

59 Physics

STUDENT_HOBBY STU_ID HOBBY

21 Dancing

21 Singing

34 Dancing

74 Cricket

59 Hockey
Fifth normal form (5NF)
• A relation is in 5NF if it is in 4NF and not contains any join dependency and joining should be lossless.
• 5NF is satisfied when all the tables are broken into as many tables as possible in order to avoid redundancy.
• 5NF is also known as Project-join normal form (PJ/NF).
• Example
SUBJECT LECTURER SEMESTER

Computer Anshika Semester 1

Computer John Semester 1

Math John Semester 1

Math Akash Semester 2

Chemistry Praveen Semester 1

• In the above table, John takes both Computer and Math class for Semester 1 but he doesn't take Math class for
Semester 2. In this case, combination of all these fields required to identify a valid data.
• Suppose we add a new Semester as Semester 3 but do not know about the subject and who will be taking that
subject so we leave Lecturer and Subject as NULL. But all three columns together acts as a primary key, so we
can't leave other two columns blank.
• So to make the above table into 5NF, we can decompose it into three relations P1, P2 & P3:
P1 SEMESTER SUBJECT P2 SUBJECT LECTURER

Semester 1 Computer Computer Anshika

Semester 1 Math Computer John

Semester 1 Chemistry Math John

Semester 2 Math Math Akash

Chemistry Praveen

P3 SEMSTER LECTURER

Semester 1 Anshika

Semester 1 John

Semester 1 John

Semester 2 Akash

Semester 1 Praveen
Relational Algebra
• Every database management system must define a query language to allow
users to access the data stored in the database.
• Relational Algebra is a procedural query language used to query the
database tables to access data in different ways.
• In relational algebra, input is a relation(table from which data has to be
accessed) and output is also a relation(a temporary table holding the data
asked for by the user).
• Relational Algebra works on the whole table at once, so we do not have to
use loops etc to iterate over all the rows(tuples) of data one by one.
• All we have to do is specify the table name from which we need the data,
and in a single line of command, relational algebra will traverse the entire
given table to fetch data.
Types of operations in relational
algebra
• We have divided these operations in two categories:
• Basic/Fundamental Operations:
1. Select (σ)
2. Project (∏)
3. Union (∪)
4. Set Difference (-)
5. Cartesian product (X)
6. Rename (ρ)

• Derived Operations:
1. Natural Join (⋈)
2. Left, Right, Full outer join (⟕, ⟖, ⟗)
3. Intersection (∩)
4. Division (÷)
Select Operator (σ)
• It selects tuples that satisfy the given predicate from a relation.
• Notation − σp(r)
• Where σ stands for selection predicate and r stands for relation. p is
prepositional logic formula which may use connectors like and, or, and not.
These terms may use relational operators like − =, ≠, ≥, < , >, ≤.
• For example −
• σsubject = "database"(Books) Output − Selects tuples from books where subject is
'database'.
• σsubject = "database" and price = "450"(Books) Output − Selects tuples from books where
subject is 'database' and 'price' is 450.
• σsubject = "database" and price = "450" or year > "2010"(Books) Output − Selects tuples from books
where subject is 'database' and 'price' is 450 or those books published after
2010.
 BRANCH_NAME LOAN_NO AMOUNT
For example: LOAN Relation
Downtown L-17 1000

Redwood L-23 2000

Perryride L-15 1500

Downtown L-14 1500

Mianus L-13 500

Roundhill L-11 900

Perryride L-16 1300

σ BRANCH_NAME="perryride" (LOAN)
Output:
BRANCH_NAME LOAN_NO AMOUNT

Perryride L-15 1500

Perryride L-16 1300
Project Operator (∏)
• It projects column(s) that satisfy a given predicate.
• Notation − ∏A1, A2, An (r)
• Where A1, A2 , An are attribute names of relation r.
• Duplicate rows are automatically eliminated, as relation is a set.
• For example −
• ∏subject, author (Books) Selects and projects columns named as subject
and author from the relation Books.
Example: CUSTOMER RELATION
NAME STREET CITY

Jones Main Harrison

Smith North Rye

Hays Main Harrison

Curry North Rye

Johnson Alma Brooklyn

Brooks Senator Brooklyn

∏ NAME, CITY (CUSTOMER)

Output:
NAME CITY

Jones Harrison

Smith Rye

Hays Harrison

Curry Rye

Johnson Brooklyn

Brooks Brooklyn
Union Operation (∪)
• Union Operation (∪)
• It performs binary union between two given relations and is defined as −
• r ∪ s = { t | t ∈ r or t ∈ s} Notation − r U s
• Where r and s are either database relations or relation result set (temporary
relation).
• For a union operation to be valid, the following conditions must hold −
• r, and s must have the same number of attributes.
• Attribute domains must be compatible.
• Duplicate tuples are automatically eliminated.
• ∏ author (Books) ∪ ∏ author (Articles)
• Output − Projects the names of the authors who have either written a book or an
article or both.
Set Intersection:
• Suppose there are two tuples R and S. The set intersection operation
contains all tuples that are in both R & S.
• It is denoted by intersection ∩.
• Notation: R ∩ S
• Example: ∏ CUSTOMER_NAME (BORROW) ∩ ∏ CUSTOMER_NAME (DEPOSITOR)
Example:
DEPOSITOR RELATION ∏ CUSTOMER_NAME (BORROW) ∪ ∏ CUSTOMER_NAME (DEPOSITOR
CUSTOMER_NAME ACCOUNT_NO
) CUSTOMER_NAME
Output:
Johnson A-101 Johnson

Smith A-121 Smith

Mayes A-321 Hayes

Turner A-176 Turner

Jones
Johnson A-273
Lindsay
Jones A-472
Jackson
Lindsay A-284
Curry
BORROW RELATION
Williams
CUSTOMER_NAME LOAN_NO
Mayes
Jones L-17

Smith L-23 ∏ CUSTOMER_NAME (BORROW) ∩ ∏ CUSTOMER_NAME (DEPOSITOR)

Output:
Hayes L-15

Jackson L-14 CUSTOMER_NAME

Curry L-93
Smith
Smith L-11
Jones
Williams L-17
Set Difference (−)
• The result of set difference operation is tuples, which are present in one relation
but are not in the second relation.
• Notation − r − s
• Finds all the tuples that are present in r but not in s.
• ∏ author (Books) − ∏ author (Articles)
• Output − Provides the name of authors who have written books but not articles.
∏ CUSTOMER_NAME (BORROW) - ∏ CUSTOMER_NAME (DEPOSITOR)
Output CUSTOMER_NAME

Jackson
Hayes
Willians
Curry
Cartesain Product (Χ)
• Combines information of two different relations into one.
• Notation − r Χ s
• Where r and s are relations and their output will be defined as −
• r Χ s = { q t | q ∈ r and t ∈ s}
• σauthor = ‘abc'(Books Χ Articles) Output − Yields a relation, which shows
all the books and articles written by abc.
EMPLOYEE EMPLOYEE X DEPARTMENT
Output:
EMP_ID EMP_NAME EMP_DEPT
EMP_ID EMP_NAME EMP_DEPT DEPT_NO DEPT_NAME
1 Smith A
1 Smith A A Marketing
2 Harry C
1 Smith A B Sales
3 John B
1 Smith A C Legal
2 Harry C A Marketing
DEPARTMENT
2 Harry C B Sales
DEPT_NO DEPT_NAME
2 Harry C C Legal
A Marketing
3 John B A Marketing
B Sales
3 John B B Sales
C Legal
3 John B C Legal
Rename Operation (ρ)
• The results of relational algebra are also relations but without any
name. The rename operation allows us to rename the output
relation.
• 'rename' operation is denoted with small Greek letter rho ρ.
• Notation − ρ x (E)
• Where the result of expression E is saved with name of x.
THANK YOU