Как создать таблицу фактов для данных о доставке - PullRequest
0 голосов
/ 29 сентября 2008

Я строю хранилище данных, которое включает информацию о доставке для ресторанов. Данные хранятся в SQL Server 2005, а затем помещаются в куб SQL Server Analysis Services 2005.

Информация о поставках состоит из следующих таблиц:

FactDeliveres

  • BranchKey
  • DeliveryDateKey
  • ProductKey
  • InvoiceNumber (DD: вырожденный размер)
  • Количество
  • UnitCosT
  • Linecost

Примечание:

  • Детализация FactDeliveres - это каждая строка в счете
  • Размер продукта включает информацию о поставщике

И проблема: нет первичного ключа для таблицы фактов. Первичный ключ должен быть чем-то, что однозначно идентифицирует каждую доставку плюс ProductKey. Но у меня нет возможности однозначно определить доставку.

В исходной базе данных OLTP есть идентификатор доставки, который уникален для каждой доставки, но это внутренний идентификатор, который не имеет смысла для пользователей. InvoiceNumber - это номер счета поставщика, который вводится вручную, поэтому мы получаем дубликаты.

В кубе я создал измерение, основываясь только на поле InvoiceNumber в FactDeliveres. Это означает, что когда вы группируете по InvoiceNumber, вы можете объединить 2 доставки только потому, что они (по ошибке) имеют один и тот же InvoiceNumber.

Я чувствую, что мне нужно включить DeliveryID (чтобы он назывался DeliveryKey), но я не уверен, как.

Итак, могу ли я:

  1. Использовать это в качестве основного ключа для измерения InvoiceNumber?
  2. Создать DimDelivery, которая растет каждый раз, когда появляется новая доставка? Это может означать, что некоторые атрибуты исходят из FactDeliveries и входят в DimDelivery, например DeliveryDate, Supplier, InvoiceNumber.

После всего этого я могу просто спросить вас: как мне создать куб Deliveries, когда в моей исходной базе данных есть следующая информация

DeliveryHeaders

  • DeliveryID (PK)
  • DeliveryDate
  • SupplierID (FK)
  • InvoiceNumber (вводится вручную)

DeliveryDetails

  • DeliveryID (PK)
  • ProductID (PK)
  • Количество
  • UnitCosT

Ответы [ 2 ]

3 голосов
/ 29 сентября 2008

У меня в таблице фактов были бы Количество, Код единицы измерения, Номер счета-фактуры, Идентификатор доставки. И InvoiceNumber, и DeliveryID являются вырожденными измерениями, потому что они будут меняться с каждым фактом (или очень немногими фактами). Вполне возможно, что вы можете поместить их в их собственное измерение, если у вас есть большое количество элементов в каждом заказе. Приведенная ниже модель может быть не на 100% правильной, если у вас есть несколько поставок в счете, но она будет близка. Проверьте Кимбалла, у него может быть пример звездной схемы для этого бизнес-сценария.

Fact table:
OrderDateID (not in your model, but probably should be, date dimension in a role)
DeliveryDateID (date dimension in a role)
SupplierID (supplier dimension surrogate key)
InvoiceID (invoice dimension surrogate key)
ProductID (product dimension surrogate key)
Quantity (fact)
UnitCost (fact)
InvoiceNumber (optional)
DeliveryID (optional)

с обычной таблицей измерений даты и следующими измерениями:

Supplier Dim:
SupplierID (surrogate)
SupplierCode and data

Invoice Dim:
InvoiceID (surrogate)
InvoiceNumber (optional)
DeliveryID (optional)

Product Dim:
ProductID (surrogate)
ProductCode and Data

Всегда помните, что ваше хранилище данных (схема звезды) вообще не будет структурировано, как ваши данные OLTP, - это все о фактах и ​​их измерениях.

0 голосов
/ 29 сентября 2008

Таблицы фактов ПК почти всегда являются суррогатными ключами. Каждый факт является частью нескольких измерений, поэтому факт имеет FK к измерениям, но не имеет своих реальных ключей.

Факт доставки (позиция) принадлежит Филиалу, у него есть Продукт, он является частью более крупной Доставки, он происходит в определенную Дату. Звучит как 4 независимых измерения.

Измерение доставки имеет свой собственный PK и атрибут измерения с номером счета. Плюс, пожалуй, другие атрибуты доставки в целом.

Каждый факт позиции строки поставки связан с одной доставкой и номером счета-фактуры для этой доставки.

...