Пустые значения в таблице измерений для числовых атрибутов

Как лучше всего обрабатывать отсутствующие значения в таблице измерений?

В случае текстового столбца легко написать "NA: Отсутствует", но что делать с числовыми столбцами, где важно сохранить конкретные значения. Примечание. Мне не нужно решение, в котором используются значения с полосами (например, текстовые столбцы для «0–50», «50–100», «NA: отсутствует»).

Например, параметр клиента может иметь год рождения. Как следует обращаться с отсутствующими годами рождения? Оставить нулевым? Добавить произвольное число в качестве заполнителя, например 1900?

Иногда может быть трудно найти номер-заполнитель. Например, если продажи на сегодняшний день неотрицательны, но могут быть равны нулю, я бы не хотел ставить «0» в качестве заполнителя для нуля. Я мог бы использовать отрицательные значения, такие как "-1", но это испортило бы запросы, использующие суммы.


data-warehouse star-schema database-design
person d_a_c321    schedule 16.04.2013    source источник
comment
Вы сами не отвечаете на свой вопрос? Что плохого в NULL?   -  person fancyPants    schedule 16.04.2013
comment
Sales-to-date не может быть нулевым. В таком случае ошибка должна возникать во время процесса ETL. У нас есть null для клиентов с отсутствующей датой рождения в нашем DW.   -  person Tomas Greif    schedule 16.04.2013
comment
@tombom, разве нули не рекомендуются в таблицах измерений? Я хотел уточнить, должны ли они быть разрешены в случае числового значения. @twn08, текущие продажи могут быть нулевыми, если данные о продажах отсутствуют. Вы правы, что пример с датой рождения лучше. Какова ваша логика для сохранения нулевой даты рождения? Кроме того, вы используете флаг, чтобы указать, что значение равно null? Например, birthday_is_null и т. д. для каждого нулевого столбца? Знаете ли вы какие-либо ссылки, в которых обсуждается этот вопрос или объясняется, почему заполнители — однозначно плохая идея?   -  person d_a_c321    schedule 16.04.2013
comment
Законов на этот счет нет: вы сами решаете, что разрешено в вашей собственной базе данных, а что нет. NULL по какой-то причине является спорной темой, но это такой же инструмент, как и любой другой. Этот вопрос на сайте администратора баз данных является хорошим вариантом для рассмотрения. Наша DWH использует значения NULL везде, где значение по умолчанию может исказить данные отчета (обычно это проблема с таблицами фактов). Единственным недостатком является то, что ваш инструмент отчетности должен правильно обрабатывать их, если вы используете их в качестве критериев отчета, что может быть основным соображением для параметров.   -  person Pondlife    schedule 16.04.2013
comment
Я согласен с @Pondlife - значения по умолчанию иногда приносят больше вреда, чем пользы. Вопрос о покупателе особенно сложный, потому что часто мы не знаем многих атрибутов клиента по разным причинам. Я предпочитаю оставлять столбцы NULL, если они действительно неизвестны.   -  person N West    schedule 16.04.2013
comment
Большое спасибо за ваши ответы, @NWest и pondlife.. Могу ли я также узнать ваши мысли о том, имеет ли смысл создавать флаг var_is_null и как вы выполняете запросы, когда есть нулевые значения?   -  person d_a_c321    schedule 23.04.2013

Ответы (1)


arrow_upward
1
arrow_downward

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

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

Если вам нужно пустое значение в измерении, тогда в измерении должна быть строка для этой цели. Например, измерение даты может иметь 3 или 4 специальные строки — no value, unknown, past и future являются разумными специальными строками значений, в зависимости от ваших потребностей.

Таким образом, вы избавите себя от боли и страданий на уровне BI.

person Corey    schedule 19.09.2013
comment
Любые мысли о том, как обрабатывать несколько причин нулевых значений числовых фактов? Я не уверен, что вижу более простой способ, чем создать отдельный столбец null_status = (PRESENT, 'Null: Reason 1', Null: Reason 2' и т. д.). - person d_a_c321; 24.09.2013