Chapter 2

QUERY PROCESSING AND OPTIMIZATION

QUERY PROCESSING

Query Processing and Optimization

Query processing and optimization are crucial components of a database management system
(DBMS). They work together to ensure that database queries are executed efficiently,
accurately, and within the expected time frame.

Query Processing

Query Processing Steps

1. Parsing: The query is broken down into smaller components, such as tables, columns, and
conditions.
2. Optimization: The query is analyzed and optimized by considering various factors, such as
the available indexes, statistics, and system resources.
3. Query Rewriting: The query is rewritten to improve performance, such as by reordering
joins or eliminating unnecessary operations.
4. Execution: The optimized query is executed, and the results are returned to the user.

Query Optimization

Query Optimization Techniques

1. Access Path Selection: Choosing the most efficient method to access the required data, such
as using an index or a full table scan.
2. Join Order Optimization: Determining the optimal order in which to join tables, taking into
account factors such as data distribution and indexing.
3. Query Transformation: Modifying the query to reduce overhead, improve parallelism, or
optimize for specific data distributions.
4. Index Selection: Choosing the most effective index for a query, considering factors such as
data distribution, indexing overhead, and query frequency.

Query Optimizer Algorithms

Common Query Optimizer Algorithms

1. Rule-Based Optimizers: Use a set of pre-defined rules to determine the optimal query plan.
2. Cost-Based Optimizers: Use dynamic programming to find the optimal query plan based on
estimated execution costs.
3. Hybrid Optimizers: Combine rule-based and cost-based approaches to improve optimization
performance.
Query Optimization Challenges

Common Challenges in Query Optimization

1. Complexity: Queries with many joins, subqueries, or correlated subqueries can be

challenging to optimize.
2. Data Distribution: Non-uniform data distributions can lead to poor query performance due
to skewed indices or inefficient join orders

2. Statistics: Inaccurate or outdated statistics can lead to suboptimal query plans.

3. Workload Variability: Frequent changes in query load or data distribution can impact query
performance and require adaptive optimization strategies.

The activities involved in parsing, validating, execution and optimizing a query is called Query
Processing. It is the activity performed in extracting data from the database. In query processing, it
takes various steps for fetching the data from the database. The steps involved are:
1. Parsing and translation
2. Evaluation
3. Optimization
Parsing and Translation
As query processing includes certain activities for data retrieval. Initially, the given user queries get
translated in high-level database languages such as SQL. It gets translated into expressions that can be
further used at the physical level of the file system. After this, the actual evaluation of the queries and
a variety of query optimizing transformations and takes place. Thus before processing a query, a
computer system needs to translate the query into a human-readable and understandable language.
Consequently, SQL or Structured Query Language is the best suitable choice for humans. But, it is not
perfectly suitable for the internal representation of the query to the system. Relational algebra is well
suited for the internal representation of a query. The translation process in query processing is similar
to the parser of a query. When a user executes any query, for generating the internal form of the
query, the parser in the system checks the syntax of the query, verifies the name of the relation in the
database, the tuple, and finally the required attribute value. The parser creates a tree of the query,
known as 'parse-tree.' Further, translate it into the form of relational algebra. With this, it evenly
replaces all the use of the views when used in the query. Thus, we can understand the working of a
query processing in the below-described diagram:
Suppose a user executes a query. As we have learned that there are various methods of extracting the
data from the database. In SQL, a user wants to fetch the records of the employees whose salary is
greater than or equal to 10000. For doing this, the following query is undertaken:
Select emp_name from Employee where salary>10000;

SQL QUERIES AND RELATIONAL ALGEBRA

Relational algebra defines the basic set of operations of relational database model. A sequence of
relational algebra operations forms a relational algebra expression. The result of this expression
represents the result of a database query.
The basic operations are:
 Projection
 Selection
 Union
 Intersection
 Minus
 Join
 Rename
1. Projection
Project operation selects (or chooses) certain attributes discarding other attributes. The Project operation
is also known as vertical partitioning since it partitions the relation or table vertically discarding other
columns or attributes.
Notation: πA(R) where ‘A’ is the attribute list, it is the desired set of attributes from the attributes of
relation(R), symbol ‘π(pi)’ is used to denote the Project operator, R is generally a relational algebra
expression, which results in a relation.
Example For example, let us consider the following Student database:
Id_No Name Course Semester Gender
1 Hagos Haile OOP 1 Male
2 Lwam Kebede OOP 1 Female
3 Abadi Desta Advanced DB 2 Male
4 Abebe Tekle Advanced DB 1 Male
5 Aster Ambachew COA 1 Female
If we want to display the names of all students, we will use the following relational algebra expression:
π Name (STUDENT); // select Name from STUDENT;
If we want to display the names and courses of all students, we will use the following relational algebra
expression: π Name, Course (STUDENT); // select Name, Course from STUDENT;
Important points:
1. The Project operation removes duplicate tuples.
2. The Project operation is not commutative, that is :
π Attribute List 1(πAttribute List2(R)) != πAttribute List 2 (πAttribute List1(R))
3. The following expression is valid only if Attribute List 1 is a subset of Attribute List 2.
πAttribute List 1(πAttribute List2(R)) Moreover, writing the above expression is as good as writing the
expression below:
πAttribute List 1(πAttribute List2(R)) = πAttribute List 1 (R)
4. The cardinality (number of tuples) of resulting relation from a Project operation is:
1 <= πA(R) <= |R|
5. The degree (number of attributes) of resulting relation from a Project operation is equal to the
number of attribute in the attribute list ‘A’.
6. In SQL, SELECT DISTINCT query is exactly as same as PROJECT here.

2. Selection
Select operation chooses the subset of tuples from the relation that satisfies the given condition
mentioned in the syntax of selection. The selection operation is also known as horizontal partitioning
since it partitions the table or relation horizontally.
Notation: σ c(R) where ‘c’ is selection condition which is a boolean expression (condition), we can have
a single condition like Id_No = 2 or combination of condition like Course =”OOP” AND Name=”Hagos
Haile”, symbol ‘σ (sigma)’ is used to denote select (choose) operator, R is a relational algebra expression,
whose result is a relation. The boolean expression specified in condition ‘c’ can be written in the
following form:
<attribute name> <comparison operator> <constant value> or <attribute name> where, <attribute name> is
obviously name of an attribute of relation, <comparison operator> is any of the operator {<, >, =, <=,
>=, !=} and, <constant value> is constant value taken from the domain of the relation.

Example-1:

σ Name = “Hagos Haile” or Id_No <= 3 (STUDENT)

σ Course =” Advanced DB”(σSemester= 2(STUDENT))

The query above (immediate) is called nested expression, here, as usual, we evaluate the inner expression
first (which results in relation say Manager1), then we calculate the outer expression on Manager1 (the
relation we obtained from evaluating the inner expression), which results in relation again, which is an
instance of a relation we input.
Example-2:
Given a relation Student (Roll, Name, Class, Fees, and Team) with the following tuples:
Roll Name Department Fees Team
1 Abebe CS 22000 A
2 Kebede CS 34000 A
3 Lwam IT 36000 C
4 Aster IT 56000 D
Select all the student of Team A :
σ Team = 'A' (Student)
This results as follows:
Roll Name Department Fees Team
1 Abebe CS 22000 A
2 Kebede CS 34000 A
Select all the students of department IT whose fees is greater than equal to 10000 and belongs to Team
other than A.
σ Fees >= 10000(σTeam != 'A' (Student))
This results as follows:
Roll Name Department Fees Team
3 Lwam IT 36000 C
4 Aster IT 56000 D
Important points about Select operation: Select operator is Unary, means it it applied to single relation
only. Selection operation is commutative that is,

σ c1(σ c2(R)) = σ c2(σ c1(R))

The degree (number of attributes) of resulting relation from a Selection operation is same as the degree of
the Relation given. The cardinality (number of tuples) of resulting relation from a Selection operation is,
0 <= σ c (R) <= |R|
Difference between Selection and Projection in DBMS

S Category Selection Projection

N.
1. Other Names The selection operation is also known as The Project operation is also known
horizontal partitioning. as vertical partitioning.

2. Use It is used to choose the subset of tuples from the It is used to select certain required
relation that satisfies the given condition attributes, while discarding other
mentioned in the syntax of selection. attributes.

3. Partitioning It partitions the table horizontally. It partitions the table vertically.

4. Which used The selection operation is performed before The projection operation is
first projection (if they are to be used together). performed after selection (if they are
to be used together).
5. Operator Select operator is used in Selection Operation. Project operator is used in Projection
Used Operation.
6. OperatorSym Select operator is denoted by Sigma symbol. Project operator is denoted by Pi
bol symbol.
7. Commutative Selection is commutative. Projection is not commutative.
8. Column Select is used to select all columns of a specific Project is used to select specific
Selection tuple. columns.
9. SQL SELECT, FROM, WHERE SELECT, FROM
Statements
used
Combination of Projection and Selection Operations
For most queries, we need a combination of projection and selection operations. There are two ways to
write these expressions:
i. Using sequence of projection and selection operations: Relational algebra expression using
sequence of projection and selection operations.
π name, team (σ Fees>10000 (Student))
// select name, team from Student where Fees >=10000;
ii. Using rename operation to generate intermediate results: Relational algebra
expression using sequence of projection and selection operations.
Result1:= σ Fees >10000 (Student)
Result2:= π name,team(Result1)
3. Union Operation:

in R or S or both in R & S. It eliminates the duplicate tuples. It is denoted by ∪.

Suppose there are two tuples R and S. The union operation contains all the tuples that are either

Notation: R ∪ S

A union operation must hold the following condition:

 R and S must have the attribute of the same number.

 Duplicate tuples are eliminated automatically.

Example:

DEPOSITOR RELATION BORROW RELATION

CUSTOMER_NAME ACCOUNT_NO CUSTOMER_NAME LOAN_NO

Johnson A-101 Jones L-17
Smith A-121 Smith L-23
Mayes A-321 Hayes L-15
Turner A-176 Jackson L-14
Johnson A-273 Curry L-93
Jones A-472 Smith L-11
Lindsay A-284 Williams L-17

Input: ∏ CUSTOMER_NAME (BORROW) ∪ ∏ CUSTOMER_NAME (DEPOSITOR)

Output:

CUSTOMER_NAME
Johnson
Smith
Hayes
Turner
Jones
Lindsay
Jackson
Curry
Williams
Mayes

4. Set Intersection:

Suppose there are two tuples R and S. The set intersection operation contains all tuples that are in
both R & S. It is denoted by intersection ∩.
Notation: R ∩ S

Example: Using the above DEPOSITOR table and BORROW table

Input: ∏ CUSTOMER_NAME (BORROW) ∩ ∏ CUSTOMER_NAME (DEPOSITOR)

Output:

CUSTOMER_NAME
Smith
Jones

5. Set Difference:

Suppose there are two tuples R and S. The set intersection operation contains all tuples that are in
R but not in S. It is denoted by intersection minus (-).

Notation: R - S

Example: Using the above DEPOSITOR table and BORROW table

Input: ∏ CUSTOMER_NAME (BORROW) - ∏ CUSTOMER_NAME (DEPOSITOR)

Output:

CUSTOMER_NAME
Jackson
Hayes
Willians
Curry
6. Cartesian product

The Cartesian product is used to combine each row in one table with each row in the other table.
It is also known as a cross product. It is denoted by X.

Notation: E X D
Example: EMPLOYEE DEPARTMENT

EMP_ID EMP_NAME EMP_DEPT

1 Smith A DEPT_NO DEPT_NAME
2 Harry C A Marketing
3 John B B Sales
C Legal
Input: EMPLOYEE X DEPARTMENT

Output:

EMP_I EMP_NAME EMP_DEPT DEPT_NO DEPT_NAME

D
1 Smith A A Marketing
1 Smith A B Sales
1 Smith A C Legal
2 Harry C A Marketing
2 Harry C B Sales
2 Harry C C Legal
3 John B A Marketing
3 John B B Sales
3 John B C Legal

7. Rename operation:

The rename operation is used to rename the output relation. It is denoted by rho (ρ).

Example: We can use the rename operator to rename STUDENT relation to STUDENT1.

ρ(STUDENT1, STUDENT)

8. Join operations:

condition is satisfied. It is denoted by ⋈.

A Join operation combines related tuples from different relations, if and only if a given join

Example: EMPLOYEE SALARY

EMP_CODE EMP_NAME
101 Stephan
102 Jack
103 Harry
 EMP_CODE SALARY
101 50000
102 30000

Input: Operation: (EMPLOYEE ⋈ SALARY)

103 25000

Result:

EMP_COD EMP_NAME SALARY

E
101 Stephan 50000
102 Jack 30000
103 Harry 25000
9. Types of Join operations:
The three types of join operations are:- Natural Outer and erui joins.

A. Natural Join:

attribute names. It is denoted by ⋈.

A natural join is the set of tuples of all combinations in R and S that are equal on their common

Example: Let's use the above EMPLOYEE table and SALARY table:

Input: ∏EMP_NAME, SALARY (EMPLOYEE ⋈ SALARY)

Output:

EMP_NAME SALARY
Stephan 50000
Jack 30000
Harry 25000

B. Outer Join:

The outer join operation is an extension of the join operation. It is used to deal with missing
information.

Example:

EMPLOYEE FACT_WORKERS

EMP_NAME STREET CITY EMP_NAME BRANCH SALARY

Ram Civil line Mumbai Ram Infosys 10000
Shyam Park street Kolkata Shyam Wipro 20000
Ravi M.G. Street Delhi Kuber HCL 30000
Hari Nehru nagar Hyderabad Hari TCS 50000

Input: (EMPLOYEE ⋈ FACT_WORKERS)

Output:

EMP_NAME STREET CITY BRANCH SALARY

Ram Civil line Mumbai Infosys 10000
Shyam Park street Kolkata Wipro 20000
Hari Nehru Hyderabad TCS 50000
nagar

An outer join is basically of three types:

I. Left outer join

II. Right outer join
III. Full outer join

I. Left outer join:

Left outer join contains the set of tuples of all combinations in R and S that are equal on their

denoted by ⟕.
common attribute names. In the left outer join, tuples in R have no matching tuples in S. It is

Example: Using the above EMPLOYEE table and FACT_WORKERS table

Input: EMPLOYEE ⟕ FACT_WORKERS

EMP_NAME STREET CITY BRANCH SALARY

Ram Civil line Mumbai Infosys 10000
Shyam Park street Kolkata Wipro 20000
Hari Nehru Hyderabad TCS 50000
street
Ravi M.G. Street Delhi NULL NULL

II. Right outer join:

Right outer join contains the set of tuples of all combinations in R and S that are equal on their

denoted by ⟖.
common attribute names. In right outer join, tuples in S have no matching tuples in R. It is

Example: Using the above EMPLOYEE table and FACT_WORKERS Relation

Input: EMPLOYEE ⟖ FACT_WORKERS

Output:

EMP_NAME BRANCH SALARY STREET CITY

Ram Infosys 10000 Civil line Mumbai
 Shyam Wipro 20000 Park street Kolkata
Hari TCS 50000 Nehru street Hyderabad
Kuber HCL 30000 NULL NULL

III. Full outer join:

Full outer join is like a left or right join except that it contains all rows from both tables. In full

tuples in R in their common attribute name. It is denoted by ⟗.

outer join, tuples in R that have no matching tuples in S and tuples in S that have no matching

Example: Using the above EMPLOYEE table and FACT_WORKERS table

Input: EMPLOYEE ⟗ FACT_WORKERS

Output:

EMP_NAME STREET CITY BRANCH SALARY

Ram Civil line Mumbai Infosys 10000
Shyam Park street Kolkata Wipro 20000
Hari Nehru Hyderabad TCS 50000
street
Ravi M.G. Street Delhi NULL NULL
Kuber NULL NULL HCL 30000

C. Equi join:

It is also known as an inner join. It is the most common join. It is based on matched data as per
the equality condition. The equi join uses the comparison operator (=).

Example:

CUSTOMER PRODUCT

CLASS_ID NAME PRODUCT_ID CITY

1 John 1 Delhi
2 Harry 2 Mumbai
3 Jackson 3 Noida
Input: CUSTOMER ⋈ PRODUCT

Output:

CLASS_ID NAME PRODUCT_ID CITY

1 John 1 Delhi
2 Harry 2 Mumbai
3 Harry 3 Noida
Translating SQL Queries into Relational Algebra

Translating SQL queries into relational algebra involves expressing the query semantics using
operations that align with the relational algebra formalism. Below, I will go through a few SQL
queries and translate them into relational algebra with suitable examples.

Example Schema

Let's consider a simplified database consisting of two tables: Employees and Departments.

Employees Table:

| EmpID | EmpName | DeptID |

|-------|---------|--------|
| 1 | Alice | 101 |
| 2 | Bob | 102 |
| 3 | Carol | 101 |
| 4 | David | 103 |

Departments Table:

| DeptID | DeptName |
|--------|---------------|
| 101 | Engineering |
| 102 | Sales |
| 103 | HR |

Example 1: Simple Selection

SQL Query:

SELECT * FROM Employees WHERE DeptID = 101;

Relational Algebra:

σ(DeptID = 101)(Employees)
Explanation: The selection operator σ is used to filter rows based on the condition DeptID =
101.

Example 2: Projection

SQL Query:

SELECT EmpName FROM Employees;

Relational Algebra:

π(EmpName)(Employees)

Explanation: The projection operator π selects only the EmpName column from the Employees
table.

Example 3: Join Operation

SQL Query:

SELECT EmpName, DeptName

FROM Employees
JOIN Departments ON Employees.DeptID = Departments.DeptID;

Relational Algebra:

π(EmpName, DeptName)(Employees ⨝ Departments)

Explanation: The join operator ⨝ combines rows from both tables based on the matching
DeptID. The projection selects only EmpName and DeptName.

Example 4: Group By and Aggregate

SQL Query:

SELECT DeptID, COUNT(*) AS NumEmployees

FROM Employees
GROUP BY DeptID;
Relational Algebra:

γ(DeptID, COUNT(EmpID) AS NumEmployees)(Employees)

Explanation: The grouping operator γ is used here to group records by DeptID and count the
number of employees in each department.

Example 5: Union

SQL Query:

SELECT EmpName FROM Employees WHERE DeptID = 101

UNION
SELECT EmpName FROM Employees WHERE DeptID = 102;

Relational Algebra:

π(EmpName)(σ(DeptID = 101)(Employees)) ∪ π(EmpName)(σ(DeptID = 102)

(Employees))

Explanation: The union operator ∪ combines the results from the two selection operations
where DeptID is either 101 or 102, projecting the EmpName.

Example 6: Intersection

SQL Query:

SELECT EmpName FROM Employees WHERE DeptID = 101

INTERSECT
SELECT EmpName FROM Employees WHERE EmpName LIKE 'A%';

Relational Algebra:

π(EmpName)(σ(DeptID = 101)(Employees)) ∩ π(EmpName)(σ(EmpName LIKE 'A%')

(Employees))

Explanation: The intersection operator ∩ returns only the employee names that appear in both
sets (Department 101 and names starting with 'A').
Basic Algorithms for Executing Query Operations

Executing query operations in databases generally involves a series of basic algorithms that help
retrieve or manipulate data based on specific conditions. Below, I will outline some of the basic
algorithms commonly used for executing query operations, along with suitable examples.

1. Sequential Search

This is the simplest form of searching in a dataset, where each element is checked until the
desired value is found.

Example:
You have a table of users, and you want to find a user with the name "Alice".

SELECT * FROM users WHERE name = 'Alice';

Internally, a sequential search will iterate through each row in the users table until it finds the
row where the name is "Alice".

2. Binary Search

Binary search is a more efficient search method, but it requires that the data is sorted. It works by
repeatedly dividing the search interval in half.

Example:
Consider a sorted list of user IDs:

SELECT * FROM users ORDER BY user_id; -- Sorted List

To find the user with a specific ID (say 7), the binary search would check the middle of the list.
If the middle ID is less than 7, it would search the upper half; if greater, it would search the
lower half.

3. Indexing

Indexing is a technique that allows fast retrieval of rows in a database. An index is a data
structure (like a B-tree or hash table) that improves the speed of data retrieval operations.
Example:
If you have an index on the name column in the users table, the database engine can directly
locate "Alice" without scanning every row.

CREATE INDEX idx_users_name ON users(name);

SELECT * FROM users WHERE name = 'Alice';

With indexing, the database could quickly navigate to the index and retrieve the relevant rows.

4. Hashing

Hashing involves using a hash function to compute the address of a data element, leading to fast
access times.

Example:
A hash index on a table of products could allow a quick lookup for a product by its SKU (Stock
Keeping Unit).

CREATE INDEX idx_products_sku ON products(sku HASH);

SELECT * FROM products WHERE sku = 'SKU1234';

Instead of searching linearly or using a binary search, the database uses the hash function to find
the correct location of 'SKU1234' in the index.

5. Join Operations

Joining tables is a common operation in relational databases, and there are various algorithms for
this, including nested loop joins, hash joins, and merge joins.

 Nested Loop Join: Go through each row of the first table and for each row, search the
second table.

Example:

SELECT *
FROM users u
JOIN orders o ON u.user_id = o.user_id;

In a nested loop join, for each user, the database will check all orders to find matching user IDs.

 Hash Join: Build a hash table from one of the tables and then probe it for matches.
 Merge Join: Requires both tables to be sorted; it merges them based on matching keys.
6. Projection and Selection

These operations involve filtering and selecting specific columns (projection) or rows (selection)
of the data.

Example:
To get only the names of users:

SELECT name FROM users;

And to filter based on age:

SELECT * FROM users WHERE age > 30;

7. Aggregation

Aggregation functions like SUM, COUNT, AVG, MAX, and MIN are used to summarize data.

Example:
To count how many users are in the database:

SELECT COUNT(*) FROM users;

Using Heuristic in Query Optimization

Using Selectivity and Cost Estimates in Query Optimization
Semantic Query Optimization

Heuristic in Query Optimization

Heuristic query optimization involves employing rules of thumb or practical approaches that help
in generating efficient execution plans for SQL queries without exhaustive searching. In contrast
to cost-based optimization, heuristics are typically faster and less resource-intensive. Here are
some examples of heuristic strategies:

1. Predicate Pushdown: Moving selection operations as close to the data source as possible
(e.g., filtering rows before joining). For example, in a query that selects products with a
price below a certain threshold from a certain category:
 SELECT * FROM Products WHERE category_id = 3 AND price < 100;

A heuristic might first filter the Products table by category_id, reducing the number of rows
in memory for subsequent operations.

 Join Order Optimization: Generally, smaller tables are joined first to reduce the size of
intermediate results. For example, if you have three tables A, B, and C, and B is significantly
smaller than A or C, a heuristic might suggest:

 SELECT * FROM A JOIN B ON A.id = B.a_id JOIN C ON B.id = C.b_id;

Instead of joining A to C first, which could lead to larger intermediate results.

 Materialization: If a subquery is referenced multiple times, it can be beneficial to compute it

once and store the results. For example:

3. WITH Temp AS (
4. SELECT id FROM Orders WHERE order_date > '2023-01-01'
5. )
6. SELECT * FROM Customers WHERE id IN (SELECT customer_id FROM Temp);
7.

A heuristic might determine that it’s more efficient to store Temp and reuse it.

Using Selectivity and Cost Estimates in Query Optimization

Selectivity refers to the fraction of rows returned by a predicate in a SQL statement.

Understanding selectivity helps in estimating the cost of various execution plans. High
selectivity means the predicate will return fewer rows, making the operation cheaper.

1. Selectivity Calculation:
For a table with 10,000 rows, if a specific condition (like salary > 80,000) returns
around 500 rows, the selectivity for that predicate is 500 / 10,000 = 0.05 (or 5%).
2. Cost Estimates:
Cost estimates involve evaluating the resources that will be consumed to execute a query,
such as CPU time, I/O operations, and memory usage. Cost models may consider:
o The number of rows to process based on selectivity.
o Data distribution (e.g., how indexed or clustered the data is).
o Join costs based on how tables are joined (nested loop, hash join, etc.).

Using selectivity, the database optimizer can expect how many rows will likely be processed
under different predicates and choose the most efficient plan. For example, if choosing between:

SELECT * FROM Employees WHERE department_id = 2;

versus

SELECT * FROM Employees WHERE salary > 100000;

If it’s known through statistics that department_id = 2 returns 20% of the data but salary >
100000 returns only 5%, the optimizer might choose the first option for better performance if
index scans are utilized.

Semantic Query Optimization with Suitable Examples

Semantic query optimization aims to improve the execution of a query by leveraging the
semantics or meaning of the data involved, often taking advantage of additional knowledge
beyond what is expressed in the SQL statements. This can include rules about the data
(functional dependencies, constraints) or application-specific knowledge.

1. Redundant Join Removal: If a query can be rewritten semantically without loss of

meaning, it can be optimized. For example, if you have:

SELECT * FROM Customers c JOIN Orders o ON c.id = o.customer_id WHERE o.total

> 100;

If you know that every customer with an order over 100 must exist (due to business logic or
constraints), it might be possible to restructure this:

 SELECT * FROM Customers WHERE id IN (SELECT customer_id FROM Orders WHERE

total > 100);

This can reduce the size of data being processed if enforced correctly.

 Eliminating Unreachable Data: Suppose a table of Employees has a rule that an employee
cannot work in multiple departments:

2. SELECT * FROM Employees WHERE (department_id = 1 OR department_id = 2)

AND department_id != 3;
3.

Knowing the semantic rules could allow the optimizer to identify that if an employee is in
department 1 or 2, they can't be in 3. This means the second condition is always true if
the first condition is true, allowing that part to be dropped or re-evaluated.
4. Utilizing Functional Dependencies: If a database has a profile where employee_id ->
employee_name holds true (functional dependency), the optimizer can recognize that if
there are no changes, retrieving names for employee_ids can be done in a
straightforward way without additional lookups once they're known from earlier joins.