DDM LAb MAnual
DDM LAb MAnual
To understand Database development Life cycle with its problem definition and
Aim:
requirement analysis along with their scope and constrains for different applications
What are the different phases of database development Life cycle (DBMS)?
The different phases of database development life cycle (DDLC) in the Database
Management System (DBMS)
Requirement analysis.
Database design.
Evaluation and selection.
Logical database design.
Physical database design.
Implementation.
Data loading.
Testing and performance tuning.
Operation.
Maintenance.
Requirement Analysis
The most important step in implementing a database system is to find out what is needed i.e
what type of a database is required for the business organization, daily volume of data, how
much data needs to be stored in the master files etc.
In order to collect all this information, a database analyst spends a lot of time within the
business organization talking to people, end users and getting acquainted with the day-to-day
process.
Database Design
In this phase the database designers will make a decision on the database model that perfectly
suits the organization’s requirement. The database designers will study the documents
prepared by the analysis in the requirement analysis stage and then start development of a
system model that fulfils the needs.
Evaluation and selection
In this phase, we evaluate the diverse database management systems and choose the one
which perfectly suits the requirements of the organization.
In order to identify the best performing database, end users should be involved.
Logical database design
Once the evaluation and selection phase is completed successfully, the next step is logical
database design.
This design is translated into internal model which includes mapping of all objects i.e design
of tables, indexes, views, transaction, access privileges etc.,
Physical Database Design
This phase selects and characterizes the data storage and data access of the database.
The data storage depends on the type of devices supported by the hardware, the data access
methods.
Physical design is very vital because of bad design which results in poor performance.
Implementation
Database implementation needs the formation of special storage related constructs.
These constructs consist of storage groups, table spaces, data files, tables etc.
Data Loading
Once the database has been created, the data must be loaded into the database.
The data required to be converted, if the loaded date is in a different format.
Operations
In this phase, the database is accessed by the end users and application programs.
This stage includes adding of new data, modifying existing data and deletion of absolute data.
This phase provides useful information and helps management to make a business decision.
Maintenance
It is one of the ongoing phases in DDLC.
The major tasks included are database backup and recovery, access management, hardware
maintenance etc.
The Database Life Cycle (DBLC) contains six phases, as shown in the following Figure:
database initial study, database design, implementation and loading, testing and evaluation,
operation, and maintenance and evolution.
1. The Database Initial Study:
In the Database initial study, the designer must examine the current system’s
operation within the company and determine how and why the current system fails. The
overall purpose of the database initial study is to:
• Analyze the company situation.
• Define problems and constraints.
• Define objectives.
• Define scope and boundaries.
The company situation describes the general conditions in which a company operates
its organizational structure, and its mission. To analyze the company situation, the database
designer must discover what the company’s operational components are, how they function,
and how they interact.
The designer has both formal and informal sources of information. The process of
defining problems might initially appear to be unstructured. Company end users are often
unable to describe precisely the larger scope of company operations or to identify the real
problems encountered during company operations.
c. Define Objectives:
A proposed database system must be designed to help solve at least the major
problems identified during the problem discovery process. In any case, the database designer
must begin to address the following questions:
• What is the proposed system’s initial objective?
• Will the system interface with other existing or future systems in the company?
• Will the system share the data with other systems or users?
The designer must recognize the existence of two sets of limits: scope and boundaries.
The system’s scope defines the extent of the design according to operational requirements.
Will the database design encompass the entire organization, one or more departments within
the organization, or one or more functions of a single department? Knowing the scope helps
in defining the required data structures, the type and number of entities, the physical size of
the database, and so on.
The proposed system is also subject to limits known as boundaries, which are external to the
system. Boundaries are also imposed by existing hardware and software.
2. Database Design:
The second phase focuses on the design of the database model that will support
company operations and objectives. This is arguably the most critical DBLC phase: making
sure that the final product meets user and system requirements. As you examine the
procedures required to complete the design phase in the DBLC, remember these points:
• The process of database design is loosely related to the analysis and design of a larger
system. The data component is only one element of a larger information system.
• The systems analysts or systems programmers are in charge of designing the other system
components. Their activities create the procedures that will help transform the data within the
database into useful information.
In most modern relational DBMSs a new database implementation requires the creation of
special storage-related constructs to house the end-user tables. The constructs usually include
the storage group (or file groups), the table spaces, and the tables.
After the database has been created, the data must be loaded into the database tables.
Typically, the data will have to be migrated from the prior version of the system. Often, data
to be included in the system must be aggregated from multiple sources. Data may have to be
imported from other relational databases, non relational databases, flat files, legacy systems,
or even manual paper-and-pencil systems
5. Operation
Once the database has passed the evaluation stage, it is considered to be operational. At that
point, the database, its management, its users, and its application programs constitute a
complete information system. The beginning of the operational phase invariably starts the
process of system evolution.
6. Maintenance and Evolution
The database administrator must be prepared to perform routine maintenance activities within
the database. Some of the required periodic maintenance activities include:
• Preventive maintenance (backup).
• Corrective maintenance (recovery).
• Adaptive maintenance (enhancing performance, adding entities and attributes, and so on).
• Assignment of access permissions and their maintenance for new and old users.
Problem Definition:
The designer has both formal and informal sources of information. The process of
defining problems might initially appear to be unstructured. Company end users are often
unable to describe precisely the larger scope of company operations or to identify the real
problems encountered during company operations.
Requirement analysis
The most important step in implementing a database system is to find out what is
needed i.e what type of a database is required for the business organization, daily volume of
data, how much data needs to be stored in the master files etc.
In order to collect all this information, a database analyst spends a lot of time within the
business organization talking to people, end users and getting acquainted with the day-to-day
process.
Scope and Constrains using PostgreSQL:
Conclusion:
Thus database development life cycle is analyzed with some constrains.
Database design using Conceptual modeling (ER-EER) – top-down approach
Mapping conceptual to relational database and validate using Normalization
Aim:
To design using database using conceptual modeling (ER – EER) – top down
approach mapping conceptual to relational database and validate using normalization.
Procedure:
Locations
Name Number
Supervisor Supervisee
Name
Number
Name
The relational model constraints, which include primary keys, unique keys (if any),
and referential integrity constraints on the relations, will also be specified in the mapping
results.
Conclusion:
Thus database using EER is constructed.
Implement the database using SQL Data definition with constraints, Views
Aim:
To implement database using SQL data definition with constrains and views.
DDL Commands:
To execute DDL Commands
1. Create Table
2. Alter Table
3. Drop Table
4. Truncate Table
5. Rename Table
DDL
Definition Syntax Example
Commands
To organizes CREATE TABLE table_name ( create table friends
and stores data Column1 data type, (
in a structured Column2 data type, regno int,
format: in rows Column3 data type, name varchar(25),
Create
and columns. ..... pno numeric(10),
Table Column N data type, addrvarchar(100)
PRIMARY KEY (one or more );
columns)
);
Add column to ALTER TABLE <table name> add alter table friends
Alter Table created table add
<column name><data
type><restrictions / conditions> mailidvarchar(25);
Drop the ALTER TABLE <table name> drop alter table friends
Column column <column name> drop column
regno;
Modify the alter table <table name> alter column alter table friends
Column Data <column name> type <new alter column addr
Type datatype> type varchar(50);
Constrains
Views:
Result :
Thus SQL Commands executed with Constrains and views.
Query the database using SQL Manipulation
AIM:
To execute different queries for database using SQL manipulation
SQL MANIPULATION:
DML Query:
1. Insert
2. Update
3. Delete
4. Select
Update<table name>
set <column name> =
Updatefri set name = 'Anand Kumar',addr =
<value>, <column
'Erode';
name> = <value>,
Update
Update <column name> =
the Data
<value>
Value
Update<table name>
set <column name> =
<value>, <column
name> = <value>,
updatefri set name = 'Anand Kumar',addr =
<column name> = 'Erode' where regno = 1;
<value> where <cn>
= <value> and <cn> =
<value> and <cn> =
<value>
Select
(<cn1,cn2,cn3>) from
Select
<table name> where
Select the Data
<cn> = <value>
from
Table
Select
(<cn1,cn2,cn3>) from
<table name> where
<cn> = <value> and
<cn> = <value>
Result:
Thus the query manipulation is done by SQL queries.
Querying/Managing the database using SQL Programming
- Stored Procedures/Functions
- Constraints and security using Triggers
Aim:
To implement queries and manage the database using SQL Programming with
procedures, function, constraints and security using triggers.
Procedure:
Stored Procedures/Functions:
A SQL function or a stored procedure is a set of SQL and procedural commands such
as declarations, assignments, loops; flow-of-control etc. stored on the database server and
can be involved using the SQL interfaces.
Group Functions:
⚫ These functions group the rows of data based on the values returned by the
query.
1) Calculate the net salary and year salary if da is 30% of basic, hra is 10% of
basic and pf is 7% if basic salary is less than 8000, pf is 10% if basic sal
between 8000 to160000.
Program:
declare
e name
varchar2(15);
basic number;
d a number; h r a
number;pf number;
net salary
number; year
salary number;
begin
e name:='&e
name';
basic:=&basic;
da:=basic *
(30/100);
hra:=basic *
(10/100);if (basic
< 8000) then
pf:=basic *
(8/100);
elsif (basic >= 8000 and basic <=
16000) thenpf:=basic * (10/100);
end if;
netsalary:=basic + da + hra - pf; yearsalary := netsalary*12;
Result:
Thus the query manipulation and querying database using SQL Programming is
executed with Querying/Managing the database using SQL Programming.
Database design using Normalization – bottom-up approach
Aim:
To implement database design using Normalization with bottom up approach.
Procedure:
Normalization is a process of converting a relation to be standard form by
decomposition a larger relation into smaller efficient relation that depicts a good database
design.
• 1NF: A Relation scheme is said to be in 1NF if the attribute values in the relation are
atomic.i.e., Mutli –valued attributes are not permitted.
• 2NF: A Relation scheme is said to be in 2NF,iff and every Non-key attribute is fully
functionally dependent on primary Key.
• 3NF: A Relation scheme is said to be in 3NF,iff and does not have transitivity
dependencies. A Relation is said to be 3NF if every determinant is a key for each & every
functional dependency.
• BCNF: A Relation scheme is said to be BCNF if the following statements are true for eacg
FD P->Q in set F of FDs that holds for each FD. P->Q in set F of FD’s that holds over R.
Here P is the subset of attributes of R & Q is a single attribute of R.
P is a super key.
Result:
Thus we implemented database design using Normalization with bottom up approach.
Develop database applications using IDE/RAD tools (Eg., NetBeans, VisualStudio)
Aim:
To develop database applications using IDE tools with NetBeans.
Procedure:
2. Right-click the Databases node and select New Connection to open the New
Connection dialog.
8. Click OK.
jdbc:derby://localhost:1527/sun-appserv-samples
4. Click the Run SQL button at the top of the editor pane.
Deleting the Tables
1. To delete the tutorial tables, do the following:
jdbc:derby://localhost:1527/sun-appserv-samples
5. Click the Run SQL button at the top of the editor pane.
Conclusion:
Thus a database application is created using IDE – Netbean Tools.
Database design using EER-to-ODB mapping / UML class diagrams
Aim:
To develop database design using EER to ODB mapping / UML Class Diagrams.
Procedure:
Step 1. Create an ODL class for each EER entity type or subclass. The type of the ODL class
should include all the attributes of the EER class. 38 Multivalued attributes are typically
declared by using the set, bag, or list constructors. 39 If the values of the multivalued
attribute for an object should be ordered, the list constructor is chosen; if duplicates are
allowed, the bag constructor should be chosen; otherwise, the set constructor is chosen.
Composite attributes are mapped into a tuple constructor (by using a struct declaration in
ODL).Declare an extent for each class, and specify any key attributes as keys of the extent.
(This is possible only if an extent facility and key constraint declarations are avail- able in the
ODBMS.)
Step 2. Add relationship properties or reference attributes for each binary relation- ship into
the ODL classes that participate in the relationship. These may be created in one or both
directions. If a binary relationship is represented by references in both directions, declare
the references to be relationship properties that are inverses of one another, if such a facility
exists. 40 If a binary relationship is represented by a reference in only one direction, declare
the reference to be an attribute in the referencing class whose type is the referenced class
name. Depending on the cardinality ratio of the binary relationship, the relationship
properties or reference attributes may be single-valued or collection types. They will be
single-valued for binary relationships in the 1:1 or N:1 directions; they are collection types
(set-valued or list-valued 41 ) for relationships in the 1:N or M:N direction. An alternative
way to map binary M:N relationships is discussed in step 7.
If relationship attributes exist, a tuple constructor ( struct ) can be used to create a structure of
the form < reference , relationship attributes >, which may be included instead of the
reference attribute. However, this does not allow the use of the inverse constraint.
Additionally, if this choice is represented in both directions, the attribute values will be
represented twice, creating redundancy.
38 This implicitly uses a tuple constructor at the top level of the type declaration, but in
general, the tuple constructor is not explicitly shown in the ODL class declarations. 39
Further analysis of the application domain is needed to decide which constructor to use
because this information is not available from the EER schema. 40 The ODL standard
provides for the explicit definition of inverse relationships. Some ODBMS products may
not provide this support; in such cases, programmers must maintain every relationship
explicitly bycoding the methods that update the objects appropriately. 41 The decision
whether to use set or list is not available from the EER schema and must be determined
Step 3. Include appropriate operations for each class. These are not available from the EER
schema and must be added to the database design by referring to the original requirements.
A constructor method should include program code that checks any constraints that must
hold when a new object is created. A destructor method should check any constraints that
may be violated when an object is deleted. Other methods should include any further
constraint checks that are relevant.
Step 4. An ODL class that corresponds to a subclass in the EER schema inherits (via
extends) the type and methods of its super class in the ODL schema. It’s specific (non
inherited) attributes, relationship references, and operations are specified, as discussed in
steps 1, 2, and 3.
Step 5. Weak entity types can be mapped in the same way as regular entity types. An
alternative mapping is possible for weak entity types that do not participate in any
relationships except their identifying relationship; these can be mapped as though they were
composite multivalued attributes of the owner entity type, by using the set < struct < ... >>
or list < struct < ... >> constructors. The attributes of the weak entity are included in the
struct < ... > construct, which corresponds to a tuple constructor. Attributes are mapped as
discussed in steps 1 and 2.
Step 6. Categories (union types) in an EER schema are difficult to map to ODL. It is
possible to create a mapping similar to the EER-to-relational mapping (see Section
9.2) by declaring a class to represent the category and defining 1:1 relationships between the
category and each of its superclasses. Another option is to use a union type, if it is available
Step 7. An n-ary relationship with degree n > 2 can be mapped into a separate class, with
appropriate references to each participating class. These references are based on mapping a
1: N relationship from each class that represents a participating entity type to the class that
represents the n-ary relationship. An M:N binary relationship, especially if it contains
relationship attributes, may also use this mapping option, if desired.
Conclusion:
Thus database design using EER-to-ODB mapping / UML class diagrams was
constructed.
Object features of SQL-UDTs and sub-types, Tables using UDTs,
Inheritance, Method definition
Aim:
To create an object features of SQL – UDTs and sub-types, Tables using UDTs,
Inheritance, Method Definition.
Procedure:
Syntax:
Example:
(a) CREATE TYPE STREET _ ADDR TYPE AS (
DOB DATE,
ADDR USA_ADDR_TYPE
INSTANTIBLE
NOT FINAL
REF IS SYSTEM GENERATED
BEGIN
RETURN
END);
NOT FINAL
BEGIN
RETURN
END,);
UNDER PERSON;
UNDER EMPOLOYEE;
UNDER PERSON;
Result:
Thus we created Object features of SQL-UDTs and sub-types, Tables using UDTs,
Inheritance, and Method definition.
Querying the Object-relational database using Objet Query language
Aim:
To query the Object-relational database using Objet Query language
Procedure:
A version of the Structured Query Language (SQL) that has been designed for use in
Network Manager. The components create and interact with their databases using OQL.
Use OQL to create new databases or insert data into existing databases (to configure
the operation of Network Manager Components) by amending the component schema files.
OQL statements using the OQL Service Provider, for example, to create or modify databases,
insert data into databases and retrieve data.
Syntax:
Example:
[ additional_columns ]
[ unique ( column_name ) , ]
[ counter ( column_name ) , ]
[ timestamp ( column_name ) ]
);
Data Types:
Syntax:
Example:
Result:
Thus we created Object-relational database using Objet Query language.