AMBEDKARNAGR, 224122

SESSION – 2020-21

PRACTICAL FILE FOR

DATABASE MANAGEMENT
SYSTEM
SUBMITTED TO SUBMITTED BY
Aniruddh KUMAR VIKRANT SINGH
(LECTURER) BRANCH :- COMPUTER SCEINCE & ENGG.

ENROLL NO. :- E19220735500025

SIGNATURE SIGNATURE
 INDEX

S.No. Title of Exercise Practical Submission Signature /

Date Date Remark
1. Creating Database
2. Table and Record Handling
3. Retrieving Data From a Database
4. Design of database for any application
 PRACTICAL NO.1

 Creating Database.
Ans.
 SYNTAX OF DATABASE IS HERE…

 Create database database_name;

 Syntax of table in database…

 Create table table_name;

 Relational database--

A relational database is a type of database that stores and provides access to data
points that are related to one another. ... The columns of the table hold attributes of the
data, and each record usually has a value for each attribute, making it easy to establish the
relationships among data points.

Examples of relational databases-

Standard relational databases enable users to manage predefined data relationships across
multiple databases. Popular examples of standard relational databases include Microsoft SQL
Server, Oracle Database, MySQL and IBM DB2.

CONSTRAINTS IN DBMS
Constraints enforce limits to the data or type of data that can be inserted/updated/deleted from a table.
The whole purpose of constraints is to maintain the data integrity during an update/delete/insert into
a table. In this tutorial we will learn several types of constraints that can be created in RDBMS.

TYPES OF CONSTRAINTS

 NOT NULL
  UNIQUE
 DEFAULT
 CHECK
 Key Constraints – PRIMARY KEY, FOREIGN KEY
 Domain constraints
 Mapping constraints

NOT NULL:
NOT NULL constraint makes sure that a column does not hold NULL value. When we don’t provide
value for a particular column while inserting a record into a table, it takes NULL value by default. By
specifying NULL constraint, we can be sure that a particular column(s) cannot have NULL values.

Example:

CREATE TABLE STUDENT(

ROLL_NO INT NOT NULL,
STU_NAME VARCHAR (35) NOT NULL,
STU_AGE INT NOT NULL,
STU_ADDRESS VARCHAR (235),
PRIMARY KEY (ROLL_NO)
);

UNIQUE:
UNIQUE Constraint enforces a column or set of columns to have unique values. If a column has a
unique constraint, it means that particular column cannot have duplicate values in a table.

CREATE TABLE STUDENT(

ROLL_NO INT NOT NULL,
STU_NAME VARCHAR (35) NOT NULL UNIQUE,
STU_AGE INT NOT NULL,
STU_ADDRESS VARCHAR (35) UNIQUE,
PRIMARY KEY (ROLL_NO)
);

DEFAULT:
The DEFAULT constraint provides a default value to a column when there is no value provided while
inserting a record into a table.

CREATE TABLE STUDENT(

ROLL_NO INT NOT NULL,
STU_NAME VARCHAR (35) NOT NULL,
STU_AGE INT NOT NULL,
EXAM_FEE INT DEFAULT 10000,
STU_ADDRESS VARCHAR (35) ,
PRIMARY KEY (ROLL_NO)
);

CHECK:
This constraint is used for specifying range of values for a particular column of a table. When this
constraint is being set on a column, it ensures that the specified column must have the value falling in
the specified range.

CREATE TABLE STUDENT(

ROLL_NO INT NOT NULL CHECK(ROLL_NO >1000) ,
STU_NAME VARCHAR (35) NOT NULL,
STU_AGE INT NOT NULL,
EXAM_FEE INT DEFAULT 10000,
STU_ADDRESS VARCHAR (35) ,
PRIMARY KEY (ROLL_NO)
);
In the above example we have set the check constraint on ROLL_NO column of STUDENT table.
Now, the ROLL_NO field must have the value greater than 1000.

KEY CONSTRAINTS:

PRIMARY KEY:
Primary key uniquely identifies each record in a table. It must have unique values and cannot contain
nulls. In the below example the ROLL_NO field is marked as primary key, that means the ROLL_NO
field cannot have duplicate and null values.

CREATE TABLE STUDENT(

ROLL_NO INT NOT NULL,
STU_NAME VARCHAR (35) NOT NULL UNIQUE,
STU_AGE INT NOT NULL,
STU_ADDRESS VARCHAR (35) UNIQUE,
PRIMARY KEY (ROLL_NO)
);

FOREIGN KEY:
Foreign keys are the columns of a table that points to the primary key of another table. They act as a
cross-reference between tables.
.

DOMAIN CONSTRAINTS:
Each table has certain set of columns and each column allows a same type of data, based on its data
type. The column does not accept values of any other data type.
Domain constraints are user defined data type and we can define them like this:

Domain Constraint = data type + Constraints (NOT NULL / UNIQUE / PRIMARY KEY / FOREIGN
KEY / CHECK / DEFAULT)

THE CREATE INDEX COMMAND

The basic syntax of a CREATE INDEX is as follows.

CREATE INDEX index_name ON table_name;

SINGLE-COLUMN INDEXES
A single-column index is created based on only one table column. The basic syntax is as follows.
CREATE INDEX index_name
ON table_name (column_name);

UNIQUE INDEXES
Unique indexes are used not only for performance, but also for data integrity. A unique index does
not allow any duplicate values to be inserted into the table. The basic syntax is as follows.
CREATE UNIQUE INDEX index_name
on table_name (column_name);

COMPOSITE INDEXES
A composite index is an index on two or more columns of a table. Its basic syntax is as follows.
CREATE INDEX index_name
on table_name (column1, column2);
Whether to create a single-column index or a composite index, take into consideration the
column(s) that you may use very frequently in a query's WHERE clause as filter conditions.
Should there be only one column used, a single-column index should be the choice. Should there
be two or more columns that are frequently used in the WHERE clause as filters, the composite
index would be the best choice.

IMPLICIT INDEXES
Implicit indexes are indexes that are automatically created by the database server when an object
is created. Indexes are automatically created for primary key constraints and unique constraints.

PRACTICAL NO.2

 Table and Record Handling.

Ans.
 Insert statement
There are two basic syntaxes of the INSERT INTO statement which are shown below.

INSERT INTO TABLE_NAME (column1, column2, column3,... columnN) VALUES (value1,

value2, value3,... valueN);

 using insert and select

The SQL INSERT INTO SELECT Statement….
The INSERT INTO SELECT statement copies data from one table and inserts it into another
 table. The INSERT INTO SELECT statement requires that the data types in source and target
tables matches. Note: The existing records in the target table are unaffected.

Example…
INSERT INTO table2 (column1, column2, column3, ...)
SELECT column1, column2, column3, ...
FROM table1
WHERE condition;

 Delete ,Update, truncate statement


SQL DELETE STATEMENT
The DELETE Statement is used to delete rows from a table.

SYNTAX OF A SQL DELETE STATEMENT

DELETE FROM table_name [WHERE condition];

SQL TRUNCATE STATEMENT

The SQL TRUNCATE command is used to delete all the rows from the table and free the space
containing the table.

SYNTAX TO TRUNCATE A TABLE:

TRUNCATE TABLE table_name;

THE SQL UPDATE STATEMENT

The UPDATE statement is used to modify the existing records in a table.

UPDATE SYNTAX
UPDATE TABLE_NAME
SET COLUMN1 = VALUE1, COLUMN2 = VALUE2, ...
WHERE CONDITION;

THE SQL DROP TABLE STATEMENT

The DROP TABLE statement is used to drop an existing table in a database.
SYNTAX
DROP TABLE TABLE_NAME;

SQL ALTER TABLE STATEMENT

The ALTER TABLE statement is used to add, delete, or modify columns in an existing table.

The ALTER TABLE statement is also used to add and drop various constraints on an existing
table.

ALTER TABLE - ADD COLUMN

To add a column in a table, use the following syntax:

ALTER TABLE TABLE_NAME

ADD COLUMN_NAME DATATYPE;

PRACTICAL NO. 3

 Retrieving Data From a Database.

Ans.
THE SQL SELECT STATEMENT
The SELECT statement is used to select data from a database.

The data returned is stored in a result table, called the result-set.

SELECT SYNTAX
SELECT COLUMN1, COLUMN2, ...
FROM TABLE_NAME;
THE SQL WHERE CLAUSE
The WHERE clause is used to filter records.

It is used to extract only those records that fulfill a specified condition.

WHERE SYNTAX
SELECT COLUMN1, COLUMN2, ...
FROM TABLE_NAME
WHERE CONDITION;

LOGICAL OPERATORS
The most used logical operator is the AND, used to filter records that satisfy two conditions
simultaneously. For example, to obtain the years where you harvest more than 90 Tons of Red
Delicious variety, you have two conditions: Tons_produced > 90 and variety = 'Red Delicious' . To obtain
the records satisfying both conditions, you connect them with the AND logical operator:

Copy

SELECT year, apple_variety, tons_produced

FROM apples

WHERE apple_variety = ‘Red Delicious’

AND Tons_Produced > 90

THE SQL BETWEEN OPERATOR

The BETWEEN operator selects values within a given range. The values can be numbers, text,
or dates.

The BETWEEN operator is inclusive: begin and end values are included.

BETWEEN SYNTAX
SELECT COLUMN_NAME(S)
FROM TABLE_NAME
WHERE COLUMN_NAME BETWEEN VALUE1 AND VALUE2;
THE SQL LIKE OPERATOR
The LIKE operator is used in a WHERE clause to search for a specified pattern in a column.

There are two wildcards often used in conjunction with the LIKE operator:

 The percent sign (%) represents zero, one, or multiple characters

 The underscore sign (_) represents one, single character

Note: MS Access uses an asterisk (*) instead of the percent sign (%), and a question mark
(?) instead of the underscore (_).

The percent sign and the underscore can also be used in combinations!

LIKE SYNTAX
SELECT COLUMN1, COLUMN2, ...
FROM TABLE_NAME
WHERE COLUMNN LIKE PATTERN;

THE SQL GROUP BY STATEMENT

The GROUP BY statement groups rows that have the same values into summary rows, like
"find the number of customers in each country".

The GROUP BY statement is often used with aggregate functions

(COUNT(), MAX(), MIN(), SUM(), AVG()) to group the result-set by one or more columns.

GROUP BY SYNTAX
SELECT COLUMN_NAME(S)
FROM TABLE_NAME
WHERE CONDITION
GROUP BY COLUMN_NAME(S)
ORDER BY COLUMN_NAME(S);

THE SQL HAVING CLAUSE

The HAVING clause was added to SQL because the WHERE keyword cannot be used with
aggregate functions.

HAVING SYNTAX
SELECT COLUMN_NAME(S)
FROM TABLE_NAME
WHERE CONDITION
GROUP BY COLUMN_NAME(S)
HAVING CONDITION
ORDER BY COLUMN_NAME(S);

AGGREGATE FUNCTIONS IN SQL

In database management an aggregate function is a function where the values of multiple rows
are grouped together as input on certain criteria to form a single value of more significant
meaning.

Various Aggregate Functions

1) Count()
2) Sum()
3) Avg()
4) Min()
5) Max()

SQL JOIN
A JOIN clause is used to combine rows from two or more tables, based on a related column
between them.

Let's look at a selection from the "Orders" table:

OrderID CustomerID OrderDate

10308 2 1996-09-18

10309 37 1996-09-19

10310 77 1996-09-20

Then, look at a selection from the "Customers" table:

CustomerID CustomerName ContactName Country

 1 Alfreds Futterkiste Maria Anders Germany

2 Ana Trujillo Emparedados y helados Ana Trujillo Mexico

3 Antonio Moreno Taquería Antonio Moreno Mexico

Notice that the "CustomerID" column in the "Orders" table refers to the "CustomerID" in
the "Customers" table. The relationship between the two tables above is the "CustomerID"
column.

Then, we can create the following SQL statement (that contains an INNER JOIN), that selects
records that have matching values in both tables:

EXAMPLE
SELECT Orders.OrderID, Customers.CustomerName, Orders.OrderDate
FROM Orders
INNER JOIN Customers ON Orders.CustomerID=Customers.CustomerID;

PRACTICAL NO. 4

 Design of database for any application.

Ans.
The design process consists of the following steps:
1. Determine the purpose of your database. ...
2. Find and organize the information required. ...
3. Divide the information into tables. ...
4. Turn information items into columns. ...
5. Specify primary keys. ...
6. Set up the table relationships. ...
7. Refine your design. ...
8. Apply the normalization rules.
  APPLICATION IS HERE

LEVERAGING THE POWER OF UUIDS TO ENSURE

INTEROPERABILITY WITH EXTERNAL APPLICATIONS OR MICRO-
SERVICES AND HOW IT RELATES TO DATABASE DESIGN.
A unique challenge exists in today's applications. They are no longer data silos or single domain applications,
and they need to interact with external services (microservices). Application developers and database
administrators need to ensure that actions taken in their applications interact with these external services and
update the correct records and - likewise - actions in these applications need the ability to update or record
actions in the source application.

In a previous post I discussed history of SQL as a language and highlighted some pretty amazing features of
the standard. In this post I'm going to cover a topic that is related called DATABASE DESIGN.
Understanding database design is key to understanding a key tool in addressing this challenge
-- the universally unique identifier (UUID).

TYPES OF DATABASES

There are many types of database systems in the world today, but the two most dominant are Relational
Databases Management Systems (RDMS) or a Document-oriented Database (often referred to as NoSQL).
The two are very different in their implementation. I'll discuss each briefly, but the core of this post focuses on
relational datasets.

DOCUMENT-ORIENTED DATABASES (NOSQL)

The two predominant characteristics of NoSQL databases are that they are SCHEMA-LESS and WEAKLY
TYPED. What this means is that database designers (often referred to as database administrators, or DBAs) do
not have to structure a database beforehand.
Document-oriented databases store data in documents. Documents are key-value stores where the key denotes
the NAME of the element you're storing and the VALUE is just that, the value. For example:
author:
name:
given_name: Bob
family_name: Smith
address:
street_address: 555 Example St.
city: Ottawa
state: Ontario
In this document example, all of the strings before the colon (user, contact, address, family_name,
street_address etc.) are KEYS and the string after is the VALUE. The value does not have to be a string, it can
be any type of data.
To build a document in a NoSQL database you do not have to predefine any of these keys or value types
beforehand, nor do you have to adhere to them. You can add or rename keys and change the types of data
stored in the value field at will.

This flexibility is great from an application development standpoint, however, there is no concept of relational
data in a NoSQL database. This means that design, as it exists for NoSQL, centers around how you want to
retrieve data from the database (the query) rather than how you want to store data. It seems subtle, but the
primary drawback of document-oriented databases is that providing different ways to retrieve or analyze data
can be challenging if your "design" is optimized for a set of queries.

For example, if you wanted to find comments by any user for a given article , then you would
store comments on an article document and the user data within the comment. Something like this:
article:
title: Awesome article title
text: Amazing article text
author:
given_name: Jane
family_name: Doe
comments:
text: This article is neither awesome or amazing.
user:
given_name: Bob
family_name: Smith
Now, if you wanted to find comments for any article by a given user it would be considerably
more challenging as you would have to reach into each article, iterate over the comments and find users that
match the specific user you're looking for.

RELATIONAL DATABASES

Relational databases are designed beforehand and strongly typed. They are a collection of database objects
including TABLES, COLUMNS, INDICES and more.
For the purposes of this article, we're going to focus on tables and columns as it related to database design.

In a relational database you would create tables to represent objects you want to store and columns within
these tables to store their values. Here's an example:

Users (users)
 id given_name family_name

1 Bob Smith

2 Jane Doe

Articles (articles)

id user_id title text

1 2 Awesome article title Amazing article text

Comments (comments)

id article_id user_id text

1 1 1 This article is neither awesome or amazing.

This example details the comparable complexity of the relational database environment. These tables need to
be setup first, the column types need to be specified (integer, varchar, text) for each type of data that column
will store and the relationships between tables need to be predefined.

There is a pattern here. This is called database normalization. In relational database design, this is incredibly
important as it will:
 Free the database of modification anomalies
 Minimize redesign when extending the database structure
 Avoid bias towards any particular pattern of querying
The last point being the most important from our example above. With this database structure, finding
comments by a user on an article as well as finding all comments by a user for any given article is extremely
easy to do as both queries would be isolated to the comments table with some conditional WHERE statements.

UNIVERSALLY UNIQUE IDENTIFIER (UUID)

In the relational example above, you'll notice some key columns that we didn't cover -- the id columns. These
columns form the cornerstone of relational database design theory. They are the primary and foreign keys that
determine the relationships between the respective tables.

This diagram details the relationships. The user_id column in comments and articles refers to the users
table. This means, for each entry in the comments or articles table, the user referenced by user_id is the author.
The family_name and given_name is not written to the articles or comments tables, instead, it is only
written to the users table. In this way, there is only a single table to update if a user changes their name, and all
references to these columns will update immediately.
A key issue that the UUID addresses is that these id columns are usually auto-incrementing integers. Each
new record added to the database will automatically increment these numbers to the latest available and then
write the rest of the columnar data.
This design is fine for single domain applications. Single domain applications typically will not interact with
other applications and their accompanying databases. In a sense, they're isolated.

In modern applications, this is no longer the case. Entities or objects represented by relationships across
multiple tables in a single-domain application will likely need to relate to data stored in external applications
and/or databases.

Enter the UUID. They look like this:

123e4567-e89b-12d3-a456-426655440000
The probability of collisions in generated UUIDs is pretty remote. As the article on wikipedia puts it, "after
generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate
would be about 50%".

The goal of the UUID is to "enable distributed systems to uniquely identify information without significant
central coordination". In simple terms, this means that auto-incremented table ids will not be be unique across
different applications and databases. Instead of using auto-incrementing ids in tables, switching to UUIDs or
storing them as a separate columnar value allows distributed applications to relate to one another.

This is called referential integrity. It allows that updates to a specify record or row in a database with a UUID
and corresponding reference in an external application will update across applications as this value can be
used to uniquely link them together.

Your database diagram now looks like this:

In this way, the native applications can still rely on their own internal mechanisms for foreign key/primary key
assignment (using ids) but have the ability to relate via associatied UUIDs.

CONCLUSION

Alongside the power of modern day databases and their accompanying standards is the power and prowess of
database design. There are many competing database technologies, but dominant ones such as document-
oriented databases seek to remove the design element from the software development lifecycle to provide
some additional flexibility and speed at the beginning of an applications life.

However, document-oriented databases suffer from a critical problem as an application grows. The original
intent of the documents can be pushed past their limit as applications stretch to look at their data in different
ways, a problem long since solved by relational database theory.

In relational database design, individual tables and their columns represent the smallest amount of data
possible and relate to eachother through auto-generated identifiers that are used to join tables together to pull
out data in a myriad of ways to analyze and report on.

As applications grow to beyond their single deployment or domain, the need to interact with external
applications pushes the relational design even further in ensuring that these foreign key relationships are as
unique as possible.

The universally unique identifier is a value either stored as a primary key on a record or as an additional
column that provides a near-impossible possibility of collisions between distinct applications.