Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people, just like you, are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions

Fact/Dimension - for DW and also DM?

Posted on 2011-02-17
Last Modified: 2012-05-11
is the Fact/Dimension way of building database only for Data warehouse or Data Mart also has the same concept?

Question by:anushahanna
  • 4
  • 3
LVL 17

Assisted Solution

MIKE earned 75 total points
ID: 34923676

Fact/Dimensions are more based on the KIMBALL methodology, a Data Mart is more inline with INMON methodology.

Basically KIMBALL believes that it is better to build the DATA WAREHOUSE first based on Business Processes and requirements, INMON believes that the DATA MARTS should be build first based on Business Processes/Requirements, then the DW should be based on these data marts.

KIMBALL METHOD = Fact / Dimensions (star schema)
INMON METHOD = DATA MART based on business units/processes.

In my opinion, KIMBALL approach is the more practical way of building Enterprise DW's.

However, the debate is a never-ending one.....


Author Comment

ID: 34935918
>>INMON ......then the DW should be based on these data marts.

what specific methodology?

regardless, in both cases, DW ends up with Facts/Dim?
LVL 22

Accepted Solution

dportas earned 425 total points
ID: 35016949
CRXIuser2005 seems to have his summary of the Ralph Kimball and Bill Inmon approaches the wrong way round.

Kimball's approach is to create data marts. Kimball's view is that a "data warehouse" is nothing more or less than a collection of marts. Kimball's "dimensional" modelling approach is therefore the one he recommends only for building marts. Marts are what dimensional modelling is typically used for. Inmon's approach is to build a DW first and then use that to populate marts. A DW typically uses a Normal Form rather than dimensional approach.

In general in my experience (and as recommended by Bill Inmon) the most successful way to build a data warehouse is a Normal Form design (I suggest at least Boyce Codd / 5th Normal Form). "Dimensional" modelling approaches can work acceptably for simple models with a few dimensions. You could use a dimensional approach to build a large enterprise warehouse but almost by definition it makes the model and the load process much more complex than they need to be. Large dimensional models are very difficult to maintain and refactor and cause significant problems and costs due to the large amount of redundant data they create.

Whereas dimensional models were popular 10 years ago it's fair to say that they are much less so today because its drawbacks are much more apparent and relevant today than they were in the past. My suggestion would be that you consider a Normal Form approach rather than a dimensional one for your DW.

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.


Author Comment

ID: 35082579
thanks dportas

>>I suggest at least Boyce Codd / 5th Normal Form

isn't that the max?

>>My suggestion would be that you consider a Normal Form

so that would be like OLTP method, right?
LVL 22

Assisted Solution

dportas earned 425 total points
ID: 35197221
>> isn't that the max?
5NF eliminates all join dependencies except those implied by superkeys. 6NF and DKNF are somewhat "stricter" though they are less commonly applied.

>> so that would be like OLTP method, right?
Normal Form is a good guiding principle for any type of database workload, yes.

Author Comment

ID: 35204013
Thanks for clarifying that, dportas.

what is a dependable reference you use for Bill Inmon method of normal form design?
LVL 22

Assisted Solution

dportas earned 425 total points
ID: 35204640
Normal Form wasn't invented by Inmon and isn't really a topic in his books but take a look at:


Author Comment

ID: 35206555
helped - thanks very much!

Featured Post

The Eight Noble Truths of Backup and Recovery

How can IT departments tackle the challenges of a Big Data world? This white paper provides a roadmap to success and helps companies ensure that all their data is safe and secure, no matter if it resides on-premise with physical or virtual machines or in the cloud.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

JSON is being used more and more, besides XML, and you surely wanted to parse the data out into SQL instead of doing it in some Javascript. The below function in SQL Server can do the job for you, returning a quick table with the parsed data.
When table data gets too large to manage or queries take too long to execute the solution is often to buy bigger hardware or assign more CPUs and memory resources to the machine to solve the problem. However, the best, cheapest and most effective so…
Using examples as well as descriptions, and references to Books Online, show the documentation available for datatypes, explain the available data types and show how data can be passed into and out of variables.
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

808 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question