Search results for query: *

I really have to disagree with you about Kimball's later writings. I have not read the first Data Warehouse Toolkit but the 2nd edition thoroughly, in parts. On page 60 (2nd ed) on the subject "Surrogate Keys" he strongly advocates the use of surrogate keys for the Date dimension too. "...

I'm on SQL Server 2000 and I'm about to update two columns on a large (tall and wide) table in my DW. The tables look like this. DW_INVOICE(TRANS_ID,INVOICE_DATE,AMOUNT,etc) 100 milj rows, 15 GB data DW_INVOICE_CARD(TRANS_ID,DISCOUNT_PERC,DISCOUNT_AMOUNT,etc) 97 milj rows, 23 GB data The...

I've browsed through the "Toolkit" and ofcourse, you're right. My experience told me differently but that says more about those old systems than what's right and recommended. I've performed a really simple but hopefully accurate test on the two datatypes (int and smalldatetime). For the integer...

Yes, I mean that I'd build an aggregated fact table on the day level. In the normalized layer I'd keep the smallest granularity, of course. I could create a FK DATE_ID that points to the corresponding DATE_DIM in the norm layer. This would probably make the ETL to the mart much smoother. But the...

Thank you guys. Actually there is a need for a 15-minute granularity but my guess is that it'll be on just a few fact tables and most will be on the day level. I'll surrogate that dimension. I'm still not sure what to use for my Day level Time Dimension. John suggests an integer with built in...

Hi all, I'm about to design a Time/Date Dimension (on Day level) for a customer and I'm convinced of doing it the Kimball way is as close as perfect you could get (ie creating a spreadsheet as source). Roughly. I'm not convinced that the use of a surrogate key is the best choice. In Kimball's...