Conceptual Modeling Overview
As mentioned in the introduction, the Systems Analysis phase of Requirements Structuring produces three views: (1) Process; (2) Logic & Timing; and (3) Data. While the Process View deals with the flow of information, and while the Logic & Timing View deals with data transformation, only the Data View focuses on the “definition, structure, and relationships within the data .” Some analysts believe that data models are the most critical component of information system requirements, for the following reasons:
- Data models are critical to the design of databases, programs, and printed reports.
- Data are more complex that processes in many information systems.
- Data characteristics are usually permanent.
- Data structure is critical for automatic program generation.
A data model represents the business rules that govern the properties of an organization’s data. This is important because a business rule represents business policies that should be enforced via the database. During the Requirements Structuring phase a data model captures the conceptual data requirements for a given system. In later phases, such as the Logical Design phase, the data model is further refined. However, in order to implement successful refinements to subsequent models, a committment must be made to designing an effective conceptual data model.
The Conceptual Data Model represents a view of the overall structure of an organization’s data. This view is independent of any other implementation considerations (i.e. database management systems, application software, etc.). The objective of a conceptual data model is to illustrate the business rules governing the meaning and interrelationships among data.
The Conceptual Data Modeling Process
Analysts usually perform conceptual data modeling in parallel with other analysis and structuring steps. The process begins with creating a conceptual model of the current system being replaced (assuming a system exists). This is necessary for planning the conversion of current data into the new database system. This original model can also serve as a proxy for understanding the data requirements for the new system. After the initial conceptual model is completed, analysts create additional models which include the data requirements for the new system (which should have been uncovered during requirements determination).
It should be noted that conceptual data modeling is an iterative process. As stated above, conceptual modeling should be performed in conjunction with other analysis steps, such as requirements determination. The information about an organization that is produced during the determination phase is critical to establishing a sound conceptual data model. Analysts must not only ask questions about data, but also questions related to process and logic (even if the analysts are only responsible for the conceptual data model). Understanding the process, logic, and data needs of an organization is essential to understanding the organization’s business rules – which is what the conceptual data model is designed to illustrate. There are two primary methods of data modeling: (1) Top-Down and (2) Bottom-Up. A sound understanding of an organization’s field of business will assist the analyst using either of these two methods, but it is especially helpful for Top-Down data modeling.
Top-Down Modeling: The rules for the conceptual data model are derived by an in-depth understanding of an organization’s business. Below are several questions analysts may ask business managers and systems users in order to elicit relevant business requirements:
- What are the objects of the business? – question related to data entities and descriptions
- What unique characteristic(s) distinguishes each object from other objects of the same type? – question related to the primary key
- How do you use these data? – question related to security controls
- Over what period of time are you interested in these data? – question related to cardinality and time dimensions of data
- What events occur that imply associations among various objects? – question related to relationships; cardinality; and degree
Bottom-Up Modeling: Here, the rules for the conceptual data model are derived by an in-depth review of business documents, such as forms, reports, and computer displays. Reviewing these documents provides insight into what data is currently being maintained in an information system. The observant analyst with a strong understanding of an organization’s business may also be able to identify data that needs to be maintained, but is currently not being captured by an organization’s existing information systems.
While information gathered during requirements determination deals with data, process, and logic, the primary concern for conceptual data modelers is the organization’s underlying data. This is not to say that process and logic are unimportant – University of Missouri - St. Louis professor, Dr. Vicki Sauter believes that data flow diagrams (related to process) and decision trees (related to logic) can be extremely useful when questioning business participants about business requirements.
According to Dr. Sauter, most non-information systems professionals find it easier to grasp DFDs and decision trees because many people find it easier to think in terms of processes (i.e. sequence of steps) . However, the conceptual data modeler must understand that their primary aim is to create model that represents the structure of an organization’s data, independent of any other considerations. And the primary way of illustrating that data is the Entity-Relationship diagram, which is the focus of the next section.