Class Video – Audio Only. Unfortunately the video was not recorded.
Electronic Data Interchange (EDI)
The material covered can be found in the CISA Review Manual, Section 3.7.2 Electronic Data Interchange, pages 188 through 191.
Structured Data Analysis
“In Unit 6, you learned how to model and analyze two important views of an information system: (1) the flow of data between manual or automated steps and (2) the decision logic of processing data. None of the techniques discussed so far, however, has concentrated on the data that must be retained in order to support the data flows and processing described. For example, you learned how to show data stores, or data at rest, in a data flow diagram (DFD). The natural structure of data, however, was not shown. DFDs, use cases, and various processing logic techniques show how, where, and when data are used or changed in an information system, but these techniques do not show the definition, structure, and relationships within the data. Data modeling develops these missing, and crucial, descriptive pieces of a system.
In fact, some systems developers believe that a data model is the most important part of the statement of information system requirements. This belief is based on the following reasons. First, the characteristics of data captured during data modeling are crucial in the design of databases, programs, computer screens, and printed reports. For example, facts such as these—a data element is numeric, a product can be in only one product line at a time, a line item on a customer order can never be moved to another customer order, customer region name is limited to a specified set of values—are all essential pieces of information in ensuring data integrity in an information system.
Second, data, not processes, are the most complex aspects of many modern information systems and hence require a central role in structuring system requirements. Transaction processing systems can have considerable process complexity in validating data, reconciling errors, and coordinating the movement of data to various databases. Current systems development focuses more on management information systems (such as sales tracking), decision support systems (such as short-term cash investment), and business intelligence systems (such as market basket analysis). Such systems are more data intensive. The exact nature of processing is also more ad hoc than with transaction processing systems, so the details of processing steps cannot be anticipated. Thus, the goal is to provide a rich data resource that might support any type of information inquiry, analysis, and summarization.
Third, the characteristics about data (e.g., length, format, and relationships with other data) are reasonably permanent and have significant similarity for different organizations in the same business. In contrast, the paths and design of data flow are quite dynamic. A data model explains the inherent nature of the organization, not its transient form. Therefore, an information system design based on a data orientation, rather than a process or logic orientation, should have a longer useful life and should have common features for the same applications or domains in different organizations. Finally, structural information about data is essential for automatic program generation. For example, the fact that a customer order has many line items on it instead of just one line item affects the automatic design of a computer screen for entry of customer orders. Although a data model specifically documents the file and database requirements for an information system, the business meaning, or semantics, of data included in the data model has a broader effect on the design and construction of a system.
The most common format used for data modeling is entity-relationship (E-R) diagramming. A similar format used with object-oriented analysis and design methods is class diagramming, which is included in a special section at the end of this chapter on the object-oriented development approach to data modeling. Data models that use E-R and class diagram notations explain the characteristics and structure of data independent of how the data may be stored in computer memory. A data model is usually developed iteratively, either from scratch or from a purchased data model for the industry or business area to be supported. Information system (IS) planners use this preliminary data model to develop an enterprise-wide data model with very broad categories of data and little detail. Next, during the definition of a project, a specific data model is built to help explain the scope of a particular systems analysis and design effort. During requirements structuring, a data model represents conceptual data requirements for a particular system. Then, after system inputs and outputs are fully described during logical design, the data model is refined before it is translated into a logical format (typically a relational data model) from which database definition and physical database design are done. A data model represents certain types of business rules that govern the properties of data. Business rules are important statements of business policies that ideally will be enforced through the database and database management system ultimately used for the application you are designing. Thus, you will use E-R and class diagramming in many systems development project steps, and most IS project members need to know how to develop and read data model diagrams. Therefore, mastery of the requirements structuring methods and techniques addressed in this chapter is critical to your success on a systems development project team.”
Valacich, J. S., & George, J. F. (2017). Modern systems analysis and design (8th ed.). Boston: Pearson.
- Modern Systems Analysis and Design
- Chapter 8 – Structuring System Data Requirements
- Modern Systems Analysis and Design
- Participate in this week’s class and online discussions
- Complete written assignment 8.1 (WA-8.1)
- Complete practical assignment 8.1 (PA-8.1)
- explain the role of conceptual data modeling in the overall analysis and design of an information system;
- describe the information gathering process for conceptual data modeling;
- describe how to represent an entity-relationship model and be able to define the terms: entity type, attribute, identifier, multivalued attribute, and relationship;
- distinguish among unary, binary, and ternary relationships as well as associative entities, providing an example of each;
- define supertypes and subtypes, showing how to represent these entity types with entity-relationship diagramming notation;
- define four basic types of business rules in a conceptual data model; and
- explain the role of prepackaged database models (patterns) in data modeling.
- Conceptual Data Modeling
- Gathering information for Conceptual Data Modeling
- E-R Modeling
- Super-types and Sub-types
- Business Rules
- Database Patterns