Datawarehouse - Как связать измерения

Question

Только что попал в хранилище данных и вам нужна ваша помощь, чтобы устранить путаницу. Допустим, у меня есть размер сотрудника и размер отдела. Если у меня есть отчет, который требует от меня перечислить поля из dimEmployee (Имя, Зарплата, Должность) и поля из отдела (DeptNo, Desc, Manager), как мне это сделать. Создать ли таблицу фактов (без фактов), которая будет объединяющей таблицей между этими двумя измерениями? Или мне нужно по-разному оформить эти две таблицы. Все говорят о фактах и ​​измерениях, но мы вообще рассматриваем возможность связывания таблиц измерений?

Спасибо за ваши идеи.

RK

Answer 1

Должна быть связь между сотрудником и отделом. Обычно это делается путем добавления столбца DepartmentId в таблицу Employee.

Answer 2

Вариант A: если каждый сотрудник может принадлежать одному и только одному отделу. Я бы добавил DepartmentID в таблицу фактов.

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

Вариант C: Вы можете добавить DepartmentID к таблице сотрудников, и это выполнит работу, но затем вы настроите иерархию. Вы можете сделать это, но ваши объединения становятся сложными и менее эффективными по мере роста набора данных.

Я бы выбрал один из первых двух вариантов, в зависимости от ваших отношений между сотрудником и отделом.

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

Answer 3

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

Например

Person Table
------------

PersonID
Forename
Surname
EffectiveFromDate
EffectiveToDate


Department Table
----------------

DepartmentID
DepartmentName

etc


AssignmentFact Table
--------------------

AssignmentID (primary key)
PersonID (foreign key to person table)
ManagerID (foreign key to person table)
DepartmentID (foreign key to department table)
Salary
CostCentre
EffectiveFromDate
EffectiveToDate.

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

Answer 4

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

dimEmployee
EmpId
Отдел
Имя
и т.д ...

dimDept
DeptId
Desc
Менеджер
и т.д ....

fctEmpDept
EmpId
DeptId
Зарплата

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

Answer 5

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

Таблицы фактов обычно содержат аддитивные вещи (например, количество людей в пределах определенного диапазона заработной платы, должность и т. Д.).

Я не уверен, что Сотрудник будет квалифицирован как измерение; для меня это больше похоже на факт.

Answer 6

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

похоже, вы имеете дело со списками данных. Это может быть лучше достигнуто с помощью прямого SQL. так что-то вроде

 SELECT person.Name, person.Salary, Person.Position,
 Department.DeptNo, Department.Desc, Department.Manager
 From person
  join Department on person.DeptId = Department.Id