sql - 事实表缓慢变化？

Question

背景)我已经完成了为库存数据构建事实表的过程，理论上该表将充当我们仓库的夜间快照。记录的是数量、重量、位置、状态等信息。数据非常精细，在许多情况下与单个实体没有具体相关(我们的源数据库将库存数据记录为具有三个主键:车牌又名托盘，产品和包装类型 - 因此它本质上有 3 个业务键并且没有代理键)。

我们的目标是能够 100% 准确地重新创建我们的仓库管理系统的数据，这些数据在历史上的任何一天都可以查看。这样我就可以查看 8 月 4 日位置 1234 有多少托盘的产品 XYZ。

问题 1)现在，我构建了这个事实表，其结构看起来像缓慢变化的维度，类型 2。这是错误的吗？我已经阅读了一些有关累积快照事实表的内容，并且开始质疑我的设计。这种情况下的最佳做法是什么？

问题 2)如果我的设计没问题，我该如何配置 Analysis Services，以便它识别 FACT 表中的 DateStart 和 DateEnd 列？我找到了一些有关如何配置维度的信息，但它似乎不适用于/适用于事实表。

供引用 - 我的事实表的结构(添加了有关列的注释):

CREATE TABLE [dbo].[FactInventory](     
[id] [int] IDENTITY(1,1) NOT NULL,  (fact table only surrogate key)
[DateStart] [datetime] NULL,    (record begin date)
[DateEnd] [datetime] NULL,       (record end date)
[CreateDate] [datetime] NULL,    (create date of the inventory record in src db)
[CreateDateId] [int] NULL,       (create date dimension key)
[CreateTimeId] [int] NULL,       (create time dimension key)
[LicensePlateId] [int] NULL,     (pallet id dimension key)
[SerialNumberId] [int] NULL,     (serial number id dimension key)
[PackagedId] [int] NULL,         (packaging type id dimension key)
[LotId] [int] NULL,          (inventory lot id dimension key)
[MaterialId] [int] NULL,         (product id dimension key)
[ProjectId] [int] NULL,          (customer project id dimension key)
[OwnerId] [int] NULL,        (customer id dimension key)
[WarehouseId] [int] NULL,     (warehouse id dimension key)
[LocationId] [int] NULL,      (location id dimension key)
[LPStatusId] [int] NULL,      (licenseplate status id dimension key)
[LPTypeId] [int] NULL,    (licenseplate type id dimension key)
[LPLookupCode] [nvarchar](128) NULL, (licenseplate non-system name)
[PackagedAmount] [money] NULL,  (inventory amount - measure)
[netWeight] [money] NULL,   (inventory netWeight - measure)
[grossWeight] [money] NULL, (inventory grossWeight - measure)
[Archived] [bit] NULL,  (inventory archived yes/no - dimension)
[SCDChangeReason] [nvarchar](128) NULL (auditing data for changes)

Answer 1

通常，在快照事实表中您没有任何更改。

您通常有一个用于测量粒度的日期/时间维度，而不是 DateStart/DateEnd。同样，您没有任何 SCD 信息。拍摄事实快照并将日期和时间维度附加到这些事实。如果这些事实每个月都重复相同，那就这样吧。

处理确定哪些事实在给定时间有效的处理量比您真正希望 DW 或 ETL 处理的处理量要多 - 这种设计(有效日期等)在实时 OLTP 类型系统中使用更有效完整的历史记录保存在实时系统中。 DW 的重点是针对报告进行优化，而不是针对空间进行优化，因此有一个直接快照日期/时间维度，可让您轻松索引并可能对数据进行分区，而无需进行大量日期算术或比较。

就您的维度模型而言，请注意不要屈服于过多维度的问题。请记住，维度不必与现实世界中的实体相对应。选择如何将维度属性分组到维度表中应考虑以下因素:1) 查询需求，2) 数据亲和性和更改行为，3) 业务组织。您可能想考虑使用一个或多个垃圾维度。