数据仓库模型方法

Question

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

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

模型1->

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

，然后可以根据具有遇到特定字段的遇到类型来构建其他表： Encounter_Emergency（紧急情况特定字段，例如紧急情况诊断，分类类别等） 遇到住院 遇到门诊病人

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

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

模型3->

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

view_Encounter_Emergency view_Encounter_Inpatient view_Encounter_outpatient

这些视图可以进一步与Emergency_diagnosis表组合以获取诊断信息，或将Emergency_alerts表用于访问警报等。

Answer 1

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

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

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

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

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