1. Chapter 10 DB SDLC
Ahmed M. Zeki
ITIS 216
ITBIS 385

2. Objectives Main components of an IS The main stages of the DB SDLC
/ 88

3. Introduction
Software has surpassed hardware as the key to the success of many computer based systems.
Ranges form small applications consisting of a few lines of code, to large and complex applications consisting of millions of lines of code.
/ 88

4. Introduction They require constant maintenance:
Correcting faults
Implementing new user requirements
Modifying software to run on new or upgraded platforms
Maintenance absorbs resources at an alarming rate.
/ 88

5. Introduction As a result many major software projects were:
Late
Over budget
Unreliable
Difficult to maintain
Performed poorly
 Software Crisis, Software Depression
/ 88

6. Software Projects Today
80-90% do not meet their performance goals
80% delivered late and over budget
40% fail or are abandoned
40% fully address training and skills requirements
25% properly integrate enterprise and technology objectives
10-20% meet all their success criteria
/ 88

7. Reasons for Failure of Software Projects
lack of a complete requirements specification;
lack of appropriate development methodology;
poor decomposition of design into manageable components.
Information Systems Lifecycle (ISLC): structured approach to development of ISs
/ 88

8. ISLC
IS: the resources that enable the collection, management, control, and dissemination of information throughout an organization.
1970s: DB systems gradually replaced the file-based systems as part of an organization’s IS infrastructure.
/ 88

9. DB SDLC Growing recognition that data is an important resource
 should be treated with respect
 Data Administration Department which responsible for the management and control of the corporate data
 DB Administration which is responsible for the corporate DB
/ 88

10. DB SDLC Computer based IS includes:
DB software
Application software
Computer hardware
Personnel using and developing the system
DB is a fundamental component of an IS
Development and usage of IS should be viewed form the perspective of the wider requirements of the organization.
/ 88

11. DB SDLC ISLC   DBSLC ISLC includes: Planning
Requirements collection and analysis
Design
Prototyping
Implementation
Testing
Conversion
Operational maintenance
/ 88

12. DB SDLC
DB Planning: Planning how the stages of the LC can be realized most efficiently and effectively.
System Definition: Specifying the scope and boundaries of the DB system, including the major user views, its users, and application areas.
Requirement Collection and Analysis: Collection and analysis of the requirements for the new DB system.
DB Design: Conceptual, logical, and physical design of the DB.
DBMS Selection: selecting a suitable DBMS for the DB System
Application Design: Designing the UI and the application programs that use and process the DB.
Prototyping: Building a working model of the DB system which allows the designers or users to visualize and evaluate how the final system will look and function.
Implementation: Creating the physical DB definitions and the application programs.
Data Conversion and Loading: Loading data from the old system to the new one and converting any existing applications to run on the new one
Testing: DB system is tested for errors and validated against the requirements specified by the users.
Operational Maintenance: DB system is fully implemented. The system is continuously monitored and maintained. When necessary, new requirements are incorporated into the DB system through the preceding stages of the LC.
/ 88

13. DB SDLC
DB SDLC Not strictly sequential. It involves some repetition through feedback loops
For small DB systems, with a small number of users, the lifecycle need not be very complex.
When designing a medium to large DB systems with tens to thousands of users, using hundreds of queries and application program, the LC can become extremely complex.
/ 88

14. DB Planning
Management activities that allow stages of DB system development lifecycle to be realized as efficiently and effectively as possible.
Must be integrated with overall IS strategy of the organization.
/ 88

15. DB Planning IS Strategy:
Identification of enterprise plans and goals with subsequent determination of IS needs
Evaluation of current IS to determine existing strengths and weaknesses
Appraisal of IT opportunities
/ 88

16. DB Planning – Mission Statement
Mission statement for the DB project defines major aims of DB application.
Usually defined by those driving DB project (eg. Director or owner).
Helps clarify purpose of the DB project and provides clearer path towards the efficient and effective creation of required DB system.
/ 88

17. DB Planning – Mission Objectives
Once mission statement is defined, mission objectives are defined.
Each objective should identify a particular task that the DB must support.
May be accompanied by some additional information that specifies the work to be done, the resources with which to do it, and the money to pay for it all.
/ 88

18. DB Planning
DB planning should also include development of standards that govern:
how data will be collected,
how the format should be specified,
what necessary documentation will be needed,
how design and implementation should proceed
Standards development and maintenance can be time consuming
/ 88

19. DB Planning
Well defined set of standards provides a basis for training staff and measuring quality control, and can ensure that work conforms to a pattern, irrespective of staff skills and experience.
Ex: specific rules may govern how data items can be named in the data dictionary, which in turn may prevent both redundancy and inconsistency.
Any legal or enterprise requirements concerning the data should be documented. Such as the stipulation that some types of data must be treated confidentially.
/ 88

20. System Definition
Describes scope and boundaries of DB system and the major user views. i.e. how it interfaces with other parts of the organization’s IS.
System boundaries should also include futures users and applications.
/ 88

21. System Definition
User view defines what is required of a DB system from perspective of:
a particular job role (such as Manager or Supervisor)
enterprise application area (such as marketing, personnel, or stock control).
DB application may have one or more user views.
/ 88

22. System Definition
Identifying user views helps ensure that no major users of the DB are forgotten when developing requirements for new system.
User views also help in development of complex DB system allowing requirements to be broken down into manageable pieces.
/ 88

23. System Definition
User view defines what is required of a DB system in terms of the data to be held and the transactions to be performed on the data, i.e what the user will do with the data.
Such requirements may be distinct to a view or overlap with other views.
/ 88

24. System Definition
/ 88

25. Requirements Collection and Analysis
Process of collecting and analyzing information about the part of organization to be supported by the DB system, and using this information to identify users’ requirements of new system.
There are many techniques for gathering this information, called fact-finding techniques.
Information is gathered for each major user view (i.e. job role or enterprise application area).
/ 88

26. Requirements Collection and Analysis
Information is gathered for each major user view including:
a description of data used or generated;
details of how data is to be used/generated;
any additional requirements for new DB system.
Information is analyzed to identify requirements to be included in new DB system. Described in a document called requirements specification.
/ 88

27. Requirements Collection and Analysis
How much information should we collect?
Depends on the nature of the problem and the policies of the enterprise.
Too much data gathered leads to paralysis by analysis.
Too little thought can result in an unnecessary waste of both time and money due to working on the wrong solution to the wrong problem.
/ 88

28. Requirements Collection and Analysis
If the information gathered is poorly structured and contains some informal requests  convert it into a more structured statement of requirements using requirements specification techniques, which include:
Structured Analysis and Design techniques (SAD)
Data Flow Diagrams (DFD)
Hierarchical Input Process Output charts (HIPO)
CASE provides such automated assistance
/ 88

29. Requirements Collection and Analysis
Identifying the required functionality for a DB system is a critical activity
Systems with inadequate functionality annoys users
 rejection or underutilization of the system
Systems with excessive functionality can also be problematic
 overcomplicate the system, difficult to implement, maintain, use, or learn.
/ 88

30. Requirements Collection and Analysis
How to manage the requirements for a DB system with multiple user views?
centralized approach;
view integration approach;
combination of both approaches
/ 88

31. Requirements Collection and Analysis
Centralized approach
Requirements for each user view are merged into a single set of requirements.
A data model is created representing all user views during the DB design stage.
This approach is preferred when there is a significant overlap in requirements for each user view and the DB system is not overly complex.
/ 88

32. Requirements Collection and Analysis
View integration approach
Requirements for each user view remain as separate lists.
Data models representing each user view are created (called local data model) and then merged later during the DB design stage to produce a global data model which represents all user requirements for the DB.
Each model includes diagrams and documentation describing requirements for one or more, but not all user views of DB.
/ 88

33. Requirements Collection and Analysis
This approach is preferred when there are significant differences between user views and the DB system is sufficiently complex to justify dividing the work into more manageable parts.
/ 88

34. Requirements Collection and Analysis
Combination of both approaches
When the DB is too complex
Ex: the requirements for two or more user views may be first merged using the centralized approach
The output is used to build a local logical data model
The model is then merged with other local logical data models using the view integration approach
The output will be a global logical data model.
In this case, each local logical data model represents the requirements of two or more user views and the final global logical data model represents the requirements of all user views.
/ 88

35. DB Design
Process of creating a design for a DB that will support the enterprise’s mission statement and mission objectives for the required DB system.
Approaches
Bottom-up
Top-down
Inside-out
Mixed
/ 88

36. DB Design: Bottom-up Starts with the attributes
Analysis of associations between attributes
Attributes grouped into relations that represent types of entities and relationships
Normalization is bottom-up
It is the identification of the required attributes and their subsequent aggregation into normalized relations based on functional dependencies between the attributes.
/ 88

37. DB Design: Bottom-up
It is appropriate for the design of simple DBs with a relatively small number of attributes.
It becomes difficult with complex DBs, where it is difficult to establish all the functional dependencies between attributes.
/ 88

38. DB Design: Top-down More appropriate for complex DBs.
Development of data models that contains a few high-level entities and relationships
Applies successive top-down refinements to identify lower-level entities, relationships, and the associated attributes.
Represented using ER model.
/ 88

39. DB Design: Inside-out
Related to the bottom-up approach but differs by first identifying a set of major entities and then spreading out to consider other entities, relationships and attributes.
/ 88

40. DB Design: Mixed
Uses both for various parts of the model before finally combining all parts together.
/ 88

41. Data Modeling Purposes
to assist in understanding the meaning (semantics) of the data
to facilitate communication about the information requirements.
Building data model requires answering questions about entities, relationships, and attributes by discovering the semantic of the enterprise’s data.
/ 88

42. Data Modeling A data model ensures we understand:
- each user’s perspective of the data
- nature of the data itself, independent of its physical representations
- use of data across user views
 Data model used to convey the designer’s understanding of the information requirements of the enterprise  supports communication between users and designers.
ER becomes the standards
/ 88

43. Criteria to produce optimal data model
The model should satisfy the following criteria. Sometimes tradeoffs are necessary.
Ex: in attempting to achieve grater expressibility in a data model, we may lose simplicity.
/ 88

44. DB Design Phases: Conceptual DB Design
Process of constructing a model of the data used in an enterprise, independent of all physical considerations.
Data model is built using the information in users’ requirements specification.
The conceptual model should be tested and validated against the user’s requirements.
/ 88

45. DB Design Phases: Conceptual DB Design
Conceptual DB design is independent of implementation details such as:
the target DBMS software
application programs
programming language
hardware platform
any other physical consideration
Conceptual data model is source of information for logical design phase.
/ 88

46. DB Design Phases: Logical DB Design
Process of constructing a model of the data used in an enterprise based on a specific data model (e.g. relational), but independent of a particular DBMS and other physical considerations.
Conceptual data model is refined and mapped on to a logical data model.
/ 88

47. DB Design Phases: Logical DB Design
The logical data model is based on the target data model for the DB (e.g. the relational data model).
Conceptual data model is independent of all physical considerations.
Logical model is derived knowing underlying data model of the target DBMS.
i.e. we know that the DBMS is relational, network, etc but we ignore any other aspects of the chosen DBMS related to the physical details such as storage structure or indexes.
/ 88

48. DB Design Phases: Logical DB Design
While developing the logical data model, the model will be tested and validated against the user’s requirements (using normalization).
Normalization ensures that the relations derived from the data model do not display data redundancy, which can cause update anomalies when implemented.
The logical data model should also be examined to ensure that it supports the transactions specified by users.
/ 88

49. DB Design Phases: Logical DB Design
The logical data model is a source of information for the next phase (physical DB design).
It Serves an important role during the operational maintenance stage of the DBSDLC.
If the logical data model is properly maintained and kept up to date, it allows future changes to application programs or data to be accurately and efficiently represented by the DB.
/ 88

50. DB Design Phases: Physical DB Design
Process of producing a description of the DB implementation on secondary storage.
Describes base relations, file organizations, and indexes used to achieve efficient access to data. Also describes any associated integrity constraints and security measures.
/ 88

51. DB Design Phases: Physical DB Design
Here the designer decides how the DB is to be implemented.
Must first identify the target DBMS.
There is feedback between physical and logical design, because decisions are taken during physical design for improving performance that may affect the structure of the logical data model.
/ 88

52. DB Design Phases: Physical DB Design
Stages:
Creating a set of relational tables and the constraints of these tables from the information presented in the logical data model.
Identifying the specific storage structures and access methods for the data to achieve and optimum performance for the DB system.
Designing security protection for the system.
/ 88

53. DB Design Phases: Physical DB Design
Conceptual and logical DB design for larger systems should be separated from physical design. Why?
It deals with a different subject matter, i.e. 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.
/ 88

54. DB Design Phases: Physical DB Design
DB design is an iterative process (should be viewed as learning process).
Once the designer understands the workings of the enterprise and the meanings of its data, and express that understanding in the selected data models  the information gained may well necessitate changes to other parts of the design.
/ 88

55. DB Design Phases: Physical DB Design
In particular, conceptual and logical DB design are critical to the overall success of the system.
If the designs are not a true representation of the enterprise, it will be difficult if not impossible to define all the required user views or to maintain DB integrity and difficult to define the physical implementation or to maintain acceptable system performance.
/ 88

56. DB Design Phases: Physical DB Design
The ability to adjust to change is one hallmark of good DB design. Therefore, it is worthwhile spending the time and energy necessary to prudence the best possible design.
/ 88

57. DB Design Phases: Physical DB Design
This figure illustrates the correspondence between the ANSI-SPARC architecture and conceptual, logical and physical DB design.
/ 88

58. DBMS Selection
Selection of an appropriate DBMS to support the DB system.
Undertaken at any time prior to logical design provided sufficient information is available regarding system requirements (such as performance, ease of restructuring, security, and integrity constraints).
Steps to selecting a DBMS:
define ‘Terms of Reference’ of study;
shortlist two or three products;
evaluate products;
recommend selection and produce report.
/ 88

59. DBMS Selection: Defines Terms of Reference of Study
Stating the:
Objectives
Scope of the study
Tasks that need to be undertaken
May also include:
Description of the criteria based on the users’ requirements specification to be used to evaluate the DBMS products
A preliminary list of possible products
All necessary constraints and timescales for the study
/ 88

60. DBMS Selection: Shortlist 2 or 3 Products
Criteria of selection may depend on:
Budget available
Level of vendor support
Compatibility with other software
Runs on particular h/w
How good the vendor support is
How the product supports particular application
Whether or not certain h/w platforms are more problematic than others
Such information can be gathered from:
Existing users
Internet
Benchmarking reports
/ 88

61. DBMS Selection: Evaluate Products
Features can be assessed as groups.
Approach of providing weightage for the features, with respect to their importance to the organization.
Products are compared based on their overall weighted value.
In-house testing by vendors (e.g demonstration)  creating a pilot testbed using the candidate products. Products will be tested against their ability to meet the user’s requirements for the DB system.
/ 88

62. DBMS Selection: Evaluate Products
/ 88

63. DBMS Selection: Evaluate Products
/ 88

64. DBMS Selection: Evaluate Products
The score for the group is then itself subject to a weighting
/ 88

65. DBMS Selection: Recommend Selection and Produce Report
Report to provide statement of finding and recommendation.
/ 88

66. Application Design
Design of UI and application programs that use and process the DB.
DB design and application design are parallel activities.
In most cases it is not possible to complete the application design until the design of the DB has taken place.
On the other hand, the DB exists to support the applications, so there must be a flow of information between application design and DB design.
/ 88

67. Application Design Includes:
Designing the application program that access the DB
Transaction design
UI design, should be user-friendly
Easy to learn
Simple to use
Straightforward
forgiving
Importance of UI sometimes ignored or delayed !
/ 88

68. Application Design: Transaction Design
Action(s) carried out by a single user or application program, which accesses or changes content of the DB.
Represent real world events, e.g
Registering of a property for rent
Addition of a new member of staff
Registration of a new client
Renting out of a property
/ 88

69. Application Design: Transaction Design
Why do we need transactions:
To ensure that data held by the DB remains current with the real world situation
To support the information needs of the users
Transaction may composed of several operations, e.g:
Transfer of money from one account to another
but to the user they look as one. To the DBMS, it transfers the DB from one consistent state to another. i.e. it ensures consistency even in the presence of failure.
/ 88

70. Application Design: Transaction Design
Once the transaction is done, the changes done are permanently stored and can’t be lost or undone (without running another transaction to compensate the effect of the first).
If the transaction can’t complete for some reasons, the DBMS should ensure that the changes made by that transaction are undone.
/ 88

71. Application Design: Transaction Design
The purpose of the transaction design is to define and document the high-level characteristics of the transactions required:
Data to be used by the transaction
Functional characteristics of the transaction
Output of the transaction
Importance to the users
Expected rate of usage
This activity should be carried out early in the design process to ensure that the implemented DB is capable of supporting all the required transactions.
/ 88

72. Application Design: Transaction Design
Types of transactions:
Retrieval: used to retrieve data for display
Ex: to search for and display the details of a property given the property number.
Update: used to insert new records, delete, or modify existing records.
Ex: the operation to insert the details of a new property into the DB.
Mixed: both retrieval and updating of data.
Ex: search and then update of the value of the monthly rent.
/ 88

73. UI Design Guidelines Meaningful Title Comprehensible instructions
Brief instructions
Familiar terminology
Help screen, if needed
Consistent style
Standard format
Logical grouping and sequencing of fields
Should be logical and consistent
/ 88

74. UI Design Guidelines Visually appealing layout of the form/report
Attractive interface
Should appear balanced with fields or groups of fields evenly positioned throughout the form/report.
There should not be areas have too few or too many fields.
Fields should be separated by a regular amount of space.
Fields should be vertically or horizontally aligned.
Appearance of hardcopy and its equivalent on the screen should be consistent.
/ 88

75. UI Design Guidelines Familiar field labels
Consistent terminology and abbreviations
Consistent use of color
Colors are used to improve the appearance and highlight important fields or messages.
E.g fields with white background  to be filled
with blue  for display only
Visible space and boundaries for data-entry fields
To indicate the total amount of space available.
/ 88

76. UI Design Guidelines Convenient cursor movement
E.g using the Tab key
Error correction for individual characters and entire fields
Error messages for unacceptable values
What is the error
How to correct it
What are the permissible values
Optional fields marked clearly
Should be placed after required fields
/ 88

77. UI Design Guidelines Explanatory messages for fields Completion signal
E.g status bar or yellow boxes
Completion signal
/ 88

78. Prototyping Building working model of a DB system.
Don’t have all features or functionalities.
Purpose
to identify features of a system that work well, or are inadequate;
to suggest improvements or even new features;
to clarify the users’ requirements;
to evaluate feasibility of a particular system design.
/ 88

79. Prototyping Should be inexpensive and quick to build. Types:
Requirements prototyping: to determine the requirements of a proposed DB system and once the requirements are complete the prototype is discarded.
Evolutionary prototyping: not discarded but further developed to become the working DB system.
/ 88

80. Implementation Physical realization of the DB and application designs.
Done after completing the design stages.
Achieved using:
DDL (commands or GUI) to create DB schemas and empty DB files.
DDL to create any specified user views.
Use 3GL or 4GL to create the application programs. This will include the DB transactions implemented using the DML, possibly embedded in a host programming language.
Menu screens, forms, reports.
/ 88

81. Implementation
Security and integrity controls for the system are also implemented at this stage.
Some or them implemented using the DDL and some using outside the DDL using such as supplied DBMS utilities or OS controls.
/ 88

82. Data Conversion and Loading
Transferring any existing data into new DB and converting any existing applications to run on new DB.
Only required when new DB system is replacing an old system.
DBMS normally has utility that loads existing files into new DB.
May be possible to convert and use application programs from old system for use by new system.
Should be properly planned.
/ 88

83. Testing
Process of running the DB system with intent of finding errors.
Use carefully planned test strategies and realistic data.
Testing cannot show absence of faults; it can show only that software faults are present.
If done correctly, it uncovers errors with the application programs and DB structure.
Demonstrates that DB and application programs appear to be working according to the performance requirements.
/ 88

84. Testing
Metrics collected from the testing stage provide a measure of software reliability and quality.
Users of the new system should be involved in the testing process.
The ideal situation for system testing is to have a test DB on a separate h/w system.
If real data is to be used, it is essential to have backups taken in case of error.
/ 88

85. Testing Testing should also cover usability of the DB system.
Examples of criteria that can be used to conduct the evaluation (some may be evaluated in other stages of the lifecycle):
Learnability: how long does it take a new user to become a productive with the system?
Performance: how well does the system response match the user’s work practice?
Robustness: how tolerant is the system of user error?
Recoverability: how good is the system at recovering form user errors?
Adaptability: how closely is the sytem tied to a single model of work?
/ 88

86. Operational Maintenance
Process of monitoring and maintaining DB system following installation. Involves:
Monitoring performance of system.
if performance falls below an acceptable level, may require tuning or reorganization of the DB.
Maintaining and upgrading DB application (when required).
Incorporating new requirements into DB application.
/ 88

87. Operational Maintenance
DBMS provides utilities to aid DB administration including utilities to load data into a DB and to monitor the system.
Utilities provide information on:
DB usage
Locking efficiency, e.g. # of deadlocks occurred
Query execution strategy
DBA can use such information to tune the system, eg:
Creating additional indexes to speed up queries
Altering storage structures
Bining or splitting tables
/ 88

88. Operational Maintenance
If the DBMS lacks certain utilities, the DBA can either develop the required utilities in-house or purchase additional vendor tools.
New systems should be operated in parallel with old system for a while, to safeguard current operations in case of unanticipated problems with the new system.
Periodic checks on data consistency between the two systems need to be made, and only when they produce the same results the old one is dropped.
In some cases both systems are maintained.
/ 88