[AccessD] Primary Key Best Practices

Sure...

A fact table is, 99.9% of the time, something that is additive. In
other words, math of some type will or has been done to it. For
example sales of products by customer. The PK would be the
sales date, customer key and product key. The dimensions would
be the date dimension, customers, and products. A dimension table
is totally denormalized. all the data math has already been done
on the date in a date dimension table. The day, year, month, etc.
are all separate columns.  In the customer, all of the addresses,
phones, email, etc are included. In the products, all of the vendor
information would be included. No joins past the dimension itself.
If there are, they are called snowflakes and they usually severely
affect the performance of teh mart/warehouse.

Robert

At 03:18 PM 7/26/2007, you wrote:
>Date: Thu, 26 Jul 2007 14:21:44 -0400
>From: "jwcolby" <jwcolby at colbyconsulting.com>
>Subject: Re: [AccessD] Primary Key Best Practices
>To: "'Access Developers discussion and problem solving'"
>         <accessd at databaseadvisors.com>
>Message-ID: <20070726182158.B2C0CBCDD at smtp-auth.no-ip.com>
>Content-Type: text/plain;       charset="us-ascii"
>
>Robert,
>
>I know nothing about data warehouses.  Would you define fact table and
>explain why the PK is a natural key?  I assume that it has to do with speed
>but beyond that could you explain the concepts a little?
>
>I am just looking to learn something here about a subject I know nothing
>about.
>
>John W. Colby
>Colby Consulting
>www.ColbyConsulting.com