In the last post I had given a primer on service oriented data warehousing. I would like to dwelve deeper into some of the topics that SOA and DW holds in parlance.

One of the most important topics is “DATA”, where DW community had learned valuable lessons over years of experience in data warehouse implementations. The same is case with SOA, where pioneers of SOA have learned valuable lessons on data quality, data integration, and governance.

Any SOA initiatives will fail:

• When they sit on a platform of poor quality data,
• Attempt to share data that is not integrated across the enterprise,
• Implemented with insufficient thought given to security, compliance, and change management.

It strikes to me about “abstract services” in the data warehouse world, which are commonly recognized, simply stated, and independent of specific data sources, business processes, and BI deployments. I guess we can do that, let’s see how this works.

Consider the relationship between the dimension manager and the fact provider.

A dimension manager is the centralized resource for defining and publishing a conformed dimension to the rest of the enterprise. A master data management (MDM) resource is an ideal candidate for dimension manager. Enterprises where MDM is not instititionalized, the data warehouse team is a kind of “downstream MDM” function that gathers in-compatible descriptions of an entity such as customer and publishes the cleaned, conformed, as well as de-duplicated dimension to the rest of the data warehouse community.

The subscribers to this dimension are almost always owners of fact tables who want to attach this high quality conformed dimension to their fact tables so that BI tools around the enterprise can perform drill across reports on the conformed contents of the dimension.

There are two basic services that every dimension manager publisher needs to provide to the fact table subscribers.

Fetch means that fact table provider pulls information from the
dimension manager.

Alert means that the dimension manager pushes
information to the fact providers.

Let me elaborate;

• Fetch specific dimension member (we assume in this and the following steps that thedimension record has a surrogate primary key, a dimension version number, and that the information transmitted is consistent with the security and privacy privileges of the requester).
• Fetch all dimension members.
• Fetch dimension members changed since specific date-time with designated SCD Types 1, 2, and 3.
• Fetch natural key to surrogate key correspondence table unique to fact table provider.
• Alert providers of new dimension release. (A major dimension release requires providers to update their dimensions because Type 1 or Type 3 changes have been made to selected attributes).
• Alert providers to late arriving dimension members. (Requires fact table provider tooverwrite selected foreign keys in fact tables).
  
  These services are generic to all integrated data warehouses.
  
  In a dimensionally modeled data warehouse, we can describe the administrative processing steps with great specificity, without regard to the underlying subject matter of the fact or dimension tables.

That is why, in SOA parlance, dimensional modeling provide,s well-defined reference architecture on which to base these services. These services seem pretty defensible as meeting SOA design requirements.