0% found this document useful (0 votes)
52 views97 pages

System Analysis & Design 8-27

Uploaded by

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

System Analysis & Design 8-27

Uploaded by

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

System Analysis &

Design
Suresh Khadka
MICT, LLB, PGDCA, Scholar M.Phil. in ICT at
NOU
Profession Certification: MCSA, MCSE, RHCSA,
RHCE,CCNA
Suresh K Khadka
MICT, LLB, PGDCA, Scholar M.Phil. in
ICT at NOU
Profession Certification: MCSA, MCSE, RHCSA,
RHCE,CCNA
Email:[email protected]
Ph:9840064993, 9857844993
Ministry of Federal Affairs &
General Administration
Freelancer Web Developer
SYSTEM
A System is an orderly grouping of
interdependent Components linked
together according to a plan to achieve a
specific objective.
SYSTEM
• A System is an orderly grouping of interdependent Components linked
together according to a plan to achieve a specific objective.
 A system must be designed to achieve a predetermined objective.
 Interrelationships and interdependence must exist among the
components.
 The objectives of the organization as a whole have a higher priority than
the objectives of its subsystems.
• A System may be defined as orderly grouping of interdependent
components linked together according to a plan to achieve a
specific goal. Each component is a part of total system and it has
to do its own share of work for the system to achieve the desired
goal.

Information system
• An information system (IS) is an arrangement of people, data, process,
and information technology that interact to collect, process, store and
provide us output the information needed to support an organization.
Basic Implications
• A System must be designed to achieved a predetermined
objective.
• Interrelationships & Interdependence must exist among the
components.
• The Objectives of the organization as whole have a higher
priority than the objectives of its subsystems
Examples of System

• Transportation System
• Telephone System
• Accounting System
• Production System
• Computer System
• Business System
• Hotel Management System
• Banking System
Element / Component of System

• Inputs
• Process
• Output
• Control
• Feedback
• Environment
Characteristics Of System

• Organization
• Interaction
• Interdependence
• Integration
• Central Objective
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.
Important Terms Systems
• Purpose
Reason for its existence and the reference point for measuring its success.

• Boundary
what is inside the system and what is outside.

• Environment
everything pertinent to the System that is outside of its boundaries.

• Inputs
physical objects and information that cross the boundary to enter it from its environment.

• Outputs
physical objects and information that go from the system into its environment.
System Approach
Its the approach of building information systems
The increase complexity of business
• The Technological Revolution
• Research & development
• Product changes
• The Information Explosion
The Increased Complexity of Management
• Information Feedback System
• Decision Making
• Management Science
• The Electronic Computer
Types of System:
• Formal & Informal
• Physical & Abstract
• Close & Open
• Manual or Automatic
• Conceptual & Empirical
• Natural & Manufactured
• Social, People-Machine & Machine
• Adaptive & Non- Adoptive
• Deterministic & Probabilistic
• Permanent & Temporary
• Stationary & Non-Stationary
• Subsystems & Super System
Formal & Informal
A Formal System is one that is planned in advance and is
used according to schedule. Example is to conduct a scheduled
meeting at the end of every month in which agenda of the
meeting has already been defined well in advance.
An Informal System is the system that is not described by
procedures. It is not used. According to a schedule. It works on
as need basis. For example, Sales order processing system
through telephone calls.
Physical & Abstract
Physical Systems are tangible entities that may be static or
dynamic.
Computer Systems, Vehicles, Buildings etc. are examples of
physical systems.
Abstract systems are conceptual entities. These are not
Physical Entities They may be formula ,representation or model
of System Example: Design
Close & Open System
Open System is a system within its environment. It receives
input from environment and provides output to environment.
Example: Any real life system, Information System,
Organization etc.
Closed System: It is isolated from environment influences. It
operates on factors within the System itself. It is also defined as
a System that includes a feedback loop, a control element and
feedback performance standard.
Manual or Automatic
Manual and Automated systems: The system, which does not
require human intervention is called Automated system. In this
system, the whole process is automatic.
Example: Traffic control system for metropolitan cities.
The system, which requires human intervention, is called a Manual
System.
Example: Face to face information centre at places like Railway
stations etc.
Real Life Business Subsystems

A Subsystem is a component of a System, even though it can also be


considered as a system in its own right. Consider a manufacturing firm. It
consists of five subsystems namely, Product design, Production, Sales, Delivery
and Service.
There are two types of Real Time systems. They are :
Hard Real Time Systems which guarantee that critical tasks are completed
on time.
Soft Real Time Systems which are less restrictive type of real time systems
where a critical real time task gets priority over other tasks, and retains the
priority until it completes them. Systems that control scientific experiments,
medical imaging systems, industrial control systems and some display systems
are real time systems.
DISTRIBUTED SYSTEMS
A Distributed System in which the Data, Process, and Interface component of
information System are distributed to multiple locations in a computer network.
Accordingly, the processing workload required to support these components is
also distributed across multiple computers on the network.
Feature / Advantage
• Resource sharing
• Computation speedup
• Reliability
• Communication.
The five Layers of Distributed System architecture are:
• Presentation Layer is the actual user interface. The inputs
are received by this layer and the outputs are presented by
this layer.
• Presentation Logic layer includes processing required to
establish user interface. Example: Editing input data,
formatting output data.
• Application Logic Layer includes all the logic and processing
required to support the actual business application and rules
Example: Calculations.
• Data Manipulation Layer includes all the command and logic
required to store and retrieve data to and from the database.
• Data Layer is actual stored data in the database.
Various Approaches for development
of Information Systems
DEVELOPMENT OF A SUCCESSFUL
SYSTEM
SDLC
Various approaches are available for
development of Information Systems:
• Model Driven: It emphasizes the drawing of pictorial system models to
document and validate both existing and/or proposed systems. Ultimately,
the system model becomes the blueprint for designing and constructing an
improved system.
• Accelerated approach: A prototyping approach emphasizes the
construction of model of a system. Designing and building a scaled-down but
functional version of the desired system is known as Prototyping. A
prototype is a working system that is developed to test ideas and
assumptions about the new system.
• Joint Application Development: It is defined as a structured approach in
which users, managers, and analysts work together for several days in a
series of intensive meetings to specify or review system requirements. In
this approach, requirements are identified and design details are finalized.
VARIOUS APPROACHES FOR
DEVELOPMENT OF INFORMATION
SYSTEMS
• Structured Analysis and Design Approach,
• Prototype Application Development
• Joint Application Development.
• RAD (Rapid Application Development)
• Water Fall
• Spiral Model
Structured Analysis and Design
Approach
• The first model driven approach is Structured Analysis and Design
approach.
• The goal of structured system analysis and design is to reduce
maintenance time and effort. Modeling is the act of drawing one or
more graphical representations of a System.
• Model driven development techniques emphasize the drawing of
models to help visualize and analyze problems, define business
requirements and design Information systems.
1. Structured Analysis
• Preliminary Investigation
• Problem Analysis
• Requirement Analysis
• Decision Analysis.
2. Structured Design
It utilizes graphic description (Output of system analysis) and focuses on
development of software specifications.
Principles Of Structured Design:
• Modularity and partitioning: Each system should consist of a hierarchy of
modules. Lower level modules are generally smaller in scope and size compared
to higher level modules. They serve to partition processes into separate
functions.
• Coupling: Modules should be loosely coupled. It means that modules should
have little dependence on other modules in a system.
• Cohesion: Modules should be highly cohesive. It means that modules should
carry out a single processing function.
• Span of control: Modules should interact with and manage the functions of a
limited number of lower level modules. It means that the number of called
modules should be limited (in a calling module).
• Size of Module: The number of instructions contained in a module should be
limited so that module size is generally small.
• Shared use of Functions: Functions should not be duplicated in separate
modules may be shared. It means that functions can be written in a single
module and it can be invoked by any other module when needed.
Prototyping
• Prototyping is an iterative process of system development in
which requirements are converted to a working system that is
continually revised through close work between an analyst
and users
• A prototyping approach emphasizes the construction model of
a system. Designing and building a scaled-down but
functional version of a desired system is the process known
as Prototyping.
The steps of Prototyping process
• Identify the user’s known information requirements
and features needed in the system.
• Develop a working prototype.
• Revise the prototype based on feedback received
from customer
• Repeat these steps as needed to achieve a
satisfactory system.
Joint Application Development.
• It is defined as a structured approach in which users,
managers, and analysts work together for several days in a
series of intensive meetings to specify or review system
requirements. The important feature of JAD is joint
requirements planning, which is a process whereby highly
structured group meetings are conducted to analyze
problems and define requirements.
• JAD was developed by Chunk Morris of IBM Raleigh and Tony
Crawford of IBM Toronto in the late 1970's
The typical participants in a JAD are listed
below:
JAD session leader: The JAD leader organizes and runs the JAD. This person is trained in group
man
(1) Users: The key users of the system under consideration are vital participants in a JAD. They
are the only ones who have a clear understanding of what it means to use the system on a
daily basis.
(2) Managers: The role of managers during JAD is to approve project objectives, establish
project priorities, approve schedules and costs and approve identified training needs and
implementation plans.
(3) Sponsors: A JAD must be sponsored by someone at a relatively high level in the company
i.e. the person from top management. If the sponsor attends any session, it is usually at the
very beginning or at the end.
(4) Systems Analysts: Members of the systems analysis team attend the JAD session
although their actual participation may be limited. Analysts are there to learn from customers
and managers, but not to run or dominate the process.
(5) Scribe: The scribe takes down the notes during the JAD sessions. This is usually done on a
personal computer or a laptop. Notes may be taken using a word processor. Diagrams may
directly be entered into a CASE tool.
(6) IS staff like systems analysts, other IS staff such as programmers, database analysts, IS
planners and data center personnel may attend to learn from the discussions and possibly to
contribute their ideas on the technical feasibility of proposed ideas or on technical limitations of
current systems. agreement and facilitation as well as system analysis.
The following are the various benefits of Joint
Application Development:
• actively involves users and management in project
development,
• reduces the amount of time required to develop a system,
and
• incorporates prototyping as a means for confirming
requirements and obtaining design approvals.
Waterfall Model
• The Waterfall Model was the 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.
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 document.
• System Design − The requirement specifications from first phase are studied in
this phase and the system design is prepared. This system design helps in
specifying hardware and system requirements and helps in defining the overall
system architecture.
• Implementation − With inputs from the 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.
Waterfall Model - Application

• 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.
RAD (Rapid Application
• The RAD (RapidDevelopment)
Application Development) model is
based on prototyping and iterative development with no
specific planning involved. The process of writing the software
itself involves the planning required for developing the
product.
• Rapid application development is a software development
methodology that uses minimal planning in favor of rapid
prototyping. A prototype is a working model that is
functionally equivalent to a component of the product
RAD Model - Application

• RAD should be used only when a system can be modularized to


be delivered in an incremental manner.
• It should be used if there is a high availability of designers for
modeling.
• It should be used only if the budget permits use of automated
code generating tools.
• RAD SDLC model should be chosen only if domain experts are
available with relevant business knowledge.
• Should be used where the requirements change during the
project and working prototypes are to be presented to
customer in small iterations of 2-3 months.
Spiral Model
• The spiral model combines the idea of iterative development
with the systematic, controlled aspects of the waterfall
model. This Spiral model is a combination of iterative
development process model and sequential linear
development model i.e. the waterfall model with a very high
emphasis on risk analysis. It allows incremental releases of
the product or incremental refinement through each iteration
around the spiral.
Spiral Model Application

• When there is a budget constraint and risk evaluation is important.


• For medium to high-risk projects.
• Long-term project commitment because of potential changes to
economic priorities as the requirements change with time.
• Customer is not sure of their requirements which is usually the
case.
• Requirements are complex and need evaluation to get clarity.
• New product line which should be released in phases to get
enough customer feedback.
• Significant changes are expected in the product during the
development cycle.
-List the fundamental principles of S/W
Development Life Cycle?

-What are the characteristics of a good information


system?

-What is the difference between information


requirements determination and specification?
Next Class
SYSTEMS ANALYST – A
PROFESSION
Introduction System Analyst
• The work of a systems analyst who designs an information
system is the same as an architect of a house. Three groups of
people are involved in developing information systems for
organizations. They are managers, users of the systems and
computer programmers who implement systems. The systems
analyst coordinates the efforts of all these groups to effectively
develop and operate computer based information systems.
• Systems analysts develop information systems. For this task,
they must know about concepts of systems. They must be
involved in all the phases of system development life cycle i.e.
from preliminary investigation to implementation. Success of
development depends on skills and the dedication of Systems
analysts.
Needs of System Analysist
•A computerized system enables an organization to provide
accurate information and respond faster to the queries,
events etc. If a business needs computerized information
system, a Systems Analyst is required for analysis and design
of that system.
• Informationsystems evolved from the need to improve the
use of computer resources for the information processing
needs of business application. Customer defines the business
problems to be solved by the computer.
• computer programmers and information technologists do not
fully understand the business applications they are trying to
computerize or support. A communication gap has always
existed between those who need computer based business
solutions and those who understand information technology.
Systems analyst bridges this gap.
System Users
• System users are defined as the people who use information systems or who
are affected by the information system on a regular basis i.e. capturing,
validating, entering, responding to, storing and exchanging data and
information apart from others. System users are concerned with business
requirements.
There are two main classes of system users:
• Internal Users are employees of the business for which an information
system is built. Examples are clerical and service staff, technical and
professional staff, supervisors, middle level managers and executive
managers.
• External Users: Modern information systems are now reaching beyond the
boundaries of the traditional business to include customers and other
businesses as system users. In business-to-business information systems,
each business becomes an external user of the other business’s information
systems. For example, in the case of direct purchasing of product through the
Internet, customer becomes an external user of the retailer’s order
processing information systems.
SYSTEM ANALYSTS IN VARIOUS
FUNCTIONAL AREAS
Systems Analyst in Traditional Business:
In the traditional business, information services are centralized for the entire organization or for
a specific location. In this organization, the staff of information services report directly to the
chief executive officer (CEO). The highest-ranking officer is sometimes called a chief
information officer (CIO) and the rest of information services are organized according to the
following functions or areas:
• System Development
• Data Administration
• Telecommunications
• End-user Computing
• Computer Operations
Systems Analyst in Modern Business
Many medium-to-large information services units for the modern business have reorganized to
be decentralized with a focus on empowerment and dynamic teams. In modern business,
systems analyst may be reassigned to different projects at time to time.
In modern business, two new trends are used for software development: outsourcing and
consulting. Outsourcing is the act of contracting an outside vendor to assume responsibility for
one or more IT functions or services. Consulting is the act of contracting with an outside vendor
to assume responsibility for or participate in one or more IT projects.
Roles & Duties of SA
Roles of SA
• The success of an information system development is based
on the role of Systems analyst. Among several roles, some
important roles are:
Change Agent:
Investigator and Monitor:
Architect
Psychologist
Motivator
Intermediary
Duties of SA

• The duty of a systems analyst is to coordinate the efforts of all


groups to effectively develop and operate computer based
information systems. The duties of a systems analyst are following
Defining Requirements
Prioritizing Requirements by Consensus
Analysis and Evaluation
Solving Problems
Drawing up Functional Specifications
Designing Systems
Evaluating Systems
Qualification of SA

• A systems analyst must fulfil the following requirements:


Working knowledge of information technology
 Computer programming experience and expertise
 General business knowledge
 Problem solving skills
Communication skills
 Interpersonal skills
 Flexibility and adaptability
 Thorough knowledge of analysis and design methodologies.
In summary, the skills of SA that are
required classified into the following:
1. Analytical skills
• System study, Organizational knowledge, Problem identification, Problem analysis and
problem solving.
2. Technical skills
• Microcomputers, workstations, minicomputers, Programming languages, Operating
systems, both for PC’s and networks, Database and File management systems, Data
communication standards and software for local and wide area networks, System
development tools and environments (such as forms & report generators and graphical
user interface design tools), Decision support systems and data analysis tools.
3. Management skills
• Resource management, Project management , Risk management, Change
management.
4. Interpersonal & Communication skills.
• Communication skills , Working alone as well as in a team , Facilitating groups,
Managing expectations.
Question

• Are excellent programmers necessarily excellent systems


analysts? Justify your answer
• List at least eight tasks performed by systems analysts.
• List at least six attributes of a systems analyst.
• Why should a systems analyst be able to communicate well?
Introduction to Documentation of
Systems
• Documentation is a process to help users of software and other
people to use and interact with system. Effective and accurate
documentation is very necessary for the success of any system.
• Documentation becomes part of each step of system development
through out the process of system development even before the
documentation starts officially.
• During the process of system development, study reports and
other necessary information are documented to help people
involved in system development to understand the process.
• There are many kinds of documentation namely analysis
documentation, design documentation, interface documentation,
internal program documentation and user-oriented documentation.
CONCEPTS AND PROCESS OF
DOCUMENTATION

• Documentation may be defined as the process of communicating


about the system. The person who is responsible for this
communication is called documenter.
• It may be noted that documenter is not responsible for the
accuracy of the information, and his job is just to communicate or
transfer the information.
• The ISO standard ISO/IEC 12207:1995 describes documentation
“as a supporting activity to record information produced by a
system development life cycle process.”
Why documentation?
Documentation is needed because it is
• a means for transfer of knowledge and details about
description of the system
• to communicate among different teams of the software
project;
• to help corporate audits and other requirements of the
organization;
• to meet regulatory demand;
• needed for IT infrastructure management and maintenance;
and
• needed for migration to a new software platform.
The Process of Documentation
The following are various steps involved in the process of documentation:
1. Collection of source material: The very first step of any documentation process is to
acquire the required source material for preparation of document. The material is collected
including specifications, formats, screen layouts and report layouts. A copy of the
operational software is helpful for preparing the documentation for user.
2. Documentation Plan: The documenter is responsible for preparation of a
documentation plan, which specifies the details of the work to be carried out to prepare
the document. It also defines and the target audience.
3. Review of Plan: The plan as set out in the process above is reviewed to see that
material acquired is correct and complete.
4. Creation of Document: The document is prepared with the help of document
generator.
5. Testing of Document: The document created is tested for usability as required by the
target audience.
6. Maintain Document: Once the document is created and distributed, it must be kept
up to date with new version of the software product. It must be ensured that the latest
document is available to the user of the software.
TYPES OF DOCUMENTATION

• Any software project is associated with a large number of


documents depending on the complexity of the project.
Documentation that are associated with system development
has a number of requirements.
1. System Requirements Specification (SRS)
Documentation
2. System Design Specification Documentation
3. Test Design Documentation
4. User Manual
1. System Requirements
Specification (SRS) Documentation
• System requirement specification is a set of complete and
precisely stated properties along with the constraints of the
system that the software must satisfy.
• A well designed software requirements specification establishes
boundaries and solutions of system to develop useful software.
All tasks, however minute, should not be underestimated and
must form part of the documentation.
• The SRS should specify only the external system behavior and
not the internal details. It also specifies any constraints imposed
on implementation.
• A good SRS is flexible to change and acts as a reference tool for
system developer, administrator and maintainer.
Characteristics of a System
Requirements Specification (SRS)
• All the requirements must be stated unambiguously
• It should be complete.
• The requirements should be realistic and achievable with
current technology
• It must be verifiable and consistent
• It should be modifiable.
• It should be traceable to other requirements and related
documents.
• SRS should not only addresses the explicit requirement but
also implicit
Rules for Specifying Software
Requirements
• Apply and use an industry standard to ensure that standard
formats are used to describe the requirements. Completeness and
consistency between various documents must be ensured.
• Use standard models to specify functional relationships, data flow
between the systems and sub-systems and data structure to
express complete requirements.
• Limit the structure of paragraphs to a list of individual sentences
to increase the tractability and modifiability of each requirement
and to increase the ability to check for completeness. It helps in
modifying the document when required.
• Phrase each sentence to a simple sentence. This is to increase
the verifiability of each requirement stated in the document.
Structure of a Typical SRS
Document:
System Design Specification
• The system design specification documents all as to how the
requirements of the system are to be implemented. It
consists of the final steps of describing the system in detail
before the coding starts.
• The system design specification gives a complete
understanding of the details of each component of the
system, and its associated algorithms, etc.
The system design specification is developed in a two
stage process:
• In the first step, design specification generally describes
the overall architecture of the system at a higher level.
• The second step provides the technical details of low-level
design, which will guide the implementer. It describes exactly
what the software must perform to meet the requirements of
Tools for describing design
1. Data dictionary
2. Database schema:
3. E-R model:
4. Security model:
5.Trade-off matrix
6. Decision table
7. Timing diagram
8. State machine diagram
9. Object Interaction Diagram
10. Inheritance Diagram
11.Aggregation Diagram
12.Structure Chart
13. Pseudocode
Typical System Design
Specification
FORMS AND REPORTS DESIGN

• Forms and Reports should be well conceived and


attractive in design. In order to achieve this goal,
we shall look into different criteria that are to be
followed while designing forms and reports.
• This unit deals with the interface of software with users.
Usually, the interface is through forms and reports that
are associated with the system. In this unit, we will study
different aspects of designing Forms and Reports, as
these are the key ingredients for successful systems.
FORMS
Form in computer terminology identifies the data we want to
collect. It also allows us to enter data into the database, display
it for review and also print it for distribution.
an electronic form has several important advantages over
standard paper forms. These have the advantage of using a
computer database and are more versatile and powerful than
paper forms.
Importance of Forms

• The following are various advantages of Forms:


• • A form provides an easy way to view data.
• • Using forms, data can be entered easily. This saves time and prevents
typographical errors.
• • Forms present data in an attractive format with special fonts and other
graphical effects such as colour and shading.
• • Forms offer the most convenient layout for entering, changing and
viewing records present in the database.
• • An entry field in a form can present a list of valid values from which
users can pick to fill out the field easily.
REPORTS
• A report is the information that is organized and formatted to
fit the required specification. It is a passive document that
contains only predefined data and is used solely for viewing
and reading. Reports can be printed on paper, or these may
be transferred to a computer file, a visual display screen, etc.
• Reports are the most visible component of a working
information system and hence they often form the basis for
the users and management’s final assessment of the systems
value.
Importance of Reports

The following are various advantages of Reports:


• • We can organize and present data in groups.
• • We can calculate running totals, group totals, grand totals,
percentage of totals, etc.
• • Within the body of Reports, we can include sub-forms, sub-
reports and graphs.
• • We can present data in an attractive format with pictures,
special fonts and lines. • We can create a design for a report
and save it so that we can use it over and over again.
DESIGN SPECIFICATIONS

• Narrative overview
• Sample design
• Testing and usability assessment
GENERAL FORMATTING
GUIDELINES
The following are gene make the Form, or
Report more acceptable:
Meaningful Titles
Meaningful Information
Balanced Layout
Easy Navigation
GUIDELINES FOR DISPLAYING
CONTENTS

• Highlighting Information
• Using Colour
• Displaying Text
• Designing Tables and Lists
CRITERIA FOR FORM DESIGN

• Organization, ,
• Consistency
• Completeness,
• Flexible entry, and
• Economy
CRITERIA FOR REPORT DESIGN

Reports convey information from one of more computer files to


the user. They perform this task satisfactorily only when they
present information to the user all portions.
• Relevancy
• Clarity
• Timeliness
• Cost
PHYSICAL FILE DESIGN AND DATA
BASE DESIGN

• The database design involves three levels of design concepts


namely Conceptual, Logical and Physical schemas.
Conceptual model produces a data model which accounts for
the relevant entities and relationships within the target
application domain.
• Logical model ensures via normalization procedures and
the definition of integrity rules that the stored database will
be non-redundant and properly connected.
• Physical model specifies how database records are stored,
accessed and related to ensure adequate performance.
Flat Files vs. Database
Flat File:
• Flat file databases are typically plain text files that store one record per line,
with record fields delimited by whitespace or a delimiting character. Flat file
databases can be read directly by a variety of software applications.
Database
• In addition to the data tables, databases use "indexes" to quickly find records
based on search criteria. Relational databases generally require a relational
database management system (RDBMS) to manage and access the data.
Benefits of Using Flat file Vs Database
Flat file databases are simple and portable, and typically can be used without
requiring special software. Relational databases are faster, more efficient and
more powerful than flat files. Most RDBMSs provide database access over
networks.
Steps in Database Design

• Analysis is the process of creating a conceptual data model


independent of the target database technology. The typical result
is an ER model.
• Design is the process of creating a logical data model. This step
is dependent on the target technology (relational, hierarchical, or
network), but not on the specific database implementation (such
as Oracle, MS SQL, DB2 for OS/390 or DB2 Universal Database).
• Implementation is the process of creating a physical model or
schema for one specific database system, such as Oracle, MS
SQL, DB2. The result is an optimized physical design.
Guidelines for Database Design
• ensure that the data stored in the files (database tables) are atomic. Data stored
in the atomic form can be combined later to generate data in specific form;
• every table must have a primary key which identifies each record in the table
distinctly. Descriptive and meaningful name is to be used while naming a field in
the table (For example, use product_id instead of ID);
• use single column primary key whenever possible. As most of the join
operations are made on primary key and composite primary keys make the
operation slower;
• use numeric key whenever possible;
• use primary key name as foreign key for better readability;
• avoid allowing null values to go into the columns that have discrete range of
possible values; and
• avoid multiple tables with similar structure when one table is sufficient.
DESIGN OF DATABASE FIELDS
• Primary key: Keys refer to the primary and foreign key that are
used to find database records and relate them to one another.
Primary should exist.
• Be unique in the table.
• The values must not change or become null during the life of each
entity instance.
• It must have a not-null value for each instance of the entity.
Secondary key: Also known as Alternate key. This is a field or
collection of fields in the table which can be used as primary key in
addition to the already existing primary key.
Descriptive fields: Attributes that are not used as key but store
business data.
Rules for Naming Tables and
Fields
Names for all database elements should be:

• Unique

• Meaningful

• Short

Restrictions for naming tables:

• Use no acronyms or abbreviations. Should be descriptive to convey meaning.

• Should not imply more than one subject

Restriction for naming fields:

• No acronyms

• Use abbreviations only if clear and meaningful

• Should not imply more than one subject

• Should be singular
While designing database fields,
it is required to set the properties
of the fields.
• Name: A name is used to refer the attribute in the DBMS that uniquely labels the field.
• Data type: Type of data the field is expected to store.
• Size: It indicates the size of the database fields
• Null or not Null: specifies whether the field will accept null value
• Domain: It indicates the range of values that are accepted by the fields.
• Default value: It refers to the value that is stored by default in the field.
• Referential integrity: It refers to a set of rules that avoid data inconsistency and
quality problems. Referential integrity ensures that a foreign key value cannot be
entered unless it matches a primary key value in another table.
DESIGN OF PHYSICAL FILES
Types of Files
Master file: is a permanent file of all the data needed by a business
Transaction file is a temporary file of all the transactions (items
bought, sold, deleted etc.) that have taken place in a given period.
Archive file is a file of data in permanent storage (usually, the data is
stored for legal reasons or to perform trend analysis).
Audit file is a file that does not store business data but data related to
transaction log. For example, data and time of access, modification etc.
Work file is file temporarily created to hold intermediate result of the
data processing. For example, a sorted file of list of customers.
File Organization
File organization is the physical organization of records on the disk.
There are different types of file organizations depending on the
organization of records in the disk and other secondary storage.
Advantage of File Organization:
• Fast retrieval of records
• Reduce disk access time
• Efficient use of disk spaces
Example:
Serial file organization
Sequential file organization
Indexed sequential file organization
Hashed file organization
Design Database

• Database design is similar to the pillars of a building. Any negligence, errors


in Database design may lead to degraded performance of the software. In
some cases such as real time applications, it may also lead to disasters.
The following are various steps in Database design :
• Selection of database architecture
• Designing database schema
• Selecting indexes
• Estimating capacity of the database
Thank You

You might also like