Пространственное Моделирование:должна ли таблица фактов иметь внешний ключ?

Question

Может ли a таблица фактов у вас вообще нет ключей?или если это возможно, то хороший ли это дизайн?Если таблица фактов не имеет никаких измерений, на каком основании она анализируется?

Что делать, если таблица фактов содержит только первичный ключ / ы и не содержит внешнего ключа / ов?

Answer 1

Говоря неточно, внешние ключи связывают вас с таблицами, которые разбивают вашу таблицу фактов на категории и подкатегории.

Итак, если таблица фактов была

create table stores (id, kindOfStore, sales)

Тогда вашим измерением был бы kindOfStore - если бы это было так, то вы могли бы утверждать, что отдельная таблица для kindOfStore является излишеством (за исключением потраченного впустую места с надписью kind of store = "Еда" вместо "Kind_id= 8".Если у вас есть подкатегории, имеет смысл ссылаться на таблицу уменьшения, например

create table kindOfStore (id, Variety, Specialization, Subspecialization) 

Было бы неэффективно с точки зрения пространства хранить Разнообразие, специализацию и Подспециализацию в таблице фактов.

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

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

Answer 2

Пространственное моделирование предназначено для того, чтобы к факту можно было привязать дополнительные детали, описывающие атрибуты, которые можно "свернуть" и объединить в значимую сводную информацию.Это характерно для хранилища данных (среда, предназначенная в основном для чтения), но также может иметь место в OLTP, моделируя действительно транзакционные данные на основе первичных фактов (подумайте о транзакциях с банковским счетом, которые могут быть финансовыми транзакциями, заметками и ревизиями надгробий клиентов - все из которых имеют общую ссылку на объект банковского счета).

Первостепенными среди множества деталей, обычно зависящих от факта, являются размеры ВРЕМЕНИ и МЕСТА.

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

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

Конечным результатом будет единая таблица фактов с несколькими небольшими измерениями, представленными в виде ПЕРЕЧИСЛЕНИЙ.

Но это был бы чрезвычайно странный случай для некоторых действительно странных данных...

Answer 3

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

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

Answer 4

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

Представьте себе базу данных продаж, таблица возможностей содержит длинный-предлинный список атрибутов, верно?Ваш клиент говорит: "Я хочу получить список всех названий возможностей, идентификаторов и людей, назначенных владельцами oppty"...Затем вы можете создать псевдоним или синоним или отобразить ту же таблицу в своем логическом проекте.

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