1.10. Refining an Event-Response

Examine your event-response model and remove any processes or data flows that are not part of the business policy and that exist purely because of the way Piccadilly currently does the job. While you are doing this, replace physical data stores with essential data entities and data-bearing relationships. The work you have already done with the system data model will help you to identify the essential data needed to support this event-response.

Another aid for you to identify the essential data is to build an event-response data model. This model shows only the essential data stored or accessed by a particular event-response, and its limited scope helps you to focus on the details for this event. Naturally, as before, the system data model that you already have will help you, but you should concentrate on establishing all the details of the data accessed or stored by this particular event-response.

While you are building the event-response data model, consider how the essential processes use the data. Annotate each of the data entities and relationships with the appropriate CRUD (create, reference, update, delete) operators. When working at the event-response level, you can see exactly what kind of use is made of the data. After you have modeled all the event-responses, you’ll combine all the fragmented data models into the system data model. At that stage, you’ll use the CRUD check to ensure that you have captured all the event-responses. In other words, every entity and relationship has to have sufficient CRUD processes to make a working system. Missing CRUD processes mean missing events or redundant data. You’ll learn about the CRUD check a little later in the Project in Chapter 1.15 CRUD Check and its associated review Chapter 3.14.

As you work with the data, remember that if you need to create any new data flows, define them in the data dictionary. Similarly, if you discover new attributes, add them to your definitions of the entities and relationships.