Обработка нулей в Datawarehouse

Question

Я хотел бы узнать ваше мнение о том, как лучше всего обрабатывать нулевые или пустые значения данных, когда это относится к хранилищу данных и службам SSIS / SSAS.

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

Особенности:

1) Каков наилучший способ обработки нулевых значений даты / времени? Должен ли я сделать строку «по умолчанию» в моих измерениях времени или даты и указать SSIS на строку по умолчанию, когда найден ноль?

2) Каков наилучший способ обработки нулевых / пустых значений внутри данных измерений. Пример: у меня есть несколько строк в измерениях «Счета», которые имеют пустые (не NULL) значения в столбце «Имя учетной записи». Должен ли я преобразовать эти пустые или нулевые значения внутри столбца в конкретное значение по умолчанию?

3) Аналогично пункту 1 выше - Что мне делать, если я получу строку Facttable, в которой нет записи в одном из столбцов измерения? Нужны ли записи измерений по умолчанию для каждого измерения в случае, если это произойдет?

4) Любые предложения или советы относительно того, как обрабатывать эти операции в службах интеграции с SQL Server (SSIS)? Были бы полезны наилучшие конфигурации потоков данных или лучшие объекты преобразования для использования.

Спасибо: -)

Answer 1

Как указано в предыдущем ответе, для значений Null может быть много разных значений для измерения, неизвестного, неприменимого, неизвестного и т. Д. Если в вашем приложении полезно различать их, добавляя «псевдо» записи измерения может помочь.

В любом случае я бы не использовал внешние ключи или поля измерений с нулевым фактом, поскольку даже одно «неизвестное» значение измерения поможет вашим пользователям определять запросы, включающие групповую группировку, где качество данных не равно 100%. (и никогда не бывает).

Один очень простой трюк, который я использовал для этого и еще не укусил меня, - это определить суррогатные ключи моих измерений, используя int IDENTITY (1,1) в T-sql (начиная с 1 и увеличивая на 1 в строке) ). Псевдоклавы («Недоступно», «Неназначено», «Не применимо») определяются как отрицательные значения и заполняются хранимой процедурой, запущенной в начале процесса ETL.

Например, таблица, созданная как

    CREATE TABLE [dbo].[Location]
    (
        [LocationSK] [int] IDENTITY(1,1) NOT NULL,
        [Name] [varchar](50) NOT NULL,
        [Abbreviation] [varchar](4) NOT NULL,
        [LocationBK] [int] NOT NULL,
        [EffectiveFromDate] [datetime] NOT NULL,
        [EffectiveToDate] [datetime] NULL,
        [Type1Checksum] [int] NOT NULL,
        [Type2Checksum] [int] NOT NULL,
    ) ON [PRIMARY]

И хранимая процедура, заполняющая таблицу

Insert Into dbo.Location (LocationSK, Name, Abbreviation, LocationBK, 
                      EffectiveFromDate,  Type1Checksum, Type2Checksum)
            Values (-1, 'Unknown location', 'Unk', -1, '1900-01-01', 0,0)

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

Answer 2

Спасибо за ввод,

В моем последнем проекте я сделал две вещи:

1) Использовал предложение Стива об отрицательных идентификаторах ключей для неизвестных / специальных значений измерений. Это сработало отлично, и в процессе построения куба SSAS проблем не возникало.

2) Созданы преобразования, чтобы проверить, является ли значение нулевым, и, если это так, преобразовать либо в -1 (неизвестная запись в измерении), либо, если это значение меры, преобразовать в 0. Выражения показаны ниже в качестве примеров (I использовал их в преобразованиях производных столбцов):

ISNULL(netWeight) ? 0 : netWeight // This is an example of a Measure column
ISNULL(completeddateid) ? -1 : completeddateid // This is an example of a dimension key column

Надеюсь, это поможет кому-то еще в будущем; -)

Answer 3

1. Либо NULL, либо зарезервированный идентификатор из вашего измерения даты с соответствующим значением. Помните, что NULL действительно может иметь много разных значений, он может быть неизвестным, неприменимым, недействительным и т. Д.

2. Я бы предпочел пустую строку (а не NULLable), но в проекте, над которым я сейчас работаю, преобразует пустую строку в NULL и разрешает их в базе данных. Потенциальная проблема, которая будет обсуждаться, заключается в том, что пустой средний инициал (без среднего имени, поэтому средний инициал, как известно, является пустым) отличается от неизвестного среднего инициала или подобной семантики. За деньги наша модель допускает NULL - у меня есть большая проблема с фактами, поскольку обычно они действительно должны быть 0, они всегда используются как 0, и они всегда должны быть заключены в ISNULL (). Но из-за политики ETL преобразования пустой строки в NULL им было присвоено значение NULL - но это был просто артефакт формата транспортного файла фиксированной ширины, в котором вместо некоторых исходных систем вместо 0 были пробелы.

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

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

Answer 4

Другое решение, которое я могу предложить, заключается в том, что во время ETL-step определяется таблица переноса, в которую импортированные записи временно сохраняются ПОСЛЕ всех необходимых преобразований. Я бы добавил несколько дополнительных атрибутов в эту таблицу переноса, позволяя кому-либо; рядом с исходными значениями-атрибутами, которые могут быть NULL или каким-либо другим нежелательным значением; вставить «закодированное» значение, идентифицирующее проблему, с одной стороны, и атрибут-имя, в котором произошло ошибочное значение.

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

, например

error-code attribute= -1 = NULL date -2 = NULL numerical value -3 = NULL PK -4 = NULL text value

и другой атрибут = IdOrder, BirthDate, OrderAmount и т. Д.

Конечно, у вас гораздо больше проблем, если записи могут иметь более 1 ошибочного (NULL) значения, но в этом случае можно либо увеличить количество атрибутов «отслеживания», либо «вернуться к источнику» и выяснить, где и почему возникла проблема (вместе с отделом разработки)

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

Может быть, это тоже кому-нибудь поможет;)