Course: MSc DS

SQL Programming

Module: 5
Learning Objectives:

1. Differentiate between predefined and user-defined

exceptions in PL/SQL.

2. Implement BEGIN... EXCEPTION... END blocks for error-

resistant code.

3. Identify the role and significance of database triggers.

4. Apply best practices in creating, managing, and optimising

triggers.

5. Classify and utilise row-level, statement-level, and

BEFORE, AFTER, and INSTEAD OF triggers.

6. Design PL/SQL solutions using exceptions and triggers for

real-world use cases.

Structure:

5.1 Understanding Exceptions

5.2 Predefined and User-Defined Exceptions

5.3 Exception Handling

5.4 Introduction to Triggers

5.5 Creating and Managing Triggers

5.6 Trigger Types: Row, Statement, Before, After, Instead Of

5.7 Summary

5.8 Keywords

5.9 Self-Assessment Questions

5.10 Case Study

5.11 Reference

5.1 Understanding Exceptions

Exceptions in PL/SQL are run-time errors and abnormal

conditions that can disrupt the normal flow of a PL/SQL

program. They can arise due to reasons such as invalid data,

resource unavailability, or unexpected scenarios not

anticipated in the regular programming flow.

Importance of Exceptions in PL/SQL:

● Predictable Program Behaviour: By handling exceptions,

a PL/SQL program can ensure that it behaves predictably

under unexpected scenarios, rather than crashing or

 producing unreliable results.

● Enhanced User Experience: Exception handling allows for

the graceful handling of errors, providing meaningful

messages to the user rather than abrupt failures.

● Resource Management: Proper exception handling can

ensure that resources like database connections, files, or

memory are appropriately released or managed, even

when an error occurs.

● Maintaining Data Integrity: Exception handling can

prevent a program from proceeding with operations that

could result in corrupt or inconsistent data in the

database.

Role of Exceptions in Robust Database Programming:

Robust database programming seeks to produce programs that

are resilient, reliable, and resistant to failures, ensuring data

integrity and consistency. Here’s how exceptions play a pivotal

role in achieving this:

1. Error Detection:
 ● Exceptions enable the identification of errors and

unexpected conditions during runtime, which would

otherwise be hard to detect during compile-time or

testing phases.

2. Segmentation of Logic:

● By separating error handling logic from the main

business logic, the code becomes more readable,

maintainable, and modular. This isolation aids in

easy identification and modification of error-

handling routines without affecting the core logic.

3. Recovery Mechanisms:

● Exceptions provide the programmer with an

opportunity to implement recovery actions, like

retrying a failed operation, logging the error for

analysis, or redirecting to an alternate flow.

4. Consistent Response to Errors:

● By centralising the error-handling routines, a

consistent response or message can be presented to

 end-users or calling systems. This uniformity can

improve the predictability of the system for both

users and developers.

5. Guarding Data Transactions:

● Exceptions are especially crucial when handling

transactions in a database environment. They can

ensure that transactions are either completely

successful or rolled back in case of errors, preserving

the atomicity and consistency of data operations.

5.2 Predefined and User-Defined Exceptions

PL/SQL inherently provides a plethora of predefined exceptions,

which are readily available for developers to utilise in

recognizing and handling common database-related errors.

● Standard Exceptions: These exceptions are automatically

raised by the Oracle Database whenever a related

database error occurs. For instance, when trying to insert

a null value into a non-null column, Oracle will

 automatically raise the VALUE_ERROR exception.

● Named System Exceptions: These are exceptions that

have been given explicit names by Oracle. Examples

include NO_DATA_FOUND (raised when a SELECT INTO

statement returns no data) and TOO_MANY_ROWS

(raised when a SELECT INTO statement returns more than

one row).

Examples of Common Predefined Exceptions

Some common predefined exceptions PL/SQL developers often

encounter include:

● NO_DATA_FOUND: Raised when a SELECT INTO

statement retrieves no rows.

● TOO_MANY_ROWS: Elicited when a SELECT INTO

retrieves more than one row.

● VALUE_ERROR: Emerges when there's an arithmetic,

conversion, truncation, or size-constraint error.

● ZERO_DIVIDE: Triggered when an attempt to divide a

 number by zero occurs.

Crafting Custom Exceptions for Specific Use Cases

There may arise scenarios where the built-in exceptions are not

sufficient to address specific error conditions pertinent to the

business logic. In these circumstances, PL/SQL permits

developers to craft their own user-defined exceptions.

● Advantages: User-defined exceptions offer granular

control, allowing developers to signal very specific error

conditions tailored to the business application's

requirements. By doing so, they can capture and handle

exceptions more efficiently, ensuring smoother end-user

experiences.

Implementing User-Defined Exceptions: A Step-by-Step

Approach

1. Declaration:

● Begin by declaring your exception in the declaration

 section of your PL/SQL block, procedure, or function

using the EXCEPTION keyword.

MY_EXCEPTION EXCEPTION;

2. Raising the Exception:

● Within the execution section, you can raise the

exception based on a specific condition using the

RAISE statement.

IF some_condition THEN RAISE MY_EXCEPTION; END IF;

3. Handling the Exception:

● In the exception-handling section of your PL/SQL

block, you can specify the actions to be undertaken

once your exception is raised.

EXCEPTION WHEN MY_EXCEPTION THEN -- handle the

exception (e.g., log the error, notify the user)

5.3 Exception Handling

1. The Need for Effective Exception Handling

Exception handling is a pivotal aspect of robust and resilient

software design, especially in SQL programming. In the world of

data, where precision, accuracy, and reliability are paramount,

exceptions—unexpected events during the execution of a

program—can derail expected outcomes or even crash systems.

These can arise from various reasons:

● Unanticipated data inputs

● Data corruption

● Resource unavailability

● System malfunctions

Effective exception handling ensures that these unforeseen

events are captured and addressed systematically, thereby:

● Preserving the integrity of the system.

● Ensuring smooth user experience by preventing abrupt

failures.

● Facilitating easier debugging and problem resolution.

2. The PL/SQL Exception Handling Mechanism

PL/SQL, Oracle's procedural language extension to SQL,

integrates a rich exception handling mechanism. This is centred

around defining, raising, and handling exceptions in the

programmatic flow.

● Predefined exceptions: PL/SQL provides a set of

exceptions that are automatically raised when

corresponding errors occur. For example, ZERO_DIVIDE is

raised when a division-by-zero occurs.

● User-defined exceptions: Users can define and name

their own exceptions to capture specific error conditions.

3. Using BEGIN... EXCEPTION... END Blocks

The foundation of PL/SQL's exception handling lies in the

BEGIN... EXCEPTION... END blocks. This structure is

instrumental in defining the normal flow and specifying how to

handle deviations:

BEGIN -- Normal execution code here EXCEPTION WHEN

exception THEN -- Error handling code for exception WHEN

exception THEN -- Error handling code for exception2 ... END;

Within this block:

● The BEGIN section contains the main PL/SQL code.

 ● The EXCEPTION section is where specific exceptions are

captured and handled.

4. The RAISE and RAISE_APPLICATION_ERROR Procedures

● RAISE: This procedure allows manual triggering of an

exception. It's especially useful for user-defined

exceptions or in scenarios where a predefined exception

needs to be triggered based on custom logic.

Example:

DECLARE

my_exception EXCEPTION;

BEGIN

IF some_condition THEN

RAISE my_exception;

END IF;

EXCEPTION

WHEN my_exception THEN

-- Handle the exception

END;
 ● RAISE_APPLICATION_ERROR: A powerful built-in

procedure that allows raising a user-defined error with a

custom error message and error number. It's particularly

beneficial when standard exceptions do not adequately

describe an error scenario.

Example:

BEGIN

IF some_condition THEN

RAISE_APPLICATION_ERROR(-20001, 'An error occurred due

to some_condition');

END IF;

END;

5. Guidelines for Efficient Exception Management

For maintaining robustness and clarity in SQL programming,

consider these best practices:

● Be specific: Handle exceptions as specifically as possible.

Avoid generic catch-alls that can mask the true nature of

an issue.
 ● Provide meaningful feedback: Whether logging the error

or informing the user, ensure that the feedback is

descriptive to facilitate quicker resolution.

● Avoid overuse: While exceptions are powerful, they

should not be a replacement for proper control flow or

validation. Use them judiciously.

● Document: Any user-defined exception or unique

handling scenario should be well-documented for the

benefit of developers and maintenance teams.

● Centralise handling: If possible, centralise exception

handling to avoid repetitive code and ensure uniform

responses to exceptions.

5.4 Introduction to Triggers

Triggers are specialised routines that are set into motion (or

"triggered") when specific events occur within a relational

database system. These events can include insertions, deletions,

and updates. Unlike regular processes, which require explicit

calls, triggers automatically spring into action when their

defined events happen.

● How they work: Triggers watch for particular changes,

then automatically initiate defined operations when those

changes occur.

● Components:

o Event: What prompts the trigger. Common events

include INSERT, UPDATE, and DELETE operations.

o Condition: An optional specification that must be

met for the trigger to run.

o Action: What the trigger does. This is typically a

series of SQL statements.

Why are Triggers Important?

The primary significance of triggers lies in their ability to ensure

data integrity, automate complex business rules, and manage

log audit trails.

● Data Integrity: By specifying certain constraints that the

built-in constraints can't enforce, triggers help maintain

 the quality and accuracy of the data.

● Automated Business Rules: Triggers can help enforce

complex business rules that might be challenging or

inefficient to implement at the application layer.

● Audit Trails: They can automatically generate logs and

historical records whenever data changes, aiding in the

tracing and monitoring of database activity.

Comparing Triggers with Stored Procedures

Both triggers and stored procedures are database objects that

store a sequence of SQL statements. However, there are key

differences:

● Activation:

o Triggers: Automatically initiated by data

modification or database operations.

o Stored Procedures: Executed when explicitly called

by a user or application.

● Purpose:

o Triggers: Mainly used for maintaining data integrity

 and enforcing business rules automatically.

o Stored Procedures: Typically used for encapsulating

and reusing a series of SQL statements, potentially

for complex operations.

● Control:

o Triggers: Less control for end-users, as they are

implicit and automatic.

o Stored Procedures: More control, as they can be

executed on-demand and can accept parameters for

versatile use.

Real-world Applications of Database Triggers

In practical scenarios, triggers can be crucial in various

operations:

● E-commerce: When a customer places an order, a trigger

can automatically update the inventory count.

● Banking: After a customer makes a transaction, a trigger

can automatically update both the sender's and the

receiver's account balances.

 ● CRM Systems: When a sales representative updates a

deal's status to 'closed-won', a trigger might generate an

invoice automatically.

● Auditing: In sensitive industries, triggers can log any

change to critical data, providing a trail of who changed

what and when.

5.5 Creating and Managing Triggers

Triggers, in database systems, particularly in Oracle's PL/SQL,

are sets of commands that automatically execute or fire in

response to certain events, such as data modifications. They

are immensely useful in implementing business rules, ensuring

data integrity, and maintaining audit logs.

Anatomy of a PL/SQL Trigger

A typical PL/SQL trigger has several components:

● Triggering Event: This specifies when the trigger should

fire. Common events include INSERT, UPDATE, and

DELETE.

● Trigger Type: Based on their timing:

 o BEFORE: Executes before the triggering event.

o AFTER: Executes after the triggering event.

● Triggering Level: Defines the level at which the trigger

acts:

o ROW level: Fires once for every row affected.

o STATEMENT level: Fires once for the SQL statement.

● Trigger Body: The PL/SQL block containing the logic to be

executed when the trigger fires.

Steps to Create a Trigger in Oracle Database

1. Define the Triggering Event: Decide when the trigger

should execute. For instance, after an INSERT on a specific

table.

2. Choose the Trigger Type and Level: Determine whether

you want it to execute before or after the event, and at

which level.

3. Write the PL/SQL Code: Define the logic inside the trigger

body.

4. Use the CREATE TRIGGER Statement: The basic syntax is:

CREATE [OR REPLACE] TRIGGER trigger_name

[BEFORE | AFTER] [INSERT | UPDATE | DELETE]

ON table_name [FOR EACH ROW]

BEGIN

-- Trigger logic here

END;

Modifying, Disabling, and Dropping Triggers: Best Practices

● Modifying Triggers:

o Use the CREATE OR REPLACE TRIGGER statement. It

ensures that if the trigger exists, it is replaced;

otherwise, a new one is created.

o Test the modified trigger in a controlled

environment before deploying in production.

● Disabling Triggers:

o If you need to temporarily halt a trigger’s operation,

you can disable it using the ALTER TRIGGER

trigger_name DISABLE; command.

 o Disabling a trigger is useful during bulk data

operations to improve performance.

● Dropping Triggers:

o To remove a trigger, use the DROP TRIGGER

trigger_name; command.

o Before dropping, ensure that there are no

dependencies or business processes that still require

it.

Performance Considerations When Working with Triggers

Triggers, while powerful, can significantly impact database

performance:

● Overhead: Each trigger introduces some overhead.

Especially for operations affecting many rows, ROW level

triggers can slow down the process considerably.

● Complex Logic: Triggers with extensive or complex logic

can result in increased execution time.

● Multiple Triggers: If multiple triggers are set on the same

event for a table, it can be challenging to predict the

 order in which they will execute, potentially causing

unintended results.

● Nested Triggers: If triggers invoke operations that fire

other triggers, it can lead to a cascading effect, affecting

performance and predictability.

5.6 Trigger Types: Row, Statement, Before, After, Instead Of

Triggers in SQL are powerful tools that allow for automatic

actions or side effects to take place in response to certain

database operations.

1. Trigger Types:

● Row-level Trigger: This is activated for each row that an

INSERT, UPDATE, or DELETE operation affects. Thus, if a

SQL operation affects multiple rows, the row-level trigger

will be executed multiple times, once for each affected

row.

● Statement-level Trigger: Activated once for each INSERT,

 UPDATE, or DELETE operation, regardless of how many

rows are affected. These triggers aren't concerned with

specific rows but rather the overarching operation.

● BEFORE Trigger: This is fired before the triggering SQL

statement is executed, providing an opportunity to check

or change data before it's committed.

● AFTER Trigger: Executed after the triggering SQL

statement has run. Useful for actions that depend on the

statement completing successfully.

● INSTEAD OF Trigger: Generally associated with views. It's

executed instead of the triggering SQL statement,

allowing for an alternative action.

2. Distinguishing Between Row-level and Statement-level

Triggers:

● Row-level:

o Focuses on individual rows.

o Typically used when we need to perform an action

 on each row affected, such as updating a specific

field.

o Has access to the 'OLD' and 'NEW' aliases to

reference the state of the row before and after the

triggering statement.

● Statement-level:

o Concerned with the operation as a whole.

o Does not have access to individual row data from

the triggering statement.

o Useful for tasks like auditing or tracking bulk

operations.

3. Deciding When to Use BEFORE vs. AFTER Triggers:

● BEFORE:

● When you need to validate or modify data before

it's written to the database.

● To prevent certain operations from happening

under specific conditions.

 ● AFTER:

● When you need to perform follow-up actions that

depend on the SQL operation successfully

completing.

● For actions that don't need to interfere with or

modify the triggering SQL operation, such as logging

or notifications.

4. Understanding and Implementing INSTEAD OF Triggers:

● Functionality:

o As the name suggests, these triggers run instead of

the operation that activated them.

● Common Use Cases:

o Primarily used with views, which can't directly

handle INSERTs, UPDATEs, or DELETEs since they

don’t represent physical tables.

o Allow developers to define actions that should be

taken when someone tries to modify data via a view.

 ● Implementation:

o The trigger essentially redefines the operation. For

example, an INSTEAD OF INSERT trigger on a view

could translate the insert action into an appropriate

insert on the underlying tables.

5. Use Cases and Scenarios for Different Trigger Types:

● Row-level:

o Cascading updates or deletes, where a change to

one row necessitates changes in other related rows.

o Record-level auditing, where changes to individual

rows are tracked.

● Statement-level:

o Monitoring bulk operations on a table.

o Logging operations without the need to capture

row-specific details.

● BEFORE:

o Data validation.
 o Data transformation before persistence.

● AFTER:

o Notifications, like sending an email after the

successful addition of a new user.

o Logging actions for auditing purposes.

● INSTEAD OF:

o Redefining operations on views.

o Ensuring the integrity of complex operations

spanning multiple tables.

5.7 Summary

❖ Exceptions are runtime errors in PL/SQL programs, and

they can be either predefined by the Oracle environment

or custom-defined by developers. They enable handling

unforeseen errors gracefully without abrupt program

termination.

❖ Predefined exceptions are built into PL/SQL and

correspond to common Oracle errors. User-defined

 exceptions are custom error conditions specified by

developers to manage specific scenarios not covered by

predefined ones.

❖ Exception handling in PL/SQL uses BEGIN... EXCEPTION...

END blocks to capture and manage errors. It allows

developers to specify actions to take when an error

occurs, such as logging, notification, or alternative

execution paths.

❖ Triggers are specialised stored procedures that

automatically execute (or "fire") in response to specific

events in a database, like data modifications or schema

changes, enhancing data integrity and enforcing business

rules.

❖ Triggers can be created using the CREATE TRIGGER

statement in Oracle. Management includes modifying,

enabling, disabling, or dropping triggers based on the

evolving needs of the database application.

 ❖ Triggers can be categorised based on timing (BEFORE,

AFTER, or INSTEAD OF) and scope (row-level or

statement-level). The choice of trigger type depends on

the specific use case and desired effect in response to

database events.

5.8 Keywords

● Exception: In PL/SQL, an exception is a runtime error or

warning condition that interrupts the normal flow of

execution. Exceptions can be caused by external factors

or can be deliberately raised by the program itself. They

are critical for identifying and handling unexpected issues

during program execution.

● Predefined Exception: These are standard exceptions

provided by Oracle's PL/SQL language. For instance,

NO_DATA_FOUND is a predefined exception that gets

raised when a SELECT INTO statement returns no rows.

 Another example is ZERO_DIVIDE, which occurs when a

program attempts to divide by zero.

● User-Defined Exception: As the name suggests, these are

custom exceptions defined by the developer. User-

defined exceptions are especially useful when one needs

to raise and catch exceptions specific to the business or

application logic.

● Trigger: A trigger in PL/SQL is a stored procedure that

automatically executes or fires in response to specific

events (like an INSERT, UPDATE, or DELETE operation) on

a particular table or view. They are useful for maintaining

database integrity, automating tasks, and implementing

business logic.

● Row-Level Trigger: This type of trigger fires once for each

row affected by the triggering statement. For example, if

an UPDATE statement modifies 10 rows, a row-level

trigger would be executed 10 times.

 ● Statement-Level Trigger: Contrary to the row-level trigger,

a statement-level trigger fires once for each SQL

statement, regardless of how many rows are affected. If

an UPDATE statement modifies 10 rows, a statement-

level trigger would be executed just once for the entire

operation.

5.9 Self-Assessment Questions

1. How can you differentiate between predefined and user-

defined exceptions in PL/SQL?

2. What is the primary purpose of the

RAISE_APPLICATION_ERROR procedure in exception

handling?

3. Which trigger type, either row-level or statement-level, is

invoked once for each row that meets the triggering event

criteria?

4. What are the key distinctions between BEFORE, AFTER,

and INSTEAD OF triggers in PL/SQL?

 5. How would you manage the performance implications of

having multiple triggers in a database application?

5.10 Case Study

Title: Tokyo Metro Data Analytics

Introduction:

The Tokyo Metro system, one of the busiest in the world,

transports millions of passengers daily. As part of an initiative

to enhance customer experience and improve operational

efficiency, the metro's management decided to use SQL

programming to analyse vast amounts of data collected

through ticketing systems, sensors, and customer feedback.

Challenge:

With increasing ridership, Tokyo Metro was facing issues in

peak hour congestion, ticketing discrepancies, and

infrastructure wear and tear. Traditional methods of data

analysis were proving insufficient to pinpoint problem areas.

They needed a data-driven approach to predict congestion,

identify potential fare evaders, and understand the lifespan of

their infrastructure components.

Solution:

A team of data scientists was set up, and they began by

centralising the disparate data sources into an SQL database.

Using SQL queries, they segmented data based on stations,

times, and ticket types.

1. To address congestion, the team developed an SQL

algorithm to predict peak times at specific stations based

on historical data. This helped in optimising train

schedules and station staffing.

2. For fare evasion detection, they analysed patterns of

ticket purchases and used SQL to correlate them with

entry and exit logs. Anomalies in this data, such as a

passenger exiting a station without any entry record,

were flagged for further investigation.

3. To understand infrastructure wear, SQL queries compare

 the age of infrastructure components, like escalators or

tracks, against maintenance records and breakdown

incidents. This provided insights into which components

were likely to need replacements or upgrades.

Outcome:

By leveraging SQL programming, Tokyo Metro was able to

make informed decisions leading to smoother operations,

reduced fare evasion, and timely infrastructure maintenance.

This case underscores the vital role of SQL in transforming raw

data into actionable insights.

Questions:

1. How did the data scientists centralise the disparate data

sources, and why was this step crucial for effective

analysis?

2. Based on the case study, how did SQL programming aid

Tokyo Metro in identifying potential fare evaders?

3. In terms of infrastructure maintenance, how did the use

of SQL queries help Tokyo Metro prioritise upgrades or

 replacements?

5.11 References

1. "Oracle PL/SQL Programming" by Steven Feuerstein and

Bill Pribyl

2. "SQL: The Complete Reference" by James R. Groff, Paul N.

Weinberg, and Andrew J. Oppel

3. "Mastering Oracle PL/SQL: Practical Solutions" by Connor

McDonald, Chaim Katz, Christopher Beck, and Joel R.

Kallman

4. "Pro Oracle Application Express" by John Scott and Scott

Spendolini

5. "Oracle Database 12c PL/SQL Programming" by Michael

McLaughlin