Data-Oriented Design

This text uses the Martin [1990] version of Information Engineering to illustrate data-oriented design. The result of data-oriented analysis – entity-relationship diagrams, data flow diagrams, CRUD matrices, and so on – is translated into screen designs, production database designs, action diagrams, procedural structures, and security plans. Compared to other approaches, data-oriented design has a strong emphasis on security, recovery, and audit controls, relating each to data and processes in the application.

In this chapter, you will learn about the concepts and terminologies for data-oriented design, analyzing data and defining system controls, and the action diagram. The action diagram shows the processing details for an application in a structured format, which can be translated into programs and modules. You will also learn about menu structure, dialogue flow, and hardware and software installation and testing.

2. Conceptual Foundations

Information Engineering is the closest to a complete methodology of the methods in common use. It borrows from research and practice to build a complete view of the application and its environment. Structured programming tenets describe the importance of limiting program structure, as much as possible, to selection, iteration, and instruction sequence components. 'Go to' statements should be minimized. Modules should have one entry and one exit. In IE design, these tenets are practiced in structuring the application as well as the' program modules. 

Subject area database design is based on theories of relational database and practice of data design. Data should be clustered with processes which create the data. Those processes determine 'subject areas' of data. Subject databases are stored in the same database environment and their processes are in integrated applications. These topics were discussed in Chapter 5 and are not repeated here. During analysis, the data entities are normalized and relations are identified (Chapter 9). Normalized data is the starting point for physical database design. Physical database design may automate the normalized relations directly or may denormalize for performance purposes. Also, in organizations with many using locations and potential for distribution of data and processes, a strategy for distribution is defined. These two activities, potential denormalization and distribution, are based on practical guidelines rather than theory.

From practice, we know that there is more to implementing an application than designing program specifications and a database. We need to design screens, a screen dialogue, provide for unauthorized and unwanted damage to the data, provide for conversion from the old to the new method of data storage, design and plan application implementation, install hardware, design and plan application tests, and develop training programs for users. While all of these tasks are discussed in some books on IE, these activities are done regardless of methodology, and to discuss them as pertaining only to IE would be misleading. For this reason, the topics in this chapter include screen dialogue design, hardware planning, and providing for data security, recovery, and audit controls, in addition to procedure and database design. Human interface design, conversion, and training are discussed in Chapter 14; testing is the subject of Chapter 17.