Chapter 9


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 1 September 98 1 Chapter Name
  • 2 September 98 2 Chapter Name
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • Chapter 9

    1. 1. Chapter 9 Database Planning, Design, and Administration Transparencies
    2. 2. Chapter 9 - Objectives <ul><li>The main stages of the information systems lifecycle. </li></ul><ul><li>The relationship between the database application and information systems lifecycles. </li></ul><ul><li>The main stages of the database application lifecycle. </li></ul>2 2
    3. 3. Chapter 9 - Objectives <ul><li>The main phases of database design: conceptual, logical, and physical design. </li></ul><ul><li>The benefits of Computer-Aided Software Engineering (CASE) tools. </li></ul><ul><li>The types of criteria used to evaluate a DBMS. </li></ul>3
    4. 4. Chapter 9 - Objectives <ul><li>How to evaluate and select a DBMS. </li></ul><ul><li>The distinction between data administration and database administration. </li></ul><ul><li>The purpose and tasks associated with data administration and database administration. </li></ul>4
    5. 5. Software Crisis <ul><li>Last few decades have seen the proliferation of software applications. </li></ul><ul><li>Many applications required constant maintenance involving </li></ul><ul><ul><li>correcting faults </li></ul></ul><ul><ul><li>implementing new user requirements </li></ul></ul><ul><ul><li>modifying the software to run on new or upgraded platforms </li></ul></ul>5
    6. 6. Software Crisis <ul><li>As a result, many major software projects were </li></ul><ul><ul><li>late </li></ul></ul><ul><ul><li>over budget </li></ul></ul><ul><ul><li>unreliable </li></ul></ul><ul><ul><li>difficult to maintain </li></ul></ul><ul><ul><li>performed poorly </li></ul></ul><ul><li>Also called software depression. </li></ul>6
    7. 7. Software Crisis <ul><li>Study on software projects in 1996 in the UK </li></ul><ul><ul><ul><li>80 - 90% do not meet their performance goals. </li></ul></ul></ul><ul><ul><ul><li>About 80% of systems are delivered late and over budget. </li></ul></ul></ul><ul><ul><ul><li>Around 40% of developments fail or are abandoned. </li></ul></ul></ul><ul><ul><ul><li>Under 40% fully address training and skills requirements. </li></ul></ul></ul><ul><ul><ul><li>Less than 25% properly integrate business and technology objectives. </li></ul></ul></ul><ul><ul><ul><li>Just 10 - 20% meet all their success criteria. </li></ul></ul></ul>7
    8. 8. Software Development Lifecycle <ul><li>Major reasons for failure of software projects </li></ul><ul><ul><li>lack of complete requirements specification </li></ul></ul><ul><ul><li>lack of appropriate development methodology </li></ul></ul><ul><ul><li>poor decomposition of design into manageable components </li></ul></ul><ul><li>Solution - a structured approach to development of software called Information System Development Lifecycle. </li></ul>8
    9. 9. Information System (IS) <ul><li>Resources that enable the collection, management, control, and dissemination of information throughout an organization. </li></ul><ul><li>Components of IS include </li></ul><ul><ul><li>Database </li></ul></ul><ul><ul><li>Database software </li></ul></ul><ul><ul><li>Application software </li></ul></ul><ul><ul><li>Computer hardware including storage media </li></ul></ul><ul><ul><li>Personnel using and developing the system </li></ul></ul>9
    10. 10. Information System Development Lifecycle <ul><li>Database is a fundamental component of an IS. </li></ul><ul><li>IS lifecycle is linked to the lifecycle of the database system that supports it. </li></ul><ul><li>Stages include: planning, requirements collection and analysis, design (including database design), prototyping, implementation, testing, conversion, and operational maintenance. </li></ul>10
    11. 11. Database Application Lifecycle 11
    12. 12. Database Application Lifecycle <ul><li>Database planning </li></ul><ul><li>System definition </li></ul><ul><li>Requirements collection and analysis </li></ul><ul><li>Database design </li></ul><ul><li>DBMS selection (optional) </li></ul>12
    13. 13. Database Application Lifecycle <ul><li>Application design </li></ul><ul><li>Prototyping (optional) </li></ul><ul><li>Implementation </li></ul><ul><li>Data conversion and loading </li></ul><ul><li>Testing </li></ul><ul><li>Operational maintenance </li></ul>13
    14. 14. Database Planning <ul><li>The management activities that allow the stages of the database application to be realized as efficiently and effectively, as possible. </li></ul><ul><li>Identifies work to be done; the resources with which to do it; and the money to pay for it all. </li></ul><ul><li>Integrated with the overall IS strategy of the organization. </li></ul>14
    15. 15. Example - Corporate Data Model 15
    16. 16. System Definition <ul><li>The scope and boundaries of the database application including its major application areas and user groups. </li></ul>16
    17. 17. Requirements Collection and Analysis <ul><li>The process of collecting and analyzing information about the part of the organization that is to be supported by the database application, and using this information to identify the users’ requirements of the new system. </li></ul>17
    18. 18. Database Design <ul><li>The process of creating a design for a database that will support the enterprise’s operations and objectives. </li></ul>18
    19. 19. Database Design <ul><li>Major aims </li></ul><ul><ul><li>Represent data and relationships between data required by all major application areas and user groups. </li></ul></ul><ul><ul><li>Provide data model that supports any transactions required on the data. </li></ul></ul><ul><ul><li>Specify a minimal design that is appropriately structured to achieve the stated performance requirements for the system such as response times. </li></ul></ul>19
    20. 20. DBMS Selection <ul><li>The selection of an appropriate DBMS to support the database application. </li></ul><ul><li>Undertaken at any time prior to logical design provided sufficient information is available regarding system requirements. </li></ul>21
    21. 21. Application Design <ul><li>The design of the user interface and the application programs that use and process the database. </li></ul><ul><li>Database and application design are parallel activities. </li></ul>22
    22. 22. Prototyping <ul><li>Building a working model of a database application. </li></ul><ul><li>Purpose </li></ul><ul><ul><li>To identify features of a system that work well, or are inadequate </li></ul></ul><ul><ul><li>To suggest improvements or even new features </li></ul></ul><ul><ul><li>To clarify the users’ requirements </li></ul></ul><ul><ul><li>To evaluate the feasibility of a particular system design. </li></ul></ul>23
    23. 23. Prototype Development Method Stages 24
    24. 24. System Development Approach <ul><li>Understanding the system requirements before design is critical to the success of creating today’s complex system. </li></ul><ul><li>A system development approach based on modeling and prototyping has proven very effective in understanding the system requirements. </li></ul><ul><li>Modeling and rapid prototyping approach replaces the traditional waterfall approach. </li></ul>
    25. 25. Two Pronged approach to Building A System –Modeling and Prototyping <ul><li>Modeling: </li></ul><ul><li>Purposes: To present the essential characteristics of the </li></ul><ul><li>System. </li></ul><ul><li>Characteristics: Model is created based on observation of </li></ul><ul><li>the real world or approximation based on system goals. (a </li></ul><ul><li>simplified representation of a complex reality) </li></ul><ul><li>Approach: Models are used to segment a complex system </li></ul><ul><li>into successively simpler components that can be easily </li></ul><ul><li>understood. </li></ul>
    26. 26. Two Pronged approach to Building A System –Modeling and Prototyping <ul><li>Prototyping: </li></ul><ul><li>Purposes: To validate and refine the model of a system. </li></ul><ul><li>Characteristics: Prototyping is a discipline of interactive </li></ul><ul><li>experimentation to stimulate user feedback. </li></ul><ul><li>Approach: A prototype is a materialization of modeling </li></ul><ul><li>process by building rapidly and simulating the essential </li></ul><ul><li>aspects of the system. </li></ul>
    27. 27. Types of Prototyping <ul><li>Evaluative (mock-up) prototyping (Blue print approach) </li></ul><ul><li>Use: Visualization; demonstration; inspection </li></ul><ul><li>Advantages. Reduce risk; low cost; resolve uncertainty </li></ul><ul><li>Early; fast; flexible </li></ul><ul><li>How: Focuses on a relatively small number of questions to avoid becoming too complex. </li></ul><ul><li>Generally thought of a throw-away. </li></ul>
    28. 28. Types of Prototyping <ul><li>Straw man (exploratory) prototyping (scale model approach) </li></ul><ul><li>Use: Experiment; validating and refining the conceptual as well as logical data model. </li></ul><ul><li>Advantages. Used to improve design; discover things about a proposed system that would otherwise not be revealed. </li></ul><ul><li>How: Evaluate the impact on work flows; validate ease of use. </li></ul>
    29. 29. Types of Prototyping <ul><li>Evolution prototyping (real world model) </li></ul><ul><li>Use: Production use. </li></ul><ul><li>Advantages. Part of production exercise. </li></ul><ul><li>How: Explore functionality of subsystem and system; probe technical feasibility the performance and the integrity of the system. </li></ul>
    30. 30. Stages of Prototyping <ul><li>Planning </li></ul><ul><li>Initial analysis and design </li></ul><ul><li>Construction </li></ul><ul><li>Tryout </li></ul><ul><li>Evaluation </li></ul><ul><li>Disposal </li></ul>
    31. 31. Dimensions of Prototyping <ul><li>Relationships of any prototyping to its eventual system </li></ul><ul><li>are characterized along four dimensions: </li></ul><ul><li>Focus – for example, a prototype may focus on the functionality, user interface, system integration, reliability, and performance. </li></ul><ul><li>Scope– Is a measure of how much of the eventual system the prototype represents. </li></ul>
    32. 32. Dimensions of Prototyping <ul><li>Depth – is a measure of how deeply it represents the behavior of the eventual system. For ex., a shallow prototype of a message system might display ‘canned’ messages, where a deeper prototype might actually perform communications to provide a more realistic surrogate for the eventual system. </li></ul><ul><li>Scale– Is a measure of how its size or performance compares with that of the eventual system. </li></ul>
    33. 33. Implementation <ul><li>The physical realization of the database and application designs. </li></ul><ul><ul><li>Use DDL of DBMS to create database schemas and empty database files. </li></ul></ul><ul><ul><li>Use DDL to create any specified user views. </li></ul></ul><ul><ul><li>Use 3GL or 4GL to create application programs. Parts of these programs are the database transactions, created using DML of DBMS possibly embedded in a host programming language. </li></ul></ul>25
    34. 34. Data Conversion and Loading <ul><li>Transferring any existing data into the new database and converting any existing applications to run on the new database. </li></ul><ul><ul><li>Only required when a new database system is replacing an old system. </li></ul></ul><ul><ul><li>DBMS normally have a utility that loads existing files into the new database. </li></ul></ul><ul><ul><li>Where applicable, it may be possible to convert and use application programs from the old system for use by the new system. </li></ul></ul>26
    35. 35. Testing <ul><li>The process of executing the application programs with the intent of finding errors. </li></ul><ul><ul><li>Use carefully planned test strategies and realistic data. </li></ul></ul><ul><ul><li>Testing cannot show the absence of faults; it can show only that software faults are present. </li></ul></ul><ul><ul><li>Demonstrates that database and application programs appear to be working according to requirements. </li></ul></ul>27
    36. 36. Operational Maintenance <ul><li>The process of monitoring and maintaining the system following installation. </li></ul><ul><ul><li>Monitoring the performance of the system. </li></ul></ul><ul><ul><li>If performance falls, may require tuning or reorganization of the database. </li></ul></ul><ul><ul><li>Maintaining and upgrading the database application (when required). </li></ul></ul><ul><ul><li>Incorporating new requirements into the database application. </li></ul></ul>28
    37. 37. Overview of Database Design <ul><li>Main aims of data modeling </li></ul><ul><ul><li>To assist in the understanding of the meaning (semantics) of the data. </li></ul></ul><ul><ul><li>To facilitate communication about requirements. </li></ul></ul><ul><li>A data model facilitates understanding </li></ul><ul><ul><li>Each user’s perspective of the data. </li></ul></ul><ul><ul><li>Nature of data itself, independent of physical representations. </li></ul></ul><ul><ul><li>The use of data across applications. </li></ul></ul>29
    38. 38. Overview of Database Design - Criteria for Data Model 30
    39. 39. Conceptual Database Design <ul><li>The process of constructing a model of the information used in an enterprise, independent of all physical considerations. </li></ul><ul><ul><li>Data model is built using the information in users’ requirements specification. </li></ul></ul><ul><ul><li>Source of information for the logical design phase. </li></ul></ul>31
    40. 40. Logical Database Design <ul><li>The process of constructing a model of the information used in an enterprise based on a specific data model (e.g. relational), but independent of a particular DBMS and other physical considerations. </li></ul><ul><li>The conceptual data model is refined and mapped on to a logical data model. </li></ul>32
    41. 41. Database Design <ul><li>A logical model that represents multiple user views of an organization is called a global logical data model. </li></ul><ul><li>There are two major approaches to merging user views. </li></ul><ul><ul><li>Centralized </li></ul></ul><ul><ul><li>View integration </li></ul></ul>33
    42. 42. Database Design - Merging User Views <ul><li>Centralized approach </li></ul><ul><ul><li>Merge separate user requirements that represent distinct user views into a single set of user requirements, and then build the global logical data model. </li></ul></ul><ul><li>View integration approach </li></ul><ul><ul><li>Merge separate local logical data models that represent distinct user views into one global logical data model. </li></ul></ul>34
    43. 43. Physical Database Design <ul><li>The process of producing a description of the implementation of the database on secondary storage. </li></ul><ul><li>Describes the storage structures and access methods used to achieve efficient access to the data. </li></ul><ul><li>Tailored to a specific DBMS system. </li></ul>35
    44. 44. ANSI-SPARC Architecture and Database Design Phases 36
    45. 45. Application Design <ul><li>Includes two important activities </li></ul><ul><ul><li>Transaction design </li></ul></ul><ul><ul><li>User interface design </li></ul></ul>37
    46. 46. Application Design - Transaction Design <ul><li>Transaction </li></ul><ul><ul><li>An action or series of actions, carried out by a single user or application program, which accesses or changes the content of the database. </li></ul></ul><ul><li>Purpose to define and document the high-level characteristics of the transactions required on the database system. </li></ul>38
    47. 47. Application Design - Transaction Design <ul><li>Important characteristics of transactions include </li></ul><ul><ul><li>Data to be used by the transaction </li></ul></ul><ul><ul><li>Functional characteristics of the transaction </li></ul></ul><ul><ul><li>Output of the transaction </li></ul></ul><ul><ul><li>Importance to the users </li></ul></ul><ul><ul><li>Expected rate of usage </li></ul></ul><ul><li>Three main types of transactions: retrieval, update and mixed. </li></ul>39
    48. 48. Transaction Analysis <ul><li>“ A Transaction is a collection of database operations grouped into a unit of work that is either completely executed or completely abandoned” </li></ul><ul><li>  </li></ul><ul><li>TM (Transaction Monitors) are a class of transaction-processing applications that were originally designed to manage very large numbers of simultaneous transactions against mainframe database mgt systems. </li></ul><ul><li>  </li></ul><ul><li>MTS (Microsoft Transaction Server) brings the robustness and scalability to the client-server arena . </li></ul>
    49. 49. Transaction Analysis <ul><li>Transactions can be classified as either implicit or explicit. Implicit transactions are single SQL statements that execute as an atomic unit. Explicit transactions are groupings of SQL statements surrounded by transaction delimiters: Begin Transaction, Commit Transaction, Rollback Transaction. </li></ul>
    50. 50. Application Design - User Interface Design Guidelines <ul><li>Meaningful title </li></ul><ul><li>Comprehensible instructions </li></ul><ul><li>Logical grouping and sequencing of fields </li></ul><ul><li>Visually appealing layout of the form/report </li></ul><ul><li>Familiar field labels </li></ul><ul><li>Consistent terminology and abbreviations </li></ul><ul><li>Consistent use of color </li></ul>40
    51. 51. Application Design - User Interface Design Guidelines <ul><li>Visible space and boundaries for data-entry fields </li></ul><ul><li>Convenient cursor movement </li></ul><ul><li>Error correction for individual characters and entire fields </li></ul><ul><li>Error messages for unacceptable values </li></ul><ul><li>Optional fields marked clearly </li></ul><ul><li>Explanatory messages for fields </li></ul><ul><li>Completion signal </li></ul>41
    52. 52. Computer-Aided Software Engineering (CASE) Tools <ul><li>Purpose - To support the efficient and effective development of database applications. </li></ul><ul><li>CASE support may include </li></ul><ul><ul><li>A data dictionary to store information about the database application’s data. </li></ul></ul><ul><ul><li>Design tools to support data analysis. </li></ul></ul><ul><ul><li>Tools to develop the corporate, conceptual, and logical data models. </li></ul></ul><ul><ul><li>Tools to enable the prototyping of applications. </li></ul></ul>42
    53. 53. Computer-Aided Software Engineering (CASE) Tools <ul><li>Divided into three categories: upper-CASE, lower-CASE, and integrated-CASE. </li></ul><ul><li>Can provide the following benefits </li></ul><ul><ul><li>Standards </li></ul></ul><ul><ul><li>Integration </li></ul></ul><ul><ul><li>Support for standard methods </li></ul></ul><ul><ul><li>Consistency </li></ul></ul><ul><ul><li>Automation </li></ul></ul>43
    54. 54. Database Application Lifecycle - CASE Tools 44
    55. 55. DBMS Selection <ul><li>Define Terms of Reference of study </li></ul><ul><li>Shortlist two or three products </li></ul><ul><li>Evaluate products </li></ul><ul><li>Recommend selection and produce report </li></ul>45
    56. 56. DBMS Evaluation Features 46
    57. 57. DBMS Evaluation Features 47
    58. 58. DBMS Evaluation Features 48
    59. 59. DBMS Evaluation Features 49
    60. 60. Example - Evaluation of DBMS Product 50
    61. 61. Database Application Lifecycle - DA and DBA Major and Minor Roles 51
    62. 62. Data Administration <ul><li>The management of the data resource, which includes database planning, development and maintenance of standards, policies and procedures, and conceptual and logical database design. </li></ul>52
    63. 63. Data Administration Tasks 53
    64. 64. Database Administration <ul><li>The management of the physical realization of a database application, which includes physical database design and implementation, setting security and integrity controls, monitoring system performance, and reorganizing the database, as necessary. </li></ul>54
    65. 65. Database Administration Tasks 55
    66. 66. DA and DBA – Main Task Differences. 56