标签: slowly-changing-dimension

当使用系统版本控制的时态表（SQL Server 2016 中的新功能）时，当使用此功能处理大型关系数据仓库中的缓慢变化维度时，查询创作和性能影响是什么？

例如，假设我有一个Customer带有Postal Code列的 100,000 行维度和一个Sales带有CustomerID外键列的数十亿行事实表。并假设我想查询“按客户邮政编码划分的 2014 年总销售额”。简化的 DDL 是这样的（为了清楚起见省略了很多列）：

CREATE TABLE Customer
(
    CustomerID int identity (1,1) NOT NULL PRIMARY KEY CLUSTERED, 
    PostalCode varchar(50) NOT NULL,
    SysStartTime datetime2 GENERATED ALWAYS AS ROW START NOT NULL, 
    SysEndTime datetime2 GENERATED ALWAYS AS ROW END NOT NULL,   
    PERIOD FOR SYSTEM_TIME (SysStartTime, SysEndTime) 
)
WITH (SYSTEM_VERSIONING = ON);

CREATE TABLE Sale
(
    SaleId int identity(1,1) NOT NULL PRIMARY KEY CLUSTERED,
    SaleDateTime …

我正在设计一个包含很多行的表。所以需要注意不要存储太多信息。其中一列是 NVARCHAR(MAX) 列，它包含我们客户的地址。由于地址不经常更改，此列将包含许多重复值，因此包含相当多的冗余。

所以我想知道我是否需要通过维护某种查找表来解决字符串来规范化（请注意，如果地址发生变化，我需要维护历史记录 - 所以这不是通常的规范化问题），或者如果 SQL Server指向幕后字符串的相同引用。或者它可能提供了一个列选项来这样做。我想到的另一种方法是使用 COMPRESS，但我想这没有意义，因为数据本身（即地址）不长。

读/写性能不是那么重要，因为数据会随着时间的推移而累积。

我们有以下昏暗和事实：

客户维度：SCD 类型 2，关于客户的信息，即首次购买日期、姓名、地址等 产品维度：SCD 类型 2，关于我们的产品

客户快照事实：有关客户产品销售事实的月度财务事实：客户销售额

并且会有更多涉及客户维度的事实。

我们有一个旧数据库，它正在收集有关客户的 100 个数据字段，并被要求对这些数据进行 DW。有 100 多个字段与客户相关，其中可能是指示客户是否有资格获得某物的标志。用户想要对我们的任何事实表进行的大多数查询可能包括这些指标的过滤和/或分组。

问题是我们是否应该向我们的 Customer Dim 添加 100 多个指标，如果不是，则应如何构建数据，以便将这些信息与我们的所有其他事实结合起来。

谢谢你的帮助。

我构建了一个 SSIS ETL 来将各种数据源（一个来自 MySQL，两个来自 SQL Server）集成到一个单独的 SQL Server 关系和规范化数据库中，我称之为 [NDS]。

SSIS ETL 处理类型 2 更新，因此 [NDS] 生成代理键和 SCD 表包括一个 [_EffectiveFrom] 时间戳和一个可为空的 [_EffectiveTo] 列，并且对链接所有的自然键和漂亮的外键有约束数据一起。

现在，我想用它构建一个 SSAS 维度数据库，没过多久我意识到我正在为雪花模式设置自己：

所以我正在考虑添加一个新的 [DDS]（关系）数据库，以创建实际的维度和事实表，这些表将为 SSAS 数据库提供 DSV。

这个 [DDS] 数据库将尽可能地非规范化，以便“扁平化”事实和维度（例如，[OrderHeaders]+[OrderDetails] 到 [Orders] 事实表，以及 [CustomerStores]+[Customers]+ [SalesReps] 到一些 [Customers] 维度表中） - 这样做不仅应该让我更容易在 SSAS 中构建维度层次结构，还应该更容易提出实际的星型模式。

不过我有几个问题：

• 我可以重用现有代理键的子集吗？我正在考虑采用最细粒度的现有键并将其作为维度键。这是一个好方法，还是我应该忽略 [NDS] 代理键并让 [DDS]（关系数据库）生成一组新的代理键？
• 如何处理SCD？例如，当源系统中的某些特定字段发生变化时，“材料”和“供应商”将在 [NDS] 中生成新记录......我想我必须设计 SSIS ETL 以仅加载“最后一个图像”记录进入 [DDS] 数据库，然后在该过程中重新实现类型 2 更新，即将 [NDS] 视为保留历史记录的“源系统”，同时复制此 [DDS] 数据库中的所有内容。但是，为什么我需要在 [NDS]和[DDS] 中保留历史记录？显然有些不对劲。

我是在为 Big Mess™ 做好准备，还是在正确的轨道上？

我听说过关于如何设计关于事实表中的内容和维度表中的内容的星型模式的教科书定义，例如：

事实表应包含有关对象的核心信息，维度应包含有关事实的信息

（转述）

但是，实际上在业务中，我看到过设计的星型模式，其中事实表包含代理键、业务键和对象的所有单值字段，每个维度存储对象的所有多值字段（因此是维度这个词）。例如，一个人可能是事实表中表示的对象。一个人有一个名字、一个年龄等，这些都在事实表中构成了可行的事实。一个人可能拥有多辆汽车，每辆汽车都有自己的属性，这些属性代表一个人的汽车维度，存储为一个维度表，其中包含多个列来描述每辆车的属性。在这个例子中，这个维度表还包括一个外键，表示来自事实表的相应行的业务键。

所以，如果我们同意这可能是一个合适的设计，我试图克服的问题是如何在多值维度表上执行 SCD 类型 2（历史）。对于我充满单一事实的事实表，这是显而易见的。我包括两个额外的列，有效日期和到期日期，并且我使用业务密钥链接公共记录，其中最近的记录具有NULL到期日期，并且同一业务密钥的所有其他历史记录都具有有效日期和到期日期表明他们是最新记录的时间点。

如何在表示多值列表的维度上使用相同的概念？我基本上想要相同的概念，我可以（1）识别当前列表（在这个例子中，一个人拥有的汽车）和（2）识别历史上任何给定时刻的列表。我可以在每个维度值上设置有效日期和到期日期吗？那么我如何区分一段时间后添加的值？还是删除的值？

但是，如果我们不同意这种设计方法，请告诉我什么行业标准，这样我才能正确地做到这一点。

处理包含多个版本的数据记录时有两种策略。一种是将当前记录放在一张表中，将其过去的版本放在历史表中。

另一种是将所有版本放在同一个表中，并在当前版本上添加一个标志。

我已经看到了每种策略的争论，并且我已经看到社区在不同的帖子中同意这两种策略。

如果没有正确答案，如何决定采取哪种策略？我可以看到将所有记录保留在同一个表中以简化查询（所有记录都在一个表中）和一般情况下表较少的优点。

另一方面是，您拥有这些巨大的表，其中包含大量记录，具体取决于表之间的版本数量和复杂关系。

Pro 历史表数据库设计是否需要修订？数据库历史记录更改，相同还是不同的表？

Pro 当前记录标志https://softwareengineering.stackexchange.com/questions/94489/handling-deleted-users-separate-or-same-table

其他文章https://softwareengineering.stackexchange.com/questions/94489/handling-deleted-users-separate-or-same-table

我正在尝试从审计日志中构建一个历史表（最终构建一个类型 2 的维度表）。不幸的是，审计日志只记录正在更改的特定字段。这是我正在谈论的一个粗略的例子；

CREATE TABLE Staff(
  [ID] int, 
  [Surname] varchar(5), 
  [FirstName] varchar(4), 
  [Office] varchar(9), 
  [Date] varchar(10)
);

INSERT INTO Staff ([ID], [Surname], [FirstName], [Office], [Date])
VALUES
  (001, 'Smith', 'Bill', 'Melbourne', '2015-01-01'),
  (001, NULL, NULL, 'Sydney', '2015-03-01'),
  (002, 'Brown', 'Mary', 'Melbourne', '2014-04-01'),
  (002, 'Jones', NULL, 'Adelaide', '2014-05-01'),
  (002, NULL, NULL, 'Sydney', '2015-01-01'),
  (002, NULL, NULL, 'Perth', '2015-03-01');

特定工作人员的第一个条目是创建他们的记录的时间，每个后续记录都是更新...但仅显示对已更新字段的更新^*。我想用当前员工记录的其余部分“填写”更新行。即，这样的结果；

001, Smith, Bill, Melbourne, 2015-01-01
001, Smith, Bill, Sydney, 2015-03-01
002, Brown, Mary, Melbourne, 2014-04-01
002, Jones, Mary, Adelaide, 2014-05-01
002, …

这是我的布局的示例图片。

如您所见，我有我的 SCD 类型（状态/开始日期/结束日期/businesskey）。

我的密钥是标识每条记录的代理密钥。

我的问题是我的层次结构似乎出错了，这可能是由于布局不正确。这是我当前的关键列结构。

等级制度

LineOfBusinessId（关键列：LineOfBusinessId）（名称列：LineOfBusinessName）

WorkerDivisionId（关键列：LineOfBusinessId、WorkerDivisionId）（名称列：WorkerDivisionName）

WorkerId（关键列：LineOfBusinessId、WorkerDivisionId、WorkerId）（名称列：WorkerName）

此维度出错是因为工作人员名称发生更改，并且在完整处理期间发生 select distinct 时，它会发现重复项。我只是想知道针对这种特定情况设置键列的最佳方法是什么。名称是否需要成为关键列的一部分，或者我的层次结构完全不正确。我确信我的设置是正确的，但我现在显然在质疑自己。

我收到了一些建议，在这种情况下最好的做法是使用代理键作为我的键列的一部分，但后来发现这会导致问题，因为我只希望在查询我的 SCD 时显示一条记录。后来，我收到了更多建议，说我不应该在 id 键列中使用代理，而应该在名称键列中使用代理，特别是在 Worker 级别。

在没有听到建立这种类型层次结构的人的意见的情况下，我对使用此设置更新所有多维数据集感到相当不安。当我看到这个设置时，我不得不认为其他人已经建立了这种类型的层次结构，因为它相当简单。非常感谢任何关于此的建议/方向。

谢谢。