DD MID ANSWERS

1.Define distributed data processing. How does it differ from centralized data
processing?
Distributed data processing refers to the approach of handling and analyzing data
across multiple interconnected devices or nodes. In contrast to centralized data
processing, where all data operations occur on a single, powerful system,
distributed processing decentralizes these tasks across a network of computers.
This method leverages the collective computing power of interconnected devices,
enabling parallel processing and faster data analysis

2. What are some common problem areas in distributed DBMS?

1. Data Consistency
 Consistency vs. Availability: In distributed systems, maintaining data
consistency across nodes while ensuring availability is a wellknown
challenge. When a network partition occurs, ensuring consistency across all
nodes while keeping the system available can be problematic.
  Eventual Consistency: Many distributed systems opt for eventual
consistency (where updates propagate to all nodes eventually), but this can
lead to temporary discrepancies in data views across different nodes.
2. Latency
 Geographical Distribution: Data spread across geographically distant
locations can result in higher network latency, affecting response times and
the performance of real-time applications.
 Communication Delays: Synchronizing data between nodes requires
frequent communication, which introduces delays.
3. Data Partitioning
 Sharding and Partitioning Strategies: Partitioning data across
nodes(sharding) can lead to uneven data distribution, "hot spots," or issues
with accessing related data stored on different nodes.
 Cross-partition Queries: Queries that span multiple partitions are more
complex and take longer to process than those within a single partition.
4. Data Replication
 Replication Lag: Replicating data across multiple nodes or regions can
introduce lag, leading to nodes having outdated copies of the data
temporarily.
 Synchronization Issues: Keeping replicated data synchronized in real-time
across multiple nodes is technically challenging and can lead to conflicts.
5. Fault Tolerance and Recovery
 Network Partitions: When network failures occur, maintaining availability
while dealing with potentially inconsistent data across nodes becomes
difficult.
 Node Failures: Handling node failures gracefully, ensuring that data is not
lost, and that the system can recover without significant downtime is a
critical issue.
6. Concurrency Control
  Locking and Deadlocks: Managing concurrent operations across distributed
nodes can lead to complex locking mechanisms and potential deadlocks.
 Concurrency Conflicts: Ensuring data integrity during concurrent
transactions across multiple nodes often leads to conflicts that need
resolution, such as through the use of distributed locking or conflict
resolution algorithms.

7. Security
 Data Encryption and Security: Ensuring that data is encrypted both at rest
and in transit across multiple locations adds complexity.
 Access Control: Ensuring that only authorized users can access and modify
data across distributed locations is more difficult to enforce.

8. Scalability
 Dynamic Scaling: While distributed databases are designed to be scalable,
dynamically adding or removing nodes, redistributing data, and managing
the resulting load balancing can be a complex task.
 Load Balancing: Distributing traffic and queries evenly across all nodes is a
significant challenge, especially in large-scale systems.

9. Cost
 Higher Infrastructure Costs: Operating and maintaining distributed
databases often require more resources, including hardware, storage,
network bandwidth, and engineering expertise.
 Overhead from Redundancy: Data redundancy (e.g., replication) across
multiple nodes increases storage and operational costs.
3. What is the difference between a homogeneous and heterogeneous
distributed database system?

Homogeneous Distributed Heterogeneous Distributed

Feature
Database System Database System

A distributed database system A distributed database system

Definition where all nodes use the same where different nodes may use
DBMS and schema. different DBMS and schemas.

Uses the same type of Uses different types of database

DBMS Type database management system management systems at different
across all locations. locations.

The schema structure is Different databases may have

Schema
identical across all databases. different schemas and structures.

Can have different data models

Data Model Follows a uniform data model. (e.g., relational, hierarchical,
NoSQL).

Complex, as query translation

Query Easier, as all databases follow
may be needed between
Processing the same query language.
different DBMS.

Data Integration Seamless integration since all Requires data transformation

nodes follow the same due to schema differences.
 Homogeneous Distributed Heterogeneous Distributed
Feature
Database System Database System

schema and format.

Simple communication More complex communication

Communication between nodes as they use due to different database
the same protocol. protocols.

A company using Oracle DBMS A company using MySQL in one

Example
in all its offices globally. office and MongoDB in another.

4. Explain the concept of fragmentation in distributed database design. What

are the types of fragmentation?
(refer unit pdf for example) or (https://www.geeksforgeeks.org/fragmentation-
in-distributed-dbms/)
Fragmentation –
In this approach, the relations are fragmented (i.e., they’re divided into smaller
parts) and each of the fragments is stored in different sites where they’re
required. It must be made sure that the fragments are such that they can be used
to reconstruct the original relation (i.e, there isn’t any loss of data).Fragmentation
is advantageous as it doesn’t create copies of data, consistency is not a problem.
In the fragmentation process, let’s say, If a table T is fragmented and is divided
into a number of fragments say T1, T2, T3….TN. The fragments contain sufficient
information to allow the restoration of the original table T. This restoration can be
done by the use of UNION or JOIN operation on various fragments. This process is
called data fragmentation. All of these fragments are independent which means
these fragments can not be derived from others. The users needn’t be logically
concerned about fragmentation which means they should not concerned that the
data is fragmented and this is called fragmentation Independence or we can
say fragmentation transparency.

Fragmentation of relations can be done in two ways:

1.Horizontal fragmentation – Splitting by rows
Horizontal fragmentation refers to the process of dividing a table horizontally by
assigning each row (or a group of rows) of relation to one or more fragments.
These fragments can then be assigned to different sites in the distributed system.
Some of the rows or tuples of the table are placed in one system and the rest are
placed in other systems. The rows that belong to the horizontal fragments are
specified by a condition on one or more attributes of the relation.

2.Vertical fragmentation – Splitting by columns

Vertical fragmentation refers to the process of decomposing a table vertically by
attributes or columns. In this fragmentation, some of the attributes are stored in
one system and the rest are stored in other systems. This is because each site
may not need all columns of a table. In order to take care of restoration, each
fragment must contain the primary key field(s) in a table. The fragmentation
should be in such a manner that we can rebuild a table from the fragment by
taking the natural JOIN operation and to make it possible we need to include a
special attribute called Tuple-id to the schema.

3.Mixed Fragmentation
The combination of vertical fragmentation of a table followed by further
horizontal fragmentation of some fragments is called mixed or hybrid
fragmentation. For defining this type of fragmentation, we use the SELECT and
the PROJECT operations of relational algebra. In some situations, the horizontal
and the vertical fragmentation isn’t enough to distribute data for some
applications and in those conditions, we need a fragmentation called a mixed
fragmentation.

5. What are the main distribution design issues to consider in a distributed

DBMS?
Several key issues need to be addressed to ensure optimal performance,
scalability, and reliability. These are collectively referred to as distribution design
issues. Below is an overview of the primary concerns and considerations:
1. Data Fragmentation
Dividing the database into smaller pieces (fragments or shards) that can be
distributed across multiple nodes.
Types of Fragmentation:
 Horizontal Fragmentation: Divides data into subsets of rows (tuples) based
on a condition (e.g., by region or department).
 Vertical Fragmentation: Divides data into subsets of columns (attributes),
often based on access patterns.
 Mixed Fragmentation: Combines horizontal and vertical fragmentation.
Challenges:
 Identifying which fragments are accessed together.
 Balancing fragmentation granularity (too fine vs. too coarse).

2. Data Replication
Making copies of data (replicas) and storing them on multiple nodes for
availability and fault tolerance.

Types of Replications:
  Full Replication: Entire database is replicated on all nodes.
 Partial Replication: Only some fragments are replicated on select nodes.
 No Replication: Each fragment is stored on only one node.
Challenges:
 Deciding which data to replicate and where.
 Managing consistency between replicas (e.g., eventual consistency vs.
strong consistency).
 Balancing the trade-offs between replication overhead and availability.

3. Data Allocation
Determining which fragments or replicas are stored on which nodes in the system.
Strategies:
 Centralized: All data is stored on a single node (rare in distributed systems).
 Decentralized: Data is distributed across multiple nodes based on
predefined rules.
 Dynamic Allocation: Data placement changes dynamically based on
workload or access patterns.
Challenges:
 Minimizing data movement between nodes during queries.
 Balancing load across nodes to avoid bottlenecks.
 Considering geographic location for latency optimization.

4. Query Processing and Optimization

Executing queries efficiently in a distributed environment.
Challenges:
 Identifying the location of the required data (fragments and replicas).
 Minimizing data transfer between nodes.
  Optimizing query execution plans to reduce latency and improve
performance.
 Handling distributed joins and aggregations efficiently.

5. Transaction Management
Ensuring ACID (Atomicity, Consistency, Isolation, Durability) properties for
transactions in a distributed environment.
Challenges:
 Managing distributed transactions across multiple nodes.
 Handling failures during transactions to maintain atomicity and consistency.
 Deciding on a concurrency control mechanism (e.g., locking, timestamp
ordering).
 Using distributed commit protocols like Two-Phase Commit (2PC) or Three-
Phase Commit (3PC).

6. Explain the characteristics of a query processor and its role in database

management.
The characterization of query processors refers to how query processors are
classified, structured, and evaluated based on their functionality, architecture, and
performance.
Query processors are essential components of systems like search engines,
database management systems (DBMS), or natural language processing (NLP)
platforms.
Below are some key aspects of how query processors can be characterized:
1. Based on Query Processing Functionality
Query Parsing:
Converts the user query into a structured format for analysis.
For example:
 In databases: Converts SQL queries into execution plans.
 In search engines: Translates natural language into tokens or search
expressions.
Query Optimization:
Improves the efficiency of query execution by determining the most efficient
strategy to retrieve data.
Examples include:
 Using indexes in DBMS.
 Optimizing query terms for better search results in search engines.
Query Execution:
Handles the actual retrieval of data or execution of the query plan.
This involves:
 Accessing relevant databases or indexes.
 Applying ranking or sorting algorithms to results.

2. Based on Input Type

Structured Queries:
Process queries written in structured languages like SQL.Often used in relational
databases or knowledge graphs.
Unstructured Queries:
Handle free-form text or natural language input. Common in search engines or
NLP-based systems.
Hybrid Queries:
Combine structured and unstructured query processing.
For example: "Find all articles written by John after 2020" combines structured
filters with unstructured text search.
3. Based on Architecture
Centralized Query Processors:
 Operate on a single database or a local system.
 Simpler architecture but limited scalability.
Distributed Query Processors:
 Process queries across multiple nodes or distributed databases.
 Used in large-scale systems like Hadoop or Spark.
Federated Query Processors:
 Query across heterogeneous systems without central data integration.
 Common in scenarios involving multiple, independent databases.
4. Based on Processing Paradigm
Batch Query Processors:
Process queries in bulk, often in a time-insensitive manner.
Examples: Data warehousing, analytics systems.
Real-Time Query Processors:
Process queries with low latency, often in real-time or near real-time.
Examples: Online search engines, recommendation systems.

5. Based on Optimization Techniques

Cost-Based Optimizers:
Use cost metrics (e.g., disk I/O, CPU time) to choose the best execution plan.
Common in relational database systems.
Heuristic-Based Optimizers:
Rely on predefined rules or heuristics to optimize queries quickly.
Often used for simpler systems where cost models are unnecessary.
AI/ML-Based Optimizers:
Leverage machine learning models to improve query optimization.
Used in advanced or experimental database systems.
6. Based on Use Case
Database Query Processors:
Designed to interact with structured databases like MySQL, PostgreSQL, or
MongoDB. Focus on data retrieval, manipulation, and transaction management.
Search Query Processors:
Handle text-based or semantic search queries in systems like Google,
Elasticsearch, or Solr. Emphasize relevance ranking, indexing, and content
matching.
Natural Language Query Processors:
Interpret and process queries written in human language. Found in virtual
assistants, chatbots, and NLP systems.
Big Data Query Processors:
Handle large-scale queries in distributed frameworks like Hadoop, Hive, or Spark
SQL. Focus on parallelism and scalability.

7. Based on Performance Metrics

Response Time:
How quickly the processor returns results.
Throughput:
Number of queries the system can handle per unit of time.
Scalability:
Ability to handle increased data size or query volume.
Accuracy and Relevance:
For search systems, how well results match the user's intent.
Resource Utilization:
Efficiency of CPU, memory, and storage use during query processing.
8. Based on Query Complexity
Simple Query Processors:
Handle straightforward queries (e.g., single-table lookups or keyword searches).
Complex Query Processors:
Handle multi-table joins, nested queries, or advanced filters. Examples include
graph queries, machine learning model predictions, or deep NLP queries.

Importance of Query Processor in DBMS

 Improves database efficiency and speed.
 Ensures query correctness through parsing and validation.
 Optimizes resource utilization for faster execution.
 Provides a user-friendly interface for interacting with databases.

7. Illustrate main layers of query processing.

Main layers of Query Processing
Query processing involves 4 main layers:
• Query Decomposition
• Data Localization
• Global Query Optimization
• Distributed Execution

• The input is a query on global data expressed in relational calculus. This

query is posed on global (distributed) relations, meaning that data
distribution is hidden.
• The first three layers map the input query into an optimized distributed
query execution plan. They perform the functions of query decomposition,
data localization, and global query optimization.
• Query decomposition and data localization correspond to query rewriting.
 • The first three layers are performed by a central control site and use
schema information stored in the global directory.
• The fourth layer performs distributed query execution by executing the
plan and returns the answer to the query. It is done by the local sites and
the control site.
1.Query Decomposition:
 First, the calculus query is rewritten in a normalized form that is suitable
for subsequent manipulation.
 Second, the normalized query is analyzed semantically so that incorrect
queries are detected and rejected as early as possible.
 Third, the correct query is simplified. One way to simplify a query is to
eliminate redundant predicates.
 Fourth, the calculus query is restructured as an algebraic query. Several
algebraic queries can be derived from the same calculus query, and that
some algebraic queries are “better” than others. The quality of an algebraic
query is defined in terms of expected performance.
2. Data Localization:
 Output of the first layer is an algebraic query on distributed relations which
is input to the second layer.
 The main role of this layer is to localize the query’s data using data
distribution information.
 We know that relations are fragmented and stored in disjoint subsets, called
fragments where each fragment is stored at different site.
 This layer determines which fragments are involved in the query and
transforms the distributed query into a fragment query.
 Fourth, the calculus query is restructured as an algebraic query. Several
algebraic queries can be derived from the same calculus query, and that
some algebraic queries are “better” than others. The quality of an algebraic
query is defined in terms of expected performance.
3. Global Query Optimization:
The input to the third layer is a fragment algebraic query.
The goal of this layer is to find an execution strategy for the algebraic fragment
query which is close to optimal.
Query optimization consists of
• Finding the best ordering of operations in the fragment query,
• Finding the communication operations which minimize a cost function.
The cost function refers to computing resources such as disk space, disk I/Os,
buffer space, CPU cost, communication cost, and so on.
Query optimization is achieved through the semi-join operator instead of join
operators.
4. Distributed Execution:
Distributed Query Optimization (DQO) refers to the process of optimizing queries
that involve data distributed across multiple locations, systems, or nodes in a
distributed database environment.
The goal is to minimize the cost of executing the query, which could involve
• Reducing communication overhead
• Data transfer
• Disk I/O, or computation time.

8. Elaborate the concept of query processing in SQL.

Query processing in SQL refers to the sequence of steps involved in translating,
optimizing, and executing an SQL query to retrieve or manipulate data from a
database efficiently. The goal of query processing is to transform a high-level SQL
query into an optimized execution plan that the database engine can efficiently
run.
Steps in Query Processing
1. Query Parsing
o The SQL query is checked for syntax errors (e.g., missing keywords or
incorrect clauses).
o A parse tree is generated to represent the logical structure of the
query.
o If errors exist, the query is rejected with an error message.
2. Query Translation
o The parsed query is converted into relational algebra expressions.
o This helps the database understand the query in a format that can be
optimized.
o Example: SELECT * FROM Employees WHERE salary > 50000;
 Converts to: σ_salary > 50000 (Employees) (Selection
operation in relational algebra).
3. Query Optimization
o The system generates multiple query execution plans and selects the
most efficient one.
o Techniques used:
 Indexing (to speed up search operations).
 Join optimization (choosing the best algorithm for joining
tables).
 Rearranging query execution order to reduce computation
cost.
o The goal is to minimize CPU, memory, and disk I/O usage.
4. Query Execution Plan Generation
 o The optimized query is converted into a physical execution plan (low-
level operations).
o This includes specific steps like table scans, index lookups, sorting,
and joins.
5. Query Execution
o The database engine executes the query using the selected execution
plan.
o Data retrieval or modification takes place.
o The result set is sent back to the user.
6. Result Presentation
o The final query output is formatted and displayed to the user.
o Example: If the query is SELECT name FROM Employees WHERE
salary > 50000; the names of employees meeting the condition are
returned.
9. What are the main distribution design issues to consider in a distributed
DBMS?
(Same as 5th question)

10. Briefly describe at least two algorithms used for distributed query
optimization. Highlight their advantages and limitations.
Algorithms aim to minimize costs (e.g., communication, computation, and storage
costs) while ensuring timely and accurate results. Below are the main algorithms
and strategies used in distributed query optimization:
1. Dynamic Programming-Based Algorithms
Description:
These algorithms systematically evaluate all possible query execution plans and
select the one with the lowest cost.
Typically used for optimizing joins.
Explores join orders (e.g., left-deep, right-deep, bushy trees).
Algorithm Steps:
Generate all possible query plans.
Estimate the cost of each plan (e.g., communication, I/O, CPU).
Choose the plan with the minimum cost.
Advantages:
Produces an optimal plan for small queries.
Disadvantages:
Computationally expensive for large queries (exponential complexity).
Example: Optimize SELECT * FROM A, B, C WHERE A.id = B.id AND B.id = C.id by
evaluating all possible join orders
2. Greedy Algorithms
Description:
These algorithms iteratively build a query execution plan by choosing the best
option at each step (locally optimal choices).
Unlike dynamic programming, greedy algorithms don't backtrack to reconsider
earlier decisions.
Algorithm Steps:
Start with the smallest subquery or data fragment.
Choose the next operation or join that has the lowest incremental cost.
Repeat until the full query is processed.
Advantages:
Simple and efficient for queries with many fragments.
Disadvantages:
May result in suboptimal plans due to lack of global optimization.
Example: Join the two smallest tables first and proceed iteratively.
3. Cost-Based Algorithms
Description:
These algorithms evaluate the cost of different execution plans based on a cost
model that considers:
Communication cost (data transfer between nodes).
Computation cost (CPU time for joins, filters, etc.).
Disk I/O cost (reading/writing data to/from disk).
Algorithm Steps:
Estimate the cost of executing each operation on each node.
Generate alternative plans for query execution.
Select the plan with the lowest estimated cost.
Advantages:
Produces high-quality plans for small to medium queries.
Disadvantages:
Requires accurate cost models, which can be challenging in dynamic
environments.
Example: Use a cost model to decide whether to ship data from Node A to Node B
for a join or to process it locally.

4. Parallel Processing Algorithms

Description:
These algorithms optimize queries for parallel execution across multiple nodes,
aiming to maximize throughput and minimize query latency.
Key Techniques:
Partitioned Parallelism: Divide data into partitions and process them
independently across nodes.
Pipelined Parallelism: Overlap different stages of query execution across nodes.
Advantages:
Exploits the full computational power of distributed systems.
Disadvantages:
Requires careful coordination and scheduling.
Example: Execute a query with a GROUP BY clause by partitioning the data based
on the grouping key and processing each partition in parallel.
5. Iterative Improvement Algorithms
Description:
These algorithms start with an initial query execution plan and iteratively refine it
by making incremental changes to reduce the cost.
Algorithm Steps:
Generate an initial plan (e.g., using heuristics).
Modify the plan (e.g., reorder joins, change data distribution).
If the modified plan has a lower cost, update the current plan.
Repeat until no further improvements can be made.
Advantages:
Simple to implement.
Disadvantages:
May converge to a local minimum rather than a global minimum.
Example: Start with a left-deep join plan and refine it to a bushy tree plan to
reduce execution costs.

11. Write syntax and give necessary examples for DDL Commands.
DDL Commands:
1. Create
2. Alter
3. truncate
4. drop
5. Rename
1.CREATE:
This command is used to create a new table in SQL.
The user has to give information like table name, column names, and their
datatypes.
Syntax –
CREATE TABLE table_name
(
column_1 datatype,
column_2 datatype,
column_3 datatype);
Example –
We need to create a table for storing Student information of a particular
College. Create syntax would be as below.
CREATE TABLE Student_info
(
College_Id number(2),
College_name varchar(30),
Branch varchar(10)
);
2.ALTER:
This command is used to add, delete or change columns in the existing table.
The user needs to know the existing table name and can do add, delete or
modify tasks easily.
Add column in table
Syntax–
Syntax to add a column to an existing table.
ALTER TABLE table_name
ADD column_name datatype;
Example–
In our Student_info table, we want to add a new column for CGPA. The
syntax would be as below as follows.
ALTER TABLE Student_info ADD CGPA number;
Add multiple columns in table
ALTER TABLE customers
ADD (customer_name varchar2(45),
city varchar2(40) DEFAULT 'Seattle');
Modify column in table
Syntax
To MODIFY A COLUMN in an existing table, the Oracle ALTER TABLE
syntax is:
ALTER TABLE table_name
MODIFY column_name column_type;
For example:
ALTER TABLE customers
MODIFY customer_name varchar2(100) NOT NULL;
Modify Multiple columns in table
Syntax
To MODIFY MULTIPLE COLUMNS in an existing table, the Oracle
ALTER TABLE syntax is:
ALTER TABLE table_name
MODIFY (column_1 column_type,
column_2 column_type,
...
column_n column_type);
Example
Let's look at an example that shows how to modify multiple columns in an
Oracle table using the ALTER TABLE statement.
For example:
ALTER TABLE customers
MODIFY (customer_name varchar2(100) NOT NULL,
city varchar2(75) DEFAULT 'Seattle' NOT NULL);
Drop column in table
Syntax
To DROP A COLUMN in an existing table, the Oracle ALTER TABLE
syntax
ALTER TABLE table_name
DROP COLUMN column_name;
Example
Let's look at an example that shows how to drop a column in an Oracle table
using the ALTER TABLE statement.
For example:
ALTER TABLE customers
DROP COLUMN customer_name;
Rename column in table
Syntax
To RENAME A COLUMN in an existing table, the Oracle ALTER TABLE
syntax is:
ALTER TABLE table_name
RENAME COLUMN old_name TO new_name;
Example
Let's look at an example that shows how to rename a column in an Oracle
table using the ALTER TABLE statement.
For example:
ALTER TABLE customers
RENAME COLUMN customer_name TO cname;
Command-3 :
TRUNCATE :
This command is used to remove all rows from the table, but the structure of
the table still exists.
Syntax –
Syntax to remove an existing table.
TRUNCATE TABLE table_name;
Example –
The College Authority wants to remove the details of all students for new
batches but wants to keep the table structure. The command they can use is as
follows.
TRUNCATE TABLE Student_info;
Command-4 :
DROP :
This command is used to remove an existing table along with its structure
from the Database.
Syntax –
Syntax to drop an existing table.
DROP TABLE table_name;
Example –
If the College Authority wants to change their Database by deleting the
Student_info Table.
DROP TABLE Student_info;
Command -5
RENAME:
It is possible to change name of table with or without data in it using simple
RENAME command.
We can rename any table object at any point of time.
Syntax –
RENAME TABLE <Table Name> To <New_Table_Name>;
Example:
If you want to change the name of the table from Employee to Emp we can
use rename command as
RENAME TABLE Employee To EMP;
12. Write syntax and give necessary examples for DML Commands.
Data Manipulation Language (DML)
Data Manipulation Language (DML) commands in Oracle are used to manage
and interact with data in a database. Some examples of DML commands in
Oracle include:
INSERT: Adds rows to an existing table
UPDATE: Updates data in an existing table
DELETE: Deletes rows from a table
SELECT: Accesses data in a database
INSERT
The INSERT statement adds rows to an existing table. For example, you can
use the INSERT statement to add a row to an employee table.
Inserting a single record using the Values keyword
1. INSERT INTO table (column1, column2, ... column_n ) VALUES
(expression1, expression2, ... expression_n );
2. INSERT INTO table VALUES (expression1, expression2, ...
expression_n );
Using INSERT ALL (Preferred for inserting multiple different rows)
INSERT ALL
INTO employees (id, name, salary) VALUES (101, 'Alice', 50000)
INTO employees (id, name, salary) VALUES (102, 'Bob', 55000)
INTO employees (id, name, salary) VALUES (103, 'Charlie', 60000)
SELECT * FROM dual;
UPDATE
The UPDATE statement updates data in an existing table. You can use the
UPDATE statement to update one or more columns.
Updating a Student's Grade
UPDATE students
SET grade = 10
WHERE student_id = 101;
Updating Multiple Fields at Once
UPDATE students
SET name = 'Alicia', email = 'alicia@email.com'
WHERE student_id = 101;
DELETE
The DELETE statement deletes rows from a table. If you don't use the WHERE
clause, the DELETE statement deletes all rows in the table.
Deleting a Record
DELETE FROM grades
WHERE student_id = 101 AND subject = 'Math';
Deleting All Records from a Table
DELETE FROM students;
SELECT
The SELECT statement accesses data in a database. You can use the SELECT
statement to manipulate the accessed data before returning the results.