我的问题是，我有一个 Dimensional Model DB NFL 联赛。因此，我们将“球员”、“球队”、“联赛”作为维度表，将“比赛”作为关联这些表的事实表。例如，如果我需要查询特定比赛或一系列比赛中某位球员的统计数据，则需要使用大量连接将机器可读的基于 ID 的表转换为人类可读的基于名称的版本，这是非常艰苦的 SQL 查询。另外，对这些数据的分析也是非常痛苦的。为了成为一个解决方案，我建议将该数据库转换为分析友好版本。再次举例，球员表将包括每行的球员以及相关统计数据，球队也同样如此。
问题是，是否有任何框架、方法或模式可以指导我设计分析友好的数据库布局。另外，使用 SQL 还是有利的，还是任何非 SQL 数据库更适合解决这个问题？
我知道这听起来很普遍，但我只是想听听有关该主题的一些专业知识。因此，非常欢迎任何帮助、建议。
最佳答案
大约 13 年前，我所在的团队面临着类似的情况。我们使用了名为“PowerPlay”的工具，这是 Cognos 的商业智能工具。这个工具对数据分析师非常友好，具有向下钻取功能和各种基于名称的搜索。
如果我没记错的话(已经有一段时间了)，BI 工具以其自己的格式(数据立方体)存储数据，但它有自己的工具来自动发现基于 SQL 的数据源的结构。该自动工具确实在处理 OLTP 数据库时遇到了困难，该数据库是 SQL (Oracle)，而且真是一团糟……糟糕的关系设计。
所以我最终做的是构建一个星型模式来收集和组织相同的数据，但与数据的多维 View 更兼容。然后，我构建了 ETL 内容以从 OLTP 数据库加载星号。 BI 工具就像热刀切黄油一样切入星型模式。 而且分析师根本不必搞乱 ID 字段。
听起来你的起点就像我必须构建的星型模式。因此，我建议您可以在您的明星之上使用一些 BI 工具，这将准确地提供您正在寻找的分析师友好的环境。 Cognos 只是众多 BI 工具供应商之一。
一些注意事项:如果您采用这种方式，则必须努力确保您的名称字段“有意义”，以便为尝试深入或搜索的分析师提供有意义的指导。有时，原始数据源将名称字段视为或多或少毫无意义的东西，其中错误并不重要。列名称也是如此。 DBA 喜欢的列名称对于数据分析师来说通常是胡言乱语。您可能还必须展平维度表中的任何层次结构分组，但您可能已经这样做了。这取决于您的 BI 工具需要什么。
希望这会有所帮助，即使它有点通用。
关于mysql - 如何将维度数据库模型转换为数据挖掘友好的布局？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25783781/