DBMS Unit II — Normalization, Security & PL/SQL

After completing this unit, you will be able to:

1. Analyze functional dependencies and determine candidate keys using closure techniques.
2. Apply normalization techniques (1NF to 5NF and BCNF) to eliminate data redundancy and anomalies.
3. Evaluate database decompositions for lossless join and dependency preservation properties.
4. Identify database security threats and recommend appropriate security mechanisms and countermeasures.
5. Design efficient and secure relational database schemas for real-world applications.

Where each outcome is covered

How the chapters connect

Chapter 2.1 gives you the mathematics of dependencies. Chapter 2.2 uses those dependencies to restructure tables so redundancy and anomalies disappear. Chapter 2.3 protects the well-structured data. PL/SQL is the programming layer that enforces business rules, constraints, audits and access control inside the database itself.

flowchart LR
  A["2.1 Functional dependencies"]:::g --> B["2.2 Normalization"]:::m
  B --> C["Decomposition: lossless and dependency preserving"]:::m
  C --> D["Normalized schema"]:::g
  D --> E["2.3 Security controls"]:::m
  D --> F["PL/SQL enforcement"]:::m
  E --> G["Secure, efficient database"]:::g
  F --> G

• Define and analyze different types of dependencies in relational databases.
• Compute attribute closures and identify candidate keys.
• Derive canonical covers for a set of functional dependencies.
• Perform decomposition and verify lossless join and dependency preservation properties.
• Apply dependency concepts in relational database design.

2.1.1 What is a functional dependency?

An FD is a constraint on the meaning of the data, not something you read off a single table. A table can only disprove an FD (by showing two rows that agree on X but not on Y). The designer declares FDs from business rules: “a student ID identifies exactly one student name”.

Here RollNo → Name, Dept, HOD holds (RollNo is the key) and Dept → HOD holds. But Dept → Name does not: rows 101 and 102 agree on Dept (CS) yet differ on Name.

Trivial FD: X → Y is trivial when Y ⊆ X (e.g. {RollNo, Name} → Name). Non-trivial: Y ⊄ X. Normalization only worries about non-trivial FDs.

2.1.2 Types of dependencies

flowchart TD
  A["Dependency X to Y in relation R"]:::g --> B{"Is Y a subset of X?"}
  B -- Yes --> C["Trivial FD"]:::m
  B -- No --> D["Non-trivial FD"]:::g
  D --> E{"Does Y depend on every attribute of X?"}
  E -- Yes --> F["Full functional dependency"]:::m
  E -- No --> G["Partial dependency on part of the key"]:::y
  D --> H{"Does X to Y and Y to Z hold with Y not a key?"}
  H -- Yes --> I["Transitive dependency X to Z"]:::y
  A --> J["Beyond FDs"]
  J --> K["Multi-valued: X multi-determines Y, independent sets"]:::m
  J --> L["Join dependency: R equals join of its projections"]:::m

2.1.3 Armstrong’s axioms

Armstrong’s axioms are sound (they derive only true FDs) and complete (they derive every FD implied by F). The set of all implied FDs is the closure of F, written F⁺.

2.1.4 Attribute closure

1. Set result = X.
2. Look for an FD A → B in F with A ⊆ result and B ⊄ result.
3. If found, set result = result ∪ B and repeat step 2.
4. When no FD adds anything new, stop. X⁺ = result.

flowchart TD
  S(["Start: attribute set X and FD set F"]):::g --> I["result = X"]
  I --> L{"Is there an FD A to B in F with A inside result and B not inside result?"}
  L -- Yes --> U["result = result union B"]
  U --> L
  L -- No --> E(["Output: X plus = result"]):::g

Try it: closure and candidate-key calculator

Enter attributes and FDs (one per line) to see closure steps and all candidate keys.

2.1.5 Identifying candidate keys

1. Find attributes that never appear on any right-hand side. They must be in every candidate key.
2. Compute the closure of that set. If it covers R, it is the only candidate key.
3. If not, add other attributes one at a time (then pairs, …) and test closures.
4. Keep only minimal sets. Repeat to find all keys; the union of their attributes is the set of prime attributes.

flowchart TD
  A["List attributes of R and FDs in F"]:::g --> B["Find attributes never on any right-hand side"]
  B --> C["Compute closure of that set"]
  C --> D{"Closure contains all attributes?"}
  D -- Yes --> E["It is a candidate key and the only one"]:::g
  D -- No --> F["Add one more attribute from the rest"]
  F --> G["Compute closure of each combination"]
  G --> H{"Closure equals all attributes?"}
  H -- No --> F
  H -- Yes --> I["Candidate key if no proper subset is a key"]:::g
  I --> J["Try other combinations of the same size for more keys"]
  J --> K["Prime attributes are all attributes in any candidate key"]:::m

2.1.6 Canonical (minimal) cover

Different FD sets can imply the same F⁺. A canonical cover F_c is an equivalent set with no redundancy: every FD has a single attribute on the right (in the textbook form), no extraneous attribute on any left side, and no FD that is implied by the others. It is the starting point for 3NF synthesis.

flowchart TD
  A["Given FD set F"]:::g --> B["Step 1: split right sides to single attributes"]
  B --> C["Step 2: remove extraneous attributes from left sides"]
  C --> D["Step 3: remove redundant FDs"]
  D --> E{"Did anything change in step 2 or 3?"}
  E -- Yes --> C
  E -- No --> F["Canonical cover Fc, optionally merge FDs with same left side"]:::g

2.1.7 Decomposition techniques

Decomposition replaces R by smaller schemas R1…Rn such that R1 ∪ … ∪ Rn = R. We decompose to remove redundancy and anomalies. A good decomposition must be lossless (the original data can be rebuilt exactly with joins) and preferably dependency preserving (every FD can be checked inside a single table).

Full tests, tableau (chase) method and worked examples are in Section 4. Below is the verification flow you apply to any proposed decomposition.

flowchart TD
  A["Proposed decomposition of R into R1 ... Rn"]:::g --> B["Check 1: lossless join"]
  B --> C{"Binary case: does R1 intersect R2 determine R1 minus R2 or R2 minus R1?"}
  B --> N["More than 2 tables: use the chase tableau"]
  C -- No --> X["Lossy: reject or add common key attributes"]:::y
  C -- Yes --> D["Check 2: dependency preservation"]
  N --> D
  D --> E{"Is every FD of F implied by the projected FDs?"}
  E -- No --> W["FD lost: enforcing it needs a join"]:::y
  E -- Yes --> OK["Good decomposition: lossless and dependency preserving"]:::g

2.1.8 Applying dependency concepts in design

In practice you (1) gather business rules, (2) write them as FDs, MVDs and JDs, (3) compute candidate keys, (4) reduce F to a canonical cover, (5) decompose to the target normal form, (6) verify lossless join and dependency preservation, and (7) implement keys and constraints in SQL.

-- FDs RollNo -> Name, Dept and Dept -> HOD become keys in two tables
CREATE TABLE department (
  dept    VARCHAR2(10) PRIMARY KEY,           -- determinant of HOD
  hod     VARCHAR2(60) NOT NULL
);
CREATE TABLE student (
  roll_no NUMBER PRIMARY KEY,                 -- determinant of name, dept
  name    VARCHAR2(60) NOT NULL,
  dept    VARCHAR2(10) NOT NULL REFERENCES department(dept)
);
-- Rebuild the original relation: the join is lossless
SELECT s.roll_no, s.name, s.dept, d.hod
FROM   student s JOIN department d ON d.dept = s.dept;

• Explain the need and objectives of normalization.
• Convert database schemas into 1NF, 2NF, 3NF, and BCNF.
• Apply higher normal forms (4NF and 5NF) to complex database designs.
• Identify insertion, deletion, and update anomalies.
• Evaluate situations where denormalization may improve performance.

3.1 Need and objectives of normalization

Normalization is the systematic process of organizing attributes into relations using dependencies, so that each fact is stored once and only once.

3.2 Insertion, deletion and update anomalies

Consider this poorly designed table that mixes employees, departments and projects. Primary key: EmpID.

flowchart TD
  R["Facts about different entities stored in one table"]:::y --> RD["Redundant data"]
  RD --> I["Insertion anomaly: cannot add one fact without another"]
  RD --> D["Deletion anomaly: deleting one fact loses another"]
  RD --> U["Update anomaly: many rows to change, risk of inconsistency"]
  I --> S["Remedy: decompose using FDs into Employee and Department"]:::g
  D --> S
  U --> S

3.3 Functional dependency review

Normal forms are defined entirely with FDs and keys. Keep these in mind: a determinant is the left side of an FD; a candidate key is a minimal set whose closure is all of R; a prime attribute lies in some candidate key. Revisit Chapter 2.1 if any term feels shaky.

3.4 The normalization ladder

flowchart TD
  U["Unnormalized: repeating groups, multi-valued cells"]:::y --> N1["1NF: atomic values, key defined"]:::m
  N1 --> N2["2NF: no partial dependency on a composite key"]:::m
  N2 --> N3["3NF: no transitive dependency for non-prime attributes"]:::m
  N3 --> BC["BCNF: every determinant is a superkey"]:::g
  BC --> N4["4NF: no non-trivial multi-valued dependency"]:::g
  N4 --> N5["5NF: every join dependency implied by candidate keys"]:::g

3.5 The normal forms, one by one

Student(StudentID, StudentName)
Course(CourseID, CourseTitle)
Enrollment(StudentID, CourseID, Grade)

Student(RollNo, Name, Dept)       -- Dept is a foreign key
Department(Dept, HOD)

flowchart TD
  A["Take each non-trivial FD X to A in R"]:::g --> B{"Is X a superkey?"}
  B -- Yes --> C["Allowed in both 3NF and BCNF"]:::g
  B -- No --> D{"Is A a prime attribute?"}
  D -- Yes --> E["3NF allows it but BCNF is violated"]:::y
  D -- No --> F["Violates both 3NF and BCNF"]:::y
  E --> G["Decompose into X plus A and the rest, then check dependency preservation"]
  F --> H["Decompose with BCNF algorithm or 3NF synthesis"]

flowchart TD
  R["EmpSkillLang with emp, skill, language"]:::g --> M["MVDs: emp multi-determines skill and emp multi-determines language"]
  M --> P["Every skill pairs with every language: row explosion"]:::y
  P --> S1["EmpSkill with emp, skill"]:::m
  P --> S2["EmpLanguage with emp, language"]:::m
  S1 --> J["Natural join on emp rebuilds the original"]:::g
  S2 --> J

flowchart TD
  R["Supply with S, P, J"]:::g --> SP["SP with supplier, part"]:::m
  R --> PJ["PJ with part, project"]:::m
  R --> SJ["SJ with supplier, project"]:::m
  SP --> JN["Join of SP, PJ and SJ equals R"]:::g
  PJ --> JN
  SJ --> JN

3.6 Comparison of normal forms

3.7 Worked example: unnormalized → 1NF → 2NF → 3NF → BCNF

Start with one wide table for course registration. Business rules (FDs): StudentID → StudentName; StudentID ↠ many phone numbers; CourseID → CourseTitle, Instructor; Instructor → Room; (StudentID, CourseID) → Grade.

StudentPhone(StudentID, Phone)                                   key: (StudentID, Phone)
Registration(StudentID, StudentName, CourseID, CourseTitle,
             Instructor, Room, Grade)                            key: (StudentID, CourseID)

Student(StudentID, StudentName)
Course(CourseID, CourseTitle, Instructor, Room)
Enrollment(StudentID, CourseID, Grade)
StudentPhone(StudentID, Phone)

Course(CourseID, CourseTitle, Instructor)      -- Instructor is a foreign key
Instructor(Instructor, Room)
Student(StudentID, StudentName)
Enrollment(StudentID, CourseID, Grade)
StudentPhone(StudentID, Phone)

3.8 Denormalization

Denormalization deliberately introduces controlled redundancy to a normalized schema to speed up reads. It is a performance decision made after normalizing, never a replacement for normalization.

flowchart TD
  A["Schema normalized to 3NF or BCNF"]:::g --> B{"Measured performance problem?"}
  B -- No --> C["Stay normalized"]:::g
  B -- Yes --> D{"Read-heavy workload with costly joins?"}
  D -- No --> E["Tune indexes, queries and caching first"]:::m
  D -- Yes --> F{"Can redundancy be kept consistent by triggers or batch refresh?"}
  F -- No --> E
  F -- Yes --> G["Denormalize selectively"]:::y
  G --> H["Document it and monitor consistency"]

Use it when: reporting or analytics dominate, joins across many tables are provably the bottleneck, data is mostly read-only (data warehouses, dashboards). Avoid it when: the workload is write-heavy or data accuracy is critical (banking balances).

4.1 Why decompose?

To eliminate the redundancy and anomalies identified by normal-form violations. Splitting a relation is safe only when it keeps (1) all the information (lossless join) and ideally (2) all the constraints (dependency preservation).

flowchart TD
  A["Relation R with FD set F"]:::g --> B{"Anomalies or redundancy present?"}
  B -- No --> Z["Keep R as it is"]
  B -- Yes --> C{"R already in BCNF?"}
  C -- Yes --> D["Check 4NF and 5NF, otherwise done"]
  C -- No --> E["Pick violating FD X to Y: split into X union Y and R minus Y"]
  E --> F["Lossless guaranteed since X is a key of X union Y"]:::g
  F --> G{"Are all FDs preserved?"}
  G -- Yes --> H["Accept BCNF decomposition"]:::g
  G -- No --> I{"Is losing the FD acceptable?"}
  I -- Yes --> H
  I -- No --> J["Use 3NF synthesis: lossless and dependency preserving"]:::m

4.2 Lossless join

Binary test

flowchart TD
  A["Decomposition D with R1 ... Rn of R"]:::g --> B{"Only two relations?"}
  B -- Yes --> C["common = R1 intersect R2"]
  C --> D["Compute closure of common under F"]
  D --> E{"Closure contains R1 or R2?"}
  E -- Yes --> L["Lossless join"]:::g
  E -- No --> M["Lossy join"]:::y
  B -- No --> F["Build tableau: one row per Ri, distinguished symbol where attribute in Ri"]
  F --> G["Apply each FD: equate symbols, prefer distinguished ones"]
  G --> H{"Any row entirely distinguished?"}
  H -- Yes --> L
  H -- No --> I{"Any further change possible?"}
  I -- Yes --> G
  I -- No --> M

4.3 Dependency preservation

Practical test (avoids computing F⁺): for each FD X → Y in F, set result = X and repeat result = result ∪ ((result ∩ Ri)⁺ ∩ Ri) for every Ri until nothing changes. X → Y is preserved iff Y ⊆ result.

flowchart TD
  A["For each FD X to Y in F"]:::g --> B["result = X"]
  B --> C["For each Ri: result = result union closure of result intersect Ri, restricted to Ri"]
  C --> D{"Did result change in this pass?"}
  D -- Yes --> C
  D -- No --> E{"Is Y inside result?"}
  E -- Yes --> F["This FD is preserved"]:::g
  E -- No --> G["FD lost: decomposition is not dependency preserving"]:::y

4.4 Trade-offs

More decomposition means more tables and more joins. Normalization optimizes write correctness and storage; read performance may need indexes, materialized views or selective denormalization (see 3.8). Aim for a lossless, dependency-preserving 3NF or BCNF design, then measure.

• Explain the importance of database security in organizations.
• Identify common database threats and vulnerabilities.
• Differentiate between authentication and authorization mechanisms.
• Recommend suitable countermeasures to secure database systems.
• Apply security principles to protect data confidentiality, integrity, and availability.

5.1 Why database security matters

Databases hold an organization’s most valuable assets: customer identities, financial records, health data, trade secrets. A breach causes financial loss, legal penalties (privacy laws such as GDPR and India’s DPDP Act), loss of customer trust and operational downtime. Security must be built in to the schema, the access rules and the code, not added afterwards.

5.2 The CIA triad

flowchart TD
  C(["CIA triad"]):::g
  C --> CO["Confidentiality: only authorized parties read data. Tools: access control, encryption, masking"]:::m
  C --> IN["Integrity: data stays accurate and changes only in authorized ways. Tools: constraints, hashing, audit, transactions"]:::m
  C --> AV["Availability: data is reachable when needed. Tools: backups, replication, patching, DoS defence"]:::m

5.3 Threats and vulnerabilities

A threat is a potential cause of harm (an attacker, malware, a careless insider). A vulnerability is a weakness that a threat can exploit (an unpatched server, a weak password). Risk arises when a threat meets a vulnerability and the asset has value. A countermeasure reduces that risk.

flowchart TD
  TA["Threat agent: external attacker, insider, malware"]:::y --> T["Threat: SQL injection, privilege escalation, data leakage"]
  T --> V["Vulnerability: weak password, unpatched server, misconfiguration"]
  V --> AS["Asset at risk: confidentiality, integrity, availability of data"]:::g
  C["Countermeasures: least privilege, encryption, auditing, patching"]:::m -. blocks .-> V
  C -. detects .-> T

-- VULNERABLE: input is concatenated into the statement
v_sql := 'SELECT * FROM customer WHERE email = ''' || p_email || '''';
EXECUTE IMMEDIATE v_sql;
-- p_email = x' OR '1'='1   returns every customer

-- SAFE: bind variable keeps input as data
EXECUTE IMMEDIATE 'SELECT full_name FROM customer WHERE email = :e'
  INTO v_name USING p_email;

5.4 Authentication versus authorization

sequenceDiagram
  autonumber
  participant U as User
  participant A as Authentication
  participant Z as Authorization
  participant D as Database
  U->>A: Username and password or token
  A->>A: Verify identity
  alt Identity invalid
    A-->>U: Login rejected
  else Identity valid
    A-->>U: Session established
    U->>Z: SELECT salary FROM employee
    Z->>Z: Check privileges and roles
    alt Not permitted
      Z-->>U: Insufficient privileges error
    else Permitted
      Z->>D: Execute query
      D-->>U: Rows returned
    end
  end

5.5 Access control models

GRANT SELECT, UPDATE (status) ON account TO asha;
GRANT SELECT ON account TO ravi WITH GRANT OPTION;
REVOKE UPDATE ON account FROM asha;

flowchart TD
  DBA["Role: DBA, full control"]:::g --> MGR["Role: Branch Manager inherits Teller rights"]:::m
  MGR --> TELLER["Role: Teller"]:::m
  MGR --> AUD["Role: Auditor"]:::m
  TELLER --> P1["Privileges: SELECT and INSERT on transactions"]
  AUD --> P2["Privilege: SELECT on audit_log"]
  U1(["User Asha"]) -.-> TELLER
  U2(["User Ravi"]) -.-> AUD
  U3(["User Meena"]) -.-> MGR

CREATE ROLE teller_role;
GRANT SELECT, INSERT ON acct_transaction TO teller_role;
GRANT teller_role TO manager_role;       -- hierarchy: manager inherits teller
GRANT teller_role TO asha;               -- user gets role

5.6 Countermeasures

-- Views: hide sensitive columns and rows
CREATE VIEW v_emp_public AS
  SELECT emp_id, name, dept_id FROM employees;
GRANT SELECT ON v_emp_public TO hr_clerk;

-- Authentication hardening: lockout and password lifetime
CREATE PROFILE secure_profile LIMIT
  FAILED_LOGIN_ATTEMPTS 5
  PASSWORD_LIFE_TIME   90;
ALTER USER asha PROFILE secure_profile;

-- Auditing
AUDIT SELECT, UPDATE ON account BY ACCESS;

6.1 Block structure

Every PL/SQL program is made of blocks. A block has up to four sections: DECLARE (optional), BEGIN (mandatory), EXCEPTION (optional) and END. Blocks can be nested and can be anonymous or named (procedures, functions, triggers, packages).

flowchart TD
  S(["Block starts"]):::g --> D["DECLARE optional: variables, constants, cursors, user exceptions"]
  D --> B["BEGIN mandatory: executable SQL and PL/SQL statements"]
  B --> Q{"Runtime error raised?"}
  Q -- No --> E(["END"]):::g
  Q -- Yes --> X["EXCEPTION optional: matching WHEN handler runs"]:::y
  X --> E

DECLARE
  v_name  employees.name%TYPE;
  c_bonus CONSTANT NUMBER(4,2) := 0.10;
BEGIN
  SELECT name INTO v_name FROM employees WHERE emp_id = 101;
  DBMS_OUTPUT.PUT_LINE('Hello ' || v_name);
EXCEPTION
  WHEN NO_DATA_FOUND THEN
    DBMS_OUTPUT.PUT_LINE('No such employee');
END;
/

6.2 Variables, constants and data types

%TYPE and %ROWTYPE make code adapt automatically when column definitions change, which is valuable when you normalize or restructure tables.

DECLARE
  r employees%ROWTYPE;
BEGIN
  SELECT * INTO r FROM employees WHERE emp_id = 101;
  DBMS_OUTPUT.PUT_LINE(r.name || ' earns ' || r.salary);
END;
/

6.3 Control structures

DECLARE
  v_sal NUMBER := 52000;
  i     PLS_INTEGER := 1;
  v_tot NUMBER := 0;
BEGIN
  -- IF / ELSIF / ELSE
  IF v_sal >= 80000 THEN
    DBMS_OUTPUT.PUT_LINE('Grade A');
  ELSIF v_sal >= 50000 THEN
    DBMS_OUTPUT.PUT_LINE('Grade B');
  ELSE
    DBMS_OUTPUT.PUT_LINE('Grade C');
  END IF;

  -- CASE
  CASE
    WHEN v_sal > 60000 THEN DBMS_OUTPUT.PUT_LINE('High');
    WHEN v_sal > 30000 THEN DBMS_OUTPUT.PUT_LINE('Medium');
    ELSE DBMS_OUTPUT.PUT_LINE('Low');
  END CASE;

  -- Basic LOOP with EXIT WHEN
  LOOP
    v_tot := v_tot + i;
    i := i + 1;
    EXIT WHEN i > 5;
  END LOOP;

  -- WHILE loop
  WHILE i > 0 LOOP
    i := i - 2;
  END LOOP;

  -- Numeric FOR loop (counter is implicit)
  FOR k IN 1..3 LOOP
    DBMS_OUTPUT.PUT_LINE('k = ' || k);
  END LOOP;
END;
/

6.4 Cursors

A cursor is a pointer to the private work area that holds the rows returned by a query. Implicit cursors are created automatically for every DML statement and single-row SELECT INTO; their attributes are read as SQL%FOUND, SQL%NOTFOUND, SQL%ROWCOUNT. Explicit cursors are declared by you to process multi-row results one row at a time.

sequenceDiagram
  participant P as PL/SQL program
  participant C as Cursor
  participant DB as Database
  P->>C: DECLARE CURSOR c IS SELECT ...
  P->>C: OPEN c
  C->>DB: Parse and execute the query
  DB-->>C: Active set of rows
  loop until c%NOTFOUND
    P->>C: FETCH c INTO variables
    C-->>P: Next row
  end
  P->>C: CLOSE c
  C-->>P: Resources released

-- Implicit cursor attribute after DML
BEGIN
  UPDATE employees SET salary = salary * 1.05 WHERE dept_id = 10;
  DBMS_OUTPUT.PUT_LINE(SQL%ROWCOUNT || ' rows updated');
END;
/

-- Explicit cursor: DECLARE, OPEN, FETCH, CLOSE
DECLARE
  CURSOR c_emp(p_dept NUMBER) IS
    SELECT emp_id, name, salary FROM employees WHERE dept_id = p_dept;
  r c_emp%ROWTYPE;
BEGIN
  OPEN c_emp(10);
  LOOP
    FETCH c_emp INTO r;
    EXIT WHEN c_emp%NOTFOUND;
    DBMS_OUTPUT.PUT_LINE(r.name || ': ' || r.salary);
  END LOOP;
  CLOSE c_emp;
END;
/

-- Cursor FOR loop: opens, fetches and closes automatically
BEGIN
  FOR r IN (SELECT name, salary FROM employees WHERE dept_id = 10) LOOP
    DBMS_OUTPUT.PUT_LINE(r.name || ': ' || r.salary);
  END LOOP;
END;
/

6.5 Stored procedures and functions

A procedure performs an action and may return values through OUT parameters. A function must RETURN one value and can be used inside SQL. Both are stored in the database, compiled once and reused; they also give a controlled access path for security.

CREATE OR REPLACE PROCEDURE raise_salary (
  p_emp_id IN employees.emp_id%TYPE,
  p_pct    IN NUMBER
) AS
BEGIN
  UPDATE employees
     SET salary = salary * (1 + p_pct / 100)
   WHERE emp_id = p_emp_id;
  IF SQL%ROWCOUNT = 0 THEN
    RAISE_APPLICATION_ERROR(-20001, 'Employee not found');
  END IF;
END raise_salary;
/

CREATE OR REPLACE FUNCTION get_balance (p_acct IN NUMBER)
RETURN NUMBER IS
  v_bal account.balance%TYPE;
BEGIN
  SELECT balance INTO v_bal FROM account WHERE account_id = p_acct;
  RETURN v_bal;
EXCEPTION
  WHEN NO_DATA_FOUND THEN RETURN NULL;
END get_balance;
/

-- Calling them
BEGIN raise_salary(101, 5); END;
/
SELECT get_balance(5001) FROM dual;

6.6 Triggers

A trigger is a stored block that Oracle runs automatically when a specified event occurs (DML, DDL or system events). Options: BEFORE/AFTER/INSTEAD OF, FOR EACH ROW (row-level, with :OLD and :NEW) or statement-level.

flowchart TD
  A["DML statement: INSERT, UPDATE or DELETE"]:::g --> B["BEFORE STATEMENT trigger runs once"]
  B --> C["For each affected row: BEFORE ROW trigger"]
  C --> D["Row change applied"]
  D --> E["AFTER ROW trigger"]
  E --> F{"More rows?"}
  F -- Yes --> C
  F -- No --> G["AFTER STATEMENT trigger"]
  G --> H{"Any error raised?"}
  H -- No --> I["Statement completes, commit possible"]:::g
  H -- Yes --> J["Statement rolled back with error"]:::y

-- Business rule: salary may never decrease
CREATE OR REPLACE TRIGGER trg_no_salary_cut
BEFORE UPDATE OF salary ON employees
FOR EACH ROW
BEGIN
  IF :NEW.salary < :OLD.salary THEN
    RAISE_APPLICATION_ERROR(-20002, 'Salary cannot be reduced');
  END IF;
END;
/

-- Keep a denormalized summary column consistent
CREATE OR REPLACE TRIGGER trg_order_total
AFTER INSERT OR DELETE ON order_item
FOR EACH ROW
BEGIN
  IF INSERTING THEN
    UPDATE orders SET total = total + :NEW.qty * :NEW.price WHERE order_id = :NEW.order_id;
  ELSIF DELETING THEN
    UPDATE orders SET total = total - :OLD.qty * :OLD.price WHERE order_id = :OLD.order_id;
  END IF;
END;
/

6.7 Exception handling

When a runtime error occurs, control jumps to the EXCEPTION section. Predefined exceptions have names; user-defined ones are declared and raised by you.

flowchart TD
  A["A statement raises an exception"]:::y --> B{"Handler for it in the current block?"}
  B -- Yes --> C["Run handler, block ends normally"]:::g
  B -- No --> D{"Enclosing block exists?"}
  D -- Yes --> E["Propagate exception to the enclosing block"]
  E --> B
  D -- No --> F["Unhandled: error returned to the caller"]:::y
  C --> G["Execution continues after the block"]

DECLARE
  e_low_balance EXCEPTION;                 -- user-defined
  v_bal NUMBER;
BEGIN
  SELECT balance INTO v_bal FROM account WHERE account_id = 5001;
  IF v_bal < 500 THEN
    RAISE e_low_balance;
  END IF;
  DBMS_OUTPUT.PUT_LINE('OK');
EXCEPTION
  WHEN NO_DATA_FOUND THEN
    DBMS_OUTPUT.PUT_LINE('Account does not exist');
  WHEN e_low_balance THEN
    DBMS_OUTPUT.PUT_LINE('Minimum balance violated');
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE('Error ' || SQLCODE || ': ' || SQLERRM);
    RAISE;                                  -- re-raise to the caller
END;
/

Use RAISE_APPLICATION_ERROR(-20000 … -20999, 'message') to send custom errors to client applications, and PRAGMA EXCEPTION_INIT to give a name to an Oracle error number.

6.8 Packages

A package groups related procedures, functions, variables, cursors and types. It has a specification (public interface) and a body (implementation, plus private items). Benefits: modularity, information hiding, load-once performance and a single object to GRANT EXECUTE on.

CREATE OR REPLACE PACKAGE emp_pkg AS
  PROCEDURE hire (p_name VARCHAR2, p_salary NUMBER);
  FUNCTION  dept_total (p_dept NUMBER) RETURN NUMBER;
END emp_pkg;
/

CREATE OR REPLACE PACKAGE BODY emp_pkg AS
  FUNCTION valid_salary (p_salary NUMBER) RETURN BOOLEAN IS   -- private
  BEGIN
    RETURN p_salary BETWEEN 10000 AND 500000;
  END;

  PROCEDURE hire (p_name VARCHAR2, p_salary NUMBER) IS
  BEGIN
    IF NOT valid_salary(p_salary) THEN
      RAISE_APPLICATION_ERROR(-20003, 'Invalid salary');
    END IF;
    INSERT INTO employees(emp_id, name, salary)
    VALUES (emp_seq.NEXTVAL, p_name, p_salary);
  END;

  FUNCTION dept_total (p_dept NUMBER) RETURN NUMBER IS
    v_total NUMBER;
  BEGIN
    SELECT NVL(SUM(salary), 0) INTO v_total FROM employees WHERE dept_id = p_dept;
    RETURN v_total;
  END;
END emp_pkg;
/

6.9 How PL/SQL connects to security, constraints and normalized design

7.1 Normalization steps

A first draft stores everything in one table, BankFlat, key TxnID:

BankFlat(TxnID, AccountNo, CustName, CustEmail, CustPhones, BranchID,
         BranchName, BranchCity, AccType, Balance, TxnType, TxnAmount, TxnTime)

Business rules: TxnID → AccountNo, TxnType, TxnAmount, TxnTime; AccountNo → CustName, CustEmail, BranchID, AccType, Balance; BranchID → BranchName, BranchCity.

The decomposition is lossless (each split table shares a foreign key that is the key of its parent) and dependency preserving (each FD is contained in one table).

CREATE TABLE branch (
  branch_id   NUMBER PRIMARY KEY,
  branch_name VARCHAR2(60) NOT NULL,
  city        VARCHAR2(40) NOT NULL
);
CREATE TABLE customer (
  customer_id     NUMBER PRIMARY KEY,
  full_name       VARCHAR2(80) NOT NULL,
  email           VARCHAR2(100) NOT NULL UNIQUE,
  phone           VARCHAR2(15),
  national_id_enc RAW(256)                       -- stored encrypted
);
CREATE TABLE employee (
  emp_id    NUMBER PRIMARY KEY,
  branch_id NUMBER NOT NULL REFERENCES branch(branch_id),
  name      VARCHAR2(80) NOT NULL,
  role      VARCHAR2(20) CHECK (role IN ('TELLER','MANAGER','AUDITOR'))
);
CREATE TABLE account (
  account_id   NUMBER PRIMARY KEY,
  customer_id  NUMBER NOT NULL REFERENCES customer(customer_id),
  branch_id    NUMBER NOT NULL REFERENCES branch(branch_id),
  account_type VARCHAR2(10) CHECK (account_type IN ('SAVINGS','CURRENT')),
  balance      NUMBER(14,2) DEFAULT 0 CHECK (balance >= 0),
  status       VARCHAR2(10) DEFAULT 'ACTIVE' CHECK (status IN ('ACTIVE','FROZEN','CLOSED'))
);
CREATE TABLE acct_transaction (
  txn_id       NUMBER PRIMARY KEY,
  account_id   NUMBER NOT NULL REFERENCES account(account_id),
  processed_by NUMBER REFERENCES employee(emp_id),
  txn_type     VARCHAR2(6) CHECK (txn_type IN ('DEBIT','CREDIT')),
  amount       NUMBER(14,2) NOT NULL CHECK (amount > 0),
  txn_time     TIMESTAMP DEFAULT SYSTIMESTAMP
);
CREATE TABLE audit_log (
  audit_id   NUMBER PRIMARY KEY,
  table_name VARCHAR2(30),
  operation  VARCHAR2(10),
  changed_by VARCHAR2(60),
  changed_at TIMESTAMP,
  old_value  VARCHAR2(200),
  new_value  VARCHAR2(200)
);
CREATE SEQUENCE audit_seq;

7.2 Security controls

CREATE ROLE teller_role;
CREATE ROLE manager_role;
CREATE ROLE auditor_role;

-- Tellers see customers through a view without the national ID
CREATE VIEW v_customer_public AS
  SELECT customer_id, full_name, email, phone FROM customer;
GRANT SELECT ON v_customer_public TO teller_role;
GRANT SELECT ON account TO teller_role;

-- Money moves only through the procedure
GRANT EXECUTE ON transfer_funds TO teller_role;

GRANT SELECT ON audit_log TO auditor_role;
GRANT teller_role TO manager_role;           -- role hierarchy
GRANT manager_role TO meena;
GRANT teller_role  TO asha;
GRANT auditor_role TO ravi;

7.3 PL/SQL for secure money transfer

CREATE OR REPLACE PROCEDURE transfer_funds (
  p_from   IN account.account_id%TYPE,
  p_to     IN account.account_id%TYPE,
  p_amount IN NUMBER
) AS
  v_balance account.balance%TYPE;
BEGIN
  IF p_amount IS NULL OR p_amount <= 0 THEN
    RAISE_APPLICATION_ERROR(-20011, 'Amount must be positive');
  END IF;

  -- Lock the source row so that concurrent transfers cannot overdraw it
  SELECT balance INTO v_balance
    FROM account WHERE account_id = p_from AND status = 'ACTIVE' FOR UPDATE;

  IF v_balance < p_amount THEN
    RAISE_APPLICATION_ERROR(-20010, 'Insufficient funds');
  END IF;

  UPDATE account SET balance = balance - p_amount WHERE account_id = p_from;
  UPDATE account SET balance = balance + p_amount WHERE account_id = p_to;

  INSERT INTO acct_transaction (txn_id, account_id, txn_type, amount)
  VALUES (txn_seq.NEXTVAL, p_from, 'DEBIT',  p_amount);
  INSERT INTO acct_transaction (txn_id, account_id, txn_type, amount)
  VALUES (txn_seq.NEXTVAL, p_to,   'CREDIT', p_amount);

  COMMIT;
EXCEPTION
  WHEN NO_DATA_FOUND THEN
    ROLLBACK;
    RAISE_APPLICATION_ERROR(-20012, 'Source account not found or not active');
  WHEN OTHERS THEN
    ROLLBACK;
    RAISE;
END transfer_funds;
/

7.4 Audit and access-control triggers

-- Audit every balance/status change and every delete on ACCOUNT
CREATE OR REPLACE TRIGGER trg_account_audit
AFTER UPDATE OF balance, status OR DELETE ON account
FOR EACH ROW
BEGIN
  INSERT INTO audit_log
    (audit_id, table_name, operation, changed_by, changed_at, old_value, new_value)
  VALUES
    (audit_seq.NEXTVAL, 'ACCOUNT',
     CASE WHEN DELETING THEN 'DELETE' ELSE 'UPDATE' END,
     SYS_CONTEXT('USERENV', 'SESSION_USER'), SYSTIMESTAMP,
     :OLD.balance || '/' || :OLD.status,
     CASE WHEN DELETING THEN NULL ELSE :NEW.balance || '/' || :NEW.status END);
END;
/

-- Access control: block account changes outside business hours
CREATE OR REPLACE TRIGGER trg_block_offhours
BEFORE UPDATE OR DELETE ON account
BEGIN
  IF TO_CHAR(SYSDATE, 'HH24') NOT BETWEEN '09' AND '18' THEN
    RAISE_APPLICATION_ERROR(-20020, 'Account changes allowed only 09:00 to 18:00');
  END IF;
END;
/

FD rules

Closure and key steps

1. result = X; repeat: if A → B and A ⊆ result then result ∪= B; stop when stable.
2. Attributes never on a right side are in every key; test their closure first.
3. Add attributes until closure = R; keep minimal sets; prime = attributes in any key.
4. Canonical cover: split RHS → drop extraneous LHS attributes → drop redundant FDs.

Normal forms

Decomposition tests

Anomalies

Insertion: cannot add a fact alone. Deletion: removing a fact loses another. Update: many rows to change, inconsistency risk.

Security: threat → countermeasure

AuthN = who you are. AuthZ = what you may do. DAC owner decides, MAC labels decide, RBAC roles decide.

PL/SQL syntax quick reference

DECLARE  -- variables, cursors, exceptions
  v x.col%TYPE;  r x%ROWTYPE;  CURSOR c IS SELECT ...;
BEGIN    -- logic
  IF cond THEN ... ELSIF cond THEN ... ELSE ... END IF;
  CASE WHEN cond THEN ... ELSE ... END CASE;
  LOOP ... EXIT WHEN cond; END LOOP;
  WHILE cond LOOP ... END LOOP;
  FOR i IN 1..n LOOP ... END LOOP;
  OPEN c;  FETCH c INTO r;  EXIT WHEN c%NOTFOUND;  CLOSE c;
EXCEPTION
  WHEN NO_DATA_FOUND THEN ...
  WHEN OTHERS THEN ...
END;
/
-- CREATE [OR REPLACE] PROCEDURE p (a IN NUMBER) AS BEGIN ... END;
-- CREATE [OR REPLACE] FUNCTION  f (a IN NUMBER) RETURN NUMBER IS BEGIN ... RETURN x; END;
-- CREATE [OR REPLACE] TRIGGER t BEFORE|AFTER INSERT OR UPDATE ON tbl FOR EACH ROW BEGIN ... END;
-- CREATE [OR REPLACE] PACKAGE pkg AS ... END;  /  PACKAGE BODY pkg AS ... END;