Возникает ли какое-либо влияние на то, что NULL на столбце внешнего ключа в пакете данных

Question

В настоящее время мы работаем над дизайном Data mart. У нас есть много Внешние ключи для таблиц размеров. Мы думаем, разрешить ли NULL в полях измерения внешнего ключа или указать -1 для представления значений NULL.

Kimball предлагает сохранить строку по умолчанию для значений NULL. http://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/fact-table-null/

Мое предложение предлагает сохранить NULL как NULL.

Возникает ли какое-либо влияние на производительность при хранении NULL в полях внешнего ключа?

Answer 1

Кимбалл прав (как обычно). Используйте значение по умолчанию, в котором вы бы использовали NULL.

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

Если вы не собираетесь следовать его совету, то используйте NULL. Значение, такое как -1, особенно плохое, поскольку оно препятствует созданию базы данных ограничений внешнего ключа.

Answer 2

Еще одна причина, по которой избегать использования NULL, который не охватил Гордон: неясно, что означает NULL.

Иногда у вас есть NULL в хранилище данных или хранилище данных, потому что что-то пошло не так в ETL или в исходной системе, что приводит к NULL. В других случаях у вас есть NULL, потому что этот столбец не применяется к этой конкретной строке. Или в случае чего-то вроде накопительной таблицы моментальных снимков, поскольку этот столбец еще не заполнен, так как процесс, о котором сообщается, еще не достиг точки, в которой будет заполнен этот столбец.

Вместо одного значения по умолчанию мне нравится настраивать несколько; например, вы можете настроить каждое измерение, чтобы иметь строку, которая указывает «Неизвестный», которую вы можете использовать для отсутствующих значений, и строку, которая указывает «N/A» для случаев, когда это значение не применяется. Я стараюсь установить их с отрицательными целыми числами для ключей (-1 - Unknown, -2 - N/A и т. Д.), Поскольку это позволяет мне использовать одни и те же ключи для этих строк в каждой таблице. Но, как указывают Кимбалл и Гордон, вы должны создать эти строки в своих измерениях.

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

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

И, если кто-то другой возьмет на себя поддержку этого хранилища данных, они будут очень благодарны, когда им не придется тратить огромное количество времени на то, будут ли эти NULL или -1s указывать на проблему.