VIEW SYNTAX

1. Creating a View (CREATE VIEW)

CREATE VIEW ViewName [(newColumnName [, . . . ])]

AS subselect [WITH [CASCADED | LOCAL] CHECK OPTION]

2. Create a horizontal view

CREATE VIEW Manager3Staff

AS SELECT *
FROM Staff
WHERE branchNo = ‘B003’;

SELECT * FROM Manager3Staff;

3. Create a vertical view

CREATE VIEW Staff3

AS SELECT staffNo, fName, IName, position, sex
FROM Staff
WHERE branchNo = ‘B003’;

CREATE VIEW Staff3

AS SELECT staffNo, fName, IName, position, sex
FROM Manager3Staff;

4. Grouped and joined views

CREATE VIEW StaffPropCnt (branchNo, staffNo, cnt)

AS SELECT s.branchNo, s.staffNo, COUNT(*)
FROM Staff s, PropertyForRent p
WHERE s.staffNo = p.staffNo
GROUP BY s.branchNo, s.staffNo;
5. Removing a View (DROP VIEW)

DROP VIEW ViewName [RESTRICT | CASCADE]

DROP VIEW Manager3Staff;

6. View Resolution

SELECT staffNo, cnt

FROM StaffPropCnt
WHERE branchNo = ‘B003’
ORDER BY staffNo;

7. Restrictions on Views

SELECT COUNT(cnt)
FROM StaffPropCnt;

SELECT *
FROM StaffPropCnt
WHERE cnt > 2;

8. View Updatability

INSERT INTO StaffPropCnt

VALUES (‘B003’, ‘SG5’, 2);

CREATE VIEW StaffPropList (branchNo, staffNo, propertyNo)

AS SELECT s.branchNo, s.staffNo, p.propertyNo
FROM Staff s, PropertyForRent p
WHERE s.staffNo = p.staffNo;

INSERT INTO StaffPropList

VALUES (‘B003’, ‘SG5’, ‘PG19’);

9. WITH CHECK OPTION

 CREATE VIEW Manager3Staff
AS SELECT *
FROM Staff
WHERE branchNo = ‘B003’
WITH CHECK OPTION;

UPDATE Manager3Staff
SET branchNo = ‘B005’
WHERE staffNo = ‘SG37’;

then the specification of the WITH CHECK OPTION clause in the definition
of the view prevents this from happening, as it would cause the row to migrate
from this horizontal view.

INSERT INTO Manager3Staff

VALUES(‘SL15’, ‘Mary’, ‘Black’, ‘Assistant’, ‘F’, DATE’1967-06-21’, 8000, ‘B002’);

then the specification of WITH CHECK OPTION would prevent the row from being
inserted into the underlying Staff table and immediately disappearing from this view
(as branch B002 is not part of the view).

then this update would fail

10. View Materialization

CREATE VIEW StaffPropRent (staffNo)

AS SELECT DISTINCT staffNo
FROM PropertyForRent
WHERE branchNo = ‘B003’ AND rent > 400;
 1. Immediate: Transactions are processed immediately. If a crash occurs:
Redo: Operations that were committed before the crash will be redone to ensure data integrity.
Undo: Uncommitted operations will be undone to revert to a consistent state.
2. Deferred: Transactions are delayed until a certain point. If a crash occurs:
Redo: Similar to Immediate, committed operations are redone.
Ignore: Operations not yet committed may be ignored since they were not processed.
3. Checkpoint: A recovery point is created. If a crash occurs:
Redo: Operations after the last checkpoint and before the crash that were committed are redone.

Uncommitted operations are undone to the last checkpoint.

The affected operations and objects would depend on the transaction log’s specific entries and the timing of the crash.
Typically, operations related to data modification (insert, update, delete) and objects like tables, records, or indexes are
affected.

1. Immediate: Any changes made by transactions that were committed before the crash will be retained. If a crash occurs after
the commit, there is no need to redo or undo those operations because they are already finalized in the database.
2. Deferred: If the system uses deferred updates, then the changes are not written to the database until after a successful
commit. If a crash happens after the commit, the recovery process will redo the operations to ensure that the committed
transactions are reflected in the database.
3. Checkpoint: A checkpoint is a point of consistency where all prior transactions have been committed. If a crash occurs after
the checkpoint, the recovery process will start from the checkpoint and redo any committed transactions that occurred after it.
For the affected operations and objects:

Redo: All operations that were committed before the crash will be redone. This includes any INSERT, DELETE, or MODIFY
operations associated with committed transactions.
Undo: There would be no undo operations for transactions committed before the crash since the commit indicates that the
transaction has been successfully completed.

In the event of a server crash after a commit:

Redo: Committed transactions are redone to ensure that their effects are reflected in the database.
Undo: Uncommitted transactions are undone to ensure that their effects are not reflected in the database.
The specific operations and objects affected would be listed in the transaction log. Each entry in the log would detail the
actions taken by each transaction, allowing for a precise recovery process.

QUERY OPTIMIZATION

1. Indexes: It evaluates which indexes can be used to speed up the query execution. Indexes allow the DBMS to quickly locate
the rows that satisfy certain conditions. Improve the speed of data retrieval
2. Heuristic optimization - also known as heuristic-based optimization, is an approach to optimization that relies on rules of
thumb, experience, and intuition to guide the search for a solution. Unlike exact optimization methods that guarantee finding
the optimal solution, heuristic optimization techniques aim to find good solutions quickly, especially in situations where
finding the optimal solution is computationally infeasible due to the problem's complexity.
a. Deconstruct the conjunctive selection
b. Move the selection operations down
c. First execute those selections
d. Replace the cartesian product operation, join operation
e. Deconstructive and move the tree down
f. Identify those subtrees whose operations are pipelined.
3. Cost-Based Optimization: Cost-based optimization relies on estimating the cost of executing different query execution plans
and selecting the plan with the lowest estimated cost. The cost is typically based on factors such as disk I/O, CPU usage, and
memory consumption. This approach requires the optimizer to have accurate statistics about the data distribution and the
system resources. Cost-based optimization tends to produce more efficient execution plans compared to rule-based
optimization, especially for complex queries and large databases. Select the one with lowest cost

1. Indexes:

Scenario: In this scenario, suppose both the Orders and Customers tables are quite large, and we frequently query orders
based on the customer's city.
Index Usage: We create an index on the Customers table's city column to speed up the retrieval of customers from a specific
city.
Optimization Impact: By utilizing the index on the city column, the database engine can quickly locate the relevant customer
rows, reducing the overall query execution time.

2. Heuristic Optimization:

Scenario: Suppose our database system uses a rule-based optimization approach.

Heuristic Approach: The optimizer may employ a heuristic approach to determine the join order of the Orders and Customers
tables and the order of applying filter conditions (in this case, filtering by city).
Optimization Impact: By employing heuristics based on common query patterns and best practices, the optimizer can quickly
select a reasonable execution plan without exhaustive search.

3. Cost-Based Optimization:

Scenario: Assume our database system uses a cost-based optimization approach.

Cost Estimation: The optimizer estimates the cost of different execution plans based on factors like disk I/O, CPU usage, and
memory consumption.
Optimization Impact: The optimizer evaluates multiple execution plans, considering the cost associated with each plan. For
example, it might evaluate the cost of joining tables in different orders and applying filter conditions at different stages. The
plan with the lowest estimated cost is chosen for execution, leading to improved query performance.
In this example, each optimization technique plays a crucial role in improving query performance. Indexes enhance data
retrieval efficiency, heuristic optimization quickly selects a reasonable execution plan based on rules of thumb, and
cost-based optimization evaluates and selects the most efficient plan based on cost estimates. Together, these techniques
contribute to optimizing query execution in the database system.