我的一位利益相关者最近告诉我，我的数据仓库中添加了一组“通用”表。这些表将与我的一个事实表具有相同的粒度，并且将包含以其数据类型命名的一组列（例如，Int1, String1, Date1, Decimal1, Int2, String2, Date2, Decimal2 ...）。
利益相关者打算在其中一个源系统中拥有一组表，用户可以访问并加载他们想要的任何内容，然后让ETL将其插入动态维度并在SSAS多维数据集中显示给他们，报告，以及他们想要的任何东西。
我已经看过几次这种可扩展的设计，通常是在一些可定制的应用程序的引擎盖下，但是我很想把这样的东西放在我漂亮的整洁仓库里。
我认为这是一个糟糕的设计决定吗？这种方法存在哪些问题/缺陷/缺陷，我可能遇到困难？或者，如果我错了，我没有看到哪些优势？
答案 0 :(得分：2)
短语＆＃34;无论他们想要什么＆＃34;可能意味着许多不同的事情。
它通常意味着数据从未经过彻底的分析，从未被整合到一个统一的整体中。不同的用户可能正在谈论不同的实体和关系，或不同的属性，即使它们都涉及相同的基础主题。
有时候，这是你能做的最好的事情，因为整个数据体没有统一的概念模型，或者它的结构随着时间的推移以不稳定和不可预测的方式发展。其他时候，分析本来是可能的，但从未完成过，只是因为让每个用户做自己的事情更容易。
当一些利益相关者开始希望从这个混乱中可以从统一数据库轻松提供的各种输出（报告和摘录）时，通常会遇到麻烦。那时，整合和协调主要是脱节和偶然的数据的整个工作就在于你和任何有意义的结果。这需要很长时间，需要花费很多钱，而且结果无法提前预测。
但是管理层认为这应该很容易，因为毕竟，数据存在于数据库中，而不是＃34;你会认为可以避免这种错误的期望。在实践中，通常无法避免。
这不是唯一的陷阱，但它是最重要的陷阱。
答案 1 :(得分：0)
这些表原则上是对数据本身的关系模型的错误应用。数据的关系模型是围绕表（表中的行）表示谓词（实例化）的核心思想设计的。表与谓词之间一一对应（这是促进解释所必需的）。
你让你的用户写一个谓词，其中他的int1，date1，...是自由的位置，并且他的谓词总是给出正确的解释＆＃34;无论他最终放入什么＆＃34; 。根据所述目的的定义，这是不可能做到的;并希望将其放入任何令我满意的地方＃34;。
低，这些表是拒绝进行前期数据/信息分析的结果。然而，如果没有这样的分析，就不可能知道事后数据的含义/解释方式。但是，如果你想操纵数据，那么知道数据意味着什么是不可避免的，这就是为什么这往往导致内部平台效应＆＃34; ：需要一些机制来促进管理数据的含义＆＃34;。 RM的设计理念是DBMS将 BE 该机制，但拒绝将DBMS用于其预期目的导致必须以其他方式实现这些目的。