The Relational Algebra

Introduction
• Data model must include a set of operations to manipulate the
database, define the database’s structure and constraints. These
operations for the formal relational model is the relational algebra.
• These operations enable a user to specify basic retrieval requests as
relational algebra expressions.
• Sequence of relational algebra operations forms a relational algebra
expression.
• Unary operations - operate on single relations.
• Binary operations - operate on two tables by combining related
tuples based on join conditions.
8.1 Unary Relational Operations: SELECT
and PROJECT
• 8.1.1 The SELECT Operation
• The SELECT operation is used to choose a subset of the tuples from a relation that satisfies
a selection condition.
• We can consider the SELECT operation to be a filter that keeps only those tuples that satisfy
a qualifying condition.
• The SELECT operation is a horizontal partition of the relation into two sets of tuples
-those tuples that satisfy the condition and are selected
-those tuples that do not satisfy the condition and are filtered out.
• In SQL, the SELECT condition is typically specified in the WHERE clause of a query.
• For example, to select the EMPLOYEE tuples whose department is 4

• or those whose salary is greater than $30,000

• In general, the SELECT operation is denoted by

• σ (sigma) denote the SELECT operator

• selection condition is a Boolean expression (condition) specified on the
attributes of relation R.
• R is name of a database relation.
• The relation resulting from the SELECT operation has the same attributes as R.
• The Boolean expression specified in is made up of a number of clauses of the
form
• For example, to select the tuples for all employees who either work in
department 4 and make over $25,000 per year, or work in
department 5 and make over $30,000
• <selecetion condition> is applied independently to each individual
tuple t in R.
• All the selected tuples appear in the result of the SELECT operation.
• Boolean conditions AND, OR, and NOT have their normal
interpretation as follows
■ (cond1 AND cond2) is TRUE if both (cond1) and (cond2) are TRUE; otherwise,
it is FALSE.
■ (cond1 OR cond2) is TRUE if either (cond1) or (cond2) or both are TRUE;
otherwise, it is FALSE.
■ (NOT cond) is TRUE if cond is FALSE; otherwise, it is FALSE.
• The SELECT operator is unary; it is applied to a single relation.
• The degree of the relation resulting from a SELECT operation is same
as the degree of R.
• The number of tuples in the resulting relation is always less than or
equal to the number of tuples in R.
• SELECT operation is commutative

• We can combine a cascade of SELECT operations into a single SELECT

operation with a conjunctive (AND) condition.
• In SQL, the SELECT condition is typically specified in the WHERE clause
of a query

corresponds to
8.1.2 The PROJECT Operation
• PROJECT operation, selects certain columns from the table and discards the
other columns.
• In SQL, the PROJECT attribute list is specified in the SELECT clause of a query.
• Result of the PROJECT operation can be visualized as a vertical partition of
the relation into two relations
- one has the needed columns (attributes) and contains the result of the
operation
- the other contains the discarded columns.
• For example, to list each employee’s first and last name and salary, we can
use the PROJECT operation as follows
• The general form of the PROJECT operation is

• π (pi) represents the PROJECT operation, and is the desired sublist of

attributes from the attributes of relation R.
• R is database relation.
• The result of the PROJECT operation has only the attributes specified in
the same order as they appear in the list.
• Hence, its degree is equal to the number of attributes in <attribute
list>.
• The PROJECT operation removes any duplicate tuples, so the result of
the PROJECT operation is a set of distinct tuples. This is known as
duplicate elimination.
• Commutativity does not hold on PROJECT.
• In SQL, the PROJECT attribute list is specified in the SELECT clause of a
query. For example, the following operation:

correspond to the following SQL query

8.1.3 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, apply a SELECT and a PROJECT
operation. We can write a single relational algebra expression, also
known as an in-line expression
• Alternatively, we can explicitly show the sequence of operations,
giving a name to each intermediate relation, and using the
assignment operation, denoted by ← (left arrow), as follows

• To rename the attributes in a relation, we simply list the new

attribute names in parentheses, as in the following example
• In SQL, a single query typically represents a complex relational
algebra expression. Renaming in SQL is accomplished by aliasing using
AS

• RENAME operation can rename either the relation name or the

attribute names, or both. The general RENAME operation when applied
to a relation R of degree n is denoted by any of the following three
forms:
8.2 Relational Algebra Operations from Set
Theory
• 8.2.1 The UNION, INTERSECTION, and MINUS Operations
• 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, we can use the UNION
operation as follows:

• RESULT1 - Ssn of all employees who work in department 5

• RESULT2 - Ssn of all employees who directly supervise an employee who works in
department 5.
• UNION operation produces the tuples that are in either RESULT1 or RESULT2 or both while
eliminating any duplicates. Thus, the Ssn value ‘333445555’ appears only once in the result.
• UNION, INTERSECTION, and SET DIFFERENCE ( MINUS or EXCEPT) are
binary operations.
• Each is applied to two sets (of tuples).
• Union compatibility or type compatibility - The two relations on
which any of these three operations are applied must have the same
type of tuples.
Two relations R(A1, A2, … , An) and S(B1, B2, … , Bn) are said to be
union compatible (or type compatible) if they have the same degree n
and if dom(Ai) = dom(Bi) for 1 ≤ i ≤ n
• We can define the three operations UNION, INTERSECTION, and SET
DIFFERENCE on two union-compatible relations R and S as follows:
■ UNION: The result of this operation, denoted by 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.
■ INTERSECTION: The result of this operation, denoted by R ∩ S, is a
relation that includes all tuples that are in both R and S.
■ SET DIFFERENCE (MINUS): The result of this operation, denoted by R
– S, is a relation that includes all tuples that are in R but not in S.
• Both UNION and INTERSECTION are commutative operations
R ∪ S = S ∪ R and R ∩ S = S ∩ R
• Also associative operations
R ∪ (S ∪ T ) = (R ∪ S) ∪ T and (R ∩ S) ∩ T = R ∩ (S ∩ T)
• The MINUS operation is not commutative
R−S≠S−R
8.2.2 The CARTESIAN PRODUCT (CROSS
PRODUCT) Operation
• CARTESIAN PRODUCT operation(CROSS PRODUCT or CROSS JOIN) is denoted
by ×.
• It is a binary set operation, but the relations on which it is applied do not
have to be union compatible.
• This set operation produces a new element by combining every member
(tuple) from one relation (set) with every member (tuple) from the other
relation (set).
• The result of R(A1, A2, … , An) × S(B1, B2, … , Bm) is a relation Q with degree
n + m attributes Q(A1, A2, … , An, B1, B2, … , Bm), in that order.
• The resulting relation Q has one tuple for each combination of tuples—one
from R and one from S.
• The n-ary CARTESIAN PRODUCT operation new tuples by
concatenating all possible combinations of tuples from n underlying
relations.
• The CARTESIAN PRODUCT creates tuples with the combined attributes
of two relations. We can SELECT related tuples only from the two
relations by specifying an appropriate selection condition after the
Cartesian product
8.3 Binary Relational Operations: JOIN and
DIVISION
• 8.3.1 The JOIN Operation
• The JOIN operation, denoted by
• It combines related tuples from two relations into single “longer” tuples.
• The general form of a JOIN operation on two relations5 R(A1, A2, … , An) and S(B1, B2, … , Bm) is

• Suppose 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. We do this by using the JOIN operation and
then projecting the result over the necessary attributes
• Mgr_ssn is a foreign key of the DEPARTMENT relation that references
Ssn, the primary key of the EMPLOYEE relation. This referential integrity
constraint plays a role in having matching tuples in the referenced
relation EMPLOYEE.
• The JOIN operation is CARTESIAN PRODUCT operation followed by a
SELECT operation.
• Consider the previous cartesian product example

• These two operations can be replaced with a single JOIN operation as

follows:
• The general form of a JOIN operation on two relations R(A1, A2, … , An)
and S(B1, B2, … , Bm) is
• The result of the JOIN is a relation Q with n + m attributes Q(A1, A2, … ,
An, B1, B2, … , Bm) in that order; Q has one tuple for each combination
of tuples—one from R and one from S—whenever the combination
satisfies the join condition.
• Main difference between CARTESIAN PRODUCT and JOIN.
-In JOIN, only combinations of tuples satisfying the join condition appear in
the result.
-In the CARTESIAN PRODUCT all combinations of tuples are included in the
result.
• The join condition is specified on attributes from the two relations R and S and is
evaluated for each combination of tuples. Each tuple combination for which the
join condition evaluates to TRUE is included in the resulting relation Q as a single
combined tuple.
• Tuples whose join attributes are NULL or for which the join condition is FALSE do
not appear in the result.
• A general join condition is of the form

• A JOIN operation with such a general join condition is called a THETA JOIN.
where each is of the form Ai θ Bj , Ai is an attribute of R, Bj is an attribute of S, Ai and
Bj have the same domain, and θ (theta) is one of the comparison operators {=,> ,<, ≥,
≠}.
8.3.2 Variations of JOIN: The EQUIJOIN and
NATURAL JOIN
• JOIN, where the only comparison operator used is =, is called an EQUIJOIN.
• In the result of an EQUIJOIN we always have one or more pairs of attributes that
have identical values in every tuple for example the equality join condition
specified on these two attributes requires the values to be identical in every
tuple in the result.
• NATURAL JOIN—denoted by *
• Created to get rid of the extra unnecessary attribute in an EQUIJOIN
condition.
• NATURAL JOIN requires that the two join attributes have the same name
in both relations. If this is not the case, renaming operation is applied
first.
• Suppose we want to combine each PROJECT tuple with the
DEPARTMENT tuple that controls the project, 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 same query can be done in two steps by creating an intermediate
table DEPT as follows:
• The attribute Dnum is called the join attribute for the NATURAL JOIN
operation, because it is the only attribute with the same name in
both relations.
• In the PROJ_DEPT relation, each tuple combines a PROJECT tuple with
the DEPARTMENT tuple for the department that controls the project,
but only one join attribute value is kept.
• If the attributes on which the natural join is specified already have the
same names in both relations, renaming is unnecessary.
• The join condition for NATURAL JOIN is constructed by equating each pair of
join attributes that have the same name in the two relations and combining
these conditions with AND. There can be a list of join attributes from each
relation, and each corresponding pair must have the same name.
• The NATURAL JOIN or EQUIJOIN operation can also be specified among
multiple tables, leading to an n-way join. For example, consider the following
three-way join:

• This combines each project tuple with its controlling department tuple into a
single tuple, and then combines that tuple with an employee tuple that is the
department manager. The net result is a consolidated relation in which each
tuple contains this project-department-manager combined information .
 8.3.3 A Complete Set of Relational Algebra
Operations
• Set of relational algebra operations {σ, π, ∪, ρ, –, ×} is a complete set.
• Relational algebra operations can be expressed as a sequence of operations
from this set.
• For example, the INTERSECTION operation can be expressed by using UNION
and MINUS as follows:
R ∩ S ≡ (R ∪ S) – ((R – S) ∪ (S – R))
• JOIN operation can be specified as a CARTESIAN PRODUCT followed by a
SELECT operation

• a NATURAL JOIN can be specified as a CARTESIAN PRODUCT preceded by

RENAME and followed by SELECT and PROJECT operations.
 8.3.4 The DIVISION Operation
• The DIVISION operation is denoted by ÷
• An example is Retrieve the names of employees who work on all the projects that ‘John Smith’
works on
• First, retrieve the list of project numbers that ‘John Smith’ works on in the intermediate relation
SMITH_PNOS

• Next, create a relation that includes a tuple <Pno,Essn> whenever the employee whose Ssn is Essn
works on the project whose number is Pno in the intermediate relation SSN_PNOS:

• Finally, apply the DIVISION operation to the two relations, which gives the desired employees’
Social Security numbers:
RESULT
• This means that, for a tuple t to appear in the result T of the
DIVISION, the values in t must appear in R in combination with every
tuple in S.
• In the DIVISION operation, the tuples in the denominator relation S
restrict the numerator relation R by selecting those tuples in the
result that match all values present in the denominator.
8.3.5 Notation for Query Trees
• A notation used in RDBMS to represent queries internally.
• It is known as a query tree or query evaluation tree or query execution tree.
• It includes the relational algebra operations being executed and is used as a
possible data structure for the internal representation of the query in an
RDBMS.
• A query tree is a tree data structure that corresponds to a relational algebra
expression. It represents the input relations of the query as leaf nodes of the
tree, and represents the relational algebra operations as internal nodes. An
execution of the query tree consists of executing an internal node operation
whenever its operands (represented by its child nodes) are available, and then
replacing that internal node by the relation that results from executing the
operation. The execution terminates when the root node is executed and
produces the result relation for the query.
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.
8.4 Additional Relational Operations
• Some common database requests can not be performed with the original relational
algebra operations.
• Additional operations to express these requests are required. These operations
enhance the expressive power of the original relational algebra.
8.4.1 Generalized Projection
• The generalized projection operation extends the projection operation by allowing
functions of attributes to be included in the projection list. The generalized form
can be expressed as:

• F1, F2, … , Fn are functions over the attributes in relation R and may involve
arithmetic operations and constant values.
• This operation is helpful when developing reports where computed values have to
be produced in the columns of a query result.
8.4.2 Aggregate Functions and Grouping
• Another type of request that cannot be expressed in the basic relational algebra is to
specify mathematical aggregate functions on collections of values from the database.
• Example, retrieving the average or total salary of all employees or the total number of
employee tuples.
• Common functions applied to collections of numeric values include SUM, AVERAGE,
MAXIMUM, and MINIMUM. The COUNT function is used for counting tuples or
values.
• Another common type of request involves grouping the tuples in a relation by the
value of some of their attributes and then applying an aggregate function
independently to each group.
• Example, group EMPLOYEE tuples by Dno, so that each group includes the tuples for
employees working in the same department. We can then list each Dno value along
with, the average salary of employees within the department, or the number of
employees who work in the department.
• AGGREGATE FUNCTION operation

• Where <grouping attribute> is a list of attributes of the relation

specified in R, and <function list> is a list of (<function><attribute> )
pairs. In each such pair, <function> is one of the allowed functions—
such as SUM, AVERAGE, MAXIMUM, MINIMUM, COUNT—and
<attribute> is an attribute of the relation specified by R. The resulting
relation has the grouping attributes plus one attribute for each element
in the function list.
• For example, to retrieve each department number, the number of
employees in the department, and their average salary, while renaming
the resulting attributes
8.4.3 Recursive Closure Operations
• Another type of operation that, in general, cannot be specified in the
basic original relational algebra is recursive closure. This operation is
applied to a recursive relationship between tuples of the same type,
such as the relationship between an employee and a supervisor.
• This relationship is described by the foreign key Super_ssn of the
EMPLOYEE relation and it relates each employee tuple (in the role of
supervisee) to another employee tuple (in the role of supervisor).
• An example of a recursive operation is to retrieve all supervisees of an
employee e at all levels—that is, all employees e′ directly supervised
by e, all employees e″ directly supervised by each employee e′, all
employees e″′ directly supervised by each employee e″, and so on.
• For example, to specify the Ssns of all employees e′ directly supervised—
at level one—by the employee e whose name is ‘James Borg’ , we can
apply the following operation:
• To retrieve all employees supervised by Borg at level 2—that is, all
employees e″ supervised by some employee e′ who is directly supervised
by Borg—we can apply another JOIN to the result of the first query, as
follows:
• To get both sets of employees supervised at levels 1 and 2 by ‘James Borg’,
we can apply the UNION operation to the two results, as follows:
 8.4.4 OUTER JOIN Operations
• It is extension to the JOIN operation and is necessary to specify certain
types of queries.
• The JOIN operations match tuples that satisfy the join condition.
• Inner join
- For 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 (or related) 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, were developed for 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, regardless of whether
or not they have matching tuples in the other relation.
• This satisfies the need of queries in which tuples from two tables are to
be combined by matching corresponding rows, but without losing any
tuples for lack of matching values.
• For example, suppose that we want a list of all employee names as well
as the name of the departments they manage if they happen to manage
a department; if they do not manage one, we can indicate it with a
NULL value. We can apply an operation LEFT OUTER JOIN, denoted by ,
to retrieve the result as follows:
• The LEFT OUTER JOIN operation keeps every tuple in the first, or left,
relation R in R S; if no matching tuple is found in S, then the attributes
of S in the join result are filled or padded with NULL values.
• RIGHT OUTER JOIN, denoted by , keeps every tuple in the second, or
right, relation S in the result of R S.
• A third operation, FULL OUTER JOIN, denoted by , keeps all tuples in
both the left and the right relations when no matching tuples are
found, padding them with NULL values as needed.
8.4.5 The OUTER UNION Operation
• The OUTER UNION operation was developed to take the union of tuples from
two relations that have some common attributes, but are not union (type)
compatible.
• This operation will take the UNION of tuples in two relations R(X, Y) and S(X, Z)
that are partially compatible, meaning that only some of their attributes, say
X, are union compatible.
• The attributes that are union compatible are represented only once in the
result, and those attributes that are not union compatible from either relation
are also kept in the result relation T(X, Y, Z). It is therefore the same as a FULL
OUTER JOIN on the common attributes.
• Two tuples t1 in R and t2 in S are said to match if t1[X] = t2[X]. These will be
combined (unioned) into a single tuple in t. Tuples in either relation that have
no matching tuple in the other relation are padded with NULL values.
• OUTER UNION can be applied to two relations whose schemas are
STUDENT(Name, Ssn, Department, Advisor) and
INSTRUCTOR(Name, Ssn, Department, Rank)
• Tuples from the two relations are matched based on having the same combination
of values of the shared attributes—
Name, Ssn, Department
• The resulting relation, STUDENT_OR_INSTRUCTOR, will have the following attributes:
STUDENT_OR_INSTRUCTOR(Name, Ssn, Department, Advisor, Rank)
• All the tuples from both relations are included in the result, but tuples with the
same (Name, Ssn, Department) combination will appear only once in the result.
Tuples appearing only in STUDENT will have a NULL for the Rank attribute, whereas
tuples appearing only in INSTRUCTOR will have a NULL for the Advisor attribute. A
tuple that exists in both relations, which represent a student who is also an
instructor, will have values for all its attributes.
 8.5 Examples of Queries in Relational Algebra
• Query 1. Retrieve the name and address of all employees who work for
the ‘Research’ department.

• As a single in-line expression, this query becomes:

• Query 6. Retrieve the names of employees who have no dependents

9.1 Relational Database Design Using ER-to-Relational
Mapping 9.1.1 ER-to-Relational Mapping Algorithm
Steps of algorithm for ER-to-relational mapping
Step 1: Mapping of Regular Entity Types.
• For each regular (strong) entity type E in the ER schema, create a
relation R that includes all the simple attributes of E.
• Include only the simple component attributes of a composite
attribute. Choose one of the key attributes of E as the primary key
for R.
• If the chosen key of E is a composite, then the set of simple
attributes that form it will together form the primary key of R.
• If multiple keys were identified for E during the conceptual design,
the information describing the attributes that form each additional
key is kept in order to specify additional (unique) keys of relation R.
• In our example, we create the relations EMPLOYEE, DEPARTMENT, and
PROJECT to correspond to the regular entity types EMPLOYEE, DEPARTMENT,
and PROJECT.
• The foreign key and relationship attributes will be added during subsequent
steps.
• These include the attributes Super_ssn and Dno of EMPLOYEE, Mgr_ssn and
Mgr_start_date of DEPARTMENT, and Dnum of PROJECT.
• Ssn, Dnumber, and Pnumber are primary keys for the relations EMPLOYEE,
DEPARTMENT, and PROJECT, respectively.
• Dname of DEPARTMENT and Pname of PROJECT are unique keys is kept for
possible use later in the design.
• The relations that are created from the mapping of entity types are sometimes
called entity relations because each tuple represents an entity instance.
 Step 2: Mapping of Weak Entity Types.
• For each weak entity type, create a relation R and include all simple
attributes of the entity type as attributes of R
• Include primary key attribute of owner as foreign key attributes of R.
• We create the relation DEPENDENT in this step to correspond to the
weak entity type DEPENDENT.
• We include the primary key Ssn of the EMPLOYEE relation—which
corresponds to the owner entity type— as a foreign key attribute of
DEPENDENT; we rename it Essn.
• The primary key of the DEPENDENT relation is the combination {Essn,
Dependent_name}, because Dependent_name is the partial key of
DEPENDENT.
Step 3: Mapping of Binary 1:1 Relationship Types

• For each binary 1:1 relationship type R in the ER schema, identify the
relations S and T that correspond to the entity types participating in R
• There are three possible approaches:
- foreign key approach
- merged relationship approach
- cross reference or relationship relation approach
1. Foreign key approach:
• Choose one of the relations S, and include as a foreign key in S the primary key
of T.
• It is better to choose an entity type with total participation in R in the role of S.
• Include all the simple attributes of the 1:1 relationship type R as attributes of S.
• In our example, we map the 1:1 relationship type MANAGES by choosing the
participating entity type DEPARTMENT to serve in the role of S because its
participation in the MANAGES relationship type is total (every department has
a manager).
• We include the primary key of the EMPLOYEE relation as foreign key in the
DEPARTMENT relation and rename it to Mgr_ssn.
• We also include the simple attribute Start_date of the MANAGES relationship
type in the DEPARTMENT relation and rename it Mgr_start_date.
2. Merged relation approach:
• An alternative mapping of a 1:1 relationship type is to merge the two entity types
and the relationship into a single relation.
• This is possible when both participations are total, as this would indicate that the
two tables will have the exact same number of tuples at all times.
3. Cross-reference or relationship relation approach:
• Set up a third relation R for the purpose of cross-referencing the
primary keys of the two relations S and T representing the entity types.
• It is required for binary M:N relationships.
• The relation R is called a relationship relation, because each tuple in R
represents a relationship instance that relates one tuple from S with
one tuple from T.
• The relation R will include the primary key attributes of S and T as
foreign keys.
Step 4: Mapping of Binary 1:N Relationship Types.
• Two possible approaches:
(1) the foreign key approach
(2) the cross-reference or relationship relation approach.
1. The foreign key approach
• For each regular binary 1:N relationship type R, identify the relation S that represents the
participating entity type at the N-side of the relationship type.
• Include as foreign key in S the primary key of the relation T that represents the other
entity type participating in R.
• Because each entity instance on the N-side is related to at most one entity instance on the
1-side of the relationship type.
• Include any simple attributes of the 1:N relationship type as attributes of S.
• Example, we map the 1:N relationship types WORKS_FOR, CONTROLS, and SUPERVISION.
• For WORKS_FOR we include the primary key Dnumber of the DEPARTMENT relation as
foreign key in the EMPLOYEE relation and call it Dno.
• For SUPERVISION we include the primary key of the EMPLOYEE relation as foreign key in
the EMPLOYEE relation itself because the relationship is recursive—and call it Super_ssn.
• The CONTROLS relationship is mapped to the foreign key attribute Dnum of PROJECT,
which references the primary key Dnumber of the DEPARTMENT relation.
The relationship relation approach:
• We create a separate relation R whose attributes are the primary keys
of S and T.
• The relation R is called a relationship relation, because each tuple in R
represents a relationship instance that relates one tuple from S with
one tuple from T.
Step 5: Mapping of Binary M:N Relationship Types.
• For each binary M:N relationship type R, create a new relation S to
represent R.
• Include as foreign key attributes in S the primary keys of the relations
that represent the participating entity types; their combination will
form the primary key of S.
• Include any simple attributes of the M:N relationship type as attributes
of S.
• We cannot represent an M:N relationship type by a single foreign key
attribute in one of the participating relations because of the M:N
cardinality ratio; we must create a separate relationship relation S.
• We map the M:N relationship type WORKS_ON by creating the relation
WORKS_ON. We include the primary keys of the PROJECT and EMPLOYEE relations
as foreign keys in WORKS_ON and rename them Pno and Essn, respectively .
• We also include an attribute Hours in WORKS_ON to represent the Hours attribute
of the relationship type. The primary key of the WORKS_ON relation is the
combination of the foreign key attributes {Essn, Pno}.
• The propagate (CASCADE) option for the referential triggered action should be
specified on the foreign keys in the relation corresponding to the relationship R,
since each relationship instance has an existence dependency on each of the
entities it relates. This can be used for both ON UPDATE and ON DELETE.
Step 6: Mapping of Multivalued Attributes.
• For each multivalued attribute A,
• create a new relation R.
• The primary key of R is the combination of A and K.
• If the multivalued attribute is composite, we include its simple components.
• Example, we create a relation DEPT_LOCATIONS.
• The attribute Dlocation represents the multivalued attribute LOCATIONS of
DEPARTMENT, whereas Dnumber—as foreign key—represents the primary
key of the DEPARTMENT relation.
• The primary key of DEPT_LOCATIONS is the combination of {Dnumber,
Dlocation}.
• A separate tuple will exist in DEPT_LOCATIONS for each location that a
department has
Step 7: Mapping of N-ary Relationship Types
• For each n-ary relationship type R.
- Create a new relation S to represent R.
- Include primary keys of participating entity types as foreign keys.
- Include any simple attributes as attributes.
- The primary key of S is usually a combination of all the foreign keys that
reference the relations representing the participating entity types.
- Consider the ternary relationship type SUPPLY which relates a SUPPLIER
s, PART p, and PROJECT j whenever s is currently supplying p to j; this
can be mapped to the relation SUPPLY whose primary key is the
combination of the three foreign keys {Sname, Part_no, Proj_name}.