甲骨文pseduo-事实“视图

假设：甲骨文pseduo-事实“视图

我有许多由事实和外键（“三维”和“键值”类型）的表。例如，遇到的问题：

ID - 主键

尺寸

LOCATION_ID
PATIENT_ID

键值

TYPE_ID
STATUS_ID
PATIENT_CLASS_ID
DISPOSITION_ID
...

事实

ADMISSION_DATE
DISCHARGE_DATE
...
1. 我没有创建一个数据仓库中的选项
2. 我想简化报告

的数据结构我的方法是创建一些伪维度视图（基于DEPARTMENT和LOCATION表的'D_LOCATION'）和伪事实视图（基于ENCOUNTER表的'F_ENCOUNTER'）。在伪事实视图中，我会将键值表（例如STATUS，PATIENT_CLASS）加入事实表以包含名称字段（例如STATUS.NAME，PATIENT_CLASS.NAME）。

问题：

如果查询选择所有字段的自F_ENCOUNTER（即不是所有的key-value.name字段）的一个子集，是Oracle 10g中优化聪明地排除一些键值表连接（即未包含在查询中的连接）？
有什么我可以做的，以优化这个架构（除了索引）
有没有其他的方法？

**编辑** 目标（按重要性排序）：

减少查询的复杂性;增加查询一致性;减少报告的开发时间
优化查询处理
减少管理员的负担
减少存储

来源

2011-05-13 craig

一种优化的建议是不要使用键值对表。 Dimension表的概念是每个记录都应该包含关于该概念的所有信息，而不需要连接到标准化表 - 即将星型模式转换为雪花模式。

虽然值可能会在维度表记录中重复，但它具有报告查询中连接数较少的优势。以这种方式非规范化表格可能看起来不直观，但在性能至关重要的情况下，它通常是最佳解决方案。

来源

2011-05-13 13:14:38 Datajam

我觉得有个同事把这称为'垃圾'维度。它被保留给低基数的字段。这当然是有道理的。不幸的是，这个客户对数据仓库没有兴趣。我想我可以创建一个视图，以这种方式去规范化数据，然后实现它（每天）。称它为F_ENCOUNTER_JUNK。 – craig 2011-05-13 13:20:44

不，垃圾尺寸用于组合几个不需要自己的表的不同想法（它本身最终可能是一个键值表）。它通常被命名为通用名称，如STANDARD_VALUES。像患者和LOCATION这样的维度本身就是合法的维度。 – Datajam 2011-05-13 13:41:01

我不相信Oracle会排除视图中的任何连接，因为连接会影响返回的行数。（当内连接不能匹配任何行时，会使整个结果集为空。）
优化的目标是什么？查询速度？查询简单？存储效率？如果您可以牺牲存储效率以获得更好的查询性能，请将键值引用替换为值本身（TYPE_NAME而不是TYPE_ID，PATIENT_CLASS_NAME而不是PATIENT_CLASS_ID等）。
[编辑：]如果原始架构无法修改，请考虑使用物化视图。它本质上是预先计算连接并存储结果集，以额外的存储空间和可能不新鲜的数据为代价提供快速的查询时间。您可以通过指定适当的刷新策略来控制后者。进一步的细节见http://en.wikipedia.org/wiki/Materialized_view和http://download.oracle.com/docs/cd/B10500_01/server.920/a96520/mv.htm。

来源

2011-05-13 13:17:40 Alanyst

我不明白你的第二点。在视图中，我将如何'用值本身替换键值引用'？或者你在建议一张桌子？ – craig 2011-05-13 13:50:12

我的意思是用实际值替换ENCOUNTER表中的键值ID，这样ENCOUNTER将包含诸如TYPE_NAME，PATIENT_CLASS_NAME等的列。它可能会增加表的存储需求，但不需要加入键值表。 – Alanyst 2011-05-13 15:03:00

DBA不太可能愿意这样做，因为所讨论的表是供应商的标准表之一。我知道我可以创建一个自定义存储库，但我不想增加ETL负担。 – craig 2011-05-13 16:50:16

甲骨文pseduo-事实“视图

回答

相关问题