A dimensional (denormalized) data warehouse is the product of a series of translations.
1. Data Sources are analyzed.
2. A normalized model called the Operational Data Store is created to represent the enterprise.
3. A denormalized Dimensional Data Store is created based on the normalized Operational Data Store.
4. ETL routines are written to move data from the Source Systems to the Operational Data Store
5. ETL routines are written to move data from the Operational Data Store to the Dimensional Data Store
6. Data is then extracted transformed and loaded from the Data Sources into the Operational Data Store
7. Data is then extracted transformed and loaded from the Operational Data Store into the Dimensional Data Store
8. Analytical tools are used against the Dimensional Data Store for reporting
9. The two step ETL process (6, 7 & 8) is repeated on a schedule as frequently as every day
This is the Kimball method.
Similar processes are used to create subsets that function as Data Marts.
I can't comment on Inmon's strategy except that he is in favor of normalized models (Operational Data Stores or even properly normalized Source Systems) being used without modification as processing power increases and makes the performance barriers of multiple joins go down. Kimball's rebuttal is that a denormalized dimensional model is easier to grasp by the end user than a complex normalized data model.
absolutely irrelevant to this topic, but interesting nonetheless
I would disagree with you R937, I see it as a bit obscure but extremely relevant once you get past the "mental disconnect" at the outset. One of the things that database "experts" often get hung up on is that there is exactly one "optimum" solution to a given problem, and I strongly think that there are often many solutions that are optimum in different ways.
Nah, I'm not saying you're hung up on anything. Regardless of what you might claim, you do qualify as an expert (but then again, I'm sure that you've heard my defintiion of what an expert is, so that's no big deal either).
I do think that everyone in the database field falls victim to the thought that there is one "optimum" solution to any given problem, and based on my experience that simply isn't true. That's why I ask a lot of questions before starting to solve hard problems, so that I understand what is important to the end user. My opinion matters, and my skills are necessary to solve the problem they pose, but their needs are what determine what they'll see as the "best" solution.
I've just spent a lot of time in my life solving the wrong problems. I've found a lot of great solutions that just didn't matter to, or at least didn't help anyone. I'm getting picky in my old age, and prefer to only solve problems that matter to someone, I've lost the thrill in solving problems just for the sake of solving problems.
I felt it was relevant because the spaghetti sauce scenario was a design problem. They were looking for a single design for spaghetti sauce and it took tremendous insight to see beyond that.
When I design databases these days I am finding more and more often that I am asking myself the question, do these users really want that off the shelf solution? Do they even know what is possible? Our opportunities as database designers lies in the democratization of data models not an all in one solution.
It called The Semantics of Business Vocabulary and Business Rules (SBVR) and if you’re a system modeler those words may never leave you the same.
“SBVR specification defines a metamodel and allows to instance it, in order to create different vocabularies and to define the related business rules; it is also possible to complete these models with data suitable to describe a specific organization. the SBVR approach provides means (i.e. mapping rules) to translate natural language artifacts into MOF-compliant artifacts; this allows to exploit all the advantages related to MOF (repository facilities, interchangeability, tools, …).
Several MDA-related OMG works in progress are expected to incorporate SBVR, including:
Business Process Definition Metamodel (BPDM)
Organization Structure Metamodel (OSM)
Business Motivation Model (BMM)
UML Profile for Production Rule Representation (PRR)
UML Profile for the Department of Defense Architecture Framework/Ministry of Defense(Canada) Architecture Framework (DoDAF/MODAF).
Knowledge Discovery Metamodel (KDM)
Wider interest in SBVR– Semantic Web, OASIS
The Ontology Definition Metamodel (ODM) has been made compatible with SBVR, primarily by aligning the logic grounding of the ISO Common Logic specification (CL) referenced by ODM with the SBVR Logical Formulation of Semantics vocabulary. CL itself was modified specifically so it potentially can include the modal sentence requirements of SBVR. ODM provides a bridge to link SBVR to the Web Ontology Language for Services (OWL-S), Resource Description Framework Schema (RDFS), Unified Modeling Language (UML), Topic Map (TM), Entity Relationship Modeling (ER), Description Logic (DL), and CL.
Other programs outside the OMG are adopting SBVR. The Digital Business Ecosystem (DBE), an integrated project of the European Commission Framework Programme 6, has adopted SBVR as the basis for its Business Modeling Language. The World Wide Web Consortium (W3C) is assessing SBVR for use in the Semantic Web, through the bridge provided by ODM. SBVR will extend the capability of MDA in all these areas.”