CHAPTER 4
The XCellR8™ Approach: The Event Entity Relationship Diagram and Data Attribution

Now that you know how to develop an event process model, let’s look at the other components that should be included in the business requirements document.

The Event Entity Relationship Diagram

The event entity relationship diagram (EERD) illustrates the relationships between the objects identified in an event process model. The main purpose of the EERD is to help us identify missing requirements. Missing requirements are the hardest requirements errors to correct.1 (Similarly, if a required object is not present in a business event, its absence will prevent us from responding appropriately to the business event.)

The EERD will help you understand the different pieces of information that will be thrown at you during the requirements session. You have to know where all the information belongs, what that information may allow you to discover, and what each piece of information will let you do. This will help you define the requirements much more effectively and comprehensively.

Remember that an object is a person, place, thing, or concept—a noun—participating in a business event. Some of the nouns you’ll discover during the requirements-gathering process may not be objects, but data attributes, pieces of data that belong to and describe objects. To determine whether a noun is an object or an attribute, try to further decompose it into descriptive attributes. If the noun cannot be further decomposed, it is an attribute. If the noun can be further decomposed, it is an object.

It can be difficult to define objects. Sometimes, even the naming of an object itself is a daunting task. I remember facilitating a requirements session for a parts warranty tracking system at which the subject matter experts struggled to articulate what a “part” was!

Related to the EERD is another essential component of the business requirements document: the data dictionary. The data dictionary contains all needed information about the objects discovered for the target project, including their names, data attributes, and a description of how the objects relate to each other.

Object Relationships

When an object is identified in an event process model, it represents all the occurrences of that object. Think of the object as a number of records in a given file. A relationship between the objects Customer and Customer Deposit might be represented like Figure 4-1:

FIGURE 4-1: Relationship between Customer and Customer Deposit Objects

Each object that appears in an event process model becomes part of the EERD. The EERD has historically been used by database designers and architects to design databases, but in our approach, we use it a bit differently.

We can determine if there is a relationship between the objects Customer and Customer Deposit by asking questions.

• Can one Customer have one or many Customer Deposits? The answer is usually represented as 1 or N, where N indicates multiple occurrences.

• Can one Customer not have any Customer Deposits? If the answer is yes, the absence of Customer Deposits is represented by a zero (0). And if the answer is yes, we need to determine the circumstances under which this could happen. In what situation (business event) would the bank have information about a Customer who has never made a Customer Deposit? Perhaps the bank has a business rule stating that a Customer may open a bank account without making a deposit into it. If so, you may have to analyze that business event as part of the target project.
  
  If the bank’s business rule states that a Customer may not open an account without making a deposit, the answer to the question “Can one Customer not have any Customer Deposits?” should be “no.”

Now, what about the reverse relationship—Customer Deposit to Customer?

• Can one Customer Deposit be made by one or many Customers? No, it does not make sense that one deposit could be made by many Customers.
  
  Remember that just documenting users’ answers is not enough. The answers should also be examined closely for sense and possible hidden events.

• Can a Customer Deposit not be made by any Customer? Even if this question sounds dumb, it still must be asked. If the answer is yes, we need to ask in what business event the bank could have received a Customer Deposit that was not made by a Customer. If a Customer did not make it, who did? The answer to this question may lead us to a hidden business event. Asking follow-up questions such as these helps prevent scope creep by allowing us to document all events, even those that are not obvious, at the beginning of the project.

Sometimes you will discover an object in an event process model that does not have any relationships with other objects. This is all right. But if at the end of your analysis, you come across an object that does not have a relationship with any of the other objects you have discovered, take a close look at that object. It is quite possible that the object is not required or that it is really a data attribute of another object.

Creating an Event Entity Relationship Diagram

We are going to create an EERD based on a very simple real estate property listing system with the following events:

• A real estate property is put on sale.

• An offer to purchase the property is received.

• A real estate property is taken off the market.

A Real Estate Property Is Put on Sale

What information do we need to know in order to respond to this event appropriately?

For this event, we have discovered three objects so far: Property, Listing Agent, and Listing (Figure 4-2).

FIGURE 4-2: Initial EERD for “A Real Estate Property Is Put on Sale”

At this point, it is presumptuous to connect the objects to one another. We need to discover if there are relationships connecting the objects, and if so, what these relationships are. There are six possible relationships to explore:

1. Property and Listing Agent

2. Listing Agent and Property

3. Property and Listing

4. Listing and Property

5. Listing Agent and Listing

6. Listing and Listing Agent.

For each possible relationship, we must ask users a set of questions.

1. Property and Listing Agent
For each Property, how many Agent(s) can list it?

• Can one Agent list it? Let’s say the answer is yes.

• Can many Agents list it? Let’s say the answer is yes.

• Can there never be an Agent listing it? Let’s say the answer is no. But if the answer is yes, you need to ask, “In what situation will there never be an Agent listing the property?” If there is a situation in which this could happen, that situation is another event that may end up being part of the scope of the project.

2. Listing Agent and Property

• Can one Agent list one Property? Let’s say the answer is yes.

• Can one Agent list many Properties? Let’s say the answer is yes.

• Can one Agent never list a Property? Let’s say that this is not realistic; therefore, the answer is no.

With the above answers, our EERD would look like Figure 4-3:

FIGURE 4-3: Relationship between Property and Listing Agent

3. Property and Listing

• Can one Property be on one Listing? Let’s say the answer is yes.

• Can one Property be on many listings? Let’s say the answer is yes, but not under different Agents at the same time.

• Can one Property never be on any Listings? Let’s say the answer is no, because if it is not on any Listing, we will not have any record of it.

4. Listing and Property

• Can one Listing be for one Property? Let’s say the answer is yes, and that a Listing can be for only one Property.

• Can one Listing be for many Properties? Let’s say the answer is no.

• Can one Listing never be for any Property? Let’s say the answer is no.

Now our EERD looks like Figure 4-4:

FIGURE 4-4: Relationships between Property and Listing Agent and Property and Listing

5. Listing Agent and Listing

• Can one Agent have one Listing? Let’s say the answer is yes.

• Can one Agent have many Listings? Let’s say the answer is yes.

• Can one Agent never have any Listings? Let’s say the answer is no.

6. Listing and Listing Agent

• Can one Listing be the responsibility of one Agent? Let’s say the answer is yes—and only one agent.

• Can one Listing be the responsibility of many Agents? Let’s say the answer is no, although Agents sometimes work as part of a team. To keep it simple, however, we’ll say that only one Agent is responsible for a specific Listing.

• Can one Listing never be the responsibility of any Agent? Let’s say the answer is no.

Now our EERD looks like Figure 4-5:

FIGURE 4-5: Final EERD for “A Real Estate Property Is Put on Sale”

An Offer to Purchase the Property Is Received

For this business event, we still need to know the same information as before about the Property, Listing Agent, and Listing. Now we also need to know something about the Offer to Purchase: the amount offered, the date and time of the offer, who made the offer, and the date and time when the offer expires.

The new object, Offer to Purchase, should be added to the EERD as shown in Figure 4-6:

FIGURE 4-6: EERD for “An Offer to Purchase the Property Is Received”

The addition of a new object opens up six new possible relationships that we must query:

1. Property and Offer to Purchase

2. Offer to Purchase and Property

3. Listing Agent and Offer to Purchase

4. Offer to Purchase and Listing Agent

5. Listing and Offer to Purchase

6. Offer to Purchase and Listing.

Remember, as long as there are relationships that have not been queried in your EERD, your requirements are not complete. You must also keep looking for additional legitimate business events if any relationships yield a response of “0,” as we’ll see for the events diagrammed below, A customer makes a bank deposit and A customer makes a bank withdrawal.

After we analyze the event A customer makes a bank deposit, our EERD might look like Figure 4-7:

FIGURE 4-7: EERD for “A Customer Makes a Bank Deposit”

Here’s how we can translate these object relationships:

• A Customer may have one or many Accounts.

• A Customer may make one, many, or no Deposits (he or she may have simply opened up an Account without making a Deposit).

• An Account must belong to one and only one Customer.

• An Account may have one or many Deposits; an Account may not have a deposit (e.g., when an Account is opened without an initial Deposit).

• A Deposit must be made by one and only one Customer.

• A Deposit must be made into one and only one Account.

After we analyze another event, A customer makes a bank withdrawal, the EERD might look like Figure 4-8:

FIGURE 4-8: EERD for “A Customer Makes a Bank Withdrawal”

The relationships among the objects Customer, Account, and Withdrawal can be described as follows:

• A Customer may make one or many Withdrawals.

• A Customer may never make a Withdrawal (if he or she did not make a Deposit, there is nothing to withdraw).

• An Account may have one or many Withdrawals.

• An Account may never have a Withdrawal (if, for example, it is a savings account that does not allow withdrawals).

• A Withdrawal must be made from one and only one Account.

• A Withdrawal must be made by one and only one Customer.

You can see that the EERD also allows users to articulate rules that drive the business, but be aware that not every rule can be articulated in the EERD.

The EERD is sometimes called a mini-entity relationship diagram (ERD) because it is not a complete entity relationship diagram. The size of the final ERD for the system depends on the number of objects discovered for all the events. When your analysis is done, you may end up with a huge, complicated ERD, depending on the size and complexity of your project.

What Is Data Attribution?

During requirements analysis, information that is relevant to the project must be identified, organized, and documented. This process of data discovery and data allocation and organization is called data attribution.

The purposes of data attribution are to structure data in a way that eliminates any redundancy and, ultimately, to allow processing of the data without inconsistencies or errors. This means that we have to make sure that any particular data item, such as Customer Name, is maintained in one place only, while being available everywhere it is needed.

Remember that data attribution is not database design. It is simply a method that will help you capture and maintain necessary data. It’s particularly useful during chaotic requirements sessions, when information may be coming at you from all directions.

Data Attribution Guidelines

Here are six guidelines that will help you ensure appropriate data attribution.

When you discover a piece of data but do not quite know where it belongs, ask “Of what?” For example, when you come across an item called Price, ask “Price of what?” If the answer is “Price of the product,” you should have an object called Product, and it should have a data attribute called Price. How should you handle totals and flags? They should not be considered data attributes of an object. These are not real data items, although systems developers are used to treating them as such. But in reality, noting totals and flags as data attributes is an easy way to show users that you are listening to them. When designing and building the physical database, the database architects must decide whether it is advisable to keep them as data attributes.

A total can be generated by summing up the values of other data items, so it is redundant. For example, the total amount of a purchase order (PO) may be determined by summing up the value of each of the PO product lines. It can be time-consuming and cumbersome to go through every product line to do this, so systems developers often use a data attribute called “total amount of purchase order.” But if a total is used as a data attribute, it must be updated whenever a product line is changed or deleted.

A flag is an indication of the state of an object, which can also usually be determined by the absence or presence of another data attribute or entity. For example, if we need to know whether a product is hazardous, we can check to see if the object Product has a commodity code indicating that it contains hazardous material. Or if we need to know if an employee has been terminated, we can investigate whether the object Employee has a data attribute called Termination Date, which may or may not be populated.

As a rule, any state is also an event. For example, a PO may have any one of the following statuses: open, cancelled, closed, or suspended. Any of the following events could be within the scope of a project:

• It is time to open a PO.

• It is time to cancel a PO.

• It is time to close a PO.

• It is time to suspend a PO.

A unique identifier (ID) is a pointer or a “key” to an occurrence of an object. We call it a key because it unlocks or allows access to the object. The business analyst need not be concerned with determining unique identifiers. They are system attributes that will be created during the development of technical requirements specifications.

Every object must participate in two or more events throughout its life. If an object is not required in more than one event, there is no reason to keep a record of it. A record of information is maintained so that someone or something else can use it at the appropriate time. An object might be created by one system and used in another event or in another system. At the very least, an object must be created somewhere and then removed or deleted, perhaps somewhere else.

• If an object is modified or updated in one event, it must have been created in another.

• If a record (an occurrence of an object) is deleted, it must have been created as part of another event.

• If an object is created, it must be used (that is, read) in some event. If not, the object is not necessary and is therefore redundant.

Deleting an object may, in some instances, really mean that it is archived—moved from the current environment to another location where it can be retrieved within a certain period of time. For example, instead of storing email messages in your inbox, you might need to archive them somewhere else so that new messages are displayed more quickly.

In a business environment, there might be a financial system in which all transactions for the previous fiscal year are archived to prevent the operations people from making changes as the books for that fiscal year are closed. The financial people can still make adjustments as required; the taxation people can view the books for the last seven years in case of taxation audits. Transactions older than seven years may be deleted or moved to a deeper archive.

A CRUD² analysis may be done to identify those objects that participate in only one event. This ensures that all the events have been captured.

An object called Purchase Order might have the following data attributes:

• PO number

• PO date

• Product’s unique identifier

• Quantity ordered

• Supplier’s unique identifier.

Different objects often have redundant attributes. Let’s look at a typical Purchase Order object as an example. The Purchase Order should, in addition to the data that’s specified above, also include information such as product description, product cost, supplier name, and supplier address. Of course, the Purchase Order object does not have these data because they belong to other objects. In accordance with our data attribution guidelines, product description and product cost have already been attributed to the object Product, and supplier name and address find their home in Supplier. If we were to attribute this data again to Purchase Order, we would violate the first data attribution guideline, attributing data to only one object.

To avoid redundancy, we introduce a pointer to these objects. This pointer is called a logical foreign key. A foreign key is the unique identifier of an object that is present in another object. It links two objects together without creating redundancy. Under the object Purchase Order, instead of repeating the data attributes product description and product cost, we simply add a logical foreign key (the product’s unique ID) to the object. Similarly, instead of repeating the data attributes supplier name and supplier address under the object Purchase Order, we add a logical foreign key—the supplier’s unique ID—to the object.

On a PO form that looks like what is shown in Figure 4-9, there are data that repeat: item, quantity, price, extension, and date each item is required.

FIGURE 4-9: Example Purchase Order

If you listed the data attributes for each object, this is what you would end up with:

Once the multi-valued repeating group of data is isolated, the original object Purchase Order should look like this:

Note that the multi-value (MV) designation of the data attributes disappears from the original object once we have assigned them to new objects, which we arbitrarily named PO Line Item and Receipt. The relationship between Purchase Order and PO Line Item may be stated as “One Purchase Order may have one or many PO Line Items.” The relationship between Purchase Order and Receipt may be stated as “One Purchase Order may have one or many Receipts; One Purchase Order may not have a Receipt if the Purchase Order is cancelled or if the Supplier cannot fill the Purchase Order.”

Let’s take a look at another example:

Why do we bother to extract a multi-valued repeating group of data from an object? Why can’t we just leave it alone? Because we are trying to find as many business events as we can to ensure that we have a complete requirements analysis. We can find these events by asking, as we analyze each object, “What does this data allow us to do?” The ensuing discussion may lead us to additional events (which may or may not be within the scope of the target project).

For example, we would attribute the following data to the objects Employee, Full-Time Employee, Part-Time Employee, and Contract Employee.

After extracting the subtype data attributes, the data attribution of the original object, Employee, will look like this:

In Brief

Defining the process for a business event is not adequate to create business requirements. We use the EERD to document the relationships between objects participating in each business event. Understanding and diagramming these relationships can reveal new business events that might not have been apparent at the beginning of the analysis.

Also at this stage of the requirements process, we identify and document data attributes, pieces of data that belong to and describe objects. This process is called data attribution. Data attribution allows us to structure data in a way that eliminates redundancy and allows processing of the data without inconsistencies or errors.

NOTES

1. Robert L. Glass, Facts and Fallacies of Software Engineering (Boston: Addison-Wesley, 2003).

2. CRUD is an acronym for Create, Read (or Review), Update (or modify), Delete. The CRUD analysis is detailed in Chapter 6.