What Is an Object-Oriented Database (OODB)?

An object-oriented database (OODB) is a database that combines object-

oriented programming concepts with relational database principles.
It is managed by an object-oriented database management system
(OODBMS). OODBs contain the following elements:

 Objects. The basic building block and an instance of a class. The

type is either built-in or user-defined.
 Classes. A schema or blueprint that defines object structure and
behavior.
 Methods. A blueprint that defines the behavior of a class.
 Pointers. An entity that helps access elements of an object
database. They also help establish relationships between objects.

Object-Oriented Database (OODB) vs. Other Types

of Databases
Object-oriented databases significantly differ from other database types in
their design and functionality. Knowing these differences can help
determine when using an OODB is the best choice. Below is a brief
comparison between OODB and other types of databases.
OODB vs. Relational Databases

The main difference between the two is how the data is structured:

 Relational databases. Data resides in structured tables with rows

and columns. It is queried using SQL, focusing mainly on data
consistency and normalization.
 OODB. Data is stored as a complete and complex object. It supports
complex data types and inheritance. The main focus is to minimize
the difference between a database structure and a programming
language.

OODB vs. Document-Oriented Databases (NoSQL)

A notable difference is in their applicability:

 Document-oriented databases (NoSQL). Data

is unstructured or semi-structured. Caters to various data
models, with a focus on scalability and flexibility.
 OODB. Manages objects with built-in relationships and behaviors.
Ideal for complex data structures or for integration with object-
oriented programming.

OODB vs. Key-Value Databases

The two database types differ in complexity:

 Key-value databases. A simple structure with key-value pairs.

Ideal for lookup tables and data caching, but there is no support for
complex relationships.
  OODB. Supports complex relationships, inheritance, and
encapsulation.

OODB vs. Graph Databases

Relationships are a key difference between these two database types:

 Graph databases. Structured for highly connected data. Uses

edges and nodes to represent relationships between entities.
 OODB. Focuses on objects and their behavior while supporting
relationships, though not as interconnected as graph databases.

Object-Oriented Programming Concepts in Database

Management

Object-oriented databases closely relate to object-oriented programming

(OOP) concepts. The four main features of OOP are:

 Polymorphism.
 Inheritance.
 Encapsulation.
 Abstraction.

These four attributes describe the main characteristics of object-oriented

management systems in general. The sections below explain each of
these concepts in greater depth.

Polymorphism
Polymorphism is the capability of an object to take multiple forms. This
ability allows the same program code to work with different data types.

To illustrate, a Vehicle class can be defined to have a method

called brake() . A Car and a Bike can both inherit from the class and
implement their version of the brake() method. The same method is
applied for different behaviors, resulting in polymorphism.

Inheritance
Inheritance creates a hierarchical relationship between related classes
while making parts of code reusable. Defining new types inherits all the
existing class fields and methods plus further extends them. The existing
class is the parent class, while the child class extends the parent. For
example, a parent class called Vehicle can have child classes such
as Car and Bike . Both child classes inherit information from the parent
class. They also extend the parent class with new information depending
on the methods defined for each vehicle type.

Encapsulation
Encapsulation allows grouping variables and methods into a single
object to create access protection. This process hides information and
details of how an object works from the rest of the code and results in
data and function security.

Classes interact with each other through interface methods without the
need to know how particular methods work.

For example, a Car class can have properties such as color , make ,
and model and methods such as changeColor() . You can change the color of
a car through a method, yet the model and make are not
accessible. Encapsulation bundles all the car information into one entity,
where some elements are modifiable while some are not.

Abstraction
Abstraction is the process of focusing on the essential characteristics to
provide functionality. The process selects vital information while
 unnecessary details stay hidden. Abstraction helps reduce data
complexity and simplifies code reusability. For example, when a web
browser connects to the internet, it doesn't need to know the specific
connection details. Whether the connection is established through Wi-
Fi or Ethernet is irrelevant. The specific connection type is hidden from
the browser to create an abstraction, whereas the various types of
connections represent different implementations of the abstraction.

Features of Object-Oriented Databases

OODB has different features and implementations. Most contain the
attributes described in the table below:

Feature Description

Query Language Finds objects and retrieve data from the database.

Transparent Allows accessing and using data with an object-oriented programming language without
Persistence special handling.

Ensures that ACID transactions, and guarantees all transactions are completed without
ACID Transactions
conflicting changes.

Creates a partial replica of the database in memory. Allows faster access to a database
Database Caching
without reading from disk.

Recovery Provides disaster recovery mechanisms in case of application or system failure.

Object-Oriented Database Management Systems

(OODBMS)
Object-oriented database management systems (OODBMS) integrate
object-oriented principles into a database technology. It enables
developers to use object-oriented languages to manage complex data
models intuitively. The sections below show several notable examples of
OODBMS. Each caters to different platform and application requirements.

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.
1. 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
horizontal partitioning. known as vertical partitioning.
2. Use It is used to choose the subset of tuples from It is used to select certain
the relation that satisfies the given condition required attributes, while
mentioned in the syntax of selection. discarding other 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 Project operator is used in
Used Operation. Projection 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 Project is used to select specific
Selection specific 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)

2. Union Operation:

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

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

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_NA LOAN_N
ME O
CUSTOMER_NA ACCOUNT_
ME NO Jones L-17
Johnson A-101 Smith L-23
Smith A-121 Hayes L-15
Mayes A-321 Jackson L-14
Turner A-176 Curry L-93
Johnson A-273 Smith L-11
Jones A-472 Williams L-17
 Lindsay A-284

∏ CUSTOMER_NAME (BORROW) ∪ ∏ CUSTOMER_NAME (DEPOSITOR)

Input:

Output:

CUSTOMER_NAME
Johnson
Smith
Hayes
Turner
Jones
Lindsay
Jackson
Curry
Williams
Mayes

3. 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

4. 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
5. 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
Input: EMPLOYEE X DEPARTMENT C Legal
Output:

EMP_ID EMP_NAME EMP_DEP DEPT_NO DEPT_NAME

T
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

6. 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)

7. Join operations:

given join condition is satisfied. It is denoted by ⋈.

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

Example: EMPLOYEE SALARY

EMP_CODE EMP_NAME
EMP_CODE SALARY
101 Stephan
101 50000
102 Jack
102 30000
103 Harry
103 25000
Input: Operation: (EMPLOYEE ⋈ SALARY)

Result:
 EMP_CODE EMP_NAME SALARY
101 Stephan 50000
102 Jack 30000
103 Harry 25000
8. Types of Join operations:
The three types of join operations are:- Natural Outer and erui joins.

A. Natural Join:

their common 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

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_NAM BRANCH SALARY
EMP_NA STREET CITY
E
ME
Ram Infosys 10000
Ram Civil line Mumbai
Shyam Wipro 20000
Shyam Park street Kolkata
Kuber HCL 30000
Ravi M.G. Delhi
Hari TCS 50000
Street
Hari Nehru Hyderab
nagar ad
Input: (EMPLOYEE ⋈ FACT_WORKERS)

Output:

EMP_NAM STREET CITY BRANCH SALARY

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

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

matching tuples in S. It is denoted by ⟕.

equal on their common attribute names. In the left outer join, tuples in R have no

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 street Hyderabad TCS 50000
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

matching tuples in R. It is denoted by ⟖.

equal on their common attribute names. In right outer join, tuples in S have no

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 outer join, tuples in R that have no matching tuples in S and tuples in

by ⟗.
S that have no matching tuples in R in their common attribute name. It is denoted

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 street Hyderabad TCS 50000
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

CUSTOMER ⋈ PRODUCT
Input:

Output:

CLASS_ID NAM PRODUCT_ID CITY

E
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.