我们正在构建健康数据仓库。并且一直在讨论数据仓库的基本结构。我需要您对以下结构的优缺点提出建议。 DWH 将用于报告和研究目的。它将是一个近乎实时的数据仓库，延迟时间约为 5-10 分钟。
源数据库有一个 Encounter/visit 表。一切都保存在这张表中。它是链接一切的中央表。因此，如果我需要在生产数据库中获取患者的行程，我只需转到会诊/就诊表，看看患者前来治疗/入院或从急诊室返回，从急诊室入院的次数等等
模型 1 ->
具有公共(public)字段(如 encounter_id、arrival_date、care_type 等)的 Encounter/visit 表
然后可以根据遇到特定字段的遇到类型构建更多表: Encounter_Emergency(紧急特定领域，如紧急诊断、分流类别等) 遭遇_住院 遇到_门诊
模型 2 -> 将单独的表作为基表，然后在顶部创建一个 View ，然后将所有遭遇类型放在一起。
Encounter_Emergency(紧急特定领域，如紧急诊断、分诊类别等) 遭遇_住院 遇到_门诊
模型 3 ->
以所有字段为源数据库的遇到/访问表 并根据遇到特定字段的遇到类型创建 View :
view_Encounter_Emergency 查看_遭遇_住院 查看_遭遇_门诊
这些 View 可以进一步与 emergency_diagnosis 表结合以获得诊断或 emergency_alerts 表以访问警报等。
最佳答案
首要考虑的是遭遇战类型增加、删除或更改的频率。
模型 B 将需要在任何此类更改之前进行大量返工，以确保继续捕获数据。其他两个模型中的任何一个都将继续捕获重新分类的数据，但需要返工才能报告。
在A和C之间，问题就变成了流量。 View 相对容易向上/向下旋转，但它们会给那个大的基表带来负载。如果 DW 上没有大量负载，这可能是可以接受的。但是，如果会有广泛的报告(专业提示总是比企业告诉您的报告更广泛)，将数据分解为更有利独立的 table 。
当然，维护所有这些表会产生 ETL 开销。
为了交付速度，也许构建模型 C，但构建模型 A 以防消费需要更强大的模型。作为记录，您可以构建没有任何类型的 vw_ 前缀的 View ，或者在名称中没有任何其他标识符，让用户知道它们是 View 。然后，稍后，您可以用同名表替换它们，针对旧 View 的遗留查询将继续工作。我在相反的方向做了同样的事情，潜入 View 以替换多余的表。
关于sql - 数据仓库模型方法，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52659251/