Comments on: Dimensional Modeling: Loading The Slowly Changing Dimension http://blog.todmeansfox.com/2007/11/20/dimensional-modeling-loading-the-slowly-changing-dimension/ Business Intelligence, Data Warehousing, SQL, Visual FoxPro. Tue, 06 Jan 2009 07:33:12 +0000 http://wordpress.org/?v=2.2 By: Tod McKenna http://blog.todmeansfox.com/2007/11/20/dimensional-modeling-loading-the-slowly-changing-dimension/#comment-4977 Tod McKenna Thu, 04 Sep 2008 03:40:57 +0000 http://blog.todmeansfox.com/2007/11/20/dimensional-modeling-loading-the-slowly-changing-dimension/#comment-4977 Hi Chris, I once had a similar problem to solve. I had just developed my first dimensional model and loved the way the Date Dimension worked. When I started programming again in our OLTP environment I noticed that to get the same functionality on reports, screens, and in queries, my users and developers were using date and time functions. All we stored in the database was a datetime stamp or just simply a date value as in 12/15/2007. To make matters more complex, we had some mySQL and SQL Server Databases together with Visual FoxPro -- all of which had subtle differences in the way they handle dates. I solved the problem by introducing a Date Dimension (an exact replica of the one in the data warehouse) into the OLTP systems. So in the end, 4 OLTP systems and the data warehouse all shared the same Date Dimension. For distribution reasons, a copy of the date dimension was shipped with the product, while the master copy was maintained in the ETL environment. The only other change I ended up making was to use the ISO date as an integer in my OLTP systems instead of using the database's date or datetime data type. This allowed for a much more consistent way of accessing the date dimension in the different environments. It was a lot of work to make this change, though... a bit painful at times! But it was well worth it. Now, all dates in all systems are stored as an integer like 20071215. So, to answer your question, I think its a great idea! Hi Chris,

I once had a similar problem to solve. I had just developed my first dimensional model and loved the way the Date Dimension worked. When I started programming again in our OLTP environment I noticed that to get the same functionality on reports, screens, and in queries, my users and developers were using date and time functions. All we stored in the database was a datetime stamp or just simply a date value as in 12/15/2007.

To make matters more complex, we had some mySQL and SQL Server Databases together with Visual FoxPro — all of which had subtle differences in the way they handle dates.

I solved the problem by introducing a Date Dimension (an exact replica of the one in the data warehouse) into the OLTP systems. So in the end, 4 OLTP systems and the data warehouse all shared the same Date Dimension. For distribution reasons, a copy of the date dimension was shipped with the product, while the master copy was maintained in the ETL environment.

The only other change I ended up making was to use the ISO date as an integer in my OLTP systems instead of using the database’s date or datetime data type. This allowed for a much more consistent way of accessing the date dimension in the different environments. It was a lot of work to make this change, though… a bit painful at times! But it was well worth it. Now, all dates in all systems are stored as an integer like 20071215.

So, to answer your question, I think its a great idea!

]]> By: Chris Woodard http://blog.todmeansfox.com/2007/11/20/dimensional-modeling-loading-the-slowly-changing-dimension/#comment-4912 Chris Woodard Wed, 03 Sep 2008 02:44:00 +0000 http://blog.todmeansfox.com/2007/11/20/dimensional-modeling-loading-the-slowly-changing-dimension/#comment-4912 I am working on a data governance project with a team who bring a range of experience to the table. We are currently developing some standard logical data models, one of which is for representing Time. The goal is to represent time consistently when captured in source OLTP databases so that warehouse type, generally dimensional, BI environments can reliably aggregate and compare (at least as regards dates) data from disparate sources within the enterprise. I am coming to the conclusion that we may as well model Time logically in a relational way that 3NF oriented team members are comfortable with, but create the physical model for the Time, actually Calendar Day, dimension table as it will be used in the warehousing environments. So the physical model would be very denormalized, more or less one table with a row for each day, including robust attributes such as Month Number or Week In Year Number. What do you think of the idea of using a replica of the actual Calendar Day dimension table as a reference table for OLTP databases, with business data tables representing dates using the Calendar Day Surrogate Key as a foreign key? Thanks, Chris. I am working on a data governance project with a team who bring a range of experience to the table. We are currently developing some standard logical data models, one of which is for representing Time.

The goal is to represent time consistently when captured in source OLTP databases so that warehouse type, generally dimensional, BI environments can reliably aggregate and compare (at least as regards dates) data from disparate sources within the enterprise.

I am coming to the conclusion that we may as well model Time logically in a relational way that 3NF oriented team members are comfortable with, but create the physical model for the Time, actually Calendar Day, dimension table as it will be used in the warehousing environments. So the physical model would be very denormalized, more or less one table with a row for each day, including robust attributes such as Month Number or Week In Year Number.

What do you think of the idea of using a replica of the actual Calendar Day dimension table as a reference table for OLTP databases, with business data tables representing dates using the Calendar Day Surrogate Key as a foreign key?

Thanks, Chris.

]]>