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

Question

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

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

Пока все хорошо... с этой моделью данных довольно легко ответить на такие вещи, как то, сколько записей имеют "Великобритания" в качестве страны с действием "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 м строк.

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

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

Answer 1

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

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

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