What is RDBMS? Explain its features.

RDBMS is a database management system based on relational model defined by E.F.Codd.

Data is stored in the form of rows and columns. The relations among tables are also stored
in the form of the table.
Example of RDBMS are : MS SQL Server, IBM DB2, Oracle, MySQL, and Microsoft Access
Features:
- Provides data to be stored in tables
- Persists data in the form of rows and columns
- Provides facility primary key, to uniquely identify the rows
- Creates indexes for quicker data retrieval
- Provides a virtual table creation in which sensitive data can be stored and simplified query
can be applied.(views)
- Sharing a common column in two or more tables(primary key and foreign key)
- Provides multi user accessibility that can be controlled by individual users.

Hierarchical database model

A hierarchical database model is a data model in which the data is organized into a tree-like
structure. The data is stored as records which are connected to one another through links. A record
is a collection of fields, with each field containing only one value. The entity type of a record defines
which fields the record contains

the hierarchical model we can identify that it used a method for storing data in a database that
looks like a family tree with one root and a number of branches or subdivisions.

Network model
The network model is a database model conceived as a flexible way of representing objects and
their relationships. Its distinguishing feature is that the schema, viewed as a graph in which object
types are nodes and relationship types are arcs, is not restricted to being a hierarchy or lattice.

Relational model
The relational model (RM) for database management is an approach to managing data using a
structure and language consistent with first-order predicate logic, first described in 1969 by Edgar F.
Codd.[1][2] In the relational model of a database, all data is represented in terms of tuples, grouped
into relations. A database organized in terms of the relational model is a relational database.

The purpose of the relational model is to provide a declarative method for specifying data and
queries: users directly state what information the database contains and what information they want
from it, and let the database management system software take care of describing data structures
for storing the data and retrieval procedures for answering queries.

Advantages and Disadvantages of using

relational databases
Advantages

Disadvantages

1. Ease of use:
2. Flexibility:
3. Precision:
4. Security:
5. Data Independence:
6. Data Manipulation Language:

1. Performance:
2. Physical Storage Consumption
Slow extraction of meaning from data

Object database
An object database (also object-oriented database management system, OODBMS) is
a database management system in which information is represented in the form of objects as used
in object-oriented programming. Object databases are different from relational databases which are
table-oriented. Object-relational databases are a hybrid of both approaches.
Object databases have been considered since the early 1980s.[2]

Characteristic

Hierarchical model

Network model

Relational model

Data structure

One to many or one to one

relationships

Allowed the network model to

support
many
to
many
relationships

One
to
One,
One to many, Many to
many relationships

In hierarchical model only one-to-many or one-to-one relationships can be exist. But in network data model
makes it possible to map many to many relationships In relational each record can have multiple parents and

multiple child records. In effect, it supports many to many relationships

Data structure

Based on
relationship

parent

child

A record can have many parents

as well as many children.

Based on relational data

structures

In hierarchical model relationship based in terms of parent child. So a child may only have one parent but a parent
can have multiple children. But in network data model a record can have many parents as well as many children.
Relational data model is based on relational data structures

Data
manipulation

Does not provide an

independent stand alone query
interface

CODASYL (Conference on
Data Systems Languages)

Relational databases are

what brings many sources
into a common query
(such as SQL)

In relational database it use powerful operations such as SQL languages or query by example are used to
manipulate data stored in the database But in hierarchical data model it does not
provide an independent stand alone query interface while network model uses CODASYL
Data
manipulation

retrieve algorithms are

complex and asymmetric

Retrieve algorithms are complex

and symmetric

Retrieve algorithms are

simple and symmetric

In hierarchical data model and network model retrieve algorithms are complex and symmetric But in relational
data model retrieve algorithms are simple and symmetric

Data integrity

Cannot insert the information

of a child who does not have
any parent.

Does not suffer form any

insertion anomaly.

Does not suffer from any

insert anomaly.

In hierarchical data model we cannot insert the information of a child who does not have any parent. But in
network model does not suffer form any insertion anomaly. relational model does not suffer from any insert
anomaly

Data integrity

Multiple occurrences of child

records which lead to
problems of inconsistency
during the update operation

Free from update anomalies.

Free form update

anomalies

In network model it is free from update anomalies because there is only a single occurrence for each record set.In
relational model it also free form update anomalies because it removes the redundancy of data by proper
designing through normalization process. But in hierarchical model there are multiple occurrences of child
records. which lead to problems of inconsistency during the update operation

Data intergirty

Deletion of parent results in

deletion of child records

Free from delete anomalies

Free from delete

anomalies

In hierarchical model it is based on parent child relationship and deletion of parent results in deletion of child
records .But in network model and in relational model it is free from deletion anomalies. Because information is
stored in different tables.

What is a 'Feasibility Study'

A feasibility study is an analysis of how successfully a project can be completed, accounting
for factors that affect it such as economic, technological, legal and scheduling factors.
Project managers use feasibility studies to determine potential positive and negative
outcomes of a project before investing a considerable amount of time and money into it.

Q.1 What do you mean by GUI.

Ans. Software that works at the point of contact (interface) between a

computer and its user, and which employs graphic elements (dialog
boxes, icons, menus, scroll bars) instead of text characters to let the
user give commands to the computer or to manipulate what is on the
screen. GUI elements are usually accessed through a pointing device
such as a mouse, pen, or stylus.
Q.2 Why back-end is difficult to use?

Back-End Developing:

+ If you are good at math and logic, you might be a really good programmer
+ Result is either correct or wrong
+ You don't have to meet that many people
+ Higher salary
+ Everybody is looking for a back-end developers
+ Companies will take care of you and you can wake up later
- You have to be really good

 - Higher responsibility (imagine writing a crappy code for a bank app)

- A lot of debugging
Front-End Developing:

+ You can be really creative

+ HTML, CSS, JS and Ajax are not that hard to learn
+ It's easiers to earn money as a freelancer
+ You meet your customers and can talk with them
- You meet your customers and talk with them
- "Being a coder is nothing hard"
- Sometimes it's difficult to have a consensus with back-end developers
- Different browsers & resolutions

SDLC Waterfall
The waterfall figure above illustrates a general waterfall model which could apply to any
computer system development. It shows the process as a strict sequence of steps where the
output of one step is the input to the next and all of one step has to be completed before moving
onto the next.
We can use the waterfall process as a means of identifying the tasks that are required, together
with the input and output for each activity. What is important is the scope of the activities, which
can be summarised as follows:

Establishing requirements involves consultation with, and agreement

among, stakeholders as to what they want of a system, expressed as a statement of

requirements.
Analysis starts by considering the statement of requirements and finishes by producing a

system specification. The specification is a formal representation of what a system should

do, expressed in terms that are independent of how it may be realized.
Design begins with a system specification and produces design documents, and provides

a detailed description of how a system should be constructed.

Implementation is the construction of a computer system according to a given design
document and taking account of the environment in which the system will be operating (for
example specific hardware or software available for the development). Implementation may
be staged, usually with an initial system than can be validated and tested before a final
system is released for use.

Testing compares the implemented system against the design documents and
requirements specification and produces an acceptance report or, more usually, a list of
errors and bugs that require a review of the analysis, design and implementation processes
to correct (testing is usually the task that leads to the waterfall model iterating through the
life cycle).
Maintenance involves dealing with changes in the requirements, or the implementation
environment, bug fixing or porting of the system to new environments (for example
migrating a system from a standalone PC to a UNIX workstation or a networked
environment). Since maintenance involves the analysis of the changes required, design of a
solution, implementation and testing of that solution over the lifetime of a maintained
software system, the waterfall life cycle will be repeatedly revisited.

Database Life Cycle

We can use the waterfall cycle as the basis for a model of database development which
incorporates three assumptions:

We can separate the development of a database that is, specification and creation of a

schema to define data in a database from the user processes that make use of the database.
We can use the three-schema architecture as a basis for distinguishing the activities

associated with a schema.

We can represent the constraints to enforce the semantics of the data once, within a

database, rather than within every user process that uses the data.
http://www.oercommons.org/courses/the-database-development-life-cycle/view

Source: http://www.oercommons.org/courses/the-database-development-life-cycle/view
Using these assumptions, the diagram above represents a model of the activities and their outputs
for database development. It is applicable to any class of DBMS (database management system),
not just a relational approach.
http://cnx.org/content/m28139/latest/
Database Application Development is the process of obtaining real-world requirements,
analyzing requirements, designing the data and functions of the system and then implementing
the operations in the system.
http://www.oercommons.org/courses/the-database-development-life-cycle/view

Requirements gathering
The first step is Requirements Gathering. During this step, the database designers have to
interview the customers (database users) to understand the proposed system, obtain and
document the data and functional requirements. The result of this step is a document including
the detail requirements provided by the users.
Establishing requirements involves consultation with, and agreement among, all the users as to
what persistent data they want to store along with an agreement as to the meaning and
interpretation of the data elements. The data administrator plays a key role in this process as they
overview the business, legal and ethical issues within the organization that impact on the data
requirements.

The data requirements document is used to confirm the understanding of requirements with
users. To make sure that it is easily understood, it should not be overly formal or highly encoded.
The document should give a concise summary of all users requirements not just a collection of
individuals requirements as the intention is to develop a single shared database.
The requirements should not describe how the data is to be processed, but rather what the data
items are, what attributes they have, what constraints apply and the relationships that hold
between the data items.

Analysis
Data analysis begins with the statement of data requirements and then produces a conceptual
data model. The aim of analysis is to obtain a detailed description of the data that will suit user
requirements so that both high and low level properties of data and their use are dealt with. These
include properties such as the possible range of values that can be permitted for attributes such
as, in the School Database example; for instance, the Student course code, course title and credit
points.
The conceptual data model provides a shared, formal representation of what is being
communicated between clients and developers during database development it is focused on
the data in a database, irrespective of the eventual use of that data in user processes or
implementation of the data in specific computer environments. Therefore, a conceptual data
model is concerned with the meaning and structure of data, but not with the details affecting how
they are implemented.
The conceptual data model then is a formal representation of what data a database should contain
and the constraints the data must satisfy. This should be expressed in terms that are independent
of how the model may be implemented. As a result, analysis focuses on What is required? not
How is it achieved?
http://www.oercommons.org/courses/the-database-development-life-cycle/view

Logical Design
Database design starts with a conceptual data model and produces a specification of a logical
schema; this will determine the specific type of database system (network, relational, objectoriented) that is required. The relational representation is still independent of any specific
DBMS, it is another conceptual data model.

We can use a relational representation of the conceptual data model as input to the logical design
process. The output of this stage is a detailed relational specification, the logical schema, of all
the tables and constraints needed to satisfy the description of the data in the conceptual data
model. It is during this design activity that choices are made as to which tables are most
appropriate for representing the data in a database. These choices must take into account various
design criteria including, for example, flexibility for change, control of duplication and how best
to represent the constraints. It is the tables defined by the logical schema that determine what
data are stored and how they may be manipulated in the database.
Database designers familiar with relational databases and SQL might be tempted to go directly to
implementation after they have produced a conceptual data model. However, such a direct
transformation of the relational representation to SQL tables does not necessarily result in a
database that has all the desirable properties: completeness, integrity, flexibility, efficiency and
usability. A good conceptual data model is an essential first step towards a database with these
properties, but that does not mean that the direct transformation to SQL tables automatically
produces a good database. This first step will accurately represent the tables and constraints
needed to satisfy the conceptual data model description, and so satisfies the completeness and
integrity requirements, but it may be inflexible or offer poor usability. The first design is
thenflexed to improve the quality of the database design. Flexing is a term that is intended to
capture the simultaneous ideas of bending something for a different purpose and weakening
aspects of it as it is bent.
The figure below summarizes the iterative (repeated) steps involved in database design, based on
the overview given. Its main purpose is to distinguish the general issue of what tables should be
used from the detailed definition of the constituent parts of each table these tables are
considered one at a time, although they are not independent of each other. Each iteration that
involves a revision of the tables would lead to a new design; collectively they are usually
referred to as second-cut designs, even if the process iterates for more than a single loop.
http://www.oercommons.org/courses/the-database-development-life-cycle/view

Source: http://www.oercommons.org/courses/the-database-development-life-cycle/view
First, for a given conceptual data model it is not necessary that all the user requirements it
represents have to be satisfied by a single database. There can be various reasons for the
development of more than one database, such as the need for independent operation in different
locations or departmental control over their data. However, if the collection of databases
contains duplicated data and users need to access data in more than one database, then there are
possible reasons that the one database can satisfy multiple requirements or issues related to data
replication and distribution need to be examined.
Second, one of the assumptions about database development is that we can separate the
development of a database from the development of user processes that make use of it. This is
based on the expectation that, once a database has been implemented, all data required by
currently identified user processes have been defined and can be accessed; but we also require
flexibility to allow us to meet future requirements changes. In developing a database for some
applications it may be possible to predict the common requests that will be presented to the
database and so we can optimize our design for the most common requests.
Third, at a detailed level, many aspects of database design and implementation depend on the
particular DBMS being used. If the choice of DBMS is fixed or made prior to the design task,
that choice can be used to determine design criteria rather than waiting until implementation.
That is, it is possible to incorporate design decisions for a specific DBMS rather than produce a
generic design and then tailor it to the DBMS during implementation.
It is not uncommon to find that a single design cannot simultaneously satisfy all the properties of
a good database. So it is important that the designer has prioritized these properties (usually
using information from the requirements specification), for example, to decide if integrity is

more important than efficiency and whether usability is more important than flexibility in a given
development.
At the end of our design stage the logical schema will be specified by SQL data definition
language (DDL) statements, which describe the database that needs to be implemented to meet
the user requirements.
http://www.oercommons.org/courses/the-database-development-life-cycle/view

Implementation
Implementation involves the construction of a database according to the specification of a logical
schema. This will include the specification of an appropriate storage schema, security
enforcement, external schema, and so on. Implementation is heavily influenced by the choice of
available DBMS, database tools and operating environment. There are additional tasks beyond
simply creating a database schema and implementing the constraints data must be entered into
the tables, issues relating to the users and user processes need to be addressed and the
management activities associated with wider aspects of corporate data management need to be
supported. In keeping with the DBMS approach we want as many of these concerns as possible
to be addressed within the DBMS. We look at some of these concerns briefly now.
In practice, implementation of the logical schema in a given DBMS requires a very detailed
knowledge of the specific features and facilities that the DBMS has to offer. In an ideal world,
and in keeping with good software engineering practice, the first stage of implementation would
involve matching the design requirements with the best available implementing tools and then
using those tools for the implementation. In database terms, this might involve choosing vendor
products whos DBMS and SQL variants are most suited to the database we need to implement.
However, we dont live in an ideal world and more often than not, hardware choice and decisions
regarding the DBMS will have been made well in advance of consideration of the database
design. Consequently, implementation can involve additional flexing of the design to overcome
any software or hardware limitations.

Realising the design

After the Logical Design has been created, we need our database to be created according to the
definitions we have produced. For an implementation with a relational DBMS, this will probably
involve the use of SQL to create tables and constraints that satisfy the logical schema description
and the choice of appropriate storage schema (if the DBMS permits that level of control).

One way to achieve this is to write the appropriate SQL DDL statements into a file that can be
executed by a DBMS so that there is an independent record, a text file, of the SQL statements
defining the database. Another method is to work interactively using a database tool like SQL
Server Management Studio or Microsoft Access. Whatever mechanism is used to implement the
logical schema, the result is that a database, with tables and constraints, is defined but will
contain no data for the user processes.

Populating the database

After a database has been created, there are two ways of populating the tables either from
existing data, or through the use of the user applications developed for the database.
For some tables, there may be existing data from another database or data files. For example, in
establishing a database for a hospital you would expect that there are already some records of all
the staff that have to be included in the database. Data might also be bought in from an outside
agency (address lists are frequently brought in from external companies) or produced during a
large data entry task (converting hard-copy manual records into computer files can be done by a
data entry agency). In such situations the simplest approach to populate the database is to use the
import and export facilities found in the DBMS.
Facilities to import and export data in various standard formats are usually available (these
functions are also known in some systems as loading and unloading data). Importing enables a
file of data to be copied directly into a table. When data are held in a file format that is not
appropriate for using the import function then it is necessary to prepare an application program
that reads in the old data, transforms them as necessary and then inserts them into the database
using SQL code specifically produced for that purpose. The transfer of large quantities of
existing data into a database is referred to as a bulk load. Bulk loading of data may involve very
large quantities of data being loaded, one table at a time so you may find that there are DBMS
facilities to postpone constraint checking until the end of the bulk loading.
http://www.oercommons.org/courses/the-database-development-life-cycle/view

Guidelines For Developing An ER Diagram

NOTE: These are general guidelines which will assist in developing a strong basis for the actual
database design (the logical model)
1. Document all entities discovered during the information gathering stage.

2. Document all attributes that belong to each entity. Select candidate and primary keys. Ensure
that all non-key attributes for each entity are full-functionally dependent on the primary key.
3. Develop an initial E-R diagram and review with appropriate personnel. (Remember that this is
an iterative process).
4. Create new entities (tables) for multi-valued attributes and repeating groups. Incorporate these
new entities (tables) in the E-R diagram. Review with appropriate personnel.
5. Verify E-R modeling by normalizing tables.

What is SDLC?
SDLC is a process followed for a software project, within a software
organization. It consists of a detailed plan describing how to develop,
maintain, replace and alter or enhance specific software. The life cycle
defines a methodology for improving the quality of software and the overall
development process.
The following figure is a graphical representation of the various stages of a
typical SDLC.

A typical Software Development life cycle consists of the following stages:

Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in
SDLC. It is performed by the senior members of the team with inputs from
the customer, the sales department, market surveys and domain experts in
the industry. This information is then used to plan the basic project
approach and to conduct product feasibility study in the economical,
operational, and technical areas.
Planning for the quality assurance requirements and identification of the
risks associated with the project is also done in the planning stage. The
outcome of the technical feasibility study is to define the various technical
approaches that can be followed to implement the project successfully with
minimum risks.

Stage 2: Defining Requirements

Once the requirement analysis is done the next step is to clearly define and
document the product requirements and get them approved from the
customer or the market analysts. This is done through .SRS. . Software
Requirement Specification document which consists of all the product
requirements to be designed and developed during the project life cycle.

Stage 3: Designing the product architecture

SRS is the
architecture
specified in
architecture

reference for product architects to come out with the best

for the product to be developed. Based on the requirements
SRS, usually more than one design approach for the product
is proposed and documented in a DDS - Design Document

Specification.
This DDS is reviewed by all the important stakeholders and based on
various parameters as risk assessment, product robustness, design
modularity , budget and time constraints , the best design approach is
selected for the product.
A design approach clearly defines all the architectural modules of
product along with its communication and data flow representation with
external and third party modules (if any). The internal design of all
modules of the proposed architecture should be clearly defined with
minutest of the details in DDS.

the
the
the
the

Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built.
The programming code is generated as per DDS during this stage. If the
design is performed in a detailed and organized manner, code generation
can be accomplished without much hassle.
Developers have to follow the coding guidelines defined by their
organization and programming tools like compilers, interpreters, debuggers
etc are used to generate the code. Different high level programming
languages such as C, C++, Pascal, Java, and PHP are used for coding. The
programming language is chosen with respect to the type of software being
developed.

Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC
models, the testing activities are mostly involved in all the stages of SDLC.
However this stage refers to the testing only stage of the product where
products defects are reported, tracked, fixed and retested, until the product
reaches the quality standards defined in the SRS.

Stage 6: Deployment in the Market and

Maintenance
Once the product is tested and ready to be deployed it is released formally
in the appropriate market. Sometime product deployment happens in
stages as per the organizations. business strategy. The product may first be
released in a limited segment and tested in the real business environment
(UAT- User acceptance testing).
Then based on the feedback, the product may be released as it is or with
suggested enhancements in the targeting market segment. After the
product is released in the market, its maintenance is done for the existing
customer base.

SDLC Models
There are various software development life cycle models defined and
designed which are followed during software development process. These
models are also referred as "Software Development Process Models". Each
process model follows a Series of steps unique to its type, in order to
ensure success in process of software development.
Following are the most important and popular SDLC models followed in the
industry:

Waterfall Model

Iterative Model

Spiral Model

V-Model

Big Bang Model

The other related methodologies are Agile Model, RAD Model, Rapid
Application Development and Prototyping Models.
The Waterfall Model was first Process Model to be introduced. It is also
referred to as a linear-sequential life cycle model. It is very simple to
understand and use. In a waterfall model, each phase must be completed
before the next phase can begin and there is no overlapping in the phases.
Waterfall model is the earliest SDLC approach that was used for software
development .
The waterfall Model illustrates the software development process in a linear
sequential flow; hence it is also referred to as a linear-sequential life cycle
model. This means that any phase in the development process begins only
if the previous phase is complete. In waterfall model phases do not overlap.

Waterfall Model design

Waterfall approach was first SDLC Model to be used widely in Software
Engineering to ensure success of the project. In "The Waterfall" approach,
the whole process of software development is divided into separate phases.
In Waterfall model, typically, the outcome of one phase acts as the input for
the next phase sequentially.
Following is a diagrammatic representation of different phases of waterfall
model.

The sequential phases in Waterfall model are:

Requirement Gathering and analysis: All possible requirements of the

system to be developed are captured in this phase and documented in a
requirement specification doc.

System Design: The requirement specifications from first phase are studied in
this phase and system design is prepared. System Design helps in specifying
hardware and system requirements and also helps in defining overall system
architecture.

Implementation: With

inputs

from

system

design,

the

system

is

first

developed in small programs called units, which are integrated in the next
phase. Each unit is developed and tested for its functionality which is referred to
as Unit Testing.

Integration and Testing: All the units developed in the implementation phase
are integrated into a system after testing of each unit. Post integration the
entire system is tested for any faults and failures.

Deployment of system: Once the functional and non functional testing is

done, the product is deployed in the customer environment or released into the
market.

Maintenance: There are some issues which come up in the client environment.
To fix those issues patches are released. Also to enhance the product some
better versions are released. Maintenance is done to deliver these changes in
the customer environment.

All these phases are cascaded to each other in which progress is seen as
flowing steadily downwards (like a waterfall) through the phases. The next
phase is started only after the defined set of goals are achieved for previous
phase and it is signed off, so the name "Waterfall Model". In this model
phases do not overlap.

Waterfall Model Application

Every software developed is different and requires a suitable SDLC
approach to be followed based on the internal and external factors. Some
situations where the use of Waterfall model is most appropriate are:

Requirements are very well documented, clear and fixed.

Product definition is stable.

Technology is understood and is not dynamic.

There are no ambiguous requirements.

Ample resources with required expertise are available to support the product.

The project is short.

Waterfall Model Pros & Cons

Advantage
The advantage of waterfall development is that it allows for
departmentalization and control. A schedule can be set with deadlines for
each stage of development and a product can proceed through the
development process model phases one by one.
Development moves from concept, through design, implementation, testing,
installation, troubleshooting, and ends up at operation and maintenance.
Each phase of development proceeds in strict order.

Disadvantage
The disadvantage of waterfall development is that it does not allow for
much reflection or revision. Once an application is in the testing stage, it is
very difficult to go back and change something that was not welldocumented or thought upon in the concept stage.
The following table lists out the pros and cons of Waterfall model:
Pros

Cons

Simple

and

easy

to

understand and use

No working software is produced until

late during the life cycle.

Easy to manage due to the

High amounts of risk and uncertainty.

Not a good model for complex and

rigidity of the model . each

phase

has

specific

object-oriented projects.

deliverables and a review

process.

projects.

Phases are processed and

completed one at a time.
Works
projects

well

for

Poor model for long and ongoing

Not suitable for the projects where

smaller

requirements are at a moderate to

where

high risk of changing. So risk and

requirements are very well

uncertainty is high with this process

understood.

model.

Clearly defined stages.

Well understood milestones.

It is difficult to measure progress

within stages.

Easy to arrange tasks.

Process and results are well

Cannot

accommodate

changing

requirements.

documented.

Adjusting scope during the life cycle

can end a project.

Integration is done as a "big-bang. at

the very end, which doesn't allow
identifying
business
early.

any

technological

bottleneck

or

or

challenges