Portals eNewsletters Web Seminars dataWarehouse.com DM Review Magazine
DM Review | Covering Business Intelligence, Integration & Analytics
   Covering Business Intelligence, Integration & Analytics Advanced Search

View all Portals

Scheduled Events

White Paper Library
Research Papers

View Job Listings
Post a job


DM Review Home
Current Magazine Issue
Magazine Archives
Online Columnists
Ask the Experts
Industry News
Search DM Review

Buyer's Guide
Industry Events Calendar
Monthly Product Guides
Software Demo Lab
Vendor Listings

About Us
Press Releases
Advertising/Media Kit
Magazine Subscriptions
Editorial Calendar
Contact Us
Customer Service

Business Intelligence:
What's in a Name?

online columnist Jonathan Wu     Column published in DMReview.com
March 9, 2001
  By Jonathan Wu

Jonathan Wu would like to recognize Mariah Hourihan, technical writer and curriculum developer at BASE, for her efforts in editing and contributing to this column.

"What's in a name? That which we call a rose by any other name would smell as sweet; so Romeo would, were he not Romeo call'd, retain that dear perfection which he owes without that title. Romeo, doff thy name, and for that name which is no part of thee take all myself."

When I first read Juliet's verse from William Shakespeare's Romeo and Juliet in junior high school, I thought that she was pretty confused. The name Romeo was not the issue; it was his family name, Montague, that was the problem. As you may recall, Juliet's family, the Capulets, was at war with Romeo's family, the Montagues. It really did not matter what Juliet wanted to call Romeo; he was still a member of the Montague family and therefore off-limits to her.

Language can be a difficult subject. How to describe, define or designate a person, place, thing or concept can be complicated. Juliet's speech expresses this complexity and captures the sometimes arbitrary, and often frustrating, nature of naming conventions. Most businesses can relate to Juliet's sentiments. Organizations continuously encounter difficulties with their naming conventions and data definitions.

I remember one client very well with just such a "naming" problem. At this client, the divisional controllers would meet with the corporate controller on a monthly basis to review the financial performance of each division and of the organization as a whole. Each divisional controller would bring with him/her a report summarizing revenue for his/her division. Theoretically, the summation of the total revenue for each division should equal the total revenue for the organization. Unfortunately, this was not the case. The summation of revenue for each division was greater than the revenue reported by the corporate controller. How could this happen? After reviewing each divisional controller's revenue report, we identified inconsistencies in the definition of "revenue" amongst the group. Depending on whom we were speaking to, "revenue" was:

  • Gross sales,
  • Gross sales less discounts, or
  • Gross sales less discounts and returns.

Which definition was correct? After some lively discussion, the group agreed upon one definition of "revenue." In subsequent meetings, the summation of revenue for each division did equal the total revenue for the organization. This example highlights the business impact of inconsistent data definitions in this particular organization. However, the naming of common objects is crucial to any business, as it is imperative for comparative reporting and analysis.

Object Data Definitions

From the perspective of business intelligence (BI) and related technologies, an object is an attribute, calculated value or logical condition that yields data. I have categorized object data definitions into three groups: user defined objects, local object data definitions (LODDs) and common object data definitions (CODDs).

Figure 1: Object Data Definition Groups
Figure 1: Object Data Definition Groups

User Defined Objects

With most BI applications that provide ad hoc query and reporting capabilities, a user can create his/her own objects within a report or query. For instance, User A at the fictitious Shakespeare Corporation – let's call him Romeo – has access to a sales subject area and can create his own object. The object he creates can be based on or derived from existing objects. Romeo creates an object called "my revenue" which is derived from gross sales less discounts for the products and services he has sold. Only its creator, Romeo, can view the "my revenue" object. User B – let's call her Juliet – cannot see Romeo's user defined object unless she creates the same object herself.

Local Object Data Definitions (LODDs)

Departments or groups within an organization may have their own unique data definitions that are shared within the department but not with the entire organization. For example, a sales subject area was developed for the Shakespeare Corporation and is primarily used by individuals in the sales department. The sales subject area contains objects about revenue, products, customers, regions and sales people. Some objects are unique to the sales department but other objects are included in other subject areas. LODDs focus on the objects unique to sales such as "commission revenue," defined as cash collected on sales. With LODDs, objects unique to one subject area are not available for use in other subject areas. LODDs differ from user-defined objects in that their unique names and definitions serve a group as opposed to an individual.

Common Object Data Definitions (CODDs)

Because they require consensus regarding the naming and defining of objects to be used throughout the entire organization, most organizations struggle to develop CODDs. Using the Shakespeare Corporation again as an example, there are two subject areas, "sales" and "general ledger" which are used by the sales department and the accounting departments, respectively. Both the "sales" and "general ledger" subject areas share common objects such as "revenue," defined as gross sales less discounts and returns. With CODDs, objects that exist in more than one subject area must have the same unique name if they have the same unique definition. One consistent definition of "revenue" (gross sales less discounts and returns) allows both the sales and accounting departments to use the "revenue" object from the "sales" and "general ledger" subject areas, respectively, to perform comparative analysis of "revenue". The consistent definition of objects enables comparability across subject areas. CODDs, like user defined objects and LODDs, are unique names and definitions but rather than serving one user or one group, they serve the entire organization.

While users can create objects for their personal use, an organization must focus on CODDs to enable comparability and consistency of information across subject areas. Establishing standards such as naming conventions of CODDs, policies that facilitate ownership and development of CODDs and procedures for deploying an object change control can be difficult because consensus within the organization is required. The greatest challenge is in enforcing the standards, policies and procedures, which often involve changing the manner in which people request and obtain information. Additional benefits of establishing CODDs include the elimination of redundant work and the ability to leverage previous efforts. So, what's in a name? For businesses like the Shakespeare Corporation, a great deal.


For more information on related topics visit the following related portals...
Business Intelligence.

Jonathan Wu is a senior principal with Knightsbridge Solutions. He has extensive experience designing, developing and implementing information solutions for reporting, analysis and decision-making purposes. Serving Fortune 500 organizations, Knightsbridge delivers actionable and measurable business results that inform decision making, optimize IT efficiency and improve business performance.  Focusing exclusively on the information management disciplines of data warehousing, data integration, information quality and business intelligence, Knightsbridge delivers practical solutions that reduce time, reduce cost and reduce risk. Wu may be reached at jwu@knightsbridge.com.

E-mail This Column E-Mail This Column
Printer Friendly Version Printer-Friendly Version
Related Content Related Content
Request Reprints Request Reprints
Site Map Terms of Use Privacy Policy
SourceMedia (c) 2006 DM Review and SourceMedia, Inc. All rights reserved.
SourceMedia is an Investcorp company.
Use, duplication, or sale of this service, or data contained herein, is strictly prohibited.