Как это обычно работает:
- В ваших измерениях у вас будут «естественные ключи» (также известные как «бизнес-ключи») - ключи, поступающие из внешних систем. Например, Номер контракта. Затем вы создаете синтетические (суррогатные) ключи для таблицы.
- В вашей таблице фактов все ключи изначально также должны быть «естественными ключами». Например, Номер контракта. Такие ключи должны существовать для каждого измерения, которое вы хотите подключить к таблице фактов. Иногда для измерения может потребоваться несколько естественных ключей (вместе они представляют уровень «детализации» таблицы измерений). Например, для Location могут потребоваться ключи State и City, если они моделируются на уровне State-City.
- Присоедините свою тусклую таблицу к таблице фактов по естественным ключам, и в результате опустите естественный ключ из факта и выберите суррогатный ключ из тусклого. Я обычно выполняю левое соединение (фактическое левое соединение тускло), чтобы контролировать записи, которые не совпадают. Я также присоединяюсь к затемнению один за другим (чтобы лучше контролировать происходящее).
Базовый пример (с использованием T-SQL). Допустим, у вас есть следующие 2 таблицы:
Table OLTP.Sales
( Contract_BK,
Amount,
Quanity)
Table Dim.Contract
( Contract_SK,
Contract_BK,
Contract Type)
Чтобы поменять местами ключи:
SELECT
c.Contract_SK
,s.Amount
,s.Quantity
INTO
Fact.Sales
FROM
OLTP.Sales s LEFT JOIN Dim.Contract c ON s.Contract_BK = c.Contract_BK
-- Test for missing keys
SELECT
*
FROM
Fact.Sale
WHERE
Contract_SK IS NULL
Кстати, я считаю, что в вашем дизайне есть некоторые ошибки.
- Отчетный период должен быть отдельным параметром. Обычно это календарная таблица со всеми атрибутами, относящимися к дате / периоду.
- Вы, конечно, не должны добавлять ContractNbr к другим измерениям. У вас уже есть эти данные в измерении "Контракт". Вот как работает звездная схема - атрибуты контракта всегда доступны вам через таблицу фактов. Не нужно их копировать.
- Я не могу сказать наверняка (недостаточно информации), но подозреваю, что тусклый учет и тусклое требование могут быть неправильно спроектированы. Если вы намереваетесь перечислить отдельные описания транзакций и отдельные атрибуты требований, это ошибка. В результате размеры будут такими же большими, как таблица фактов. В хорошем дизайне таблицы фактов "высокие и тонкие", а размеры "короткие и толстые". То есть в таблице фактов должно быть несколько полей и много записей, а в таблице фактов должно быть много полей и мало записей. Обычно, если количество записей в вашем диме составляет более 10-20% от записей таблицы фактов, это указывает на неправильный дизайн. Правильный способ решения этой проблемы - разложить претензии на несколько измерений и оставить номер претензии (номер заказа, номер накладной, номер транзакции и т. Д.) В качестве «вырожденного измерения» в вашей таблице фактов. Это немного сложная тема, но она вам явно понадобится в вашем случае. Причина, по которой это важно: если ваши размеры будут такими же высокими, как и таблица фактов, производительность будет ухудшаться. Если количество обращений или претензий исчисляется миллионами записей, это может быть настолько медленным, что убьет ваш дизайн.
Если вам нужна дополнительная информация по этому поводу, я рекомендую эту книгу:
Схема звезды - полное руководство
[Измените, чтобы ответить на дополнительный вопрос]:
Я не хотел удалять поле ClaimNbr из измерения претензий. Я предположил, что вам вообще не нужен такой размер.
Это может быть немного сложно переварить, но учтите следующее. «Заявление» - это, по сути, контейнер для информации (такой же, как «Счет-фактура», «Заказ» и т. Д.). Если вы переместите все полезные данные в соответствующие измерения, не останется ничего, кроме пустого контейнера.
Например, предположим, что ваша таблица требований OLTP содержит следующие поля: Номер претензии, Период отчета, Описание претензии, Имя претензии, Номер контракта, Сумма претензии. Вы можете смоделировать их следующим образом:
- Отчетный период: становится бизнес-ключом для измерения «Дата».
- Номер контракта: становится бизнес-ключом для измерения «Контракт».
- Сумма претензии: остается в таблице фактов как числовой (полностью складывающийся) факт
Остается 3 поля: Номер претензии, Название претензии и Описание претензии. На этом этапе некоторые дизайнеры создают измерение «Утверждение» и размещают там эти поля. Как я упоминал ранее, это ошибка, потому что в этом случае у вас будет столько же записей в вашем измерении, сколько в вашей таблице фактов, что приведет к серьезным проблемам.
Лучше оставить эти поля в таблице фактов. Номер претензии становится «вырожденным измерением» - бизнес-ключом к «пустому» (несуществующему) измерению. По сути, это просто идентификатор информационного контейнера, например номер счета, номер заказа и т. Д.
Название утверждения и описание утверждения также должны оставаться в таблице фактов и становиться «нечисловыми» (неаддитивными) фактами. Если вам нужно отобразить их в отчете, это легко сделать, и вы можете их подсчитать, выполнить с ними условную логику, измерить их длину и т. Д.
Другой способ взглянуть на это: измерения обычно используются для «разрезания» (отсечения) фактов ПО какому-либо атрибуту / полю. Например, «Сумма продаж по странам», «Стоимость продукта по расположению завода» и т. Д. Но вы не можете разрезать по описаниям, примечаниям или другому произвольному тексту - это не имеет смысла.
Что, если ваши описания или другие атрибуты утверждения структурированы? Например, используются ли они для категоризации / классификации ваших требований? В этом случае это не свободный текст, это атрибут, принадлежащий измерению. Например, вы можете разработать измерение «Тип претензии». Или «Статус претензии». И т.д. Если этих небольших полей атрибутов слишком много, вы можете объединить их в так называемое «ненужное» измерение (также известное как «Профиль»), то есть измерение «Профиль заявки». Такие конструкции чистые и эффективные.
Подробнее о размерах мусора здесь
person
RADO
schedule
03.03.2018
