SQL 数据库模型 - 关系型或雪花型

Question

我正在创建数据模型并需要帮助。我已附加虚拟数据，说明我期望如何接收数据，如下所示。它基本上是不同层次的服务量。

第一个文件具有所有属性的总计和组合，使其独一无二

第二个文件更详细，与文件 1 类似，所有属性的组合使其独一无二，区域分配基本上是文件 1 中服务量的分割。在一段时间内，值会发生变化，有时在季度中经常发生变化并更新在文件 1 中，基于初始分配，文件 2（在数据库中）的金额必须更新。

文件1

服务	服务类别	子组件	方向	YYYYQQ	服务金额
T	T1	是	E	202201	2000
T	T2	N	E	202202	1000
A	T1	是	W	202201	100
A	T3	N	E	202201	200

文件2

服务	服务类别	子组件	方向	服务区	服务代理	服务区域	YYYYQQ	领土分配
T	T1	是	E	SA1	特工1	东方001	202201	1500
T	T1	是	E	SA1	特工2	东002	202201	500

我正在考虑一个雪花模式，其中包含 Territorygrain 和 Date Dim 处的事实，Territory Dim 带有到 ServiceArea Dim 的桥接表，另一个维度结合了文件 1 和桥接表中的数据来链接 ServiceArea。

我不确定这是否是正确的方法，或者我可以构建一个简单的关系数据库模型。预先感谢

Answer 1

如果我正确理解这个例子，

File1

本质上包含来自

File2

的聚合值。因此，导入两者可能没有什么意义，因为您总是可以从后者生成前者，除非出于某种特定原因您想验证文件之间数据的一致性。

对于所有场景，平面文件摄取步骤通常都是相同的。您创建临时表，每个导入的文件一个，其架构与文件的架构相同。这样您就可以使用

bulk insert

或任何其他批量加载机制加载数据，速度尽可能快。

下一步就是差异开始出现的地方。如果您想标准化数据，那么您可以添加下一组表、一些查找（维度）和其他事实。如果，正如你所说，你有跨维度的依赖关系，那么雪花看起来是一个明显的选择，当然。然而，问题是它对数据消费者是否有用。另外，如果您的数据库已经具有部分或全部这些查找，我会尽可能遵循现有模型，除非您想重新设计它并寻找更好的设计。

回答这样的问题的主要困难是您从未指定结果模式应满足的要求。您自己可能并不认识他们。如果您的目标是拥有一个完全标准化的模型，这对大多数人来说意味着BCNF，那么您可以自由地选择您能想到的最精致、最精确的雪花。

另一方面，精确模型很容易定期重新设计，正是因为它们限制太多、不灵活且不太面向未来。因此，当业务环境发生变化并且昨天不可能的事情今天变得正常时，您不仅需要重新设计表，还需要重新设计使用它们的代码（可能还包括 UI）。

您应该在生成的模型中加入多少余地，以及在哪些位置？没有人可以肯定地告诉你，因为“未来......不确定”。不过，主题专家可能会有所帮助。

总而言之：您可以采用任何一种方式，甚至可以采用混合方式，只有您的业务用户可以告诉您在哪些地方可以严格，以及在哪些地方为面向未来留出一些空间可能是有意义的。另请记住，您的数据越标准化，您的查询就会变得越复杂 - 这也可能是一个需要考虑的因素。