Specifying Constraints as

Assertions and Actions as

Triggers, views(Virtual table )
Dhruva S
Eshwar Shashidhar
Kishan L
● We introduce two additional features of SQL: the CREATE ASSERTION statement and the
CREATE TRIGGER statement
● CREATE ASSERTION, which can be used to specify additional types of constraints that are
outside the scope of the built-in relational model constraints (primary and unique keys, entity
integrity, and referential integrity)
● These built-in constraints can be specified within the CREATE TABLE statement of SQL
● We introduce CREATE TRIGGER, which can be used to specify automatic actions that the
database system will perform when certain events and conditions occur. This type of functionality
is generally referred to as active databases. We only introduce the basics of triggers in this
chapter
Specifying General Constraints as Assertions in SQL

● In SQL, users can specify general constraints—those that do not fall into any of the categories
described via declarative assertions, using the CREATE ASSERTION statement. Each assertion is
given a constraint name and is specified via a condition similar to the WHERE clause of an SQL
query. For example, to specify the constraint that the salary of an employee must not be greater
than the salary of the manager of the department that the employee works for in SQL, we can
write the following assertion:
CREATE ASSERTION SALARY_CONSTRAINT

CHECK ( NOT EXISTS ( SELECT *

FROM EMPLOYEE E, EMPLOYEE M, DEPARTMENT D

WHERE E.Salary>M.Salary

AND E.Dno = D.Dnumber

AND D.Mgr_ssn = M.Ssn ) );

E SSN ENAME SAL dno

1 e1 15k 5

2 e2 20k 5

M SSN ENAME SAL dno

1 e1 15k 5

2 e2 20k 5

DEP

dno dname mgrssn

5 X 2
Introduction to Triggers in SQL

Another important statement in SQL is CREATE TRIGGER. In many cases it is convenient to specify the type of
action to be taken when certain events occur and when certain conditions are satisfied.Another important
statement in SQL is CREATE TRIGGER. In many cases it is convenient to specify the type of action to be taken
when certain events occur and when certain conditions are satisfied. For example, it may be useful to specify a
condition that, if violated, causes some user to be informed of the violation. A manager may want to be informed if
an employee’s travel expenses exceed a certain limit by receiving a message whenever this occurs. The action that
the DBMS must take in this case is to send an appropriate message to that user. The condition is thus used to
monitor the database. Other actions may be specified, such as executing a specific stored procedure or triggering
other updates. The CREATE TRIGGER statement is used to implement such actions in SQL. Here we just give a
simple example of how triggers may be used.
 Syntax

create trigger [trigger_name]

[before | after]

{insert | update | delete}

on [table_name]

[for each row]

[trigger_body]

EVENT
COND
ACTION
CREATE TRIGGER SALARY_VIOLATION

BEFORE INSERT OR UPDATE OF SALARY, SUPERVISOR_SSN

ON EMPLOYEE

FOR EACH ROW

WHEN ( NEW.SALARY > ( SELECT SALARY FROM EMPLOYEE

WHERE SSN = NEW.SUPERVISOR_SSN ) )

INFORM_SUPERVISOR(NEW.Supervisor_ssn, NEW.Ssn );
SSN ENAME SAL SUPERV

1 e1 15k 2

2 e2 20k Null

3 e3 21k 2
1. The event(s): These are usually database update operations that are explicitly applied to the database. In this example
the events are: inserting a new employee record, changing an employee’s salary, or changing an employee’s supervisor.

The person who writes the trigger must make sure that all possible events are accounted for. In some cases, it may be
necessary to write more than one trigger to cover all possible cases.

These events are specified after the keyword BEFORE in our example, which means that the trigger should be
executed before the triggering operation is executed. An alternative is to use the keyword AFTER, which specifies that
the trigger should be executed after the operation specified in the event is completed.

2. The condition that determines whether the rule action should be executed: Once the triggering event has occurred,
an optional condition may be evaluated. If no condition is specified, the action will be executed once the event occurs.
If a condition is specified, it is first evaluated, and only if it evaluates to true will the rule action be executed. The
condition is specified in the WHEN clause of the trigger.

3. The action to be taken: The action is usually a sequence of SQL statements, but it could also be a database
transaction or an external program that will be automatically executed. In this example, the action is to execute the
stored procedure INFORM_SUPERVISOR
Views (Virtual Tables) in SQL

What is View in Database

● Virtual Table
-A view does not necessarily exist in physical form.
● View is the result set of stored query
● In SQL, the command to specify a view is CREATE VIEW.
● If we do not need a view anymore, we can use the DROP VIEW command to dispose of it.
View implementation , update & Inline views

Two main approaches have been suggested for implementation of views .

Query modification

View materialization

query modification, involves modifying or transforming the view query (submitted by the user) into a query on the
underlying base tables.

The disadvantages of this approach is that it is inefficient or views defined via com- plex queries that are time-consuming
to execute, especially if multiple view queries are going to be applied to the same view within a short period of time.
SELECT FROM WHERE

Fname, Lname

EMPLOYEE, PROJECT, WORKS_ON Ssn = Essn AND Pno = Pnumber AND Pname = ‘ProductX’;

view materialization, involves physically creating a temporary or permanent view table when the view is first queried or
created and keeping that table on the assumption that other queries on the view will follow .

In this case, an efficient strategy for automatically updating the view table when the base tables are updated must be
developed in order to keep the view up-to-date.
View update

Different strategies as to when a materialized view is updated are possible.

The immediate update strategy updates a view as soon as the base tables are changed .

The lazy update strategy updates the view when needed by a view query .

The periodic update strategy updates the view periodically (in the latter strategy, a view query may get a result that is
not up-to-date).

Issuing INSERT , DELETE , UPDATE command on a view table is not possible in many cases
ID NAME SALARY GENDER DEPT_ID

1 John 5000 M 3

2 Rock 4500 M 4

3 Dave 4800 M 6

4 Sins 6000 M 1
Create view vwEmpdata

as

Select ID , NAME , GENDER , DEPT_ID

from tblEmp

ID NAME GENDER DEPT_ID

1 John M 3

2 Rock M 4

3 Dave M 6

4 Sins M 1
Update vwEmpdata

Set NAME = ‘ Dwight ’ Where ID = 1

ID NAME GENDER DEPT_ID

1 Dwight M 3

2 Rock M 4

3 Dave M 6

4 Sins M 1
Summary
● A view with a single defining table is updatable if the view attributes contain the primary key of the base relation,
as well as all attributes with the NOT NULL constraint that do not have default values specified.

● Views defined on multiple tables using joins are generally not updatable .

● Views defined using grouping and aggregate functions are not updatable .
● In SQL, the clause WITH CHECK OPTION should be added at the end of the view definition if a view is to be
updated by INSERT, DELETE, or UPDATE statements. This allows the system to reject operations that violate
the SQL rules for view updates. The full set of SQL rules for when a view may be modified by the user are more
complex than the rules stated earlier.

● It is also possible to define a view table in the FROM clause of an SQL query. This is known as an in-line view. In
this case, the view is defined within the query itself.
● Inline views are utilized for writing complex SQL queries without join and subqueries operations .