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