On yet another application review with a prospective client the issue of potentially troublesome data entity relationships came up.  A number of our clients are existing QuickBase users who have made an initial attempt to design their applications and find that some assistance is needed.  The first thing we look at to understand their application requirements are the data entity relationships.

This is done in the context of both their existing application as well as their general business requirement because often applications are not correctly designed to support the structure of the business information.

One of the most common mistakes we see is when application designers build inflexible structures into their applications because of a lack of understanding of relational data.  During the client call mentioned above we saw that they had set up a table of Projects and then wanted to capture monthly budget data.  To do this the application designer created twelve fields, one for each month, on the project form to capture the budget information.  For spreadsheet abusers this kind of flat structure may seem natural.  However, in a database environment the goal is to structure related data to support reporting, visibility and analysis of information.

Data Entity Modeling 101
Whenever we start development of a new client application our first step is to model the data entity relationships.  The key to this is asking detailed questions about how information in the organization is structured, used and viewed.  A simple line of questioning can help flesh out data entity relationships.

1. Start with element of data that is at the core of the process being evaluated.  In most cases this should be relatively easy to identify; for example, when discussing a Project Management application the core data element is typically a Project.  CRM or Sales force Automation applications can be more challenging but typically have an entity such as an Opportunity, Case or Lead as the core.

KEY QUESTIONS

• What is the main function of the application?
• What do you call the form that you currently fill out as part of the process?

2. Identify primary relationships to the core data entity (see Example A).  Almost all business processes involve data that has some kind of hierarchy so it's should be expected that a core data entity will have one or sub-entities.  A sub-entity is a child relationship where the core is the parent and the sub-entity has one or more pieces of information related to the parent core entity.  There are many examples of this; Projects almost always have a list of associated Tasks, Quotes have Lines or Quote Items, Sales Orders have Order Lines.

KEY QUESTIONS

• What other information is captured as part of the primary function?
• Is additional information singular to the core entity or might there be more than one piece of information of the same type?
• Is information entered on a separate form linked or referenced to the core entity?

3. Identify auxiliary entity relationships to the core and primary data entities (see Example B).  We often refer to this auxiliary information as meta data because it is really information that helps qualify another data entity.  Auxiliary information is best defined as information that helps define, assign or organize a core or primary data entity.  Often information that is contained in a drop-down field is converted to an auxiliary data entity to allow for easier management of the list.  Another very common auxiliary data entity is a Staff or Resource table used to assign a Task or a Project Manager.

KEY QUESTIONS

• Is the field on the primary or core entity a drop down that needs to be selected from a dynamically changing list?
• Is there additional information that needs to be passed to the primary or core entity from a selection other than just the selection value?
• Is there categorical or list data that is likely to be used in more than one place in the application?

The Benefits of Proper Data Entity Modeling

Circling back to the example above where the budget data was set up as a flat structure with a field for each month there are a number of considerations to point out.

1. It's would be confusing to interpret a project budget that spans the end of the year because there would be data points in the ending months and beginning months but no specification as to which year the months belong in.

2. No project budget could ever be more than year long (there are only 12 fields to capture data).

3. Reporting trend and aggregate data would be very difficult due to the inability to easily identify the budget year and not having budget amounts in 12 different fields.

The ideal solution would be to set up a Budget entity related to the Project and capture each month as a single entry with the month, year and amount entered.  This would allow QuickBase and really just about any database to much more effectively report the budget information.

This small example is just one of many such data entity challenges we have seen.  In some cases the limitations caused by inefficient structures is not realized until substantial data and process development has occurred and correcting it can be a major project.  Therefore it is critically important when designing any database application to go through the data entity mapping exercise as an early step.