2/12/2015

UK OASIG conclusions about Software Projects

 What is software crisis or software depression
 If a major software projects is late, over budget, unreliable, difficult to
maintain, or/and performed poorly.
Database Planning,
Design, and Administration UK OASIG conclusions about Software Projects
 80–90% do not meet their performance goals;
 about 80% are delivered late and over budget;
Prepared By G.Uthayakumar  around 40% fail or are abandoned;
 under 40% fully address training and skills requirements;
 less than 25% properly integrate enterprise and technology objectives;
 just 10–20% meet all their success criteria.
 What are the major reasons for the failure of software projects including:
 lack of a complete requirements specification;
 lack of an appropriate development methodology;
 poor decomposition of design into manageable components.

2 Prepared By Uthayakumar

What is a solution to these problems? The Information Systems Lifecycle

 a structured approach to the development of software was proposed  Information system
called the Information Systems Lifecycle (ISLC) or the  The resources that enable the collection, management, control, and
Software Development Lifecycle (SDLC). dissemination of information throughout an organization.
 When the software being developed is a database system the  A computer-based information system includes a database,
lifecycle is more specifically referred to as the Database System database software, application software, computer hardware, and
Development Lifecycle (DSDLC). personnel using and developing the system.
 The database is a fundamental component of an information
system.
 Stages in the lifecycle of an information system include:
 planning, requirements collection and analysis, design,
prototyping, implementation, testing, conversion, and
operational maintenance.

3 Prepared By Uthayakumar 4 Prepared By Uthayakumar

The Database System Development Lifecycle  Application design

 Designing the user interface and the application programs that use and
 Database planning process the database.
 Planning how the stages of the lifecycle can be realized most efficiently and  Prototyping (optional)
effectively.  Building a working model of the database system, which allows the designers
 System definition or users to visualize and evaluate how the final system will look and function.
 Specifying the scope and boundaries of the database system, including the  Implementation
major user views, its users, and application areas.  Creating the physical database definitions and the application programs.
 Requirements collection and analysis  Data conversion and loading
 Collection and analysis of the requirements for the new database system.  Loading data from the old system to the new system and, where possible,
 Database design converting any existing applications to run on the new database.
 Conceptual, logical, and physical design of the database.  Testing
 Conceptual Database design  Database system is tested for errors and validated against the requirements
 Logical Database design specified by the users.
 Physical Database design  Operational maintenance
 DBMS selection (optional)  Database system is fully implemented. The system is continuously monitored
 Selecting a suitable DBMS for the database system. and maintained.When necessary, new requirements are incorporated into the
database system through the preceding stages of the lifecycle.

5 Prepared By Uthayakumar 6 Prepared By Uthayakumar

1
 2/12/2015

Database Planning System Definition

 The management activities that allow the stages of the database system  Describes the scope and boundaries of the database application and
development lifecycle to be realized as efficiently and effectively as the major user views.
possible.
 User Views Defines what is required of a database system from the
 Main issues involved in formulating an IS strategy
 identification of enterprise plans and goals with subsequent determination of perspective of a particular job role (such as Manager or Supervisor)
information systems needs; or enterprise application area (such as marketing, personnel, or
 evaluation of current information systems to determine existing strengths and stock control).
weaknesses;
 appraisal of IT opportunities that might yield competitive advantage.
 Database planning development of standards that govern
 how data will be collected,
 how the format should be specified,
 what necessary documentation will be needed,
 and how design and implementation should proceed.

7 Prepared By Uthayakumar 8 Prepared By Uthayakumar

Requirements Collection and Analysis

 The process of collecting and analyzing information about the part of the
organization that is to be supported by the database system, and using this
information to identify the requirements for the new system.
 The fact-finding techniques is used to gathering this information.
 Information is gathered for each major user view (that is, job role or
enterprise application area), including:
 a description of the data used or generated;
 the details of how data is to be used or generated;
 Any additional requirements for the new database system
 This information is then analyzed to identify the requirements (or
features) to be included in the new database system.
 This is requirements specifications for the new database system.
Representation of a database system with multiple user views: user views (1, 2,  The requirements specification techniques used to convert poorly
and 3) and (5 and 6) have overlapping requirements (shown as hatched areas), structured information into more structured statement of requirements.
whereas user view 4 has distinct requirements.
9 Prepared By Uthayakumar 10 Prepared By Uthayakumar

Requirements specification techniques  Three main approaches to managing the requirements of a

database system with multiple user views, namely:
 Structured Analysis and Design (SAD) techniques,
 the centralized approach;
 Data Flow Diagrams (DFD),
 Requirements for each user view are merged into a single set of
 and Hierarchical Input Process Output (HIPO) charts supported by
requirements for the new database system. A data model representing
documentation. all user views is created during the database design stage.
 Computer-Aided Software Engineering (CASE) tools may
 the view integration approach;
provide automated assistance to ensure that the requirements are
 Requirements for each user view remain as separate lists. Data models
complete and consistent. representing each user view are created and then merged later during
the database design stage.
 a combination of both approaches.

11 Prepared By Uthayakumar 12 Prepared By Uthayakumar

2
 2/12/2015

The view integration approach to managing

multiple user views 1 to 3.

The centralized approach to managing multiple user views 1 to 3.

13 Prepared By Uthayakumar 14 Prepared By Uthayakumar

Database Design  The inside-out approach is related to the bottom-up

approach but differs by first identifying a set of major entities and
 The process of creating a design that will support the enterprise’s then spreading out to consider other entities, relationships, and
mission statement and mission objectives for the required database attributes associated with those first identified.
system.  The mixed strategy approach uses both the bottom-up and top-
 Top-down approach. down approach for various parts of the model before finally
 This approach starts with the development of data models that contain combining all parts together.
a few high-level entities and relationships and then applies successive
top-down refinements to identify lower-level entities, relationships,
and the associated attributes.
 The approach is illustrated using the concepts of the Entity–
Relationship (ER) model, beginning with the identification of entities
and relationships between the entities, which are of interest to the
organization.

15 Prepared By Uthayakumar 16 Prepared By Uthayakumar

Data Modeling Phases of Database Design

 The two main purposes of data modeling are to assist in the  Conceptual database design
understanding of the meaning (semantics) of the data and to  The process of constructing a model of the data used in an enterprise,
facilitate communication about the information requirements. independent of all physical considerations.
 Building a data model requires answering questions about entities,  Logical database design
relationships, and attributes.  The process of constructing a model of the data used in an enterprise
 model data to ensure that we understand: based on a specific data model, but independent of a particular DBMS
 each user’s perspective of the data;
and other physical considerations.
 the nature of the data itself, independent of its physical representations;  Physical database design
 the use of data across user views.  The process of producing a description of the implementation of the
database on secondary storage; it describes the base relations, file
organizations, and indexes used to achieve efficient access to the data,
and any associated integrity constraints and security measures.

17 Prepared By Uthayakumar 18 Prepared By Uthayakumar

3
 2/12/2015

 In general, the main aim of physical database design is to describe DBMS Selection
how we intend to physically implement the logical database design.
For the relational model, this involves:  The selection of an appropriate DBMS to support the database
 creating a set of relational tables and the constraints on these tables system.
from the information presented in the logical data model;
 identifying the specific storage structures and access methods for
the data to achieve an optimum performance for the database Data modeling and
system; the ANSI-SPARC
 designing security protection for the system. architecture.
 Ideally, conceptual and logical database design for larger systems
should be separated from physical design for three main reasons:
 it deals with a different subject matter – the what, not the how;
 it is performed at a different time – the what must be understood before
the how can be determined;
 it requires different skills, which are often found in different people.
19 Prepared By Uthayakumar 20 Prepared By Uthayakumar

 Main steps to selecting a DBMS.  Evaluate products

 Define Terms of Reference of study  lists possible features for DBMS product evaluation grouped by data
 The Terms of Reference for the DBMS selection is established, stating the definition, physical definition, accessibility, transaction handling,
objectives and scope of the study, and the tasks that need to be undertaken. utilities, development, and other features.
 Shortlist two or three products
 Criteria considered to be ‘critical’ to a successful implementation can be used to
produce a preliminary list of DBMS products for evaluation.
 For example, the decision to include a DBMS product may depend on the budget
available, level of vendor support, compatibility with other software, and whether
the product runs on particular hardware.
 Additional useful information on a product can be gathered by contacting existing
users who may provide specific details on how good the vendor support actually is,
on how the product supports particular applications, and whether or not certain
hardware platforms are more problematic than others.

21 Prepared By Uthayakumar 22 Prepared By Uthayakumar

23 Prepared By Uthayakumar 24 Prepared By Uthayakumar

4
 2/12/2015

 Recommend selection and produce report

 The final step of the DBMS selection is to document the process and to
provide a statement of the findings and recommendations for a
particular DBMS product.

25 Prepared By Uthayakumar 26 Prepared By Uthayakumar

Application Design Transaction Design

 The design of the user interface and the application programs that  An action, or series of actions, carried out by a single user or
use and process the database. application program, which accesses or changes the content of the
 database and application design are parallel activities of the database database.
system development lifecycle.  The purpose of transaction design is to define and document the
 In most cases, it is not possible to complete the application design high-level characteristics of the transactions required on the
until the design of the database itself has taken place. database, including:
 data to be used by the transaction;
 functional characteristics of the transaction;
 output of the transaction;
 importance to the users;
 expected rate of usage.

27 Prepared By Uthayakumar 28 Prepared By Uthayakumar

Three main types of transactions: User Interface Design Guidelines

 Retrieval transactions are used to retrieve data for display on  Before implementing a form or report, it is essential that we first
the screen or in the production of a report. design the layout.
 For example, the operation to search for and display the details of a
property (given the property number) is an example of a retrieval
transaction.
 Update transactions are used to insert new records, delete Guidelines for form/
old records, or modify existing records in the database. report design.
 For example, the operation to insert the details of a new property into
the database is an example of an update transaction.
 Mixed transactions involve both the retrieval and updating
of data.
 For example, the operation to search for and display the details of a
property (given the property number) and then update the value of the
monthly rent is an example of a mixed transaction.
29 Prepared By Uthayakumar 30 Prepared By Uthayakumar

5
 2/12/2015

Prototyping Implementation
 Building a working model of a database system.  The physical realization of the database and application designs.
 A prototype is a working model that does not normally have all the  On completion of the design stages (which may or may not have
required features or provide all the functionality of the final system. involved prototyping), now in a position to implement the database
 The main purpose of developing a prototype database system is to and the application programs.
allow users to use the prototype to identify the features of the
 The database implementation is achieved using the Data Definition
system that work well, or are inadequate, and if possible to suggest
improvements or even new features to the database system. Language (DDL) of the selected DBMS or a Graphical User
 two prototyping strategies
Interface (GUI).
 Requirements prototyping uses a prototype to determine the  The application programs are implemented using the preferred
requirements of a proposed database system and once the requirements third or fourth generation language (3GL or 4GL).
are complete the prototype is discarded.  possibly embedded within a host programming language, such as
 Evolutionary prototyping is used for the same purposes, the
Visual Basic (VB), VB.net, Python, Delphi, C, C++, C#, Java,
important difference is that the prototype is not discarded but with
further development becomes the working database system. COBOL, Fortran, Ada, or Pascal.

31 Prepared By Uthayakumar 32 Prepared By Uthayakumar

Data Conversion and Loading  Testing should also cover usability of the database system.
 Learnability – How long does it take a new user to become
 Transferring any existing data into the new database and converting productive with the system?
any existing applications to run on the new database.
 Performance – How well does the system response match the user’s
 Testing work practice?
 The process of running the database system with the intent of  Robustness – How tolerant is the system of user error?
finding errors.
 Recoverability – How good is the system at recovering from user
 Before going live, the newly developed database system should be
errors?
thoroughly tested.
 This is achieved using carefully planned test strategies and realistic data
 Adapatability – How closely is the system tied to a single model of
so that the entire testing process is methodically and rigorously carried work?
out.

33 Prepared By Uthayakumar 34 Prepared By Uthayakumar

Operational Maintenance CASE Tools

 The process of monitoring and maintaining the database system  CASE support may include:
following installation.  a data dictionary to store information about the database system’s
 which involves the following activities: data;
 Monitoring the performance of the system. If the performance falls  design tools to support data analysis;
below an acceptable level, tuning or reorganization of the database may
 tools to permit development of the corporate data model, and the
be required.
conceptual and logical data models;
 Maintaining and upgrading the database system (when required). New
requirements are incorporated into the database system through the  tools to enable the prototyping of applications.
preceding stages of the lifecycle.  CASE tools may be divided into three categories:
 upper-CASE,
 lower-CASE,
 and integrated-CASE,

35 Prepared By Uthayakumar 36 Prepared By Uthayakumar

6
 2/12/2015

 CASE tools provide the following benefits that improve

productivity:
 Standards CASE tools help to enforce standards on a software project or
across the organization.
 They encourage the production of standard test components that can
be reused, thus simplifying maintenance and increasing productivity.
 Integration CASE tools store all the information generated in a repository, or
data dictionary.
 Thus, it should be possible to store the data gathered during all stages
of the database system development lifecycle. The data then can be
linked together to ensure that all parts of the system are integrated. In
this way, an organization’s information system no longer has to consist
of independent, unconnected components.

37 Prepared By Uthayakumar 38 Prepared By Uthayakumar

 Support for standard methods Structured techniques make significant use of Data Administration and Database Administration
diagrams, which are difficult to draw and maintain manually.
 CASE tools simplify this process, resulting in documentation that is  The Data Administrator (DA) and Database Administrator (DBA)
correct and more current. are responsible for managing and controlling the activities
associated with the corporate data and the corporate database,
 Consistency Since all the information in the data dictionary is
respectively.
interrelated, CASE tools can check its consistency.
 Automation Some CASE tools can automatically transform parts of a design
specification into executable code.
 This reduces the work required to produce the implemented system,
and may eliminate errors that arise during the coding process.

39 Prepared By Uthayakumar 40 Prepared By Uthayakumar

Data Administration
 The management of the data resource, which includes database
planning, development, and maintenance of standards, policies and
procedures, and conceptual and logical database design.
 The Data Administrator (DA) is responsible for the corporate data
resource, which includes non-computerized data, and in practice is
often concerned with managing the shared data of users or
application areas of an organization.

41 Prepared By Uthayakumar 42 Data administration tasks. Prepared By Uthayakumar

7
 2/12/2015

Database Administration
 The management of the physical realization of a database system,
which includes physical database design and implementation, setting
security and integrity controls, monitoring system performance,
and reorganizing the database, as necessary.
 The database administration staff are more technically oriented than
the data administration staff, requiring knowledge of specific
DBMSs and the operating system environment.

Database administration tasks.

43 Prepared By Uthayakumar 44 Prepared By Uthayakumar

Data administration and database administration – main task

differences.

45 Prepared By Uthayakumar