sql - 数据仓库模型方法

我们正在建立健康数据仓库。并一直在讨论数据仓库的基本结构。我需要您对以下结构的利弊提出建议。 DWH将用于报告和研究目的。这将是一个接近实时的数据仓库，延迟时间约为5-10分钟。

源数据库有一个“遇到/访问”表。一切都保存在此表中。这是链接所有内容的中央表。因此，如果我需要在生产数据库中获取患者的旅程，则只需转到“相遇/访问”表，查看患者接受治疗的次数/已被接纳或已从紧急情况中退回，已从紧急情况中被接纳等等

模型1->

包含公共字段（例如遭遇ID，到达日期，护理类型等）的访问/访问表

然后可以根据遇到类型，使用遇到特定字段构建更多表：
Encounter_Emergency（紧急特定字段，例如紧急诊断，分类类别等）
遇到住院
遇到门诊病人

模型2->
将单独的表作为基础表，然后在顶部创建一个视图，然后将所有遭遇类型包括在内。

Encounter_Emergency（紧急情况特定字段，例如紧急情况诊断，分类类别等）
遇到住院
遇到门诊病人

模型3->

具有所有字段作为源数据库的遭遇/访问表
和视图是根据遇到类型创建的，具有遇到特定字段：

view_Encounter_Emergency
view_Encounter_Inpatient
view_Encounter_门诊病人

这些视图可以进一步与Emergency_diagnosis表组合以获取诊断，或者可以通过Emergency_alerts表访问警报等。

最佳答案

首先要考虑的是遇到类型的添加，删除或更改的频率。

为了确保继续捕获数据，模型B将需要在进行任何此类更改之前进行大量的返工。其他两个模型中的任何一个都将继续捕获重新分类的数据，但是将需要重新工作以对其进行报告。

在A和C之间，问题变成了流量。相对来说，视图的上/下旋转比较容易，但是它们会将负载加到这个大的基表上。如果DW上没有大量负载，那可能是可以接受的。但是，如果会有大量的报告（专业提示中总是存在比企业告诉您的报告还要多的报告），那么将数据分解为独立的表可能会更有利。

当然，维护所有这些表都有ETL开销。

为了提高交付速度，也许可以构建模型C，但为构建模型A，以防万一消耗需要更强大的模型。作为记录，您可以构建不带有任何vw_前缀或名称中没有任何其他标识符的视图，以使用户知道他们是视图。然后，以后可以用相同名称的表替换它们，并且针对旧视图的旧查询将继续起作用。我在相反的方向上做了同样的事情，潜入视图中以替换冗余表。

关于sql - 数据仓库模型方法，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/52659251/