Coming from a world of B2C web applications, I am more than familiar with the reporting challenges associated with pulling analytics from transactional databases:
- (1) Profile information is often overwritten when UPDATEs are performed,
- (2) Information is segmented in different systems and worse, with different data access methods (If you want a headache, try writing an R script to mash up information from a SOAP API with a PostGres database!),
- (3) Different business units have different definitions of business objects, and
- (4) the data isn’t in a performant or understandable system.
Yep, it’s safe to say that I’ve pulled some long hours preparing for some board meetings or doing decision support on some production direction my team is choosing.
The last several months, I have been fortunate to be put on a fun little project at Simple Energy: A Data Warehouse. I was *even* lucky enough to be sent to San Francisco for a 4 day intensive class on Dimensional Modeling In Depth: By The Kimball Group. Learning Data Warehousing from Ralph Kimball is like learning design from Jony Ive — The guy has been working on this since the 70s and has been where the action is since then. Zerox PARC, IBM, and consulting for a handful of Fortune 500 companies!
I am preparing a series of posts about what I’ve learned and why it matters. These posts are for you if you:
- Have trouble with decision support in your organization.
- Are seeing slow query response times.
- Have a transactional system that requires multiple-joins or multiple data-sources to get your information.
- Are integrating with a 3rd party marketing software.
- Have data integrity issues.
- Have inconsistent definitions of business objects across groups.
You can follow along with the data warehousing tag on owocki.com.