Unit 3

TRIGGERS, Functional Dependency and Decomposition

PL/SQL - Triggers
Triggers are stored programs, which are automatically executed or fired when some
events occur. Triggers are, in fact, written to be executed in response to any of the
following events −

 A database manipulation (DML) statement (DELETE, INSERT, or UPDATE)

 A database definition (DDL) statement (CREATE, ALTER, or DROP).
 A database operation (SERVERERROR, LOGON, LOGOFF, STARTUP, or
SHUTDOWN).

Triggers can be defined on the table, view, schema, or database with which the event is
associated.

Benefits of Triggers

Triggers can be written for the following purposes −

 Generating some derived column values automatically

 Enforcing referential integrity
 Event logging and storing information on table access
 Auditing
 Synchronous replication of tables
 Imposing security authorizations
 Preventing invalid transactions

Creating Triggers
The syntax for creating a trigger is −

CREATE [OR REPLACE ] TRIGGER trigger_name {BEFORE | AFTER | INSTEAD OF }

{INSERT [OR] | UPDATE [OR] | DELETE} [OF col_name]
ON table_name [REFERENCING OLD AS o NEW AS n] [FOR EACH ROW]
WHEN (condition)
DECLARE
Declaration-statements BEGIN
Executable-statements
EXCEPTION
Exception-handling-statements END;

1
Where,

 CREATE [OR REPLACE] TRIGGER trigger_name − Creates or replaces an existing

trigger with the trigger_name.

 {BEFORE | AFTER | INSTEAD OF} − This specifies when the trigger will be executed.
The INSTEAD OF clause is used for creating trigger on a view.

 {INSERT [OR] | UPDATE [OR] | DELETE} − This specifies the DML operation.

 [OF col_name] − This specifies the column name that will be updated.

 [ON table_name] − This specifies the name of the table associated with the trigger.

 [REFERENCING OLD AS o NEW AS n] − This allows you to refer new and old values
for various DML statements, such as INSERT, UPDATE, and DELETE.

 [FOR EACH ROW] − This specifies a row-level trigger, i.e., the trigger will be executed
for each row being affected. Otherwise the trigger will execute just once when the SQL
statement is executed, which is called a table level trigger.

 WHEN (condition) − This provides a condition for rows for which the trigger would fire.
This clause is valid only for row-level triggers.

Example

To start with, we will be using the CUSTOMERS table we had created and used in the
previous chapters −

Select * from customers;

+----+----------+-----+-----------+----------+
| ID | NAME | AGE | ADDRESS | SALARY |
+----+----------+-----+-----------+----------+
| 1 | Ramesh | 32 | Ahmedabad | 2000.00 |
| 2 | Khilan | 25 | Delhi | 1500.00 |
| 3 | kaushik | 23 | Kota | 2000.00 |
| 4 | Chaitali | 25 | Mumbai | 6500.00 |
| 5 | Hardik | 27 | Bhopal | 8500.00 |
| 6 | Komal | 22 | MP | 4500.00 |
+----+----------+-----+-----------+----------+

The following program creates a row-level trigger for the customers table that would fire
for INSERT or UPDATE or DELETE operations performed on the CUSTOMERS table.
This trigger will display the salary difference between the old values and new values −

2
CREATE OR REPLACE TRIGGER display_salary_changes
BEFORE DELETE OR INSERT OR UPDATE ON customers
FOR EACH ROW
WHEN (NEW.ID > 0)
DECLARE
sal_diff number; BEGIN
sal_diff := :NEW.salary - :OLD.salary;
dbms_output.put_line('Old salary: ' || :OLD.salary);
dbms_output.put_line('New salary: ' || :NEW.salary);
dbms_output.put_line('Salary difference: ' || sal_diff); END; /

When the above code is executed at the SQL prompt, it produces the following result −

Trigger created.

The following points need to be considered here −

 OLD and NEW references are not available for table-level triggers, rather you can use
them for record-level triggers.

 If you want to query the table in the same trigger, then you should use the AFTER
keyword, because triggers can query the table or change it again only after the initial
changes are applied and the table is back in a consistent state.

 The above trigger has been written in such a way that it will fire before any DELETE or
INSERT or UPDATE operation on the table, but you can write your trigger on a single
or multiple operations, for example BEFORE DELETE, which will fire whenever a
record will be deleted using the DELETE operation on the table.

Triggering a Trigger
Let us perform some DML operations on the CUSTOMERS table. Here is one INSERT
statement, which will create a new record in the table −

INSERT INTO CUSTOMERS (ID,NAME,AGE,ADDRESS,SALARY)

VALUES (7, 'Kriti', 22, 'HP', 7500.00 );

When a record is created in the CUSTOMERS table, the above create

trigger, display_salary_changes will be fired and it will display the following result −

Old salary:
New salary: 7500
Salary difference:

3
Because this is a new record, old salary is not available and the above result comes as
null. Let us now perform one more DML operation on the CUSTOMERS table. The
UPDATE statement will update an existing record in the table −

UPDATE customers
SET salary = salary + 500
WHERE id = 2;

When a record is updated in the CUSTOMERS table, the above create

trigger, display_salary_changes will be fired and it will display the following result −

Old salary: 1500

New salary: 2000
Salary difference: 500

Types of SQL Triggers

In SQL Server, we have 3 groups of triggers:

 DML (data manipulation language) triggers – They react to DML commands.

These are – INSERT, UPDATE, and DELETE
 DDL (data definition language) triggers – As expected, triggers of this type shall
react to DDL commands like – CREATE, ALTER, and DROP
 Logon triggers – The name says it all. This type reacts to LOGON events

Functional Dependency in DBMS

In database management systems (DBMS), dependencies are a crucial concept that helps
effectively manage and organize data. A fully-functional dependency is a type of
dependency that exists between two sets of attributes in a database table. This article will
explore the concept of fully-functional dependency in DBMS and its significance in
database design and management.

A functional dependency is a relationship between two sets of attributes in a database

table. It indicates that the value of one attribute determines the value of another attribute
in the same table. A fully-functional dependency is a more specific type of functional
dependency that occurs when a set of attributes determines the value of every other
attribute in the table.

Explanation
To understand fully-functional dependency, let us consider an example.

The Employee_Details table could have attributes such as Employee_ID, Name, Address,
Phone_Number, Email, Department, Position, and Salary. If we know the value of
Employee_ID, we can determine the values of all other attributes in the table. This means

4
that the set of attributes {Employee_ID} fully functionally determines all other attributes
in the table.

In this case, identifying the fully-functional dependency allows us to split the table into
smaller, more manageable tables based on related attributes. For example, we could
create a table called Employee_Contact that only contains attributes related to employee
contact information, such as Employee_ID, Name, Address, Phone_Number, and Email.
We could also create a table called Employee_Salary that only contains attributes related
to employee salary information, such as Employee_ID, Department, Position, and Salary.

By splitting the table into smaller, more manageable tables, we can reduce data
redundancy and improve data consistency. It also makes it easier to modify and update
the database as we only need to make changes to the relevant tables rather than having to
update the entire Employee_Details table.

Identifying fully-functional dependencies is an important step in database design and

management. It allows us to organize data efficiently and ensure data consistency,
leading to better query performance and a more effective database management system.

Fully-functional dependencies play a crucial role in database design and management.

They help in reducing data redundancy and ensure data consistency. When we identify
fully-functional dependencies in a table, we can split the table into multiple smaller tables,
each containing a subset of the attributes. This process is known as normalization, and it
helps in reducing data redundancy and improves data consistency.

First Normal Form (1NF)

The first normalization technique is First Normal Form (1NF), which requires that each
attribute in a relational database table must have a unique value, meaning no two records
in the table can have the same value for any attribute.

Second Normal Form (2NF)

Second Normal Form (2NF) is the second normalization technique, which requires that
each non-key attribute in a relational database table be functionally dependent on the
entire primary key. This means that if a primary key has multiple attributes, each non-key
attribute must depend on all the attributes of the primary key.

Third Normal Form (3NF)

The third normalization technique is the Third Normal Form (3NF), which requires that
each non-key attribute in a relational database table must be functionally dependent only
on the primary key and not on any other non-key attributes. This means there should be
no transitive dependencies between non-key attributes.

Additionally, identifying fully-functional dependencies can help in improving query

performance. When tables are split into smaller, more manageable tables, queries can be

5
executed faster as there is less data to search. This can improve the overall performance
of the database management system.

Fully-Functional dependencies are also used in data modeling, the process of creating a
model of data that represents the structure, relationships, and constraints of data in a
database. In data modeling, functional dependencies help to represent the relationships
between attributes in a relational database, identify the minimum set of attributes required
to uniquely identify a record in a database table, and create a normalized relational
database that minimizes redundancy and improves data integrity.

Conclusion
In conclusion, fully-functional dependencies are an essential concept in database
management systems. They indicate a specific type of functional dependency where a set
of attributes determines the value of every other attribute in a table. Identifying fully-
functional dependencies can help reduce data redundancy, ensure data consistency, and
improve query performance. The process of normalization is used to organize data in a
database by splitting tables into smaller, more manageable tables based on the identified
dependencies.

Armstrong’s Axioms in Functional Dependency in DBMS

Armstrong Axioms
The term Armstrong Axioms refers to the sound and complete set of inference rules or
axioms, introduced by William W. Armstrong, that is used to test the logical implication
of functional dependencies. If F is a set of functional dependencies then the closure of F,
denoted as F+, is the set of all functional dependencies logically implied by F.
Armstrong’s Axioms are a set of rules, that when applied repeatedly, generates a closure
of functional dependencies.

Axioms
 Axiom of Reflexivity: If A is a set of attributes and B is a subset of A, then A holds B.
If B⊆A then A→B. This property is trivial property.
 Axiom of Augmentation: If A→B holds and Y is the attribute set, then AY→BY also
holds. That is adding attributes to dependencies, does not change the basic
dependencies. If A→B, then AC→BC for any C.
 Axiom of Transitivity: Same as the transitive rule in algebra, if A→B holds
and B→C holds, then A→C also holds. A→B is called A functionally which
determines B. If X→Y and Y→Z, then X→Z.

6
Secondary Rules
These rules can be derived from the above axioms.

 Union: If A→B holds and A→C holds, then A→BC holds.

If X→Y and X→Z then X→YZ.
 Composition: If A→B and X→Y hold, then AX→BY holds.
 Decomposition: If A→BC holds then A→B and A→C hold.
If X→YZ then X→Y and X→Z.
 Pseudo Transitivity: If A→B holds and BC→D holds, then AC→D holds.
If X→Y and YZ→W then XZ→W.
 Self Determination: It is similar to the Axiom of Reflexivity, i.e. A→A for any A.
 Extensivity: Extensivity is a case of augmentation. If AC→A, and A→B,
then AC→B. Similarly, AC→ABC and ABC→BC. This leads to AC→BC.

Decomposition in DBMS removes redundancy, anomalies and

inconsistencies from a database by dividing the table into multiple tables.

The term decomposition refers to the process in which we break down a table in a
database into various elements or parts. Thus, decomposition replaces a given relation
with a collection of various smaller relations. Thus, in a database, we can make any table
break down into multiple tables when we want to collect a particular set of data.

Decomposition must always be lossless. This way, we can rest assured that the
data/information that was there in the original relation can be reconstructed accurately on
the basis of the decomposed relations. In case the relation is not decomposed properly,
then it may eventually lead to problems such as information loss.

The following are the types −

Lossless Decomposition
Decomposition is lossless if it is feasible to reconstruct relation R from decomposed
tables using Joins. This is the preferred choice. The information will not lose from the
relation when decomposed. The join would result in the same original relation.

Let us see an example −

<EmpInfo>
7
Emp_I Emp_Na Emp_Ag Emp_Locati Dept_I Dept_Na
D me e on D me
E001 Jacob 29 Alabama Dpt1 Operations
E002 Henry 32 Alabama Dpt2 HR
E003 Tom 22 Texas Dpt3 Finance

Decompose the above table into two tables:

<EmpDetails>

Emp_ID Emp_Name Emp_Age Emp_Location

E001 Jacob 29 Alabama
E002 Henry 32 Alabama
E003 Tom 22 Texas

<DeptDetails>

Dept_ID Emp_ID Dept_Name

Dpt1 E001 Operations
Dpt2 E002 HR
Dpt3 E003 Finance

Now, Natural Join is applied on the above two tables −

The result will be −

Emp_I Emp_Na Emp_Ag Emp_Locati Dept_I Dept_Na

D me e on D me
E001 Jacob 29 Alabama Dpt1 Operations
E002 Henry 32 Alabama Dpt2 HR
E003 Tom 22 Texas Dpt3 Finance

Therefore, the above relation had lossless decomposition i.e. no loss of information.

8
Lossy Decomposition
As the name suggests, when a relation is decomposed into two or more relational
schemas, the loss of information is unavoidable when the original relation is retrieved.

Let us see an example −

<EmpInfo>

Emp_I Emp_Na Emp_Ag Emp_Locati Dept_I Dept_Na

D me e on D me
E001 Jacob 29 Alabama Dpt1 Operations
E002 Henry 32 Alabama Dpt2 HR
E003 Tom 22 Texas Dpt3 Finance

Decompose the above table into two tables −

<EmpDetails>

Emp_ID Emp_Name Emp_Age Emp_Location

E001 Jacob 29 Alabama
E002 Henry 32 Alabama
E003 Tom 22 Texas

<DeptDetails>

Dept_ID Dept_Name
Dpt1 Operations
Dpt2 HR
Dpt3 Finance

Now, you won’t be able to join the above tables, since Emp_ID isn’t part of
the DeptDetails relation.

Therefore, the above relation has lossy decomposition.