My company needs a central location for all customer-related data. We are talking about building a customr data mart because everyone wants to do data mining against heterogeneous source systems, monitor the life cycle of the customer, have accurate information about address, contact, householding, etc. Since some of the related information needs near real-time or real-time updates. There are no specific facts associated with customer information, so maybe an ODS is a better solution. What's your opinion? Is that even valid to have a data mart without any fact tables?


Sid Adelman’s Answer: If people need real-time data, the requirement is for an operational system not a data warehouse. If you try to design and develop a database that will satisfy data mining, tactical decision making, strategic decision making and operational capabilities, your system will satisfy no one and it will fail. Don’t do it!

Larissa Moss’ Answer: There is a gigantic myth in data warehouse Land that all data warehouse databases must be multidimensional. That is not true at all. Multidimensional databases are reporting databases, which support the typical line-item, column, sub-total, grand-total types of reports. For example, if your requirements call for a "sales report" to show the columns Total Number of Sales, Total Sales Amount, Total Discount Amount by the dimensions PRODUCT, STORE, REGION and TIME, then, by all means, build a multidimensional database with facts and dimensions. However, if your requirements are to reflect true data relationships as they exist in the real business world (appears to be your case) – and not as they exist on a report, don’t build a multi-dimensional database. It is not a sin to build entity- relationship-based databases, whether ODS, data mart or oper mart as long as it is the most appropriate design for your specific requirements. And, it is the most appropriate design if your requirements do not call for storing facts for any reporting patterns. I will go a step further and say that in your case a multi-dimensional design would be detrimental, because you would loose the true business relationships among the entities that you desire to capture. Bottom line, it is perfectly valid to have an entity-relationship-based data mart without any fact tables. (By the way, "dimensions" are nothing more than business entities anyway.)

Chuck Kelley’s Answer: I have not quite succumbed to the concept of real-time data warehousing. I don’t think that a new point changes a strategic decision. Surely a tactical one, but not a strategic one. If I saw sales of Coca Cola dropping in all my stores during the last minute, what effect would that have on my strategic thinking? I don’t think it would have any affect. Now if you are running a special promotion on egg nog during the Christmas holiday season (or you can pick you favorite holiday), then you might want up to the minute sales to help project ordering and shipments. However, I believe that is operational in nature and would be an ODS.

Now, looking at the data that you want to data mine, these are prime candidates for a data mart (as part of the data warehouse). I can not see anything that requires real-time updates. As for facts, what metric would you be monitoring for the life cycle of the customer? That they came into the store on a certain day (that’s the fact)? That they bought something, although you may not know what it is (they bought something, that’s the fact)? That they visited my Web site (that’s the fact)? I think there probably are facts; you may not quite recognize them yet. I would find it hard to have a data mart without facts (remember that existence is a fact!), because I couldn’t see how you could tie all the dimensions together for analysis.

Joe Oates’ Answer: It sounds to me that what you are looking for is consolidated customer data, where there is only one instance of a customer no matter how many products or services the customer has. It also sounds like this information is probably primarily for use in application systems. While many organizations have used data warehouse initiatives to achieve this, many organizations have done so without implementing a data warehouse.

My advice is to forget about putting labels to the solution and to identify the critical success factors and other important requirements and then decide how it will be implemented. It is important to understand that if produce a central customer database for operational purposes, e.g., not as part of a data warehouse, it will probably not have some critical information that would be very important to your organization. It would lack such things as understanding which customers are profitable, what customers are likely to respond to certain promotional campaigns, customer profiles, behavior scores, etc.

Clay Rehm’s Answer: Calling this a data mart may be selling the idea short – this is really a customer database or even a customer relationship management (CRM) system. Don’t get hung up on the name – as long as everyone understands what it is. Design and develop it so it is easy to use and easy to access. Design with your business partner’s needs in mind. They must be involved with the design process.

I feel that it is valid to not to have fact tables in this database. You can always add facts and measures later once you determine the need for them.

Les Barbusinski’s Answer: I question your assertion that "there are no specific facts" associated with a Customer. In most cases when a company sets up a centralized repository for Customer information they want to see a 360-degree picture of the Customer. This includes things like credit history, credit card balances, product purchases in the last 14 months, number of visits to the store or to a company Web site, reaction to specific campaigns, etc. All of these measurements are facts.

In any case, if this information will be analyzed dimensionally, then a data mart is the appropriate approach. If not, an ODS would probably be a better approach. Either way, your requirement for achieving near-real-time updates of certain Customer data will be your largest hurdle. Just remember to a) minimize the number of elements that require real-time updates, b) segregate those elements into separate tables, c) use views to join real-time data elements with other facts or dimensions in the mart, and (d) apply OLTP methods to maintain the selected data elements in near-real time.

Lastly, without fact tables, all you have is dimensions. A data mart consists of both facts and dimensions. Hence, a mart without fact tables…is not a mart. You can have a "factless" fact table (see Kimball’s Data Warehouse Toolkit book), but not a "factless" mart. Hope this helps.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access