Подсистема сопоставления записей в хранилище данных

Автор: Дмитрий Орлов

Введение

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

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

Сопоставление записей (record linkage) – задача достаточно нетривиальная и, что немаловажно, мало описанная в русскоязычной технической литературе, так что данная статья является попыткой в какой-то мере восполнить этот пробел.

Предпосылки создания подсистемы

При интеграции данных из нескольких независимых информационных систем в хранилище данных (далее ХД) возникает необходимость однозначной идентификации экземпляров некоторых сущностей – иначе говоря, перед разработчиком встает задача сопоставления записей (record linkage). Само существование такой задачи обусловлено следующими факторами:

• Независимость информационных систем - каждая система использует собственные правила ввода данных и заполнения таблиц БД, в результате чего одни и те же сущности описаны разным набором атрибутов с различными правилами комплектности;
• Использование структур данных, нарушающих инвариантность представления атрибутов – одни и те же атрибуты у разных экземпляров одной сущности можно представить различным образом (формат, язык и т.п.);
• Недостаточная проработанность процедур контроля при вводе новых данных - контроль при вводе новых данных в систему на пересечение с уже существующими недостаточно проработан, в результате чего в одной системе возможно задвоение экземпляров сущности;
• Ошибки ввода – которые, как показывает практика, всегда сопутствуют вводу данных в информационную систему.

Наверняка каждый разработчик хоть раз в своей практике подвергался воздействию этих факторов и задавал вопрос: «Как с этим бороться?». Один из возможных ответов на этот вопрос – разработка в ХД подсистемы сопоставления записей.

Цели и принципы проектирования подсистемы

Цели

Для начала необходимо определиться с целями, которые преследует создание подсистемы сопоставления записей. В нашем случае цели сформулированы следующим образом:

Реализовать средствами РСУБД механизм связывания логически идентичных экземпляров сущностей, поступающих из разных информационных систем;

Минимизировать человеческий фактор в процессе связывания.

Цели достаточно прозрачны и очевидны, так что можно перейти к рассмотрению принципов проектирования.

Принципы проектирования подсистемы

Формулирование принципов – важный этап в проектировании любой системы (не только информационной), т.к. все последующие выводы и решения будут приниматься на их основе [1]. В нашем случае принципы проектирования подсистемы выглядят следующим образом:

1. Язык и кодовая страница являются общими для всех текстовых данных, циркулирующих в подсистеме;
2. Существует общий алфавит¹, включающий в себя все значимые символы (согласно п.1);
3. Существует особый символ в алфавите, который является пустым и используется в качестве разделителя слов в текстовых данных (как правило – пробел);
4. Преобразование данных, подразумевающее исключение всех символов, отсутствующих в алфавите (незначимые символы), не искажает их смысла (согласно п.2);
5. Существует эталонный набор данных, покрывающий все пространство возможных значений определенной предметной области;
6. Все элементы эталонного набора уникальны;
7. Каждый элемент эталонного набора может иметь множество синонимов;
8. Соответствие любому синониму элемента эталонного набора означает соответствие самому элементу (согласно п.7);
9. Сопоставление любого рабочего набора производится только с соответствующим эталонным набором (согласно п.5);
10. Каждому элементу рабочего набора может соответствовать только один элемент эталонного набора (согласно п.6);
11. Точное соответствие элемента рабочего набора любому синониму элемента эталонного набора является достаточным для успешного сопоставления (согласно п.8);

Ознакомившись с принципами проектирования можно переходить к описанию работы подсистемы.

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

• Часть 2

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

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