Основные ключи и ограничения - PullRequest
0 голосов
/ 19 июня 2009

В моем новом хранилище данных, которое построено (разумеется) из базы данных OLTP, я отбросил все столбцы IDENTITY и изменил их на столбцы INT.

Каковы наилучшие практики в отношении следующего, особенно если склад денормализован:

  1. Первичный ключ
    -> теперь это может быть составной ключ, потому что несколько таблиц собрались вместе
    -> мне нужно следовать структуре ключа из OLTP?

  2. Ограничения
    -> есть некоторые ограничения (NOT NULL) со значениями по умолчанию (0) для битовых столбцов

Ответы [ 3 ]

1 голос
/ 27 ноября 2009

Для Размерность Таблицы:

  • Сохранять суррогатное автоинкремент (идентификатор) PK, за исключением измерения даты (см. Ниже).
  • Обеспечивает наличие альтернативного «естественного ключа», позволяющего медленно изменять размеры (тип 2).
  • В таблицах измерений недопустимы нули, замените их многословным «н / п, не введено, неизвестно ..»
  • Если возможно, замените логические флаги (1/0) на подробное «Да, Нет», чтобы сделать их удобными для работы с отчетами / бизнес-пользователями.
  • Избавьтесь от вычисляемых полей и замените их значениями или хотя бы сохраните вычисленное поле - зависит от БД.
  • Реализуйте звездную схему, если можете, обменяйте пространство на скорость. Снежинка только если надо.
  • Проверьте ваши запросы, если в предложении WHERE есть функция, добавьте столбец в таблицу измерений и предварительно рассчитайте значения.
  • Измерение даты легко разбить, если PK выглядит как 20090619.
  • Избавьтесь от проверочных ограничений и значений по умолчанию, переместите их в фазу соответствия процесса ETL. Проверки и настройки по умолчанию замедляют загрузку, и как только вы закончите загрузку, они не играют никакой роли.

Для факт таблицы:

  • Рассмотрите возможность использования суррогатного автоинкремента (идентификатора) PK, чтобы обеспечить простое разбиение, при использовании составного PK вместо этого вы можете создать составной уникальный некластеризованный.

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

ETL

  • Разработка процесса ECCD (ETL) на всех этапах: извлечение, очистка, согласование, доставка.
  • Если возможно, сохраняйте промежуточные результаты (файлы) после каждого этапа для целей аудита и отладки.
  • Документируйте ETL, и при использовании сценариев используйте контроль версий, чтобы можно было сопоставлять версии сценариев с архивированными (промежуточными) файлами.
  • Иметь диаграмму происхождения данных, Excel лучше, чем ничего. Сохраняйте версии тоже.
1 голос
/ 19 июня 2009

Для вашего первичного ключа рассмотрите возможность использования суррогатного или альтернативного ключа; вам нужно учитывать медленно меняющиеся размеры, например, если в течение последних 5 лет вы составляете отчет о средних продажах на одного женатого / неженатого продавца, вам нужно зарегистрировать тот факт, что кто-то не был женат в течение 2 лет, а затем женился в течение последних 3. Это означает, что ваше хранилище данных будет иметь две строки таблицы измерений для одного человека. Следовать структуре OLTP для этого будет сложно:)

Ограничения менее важны; DW в значительной степени оптимизированы для чтения (при условии, что вы заполняете пакет), а ограничения не влияют на операции чтения. Как правило, вы можете обойти любые проблемы с заданием, заполняющим DW, и, при необходимости, иметь дело с нулями и т. Д. В инструменте отчетности. Гораздо важнее убедиться, что значения по умолчанию соответствуют вашей концептуальной модели данных, и не создавать проблем в клиентских инструментах DW.

0 голосов
/ 19 июня 2009

Я бы сказал о 2 .: Битовые столбцы -> работают как bool cols -> разрешено только 1/0 (true / false) -> Constraint ok

...