Сбор измененных данных и службы анализа SQL Server

Вы упомянули, что в настоящее время у вас есть таблица фактов, которая содержит ежемесячные данные о продажах. Таким образом, одна запись на клиента в месяц. Таким образом, каждая запись в этой таблице фактов на самом деле представляет собой совокупность отдельных «транзакций» продаж, которые произошли в течение месяца для соответствующих измерений.

Таким образом, в данном месяце может быть 5 отдельных транзакций продаж по 10 долларов каждая для клиента 123... и каждая отдельная транзакция продаж может обрабатываться другим торговым представителем (A, B, C, D, E). В таблице фактов, которую вы описываете, будет одна запись на 50 долларов для клиента 123... но как мы смоделируем торговых представителей (A-B-C-D-E)?

Исходя из ваших целей...

• чтобы иметь возможность вести историю того, какой торговый представитель был ответственным за клиента во время определенного факта продажи
• узнать, где находился офис торгового представителя во время конкретного факта продажи
• чтобы узнать размер организации клиента на момент совершения конкретного факта продажи

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

FactSales
    DateKey (date of the sale)
    CustomerKey (customer involved in the sale)
    SalesRepKey (sales rep involved in the sale)
    SalesAmount (amount of the sale)

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

Вот как я бы смоделировал данные для ваших измерений...

DimCustomer
    CustomerKey (surrogate key, probably generated via IDENTITY function)
    CustomerID (business key, what you will find in your source systems)
    CustomerName
    Location (attribute we wish to track historically)
    -- the following columns are necessary to keep track of history
    BeginDate
    EndDate
    CurrentRecord

DimSalesRep
    SalesRepKey (surrogate key)
    SalesRepID (business key)
    SalesRepName
    OfficeLocation (attribute we wish to track historically)
    -- the following columns are necessary to keep track of historical changes
    BeginDate
    EndDate
    CurrentRecord

FactSales
    DateKey (this is your link to a date dimension)
    CustomerKey (this is your link to DimCustomer)
    SalesRepKey (this is your link to DimSalesRep)
    SalesAmount

Это позволяет вам иметь несколько записей для одного и того же клиента. Бывший. CustomerID 123 перемещается из NC в GA 05.03.2012...

CustomerKey | CustomerID | CustomerName | Location | BeginDate | EndDate | CurrentRecord
1 | 123 | Ted Stevens | North Carolina | 01-01-1900 | 03-05-2012 | 0
2 | 123 | Ted Stevens | Georgia        | 03-05-2012 | 01-01-2999 | 1

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

Таким образом, когда вы разделяете таблицу фактов транзакций продаж по CustomerID, CustomerName (или любому другому атрибуту, не отслеживаемому исторически), вы должны увидеть одну запись с фактами, агрегированными по всем транзакциям для клиента. А если вместо этого вы решите проанализировать транзакции продаж по CustomerName и Location (исторически отслеживаемый атрибут), вы увидите отдельную запись для каждой «версии» местоположения клиента, соответствующую сумме продаж, пока клиент находился в этом местоположении.

Кстати, если у вас есть время и вы хотите узнать больше, я настоятельно рекомендую библию Кимбалла «Инструментарий хранилища данных» ... которая должна обеспечить прочную основу для сценариев многомерного моделирования.

Самый лучший способ сделать то, что вы хотите, — это многомерная модель с медленно меняющимися измерениями. Торговые представители часто используются для описания полезности SCD. Например, менеджеры по продажам, бонусы которых привязаны к результатам работы их команд, не хотят, чтобы их общая сумма падала, если торговый представитель переезжает на новую территорию. SCD идеально подходят для отслеживания такого рода вещей (и ситуаций, которые вы описываете) и позволяют вам увидеть, как все выглядело в любой исторический момент.

Потратьте некоторое время на веб-сайт Ральфа Кимбалла, чтобы начать. Первые 3 статьи, которые я рекомендую вам прочитать, это Медленно изменяющиеся размеры, Медленно меняющиеся размеры, часть 2 и 10 основных правил объемного моделирования. .

Вот несколько вещей, на которых нужно сосредоточиться, чтобы добиться успеха:

1. Вы не разрабатываете транзакционную базу данных 3NF. Освойтесь с денормализацией.
2. Убедитесь, что вы понимаете, что означает зернистость, и явно определите зернистость вашей базы данных.
3. Не используйте естественные ключи в качестве ключей и не встраивайте в свои суррогатные ключи какой-либо интеллект (за исключением временных ключей).
4. Целями вашего приложения должны быть скорость запросов и простота понимания и навигации.
5. Поймите тип 1 и тип 2, медленно изменяющиеся измерения, и знайте, где их использовать.
6. Убедитесь, что у вас есть спонсор со стороны бизнеса, способный «разорвать связи». В организации вы найдете разных людей с разными определениями одного и того же, и вам нужен исполнитель, обладающий полномочиями принимать решения. Чтобы понять, что я имею в виду, попросите 5 разных сотрудников вашей организации дать определение понятиям «клиент» или «валовая прибыль». Вам повезет, если 2 человека определят одно и то же.
7. Не пытайтесь надуть его. Прочтите Инструментарий жизненного цикла хранилища данных и освойте идеи, даже если они поначалу кажутся странными. Они работают.
8. OLAP мощен и может изменить жизнь, если его умело внедрить. Это может быть абсолютным кошмаром, если это не так.
9. Повеселись!