Таблица фактов - выберите отличное?

в моей модели данных хранилища я получил следующие отношения:

root_tbl - 1: n - entry_tbl - n: 1 - action_tbl

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

Пример данных:

root_tbl:

ID_root ; Country ; FK_User ; FK_Product
      1 ;      UK ;      23 ;      31
      2 ;      NL ;      42 ;      01


entry_tbl:

ID_entry ; FK_root ; FK_Action ; Duration
       1 ;       1 ;        42 ; 200ms
       2 ;       1 ;        10 ; 94ms
       3 ;       1 ;         9 ; 300ms
       4 ;       2 ;        10 ; 322ms
       5 ;       2 ;        30 ; 100ms

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

Таблица фактов будет выглядеть примерно так (просто представьте строки как внешние ключи):

fact_tbl:

ID ; FK_Action ; Duration ; Country ; User ; Product
1  ;        42 ;    200ms ;      UK ;   23 ;      31
1  ;        10 ;     94ms ;      UK ;   23 ;      31
1  ;         9 ;    300ms ;      UK ;   23 ;      31
2  ;        10 ;    322ms ;      NL ;   42 ;      01
2  ;        30 ;    100ms ;      NL ;   42 ;      01

Это означает, что у меня будет много избыточных данных.

Есть ли способ обойти это решение? Таблица фактов будет содержать ~ 300-500 м строк.

Надеюсь, вы поняли мою точку зрения. Если что-то непонятно, не стесняйтесь спрашивать

С уважением, Томас


oracle data-warehouse datamart
person user2428207    schedule 10.10.2013    source источник

Ответы (1)


arrow_upward
3
arrow_downward

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

Здесь вам нужно использовать count (unique) для подсчета количества идентификаторов, но для этого и предназначено хранилище данных. Точно так же вам может потребоваться выполнить Sum (продолжительность), или счет (отдельный пользователь), или счет (отдельный продукт).

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

person David Aldridge    schedule 10.10.2013
comment
Я уточнил свой вопрос ... Надеюсь, это дает лучший обзор! - person user2428207; 10.10.2013
comment
Хорошо, в основном вы говорите, что денормализованная таблица фактов - это обычное дело, верно? - person user2428207; 10.10.2013
comment
Я бы не стал так описывать это - таблица фактов - это набор показателей (фактов) с соответствующей классификацией (измерениями). То, что у вас есть, выглядит как вырожденное измерение, если для него нет отдельной таблицы измерений, но подсчет показателей в звездообразной схеме почти всегда потребует отдельного измерения, если вы не подсчитываете количество самих фактов. Для этого в вашей модели вам придется денормализовать ее, чтобы она была одной строкой для каждого идентификатора, следовательно, одним столбцом для хранения продолжительности для каждого возможного действия. Это было бы больше похоже на витрину данных - в равной степени допустимое, но не столь расширяемое. - person David Aldridge; 10.10.2013
comment
Хорошо, я имею в виду, что мой fact_tbl сверху будет содержать набор показателей, я просто забыл их добавить. Но как можно денормализовать мой пример до одной строки для каждого идентификатора ... один root_id имеет несколько действий, поэтому я придумал эту таблицу фактов. - person user2428207; 10.10.2013
comment
Это возможно только в том случае, если вы потеряете другие измерения, поворачивая их или агрегируя до более высокого уровня атомарности. - person David Aldridge; 10.10.2013