UNIT-1

Systems Concept; Characteristics of a System

Systems Concept
A system is an orderly grouping of interdependent components linked together according to a
plan to achieve a specific objective.

The study of system concepts has three basic implications:

1. A system must be designed to achieve a predetermined objective.

2. Interrelationships and interdependence must exist among the components.
3. The objectives of the organization as a whole have a higher priority than the
objectives of its subsystems.

Characteristics of a system:

1. Organization:

It implies structure and order. It is the arrangement of components that helps to achieve
objectives.

2. Interaction:

It refers to the manner in which each component functions with other components of the
system.

3. Interdependence:

It means that parts of the organization or computer system depend on one another. They are
coordinated and linked together according to a plan. One subsystem depends on the output of
another subsystem for proper functioning.

4. Integration:

It refers to the holism of systems. It is concerned with how a system is tied together.

5. Central Objective:

A system should have a central objective. Objectives may be real or stated. Although a stated
objective may be the real objective, it is not uncommon for an organization to state one
objective and operate to achieve another. The important point is that users must know the
central objective of a computer application early in the analysis for a successful design and
conversion.
 Elements of System; Types of Systems
Elements of a System:

1. Outputs and inputs:

A major objective of a system is to produce an output that has value to its user. In order to get
a good output, inputs to system must be appropriate. It is important to point out here that
determining the output is a first step in specifying the nature, amount and regularity of the
input needed to operate a system.

2. Processors:

It is the element of a system that involves the actual transformation of input into output. It is
the operational component of a system. Processors may modify the input totally or partially,
depending on the specifications of the output. In some cases, input is also modified to enable
the processor to handle the transformation.

3. Control:

The control elements guide the system. It is the decision-making subsystem that controls the
pattern of activities governing input, processing, and output.

4. Feedback:

Feedback measures output against a standard in some form of cybernetic procedure that
includes communication and control.

Feedback may be positive or negative, routine or informational. Positive feedback reinforces

the performance of the system. It is routine in nature. Negative feedback generally provides
the controller with information for action.

5. Environment:

The environment is the “supra-system” within which an organization operates. It is the source
of external elements that impinge on the system. In fact, it often determines how a system
must function.

6. Boundaries and Interfaces:

A system should be defined by its boundaries- the limits that identify its components,
processes, and interrelationships when it interfaces with another system.
 Types of System
Physical or Abstract Systems

 Physical systems are tangible entities. We can touch and feel them.
 Physical System may be static or dynamic in nature. For example, desks and chairs
are the physical parts of computer center which are static. A programmed computer is a
dynamic system in which programs, data, and applications can change according to the user’s
needs.
 Abstract systems are non-physical entities or conceptual that may be formulas,
representation or model of a real system.

Open or Closed Systems

 An open system must interact with its environment. It receives inputs from and
delivers outputs to the outside of the system. For example, an information system which must
adapt to the changing environmental conditions.
 A closed system does not interact with its environment. It is isolated from
environmental influences. A completely closed system is rare in reality.

Adaptive and Non Adaptive System

 Adaptive System responds to the change in the environment in a way to improve their
performance and to survive. For example, human beings, animals.
 Non Adaptive System is the system which does not respond to the environment. For
example, machines.

Permanent or Temporary System

 Permanent System persists for long time. For example, business policies.
 Temporary System is made for specified time and after that they are demolished. For
example, A DJ system is set up for a program and it is dissembled after the program.

Natural and Manufactured System

 Natural systems are created by the nature. For example, Solar system, seasonal
system.
 Manufactured System is the man-made system. For example, Rockets, dams, trains.

Deterministic or Probabilistic System

 Deterministic system operates in a predictable manner and the interaction between

system components is known with certainty. For example, two molecules of hydrogen and
one molecule of oxygen makes water.
 Probabilistic System shows uncertain behavior. The exact output is not known. For
example, Weather forecasting, mail delivery.

Social, Human-Machine, Machine System

 Social System is made up of people. For example, social clubs, societies.
 In Human-Machine System, both human and machines are involved to perform a
particular task. For example, Computer programming.
 Machine System is where human interference is neglected. All the tasks are
performed by the machine. For example, an autonomous robot.

Man–Made Information Systems

 It is an interconnected set of information resources to manage data for particular

organization, under Direct Management Control (DMC).
 This system includes hardware, software, communication, data, and application for
producing information according to the need of an organization.

Man-made information systems are divided into three types −

 Formal Information System: It is based on the flow of information in the form of

memos, instructions, etc., from top level to lower levels of management.
 Informal Information System: This is employee based system which solves the day
to day work related problems.
 Computer Based System: This system is directly dependent on the computer for
managing business applications. For example, automatic library system, railway reservation
system, banking system, etc.
System Development Life Cycle


Stage Key Question Result

1. Recognition of need Statement of scope and

Preliminary survey/ objectives
What is the problem or
opportunity?
Initial investigation Performance criteria

2. Feasibility Study What are the user’s Technical / behavioral

demonstrable needs?
Evaluation of existing feasibility

system and procedures Cost / benefit analysis

Is the problem worth solving?
Analysis of alternative System scope and objectives
How can the problem be
redefined?
candidate systems Statement f new scope and

Cost estimates Objectives

What must be done to solve the Logical model of system

3. Analysis Detailed problem? e.g. data dictionary, data
evaluation of present What are the facts? flow diagrams Pertinent data
system Data collection

Design Design of alternative

General design solutions

specifications Final cost/ benefit analysis

Detailed design In general, how must the Hardware specifications

problem be solved?
specifications Specifically, how must the Cost estimates
problem be solved?
Output, Input, Files Implementation
What is the system
(processing) flow?
Procedures specifications
Does the user approve the
Program construction system? Implementation schedule

Testing How well do individual Approval of systems by user

Unit Testing programs / modules test out? Programs, Test plans

How ready are
Combined module Security, audit and operating
programs for acceptance test?
Testing procedures

User acceptance Actual hardware use

Testing Formal system test

5. Implementation What is the actual Training program

User training operation? Are user User-friendly documentation
 manuals ready? Are
File / system
these delays in loading
Conversion
files?

6. Post-implementation
and maintenance
Is the key system User requirements met
Evaluation running? Should the User standards met

Maintenance system be modified? Satisfied user

Enhancements

Case Tools for Analysts

CASE stands for Computer Aided Software Engineering. It means, development and
maintenance of software projects with help of various automated software tools.

CASE Tools
CASE tools are set of software application programs, which are used to automate SDLC
activities. CASE tools are used by software project managers, analysts and engineers to
develop software system.

There are number of CASE tools available to simplify various stages of Software
Development Life Cycle such as Analysis tools, Design tools, Project management tools,
Database Management tools, Documentation tools are to name a few.

Use of CASE tools accelerates the development of project to produce desired result and
helps to uncover flaws before moving ahead with next stage in software development.

Components of CASE Tools

CASE tools can be broadly divided into the following parts based on their use at a
particular SDLC stage:

 Central Repository: CASE tools require a central repository, which can serve as

a source of common, integrated and consistent information. Central repository is a
central place of storage where product specifications, requirement documents, related
reports and diagrams, other useful information regarding management is stored. Central
repository also serves as data dictionary.
 Upper Case Tools: Upper CASE tools are used in planning, analysis and design
stages of SDLC.
 Lower Case Tools: Lower CASE tools are used in implementation, testing and
maintenance.
 Integrated Case Tools: Integrated CASE tools are helpful in all the stages of
SDLC, from Requirement gathering to Testing and documentation.

CASE tools can be grouped together if they have similar functionality, process activities
and capability of getting integrated with other tools.

Case Tools Types

Diagram tools

These tools are used to represent system components, data and control flow among
various software components and system structure in a graphical form. For example,
Flow Chart Maker tool for creating state-of-the-art flowcharts.

Process Modeling Tools

Process modeling is method to create software process model, which is used to develop
the software. Process modeling tools help the managers to choose a process model or
modify it as per the requirement of software product. For example, EPF Composer

Project Management Tools

These tools are used for project planning, cost and effort estimation, project scheduling
and resource planning. Managers have to strictly comply project execution with every
mentioned step in software project management. Project management tools help in
storing and sharing project information in real-time throughout the organization. For
example, Creative Pro Office, Trac Project, Basecamp.
 Documentation Tools

Documentation in a software project starts prior to the software process, goes

throughout all phases of SDLC and after the completion of the project.

Documentation tools generate documents for technical users and end users. Technical
users are mostly in-house professionals of the development team who refer to system
manual, reference manual, training manual, installation manuals etc. The end user
documents describe the functioning and how-to of the system such as user manual. For
example, Doxygen, DrExplain, Adobe RoboHelp for documentation.

Analysis Tools

These tools help to gather requirements, automatically check for any inconsistency,
inaccuracy in the diagrams, data redundancies or erroneous omissions. For example,
Accept 360, Accompa, CaseComplete for requirement analysis, Visible Analyst for total
analysis.

Design Tools

These tools help software designers to design the block structure of the software, which
may further be broken down in smaller modules using refinement techniques. These
tools provides detailing of each module and interconnections among modules. For
example, Animated Software Design

Configuration Management Tools

An instance of software is released under one version. Configuration Management tools
deal with:

 Version and revision management

 Baseline configuration management
 Change control management

CASE tools help in this by automatic tracking, version management and release
management. For example, Fossil, Git, Accu REV.

Change Control Tools

These tools are considered as a part of configuration management tools. They deal with
changes made to the software after its baseline is fixed or when the software is first
released. CASE tools automate change tracking, file management, code management
and more. It also helps in enforcing change policy of the organization.

Programming Tools
These tools consist of programming environments like IDE (Integrated Development
Environment), in-built modules library and simulation tools. These tools provide
comprehensive aid in building software product and include features for simulation and
testing. For example, Cscope to search code in C, Eclipse.

Prototyping Tools
Software prototype is simulated version of the intended software product. Prototype
provides initial look and feel of the product and simulates few aspect of actual product.

Prototyping CASE tools essentially come with graphical libraries. They can create
hardware independent user interfaces and design. These tools help us to build rapid
prototypes based on existing information. In addition, they provide simulation of software
prototype. For example, Serena prototype composer, Mockup Builder.

Web Development Tools

These tools assist in designing web pages with all allied elements like forms, text, script,
graphic and so on. Web tools also provide live preview of what is being developed and
how will it look after completion. For example, Fontello, Adobe Edge Inspect, Foundation
3, Brackets.

Quality Assurance Tools

Quality assurance in a software organization is monitoring the engineering process and
methods adopted to develop the software product in order to ensure conformance of
quality as per organization standards. QA tools consist of configuration and change
control tools and software testing tools. For example, SoapTest, AppsWatch, JMeter.

Maintenance Tools
Software maintenance includes modifications in the software product after it is delivered.
Automatic logging and error reporting techniques, automatic error ticket generation and
root cause Analysis are few CASE tools, which help software organization in
maintenance phase of SDLC. For example, Bugzilla for defect tracking, HP Quality
Center.

Role of System Analyst
A system analyst is responsible for analyzing, designing and implementing systems to
fulfill organizational needs. He/she plays a vital role in making operational the
management information system. The role of the system analyst has however changed.

The role of the analyst has however changed with time. Now a system analyst is seen
more as a change agent responsible for delivering value to an organization on its
investments in management information systems (that includes a heavy dose of
information communication technology investment). A dictionary definition of a system
analyst (as per Random House Dictionary) defines it as, ‘a person who conducts a
methodical study and evaluation of an activity such as business to identify its desired
objectives in order to determine procedures by which these objectives can be gained.
 An organization requires system analysts as line managers normally do not have an
understanding of the kind of information-based solutions that are possible for their
business problems. A system analysts bridges this gap as he/she is has a thorough
knowledge of both the business systems and business processes. A system analyst is
therefore in a position to provide information system based solutions to organizations
after having studied the problem that the organization is facing. They understand both
business and technology. They study a business problem or opportunity and devise an
information system enabled solution for it by detailing the information system
specifications. This set of specification that the analyst delivers is in a technical format
which is easily understandable to a technical (IT) specialist. The technical specialist
might not understand the business issue, if it comes directly from the line managers as
he has very little knowledge of business processes. The system analyst then bridges the
gap between the two by translating and transforming the business problem/opportunity
into a information systems solution and supplying the specification of such a system to
the technologist who can then take up the task and build the actual system.

This may sound very easy but it is actually not an easy task. In most cases, the analyst
works as a change agent. When devising a solution, the analyst does not restrict him/
her to the immediate problem/opportunity at hand but also focuses on the future. This
requires that an analyst suggest some changes in the process of doing business to bring
in greater efficiency in future. Inevitably, the process of creating an information systems
enabled solution is coupled with the activity of business process reengineering through
which change is brought in. The analyst uses the opportunity of devising a solution to
bring in change and make the organization more efficient. Thus, a system analyst may
also be considered as a change agent.

As we have pointed out in the previous section, the role of the analyst encompasses
both the business and technology domain. In addition, the analyst also works, as a
change agent hence the work of an analyst not only requires very good understanding of
technical knowledge but also of business and interpersonal skills.

The interpersonal skills required by a system analyst are:

1. Communication: The analyst needs to be a very good communicator to

understand and communicate to the user group as well as to the1echnical specialists.
Sometimes the users may not be able to communicate their needs fully to the analyst,
but the analyst must be able to understand their needs from incomplete communication
of the users.
2. Foresightedness and vision: The analyst must have foresight and vision, so
that they can factor in the future requirement of the users even if they have not factored
that in the design. The analyst must also have vision with regard to the technological
changes. He/she must be able to predict where the business needs and technological
capabilities/constraints will be in the future. They should also clearly communicate that
the design holds good not only for the short term but also the long term.
3. Adaptability and flexibility skills: The analyst may be new to the environment
of the particular business but he/she has to be quick on the uptake and adapt fast to the
culture and environment of the organization. Some flexibility in the understanding of
problems is also required along with the flexibility to come up with alternative solutions.
4. Selling: The analyst needs to have flair to sell their ideas and solutions to the
users. Sometimes this may be difficult as the users and clients might not know what
 solution will serve them best. The analyst needs to employ his selling skills to convince
the users on the suitability of a solution.
5. Patience and rationality: The analyst needs to be patient and rational so that
he/she do not rush to a solution. If they make haste then they might miss critical
information about the problem/opportunity and end up promoting a wrong solution for the
users. Rationality is also a virtue for the system analyst, as this will help them in
analyzing the problem/opportunity with a clear mind without prejudice.
6. Sound temperament: The analyst needs to remain calm in the face of adverse
situations. Most of the time the critical data that the analyst seeks is hard to come by and
may be late in coming. The analyst will have to put up with all this and be clam in such
situations. Thus, the temperament that he exhibits will help him in devising an
appropriate solution for the client.
7. Management skills: These skills are an absolute necessity for any analyst. The
system analyst has to deliver in spite of several constraints hence they must have good
management skills to manage time and resources at their disposal. The particular
management skills that they need to have are:
1. Time management skills. This will help them adhere to the strict schedules
of the task.
2. Project management skills. This will help them manage the project within
the boundaries of time and cost.
3. Man management skills. The analyst will need human resource skills so
that they can manage people working under him. This skill will also help them to connect
to people in the client organization so that there is greater acceptability for their
solutions.
4. Team management skills. The analyst must be a team player. They have
to work in a team and they should ensure smooth team functioning.
5. Organizing and directing skills. These are basic managerial skills that the
analyst must have to conduct the analysis properly.
6. Negotiation skills. The analyst should be a good negotiator to get his way
around for the purposes of selling his solution and to get the relevant data from the
client.
8. Leadership quality: The analyst must exhibit leadership and take initiative to
understand issues pertaining to the organization and its line of business in a proactive
manner so that they are well aware of the associated issues of the problem/opportunity
as well.
9. Training and documentation capability: The analyst needs to be a good trainer
as they may be called upon to enhance the capacities of the users. Their documentation
skills will also have to be good, as without those skills the communication with the
technical team will remain incomplete.
10. Presentation skills: The analyst must have good presentation skills that will help
him to communicate better.
11. The technical skills required by the system analyst are:

 Creativity: This skill will ensure that the analyst can give the users novel
technical solutions for the same problem.
 Problem solving: This skill will help the analyst form a systems approach to
problem solving so that they are able to structure a problem even when there is none.
 Technical knowledge: The analyst needs to have concrete knowledge in the
technical domain so that they are able to generate alternative solutions to problem.
Without the technical know how they will not be able to develop the solution. The analyst
must also have a broad knowledge of the entire technical domain. The broad spectrum
 of knowledge will help them be flexible in their solution approach and will ensure that
they have a better understanding of the future of technologies.

Types of Data Models, ER Modeling

 
Data models define how the logical structure of a database is modeled. Data Models are
fundamental entities to introduce abstraction in a DBMS. Data models define how data is
connected to each other and how they are processed and stored inside the system.

The very first data model could be flat data-models, where all the data used are to be kept in
the same plane. Earlier data models were not so scientific, hence they were prone to introduce
lots of duplication and update anomalies.

Entity-Relationship Model
Entity-Relationship (ER) Model is based on the notion of real-world entities and relationships
among them. While formulating real-world scenario into the database model, the ER Model
creates entity set, relationship set, general attributes and constraints.

ER Model is best used for the conceptual design of a database.

ER Model is based on −

 Entitiesand their 
 Relationshipsamong entities.

These concepts are explained below.

 Entity− An entity in an ER Model is a real-world entity having properties

called attributes. Every attribute is defined by its set of values called domain. For example,
 in a school database, a student is considered as an entity. Student has various attributes like
name, age, class, etc.
 Relationship− The logical association among entities is called relationship.
Relationships are mapped with entities in various ways. Mapping cardinalities define the
number of association between two entities.

Mapping cardinalities −


o one to one
o one to many
o many to one
o many to many

Relational Model

The most popular data model in DBMS is the Relational Model. It is more scientific a model
than others. This model is based on first-order predicate logic and defines a table as an n-ary
relation.

The main highlights of this model are −

 Data is stored in tables called relations.

 Relations can be normalized.
 In normalized relations, values saved are atomic values.
 Each row in a relation contains a unique value.
 Each column in a relation contains values from a same domain.

Feasibility Study, Feasibility Considerations in

Feasibility Analysis
Feasibility Study can be considered as preliminary investigation that helps the management
to take decision about whether study of system should be feasible for development or not.

 It identifies the possibility of improving an existing system, developing a new system,

and produce refined estimates for further development of system.
 It is used to obtain the outline of the problem and decide whether feasible or
appropriate solution exists or not.
 The main objective of a feasibility study is to acquire problem scope instead of
solving the problem.
 The output of a feasibility study is a formal system proposal act as decision document
which includes the complete nature and scope of the proposed system.

Steps Involved in Feasibility Analysis

The following steps are to be followed while performing feasibility analysis −

 Form a project team and appoint a project leader.

 Develop system flowcharts.
 Identify the deficiencies of current system and set goals.
 Enumerate the alternative solution or potential candidate system to meet goals.
 Determine the feasibility of each alternative such as technical feasibility, operational
feasibility, etc.
 Weight the performance and cost effectiveness of each candidate system.
 Rank the other alternatives and select the best candidate system.
 Prepare a system proposal of final project directive to management for approval.
 Types of Feasibilities
Economic Feasibility

 It is evaluating the effectiveness of candidate system by using cost/benefit analysis

method.
 It demonstrates the net benefit from the candidate system in terms of benefits and
costs to the organization.
 The main aim of Economic Feasibility Analysis (EFS) is to estimate the economic
requirements of candidate system before investments funds are committed to proposal.
 It prefers the alternative which will maximize the net worth of organization by earliest
and highest return of funds along with lowest level of risk involved in developing the
candidate system.

Technical Feasibility

 It investigates the technical feasibility of each implementation alternative.

 It analyzes and determines whether the solution can be supported by existing
technology or not.
 The analyst determines whether current technical resources be upgraded or added it
that fulfill the new requirements.
 It ensures that the candidate system provides appropriate responses to what extent it
can support the technical enhancement.

Operational Feasibility

 It determines whether the system is operating effectively once it is developed and

implemented.
 It ensures that the management should support the proposed system and its working
feasible in the current organizational environment.
 It analyzes whether the users will be affected and they accept the modified or new
business methods that affect the possible system benefits.
 It also ensures that the computer resources and network architecture of candidate
system are workable.

Behavioral Feasibility
 It evaluates and estimates the user attitude or behavior towards the development of
new system.
 It helps in determining if the system requires special effort to educate, retrain,
transfer, and changes in employee’s job status on new ways of conducting business.

Schedule Feasibility

 It ensures that the project should be completed within given time constraint or
schedule.
 It also verifies and validates whether the deadlines of project are reasonable or not.

Unit-2
DFDs
Data flow diagram is graphical representation of flow of data in an information system. It
is capable of depicting incoming data flow, outgoing data flow and stored data. The DFD
does not mention anything about how data flows through the system.

There is a prominent difference between DFD and Flowchart. The flowchart depicts flow
of control in program modules. DFDs depict flow of data in the system at various levels.
DFD does not contain any control or branch elements.

Types of DFD
Data Flow Diagrams are either Logical or Physical.

 Logical DFD – This type of DFD concentrates on the system process, and flow
of data in the system. For example in a Banking software system, how data is moved
between different entities.
 Physical DFD – This type of DFD shows how the data flow is actually
implemented in the system. It is more specific and close to the implementation.

DFD Components
DFD can represent Source, destination, storage and flow of data using the following set
of components:
 Entities – Entities are source and destination of information data. Entities are
represented by a rectangles with their respective names.
 Process – Activities and action taken on the data are represented by Circle or
Round-edged rectangles.
 Data Storage – There are two variants of data storage – it can either be
represented as a rectangle with absence of both smaller sides or as an open-sided
rectangle with only one side missing.
 Data Flow – Movement of data is shown by pointed arrows. Data movement is
shown from the base of arrow as its source towards head of the arrow as destination.

Levels of DFD

 Level 0 – Highest abstraction level DFD is known as Level 0 DFD, which depicts
the entire information system as one diagram concealing all the underlying details. Level
0 DFDs are also known as context level DFDs.

 Level 1 – The Level 0 DFD is broken down into more specific, Level 1 DFD.
Level 1 DFD depicts basic modules in the system and flow of data among various
modules. Level 1 DFD also mentions basic processes and sources of information.
 Level 2 – At this level, DFD shows how data flows inside the modules mentioned
in Level 1.

Higher level DFDs can be transformed into more specific lower level DFDs with deeper
level of understanding unless the desired level of specification is achieved.

Form Design, Screen Design, Report Design

Both forms and reports are the product of input and output design and are business document
consisting of specified data. The main difference is that forms provide fields for data input
but reports are purely used for reading. For example, order forms, employment and credit
application, etc.

 During form designing, the designers should know −

o who will use them
o where would they be delivered
o the purpose of the form or report
 During form design, automated design tools enhance the developer’s ability to
prototype forms and reports and present them to end users for evaluation.

Objectives of Good Form Design

A good form design is necessary to ensure the following:
 To keep the screen simple by giving proper sequence, information, and clear captions.
 To meet the intended purpose by using appropriate forms.
 To ensure the completion of form with accuracy.
 To keep the forms attractive by using icons, inverse video, or blinking cursors etc.
 To facilitate navigation.

Types of Forms
Flat Forms

 It is a single copy form prepared manually or by a machine and printed on a paper.

For additional copies of the original, carbon papers are inserted between copies.
 It is a simplest and inexpensive form to design, print, and reproduce, which uses less
volume.

Unit Set/Snap out Forms

 These are papers with one-time carbons interleaved into unit sets for either
handwritten or machine use.
 Carbons may be either blue or black, standard grade medium intensity. Generally,
blue carbons are best for handwritten forms while black carbons are best for machine use.

Continuous strip/Fanfold Forms

 These are multiple unit forms joined in a continuous strip with perforations between
each pair of forms.
 It is a less expensive method for large volume use.

No Carbon Required (NCR) Paper

 They use carbonless papers which have two chemical coatings (capsules), one on the
face and the other on the back of a sheet of paper.
 When pressure is applied, the two capsules interact and create an image.

Structure Chart
Structure chart is a chart derived from Data Flow Diagram. It represents the system in more
detail than DFD. It breaks down the entire system into lowest functional modules, describes
functions and sub-functions of each module of the system to a greater detail than DFD.

Structure chart represents hierarchical structure of modules. At each layer a specific task is
performed.

Here are the symbols used in construction of structure charts –

 Module – It represents process or subroutine or task. A control module branches to

more than one sub-module. Library Modules are re-usable and invokable from any module.
 Condition – It is represented by small diamond at the base of module. It depicts that
control module can select any of sub-routine based on some condition.

 Jump – An arrow is shown pointing inside the module to depict that the control will
jump in the middle of the sub-module.

 Loop – A curved arrow represents loop in the module. All sub-modules covered by
loop repeat execution of module.
 Data flow – A directed arrow with empty circle at the end represents data flow.

 Control flow – A directed arrow with filled circle at the end represents control flow.

Data Base Definition, Equipment Specification

and Selection
Database is a systematic collection of data. Databases support storage and
manipulation of data. Databases make data management easy. Let’s discuss few
examples.

An online telephone directory would definitely use database to store data pertaining to
people, phone numbers, other contact details, etc.
 Your electricity service provider is obviously using a database to manage billing, client
related issues, to handle fault data, etc.

Let’s also consider the Facebook. It needs to store, manipulate and present data related
to members, their friends, member activities, messages, advertisements and lot more.

Equipment Specification and Selection

The software requirements are description of features and functionalities of the target
system. Requirements convey the expectations of users from the software product. The
requirements can be obvious or hidden, known or unknown, expected or unexpected
from client’s point of view.

Requirement Engineering
The process to gather the software requirements from client, analyze and document
them is known as requirement engineering.

The goal of requirement engineering is to develop and maintain sophisticated and

descriptive ‘System Requirements Specification’ document.

Requirement Engineering Process

It is a four step process, which includes:

 Feasibility Study
 Requirement Gathering
 Software Requirement Specification
 Software Requirement Validation

Let us see the process briefly –

Feasibility study
When the client approaches the organization for getting the desired product developed,
it comes up with rough idea about what all functions the software must perform and
which all features are expected from the software.

Referencing to this information, the analysts does a detailed study about whether the
desired system and its functionality are feasible to develop.

This feasibility study is focused towards goal of the organization. This study analyzes
whether the software product can be practically materialized in terms of implementation,
contribution of project to organization, cost constraints and as per values and objectives
of the organization. It explores technical aspects of the project and product such as
usability, maintainability, productivity and integration ability.

The output of this phase should be a feasibility study report that should contain adequate
comments and recommendations for management about whether or not the project
should be undertaken.
 Requirement Gathering
If the feasibility report is positive towards undertaking the project, next phase starts with
gathering requirements from the user. Analysts and engineers communicate with the
client and end-users to know their ideas on what the software should provide and which
features they want the software to include.

Software Requirement Specification

SRS is a document created by system analyst after the requirements are collected from
various stakeholders.

SRS defines how the intended software will interact with hardware, external interfaces,
speed of operation, response time of system, portability of software across various
platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations
etc.

The requirements received from client are written in natural language. It is the
responsibility of system analyst to document the requirements in technical language so
that they can be comprehended and useful by the software development team.

SRS should come up with following features:

 User Requirements are expressed in natural language.

 Technical requirements are expressed in structured language, which is used
inside the organization.
 Design description should be written in Pseudo code.
 Format of Forms and GUI screen prints.
 Conditional and mathematical notations for DFDs etc.

Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this
document are validated. User might ask for illegal, impractical solution or experts may
interpret the requirements incorrectly. This results in huge increase in cost if not nipped
in the bud. Requirements can be checked against following conditions –

 If they can be practically implemented

 If they are valid and as per functionality and domain of software
 If there are any ambiguities
 If they are complete
 If they can be demonstrated

Requirement Elicitation Process

Requirement elicitation process can be depicted using the folloiwng diagram:

 Requirements gathering – The developers discuss with the client and end users
and know their expectations from the software.
 Organizing Requirements – The developers prioritize and arrange the
requirements in order of importance, urgency and convenience.

 Negotiation & discussion – If requirements are ambiguous or there are some
conflicts in requirements of various stakeholders, if they are, it is then negotiated and
discussed with stakeholders. Requirements may then be prioritized and reasonably
compromised.

The requirements come from various stakeholders. To remove the ambiguity and
conflicts, they are discussed for clarity and correctness. Unrealistic requirements are
compromised reasonably.

 Documentation – All formal & informal, functional and non-functional

requirements are documented and made available for next phase processing.

Requirement Elicitation Techniques

Requirements Elicitation is the process to find out the requirements for an intended
software system by communicating with client, end users, system users and others who
have a stake in the software system development.

There are various ways to discover requirements

Interviews
Interviews are strong medium to collect requirements. Organization may conduct several
types of interviews such as:

 Structured (closed) interviews, where every single information to gather is

decided in advance, they follow pattern and matter of discussion firmly.
 Non-structured (open) interviews, where information to gather is not decided in
advance, more flexible and less biased.
 Oral interviews
 Written interviews
 One-to-one interviews which are held between two persons across the table.
 Group interviews which are held between groups of participants. They help to
uncover any missing requirement as numerous people are involved.

Surveys
Organization may conduct surveys among various stakeholders by querying about their
expectation and requirements from the upcoming system.

Questionnaires
A document with pre-defined set of objective questions and respective options is handed
over to all stakeholders to answer, which are collected and compiled.
 A shortcoming of this technique is, if an option for some issue is not mentioned in the
questionnaire, the issue might be left unattended.

Task analysis
Team of engineers and developers may analyze the operation for which the new system
is required. If the client already has some software to perform certain operation, it is
studied and requirements of proposed system are collected.

Domain Analysis
Every software falls into some domain category. The expert people in the domain can be
a great help to analyze general and specific requirements.

Brainstorming
An informal debate is held among various stakeholders and all their inputs are recorded
for further requirements analysis.

Prototyping
Prototyping is building user interface without adding detail functionality for user to
interpret the features of intended software product. It helps giving better idea of
requirements. If there is no software installed at client’s end for developer’s reference
and the client is not aware of its own requirements, the developer creates a prototype
based on initially mentioned requirements. The prototype is shown to the client and the
feedback is noted. The client feedback serves as an input for requirement gathering.

Observation
Team of experts visit the client’s organization or workplace. They observe the actual
working of the existing installed systems. They observe the workflow at client’s end and
how execution problems are dealt. The team itself draws some conclusions which aid to
form requirements expected from the software.

Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software development
project. Hence they must be clear, correct and well-defined.

A complete Software Requirement Specifications must be:

 Clear
 Correct
 Consistent
 Coherent
 Comprehensible
 Modifiable
 Verifiable
 Prioritized
 Unambiguous
 Traceable
 Credible source

Software Requirements
We should try to understand what sort of requirements may arise in the requirement
elicitation phase and what kinds of requirements are expected from the software system.

Broadly software requirements should be categorized in two categories:

Functional Requirements
Requirements, which are related to functional aspect of software fall into this category.

They define functions and functionality within and from the software system.

EXAMPLES –

 Search option given to user to search from various invoices.

 User should be able to mail any report to management.
 Users can be divided into groups and groups can be given separate rights.
 Should comply business rules and administrative functions.
 Software is developed keeping downward compatibility intact.

Non-Functional Requirements
Requirements, which are not related to functional aspect of software, fall into this
category. They are implicit or expected characteristics of software, which users make
assumption of.

Non-functional requirements include –

 Security
 Logging
 Storage
 Configuration
 Performance
 Cost
 Interoperability
 Flexibility
 Disaster recovery
 Accessibility

Requirements are categorized logically as

 Must Have : Software cannot be said operational without them.

 Should have : Enhancing the functionality of software.
 Could have : Software can still properly function with these requirements.
 Wish list : These requirements do not map to any objectives of software.

While developing software, ‘Must have’ must be implemented, ‘Should have’ is a matter
of debate with stakeholders and negation, whereas ‘could have’ and ‘wish list’ can be
kept for software updates.

User Interface requirements

UI is an important part of any software or hardware or hybrid system. A software is
widely accepted if it is –

 easy to operate
 quick in response
 effectively handling operational errors
 providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software. UI is the only
way for users to perceive the system. A well performing software system must also be
equipped with attractive, clear, consistent and responsive user interface. Otherwise the
functionalities of software system can not be used in convenient way. A system is said
be good if it provides means to use it efficiently. User interface requirements are briefly
mentioned below –

 Content presentation
 Easy Navigation
 Simple interface
 Responsive
 Consistent UI elements
 Feedback mechanism
 Default settings
 Purposeful layout
 Strategical use of color and texture.
 Provide help information
 User centric approach
 Group based view settings.

Software System Analyst

System analyst in an IT organization is a person, who analyzes the requirement of
proposed system and ensures that requirements are conceived and documented
properly & correctly. Role of an analyst starts during Software Analysis Phase of SDLC.
It is the responsibility of analyst to make sure that the developed software meets the
requirements of the client.

System Analysts have the following responsibilities:

 Analyzing and understanding requirements of intended software

 Understanding how the project will contribute in the organization objectives
 Identify sources of requirement
 Validation of requirement
 Develop and implement requirement management plan
 Documentation of business, technical, process and product requirements
 Coordination with clients to prioritize requirements and remove and ambiguity
 Finalizing acceptance criteria with client and other stakeholders

Software Metrics and Measures

Software Measures can be understood as a process of quantifying and symbolizing
various attributes and aspects of software.

Software Metrics provide measures for various aspects of software process and
software product.

Software measures are fundamental requirement of software engineering. They not only
help to control the software development process but also aid to keep quality of ultimate
product excellent.

According to Tom DeMarco, a (Software Engineer), “You cannot control what you cannot
measure.” By his saying, it is very clear how important software measures are.

Let us see some software metrics:

 Size Metrics – LOC (Lines of Code), mostly calculated in thousands of delivered

source code lines, denoted as KLOC.

Function Point Count is measure of the functionality provided by the software. Function
Point count defines the size of functional aspect of software.

 Complexity Metrics – McCabe’s Cyclomatic complexity quantifies the upper

bound of the number of independent paths in a program, which is perceived as
complexity of the program or its modules. It is represented in terms of graph theory
concepts by using control flow graph.

 Quality Metrics – Defects, their types and causes, consequence, intensity of

severity and their implications define the quality of product.

The number of defects found in development process and number of defects reported by
the client after the product is installed or delivered at client-end, define quality of product.

 Process Metrics – In various phases of SDLC, the methods and tools used, the
company standards and the performance of development are software process metrics.
 Resource Metrics – Effort, time and various resources used, represents metrics
for resource measurement.

Personnel Estimates
 The stockroom personnel will also need information about the business. Each design
describes output to be produced by the system, such as inventory reports, sales
analyses, purchasing summaries, and invoices. The systems analysts will actually
decide which outputs to use, as well as how to produce them.

Analysis specifies what the system should do. Design states how to accomplish the
objective. Notice that each of the processes mentioned involves people. Managers and
employees have good ideas about what works and what does not, about what flows
smoothly and what causes problems, about where change is needed and where it is not,
and especially about where change will be accepted and where it will not. Despite
technology, people are still the keys that make the organizations work. Thus,
communicating and dealing with people are very important parts of the systems analyst’s
job.

In many organizations, steering (also called operating committees, operating councils, or

project selection boards) supervise the review of project proposal. The steering
committee typically consists of key managers from various departments of the
organization, as well as members of the information systems group. However, systems
specialists do not dominate the committee. The information systems steering committee
referred to in “The Good Old Days of Information Systems”.

A typical seven to ten – person committee would consist of the following membership:

1. Upper – management members:

Executive Vice president

Vice President for manufacturing

2. Departmental management:

Manager of retail marketing

Credit manager

3. Technical managers:

Manager of research and development

Quality control coordinator

4. Information system group:

Data processing manager

Senior systems analyst

The committee receives proposals and evaluated them. The major responsibility of the
committee is to make a decision, which often requires more information than the
 proposal provides, therefore, a preliminary investigation, is often requested to gather
those details.

The steering – committee method brings high respectability and visibility to the review of
project proposals. The committee consists of managers with the responsibility and the
authority to decide which projects are in the best interest of the entire firm.

Because several levels of management are included on the committee, members can
have informed discussions on matters relating to day – to – day operations (treating
patients, ordering materials, or hiring staff members) and long – range plans (new
facilities, new programs) that many have a bearing on the project request. The
managers provide practical information and insight about operations and long – term
development. Systems specialists on the committee provide technical and
developmental information that is useful in reaching decisions about project
management.

The steering committee approach is often favored because systems projects are
business investments. Management, not systems analysts or designers, selects projects
for development, decisions are made on the basis of the cost of the project, its benefit to
the organization, and the feasibility of accomplishing the development within the limits of
information systems technology in the organization.

This is the method used by Peter Wallington’s employer in “The Good Old Days of
Information systems”.

I-O Design
Input Design
In an information system, input is the raw data that is processed to produce output. During the
input design, the developers must consider the input devices such as PC, MICR, OMR, etc.

Therefore, the quality of system input determines the quality of system output. Well-designed
input forms and screens have following properties −

 It should serve specific purpose effectively such as storing, recording, and retrieving
the information.
 It ensures proper completion with accuracy.
 It should be easy to fill and straightforward.
 It should focus on user’s attention, consistency, and simplicity.
 All these objectives are obtained using the knowledge of basic design principles
regarding −
o What are the inputs needed for the system?
o How end users respond to different elements of forms and screens.

Objectives for Input Design

 The objectives of input design are:

 To design data entry and input procedures

 To reduce input volume
 To design source documents for data capture or devise other data capture methods
 To design input data records, data entry screens, user interface screens, etc.
 To use validation checks and develop effective input controls.

Data Input Methods

It is important to design appropriate data input methods to prevent errors while entering data.
These methods depend on whether the data is entered by customers in forms manually and
later entered by data entry operators, or data is directly entered by users on the PCs.

A system should prevent user from making mistakes by:

 Clear form design by leaving enough space for writing legibly.

 Clear instructions to fill form.
 Clear form design.
 Reducing key strokes.
 Immediate error feedback.

Some of the popular data input methods are −

 Batch input method (Offline data input method)

 Online data input method
 Computer readable forms
 Interactive data input

Input Integrity Controls

Input integrity controls include a number of methods to eliminate common input errors by
end-users. They also include checks on the value of individual fields; both for format and the
completeness of all inputs.

Audit trails for data entry and other system operations are created using transaction logs
which gives a record of all changes introduced in the database to provide security and means
of recovery in case of any failure.

Output Design
The design of output is the most important task of any system. During output design,
developers identify the type of outputs needed, and consider the necessary output controls
and prototype report layouts.

Objectives of Output Design

The objectives of input design are:
 To develop output design that serves the intended purpose and eliminates the
production of unwanted output.
 To develop the output design that meets the end users requirements.
 To deliver the appropriate quantity of output.
 To form the output in appropriate format and direct it to the right person.
 To make the output available on time for making good decisions.

Let us now go through various types of outputs:

External Outputs
Manufacturers create and design external outputs for printers. External outputs enable the
system to leave the trigger actions on the part of their recipients or confirm actions to their
recipients.

Some of the external outputs are designed as turnaround outputs, which are implemented as a
form and re-enter the system as an input.

Internal outputs
Internal outputs are present inside the system, and used by end-users and managers. They
support the management in decision making and reporting.

There are three types of reports produced by management information −

 Detailed Reports: They contain present information which has almost no filtering or
restriction generated to assist management planning and control.
 Summary Reports: They contain trends and potential problems which are
categorized and summarized that are generated for managers who do not want details.
 Exception Reports: They contain exceptions, filtered data to some condition or
standard before presenting it to the manager, as information.

Output Integrity Controls

Output integrity controls include routing codes to identify the receiving system, and
verification messages to confirm successful receipt of messages that are handled by network
protocol. Printed or screen-format reports should include a date/time for report printing and
the data. Multipage reports contain report title or description, and pagination. Pre-printed
forms usually include a version number and effective date.

UNIT-3
Data Dictionary, Decision Tables
Data Dictionary
 A data dictionary contains metadata i.e data about the database. The data dictionary is
very important as it contains information such as what is in the database, who is allowed
to access it, where is the database physically stored etc. The users of the database
normally don’t interact with the data dictionary, it is only handled by the database
administrators.

The data dictionary in general contains information about the following:

1. Names of all the database tables and their schemas.

2. Details about all the tables in the database, such as their owners, their security
constraints, when they were created etc.
3. Physical information about the tables such as where they are stored and how.
4. Table constraints such as primary key attributes, foreign key information etc.
5. Information about the database views that are visible.

This is a data dictionary describing a table that contains employee details.

Data Field Size for

Field Name Description Example
Type display

Employee Unique ID of each

Integer 10 1645000001
Number employee

Name of the David

Name Text 20
employee Heston

Date of Birth Date/Time 10 DOB of Employee 08/03/1995

Phone Phone number of

Integer 10 6583648648
Number employee

The different types of data dictionary are:

Active Data Dictionary

If the structure of the database or its specifications change at any point of time, it should
be reflected in the data dictionary. This is the responsibility of the database management
system in which the data dictionary resides.
 So, the data dictionary is automatically updated by the database management system
when any changes are made in the database. This is known as an active data dictionary
as it is self-updating.

Passive Data Dictionary

This is not as useful or easy to handle as an active data dictionary. A passive data
dictionary is maintained separately to the database whose contents are stored in the
dictionary. That means that if the database is modified the database dictionary is not
automatically updated as in the case of Active Data Dictionary. 

So, the passive data dictionary has to be manually updated to match the database. This
needs careful handling or else the database and data dictionary are out of sync.

Decision Tables
Decision tables are a method of describing the complex logical relationship in a precise
manner which is easily understandable.

 It is useful in situations where the resulting actions depend on the occurrence of

one or several combinations of independent conditions.
 It is a matrix containing row or columns for defining a problem and the actions.

Components of a Decision Table

 Condition Stub: It is in the upper left quadrant which lists all the condition to be
checked.
 Action Stub: It is in the lower left quadrant which outlines all the action to be
carried out to meet such condition.
 Condition Entry: It is in upper right quadrant which provides answers to
questions asked in condition stub quadrant.
 Action Entry: It is in lower right quadrant which indicates the appropriate action
resulting from the answers to the conditions in the condition entry quadrant.

The entries in decision table are given by Decision Rules which define the relationships
between combinations of conditions and courses of action. In rules section,

 Y shows the existence of a condition.

 N represents the condition, which is not satisfied.
 A blank – against action states it is to be ignored.
 X (or a check mark will do) against action states it is to be carried out.

For example, refer the following table:

CONDITIONS Rule 1 Rule 2 Rule 3 Rule 4

Advance payment made Y N N N

 Purchase amount = Rs 10,000/- – Y Y N

Regular Customer – Y N –

ACTIONS        

Give 5% discount X X – –

Give no discount – – X X

Decision Trees
Decision trees are a method for defining complex relationships by describing decisions and
avoiding the problems in communication. A decision tree is a diagram that shows alternative
actions and conditions within horizontal tree framework. Thus, it depicts which conditions to
consider first, second, and so on.

Decision trees depict the relationship of each condition and their permissible actions. A
square node indicates an action and a circle indicates a condition. It forces analysts to
consider the sequence of decisions and identifies the actual decision that must be made.
The major limitation of a decision tree is that it lacks information in its format to describe
what other combinations of conditions you can take for testing. It is a single representation of
the relationships between conditions and actions.

For example, refer the following decision tree:

Logical design to Physical Implementation

A proper database design cannot be thrown together quickly by novices. What is
required is a practiced and formal approach to gathering data requirements and
modeling data. This modeling effort requires a formal approach to the discovery and
identification of entities and data elements. Data normalization is a big part of data
modeling and database design. A normalized data model reduces data redundancy and
inconsistencies by ensuring that the data elements are designed appropriately.

From Logical…
So, database design is the process of transforming a logical data model into an actual
physical database. Technicians sometimes leap to the physical implementation before
producing the model of that implementation. This is unwise. A logical data model is
required before you can even begin to design a physical database. And the logical data
model grows out of a conceptual data model. And any type of data model begins with
the discipline of data modeling.

The first objective of conceptual data modeling is to understand the requirements. A

data model, in and of itself, is of limited value. Of course, a data model delivers value by
enhancing communication and understanding, and it can be argued that these are quite
valuable. But the primary value of a data model is its ability to be used as a blueprint to
build a physical database.

When databases are built from a well-designed data model the resulting structures
provide increased value to the organization. The value derived from the data model
exhibits itself in the form of minimized redundancy, maximized data integrity, increased
stability, better data sharing, increased consistency, more timely access to data, and
better usability. These qualities are achieved because the data model clearly outlines the
data resource requirements and relationships in a clear, concise manner. Building
databases from a data model will result in a better database implementation because
you will have a better understanding of the data to be stored in your databases.
 Another benefit of data modeling is the ability to discover new uses for data. A data
model can clarify data patterns and potential uses for data that would remain hidden
without the data blueprint provided by the data model. Discovery of such patterns can
change the way your business operates and can potentially lead to a competitive
advantage and increased revenue for your organization.

Data modeling requires a different mindset than requirements gathering for application
development and process-oriented tasks. It is important to think “what” is of interest
instead of “how” tasks are accomplished. To transition to this alternate way of thinking,
follow these three “rules”:

 Don’t think physical; think conceptual – do not concern yourself with physical
storage issues and the constraints of any DBMS you may know. Instead, concern
yourself with business issues and terms.
 Don’t think process; think structure – how something is done, although important
for application development, is not important for data modeling. The things that
processes are being done to are what is important to data modeling.
 Don’t think navigation; think relationship – the way that things are related to one
another is important because relationships map the data model blueprint. The way in
which relationships are traversed is unimportant to conceptual and logical data
modeling.

Data models are typically rendered in a graphical format using an entity-relationship

diagram, or E/R diagram for short. An E/R diagram graphically depicts the entities and
relationships of a data model. There are many popular data modeling tools on the
market from a variety of vendors. But do not confuse the tool as being more important
than the process. Of what use is a good tool if you do not know how to deploy it?

A data model is built using many different components acting as abstractions of real
world things. The simplest data model will consist of entities and relationships. As work
on the data model progresses, additional detail and complexity is added. Let’s examine
the many different components of a data model and the terminology used for data
modeling.

The first building block of the data model is the entity. An entity, at a very basic level, is
something that exists and is capable of being described. It is a person, place, thing,
concept, or event about which your organization maintains facts. For example:
“STUDENT,” “INSTRUCTOR,” and “COURSE” are specific entities about which a
college or university must be knowlegeable to perform its business.

Entities are comprised of attributes. An attribute is a characteristic of an entity. Every

attribute does one of three things:

1. Describe – An attribute is descriptive if it does not identify or relate, but is used to

depict or express a characteristic of an entity occurrence.
2. Identify – An attribute that identifies is a candidate key. If the value of an
identifying attribute changes, it should identify a different entity occurrence. An attribute
that identifies should be unchangeable and immutable.
3. Relate – An attribute that relates entities is a foreign key; the attribute refers to
the primary key attribute of an occurrence of another (or the same) entity.
 Each attribute is assigned a domain that defines the type of data, its size, and the valid
values that can be assigned to the attribute. As a general rule of thumb, nouns tend to
be entities and adjectives tend to be attributes. But, of course, this is not a hard and fast
rule: be sure to apply of the business to determine which nouns and attributes are
entities and which are attributes. Every attribute must either identify the entity
occurrence, describe the entity occurrence, or relate the entity occurrence to another
entity occurrence (in the same or another entity).

Relationships define how the different entities are associated with each other. Each
relationship is named such that it describes the role played by an entity in its association
with another (or perhaps the same) entity. A relationship is defined by the keys of the
participating entities: the primary key in the parent entity and the foreign key in the
dependent entity. Relationships are not just the “lines” that connect entities, but provide
meaning to the data model and must be assigned useful names.

Keep in mind that as you create your data models, you are developing the lexicon of
your organization’s business. Much like a dictionary functions as the lexicon of words for
a given language, the data model functions as the lexicon of business terms and their
usage. Of course, this short introduction just scrapes the tip of the data modeling
iceberg.

…To Physical
Assuming that the logical data model is complete, though, what must be done to
implement a physical database?

The first step is to create an initial physical data model by transforming the logical data
model into a physical implementation based on an understanding of the DBMS to be
used for deployment. To successfully create a physical database design you will need to
have a good working knowledge of the features of the DBMS including:

 In-depth knowledge of the database objects supported by the DBMS and the
physical structures and files required to support those objects.
 Details regarding the manner in which the DBMS supports indexing, referential
integrity, constraints, data types, and other features that augment the functionality of
database objects.
 Detailed knowledge of new and obsolete features for particular versions or
releases of the DBMS to be used.
 Knowledge of the DBMS configuration parameters that are in place.
 Data definition language (DDL) skills to translate the physical design into actual
database objects.

Armed with the correct information, you can create an effective and efficient database
from a logical data model. The first step in transforming a logical data model into a
physical model is to perform a simple translation from logical terms to physical objects.
Of course, this simple transformation will not result in a complete and correct physical
database design – it is simply the first step. The transformation consists of the following:

 Transforming entities into tables

 Transforming attributes into columns
 Transforming domains into data types and constraints

To support the mapping of attributes to table columns you will need to map each logical
domain of the attribute to a physical data type and perhaps additional constraints. In a
physical database, each column must be assigned a data type. Certain data types
require a maximum length to be specified. For example a character data type could be
specified as CHAR(25), indicating that up to 25 characters can be stored for the column.
You may need to apply a length to other data types as well, such as graphic, floating
point, and decimal (which require a length and scale) types.

But no commercial DBMS product fully supports relational domains. Therefore the
domain assigned in the logical data model must be mapped to a data type supported by
the DBMS. You may need to adjust the data type based on the DBMS you use. For
example, what data type and length will be used for monetary values if no built-in
currency data type exists? Many of the major DBMS products support user-defined data
types, so you might want to consider creating a data type to support the logical domain,
if no built-in data type is acceptable.

In addition to a data type and length, you also may need to apply a constraint to the
column. Consider a domain of integers between 1 and 10 inclusive. Simply assigning the
physical column to an integer data type is insufficient to match the domain. A constraint
must be added to restrict the values that can be stored for the column to the specified
range, 1 through 10. Without a constraint, negative numbers, zero, and values greater
than ten could be stored. Using check constraints you can place limits on the data
values that can be stored in a column or set of columns.

Specification of a primary key is an integral part of the physical design of entities and
attributes. A primary key should be assigned for every entity in the logical data model.
As a first course of action you should try to use the primary key as selected in the logical
data model. However, multiple candidate keys often are uncovered during the data
modeling process. You may decide to choose a primary key other than the one selected
during logical design – either one of the candidate keys or another surrogate key for
physical implementation. But even if the DBMS does not mandate a primary key for each
table it is a good practice to identify a primary key for each physical table you create.
Failure to do so will make processing the data in that table more difficult.

Of course, there are many other decisions that must be made during the transition from
logical to physical. For example, each of the following must be addressed:

 The nullability of each column in each table

 For character columns, should fixed length or variable length be used?
 Should the DBMS be used to assign values to sequences or identity columns?
 Implementing logical relationships by assigning referential constraints
 Building indexes on columns to improve query performance
 Choosing the type of index to create: b-tree, bit map, reverse key, hash,
partitioning, etc.
 Deciding on the clustering sequence for the data
 Other physical aspects such as column ordering, buffer pool specification, data
files, denormalization, and so on.
Summary
A logical data model should be used as the blueprint for designing and creating a
physical database. But the physical database cannot be created properly with a simple
logical to physical mapping. Many physical design decisions need to be made by the
DBA before implementing physical database structures. This may necessitate deviating
from the logical data model. But such deviation should occur only based on in-depth
knowledge of the DBMS and the physical environment in which the database will exist.

UNIT-4
Introduction to Distributed Data Processing and
Real Time System
Distributed systems use multiple central processors to serve multiple real-time
applications and multiple users. Data processing jobs are distributed among the
processors accordingly.

The processors communicate with one another through various communication lines
(such as high-speed buses or telephone lines). These are referred as loosely coupled
systems or distributed systems. Processors in a distributed system may vary in size and
function. These processors are referred as sites, nodes, computers, and so on.

The advantages of distributed systems are as follows:

 With resource sharing facility, a user at one site may be able to use the resources
available at another.
 Speedup the exchange of data with one another via electronic mail.
 If one site fails in a distributed system, the remaining sites can potentially
continue operating.
 Better service to the customers.
 Reduction of the load on the host computer.
 Reduction of delays in data processing.

Real Time operating System

A real-time system is defined as a data processing system in which the time interval
required to process and respond to inputs is so small that it controls the environment.
The time taken by the system to respond to an input and display of required updated
information is termed as the response time. So in this method, the response time is
very less as compared to online processing.

Real-time systems are used when there are rigid time requirements on the operation of a
processor or the flow of data and real-time systems can be used as a control device in a
dedicated application. A real-time operating system must have well-defined, fixed time
constraints, otherwise the system will fail. For example, Scientific experiments, medical
imaging systems, industrial control systems, weapon systems, robots, air traffic control
systems, etc.

There are two types of real-time operating systems.

Hard real-time systems

Hard real-time systems guarantee that critical tasks complete on time. In hard real-time
systems, secondary storage is limited or missing and the data is stored in ROM. In these
systems, virtual memory is almost never found.

Soft real-time systems

Soft real-time systems are less restrictive. A critical real-time task gets priority over other
tasks and retains the priority until it completes. Soft real-time systems have limited utility
than hard real-time systems. For example, multimedia, virtual reality, Advanced
Scientific Projects like undersea exploration and planetary rovers, etc.

Evaluating Distributing System

In a distributed database, there are a number of databases that may be geographically
distributed all over the world. A distributed DBMS manages the distributed database in a
manner so that it appears as one single database to users. In the later part of the
chapter, we go on to study the factors that lead to distributed databases, its advantages
and disadvantages.

A distributed database is a collection of multiple interconnected databases, which are

spread physically across various locations that communicate via a computer network.

Features
 Databases in the collection are logically interrelated with each other. Often they
represent a single logical database.
 Data is physically stored across multiple sites. Data in each site can be managed
by a DBMS independent of the other sites.
 The processors in the sites are connected via a network. They do not have any
multiprocessor configuration.
 A distributed database is not a loosely connected file system.
 A distributed database incorporates transaction processing, but it is not
synonymous with a transaction processing system.

Distributed Database Management System

A distributed database management system (DDBMS) is a centralized software system
that manages a distributed database in a manner as if it were all stored in a single
location.

Features

 It is used to create, retrieve, update and delete distributed databases.

 It synchronizes the database periodically and provides access mechanisms by
the virtue of which the distribution becomes transparent to the users.
 It ensures that the data modified at any site is universally updated.
 It is used in application areas where large volumes of data are processed and
accessed by numerous users simultaneously.
 It is designed for heterogeneous database platforms.
 It maintains confidentiality and data integrity of the databases.

Factors Encouraging DDBMS

The following factors encourage moving over to DDBMS:

 Distributed Nature of Organizational Units: Most organizations in the current

times are subdivided into multiple units that are physically distributed over the globe.
Each unit requires its own set of local data. Thus, the overall database of the
organization becomes distributed.
 Need for Sharing of Data: The multiple organizational units often need to
communicate with each other and share their data and resources. This demands
common databases or replicated databases that should be used in a synchronized
manner.
 Support for Both OLTP and OLAP: Online Transaction Processing (OLTP) and
Online Analytical Processing (OLAP) work upon diversified systems which may have
common data. Distributed database systems aid both these processing by providing
synchronized data.
 Database Recovery: One of the common techniques used in DDBMS is
replication of data across different sites. Replication of data automatically helps in data
recovery if database in any site is damaged. Users can access data from other sites
while the damaged site is being reconstructed. Thus, database failure may become
almost inconspicuous to users.
 Support for Multiple Application Software: Most organizations use a variety of
application software each with its specific database support. DDBMS provides a uniform
functionality for using the same data among different platforms.

Advantages of Distributed Databases

Following are the advantages of distributed databases over centralized databases.

Modular Development: If the system needs to be expanded to new locations or new

units, in centralized database systems, the action requires substantial efforts and
disruption in the existing functioning. However, in distributed databases, the work simply
requires adding new computers and local data to the new site and finally connecting
them to the distributed system, with no interruption in current functions.

More Reliable: In case of database failures, the total system of centralized databases
comes to a halt. However, in distributed systems, when a component fails, the
functioning of the system continues may be at a reduced performance. Hence DDBMS is
more reliable.

Better Response: If data is distributed in an efficient manner, then user requests can be
met from local data itself, thus providing faster response. On the other hand, in
centralized systems, all queries have to pass through the central computer for
processing, which increases the response time.

Lower Communication Cost: In distributed database systems, if data is located locally

where it is mostly used, then the communication costs for data manipulation can be
minimized. This is not feasible in centralized systems.

Adversities of Distributed Databases

Following are some of the adversities associated with distributed databases.

 Need for complex and expensive software: DDBMS demands complex and

often expensive software to provide data transparency and co-ordination across the
several sites.
 Processing overhead: Even simple operations may require a large number of
communications and additional calculations to provide uniformity in data across the
sites.
 Data integrity: The need for updating data in multiple sites pose problems of
data integrity.
 Overheads for improper data distribution: Responsiveness of queries is
largely dependent upon proper data distribution. Improper data distribution often leads to
very slow response to user requests.

Designing Distributed Data Base

The strategies can be broadly divided into replication and fragmentation. However, in most
cases, a combination of the two is used.
 Data Replication
Data replication is the process of storing separate copies of the database at two or more sites.
It is a popular fault tolerance technique of distributed databases.

Advantages of Data Replication

 Reliability: In case of failure of any site, the database system continues to work since a copy
is available at another site(s).
 Reduction in Network Load: Since local copies of data are available, query processing can be
done with reduced network usage, particularly during prime hours. Data updating can be done at
non-prime hours.
 Quicker Response: Availability of local copies of data ensures quick query processing and
consequently quick response time.
 Simpler Transactions: Transactions require less number of joins of tables located at different
sites and minimal coordination across the network. Thus, they become simpler in nature.

Disadvantages of Data Replication

 Increased Storage Requirements: Maintaining multiple copies of data is associated with

increased storage costs. The storage space required is in multiples of the storage required for a
centralized system.
 Increased Cost and Complexity of Data Updating: Each time a data item is updated, the
update needs to be reflected in all the copies of the data at the different sites. This requires complex
synchronization techniques and protocols.
 Undesirable Application – Database coupling: If complex update mechanisms are not used,
removing data inconsistency requires complex co-ordination at application level. This results in
undesirable application – database coupling.

Some commonly used replication techniques are:

 Snapshot replication
 Near-real-time replication
 Pull replication

Fragmentation
Fragmentation is the task of dividing a table into a set of smaller tables. The subsets of the
table are called fragments. Fragmentation can be of three types: horizontal, vertical, and
hybrid (combination of horizontal and vertical). Horizontal fragmentation can further be
classified into two techniques: primary horizontal fragmentation and derived horizontal
fragmentation.

Fragmentation should be done in a way so that the original table can be reconstructed from
the fragments. This is needed so that the original table can be reconstructed from the
fragments whenever required. This requirement is called “reconstructiveness.”
 Advantages of Fragmentation

 Since data is stored close to the site of usage, efficiency of the database system is increased.
 Local query optimization techniques are sufficient for most queries since data is locally
available.
 Since irrelevant data is not available at the sites, security and privacy of the database system
can be maintained.

Disadvantages of Fragmentation

 When data from different fragments are required, the access speeds may be very high.
 In case of recursive fragmentations, the job of reconstruction will need expensive
techniques.
 Lack of back-up copies of data in different sites may render the database ineffective in case
of failure of a site.

Vertical Fragmentation
In vertical fragmentation, the fields or columns of a table are grouped into fragments. In order
to maintain reconstructiveness, each fragment should contain the primary key field(s) of the
table. Vertical fragmentation can be used to enforce privacy of data.

For example, let us consider that a University database keeps records of all registered
students in a Student table having the following schema.

STUDENT

Regd_N Cours Semeste

Name Address Fees Marks
o e r

Now, the fees details are maintained in the accounts section. In this case, the designer will
fragment the database as follows −

CREATE TABLE STD_FEES AS

   SELECT Regd_No, Fees

   FROM STUDENT;
Horizontal Fragmentation

Horizontal fragmentation groups the tuples of a table in accordance to values of one or more
fields. Horizontal fragmentation should also confirm to the rule of reconstructiveness. Each
horizontal fragment must have all columns of the original base table.

For example, in the student schema, if the details of all students of Computer Science Course
needs to be maintained at the School of Computer Science, then the designer will horizontally
fragment the database as follows −
 CREATE COMP_STD AS

   SELECT * FROM STUDENT 

   WHERE COURSE = “Computer Science”;

Hybrid Fragmentation

In hybrid fragmentation, a combination of horizontal and vertical fragmentation techniques

are used. This is the most flexible fragmentation technique since it generates fragments with
minimal extraneous information. However, reconstruction of the original table is often an
expensive task.

Hybrid fragmentation can be done in two alternative ways:

 At first, generate a set of horizontal fragments; then generate vertical fragments from one or
more of the horizontal fragments.
 At first, generate a set of vertical fragments; then generate horizontal fragments from one or
more of the vertical fragments.

Event Based Real Time Analysis Tools

 Each real-time design concern for software must be applied in the context of
system performance. In most cases, the performance of a real-time system is
measured as one or more time-related characteristics, but other measures such
as fault-tolerance may also be used.
 Some real-time systems are designed for applications in which only the response
time or the data transfer rate is critical. Other real-time applications require
optimization of both parameters under peak loading conditions. What’s more,
real-time systems must handle their peak loads while performing a number of
simultaneous tasks.
 Since the performance of a real-time system is determined primarily by the
system response time and its data transfer rate, it is important to understand
these two parameters. System response time is the time within which a system
must detect an internal or external event and respond with an action. Often, event
detection and response generation are simple. It is the processing of the
information about the event to determine the appropriate response that may
involve complex, time-consuming algorithms.
 Among the key parameters that affect the response time are context
switching and interrupt latency.Context switching involves the time and overhead
to switch among tasks, and interrupt latency is the time lag before the switch is
actually possible. Other parameters that affect response time are the speed of
computation and of access to mass storage.
 The data transfer rate indicates how fast serial or parallel, as well as analog or
digital data must be moved into or out of the system. Hardware vendors often
quote timing and capacity values for performance characteristics. However,
hardware specifications for performance are usually measured in isolation and
are often of little value in determining overall real-time system performance.
 Therefore, I/O device performance, bus latency, buffer size, disk performance,
and a host of other factors, although important, are only part of the story of real-
time system design.
 Real-time systems are often required to process a continuous stream of incoming
data. Design must assure that data are not missed. In addition, a real-time
system must respond to events that are asynchronous. Therefore, the arrival
sequence and data volume cannot be easily predicted in advance.
 Although all software applications must be reliable, real-time systems make
special demands on reliability, restart, and fault recovery. Because the real-world
is being monitored and controlled, loss of monitoring or control (or both) is
intolerable in many circumstances (e.g., an air traffic control system).
Consequently, real-time systems contain restart and fault-recovery mechanisms
and frequently have built-in redundancy to insure backup.
 The need for reliability, however, has spurred an on-going debate about
whether on-line systems, such as airline reservation systems and automatic bank
tellers, also qualify as real-time. On one hand, such on-line systems must
respond to external interrupts within prescribed response times on the order of
one second. On the other hand, nothing catastrophic occurs if an on-line system
fails to meet response requirements; instead, only system degradation results.

State Transition Diagrams

 State-transition diagrams describe all of the states that an object can have, the events
under which an object changes state (transitions), the conditions that must be fulfilled
before the transition will occur (guards), and the activities undertaken during the life
of an object (actions). State-transition diagrams are very useful for describing the
behavior of individual objects over the full set of use cases that affect those objects.
State-transition diagrams are not useful for describing the collaboration between
objects that cause the transitions.
 The UML notation for state-transition diagrams is shown below:


 Notation
 For those not familiar with the notation used for state-transition diagrams, some
explanation is in order.
 State: A condition during the life of an object in which it satisfies some condition,
performs some action, or waits for some event.
 Event: An occurrence that may trigger a state transition. Event types include an
explicit signal from outside the system, an invocation from inside the system, the
passage of a designated period of time, or a designated condition becoming true.
 Guard: A boolean expression which, if true, enables an event to cause a transition.
 Transition: The change of state within an object.
 Action: One or more actions taken by an object in response to a state change.