DW可以接受left join吗？
DW acceptable left join?
在一份报告中，我有来自 FACT 的下一个连接 table：
加入…
LEFT JOIN DimState AS s
ON s.StateCode = l.Province AND l.Locale LIKE (s.CountryCode + '%')
更多信息：
事实 table 有 59,567,773 行
L.Province 可以匹配 DimState 中的一个 StateCode：42,346,471 行 71%
L.Province无法匹配DimState中的一个StateCode：13,742,966行23%（其中大部分是L.Province中的空白值）
L.Province 在 3,500,000 行中为 NULL (6%)
4个问题：
- 正确的做法是将 L.Province 空值和空白替换为“other”……并在 DimState 中有一个条目，StateCode 为“other”，对吗？
-是否接受table LEFT JOIN 到维度？或者它应该始终是 INNER JOIN？
-连接到 2 列上的维度是否正确？
-做一个l.Locale = s.CountryCode...我应该修改l.Locale中的值还是s.CountryCode中的值？
按照你的四个问题的顺序：
是的，您的事实 table 中不应有维度键的空白。如果源数据中的值实际上为 null 或空，则您的维度 table 中应该有成员被预留以反映这一点。
因此，从 1 开始，在将事实连接到维度时，通常不应该进行左连接。我说一般是因为在某些情况下可能有必要这样做，但我想不出任何事情。您不必使用正确设计的事实和维度 tables.
一般不会。我建议在这种情况下使用代理键，因为您的业务键分布在两列中。
不确定你在这里问什么。如果保留此设计，则需要更改两者。如果您切换为使用 DimState 的代理键，则只需在任何更改时更新维度 table。
- 不要这样做出于一个简单的原因。您将在维度 table 中获得带有键
L.Province = 'Other' 的 1300 万条记录 - 来自事实 table 和 s.StateCode = 'Other' 的每条记录将与那些 1300 万条维度记录相结合，从而导致大量重复措施。
正确的答案是在您的维度上强制执行主键。通常，一个维度有 一个记录，键为 other（意味着键未知），可能还有另一个记录 NA（该维度在 for这个事实记录）。
问题不在 OUTER join- 设计应该强制执行的是 fact table 中的所有外键都在维度 table.
实现这一目标的一个步骤是定义 NA 和 Other，如 1.
中所述
这种方法背后的基本原理是强制 INNER 和 OUTER 连接导致相同的结果，即不要混淆不同的结果。
- 同样，每个维度都应该定义一个
PRIMARY KEY - 如果 PK 由两列组成 - 这些列上的连接没问题。 （虽然 DWh 中的典型场景是单列数字 PK）。
应避免在 LIKE 或 SUBSTR 上加入 - 这表明维度 PK 未明确定义。
- 如果您的维度有两列 PK
Locale + province 事实 table 必须更新以包含这两列作为 FK。
以 mallan1121 所说的为基础：
1:null/blank在数据仓库中一般有三种不同的含义。
一个。我不知道值
乙。该值已知且为空白
C。该值不适用。
确保在设计仓库时考虑每个选项的相关性。事实应该始终引用维度键，否则您最终会遇到数据质量问题。
2：如果您使用视图从多维数据集中抽象表（一个好主意），并且您可以将这些视图用于非多维数据集报告，则使用左联接可能很有用。原因是内连接是过滤连接，即使只返回一列，结果集也会被所有内连接表过滤。
SELECT DimA.COLUMN, Fact.COLUMN
FROM Fact
JOIN DimA
JOIN DimB --filters result
JOIN DimC --filters result
如果您使用左联接并且您只需要一些表中的列，则其他联接将被忽略并且永远不会访问这些表。
SELECT DimA.COLUMN, Fact.COLUMN
FROM Fact
LEFT JOIN DimA
LEFT JOIN DimB --ignored
LEFT JOIN DimC --ignored
这可以加快直接针对 SQL 数据库的报告查询 运行。但是，您必须确保您的 ETL 过程强制执行完整性，并且无论使用内部联接还是左联接，返回的结果都是相同的。
4：在连接中要求多列不是问题，但我会非常担心使用通配符的多列连接。我希望您的维度存在粒度问题。我不知道您的数据，但使用通配符可能会从该维度返回多个值。
在一份报告中，我有来自 FACT 的下一个连接 table：
加入…
LEFT JOIN DimState AS s
ON s.StateCode = l.Province AND l.Locale LIKE (s.CountryCode + '%')
更多信息： 事实 table 有 59,567,773 行
L.Province 可以匹配 DimState 中的一个 StateCode：42,346,471 行 71%
L.Province无法匹配DimState中的一个StateCode：13,742,966行23%（其中大部分是L.Province中的空白值）
L.Province 在 3,500,000 行中为 NULL (6%)
4个问题： - 正确的做法是将 L.Province 空值和空白替换为“other”……并在 DimState 中有一个条目，StateCode 为“other”，对吗？
-是否接受table LEFT JOIN 到维度？或者它应该始终是 INNER JOIN？
-连接到 2 列上的维度是否正确？
-做一个l.Locale = s.CountryCode...我应该修改l.Locale中的值还是s.CountryCode中的值？
按照你的四个问题的顺序：
是的，您的事实 table 中不应有维度键的空白。如果源数据中的值实际上为 null 或空，则您的维度 table 中应该有成员被预留以反映这一点。
因此，从 1 开始，在将事实连接到维度时，通常不应该进行左连接。我说一般是因为在某些情况下可能有必要这样做，但我想不出任何事情。您不必使用正确设计的事实和维度 tables.
一般不会。我建议在这种情况下使用代理键，因为您的业务键分布在两列中。
不确定你在这里问什么。如果保留此设计，则需要更改两者。如果您切换为使用 DimState 的代理键，则只需在任何更改时更新维度 table。
- 不要这样做出于一个简单的原因。您将在维度 table 中获得带有键
L.Province = 'Other'的 1300 万条记录 - 来自事实 table 和s.StateCode = 'Other'的每条记录将与那些 1300 万条维度记录相结合，从而导致大量重复措施。
正确的答案是在您的维度上强制执行主键。通常，一个维度有 一个记录，键为 other（意味着键未知），可能还有另一个记录 NA（该维度在 for这个事实记录）。
问题不在
OUTER join- 设计应该强制执行的是 fact table 中的所有外键都在维度 table.实现这一目标的一个步骤是定义
中所述NA和Other，如 1.
这种方法背后的基本原理是强制 INNER 和 OUTER 连接导致相同的结果，即不要混淆不同的结果。
- 同样，每个维度都应该定义一个
PRIMARY KEY- 如果 PK 由两列组成 - 这些列上的连接没问题。 （虽然 DWh 中的典型场景是单列数字 PK）。
应避免在 LIKE 或 SUBSTR 上加入 - 这表明维度 PK 未明确定义。
- 如果您的维度有两列 PK
Locale + province事实 table 必须更新以包含这两列作为 FK。
以 mallan1121 所说的为基础：
1:null/blank在数据仓库中一般有三种不同的含义。
一个。我不知道值
乙。该值已知且为空白
C。该值不适用。
确保在设计仓库时考虑每个选项的相关性。事实应该始终引用维度键，否则您最终会遇到数据质量问题。
2：如果您使用视图从多维数据集中抽象表（一个好主意），并且您可以将这些视图用于非多维数据集报告，则使用左联接可能很有用。原因是内连接是过滤连接，即使只返回一列，结果集也会被所有内连接表过滤。
SELECT DimA.COLUMN, Fact.COLUMN
FROM Fact
JOIN DimA
JOIN DimB --filters result
JOIN DimC --filters result
如果您使用左联接并且您只需要一些表中的列，则其他联接将被忽略并且永远不会访问这些表。
SELECT DimA.COLUMN, Fact.COLUMN
FROM Fact
LEFT JOIN DimA
LEFT JOIN DimB --ignored
LEFT JOIN DimC --ignored
这可以加快直接针对 SQL 数据库的报告查询 运行。但是，您必须确保您的 ETL 过程强制执行完整性，并且无论使用内部联接还是左联接，返回的结果都是相同的。
4：在连接中要求多列不是问题，但我会非常担心使用通配符的多列连接。我希望您的维度存在粒度问题。我不知道您的数据，但使用通配符可能会从该维度返回多个值。