Большинство реляционных СУБД поддерживают использование значения NULL для представления отсутствующих данных. NULL сбивает с толку как разработчиков хранилищ данных, так и пользователей, потому что СУБД обрабатывает отсутствующие значения иначе, нежели нули и пустые строки, хотя NULL и очень похожи на последние. В этом совете исследуются три основных области, в которых мы сталкиваемся с отсутствующими значениями в исходных данных, и даются рекомендации по действиям в каждой ситуации.

NULL во внешних ключах таблицы фактов

Мы сталкиваемся с такой ситуацией в источниках данных по нескольким причинам: значение может быть не известно в момент извлечения данных, либо неприменимо к извлекаемым фактам, либо попросту отсутствовать из-за какой-либо ошибки в источнике. Очевидно, что если мы просто поместим NULL в колонку таблицы фактов, объявленную как внешний ключ, то мы нарушим ссылочную целостность, потому что в реляционных СУБД обычно NULL не равен сам себе.

В первом случае, особенно часто возникающем при использовании накопительных снимков (accumulating snapshot), некоторые колонки отслеживают события, которые еще не произошли. Например, в накопительном снимке заказов может быть строка, соответствующая заказу, полученному 31го числа, но отгружен заказ будет только в следующем месяце. И когда строка будет вставлена в таблицу, значение столбца «Дата отгрузки» еще будет неизвестно. В этом случае столбец «Дата отгрузки» является внешним ключом, ссылающимся на таблицу дат. Но если при этом мы просто вставим в колонку значение NULL, то соединение между таблицами не будет работать так, как этого ожидает пользователь. Из любого отчета, использующего связь измерения дат и столбца «Дата отгрузки», пропадут строки в которых «Дата отгрузки» равна NULL. Большинство пользователей нервничают, когда исчезают данные. Поэтому мы рекомендуем использовать вместо NULL суррогатный ключ, который ссылается не специальную запись в таблице дат с описанием вроде «Дата еще не доступна».

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

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

NULL в значениях показателей

В этом случае NULL имеет два возможных смысла. Либо значение отсутствует, либо исходная система не смогла измерить факт. В любом случае мы обычно просто оставляем значение NULL, так как в большинстве СУБД значение NULL обрабатывается корректно в агрегатных функциях типа SUM, MAX, MIN, COUNT и AVG. Замена NULL на ноль исказит результат вычисления этих функций.

NULL в атрибутах измерений

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

Имейте в виду, что инструменты для data mining по-разному обрабатывают NULL. Если подготавливаемые вами данные будут использоваться для data mining, то возможно вам придется приложить дополнительные усилия, помимо выполнения предложенных рекомендаций.

 

Материал опубликован с разрешения компании Ralph Kimball Associates
Автор оригинала: Warren Thornthwaite
Перевод на русский язык: Егор Демьянов
Оригинальный документ располагается здесь


Для удобства отслеживания новых публикаций рекомендуем подписаться на рассылку или на канал RSS.

Читайте также: