Most Read This Week
Tips for Efficient PaaS Application Design
Simple Data Entity Modeling
By: Govind Davis
Sep. 16, 2009 09:00 AM
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
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.
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.
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.
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.
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads