Разделение базы данных с суррогатными ключами на физический и логический уровень - PullRequest
Новая
       48

Разделение базы данных с суррогатными ключами на физический и логический уровень

0 голосов
/ 23 января 2020

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

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

На физическом уровне каждая таблица получает в основном два поля, подобных этому: (упрощенный случай)

tblProducts: 

ProductKey bigint identity (1,1) not null primary key,
ProductID nvarchar(100) not null unique

tblSales: 

RowKey bigint identity (1,1) not null primary key,
ProductKey bigint not null references tblProducts(ProductKey),
DateSold date,
UnitsSold decimal,
UNIQUE (ProductKey, DateSold)
  • Поле «Ключ» всегда является первичным ключом, который также используется во всех отношениях внешнего ключа.
  • Поле «ID» является уникальным nvarchar. Пользователи всегда будут работать с «ID» и никогда не увидят «ключ».

В логическом слое идея состоит в том, чтобы создавать представления для каждой таблицы, которая будет " скрыть "суррогатный ключ и позволит мне работать с идентификаторами. Даже администраторы базы данных должны, наконец, работать только с представлениями! Например:

Просмотр vwSales: 

select 
    prd.ProductID,
    sls.DateSold,
    sls.UnitsSold
from tblSales sls inner join tblProducts prd on sls.ProductKey = prd.ProductKey

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

  • Есть ли способ «автоматически» создавать такие представления?
  • Это хороший подход для разделения базы данных на физический и логический уровень вообще?

1 Ответ

1 голос
/ 13 февраля 2020

Хотя есть способ автоматизировать создание DDL, я могу сказать вам по опыту, что это не тот способ, которым вы хотите go.

Да, создание суррогатных ключей является наилучшей практикой в ​​данных. Склад (который мы делаем). И да, вы можете скрыть суррогатные ключи от видов или размерных слоев (что мы тоже делаем), автоматическое создание c представлений, которые по сути совпадают с базовыми данными (за исключением суррогатного ключа), излишне обременяет вас сложностью я верю, что вы в конечном итоге пожалеете.

Известно, что Эйнштейн сказал: «Все должно быть сделано настолько просто, насколько это возможно, но не проще».

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

Вы все еще можете получить преимущества, имея другой логический уровень. Я бы порекомендовал использовать виды для создания вашего размерного слоя. Мы публикуем «логические» представления размерного уровня только для бизнес-пользователей, которые хотят использовать данные DW.

Я настоятельно рекомендую вам изучить преимущества ELT по сравнению с традиционными процессами ETL. Это произвело революцию в нашем подходе DW и позволило получить преимущества, которые вы можете искать на логическом уровне.

...