[dba-SQLServer] AdventureWorks->AdventureWorksDW

Arthur,

dimCustomer is a dimension table which is highly denormalized, or should be.
The idea is to keep it to what is called a star schema. This means that there
should be on a single kep to link the different aspects to the fact table. The
fact table is what holds the additive data, data which can 99% of the time
be added, subtracted, multiplied or divided. If you, for instance, do not
store the address information in the customer dimension, and then link to
the customer address table to get it, it is called snowflaking. Snowflaking
will significantly reduce the performance on a data warehouse.

I have not dealt with the cube type data mart (MOLAP). I have only dealt
with star schema type (ROLAP).

At 12:00 PM 7/4/2008, you wrote:
>Date: Fri, 4 Jul 2008 08:28:11 -0300
>From: "Arthur Fuller" <fuller.artful at gmail.com>
>Subject: [dba-SQLServer] AdventureWorks->AdventureWorksDW
>To: "Discussion concerning MS SQL Server"
>         <dba-sqlserver at databaseadvisors.com>
>Message-ID:
>         <29f585dd0807040428t26f840d1g8840ce16ab36ac11 at mail.gmail.com>
>Content-Type: text/plain; charset=ISO-8859-1
>
>I have failed to discover in the docs exactly how AdventureWorksDW was
>created from the original source AdventureWorks, such as how and why various
>decisions were made. For example, DimCustomer. Should one create a view to
>denormalize all the attendant lookups and then use that as one of the data
>sources? And even more basically, given your basic OLTP db (call it a), what
>steps do you execute to create your OLAP db (call it b)? I understand some
>of what to do once I get from a to b, I'm just unsteady on how to get from a
>to b.
>
>TIA,
>Arthur