I've recently been having a lot of problems with my laptop. Seeing regular BSODs isn't something that makes me very happy. Now it just so happens that I'm running Vista on my Toshiba tablet. Although it is purportedly faster, better, etc. than XP, other then the occasional slow response I was not altogether too unhappy with Vista. Contrary to what other people seem to experience I might add. I have been 'cured' of my optimism however. Since the start of this year my tablet has started BSOD-ing on me. I finally decided to attack the beast and tried to figure out what was happening. I am not an expert in the actual sense of the word, but searching the internet does show the occasional nugget between the garbage. A large part of that of course stems from the fact that my questions aren't always smart or to-the-point. A question like 'BSOD Vista' is likely to get a lot of hits, as I was not so happy to find out. Being more particular in asking 'BSOD Vista Toshiba' considerably brought down the number of suspects. Including the tablet bit and make also helped. And replacing the brand related stuff with the name of the driver shown prominently in the blue screen itself gave the best answer at the first page of my search.
Now why am I nattering on about this issue when we're usually talking data warehouse and master data issues here? Just bear with me, I'm getting to it… It is actually quite amazing to see how much garbage you can get when searching for things on the internet. "But hey, that's only natural" you could say, "if you start your seach more or less at random you cannot hope to get any useful result". Surely true, I'll not deny it. However it generally takes most people quite a few tries to get something even remotely related when previously unknown or rather unanticipated questions need to be asked about some issue, particularly when the issue itself is not very clear. Now that is what I am getting at.
It is very hard to formulate a proper question when you don't really have an idea of what it is you want to know or hope to find. You usually hope to get something you can work with: a solution to a problem, or an explanation for some issue. For that you need to have a certain knowledge about your issue, which things matter, what their meaning is and how they are related. Combining meaningful and related elements usually yields far better results then trying various combinations of unrelated elements in your search or – as in our usual blog case – your query.
So we need some sort of 'lingua franca' within our organisation (where we might have multiple applications and even data warehouse environments) so we can ask our questions and get meaningful results – i.e. we need a collection of important terms, their semantics and how they are related. This 'collection' is also known as a 'Fact Model' based on a 'Business Vocabulary'. A Fact Model contains all assertions (called facts) involving core concepts of the business. The Business Vocabulary exists of all the terms and definitions of those concepts that an organisation or community uses in their communication. Facts connect those terms in a manner that should reflect the real world. A fact model focuses on the knowledge (or semantical) part of a business problem – that is, on how knowledge underlying business operations (the "flow") is organized. A good fact model therefore tells you how to structure your basic thinking (or knowledge) about the business process based on a standard (business) vocabulary. This ensures that you can communicate effectively about that knowledge with other project participants. It also allows you to exploit this standardized knowledge and vocabulary to express other types of requirements, especially rules – and to communicate (or search/query) about those effectively too. See also http://www.tdan.com/view-articles/5169/ and http://www.semanticarts.com/DesktopModules/ViewArticle.aspx?ArticleID=745&mid=3475.
The term 'Fact Model' should not be mistaken with the facts we usually talk about in terms of data warehousing. These are basic or ground facts people use in communication that denote a proposition taken to be true by the business (e.g. Employee works for Department), as opposed to quantitative figures broken down by dimensions that denotes something measured (e.g. 14 employees work within the Sales Department). A Business Vocabulary in its turn should not to be mistaken for a data model. A business vocabulary is all about description, not design and about semantics, not syntax. The similarities are that both Business Vocabularies and data models use more or less the same terminology; things like definitions, homonyms, synonyms, roles, categorizations and classifications, etc. Business vocabularies however do not try to distinguish between 'entities' and 'attributes'. Business Vocabularies also are not specifically system or database related and Business Vocabularies can include verbs (i.e. information about process) and thus can also be used to formulate consise business rules (as said earlier). There is an OMG standard for the 'Semantics of Business Vocabulary and Business Rules' (SVBR, http://www.omg.org/docs/dtc/06-03-02.pdf), that can be used to foramally capture business concepts and business rules.
To finish with a bang, as Fact Models and Business Vocabularies capture formal written knowlegde (semantics) about business concepts and business rules, a candidate schema methodology for (parts of) Fact Models and Business Vocabularies could be ADAPT ™, as we strive to capture the business demand for performance analysis with ADAPT ™!
More on this later…