背景) 我已经完成了为我们的库存数据构建一个事实表的过程,理论上它将作为我们仓库的夜间快照。记录的是数量,重量,位置,状态等信息。数据非常精细,在许多情况下与单个实体无关(我们的源数据库将库存数据记录为具有三个主键:licenseplate aka pallet,产品和包装类型 - 因此它基本上有3个业务键,没有代理键。)
目标是能够100%准确地重新创建仓库管理系统的数据,这些数据可以在历史中的任何一天查看。所以我可以查看8月4日在1234号位置生产的XYZ产品托盘数量。
问题1) 现在,我已经构建了这个事实表,在结构上看起来像一个慢慢变化的维度,类型2.这是错的吗?我一直在阅读有关累积快照事实表的内容,我开始质疑我的设计。在这种情况下,最佳做法是什么?
问题2) 如果我的设计没问题,我该如何配置Analysis服务,以便它识别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)
答案 0 :(得分:8)
通常,在快照事实表中,您没有更改。
您通常有一个日期/时间维度,用于测量的粒度而不是DateStart / DateEnd。同样,您没有任何SCD信息。拍摄事实快照,并将日期和时间维度附加到这些事实。如果这些事实每个月都重复相同,那就这样吧。
处理在给定时间确定哪些事实有效比您真正希望DW或ETL处理更多的处理 - 在实时OLTP类型系统中更有效地使用这种设计(生效日期等)在现场系统中保存完整的历史记录。 DW的目的是优化报告,而不是空间,因此有一个直接的快照日期/时间维度,允许您轻松索引和潜在地对数据进行分区,而无需进行大量的日期算术或比较。
就您的尺寸模型而言,请注意不要屈服于太多尺寸问题。请记住,维度不必与现实世界中的实体相对应。如何将维度属性分组到维度表中的选择应该通过以下方式告知:1)查询需求,2)数据亲和性和变更行为,3)业务组织。您可能希望研究使用一个或多个垃圾维度。
答案 1 :(得分:0)
在继续前进之前,库存真的是一个缓慢变化的事实吗?
编辑:那么为什么不每天只对每件产品进行快照,因为这就是你想要的。
问题在于事实表变得很大,而且你不必要地将所有事情都投入到事实表中。理想情况下,事实表只包含维度的外键和仅与手头的事实有关的数据。但是你概述的一些列看起来就像它们属于一个维度表而
例如,车牌信息。状态,类型和查找代码。与netWeight / grossWeight相同。它们应该来自产品维度和PackagedAmount。
CREATE TABLE [dbo].[FactInventory](
[id] [int] IDENTITY(1,1) NOT NULL, (fact table only surrogate key)
[day] [int] NULL, (day dimension key, grain of a day)
[CreateDateId] [int] NULL, (create date dimension key)
/* I take these are needed?
* [CreateTimeId] [int] NULL, (create time dimension key)
* [CreateDate] [datetime] NULL, (create date of the inventory record in src db)
*/
[LicensePlateId] [int] NULL, (pallet id dimension key)
/* Now THESE dimension columns...possibly slowly changing dimensions?
[LPStatusId] [int] NULL, (licenseplate status id dimension key)
[LPTypeId] [int] NULL, (licenseplate type id dimension key)
[LPLookupCode] [nvarchar](128) NULL, (licenseplate non-system name)
*/
[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)
[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)