Every TY (this year's) day, week, period or quarter, has a corresponding LY (last year) day, week, period or quarter. This implicit mapping is straightforward for 52-week years. The acid test, however, is in handling 53-week years.
There are two common approaches for defining the TY-LY relationship:
The TY and LY have the same day number (1-371) and week number (1-53.) Higher levels, i.e. periods and quarters, are made up of the same days and weeks following a 4-4-5 pattern, so any TY day belongs to the same period as its corresponding LY day. The only oddity is that we have to skip the 53d week in year-to-year comparisons.
The following configuration is based on these general guidelines. It covers data partition nodes, coordinator/administration node, application server and spare. We propose initially to configure all nodes as production data servers for flexibility and expandability. QA and Test nodes can be built with higher density and less I/O bandwidth per core. The following diagram captures the data path components, unit rates and relationships driving their configuration selections and sizing.
VDM recognizes three types of dimensions from the perspective of their behavior as hierarchies:
These dimensions are usually modeled as a single entity. They carry an identifier and basic descriptive attributes, such as a name and description. They potentially may have additional attributes that can be used to aggregate facts. As an example, take a Geo-location dimension, which may have Zip-Code as an attribute. We may aggregate and report sales by zip-code and retain summaries with zip as one of the aggregate dimensions.
The original article was published in the October/November 1992 issue of the Relational Journal, and proposed a way to effectively make ancestor-descendent searches in hierarchies working around relational database limitations, i.e. the lack of recursion capability. Since then variants on the technique appeared at trade journals and books. An excellent explanation is included in the "SQL for Smarties" by J. Celco as well as his more recent "Trees and Hierarchies in SQL fr Smarties".
The dimension of time is such a core and critical concept in dimensional design and analytics that sometimes we forget some of the subtleties and nuances involved. Since practically every large table in the data warehouse contains a reference to the time dimension, any time or calendar change may have substantial repercussions. Here are the things to consider:
Most business applications require daily grain. There are often requirements that involve time-of-day grain, but before you decide to build a time dimension at the hour or minute level consider the problem and its implications carefully.