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

Question

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

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

Answer 1

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

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

create table stores (id, kindOfStore, sales)

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

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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