The Concept As a Model

In the Billington case study, you can see many facets that begin to form a system. You have an existing physical structure and interactions between elements. Some of the components in the old system will stay in the new system, and others will undergo significant change. Many of the interviewees have expressed opinions on what they perceive the new system to be. You have a collection of ideas from a number of different sources. In this, the conceptual design process, you are going to draw a picture of their interactions and begin forming a basis for moving forward with the system design.

Many forms of conceptual modeling are used in the computer industry. Data specialists usually prefer the ER modeling approach, which defines the tables, fields, and relationships found in a data store. Often you need a looser modeling tool, however, for better expressing the conceptual design elements without the rigors of the rules for data structures.

ORM attempts to make modeling the process as simple as possible. It uses standard language as a way of expressing data and relationships and is also a diagramming process that can be used to illustrate actual data. You begin the process by taking information from the problem statement in the form of simple facts and then attempt to show these factual elements as objects within a conceptual model.

Beginning with the FactsIt's Elementary, My D(ea)r Watson

To start the conceptual model, you need to formulate simple or elementary facts in the systemthe facts, and nothing but the facts, you might say. At first, you are trying to do nothing more than isolate a series of English words and phrases that represent the "known" in the system. These facts are represented for both current elements and future content of the system that doesn't exist in the concrete yet.

Although input documents are the most common source of fact information in the industry, the majority of the facts on the exam are drawn from the case study or given in the text of a drag-and-drop question.

Often facts for the conceptual model are derived from inputs, outputs, and reports used in the current system. If you lack this documentation, it is equally possible that you might have to derive facts from interviews and, in your case, directly from the problem statement or case study. Figure 6.1 contains a listing of the facts that can be derived from the case study.

Figure 6.1. ORM facts for the Billington case study.

Although this fact list is intended to be a complete listing of all system facts, some assumptions have been made to formulate it. If you were to peruse the case study, you would likely come up with a slightly different version of this list. To see how facts can be extracted from business documents, you can base a simple exercise on a portion of the system. To cover the entire conceptual model at this point would be somewhat overwhelming, so for the purpose of illustrating the ORM process, information that can be drawn from a prescription has been isolated.

On a prescription, you find identification for the Patient and the Doctor. You also find the date of the prescription, the drugs being prescribed, a dosage for each drug, and a route (method of taking the drug) for each drug. That information provides a fact list similar to the one in Figure 6.2.

Figure 6.2. ORM facts for a prescription.

After drawing the basic set of facts, you are ready to proceed with a quality check of the fact listing. As a quality check, you ensure that objects are well defined and, consulting your knowledge of the case study, make decisions about splitting and combining facts. At the completion of this stage, you prepare associated phrasing so that your fact list now looks like the following:

• A Prescription is given to the Patient

• A Prescription is given by the Doctor

• A Prescription has a Date

• A Prescription has Drug(s)

• A Drug has a Route

• A Drug has a Dosage

This list begins to form the relationship between the entity and data elements being used in the system. In developing an ORM model, there is also a reverse relationship, which would look similar to the following:

• A Patient is on the Prescription

• A Doctor is on the Prescription

• A Date is on the Prescription

• One or more Drugs are on the Prescription

• A Route is of Drug

• A Dosage is of Drug

Now you have a listing of elementary phrases that represents the data's relationships and reverse relationships. The ORM modeling process now moves into the second step, where you begin to draw out the system.

Population Checks for Facts

In the second step of the conceptual design process and ORM modeling process, you take the elementary facts prepared in the first step and begin drawing them out in an ORM style. After preparing the initial draft of the diagram, you then add samples of true data to the diagram.

Entities and data elements are represented in an ORM model as ellipses connected by subtype relational lines and predicate rectangles. The initial draft of your prescription ORM model would look similar to the example in Figure 6.3.

Figure 6.3. The ORM model for a prescription.

After you start drawing the diagram, it is easier to see relationships between the data. This is further enforced with the addition of sample data values. Supplying some data samples helps illustrate the relationships and can also indicate structural elements that might need to be modified to derive a better overall system. Although the data is not completely normalized, finishing the second step results in the diagram shown in Figure 6.4.

Figure 6.4. The ORM model with sample data.

This is by no means the finished model; it's not even a completed prescription model. Some elements of this design, when brought into the whole system, begin to look peculiar as presented. The use of proper names will later be replaced by identifiers and links to other entities. In most systems of this nature, particularly those that lead to database structures, there is a need for more coding and identifiers. If the prescription was the entire system, the current diagram would be suitable. You know, however, that the prescription is only a small part of a much larger and more intricate system.

Therefore, you move forward to the next stage of ORM developmentbeginning to isolate entities. Currently, your model depicts entities and values and the interaction between them. To select entities for the system, you must step back and take a broader look at the system. Some entities are much easier to spot than others. Some entities play a more important role in the system. In the third step of the conceptual design, you attempt to identify all the primitive entity types in the conceptual model.

Focus ORM Modeling on Entities

The third step of the conceptual design requires knowledge of the entities in the system and how they interact. To derive all the data values would require knowing the properties that describe the system's elements. What you are looking at in this step of the process is entities that should be combined or those that can be derived through the use of arithmetic expressions. In other words, you want to group like information together and segregate calculated fields.

The exam will ask you to associate property information with the most appropriate entities. Pay close attention to the wording in the case study, which will give the necessary criteria for properly formulating the facts.

In the prescription example, you did not need to combine entities, nor did you have any entity that could be calculated. To give you a better perspective on this operation, take a look at another part of the system where you might find these combined or calculated entities. Using the call recording process, you could possibly identify these items. First, look at a sample call report (see Figure 6.5).

Figure 6.5. Billington call report.

From this information, you could come up with a fact list (see Figure 6.6).

Figure 6.6. Fact listing from a call report.

From this set of facts, you can apply the check for this step and see that the calculated element Duration could be removed. This field simply represents the difference between the call's start and finish times. Another possibility is combining the Doctor ID and Patient ID into a single element, Caller ID, a decision that should be based on your knowledge of the case study. It is possible for both IDs to remain if they are needed as separate elements. A database structure could easily handle the relationship of a single Caller ID to either a Doctor ID or a Patient ID, depending on what was needed.

Combining entities in an ORM model requires a careful look at the many types of elements in the model. Is the element type a Caller? Are there really two element types, a Doctor Caller and a Patient Caller? After all decisions have been made and the necessary entities eliminated or combined, what is left should be a better depiction of the true conceptual model.

For the purpose of continuing with the design, you will leave the two ID elements as separate entities. It is quite possible that Patient calls in the new system will have to be dealt with differently from Doctor calls. Keeping the two entities separate gives you the proposed ORM diagram shown in Figure 6.7. Notice the use of IDs for Employee, Doctor, and Patient. This is different from what you did with the prescription process, and when the whole system is combined, the prescription ORM would need to be redesigned slightly. The current names would belong as properties of the Patient and Doctor entities.

Figure 6.7. ORM for the call report portion of the system.

The complete ORM diagram for the Billington system would include some 65 or more separate entities. The major entities in the system that will represent tables include Doctor, Doctor-Patient, Patient, Calls, Orders, Order Items, Products, Prescriptions, Prescriptions-Drugs, Drugs, and HMO. Each table will have a set of ORM entities that will represent fields in the table structures. Given the space available in this book, illustrating the entire ORM model for the proposed Billington system is difficult. To gain some appreciation of the complexity of the system, however, review the sample ORM diagram prepared using Microsoft Visio (see Figure 6.8). Although it is difficult to see the details, it is easy to see how the ORM will later become the basis for the database layout. Visio is used throughout this chapter to illustrate ORM. It's well suited, with many facilities to diagram using ORM.

Figure 6.8. The Billington ORM entities.

In the next step of the ORM development process, you isolate the order portion of the diagram, which is not much different from the standard order-processing layout in most companies.