Chapter 2 The Database Development Process Modern Database
Chapter 2: The Database Development Process Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. Mc. Fadden © 2007 by Prentice Hall 1
Objectives n n n n n Definition of terms Describe system development life cycle Explain prototyping approach Explain roles of individuals Explain three-schema approach Explain role of packaged data models Explain three-tiered architectures Explain scope of database design projects Draw simple data models Chapter 2 © 2007 by Prentice Hall 2
Enterprise Data Model n n n n First step in database development Specifies scope and general content Overall picture of organizational data at high level of abstraction Entity-relationship diagram Descriptions of entity types Relationships between entities Business rules Chapter 2 © 2007 by Prentice Hall 3
Figure 2 -1 Segment from enterprise data model Enterprise data model describes the highlevel entities in an organization and the relationship between these entities Chapter 2 © 2007 by Prentice Hall 4
Information Systems Architecture (ISA) n n Conceptual blueprint for organization’s desired information systems structure Consists of: n n n Data (e. g. Enterprise Data Model–simplified ER Diagram) Processes – data flow diagrams DFD, process decomposition, etc. Data Network–topology diagram (like Fig 1 -9) People–people management using project management tools (Gantt charts, etc. ) Events and points in time (when processes are performed, e. g. state transition diagram) Reasons for events and rules (e. g. , decision tables) Chapter 2 © 2007 by Prentice Hall 5
Information Engineering n n n A data-oriented methodology to create and maintain information systems Top-down planning–a generic IS planning methodology for obtaining a broad understanding of the IS needed by the entire organization Four steps to Top-Down planning: n n Planning Analysis Design Implementation Chapter 2 © 2007 by Prentice Hall 6
Information Systems Planning (Table 2 -1) n n Purpose –align information technology with organization’s business strategies Three steps: 1. Identify strategic planning factors 2. Identify corporate planning objects 3. Develop enterprise model Chapter 2 © 2007 by Prentice Hall 7
Identify Strategic Planning Factors (Table 2 -2) n n n Organization goals –what we hope to accomplish ( 10% per year growth) Critical success factors –what MUST work in order for us to survive (high quality product, on-time delivery, raise productivity of employees) Problem areas –weaknesses we now have (inaccurate sales forecasts, competitions) Chapter 2 © 2007 by Prentice Hall 8
Identify Corporate Planning Objects (Table 2 -3) n n n Organizational units – departments Organizational locations Business functions – groups of business processes Entity types – the things we are trying to model for the database Information systems – application programs Chapter 2 © 2007 by Prentice Hall 9
Develop Enterprise Model n Functional decomposition n Iterative process breaking system description into finer and finer detail n Enterprise data model n Planning matrixes n Describe interrelationships between planning objects Chapter 2 © 2007 by Prentice Hall 10
Figure 2 -2 Example of process decomposition of an order fulfillment function (Pine Valley Furniture) Decomposition = breaking large tasks into smaller tasks in a hierarchical structure chart Chapter 2 © 2007 by Prentice Hall 11
Planning Matrixes n n Describe relationships between planning objects in the organization Types of matrixes: Function-to-data entity n Location-to-function n Unit-to-function n IS-to-data entity n Supporting function-to-data entity n IS-to-business objective n Chapter 2 © 2007 by Prentice Hall 12
Example business function-todata entity matrix (Fig. 2 -3) Chapter 2 © 2007 by Prentice Hall 13
Two Approaches to Database and IS Development n SDLC n n n System Development Life Cycle Detailed, well-planned development process Time-consuming, but comprehensive Long development cycle Prototyping n n Rapid application development (RAD) Cursory attempt at conceptual data modeling Define database during development of initial prototype Repeat implementation and maintenance activities with new prototype versions Chapter 2 © 2007 by Prentice Hall 14
Systems Development Life Cycle (see also Figures 2. 4, 2. 5) Planning Analysis Logical Design Physical Design Implementation Maintenance Chapter 2 © 2007 by Prentice Hall 15
Systems Development Life Cycle (see also Figures 2. 4, 2. 5) (cont. ) Purpose – primary understanding Outcome– request for study Planning Analysis Logical Design Physical Design Database activity– enterprise modeling and early conceptual data modeling Chapter 2 Implementation Maintenance © 2007 by Prentice Hall 16
Systems Development Life Cycle (see also Figures 2. 4, 2. 5) (cont. ) Purpose–thorough requirements analysis and structuring Outcome– functional system specifications Planning Analysis Logical Design Physical Design Database activity– Thorough and integrated conceptual data modeling Chapter 2 Implementation Maintenance © 2007 by Prentice Hall 17
Systems Development Life Cycle (see also Figures 2. 4, 2. 5) (cont. ) Purpose–information requirements elicitation and structure Outcome – detailed design specifications Planning Analysis Logical Design Physical Design Database activity– logical database design (transactions, forms, displays, views, data integrity and security) Chapter 2 Implementation Maintenance © 2007 by Prentice Hall 18
Systems Development Life Cycle (see also Figures 2. 4, 2. 5) (cont. ) Purpose–develop technology and organizational specifications Outcome – program/data structures, technology purchases, organization redesigns Planning Analysis Logical Design Physical Design Database activity– physical database design (define database to DBMS, physical data organization, database processing programs) Chapter 2 © 2007 by Prentice Hall Implementation Maintenance 19
Systems Development Life Cycle (see also Figures 2. 4, 2. 5) (cont. ) Planning Analysis Purpose–programming, testing, training, installation, documenting Outcome – operational programs, documentation, training materials Logical Design Physical Design Database activity– database implementation, including coded programs, documentation, installation and conversion Chapter 2 Implementation Maintenance © 2007 by Prentice Hall 20
Systems Development Life Cycle (see also Figures 2. 4, 2. 5) (cont. ) Purpose–monitor, repair, enhance Outcome – periodic audits Planning Analysis Logical Design Physical Design Database activity– database maintenance, performance analysis and tuning, error corrections Chapter 2 Implementation Maintenance © 2007 by Prentice Hall 21
Prototyping Database Methodology (Figure 2. 6) Chapter 2 © 2007 by Prentice Hall 22
Prototyping Database Methodology (Figure 2. 6) (cont. ) Chapter 2 © 2007 by Prentice Hall 23
Prototyping Database Methodology (Figure 2. 6) (cont. ) Chapter 2 © 2007 by Prentice Hall 24
Prototyping Database Methodology (Figure 2. 6) (cont. ) Chapter 2 © 2007 by Prentice Hall 25
Prototyping Database Methodology (Figure 2. 6) (cont. ) Chapter 2 © 2007 by Prentice Hall 26
CASE n n Computer-Aided Software Engineering (CASE) –software tools providing automated support for systems development Three database features: Data modeling–drawing entity-relationship diagrams n Code generation–SQL code for table creation n Repositories – knowledge base of enterprise information n Chapter 2 © 2007 by Prentice Hall 27
Packaged Data Models n n Model components that can be purchased, customized, and assembled into full-scale data models Advantages n n n Reduced development time Higher model quality and reliability Two types: n n Universal data models Industry-specific data models Chapter 2 © 2007 by Prentice Hall 28
Managing Projects n n Project –a planned undertaking of related activities to reach an objective that has a beginning and an end Involves use of review points for: Validation of satisfactory progress n Step back from detail to overall view n Renew commitment ﺗﻌﻬﺪ of stakeholders n n Incremental commitment–review of systems development project after each development phase with rejustification after each phase Chapter 2 © 2007 by Prentice Hall 29
Managing Projects: People Involved n n n n n Chapter 2 Business analysts Systems analysts Database analysts and data modelers Users Programmers Database architects Data administrators Project managers Other technical experts © 2007 by Prentice Hall 30
Database Schema n Physical Schema n n Conceptual Schema n n Physical structures–covered in Chapters 5 and 6 E-R models–covered in Chapters 3 and 4 External Schema n n User Views Subsets of Conceptual Schema Can be determined from business-function/data entity matrices DBA determines schema for different users Chapter 2 © 2007 by Prentice Hall 31
Figure 2 -7 Three-schema architecture Different people have different views of the database…these are the external schema The internal schema is the underlying design and implementation Chapter 2 © 2007 by Prentice Hall 32
Figure 2 -8 Developing the three-tiered architecture Chapter 2 © 2007 by Prentice Hall 33
Figure 2 -9 Three-tiered client/server database architecture Chapter 2 © 2007 by Prentice Hall 34
Degrees of Data Abstraction n n Database designer starts with abstracted view, then adds details ANSI Standards Planning and Requirements Committee (SPARC) n Defined a framework for data modeling based on degrees of data abstraction (1970 s): External n Conceptual n Internal n Chapter 2 © 2007 by Prentice Hall Database Systems, 9 th Edition
Chapter 2 © 2007 by Prentice Hall Database Systems, 9 th Edition
The External Model n n n End users’ view of the data environment ER diagrams represent external views External schema: specific representation of an external view n n Entities Relationships Processes Constraints Chapter 2 © 2007 by Prentice Hall Database Systems, 9 th Edition
The External Model (cont’d. ) n n Easy to identify specific data required to support each business unit’s operations Facilitates designer’s job by providing feedback about the model’s adequacy Ensures security constraints in database design Simplifies application program development Chapter 2 © 2007 by Prentice Hall Database Systems, 9 th Edition
Chapter 2 © 2007 by Prentice Hall Database Systems, 9 th Edition
The Conceptual Model n n Represents global view of the entire database All external views integrated into single global view: conceptual schema ER model most widely used ERD graphically represents the conceptual schema Chapter 2 © 2007 by Prentice Hall Database Systems, 9 th Edition
Chapter 2 © 2007 Database by Prentice Systems, Hall 9 th Edition
The Conceptual Model (cont’d. ) n n Provides a relatively easily understood macro level view of data environment Independent of both software and hardware n n n Does not depend on the DBMS software used to implement the model Does not depend on the hardware used in the implementation of the model Changes in hardware or software do not affect database design at the conceptual level Chapter 2 © 2007 by Prentice Hall Database Systems, 9 th Edition
The Internal Model n Representation of the database as “seen” by the DBMS n n n Internal schema depicts a specific representation of an internal model Depends on specific database software n n Maps the conceptual model to the DBMS Change in DBMS software requires internal model be changed Logical independence: change internal model without affecting conceptual model Chapter 2 © 2007 by Prentice Hall Database Systems, 9 th Edition
Chapter 2 © 2007 Database by Prentice Systems, Hall 9 th Edition
The Physical Model n Operates at lowest level of abstraction n Requires the definition of physical storage and data access methods Relational model aimed at logical level n n Describes the way data are saved on storage media such as disks or tapes Does not require physical-level details Physical independence: changes in physical model do not affect internal model Chapter 2 © 2007 by Prentice Hall Database Systems, 9 th Edition
Chapter 2 © 2007 Database by Prentice Systems, Hall 9 th Edition
Pine Valley Furniture Segment of project data model (Figure 2 -11) Chapter 2 © 2007 by Prentice Hall 47
Figure 2 -12 Four relations (Pine Valley Furniture) Chapter 2 © 2007 by Prentice Hall 48
Figure 2 -12 Four relations (Pine Valley Furniture) (cont. ) Chapter 2 © 2007 by Prentice Hall 49
- Slides: 49