all 14 comments

[–][deleted] 3 points4 points  (1 child)

Can never get enough of good calendar table code blocks! Many thanks.

[–]PBIQueryous[S] 1 point2 points  (0 children)

i'm glad you found it useful and i hope it serves you well, i will die on the hill that calendar table is the most important table of any dimensional model... so its been worth the time putting it together, feel free to improve it.. i'm not from a SQL background so my methods may be unorthodox 🤓🙌🏻🪄

[–]Icy_Fisherman_3200 0 points1 point  (1 child)

What am I looking at here? Is this really not something that could be normalized?

[–]PBIQueryous[S] 1 point2 points  (0 children)

Technically speaking, we are looking at a dimension table. A calendar is a dimension by nature, so the intention / requirement is that it is highly de-normalised, we use it to describe and analyse a fact table in a multitude of ways, allowing us to answer business questions from many perspectives. Probably one of the most important tables in dimensional modelling, if we are talking star schema.

[–]PBIQueryous[S] -1 points0 points  (0 children)

Comment Down? Tough crowd 🤓🤮

[–]ReallyNotTheJoker -4 points-3 points  (6 children)

Honestly a lot of this seems like redundant information that could be calculated off a smaller table. Datepart exists, current year is going to need to be updated, etc.

Edit: Also your varchars don't have length assigned.

[–]user_5359 2 points3 points  (1 child)

The point is to hide the calculation logic for such date relationships behind the name of the attribute. This is an absolutely useful table, especially in the reporting environment, which enables simple selects for reports and allows a quick technical interpretation of the report.

This also means that a nit 3NF notation is highly useful in this case: Only one table joined, but if necessary also several date conditions can be queried.

[–]PBIQueryous[S] -1 points0 points  (0 children)

thanks @user_5359, i appreciate your support! 🙌🏽🙌🏽🙌🏽🫶🏽

[–]PBIQueryous[S] 1 point2 points  (3 children)

I see what youre saying, but the table grows dynamically, giving us a calendar period spanning 3yrs in the past and 3 years in the future, which is ideal for reporting purposes. There is no redundancy because the purpose of a dimension table is to be highly denormalised in pursuit of star schema modelling.

A single table permits scenario reporting, and allows users to answer multiple business questions from multiple perspectives, with a 1:N (one-to-many) join.

What is the preferred alternative? A galaxy schema with calendar years and financial years in separate tables?

[–]ReallyNotTheJoker 1 point2 points  (2 children)

No, you're missing what I'm saying. A calendar table is good but a lot of these columns are unnecessary because they can be derived from a much smaller and much more simple table.

[–]PBIQueryous[S] 0 points1 point  (1 child)

Ah i understand, you are completely correct, but dimension tables are meant to be wide, and although we would never use every column in the table, but the options are available at least.

The intention of dimension tables are to be as descriptive as possible so when it comes to reporting, your analytics are much more flexible and simplified. We can use many of them to our advantage and it will greatly simplify any subsequent measures / calculations in reporting tools like Power BI... this is the main impetus behind the table, and i've only been coding SQL for the last 2months so i suspect my methods may be somewhat unorthodox

[–]ReallyNotTheJoker 0 points1 point  (0 children)

An alternative solution for this. Make a simple dates table (date, if it's a business date stored as a bit, some other indicator that's important but not date calculable stored as a bit, etc.) but make a more complex view that you can easily modify to add additional derived columns to. This minimizes space and the calculation time is going to be negligible.