0% found this document useful (0 votes)
38 views57 pages

Adbms All

Uploaded by

patelpreksha1725
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
38 views57 pages

Adbms All

Uploaded by

patelpreksha1725
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 57

NAME:-PREKSHA ASHOK PATEL

SAPID:-60004210126

BRANCH:-COMPUTER ENGINEERING

DIV:-C2 ; BATCH:-1

ADBMS
EXPERIMENT-02

AIM: STIMULATE QUERY OPTIMISATION BY APPLYING SQL QUERY ON YOUR SELECTED DATABASE.

THEORY:
QUERY:

Renamed employee table as preksha

QUERY TIME OF EXECUTION


SELECT AND select first_name from 0.015 s
WHERE QUERY preksha;
SELECT
first_name,last_name
FROM preksha
WHERE first_name LIKE
'P%';
AGGREGATE SELECT AVG(salary) AS
FUNCTION QUERY average_salary
FROM salaries;

1.234s
ORDER BY SELECT * FROM
SALARIES ORDER BY
SALARY ASC;

1.171 s

NESTED QUERY SELECT emp_no,


first_name, last_name, 0.235s
hire_date,birth_date
FROM preksha
WHERE emp_no IN (
SELECT emp_no
FROM salaries
WHERE hire_date >
'1960-06-24'
AND salary > 35000
)
ORDER BY hire_date
DESC
JOIN QUERY SELECT
preksha.first_name,
preksha.last_name,
dept_emp.dePt_no,pre
ksha.emp_no,preksha.b
irth_date,departments.
dept_name
FROM dept_emp
LEFT JOIN preksha ON
preksha.emp_no =
dept_emp.emp_no
JOIN departments ON
departments.dept_no =
dept_emp.dept_no
ORDER BY
preksha.last_name 1.985 s
DESC

OPTIMIZE TABLE

COMMAND RUN

QUERY TIME OF EXECUTION


SELECT AND select first_name from 0.016 s
WHERE QUERY preksha;
SELECT
first_name,last_name
FROM preksha
WHERE first_name LIKE
'P%';

AGGREGATE SELECT AVG(salary) AS


FUNCTION QUERY average_salary
FROM salaries;
2.891

ORDER BY SELECT * FROM


SALARIES ORDER BY
SALARY ASC;

1.765 s

NESTED QUERY SELECT emp_no,


first_name, last_name, 0.921s
hire_date,birth_date
FROM preksha
WHERE emp_no IN (
SELECT emp_no
FROM salaries
WHERE hire_date >
'1960-06-24'
AND salary > 35000
)
ORDER BY hire_date
DESC
JOIN QUERY SELECT
preksha.first_name,
preksha.last_name,
dept_emp.dePt_no,pre
ksha.emp_no,preksha.b
irth_date,departments.
dept_name
FROM dept_emp
LEFT JOIN preksha ON
preksha.emp_no =
dept_emp.emp_no
JOIN departments ON
departments.dept_no =
dept_emp.dept_no
ORDER BY
preksha.last_name 2.110 s
DESC

INDEXING:

QUERY TIME OF EXECUTION


SELECT AND select first_name from 0.094 s
WHERE QUERY preksha;
SELECT
first_name,last_name
FROM preksha
WHERE first_name LIKE
'P%';
AGGREGATE SELECT AVG(salary) AS
FUNCTION QUERY average_salary
FROM salaries;

3.219 s
ORDER BY SELECT * FROM
SALARIES ORDER BY
SALARY ASC;

1.687 s
NESTED QUERY SELECT emp_no,
first_name, last_name, 0.547s
hire_date,birth_date
FROM preksha
WHERE emp_no IN (
SELECT emp_no
FROM salaries
WHERE hire_date >
'1960-06-24'
AND salary > 35000
)
ORDER BY hire_date
DESC

JOIN QUERY SELECT


preksha.first_name,
preksha.last_name,
dept_emp.dePt_no,pre
ksha.emp_no,preksha.b
irth_date,departments.
dept_name
FROM dept_emp
LEFT JOIN preksha ON
preksha.emp_no =
dept_emp.emp_no
JOIN departments ON
departments.dept_no =
dept_emp.dept_no
ORDER BY
preksha.last_name
DESC

1.953 s

CONCLUSION:- Thus stimulated query optimisation by applying SQL query on seleceted


database of employees,by 3 ways unoptimized ,optimised and indexing query.
NAME:- PREKSHA ASHOK PATEL

BRANCH:-COMPUTER ENGINEERING

SAPID:-60004210126

DIV:-C2 ; BATCH:- 1

ADBMS
EXPERIMENT-3
AIM:- Perform Query Monitor.
THEORY :-
COMMAND:-
JOIN QUERY :-
SELECT preksha.first_name, preksha.last_name, dept_emp.dept_no
FROM preksha
JOIN dept_emp ON preksha.emp_no = dept_emp.emp_no;

RESULT GRID:
FORM EDITOR:

FIELD TYPES:
QUERY STATISTICS:

EXECUTION PLAN:
CONCLUSION:-
In conclusion,an experiment to perform a query Monitor provided valuable insight into how
we can keep a close watch on the performance of our database queries. By using this tool,
we know how to track,analyze and optimize our database interactions, ensuring our projects
to run smoothly and efficiently.
NAME:-PREKSHA ASHOK PATEL

BRANCH:-COMPUTER ENGINEERING

SAPID:-60004210126

DIV:-C2 ; BATCH:-1

ADBMS
Experiment 4
Aim: Optimize using B and B+ trees.

Theory:-
B-Tree:
A B-Tree (Balanced Tree) is a self-balancing tree data structure that maintains sorted data and
allows searches, insertions, and deletions in logarithmic time. It is designed to keep data
sorted and balanced, ensuring efficient operations even with large datasets. A B-Tree node
contains multiple keys and child pointers, and it is structured in a way that maintains balance
by redistributing keys among nodes during insertions and deletions. This balancing property
helps in optimizing search operations, making B-Trees suitable for use in databases and file
systems.
The main characteristics of a B-Tree include:
• Balanced Structure: All leaf nodes of the tree are at the same level, ensuring a
balanced structure that guarantees logarithmic height.
• Sorted Data: Within each node, keys are stored in sorted order, allowing for efficient
searching through a binary search-like mechanism.
• Node Capacity: Each node in a B-Tree has a maximum and minimum number of keys
it can hold. When a node becomes full, it is split, and the median key is pushed up to
the parent node.
• Child Pointers: Non-leaf nodes have child pointers corresponding to ranges of keys.
These pointers guide the search process.
B-Trees are commonly used in databases to store and manage indices, allowing for rapid
retrieval of records.
B+ Tree:
A B+ Tree is an extension of the B-Tree that optimizes certain aspects, especially for use in
databases and file systems. The key differences lie in the structure of the nodes and the way
keys are stored.
In a B+ Tree:
• Data Storage: Unlike B-Trees, B+ Trees store data only in the leaf nodes. Internal
nodes contain only keys and child pointers, leading to a more efficient use of memory.
• Sequential Access: Leaf nodes are linked in a sequential manner, facilitating range
queries and sequential access to the data.
• Search Operation: Search operations involve navigating down the tree through
internal nodes and finally reaching a leaf node where the desired data is stored.
• Balanced Structure: Similar to B-Trees, B+ Trees maintain a balanced structure,
ensuring logarithmic height and efficient operations.
• Key Range Queries: B+ Trees are particularly well-suited for range queries due to
their sequential leaf node arrangement.
B+ Trees are commonly used in database systems to implement indices, providing efficient
support for various query types, including equality searches and range queries.

Code:

B Tree
from BTrees import IIBTree

import time

t = IIBTree()

insertion_start_time= time.time()

for i in range(1000):

t.update({i: 2*i})

insertion_end_time=time.time()

print("Insertion time:", format((insertion_end_time-insertion_start_time)*1000, ".3f"),

"milliseconds")

key = int(input("enter key: "))

search_start_time = time.time()

if t.has_key(key):

print(t[key])

search_end_time = time.time()

print("Search time:", format((search_end_time-search_start_time)*1000, ".3f"),

"milliseconds")

Output:
B+ Tree:

from bplustree import BPlusTree

import time

tree = BPlusTree('D:/PY_PROJECTS/tmp/bplustree.db',order=50)

for i in range(1000):

data=(2*i).to_bytes(10,'big')

tree[i]=data

start_time=time.time()

for i in range(5):

data=int(input("Enter key : "))

byte_data=tree.get(data)

int_data=int.from_bytes(byte_data, 'big')

print("Value : ",int_data)

end_time=time.time()

print("Time taken : ",(end_time-start_time)*1000," ms")

tree.close()

Output

Observation:
Runtime for a single search in B Tree was 0.999 ms while that in B+ Tree was 0.195 ms which proves
that

B+ Tree optimize the query further B Trees.


CONCLUSION:-

The B-Tree and B+ Tree data structures are powerful tools for managing sorted data
efficiently. B-Trees excel in scenarios where a balanced structure and sorted data are crucial,
providing logarithmic time complexity for operations. On the other hand, B+ Trees optimize
memory usage and enhance support for range queries, making them particularly well-suited
for database applications. Both tree types play a significant role in improving the
performance of search, insertion, and deletion operations, with B+ Trees offering specific
advantages in certain database-related scenarios.
NAME:-PREKSHA ASHOK PATEL

SAPID:-60004210126

BRANCH:-COMPUTER ENGINEERING

DIV:-C2 ; BATCH:-1

ADBMS
EXPERIMENT-5
AIM:- Implement various types of fragmentation and partitioning
(list,keys,hash and range)
THEORY:
How can we partition the table in MySQL?
We can create a partition in MySQL using the CREATE TABLE or ALTER TABLE statement. Below
is the syntax of creating partition using CREATE TABLE command:

CREATE TABLE [IF NOT EXISTS] table_name


(column_definitions)
[table_options]
[partition_options]

The below is the syntax of creating partition using ALTER TABLE command:

ALTER TABLE [IF EXISTS] tab_name


(colm_definitions)
[tab_options]
[partition_options]

Types of MySQL Partitioning

MySQL has mainly six types of partitioning, which are given below:

● RANGE Partitioning
● LIST Partitioning
● COLUMNS Partitioning
● HASH Partitioning
● KEY Partitioning
● Subpartitioning

MySQL RANGE Partitioning

This partitioning allows us to partition the rows of a table based on column values that fall within a
specified range. The given range is always in a contiguous form but should not overlap each other,
and also uses the VALUES LESS THAN operator to define the ranges.

CODE:
CREATE TABLE Sales ( cust_id INT NOT NULL, name VARCHAR(40),
store_id VARCHAR(20) NOT NULL, bill_no INT NOT NULL,
bill_date DATE PRIMARY KEY NOT NULL, amount DECIMAL(8,2) NOT
NULL)
PARTITION BY RANGE (year(bill_date))(
PARTITION p0 VALUES LESS THAN (2016),
PARTITION p1 VALUES LESS THAN (2017),
PARTITION p2 VALUES LESS THAN (2018),
PARTITION p3 VALUES LESS THAN (2020));

INSERT INTO Sales VALUES


(1, 'Mike', 'S001', 101, '2015-01-02', 125.56),
(2, 'Robert', 'S003', 103, '2015-01-25', 476.50),
(3, 'Peter', 'S012', 122, '2016-02-15', 335.00),
(4, 'Joseph', 'S345', 121, '2016-03-26', 787.00),
(5, 'Harry', 'S234', 132, '2017-04-19', 678.00),
(6, 'Stephen', 'S743', 111, '2017-05-31', 864.00),
(7, 'Jacson', 'S234', 115, '2018-06-11', 762.00),
(8, 'Smith', 'S012', 125, '2019-07-24', 300.00),
(9, 'Adam', 'S456', 119, '2019-08-02', 492.20);

SELECT TABLE_NAME, PARTITION_NAME, TABLE_ROWS, AVG_ROW_LENGTH,


DATA_LENGTH
FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_SCHEMA = 'partitioning' AND TABLE_NAME = 'Sales';
OUTPUT:
MySQL LIST Partitioning
It is the same as Range Partitioning. Here, the partition is defined and selected based on columns
matching one of a set of discrete value lists rather than a set of a contiguous range of values. It is
performed by the PARTITION BY LIST(exp) clause. The exp is an expression or column value that
returns an integer value. The VALUES IN(value_lists) statement will be used to define each partition.

CODE:

CREATE TABLE Stores ( cust_name


VARCHAR(40), bill_no VARCHAR(20)
NOT NULL, store_id INT PRIMARY
KEY NOT NULL, bill_date DATE NOT
NULL, amount DECIMAL(8,2) NOT
NULL
)
PARTITION BY LIST(store_id) (
PARTITION pEast VALUES IN (101, 103, 105),
PARTITION pWest VALUES IN (102, 104, 106),
PARTITION pNorth VALUES IN (107, 109, 111),
PARTITION pSouth VALUES IN (108, 110, 112));

INSERT INTO Stores VALUES


("Mike", "1", 101, "2015-01-25", 100.00),
("Joseph", "2", 102, "2015-01-25", 100.00),
("Robert", "3", 103, "2015-01-25", 100.00),
("Peter", "4", 104, "2015-01-25", 100.00),
("Joseph", "5", 105, "2015-01-25",100.00),
("Harry", "6", 106, "2015-01-25", 100.00),
("Jacson", "7", 107, "2015-01-25", 100.00),
("Smith", "8", 108, "2015-01-25", 100.00),
("Adam", "9", 110, "2015-01-25", 100.00);

SELECT TABLE_NAME, PARTITION_NAME, TABLE_ROWS, AVG_ROW_LENGTH,


DATA_LENGTH
FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_SCHEMA = 'partitioning' AND TABLE_NAME = 'Stores';

OUTPUT:
MySQL HASH Partitioning
This partitioning is used to distribute data based on a predefined number of partitions. In other
words, it splits the table as of the value returned by the user-defined expression. It is mainly used to
distribute data evenly into the partition. It is performed with the PARTITION BY HASH(expr) clause.
Here, we can specify a column value based on the column_name to be hashed and the number of
partitions into which the table is divided.

CODE:
CREATE TABLE Stores2 ( cust_name VARCHAR(40), bill_no
VARCHAR(20) NOT NULL, store_id INT PRIMARY KEY NOT NULL,
bill_date DATE NOT NULL, amount DECIMAL(8,2) NOT NULL
)
PARTITION BY HASH(store_id)
PARTITIONS 4;

INSERT INTO Stores2 VALUES


("Mike", "1", 101, "2015-01-25", 100.00),
("Joseph", "2", 102, "2015-01-25", 100.00),
("Robert", "3", 103, "2015-01-25", 100.00),
("Peter", "4", 104, "2015-01-25", 100.00),
("Joseph", "5", 105, "2015-01-25",100.00),
("Harry", "6", 106, "2015-01-25", 100.00),
("Jacson", "7", 107, "2015-01-25", 100.00),
("Smith", "8", 108, "2015-01-25", 100.00),
("Adam", "9", 110, "2015-01-25", 100.00);

SELECT TABLE_NAME, PARTITION_NAME, TABLE_ROWS, AVG_ROW_LENGTH,


DATA_LENGTH
FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_SCHEMA = 'partitioning' AND TABLE_NAME = 'Stores2';

OUTPUT:
MySQL COLUMN Partitioning
This partitioning allows us to use the multiple columns in partitioning keys. The purpose of these
columns is to place the rows in partitions and determine which partition will be validated for
matching rows. It is mainly divided into two types:

RANGE Columns Partitioning


LIST Columns Partitioning
They provide supports for the use of non-integer columns to define the ranges or value lists. They
support the following data types:

All Integer Types: TINYINT, SMALLINT, MEDIUMINT, INT (INTEGER), and BIGINT.
String Types: CHAR, VARCHAR, BINARY, and VARBINARY.
DATE and DATETIME data types.
Range Column Partitioning: It is similar to the range partitioning with one difference. It defines
partitions using ranges based on various columns as partition keys. The defined ranges are of
column types other than an integer type.

CODE:
CREATE TABLE test_part (A INT, B CHAR(5), C INT, D INT)
PARTITION BY RANGE COLUMNS(A, B, C)
(PARTITION p0 VALUES LESS THAN (50, 'test1', 100),
PARTITION p1 VALUES LESS THAN (100, 'test2', 200),
PARTITION p2 VALUES LESS THAN (150, 'test3', 300), PARTITION p3
VALUES LESS THAN (MAXVALUE, MAXVALUE, MAXVALUE));

INSERT INTO test_part VALUES


(10, 'a', 50, 3),
(30, 'test1', 150, 3),
(55, 'test1', 175, 3),
(123, 'test2', 233, 3),
(160, 'test4', 333, 3);

SELECT TABLE_NAME, PARTITION_NAME, TABLE_ROWS, AVG_ROW_LENGTH,


DATA_LENGTH
FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_SCHEMA = 'partitioning' AND TABLE_NAME = 'test_part';
OUTPUT:
LIST Columns Partitioning
It takes a list of single or multiple columns as partition keys. It enables us to use various columns
of types other than integer types as partitioning columns. In this partitioning, we can use String
data types, DATE, and DATETIME columns.

CODE:
CREATE TABLE AgentDetail (
agent_id VARCHAR(10),
agent_name VARCHAR(40),
city VARCHAR(10))
PARTITION BY LIST COLUMNS(agent_id) (
PARTITION pNewyork VALUES IN('A1', 'A2', 'A3'),
PARTITION pTexas VALUES IN('B1', 'B2', 'B3'),
PARTITION pCalifornia VALUES IN ('C1', 'C2', 'C3'));

INSERT INTO AgentDetail VALUES


('A1', 'DummyName', 'CityName'),
('A2', 'DummyName', 'CityName'),
('A3', 'DummyName', 'CityName'),
('B1', 'DummyName', 'CityName'),
('B2', 'DummyName', 'CityName'),
('B3', 'DummyName', 'CityName'),
('C1', 'DummyName', 'CityName'),
('C2', 'DummyName', 'CityName'),
('C3', 'DummyName', 'CityName'),
('A1', 'DummyName', 'CityName'),
('C2', 'DummyName', 'CityName'),
('B1', 'DummyName', 'CityName');

SELECT TABLE_NAME, PARTITION_NAME, TABLE_ROWS, AVG_ROW_LENGTH,


DATA_LENGTH
FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_SCHEMA = 'partitioning' AND TABLE_NAME = 'AgentDetail';

MySQL KEY Partitioning


It is similar to the HASH partitioning where the hash partitioning uses the user-specified expression,
and MySQL server supplied the hashing function for key. If we use other storage engines, the MySQL
server employs its own internal hashing function that is performed by using the PARTITION BY KEY
clause. Here, we will use KEY rather than HASH that can accept only a list of zero or more column
names.

If the table contains a PRIMARY KEY and we have not specified any column for partition, then
the primary key is used as partitioning key.

CODE:

CREATE TABLE AgentDetail2 ( agent_id


INT NOT NULL PRIMARY KEY,
agent_name VARCHAR(40)
)
PARTITION BY KEY()
PARTITIONS 2;

INSERT INTO AgentDetail2 VALUES


(1, "Name"),
(2, "Name"),
(3, "Name"),
(4, "Name"),
(5, "Name"),
(6, "Name"),
(7, "Name"),
(8, "Name"),
(9, "Name"),
(10, "Name"),
(11, "Name");

SELECT TABLE_NAME, PARTITION_NAME, TABLE_ROWS, AVG_ROW_LENGTH,


DATA_LENGTH
FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_SCHEMA = 'partitioning' AND TABLE_NAME = 'AgentDetail2';
OUTPUT:
SUBPARTITIONING
It is a composite partitioning that further splits each partition in a partition table.

CODE:

CREATE TABLE Person (


id INT NOT NULL,
name VARCHAR(40),
purchased DATE,
PRIMARY KEY (`id`, `purchased`)
)
PARTITION BY RANGE( YEAR(purchased) )
SUBPARTITION BY HASH( TO_DAYS(purchased) )
SUBPARTITIONS 2 (
PARTITION p0 VALUES LESS THAN (2015),
PARTITION p1 VALUES LESS THAN (2020),
PARTITION p2 VALUES LESS THAN MAXVALUE
);

INSERT INTO Person VALUES


(1, "Name", "2013-01-13"),
(2, "Name2", "2014-04-22"),
(3, "Name3", "2015-02-25"),
(4, "Name4", "2018-05-05"),
(5, "Name5", "2020-02-04");

SELECT PARTITION_NAME, TABLE_ROWS


FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_SCHEMA = 'partitioning' AND TABLE_NAME = 'Person';
OUTPUT:
Conclusion: In conclusion, the implementation of diverse fragmentation and partitioning
strategies, including list, key-based, hash, and range methods, serves to optimize data
management in databases, enhancing retrieval efficiency and scalability. Tailoring these
strategies to the nature of the data and anticipated query patterns is essential for achieving
balanced workloads and maximizing the performance of database systems.
NAME:-PREKSHA ASHOK PATEL

SAPID:-60004210126

BRANCH:-COMPUTER ENGINEERING

DIV:-C2 ; BATCH:-1

ADBMS EXPERIMENT-6

AIM:- Implementation of 2 phase commit protocol in distributed system

THEORY:-
IMPLEMENTATION:
COORDINATOR
import java.io.IOException;
import
java.net.ServerSocket;
import java.net.Socket;
public class Coordinator {
private static final int COORDINATOR_PORT = 9001;

public static void main(String[] args) throws IOException {


ServerSocket serverSocket = new ServerSocket(COORDINATOR_PORT);

while (true) {
Socket clientSocket = serverSocket.accept(); new
CoordinatorThread(clientSocket).start();
}
}
}
COORDINATOR.THREAD
import java.io.BufferedReader; import
java.io.IOException; import
java.io.InputStreamReader; import
java.io.PrintWriter;

import java.net.Socket;

public class CoordinatorThread extends Thread {


private Socket socket;

public CoordinatorThread(Socket socket) {


this.socket = socket;
}

public void run() {


try {
BufferedReader in = new BufferedReader(new
InputStreamReader(socket.getInputStream()));
PrintWriter out = new PrintWriter(socket.getOutputStream(), true);
// Receive votes from participants
String participantVote = in.readLine();
System.out.println("Received vote from participant: " + participantVote);

// Make a decision based on votes


boolean commitDecision = decideCommitOrAbort(participantVote);

// Inform participants about the decision


out.println(commitDecision ? "COMMIT" : "ABORT");

socket.close();
} catch (IOException e) {
e.printStackTrace();
}
}

private boolean decideCommitOrAbort(String participantVote) { //


Simplified decision logic, can be enhanced based on requirements
return participantVote.equals("VOTE_COMMIT");
}
}
PARTICIPANT
import java.io.BufferedReader;

import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;

import java.net.Socket; import


java.util.Scanner;

public class Participant { private static final int PARTICIPANT_PORT =


8001; private static final
int COORDINATOR_PORT = 9001;
public static void main(String[] args) throws IOException {
Scanner scanner = new Scanner(System.in);
System.out.println("Enter 'VOTE_COMMIT' to vote COMMIT or 'VOTE_ABORT' to vote ABORT:");

String vote = scanner.nextLine();


scanner.close();

Socket socket = new Socket("localhost", COORDINATOR_PORT); PrintWriter


out = new PrintWriter(socket.getOutputStream(),
true); out.println(vote);

BufferedReader in = new BufferedReader(new InputStreamReader(socket.getInputStream()));


String decision = in.readLine();
System.out.println("Received decision from coordinator: " + decision);

socket.close();
}
}
OUTPUT:
CONCLUSION:-
NAME:-PREKSHA ASHOK PATEL
SAPID:-60004210126
BRANCH:COMPUTER ENGINEERING
DIV:-C2 ; BATCH:-1
ADBMS
EXPERIMENT NO.-07

AIM: Query execution on XML Database

THEORY:-
IMPLEMENTATION:

1. Creating an XML Table:


2. Selecting from Users Table:
3. Using xpath to extract data from XML

CONCLUSION:-
NAME:-PREKSHA ASHOK PATEL
SAPID:-60004210126
BRANCH:COMPUTER ENGINEERING
DIV:-C2 ; BATCH:-1
ADBMS
EXPERIMENT NO.-08

AIM:- Data Handling using Json .

THEORY:-
IMPLEMENTATION:
CONCLUSION:-
NAME:-PREKSHA ASHOK PATEL

SAPID:-60004210126

BRANCH:-COMPUTER ENGINEERING

DIV:-C2 ; BATCH:-1

ADBMS
EXPERIMENT NO.09
AIM: Procesing spatial and temporal data

THEORY:-
IMPLEMENTATION:
CONCLUSION:-

You might also like