问题标签 [star-schema-datawarehouse]

在数据仓库-维度建模中，Star Schema 是一种什么样的范式？

我目前正在研究一个金融风险数据仓库。对于我的附属维度，我正在对来自一个源系统的数据进行排序。然而，经过业务分析师的进一步研究，我们发现了一个遗留应用程序，它还保存了银行在数据仓库中也需要的抵押信息。除了两个源系统共享的一些共同属性外，遗留应用程序包含的属性比我当前的附带维度中已经定义的属性要多得多。因此，在仓库中加入这些新信息的最佳方式是什么？我正在考虑扩展当前的抵押品维度，但是每次我找到一个新的来源时我都需要这样做，这很可能是考虑到银行的规模。

我新加入了一个组织，我们最近推出了一个包含大量外部系统（CRM 等）的数据仓库解决方案（Snowflake）。有一些用例可以每周手动输入数据（ei 销售目标）。这是我遇到麻烦的一个领域。

在理想的世界中，所有系统都将完美地整合并形成 DW 中的核心数据。

但现实情况是，可能需要保留手动数据输入以创建完整的图片（至少在我们找到长期解决方法之前）。

到目前为止，我一直认为 Excel/Google Sheet 是手动输入到后台服务中的，该服务在登台服务器中填充 DB 表。

这里有没有人有这种情况的经验？数据平台的用户通常如何处理这种情况？以及将手动数据输入数据仓库解决方案的做法？

您可以在此处提供的任何帮助将不胜感激。

我的任务是对 DW 的粗略设计进行建模。主要目的是搜索属性信息和文件，在所述属性上打开的订单。

当涉及到文件（父级事务）和订单时，我正在努力解决结构问题。首先打开文件，然后在这些文件下打开订单。这可以是多对多的关系。我被告知主 Fact 表将是订单，而文件将是退化维度。

但是还有其他表格，例如订单和文件上的缔约方（即业主、房地产经纪人等）OrderParty 和 FileParty，也需要考虑。

关于如何开始这个模型设计的任何想法？

数据仓库设计和星型模式相当新。我们设计了一个事实表，其中存储了有关会员资格的各种度量，我们的粮食是每天的，并且该表中的一些度量是诸如新售出的数量、更新的售出数量、活跃的数量、取消的数量等。

我的问题是，企业将希望看到其他谷物的措施，如每月、每季度、每年等。所以通常这里的方法只是汇总所需时间段的日级数据，或者你会推荐为我们的业务需求（例如每月、每季度、每年）的“关键”时间段创建单独的事实表？我已经阅读了一些关于此的混合信息，这主要是我寻求其他观点的原因。

我读到的一些信息让人们在事实表中嵌入了一个层次结构来指定不同的粒度，然后通过一个“级别”类型的列来识别，这被很多人反对，对我来说似乎也不好，那些建议反对我们建议每个粒度单独的事实表，但老实说，我不明白为什么我们不只是从我们拥有的每日条目中汇总，除了一些轻微的性能之外，我们将从每个粒度的事实表中获得什么好处也许改进？