Chapter 2 Database Development Process
Chapter Objectives
The purpose of this chapter is to introduce students to the database development process, within the broader context of information systems development. It is a synthesis of the material presented in Chapters 2 and 3 of fourth edition. The chapter presents an expanded description of the systems development life cycle, and the role of database development within that cycle. It also presents a new description of the prototyping methodology and its impact on database development. The chapter continues to emphasize the information engineering methodology in database development, including the role of the enterprise data model.
Specific student learning objectives are included at the beginning of the chapter. From an instructor's point of view, the objectives of this chapter are to:
1. Illustrate some of the database design and processing skills your students will have after completing a database course using this text.
2. Provide an idea of how to structure a database development project sufficient to begin on a course exercise.
3. Provide a comprehensive overview of various concepts and issues in database management that will be developed in more detail in later chapters.
4. Discuss the goal of enterprise-wide computing, and the need for strategic information systems planning in achieving this goal.
5. Introduce the Zachman Information Systems Architecture and its role in information systems development.
6. Provide a review of systems development methodologies, particularly the systems development lifecycle and prototyping, and build an understanding of how database development fits with these methodologies.
7. Build an awareness of CASE tools and how they can be used to facilitate the database development process.
8. Make students aware of the three-schema architecture and its benefits for database development and design.
9. Develop an understanding of the different roles involved in a database development team.
Classroom Ideas
1. You can discuss in class the types of systems analysis that might have been done to design the application illustrate in this chapter. This is a good opportunity to discuss the linkage between your database course and the systems analysis & design courses(s) your students take. You can also mention that a tool like Microsoft Access® is excellent for system prototyping since the database, screens, views, and reports shown in this chapter can be developed easily and quickly. If you are interested in teaching materials on SA&D that are consistent with this database text, the second edition of Modern Systems Analysis and Design, authored by Hoffer, George, and Valacich, is available from Addison Wesley Longman.
2. Discuss the importance of enterprise-wide computing in today's competitive environment, and the difficulties of sharing information given the proliferation of personal computers and databases.
3. Introduce the Zachman Information Systems Architecture Framework. We find in discussing this model it is especially helpful to discuss the different roles associated with each component.
4. Discuss the major phases in the information engineering methodology (Tables 2-1 and 2-2). Illustrate sample deliverables from each of the phases using the Pine Valley Furniture Company case.
5. If feasible, provide an in-class demonstration of a CASE tool that supports the information engineering methodology.
6. Review the steps in the database development process (Figure 2-5). Indicate in which row the output for each step relates to the Information Systems Architecture framework as described in the text.
7. Discuss the importance of strategic information systems planning with your students. Have your students give examples of poor results when planning is ignored. Also discuss factors that often interfere with effective planning.
8. Discuss the role of CASE tools and a repository in information systems development. If appropriate, find out what CASE tools your students use in their work environment and their experience with these tools.
9. A quick in-class demo of Microsoft Access or similar product may be used to give the students an initial exposure to an RDBMS and demonstrate a prototyping approach to database development.
10. Your students may have examples from their workplaces to contribute about client/server architectures. Or, you may provide them with an understanding of where the RDBMS software and their data will be stored at your school as an illustration.
Answers to Review Questions
- Define each of the following key terms:
a. Information systems architecture (ISA). A conceptual blueprint or plan that expresses the desired future structure for the information systems in an organization.
b. Systems development life cycle (SDLC). A traditional methodology used to develop, maintain, and replace information systems.
c. Client/server architecture. A local area network-based environment in which database software on a server (called a database server or database engine) performs database commands sent to it from client workstations, and application programs on each client concentrate on user interface functions.
d. Incremental commitment, A strategy in systems development projects in which the project is reviewed after each phase and continuation of the project is rejustified in each of these reviews.
e. Enterprise data modeling. The first step in database development, in which the scope and general contents of organizational databases are specified.
f. Conceptual data modeling. An analysis of the overall data requirements of a proposed information system which results in a conceptual data model or conceptual schema. It is done in a top-down fashion, driven from a general understanding of the business area, not from specific information processing activities and is independent of any particular RDBMS product.
- Contrast the following terms:
a. Physical schema; conceptual schema. A physical schema contains the specifications for how data from a conceptual schema are stored in computer secondary memory. It is possible that when you design the physical database you will encounter inconsistencies or other issues with the conceptual schema or user views, so it is possible to cycle back through these design steps.
b. Systems development life cycle; prototyping. Both are systems development processes. The SDLC is a methodical, highly structured approach, which includes many checks and balances. Consequently, the SDLC is often criticized for the length of time needed until a working system is produced, which occurs only at the end of the process. Increasingly, organizations use more rapid application development (RAD) methods, which follow an iterative process of rapidly repeating analysis, design, and implementation steps until you converge on the system the user wants. Prototyping is one of them. In prototyping, a database and its applications are iteratively refined through a close interaction of systems developers and users.
c. Top-down planning; functional decomposition. Top-down planning approaches have the advantages of a broad perspective, an ability to look at integration of individual system components, an understanding of the relationship of information systems to business objectives, and an understanding of the impact of information systems across the whole organization. Functional decomposition is a classical process employed in systems analysis in order to simplify problems, isolate attention, and identify components.
d. Enterprise data modeling; information engineering. In many organizations, database development begins with enterprise data modeling, where the range and general contents of organizational databases are set. An information systems architecture is developed by information systems planners following a particular methodology for IS planning. One such formal and popular methodology is information engineering.
e. Repository; computer-aided software engineering. CASE tools automate some portions of the development process and thereby improve system development time and the quality of the delivered products. A repository helps systems and database analysts achieve a seamless integration of data from several CASE tools.
3. Information engineering steps:
a. Planning phase: Development of strategic information systems plans that are linked to strategic business plans. This stage results in developing an enterprise model that includes a decomposition of business functions and high-level entity-relationship diagram.
b. Analysis phase: Current business situations and information systems are studied to develop detailed specifications for the information systems required to support the organization.
c. Design phase: Transformation of the information models developed during Analysis to models that conform to the target technology.
d. Implementation phase: Construction and installation of the information systems by creating database definitions and applications in the languages of the target systems.
4. Information engineering planning phase steps:
a. Identify strategic planning factors. The purpose of this step is to develop the planning context and to link information systems plans to the strategic business plans.
b. Identify corporate planning objects. The corporate planning objects define the business scope. The scope limits subsequent systems analysis and where information system changes can occur.
c. Develop enterprise model. A comprehensive enterprise model consists of a functional breakdown (or decomposition) model of each business function, an enterprise data model, and various planning matrices.
5. Three information engineering strategic planning factors:
The strategic planning factors are organization goals, critical success factors, and problem areas. These factors help information system managers to set priorities to address requests for new information systems, and hence the development of databases. For example, the problem area of inaccurate sales forecasts might cause information system managers to include additional historical sales data, new market research data, or data concerning results from test trials of new products in organizational databases.
6. Five key corporate planning objects:
a. Organizational units, which are the various organizational departments.
b. Organizational locations, which are the places at which business operations occur.
c. Business functions, which are related groups of business processes that support the mission of the organization. Note that business functions are different from organizational units; in fact, a function may be assigned to more than one organizational unit (for example, product development, a function, may be the joint responsibility of the Sales and Manufacturing departments).
d. Entity types, which are major categories of data about the people, places, and things managed by the organization.
e. Information systems, which are the application software and supporting procedures for handling sets of data.
7. Functional decomposition:
Functional decomposition is a classical process employed in systems analysis in order to simplify problems, isolate attention, and identify components. Often many databases are necessary to handle the full set of business functions and supporting functions, whereas a particular database may support only a subset of the supporting functions. It is, however, helpful to have a total, high-level enterprise view so that redundancy of data can be minimized and purposeful.
8. Using information system planning matrices:
Planning matrices are used to show interrelationships between planning objects. Relationships between data entities and the other organizational planning objects can be represented at a high level by the planning matrices, which can be manipulated to understand patterns of relationships.
9. Seven SDLC phases:
a. Project Identification and Selection. Purpose: Develop a preliminary understanding of the business situation that has caused the request for a new or an enhanced information system. Deliverable: A formal request to conduct a project to design and develop an information systems solution to the business problems or opportunities.
b. Project Initiation and Planning. Purpose: State business situation and how information systems might help solve a problem or make an opportunity possible Deliverable: A written request to study the possible changes to an existing system or the development of a new system.
c. Analysis. Purpose: Analyze the business situation thoroughly to determine requirements, to structure those requirements, and to select among competing system features. Deliverables: The functional specifications for a system that meets user requirements and is feasible to develop and implement.
d. Logical Design. Purpose: Elicit and structure all information requirements. Deliverables: Detailed functional specifications of all data, forms, reports, displays, and processing rules.
e. Physical Design. Purpose: Develop technology and organizational specifications. Deliverables: Program and database structures, technology purchases, physical site plans, and organizational redesigns.
f. Implementation. Purpose: Write programs, build data files, test and install the new system, train users, finalize documentation. Deliverables: Programs that work accurately and to specifications, documentation, and training materials.
g. Maintenance. Purpose: To monitor the operation and usefulness of a system, and to repair and enhance the system. Deliverables: Periodic audits of the system to demonstrate whether the system is accurate and still meets needs.
10. Database development activities occur in every phase of the SDLC.
11. Prototyping steps:
Identify Problem.
a. Conceptual data modeling:
b. Analyze requirements;
c. Develop preliminary data model.
Develop Initial Prototype.
a. Logical database design:
b. Analyze requirements in detail;
c. Integrate database views into conceptual data model.
Physical database design and creation:
a. Define new database contents to DBMS;
b. Decide on physical organization for new data;
c. Design database processing programs.
Implement & Use Prototype.
a. Database implementation:
b. Code database processing;
c. Install new database contents, usually from existing data sources.
Revise & Enhance Prototype.
a. Database maintenance:
b. Analyze database to ensure it meets application needs;
c. Fix errors in database.
Convert to Operational System.
a. Database maintenance:
b. Tune database for improved performance;
c. Fix errors in database
12. Differences between user views, a conceptual schema, and a physical schema:
A conceptual schema defines the whole database without reference to how data are stored in computer secondary memory. A user view (or external schema) is also independent of database technology, but typically contains a subset of the associated conceptual schema, relevant to a particular user or group of users (for example, an inventory manager or accounts receivable department). A physical schema contains the specifications for how data from a conceptual schema are stored in computer secondary memory.
13. External and conceptual schema design:
External schemas are not necessarily developed before the conceptual schema. In fact, they are typically developed iteratively. Often, a first cut at the conceptual schema is based on the organization’s enterprise data model and the general understanding of database requirements on a project. Then external schemas (user views) are developed for each transaction, report, screen display, and other system use.