Хранилища данных,
OLAP, CRM: информация
 
 На главную | Книги | Ссылки | Рассылка | Письмо автору | RSS

Порядок разработки ETL-процессов (часть 3)

Автор: Евгений Островский

Типовые сценарии извлечения данных

1. Прямая загрузка из локального структурированного файла

2. Перегрузка из СУБД в СУБД (или ODBC-СУБД)1

3. Загрузка локального структурированного источника

4. Загрузка удалённого структурированного источника

5. Загрузка локального неструктурированного источника

6. Загрузка удалённого или подготавливаемого неструктурированного источника

Очистка данных

Очистка данных заключается в фильтрации тех данных, которые, в каком-либо смысле, не удовлетворяют существующим физическим ограничениям или бизнес-правилам.
При этом данные из таблицы области STTM полностью разделяются на 2 части (потока), которые впоследствии обрабатываются отдельно: данные, которые не прошли проверку, поступают в таблицу с префиксом “ster”, а данные, пригодные к дальнейшей обработке – в таблицу с префиксом “stac”.

STER

В поток STER, как уже сказано, попадают данные, не пригодные к загрузке в ХД по какому-либо заранее заданному критерию. Эти критерии определяются на этапе информационного исследования и преобразуются в SQL-запросы разработчиком ETL.

Категории критериев оценки качества данных можно свести к следующим классам:

A По критичности:

1. Критичные ошибки в данных (данные, которые не соответствуют этому критерию, не могут быть загружены в ХД). Пример: числовое выражение, содержащее букву.
2. Некритичные ошибки в данных (данные, которые могут быть загружены в ХД, но не являются качественными). Пример: пустое (NULL) значение в поле имени.
3. Качественные данные.

B По проверяемым объектам:

1. Корректность форматов и представлений данных.
2. Уникальность первичных и альтернативных ключей.
3. Полнота данных.
4. Полнота связей.
5. Соответствие данных аналитическим ограничениям.

Возможны несколько вариантов реализации процедур фильтрации потока STER:

1. Записи таблицы области STTM обрабатываются по принципу приоритета: если запись не удовлетворяет критерию с более высоким приоритетом, то она не будет проверяться на соответствие остальным критериям с более низким приоритетом, и заносится в набор данных области STER (это может быть как таблица, так и логический файл-представление (view), но его физическая структура полностью включает в себя все поля исходной таблицы STTM).
Пример:

Здесь, таблица ster_client содержит в себе поля исходной таблицы sttm_client(client_code, client_name, client_manager_code) и код ошибки качества error_code.

2. Записи таблицы области STTM получают уникальный идентификатор, и таблица STER формируется по принципу «тестового листа» - как карта соответствия критерия проверки качества данных и идентификатора записи.
Пример:

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

Преимущества второго метода в том, что он даёт полное представление обо всех аспектах качества входных данных, и использует более простую форму таблиц области STER. Однако он требует решения задачи заполнения record_id для каждой таблицы STTM.

Для проектов, где качество данных не является составляющей основных требований, поток STER просто не выводится, и процедуры проверки данных не разрабатываются.

STAC

Таблица области STAC содержит данные, повторяющие входные по составу полей, но уже прошедшие все фильтры на этапе заполнения STER, и, таким образом, признанные качественными. Разработка дальнейших процедур производится с учётом того, что данные области STAC не «пропадут» и не «задвоятся» при объединении, будут удовлетворять бизнес-правилам и ограничениям на формат данных.

Формирование таблицы STAC может производится по принципу «STTM минус STER», или наложением всех фильтров одновременно. Первый способ предпочтительнее, из-за очевидного выигрыша в скорости.

Способ 1

Способ 2



 

 

1 В случае извлечения данных из ODBC-, JDBC-источника данных, или СУБД, применяется функция Pump программы SQLExecutor. Она логически разделяет пересылку данных на две части – извлечение и вставка данных – и, между этими частями, может применить программную обработку данных через механизм трансформаторов. Подробнее см. документацию по SQLExecutor.

 

 

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

 

Если вы нашли в сети интересные ссылки на ресурсы по технологиям хранилищ данных, OLAP, CRM или data mining, и хотите поделиться ими с другими, присылайте их. Я с удовольствием размещу их на этом сайте.

Популярные страницы:

Советы разработчику хранилищ данных

OLAP

Моделирование

Книги

Книги на русском языке

Бесплатные книги

Производители OLAP

CRM

Производители CRM

Управление метаданными

Коллекция ссылок


Найти: на

[ На главную | Книги | Ссылки | Рассылка | Письмо автору | Реклама на сайте ]

© Константин Лисянский, 2001-2008.

SpyLOG Rambler's Top100 Rambler's Top100

Используются технологии uCoz