Database Development Lifecycle

Nowadays, organisations have been becoming more dependent on sofware applications, many of which require constant maintenance to:

• Correct faults
• Implement new user requirements
• Make modifications to run on new or upgraded machines

The maintenance ended up becoming more and more time-consuming, complex and expensive, leading to projects being late and often over-budget, along with software that did not meet user requirements and was made poorly.

• Approx. 40% of projects either fail or are abandoned
• 10% - 20% of all projects meet their original success points
• 80% of all information systems were delivered either late or over-budget

Reasons for a project failure include:

• Requirements not being thorough enough
• A methodology appropriate for the project is not used
• The design was not broken down into smaller tasks

A structured approach, known as the software development lifecycle, was proposed as a potential solution to the problem.

Information system = A set of resources that can:

• Enable the collection, management and control of data obtained or generated by the organisation
• Enable the transformation of this data into useful information
• Provide an infrastructure that facilitates disseminagtion of information to those making key decisions

Databases are key components to help support an information system, so it is important that a structured approach to database developemtn is used.

Stage of the IS lifecycle include:

• Planning
• Requirements collection and analysis
• Design
• Prototyping
• Implementation
• Testing
• Installation/conversion
• Maintenance and review

This is carries out by management right at the start of a project so that the DSDLC is:

• Understood efficiently and effectively
• In line with the broader objectives of the organisation's IS strategy

A mission statement is created in order to define the major aims of the database

Mission objectives define certain tasks that need to be supported, along with the resources needed to reach them.

Database planning also involves estimating the costs and the resources needed for the project. It can also include development of standards that look at:

• The way in which data is collected
• The format it should be in
• The necessary documentation
• How to design and implement the system
• Legal and organisational requirements relating to data management

A system definition will describe the scope and boundaries of the database system, including its major user views. It can also describe how the database system will interface with other parts of the organisation's information system

User views can define the requirements of a databast, from the following perspectives:

• A particular job
• A business application area

The definition helps to make sure that no users are forgotten when developing requirements for a new application, as well as help the development of a complex database system, allowing requriements to be broken down into smaller, more manageble pieces.

The requirements of some user groups may be shared, whilst others may be distinct. 

Information about the areas of an organisation to be served by the database is collected and analysed.

Known as fact finding.

Information is gathered for each major user view identified in the system definition, including:

• Description of the data used
• Details about how data is used
• Any other requirements

It's important that the required degree of functionality is found, as too much means an extremely complex system that is difficult to implement, and too little leads to systems that are inadequate and may result in the system being underused.

Three ways of dealing with multiple views are the centralised approach, the view integration approach, and a combination of the two.

Centralised approach = When requirements for each user view are merged into a single set of requirements for the database

Single data model representing all user views is created during the database design stage

It is preferred when there is significant overlap in requirements between views and the database is not too sophisticated.

View integration approach = Separate lists of requirements for each user view

Local data models representing each user view are created

Local models are merged to produce a global data model to represent all user views.

It is preferred when user views are distinct and the database is sufficiently complex to warrant dividing the modelling work into parts.

Process of creating a design that is going to support the organisation's mission statement and objectives for the proposed database system.

There are 3 main areas of database design:

• Conceptual - Creating the essential data model
• Logical - Turning the conceptual model into a certain data modelling representation
• Physical - Deciding how to implement the logical model within the target DBMS.

The aim of this is to:

• Select a product that meets the current, and potentially future, requirements of the organisation.
• It is balanced against initial and future costs.

No DBMS = Selection of a particular product would normally take place between logical and physical design phases.

Selection may take place earlier if the system requirements have enough information to support them.

Database application = Computer program that interacts with the database by issuing appropriate requests to the DBMS.

Usually provides a user interface that enables input and provides output.

Database and application design are both parallel activities.

There should be regular communication between both design processes as the database supports that applications.

Apps need to provide functionality identified in the requirements specification.

The design of the interaction between the user and the data is known as transaction design

Transaction = Action(s) carried out by a single user or database application that accesses or changes the content of the database.

There are three main types of transaction:

• Retrieval - (SELECT) e.g. when a user inputs the DVD number and the system will display all the details of the DVD
• Update - (UPDATE, INSERT, DELETE) e.g. user inputs the details of a new DVD title
• Mixed - Involves both retrieval and update transactions.

Characteristics of transactions for the database need to be defined and documented; such characteristics include:

• Data to be used by the transaction
• Functional characteristics of the transaction
• Transaction output
• Importance to the users
• Expected rate of usage

This design is often overlooked, yet it is one of the most vital aspects of application design

User interfaces that are not user friendly can frustrate users and lead to decrease in usage of the app.

Good user interfaces need to be:

• Easy to learn, as well as remember
• Efficient in use - Tasks are completed simply and swiftly
• Forgiving (when errors are made)
• Satisfying - Good interaction

Prototype = Working model of the database system that partially provides features and functionality of the intended system

Purpose is:

• To identify features that work well, and which ones need improvement
• To clarify user requirements
• To suggest improvements and maybe new features
• To evaluate feasibility of a particular system design

Prototyping can be done rather early in the design process

Prototype may be cheap and easy to build but the feedback it can provide to the requirements specification and design process can be valuable.

Implementation happens when the design phase is finished

Database structure, user views and empty files are created using the data definition language, which is a part of SQL

Database applications are implemented through the use of a suitble programming language, such as Java, C# or C++.

Transactions are done through  the use of the data manipulation language, whilst user interfaces are also coded.

Data definition language can also be used for security and integrity controls, but some DBMS's may provide separate utilities for this.

Transferring exisiting data into a new database and converting any existing applications to run on a new database.

Only required when a new database system is replacing an old one.

Common for a DBMS to have a utility that loads existing files into the new database.

Also possible for programs from the old system to be converted to the new one.

Testing = Running the database system to look for errors

This is done thorugh the use of planned test strategies and realistic data

Users need to be involved in the testing process to test the usability

Testing should firstly take place on an isolated system early on, otherwise it is important to make regular backups in case of unexpected errors.

Successful completion can show that the database and applications are working according the requirements and the database is ready for use.

This is the process of monitoring the database system following the installation and it involves:

• Monitoring system performance. If performance decreases, the system may need to be tuned or the database reorganised.
• Maintaining and upgrading the database system
• Incorporating new requirements into the database system.