我们的关系数据仓库中的许多事实表都有一个＆＃34; primary＆＃34;日期以及其他日期。我应该如何在数据模型中指出这种优先级，以便在数据模型之上构建的应用程序将引导用户走向＆＃34; primary＆＃34;默认为日期？
例如，在销售事实表中，有一个＆＃34;销售日期＆＃34;作为主要日期的列，但也是＆＃34;录制日期＆＃34;在报道中很少使用。
另一个例子：WarehouseReceiving事实表有一个＆＃34;交货日期＆＃34;主要的列，但也是＆＃34;交易输入日期＆＃34;很少使用。
当有role-playing dimensions时，是否存在如何将一个角色建模为比其他角色更重要的约定？
或者试图将主要角色定义为一个坏主意，因为如果不是自然的＆＃34;主要＆＃34;作用
我们的平台是SQL Server 2014，如果这很重要，但问题是平台中立。
答案 0 :(得分：1)
角色扮演维度中没有“主要”概念。
每个维度和角色都是出于商业原因。在您的情况下，sale_date和delivery_date看起来很重要，但您可能想要质疑recording_date和transaction_entry_date的角色，因为它们可能不会在业务流程中发挥任何作用。
我们假设我们只有sale_date和delivery_date。哪个更重要？都不是。都。这取决于撰写查询的人的观点。
在处理包含多个日期的事实表时，我使用的一种技术是按业务流程中的常规顺序排序日期列。例如，date_ordered位于date_shipped之前，它位于date_invoiced和date_paid之前。将日期列保持在一起并排序，可能有助于使休闲BI用户熟悉数据。
答案 1 :(得分：0)
只要所有日期都明确命名或以其他方式为您的用户确定，我就不明白为什么您需要这样做。如果你从最终用户的角度来看待这一点，他们会认为“同一类型的领域不止一次被列出，所以现在我不知道哪个是主要的“？我怀疑他们会想到更像“我需要在销售发生当天查看销售额......哦，销售日期听起来像我正在寻找的东西。”如果您的名字确实不清楚，那么您可能需要采取进一步措施 - 无论是与用户协议重新命名，进行培训还是设置文档。
无论如何，您确实需要您的用户了解所有维度的含义，而无需使用他们的事实表上下文。假设您将其放入SSAS多维数据集中; Dimensions将独立显示，并可能跨越多个Fact表，因此任何说一个是主要日期的事实可能适用于一个事实而不是另一个事实。并且您可能遇到一个用户最感兴趣的是按销售日期分析数据的情况，但另一个用户最感兴趣的是通过记录日期对其进行分析。那个案子的主要日期是哪一天？
如果您担心自己没有好的方法将数据字段的含义告知用户，请考虑设置数据字典。我没有链接到特定的教程，因为我没有验证任何内容，似乎有不同的方法，但如果你在Google上搜索数据字典SSAS ，你会发现很多建议用于设置多维数据集字段的说明，然后在SSRS报告中显示此信息。如果您不使用SSAS多维数据集作为人们访问数据的主要方式，那么您可能需要做一些不同的事情，但希望这可以让您了解合适的解决方案。
根据您传播数据的方式，您还可以查看哪些字段可供哪些人使用 - 例如，如果他们使用报表生成器或使用SSAS，他们在SQL Server中具有哪些权限？透视图，如果他们使用立方体。我不会这样做，除非你的用户抱怨他们在某种程度上发现了可用维度的数量问题 - 有时如果有很多不相关的字段，它可能会让人感到烦躁和减慢人们（是的，可能导致人们在某些情况下选择了错误的字段），但你不想冒隐藏相关数据的风险。