Схема звезды многие ко многим для данных временных рядов

У меня есть вопрос о моделировании схемы DataWarehouse / star.

У меня есть показания счетчиков (факты) для разных мест (размеров). В каждом месте есть несколько организаций с разными ролями. Я хотел бы смоделировать это в схеме хранилища данных. Текущий план:

fact_meter_readings
   timestamp,
   location_id,
   meter_reading (number)

dim_locations
   location_id
   name

dim_location_organisations
   location_id
   organisation_id
   role_id
   organisation_name
   role_name

Unique key (location_id, organisation_id, role_id)

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

Я хочу использовать эту схему, чтобы ответить на такие вопросы, как суммировать meter_reading, сгруппированную по организациям, где они находятся в роли "оператора"

e.g.

select 
  lo.organisation_name,
  sum(meter_reading) 
from fact_meter_readings m
inner join dim_location_organisations lo
on lo.location_id = m.location_id
where lo.role_id = xyz
group by lo.organisation_name

Есть ли здесь какие-либо проблемы, поскольку таблица измерений не имеет уникального ключа, который используется совместно с таблицей фактов? Очевидно, что запросы нужно будет обрабатывать осторожно, чтобы избежать двойного подсчета фактов.


sql data-warehouse star-schema
person Paul Grimshaw    schedule 09.04.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

fact_meter_readings
   timestamp,
   location_id,
   meter_reading (number)

dim_locations
   location_id
   name

dim_location_organisations
   location_id
   role_id
   role_name

dim_organization
   organization_id
   location_id
   organisation_name

И, наверное, «роли» тоже заслуживают своего измерения. Запрос будет немного длиннее, но я верю, что его яснее дать каждой концепции собственное измерение и окупится в будущем.

person Matias Thayer    schedule 09.04.2020
comment
Я предпочитаю, чтобы размеры были как можно более плоскими. В сопутствующей реляционной системе эти концепции строго нормализованы, измерения здесь синхронизированы. - person Paul Grimshaw; 09.04.2020
comment
мм, хорошо, в таком случае я не вижу большой проблемы. Но это может привести к путанице в будущем и непреднамеренному двойному учету. Предложение: если у вас нет проблем с хранением, вы можете найти полезным нормализовать затемнение, как я предлагал, а затем создать большую таблицу, чтобы никому не приходилось тратить время на объединения. Какое-то материализованное представление с результатом вашего запроса. Мы делали это на нескольких предыдущих работах, и это было довольно эффективно. - person Matias Thayer; 09.04.2020
comment
Да, двойной учет - это риск, поэтому мне любопытны идеи другой структуры. Насколько я понимаю, ваша структура выше не предотвратит двойной подсчет, а просто добавит дополнительное соединение к запросу. - person Paul Grimshaw; 13.04.2020