Using aliases for date columns in a dimension table to associate them with specific date columns in a fact table is not the recommended approach. It can lead to confusion and make the data model less intuitive and maintainable. It's advisable to establish proper relationships between the fact table and the date dimension table using appropriate keys or foreign key relationships for each date column. This ensures data integrity and allows for easier analysis and reporting.
Miguel_Blanton Thank you for your response, but since Sisense allows only a single association from a dimension table column to a fact table, I fail to see how "appropriate keys or foreign key relationships for each date column" is possible without providing an example. Otherwise, your statement, "It [aliased columns] can lead to confusion and make the data model less intuitive and maintainable." sounds like unsubstantiated opinion.
I'm looking for a demonstration of why my approach might fail to achieve the desired results, and if so, an example of an alternative approach. Inflating a fact table by the number of columns to be associated with a column in a dimension table, or creating multiple copies of a fact table, one for each type of the column to be associated with the column in the dimension table, seems highly inefficient to me and did not work when I tried it.
The only other option I can think of is to treat each date type in a fact table as requiring a separate dimension and duplicate the dimension table. In my original example, this would be DimQuoteDate, DimOrderDate, DimShipDate and DimInvoiceDate.
