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

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.

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

SN. Category Selection Projection

1. Other Names The selection operation is also known as horizontal The Project operation is also known as
partitioning. 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 mentioned attributes, while discarding other
in the syntax of selection. attributes.
3. Partitioning It partitions the table horizontally. It partitions the table vertically.
4. Which used first The selection operation is performed before The projection operation is performed
projection (if they are to be used together). after selection (if they are to be used
together).
5. Operator Used Select operator is used in Selection Operation. Project operator is used in Projection
Operation.
6. OperatorSymbol Select operator is denoted by Sigma symbol. Project operator is denoted by Pi
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 Statements SELECT, FROM, WHERE SELECT, FROM
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
that are either in R or S or both in R & S. It eliminates the duplicate tuples. It is
denoted by ∪.

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 LOAN_NO
CUSTOMER_NAME ACCOUNT_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
Input:
∏ CUSTOMER_NAME (BORROW) ∪ ∏ CUSTOMER_NAME (DEPOSITOR)

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_DEPT DEPT_NO DEPT_NAME
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:
A Join operation combines related tuples from different relations, if and only if a
given join condition is satisfied. It is denoted by ⋈.

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:

A natural join is the set of tuples of all combinations in R and S that are equal on
their common attribute names. It is denoted by ⋈.

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 BRANCH SALARY
Ram Infosys 10000
Shyam Wipro 20000
Kuber HCL 30000
Hari TCS 50000
EMP_NAME STREET CITY
Ram Civil line Mumbai
Shyam Park street Kolkata
Ravi M.G. Street Delhi
Hari Nehru nagar Hyderabad
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 nagar Hyderabad TCS 50000

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 common attribute names. In the left outer join, tuples in R have no
matching tuples in S. It is denoted by ⟕.

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
equal on their common attribute names. In right outer join, tuples in S have no
matching tuples in R. It is denoted by ⟖.

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
S that have no matching tuples in R in their common attribute name. It is denoted
by ⟗.

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
1 John
2 Harry
 PRODUCT_ID CITY
1 Delhi
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.