Свертывание редких изменений в столбце фактов

Question

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

Я не уверен, что люди всегда думают об этом. Легче просто добавить измерение и не думать об этом. Однако, как один из правил Кимбалла, не должно быть слишком много измерений для таблицы фактов (я думаю, что число, которое он предложил, составляет около 20).

я взял пол в качестве примера, но есть много других, таких как государственное название, название города, кредит типа карты и т.д.

Мой вопрос:

Какое правило нужно использовать, чтобы решить, следует ли вставлять/сворачивать значение в таблице фактов против наличия отдельного измерения для него? Некоторые из возможных ответов: 1. Когда он не изменяется (например, пол). 2. Когда он имеет несколько возможных значений и имеет короткую длину?

Что еще?

EDIT

Даже если я рассмотрел этот вопрос ответил, я все-таки пошел на дальнейшие исследования. Существует случай, когда у вас есть может иметь, чтобы использовать измерение. Дело здесь: «Факультативные размеры часто используются для поддержки действий сверления, потому что для сквозного действия в службах анализа SQL Server (SSAS) требуется, чтобы вы выбрали атрибуты из измерения. Поэтому, если вы хотите видеть определенные поля, когда они выполняют упражнение, вы должны иметь эти поля в измерении ».

выше цитировали здесь Degenerate Dimensions

Я думаю, что вопрос требует дальнейшего анализа для заинтересованного лица (лиц).

Answer 1

Похоже, вы описываете, что Кимбалл называет «вырожденными измерениями» - где вы храните значение измерения непосредственно в таблице фактов. Собственный подход Кимбалла заключается в том, что вы используете их, когда у вас есть только один столбец для этого измерения. С этим часто бывает что-то очень низкое. Хороший пример - это что-то вроде заказа на поставку - у вас будет таблица фактов заказа на поставку, а затем есть столбец, называемый PurchaseOrderReference, который на самом деле является дегенеративным измерением, вместо того, чтобы иметь размер заказа на покупку, который является индивидуальным с фактом.

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

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

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