Объединение идентичных таблиц, но поддержание отдельной ссылочной целостности - PullRequest
1 голос
/ 09 сентября 2009

Рассмотрим модель измерений с таблицами фактов, такими как (fk_dim1value, fk_dim2value, ..., value), где столбцы fk_X являются внешними ключами в соответствующих таблицах тривиальных измерений dim1value (id, value), dim2value (id, value), и т. Д.

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

Итак, я хочу объединить таблицы измерений в одну таблицу dimvalue (fk_dim, dimvalue_id, value), где fk_dim ссылается на таблицу dimension (dim_id, name), а dimvalue_id уникален только для каждого измерения. Естественный первичный ключ тогда составной: (fk_dim, dimvalue_id).

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

Есть ли (разумный) способ сделать это?

Я имею в виду что-то вроде «полусоставного» внешнего ключа, то есть одностолбцовую ссылку на «срез» составного PK с фиксированным значением для другого столбца (столбцов). «Полностью составной» FK будет FOREIGN KEY (col1, col2) REFERENCES dimvalue (fk_dim, dimvalue_id), но здесь fk_dim является фиксированным, и поэтому «домашняя» сторона ключа - это всего лишь один столбец, ссылающийся на второй столбец первичного ключа dimvalue; что-то вроде FOREIGN KEY (fk_dim7value) REFERENCES dimvalue (fk_dim=7, dimvalue_id).

Возможно ли что-то подобное? Или я заблудился в этом последнем абзаце? Должен ли я отказаться и просто ввести внешний ключ ко всей таблице dimvalue, а затем добавить проверочные ограничения для ограничения по измерению? Или ссылочная целостность требует, чтобы я отказался от еще большего и просто принял все отдельные идентичные таблицы?

(Влияние ограничений на производительность записи не важно; производительность чтения является целью проектирования.)

1 Ответ

1 голос
/ 11 сентября 2009

Вы изложили эти ключевые соображения

  • Данные собираются из разрозненных систем, поэтому я пришел к выводу, что это таблица «отчетности», а не система «операций» или «транзакций»
  • каждая таблица фактов содержит 1 часть бизнес-данных на строку, т. Е. Столбец «значение»
  • Ваша таблица фактов, кажется, содержит только одну "меру" или "факт"
  • производительность записи не имеет значения, цель - только производительность чтения. Это подтверждает мой вывод, что это «отчетная» таблица

Учитывая, что вы после быстрого чтения прочитали, я бы выбрал дизайн "большого стола". Конечно, дизайн больших таблиц ужасен для транзакционных систем, но это не так. Под большим столом я имею в виду TABLE (DIM1VALUE, DIM2VALUE, DIM3VALUE, DIM4VALUE .... DIMNVALUE, FACTVALUE)

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

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

Теперь, если ваше количество таблиц измерений было чрезмерным, вы могли бы разделить большую таблицу на группы, где группировка основана на логическом использовании, например, если 10 атрибутов из измерений всегда используются вместе, то оставьте их вместе в BIGTABLE1, и т. д.

...