Медленно меняющаяся таблица фактов?

Question

Фон) Я прошел процесс создания таблицы фактов для наших данных инвентаризации, которые теоретически будут действовать как ночные снимки нашего склада. Записывается такая информация, как количество, вес, местоположение, статусы и т. Д. Данные очень детализированы и во многих случаях не связаны конкретно с одним объектом (наша исходная база данных регистрирует данные инвентаризации как имеющие три основных ключа: licenseplate aka pallet, продукт и тип упаковки - таким образом, он имеет по существу 3 бизнес-ключа и не имеет суррогатного ключа).

Цель состоит в том, чтобы иметь возможность на 100% точно воспроизводить данные нашей системы управления складом, которые можно просматривать в любой день истории. Так что я могу посмотреть и посмотреть, сколько поддонов с продуктом XYZ было на складе 1234 4 августа.

Вопрос 1) Теперь я построил эту таблицу фактов так, чтобы она структурно выглядела как медленно меняющееся измерение, тип 2. Это неправильно? Я немного читал о накоплении таблиц фактов снимков и начинаю сомневаться в своем дизайне. Какова лучшая практика в этой ситуации?

Вопрос 2) Если мой дизайн в порядке, как мне настроить службы Analysis Services, чтобы он распознавал мои столбцы DateStart и DateEnd в таблице FACT? Я нашел некоторую информацию о том, как настроить это для измерений, но он не работает / не применим к таблицам фактов.

Для справки - Структура моей таблицы фактов (с добавленными примечаниями о столбцах):

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) организации бизнеса. Возможно, вы захотите использовать одно или несколько ненужных измерений.

Answer 2

Прежде чем идти дальше, действительно ли инвентарь медленно меняется?

Редактировать: Тогда почему бы не делать снимки каждого продукта каждый день, поскольку это то, что вы хотите.

Проблема в том, что таблицы фактов становятся большими, и вы без необходимости выбрасываете ВСЕ в таблицу фактов. В идеале таблица фактов должна содержать не что иное, как внешние ключи к измерениям и данные, относящиеся только к факту. Но некоторые из представленных вами столбцов выглядят так, как будто они принадлежат одной из таблиц измерений, тогда как

Например, информация о номерном знаке. Статус, тип и код поиска. Аналогично с 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)