We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Blog: Dan E. Linstedt Subscribe to this blog's RSS feed!

Dan Linstedt

Bill Inmon has given me this wonderful opportunity to blog on his behalf. I like to cover everything from DW2.0 to integration to data modeling, including ETL/ELT, SOA, Master Data Management, Unstructured Data, DW and BI. Currently I am working on ways to create dynamic data warehouses, push-button architectures, and automated generation of common data models. You can find me at Denver University where I participate on an academic advisory board for Masters Students in I.T. I can't wait to hear from you in the comments of my blog entries. Thank-you, and all the best; Dan Linstedt http://www.COBICC.com, danL@danLinstedt.com

About the author >

Cofounder of Genesee Academy, RapidACE, and BetterDataModel.com, Daniel Linstedt is an internationally known expert in data warehousing, business intelligence, analytics, very large data warehousing (VLDW), OLTP and performance and tuning. He has been the lead technical architect on enterprise-wide data warehouse projects and refinements for many Fortune 500 companies. Linstedt is an instructor of The Data Warehousing Institute and a featured speaker at industry events. He is a Certified DW2.0 Architect. He has worked with companies including: IBM, Informatica, Ipedo, X-Aware, Netezza, Microsoft, Oracle, Silver Creek Systems, and Teradata.  He is trained in SEI / CMMi Level 5, and is the inventor of The Matrix Methodology, and the Data Vault Data modeling architecture. He has built expert training courses, and trained hundreds of industry professionals, and is the voice of Bill Inmons' Blog on http://www.b-eye-network.com/blogs/linstedt/.

June 2008 Archives

For a long time Dr Ralph Kimball has spoken about subject oriented design. Many have made a living off of producing subject based data marts. One of the problems this has lead to is a series of loosely coupled stove-piped answer sets that are then "discussed" in the light of an enterprise data warehouse. I've been teaching, talking and writing about (over the last 10 years at least) a notion called Functionally Oriented Design. In this entry I will briefly introduce my notions of these concepts.

When we examine subject oriented design patterns we discover that the true nature of this design is to meet the needs of a specific group of people, furthermore - performing a very specific task or attempting to answer a highly specified business question. In fact when we do additional research around "subject-oriented design" we find a number of interesting facts:

Decompose problem vertically into separate features, perhaps with a distinguished base feature containing common functionality; design and implement each of these features separately; then compose feature implementations to produce a complete system."
Define the problem and design the system. Then decompose the design horizontally into implementation stage’s each of which extends its predecessor. Implement these stages successively, extending system through composition. "

What does this mean?
Well, if it's used as a design paradigm for an enterprise - this usually means that the enterprise should be broken in to lines of business, and then further broken in to specific feature-based activities. I can easily see where we would get our notions of facts for a specific feature set, that is: facts at a specific grain, designed to answer a very specific set of questions.

What about the staging or re-composition?
Interestingly enough this is what conformed dimensions attempt to do, along with Junk and Helper tables... Once decomposed, then the next step is to "stage" the problem - horizontally along the implementation to extend it's predecessor. This might be related to additional aggregate fact tables, and even more conformed dimensions _at a different grain_. However this usually doesn't extend itself beyond a single line of business. Which is why, when we examine Dr Kimball's enterprise Service Bus, a line has been drawn around the loosely coupled subject oriented data marts and "assigned the term" of data warehouse.

The image seen here, is one representation of many that Dr Kimball has subscribed to over the years. http://www.dwmantra.com/concept_index.html

As Bill Inmon states: "A school of minnows (swimming in close proximity) doesn't equal a whale." At the same time, the original definition of data warehousing includes "subject-oriented" in it's purpose.

Lately (for the past 15 years or so) I've been experimenting with Functionally Oriented Designs. Why? Because the business process is very important to the enterprise data warehouses that I've been building.

The nature of functional design is to couple form and function together to solve a problem. In this case, the form is the data model, and the function is the business process. By doing so, we solve different types of problems for the enterprise data warehouse. Don't get me wrong, I believe in Star Schemas for end-user access, cleansed and organized data, but I do _not_ subscribe to their use as an enterprise data warehouse. More on that later.

Functionally Oriented Design has taught me that it is possible to build a system based on business rules and to maintain it as quickly and easily as the business changes. More to the point, if we design our enterprise data warehouse properly, we can actually store the history of _some_ of the business rule changes within the structure of the enterprise warehouse as well. Thereby opening up new territory for "comparative design analytics" in review of "what have we changed business wise, and was it a good decision..."

Functionally oriented design is focused on the business process, and therefore the business keys that drive through the business processes. Because of this notion, the design actually runs horizontally (instead of vertically by line of business) across the entire enterprise. The design focuses on tracking and tracing all information by business key from the time it first enters the business to the time of delivery of the goods or services.

The Data Vault modeling paradigm is based on functionally oriented design views, we'll discuss more in the next entry. For now, if you have a different view on Subject Oriented Design I'd love to hear it.

Dan Linstedt

Posted June 30, 2008 5:57 AM
Permalink | No Comments |