Вопрос проектирования хранилищ данных - PullRequest
Новая
       32

Вопрос проектирования хранилищ данных

3 голосов
/ 12 августа 2010

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

DimInstructor <- Таблица размеров для инструкторов DimStudent <- Таблица размеров для студентов </p>

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

Теперь я хочу создать таблицу измерений урока с именем DimLesson. В DimLesson я хочу создать ссылку на инструктора.

Таблица DimInstructor содержит:

InstructorDWID <- поле идентификатора при вводе в DW InstructorID <- идентификатор инструктора, полученный из базы данных OLTP </p>

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

Итак, мой вопрос, как я могу ссылаться на инструктора из DimLesson? Я использую InstructorDWID? Если это так, если у меня будет 2 записи для инструктора в DimInstructor, это усложнит запросы, когда я захочу посмотреть на все уроки конкретного инструктора.

Буду признателен за любую помощь!

Ответы [ 3 ]

2 голосов
/ 12 августа 2010

То, что вы здесь описываете, обычно называется измерением типа 2. В книгах хранилища данных Kimball есть целые разделы по измерениям типа 2 и ETL для этого типа - прочитайте.

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

InstructorKey  InstructorBusinessKey  FirstName LastName  row_ValidFrom row_ValidTo   row_Status
  1234           jane_doe_7211           Jane     Doe       2000-03-11   2010-08-12     expired
  7268           jane_doe_7211           Jane     Smith     2010-08-12   3000-01-01     current

Теперь, при условии, что dimLesson является подходящим дизайном для вашей бизнес-модели (в отличие от наличия какого-либо факта), dimLesson будет иметь столбец с именем InstructorKey. В процессе ETL при доставке новой строки (7258) в таблицу dimInstructor замените все ссылки на строку 1234 в dimLesson на 7268.

1 голос
/ 12 августа 2010

Пол,

Есть несколько способов справиться с этим.Вы можете использовать дату вступления в силу / неактивную дату, порядковый номер или номер версии, чтобы различать записи с одним и тем же идентификатором InstructorID.

Модуль DIM, который собирает все соответствующие данные, будет выглядеть как .. 

create table DIM_INSTRUCTOR(
  instr_guid number, --populated through a sequence     -----Composite pk-Part1
  istr_oid   number, --direct id from the OLTP system   -----cmposite  pk-part2
  instr_name number,
  other_attr varchar2(25),
  eff_date   date,
  expiration_date date
);

instr_guid напрямую генерируется из последовательности и не зависит от системы OLTP.

Это позволит вам собрать все детали для данного инструктора.Вы можете использовать только instr_guid в качестве внешнего ключа к таблице фактов, но включение их обоих (instr_guid, instr_guid) увеличит удобство запросов ..., что является одной из целей Datawarehousing.

Полезные ссылки:

http://en.wikipedia.org/wiki/Surrogate_key http://en.wikipedia.org/wiki/Slowly_changing_dimension#Type_2

0 голосов
/ 12 августа 2010

Использование guid / uuid в качестве первичного ключа или комбинации столбцов

...