Data Analysis – Structured
“Previously, 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.
Data Analysis: Object Oriented
In UML, class diagrams are typically used to show types of objects that a system must keep track of, and the relationships between objects. In this unit, we will study the use of class diagrams for modeling persistent objects (i.e., thinks the system must remember outside the scope of run-time). Unlike the structured models, these diagrams also allow the visualization of properties and operations (which are typical in the parlance of software developers).
Activities
- Read: Chapter 8 in the Modern Systems Analysis and Design text
- Read: Appendix 8 in Modern Systems Analysis and Design
Objectives
- 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.
- demonstrate the differences between object diagrams and class diagrams,
- explain the three types of operations possible in class diagrams,
- illustrate how associations are represented in class diagrams,
- show how associative classes are drawn in class diagrams, and
- show how generalization and aggregation are represented in class diagrams
Topics
- Conceptual Data Modeling
- Gathering information for Conceptual Data Modeling
- E-R Modeling
- Super-types and Sub-types
- Business Rules
- Database Patterns
- Objects & Classes
- Operations
- Associations
- Associative Classes
- Stereotypes for Attributes
- Generalization
- Aggregation