Datawarehouse - Как Связать размеры

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

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

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

dimDept
DeptId
Описание
Менеджер
и т. д ....

fctEmpDept
empId
DeptId
Зарплата

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

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

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

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

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

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

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

If you keep your dimensions independent of each other no department reference in the person dimension, no person reference in the department dimension, an assignment fact table can act as the bridge between the two.

For example

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.

So a change to a persons assignment such as a change in line manager or a promotion requires no change to the dimensions but only to the fact table which will provide a nice simple historical record of changes. When you have multiple fact tables sharing these dimensions keeping them simple will pay dividends. Try a simple implementation of both and give them a try and I'm sure you'll find this to be more natural.

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

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

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

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

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