Стоит ли включать флаги в таблицу фактов?

Таблица фактов транзакций одной из звездообразных схем должна отвечать на такие вопросы, как «Является ли первое приложение окончательным приложением?» Это связано с одним из бизнес-процессов. Это хорошая идея сохранить это как часть таблицы фактов с именем столбца IsFirstAppLastFlag. Существует не так много флагов для создания отдельного измерения. Кроме того, этот флаг (вычисляемый флаг) необходим при написании отчета. В этом контексте нам нужно сохранить его в измерении или на самом деле!

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


sql-server dimensional-modeling star-schema database-design entity-relationship
person user1254579    schedule 08.09.2015    source источник

Ответы (3)


arrow_upward
3
arrow_downward

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

Таблица фактов должна включать ключи измерений, вырожденные ключи измерений и факты.

IsStatusOne, IsStatusTwo и т. д. являются атрибутами и, как вы справедливо предполагаете, хорошо подходят для нежелательного измерения, если они не принадлежат более подходящему измерению, например, IsWeekDay подходит для измерения таблицы «Дата».

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

Производительность: Интересно, что если вы используете битовые столбцы для своих флагов, то разница в хранении при использовании 8-битных флагов в вашей таблице фактов невелика, чем при наличии одного ключа измерения tinyint, однако, когда ваши флаги более подробные или имеют несколько значений состояния, вам следует используйте нежелательное измерение, чтобы повысить производительность таблицы фактов, уменьшить объем хранилища, памяти, увеличить количество строк на странице и т. д.

Лично я бы их выкинул

person Edward Comeau    schedule 08.09.2015
comment
Как вы думаете, мы должны объединить эти атрибуты только в одной таблице? Я имею в виду, что если есть два атрибута true/false, то эти два атрибута должны быть помещены в столбцы и получить 4 строки для указания 4 различных комбинаций. - person mingchau; 30.04.2019
comment
@mingchau да, вы должны поместить все возможные комбинации в одну таблицу измерений (только для поданных флагов). имя этого измерения — JunkDimension. - person Ardalan Shahgholi; 19.08.2020

arrow_upward
1
arrow_downward

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

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

person David Aldridge    schedule 08.09.2015

arrow_upward
0
arrow_downward

Вы можете использовать Junk Dimension.

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

вы можете заполнить свое нежелательное измерение запросом, как показано ниже.

WITH cteFlags AS
(
    SELECT 'N' AS Value
    UNION ALL
    SELECT 'Y'
)
SELECT
    Flag1.Value,
    Flag2.Value,
    Flag3.Value
FROM 
    cteFlags Flag1
    CROSS JOIN cteFlags Flag2
    CROSS JOIN cteFlags Flag3
person Ardalan Shahgholi    schedule 19.08.2020