1.3. What About the Business Data?

Let’s consider the underlying strategy you are using here. Why start by building a context diagram rather than a data model? The answer hinges on the word “start.” You start the context diagram but do not necessarily complete it before starting the data model. In our experience, you can rarely build an accurate context diagram on the first attempt. However, the better your knowledge of the boundary data flows, the easier it is to construct the data model. By at least making a first attempt at the context diagram, you make it easier to build a relevant first cut of the data model. Then, the experience of working with the data model verifies your ideas for the context diagram. We therefore suggest you first attempt the context diagram, and then start the data model. The two models are completed in parallel, with the knowledge gained from one model helping you to build the other.

Figure 1.3.1: The context diagram, which defines the boundaries of the system. All of the data that flow into and out of the context are part of the data model.

Now let’s turn our attention to the data model. This model focuses on the business subject matter, and helps you to raise new questions by putting aside, for the moment, the system’s processing. However, you can’t complete the data model until you have thoroughly investigated all the processes. So the model you are about to build must remain a provisional model until you can confirm it by modeling the processes in the form of event-response process models. These will be discussed at a later stage of the Piccadilly Project.

To build the first cut of the data model for Piccadilly Television, start with a detailed description of the system’s policy. “The Story of Piccadilly Television” in Chapter 1.2 Start with the Context, which provided the information for you to build your context diagram, is also the source of information for identifying entities and relationships. To help in this task, use the heuristics, or rules of thumb, presented in Chapter 2.5 Data Models to identify entities and relationships.

You are trying to convert a statement of policy into a data model, so there will be occasions when you are not sure whether you have discovered a legitimate entity or a relationship. The best approach is to put it in the model and mark it with a question mark for later resolution. One of the reasons you’re building this model is it focuses your questions. Normally, you’d resolve your questions with the users. Because you don’t have a user for this project, we’ll try to anticipate your questions. We can’t possibly anticipate all of them, but your questions won’t remain unanswered. Later, when you do a detailed analysis of all the processes and data inside the context, this analysis will provide the answers and confirm all your entities and relationships.

The first-cut data model is not intended to be definitive, and, as we mentioned, there will be opportunities to confirm and correct it. This model is a statement of what you know about the business policy within the context. It should contain all of the entities and relationships that you believe are necessary for the system to remember.

“Necessary to remember” means that an entity must have a business purpose, and must be needed for later reference. For each relationship, ask if it has a business reason and if the user needs to know that connection between the entities. Add cardinality to the model by asking this question of the entities at each end of the relationship: “For one instance of this entity, how many of the other can participate in this relationship?”