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

Дмитрий Орлов,
ведущий специалист Производственного центра Datagy

Введение

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

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

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

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

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

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

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

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

Цели

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

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

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

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

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

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

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

Как работает подсистема

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

Подсистема работает по принципу трехступенчатого фильтра, т.е. имеет в своем составе три ступени "фильтрации"³ данных:

• Точное сравнение - первая стадия "фильтрации". На этой стадии происходит точное сравнение элементов рабочего набора с синонимами соответствующего эталонного набора. Все элементы рабочего набора, точно совпавшие с синонимами эталона, считаются связанными и в дальнейшем процессе не участвуют (см. п.11)
• Нечеткое сравнение - вторая стадия "фильтрации". Здесь данные сравниваются с применением методов нечеткого сравнения. Эффективность данной стадии зависит от грамотно подобранных критериев идентичности, согласно которым и делается вывод об удачном сопоставлении. Разработка и уточнение этих критериев является одной из самых сложных задач при проектировании и эксплуатации подсистемы. Исходя из того, что имеются вполне работоспособные критерии, некоторая часть данных, возможно, также будет успешно сопоставлена с эталонным набором на этой стадии
• Ручное связывание - это та самая стадия, где необходимо применить человеческий интеллект и поработать руками. Собственно, на входе имеется список похожих пар "эталон-рабочий образец", а окончательное решение об их идентичности принимает оператор. Для взаимодействия оператора с системой необходимо разработать GUI программу, аспекты создания которой выходят за рамки статьи. Здесь стоит заметить, что данная GUI программа должна позволить сформировать набор связанных записей оператору, не обладающему навыками программирования.

По завершении рабочих стадий необходимо произвести расширение набора синонимов эталона за счет вновь выявленных, на втором и третьем этапе, связей "эталон-рабочий образец" (согласно п.7). Расширение словаря синонимов возможно реализовать, как дополнительную функцию GUI программы, используемой оператором на стадии ручного связывания, либо как хранимую процедуру (stored procedure). Хочется подчеркнуть, что расширение словаря синонимов играет ключевую роль в подсистеме, т.к. во время следующего сеанса загрузки данных в ХД, нагрузка на оператора значительно уменьшится, либо дело вообще не дойдет до стадии ручного связывания, т.к., возможно, все необходимые связи будут обнаружены уже на стадии точного сравнения!
Теперь, когда имеется представление об основных принципах работы подсистемы, можно ознакомиться с процессом сопоставления более наглядно с помощью предоставленной ниже диаграммы.

IDEF0 диаграмма процесса

На диаграмме процесса средствами IDEF0, по сути, изложено то, о чем уже говорилось выше. Но все же, не помешают некоторые дополнительные пояснения.

Рис.1 IDEF0 диаграмма процесса сопоставления записей

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

Во-вторых, обязательно должен последовать вопрос, что это за набор несвязанных записей на выходе? Вопрос закономерный, и существуют, как минимум, три ответа на него:

1. Данные, которые не связались с эталоном, - просто мусор, что согласуется с п.5 (и многими реальными системами, где в поле "Наименование" какого-либо справочника можно встретить строку типа: "$$$_OTLADKA_NE_UDALIAT!!_$$$"). Для фильтрации подобных записей можно создать специальный "Справочник мусора", который будет содержать записи такого рода, что позволит исключить их из процесса сопоставления еще до начала первой стадии;
2. Эталонный набор не покрывает все пространство значений и его необходимо дополнить. Это противоречит п.5, однако соответствует большинству реальных ситуаций. В этом случае несвязанные записи можно добавить в эталонный набор;
3. Реализация методов нечеткого сравнения неудовлетворительна, т.е. критерии идентичности реализованы так, что "не замечают" часть похожих записей.

Автор при испытании прототипа подсистемы получил на выходе такой набор, и хотя записей было достаточно мало, что делало его пригодным для ручного связывания (около десятка записей), попробовал пропустить его еще раз через стадию нечеткого сравнения с менее строгими условиями. Это дало определенный эффект - несколько записей "нашли" свои эталоны, но были и неверные соответствия. Так что, в принципе, возможно применение повторного цикла нечеткого сравнения с более мягкими критериями, при наличии на выходе несвязанных записей.
Также стоит заметить, что наличие потока 'Набор связанных записей" на стадии нечеткого сравнения носит, скорее, символический характер, т.к. на практике вряд ли представляется возможным реализовать полностью однозначный критерий, применимый на этой стадии.

Критерий качества

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

Методы нечеткого сравнения

Разобравшись с принципом работы подсистемы легко заметить, что основной вклад в эффективность работы подсистемы вносит именно стадия нечеткого сравнения. О том, как осуществлять нечеткий поиск и сравнение, написано достаточно много [5,7,8], однако большинство алгоритмов невозможно⁵ адаптировать к особенностям РСУБД. Рассмотрим вкратце два основных метода, которые достаточно просто реализовать с использованием языка SQL.

Метод Q-грам

Это самый простой и очевидный метод, который, тем не менее, может показать хорошие результаты для некоторых видов данных, например географических названий.
Суть метод проста - сравниваемые строки режутся на подстроки длины Q (Q-грамы), далее осуществляется сравнение наборов подстрок и, исходя из количества совпавших подстрок, можно сделать выводы об их похожести или непохожести [10].

Критериями, в данном случае, могут служить следующие величины:

• Количество совпавших подстрок с учетом длин сравниваемых строк;
• Количество совпавших подстрок с учетом их позиций в сравниваемых строках;
• Количество совпавших подстрок с учетом их позиций в сравниваемых строках и длин сравниваемых строк;
• Количество совпавших подстрок с учетом допустимого интервала отклонения их позиций в сравниваемых строках и допустимого отклонения длин сравниваемых строк.

Судя по опытным данным, наиболее оптимальным является деление на подстроки длины Q = 2 (би-грамы). Рассмотрим пример:

Таблица 1. Исходные данные

Количество Q-грам в строке рассчитывается по следующей формуле:

К = Длина строки - Q + 1

В случае би-грам для эталона эта величина равна 19, а для рабочей строки 16. Сами би-грамы приведены в таблице 2.

Таблица 2. Би-грамы

Эталон	Рабочая строка
РЕ 6	ТА
ЕС	АТ
СП	ТА
ПУ	АР
УБ	РС
БЛ	СТ
ЛИ	ТА
ИК	АН
КА	Н
А	Р
Т	РЕ
ТА	ЕС
АТ	СП
ТА	ПУ
АР	УБ
РС	БЛ
СТ
ТА
АН

Теперь можно продемонстрировать, как результат сравнения зависит от критерия идентичности, в очередной раз подчеркнув важность и сложность задачи по формированию критериев.

Определим два различных критерия идентичности:

КИ1 = Количество совпадений/ К_{эталона}
КИ2 = Количество совпадений * 2 / (К_{эталона} + К_{рабочей строки})

Для нашего случая они таковы (количество совпадений не учитывает повторяемость подстроки ТА):

КИ1 = 14/19 = 0.73
КИ2 = 14 * 2/(19+16) = 0.8

Допустим, что для положительного решения о схожести строк величина критерия должна превышать некое пороговое значение, например - 0.75. Тогда, согласно критерию КИ1 - строки разные, а для КИ2 - похожие. В общем, есть простор для творчества.

Основными достоинствами данного метода являются его простота и легкость реализации. Кроме того, он позволяет находить похожие строки с различным порядком слов. Недостатком же является необходимость работать с огромным количеством записей - Q-грамами.

Метод хэширования

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

Хэш-алгоритмы традиционно использовались и используются для связывания записей, в чем можно убедиться, ознакомившись с альманахом Федерального Комитета США по методам статистики, посвященному сопоставлению записей [8]. В этом альманахе описано достаточно много различных методов, так что автор рекомендует потратить время на его изучение.

Самыми известными хэш-преобразованиями являются алгоритмы Soundex [2] и MetaPhone. Алгоритм MetaPhone адаптирован к особенностям русского языка Петром Каньковски из Новосибирска и прекрасно описан в его статье [6], где можно познакомиться с реализацией данного алгоритма на VB. Заметим, что такой алгоритм преобразования можно реализовать и средствами SQL.

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

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

Возможности оптимизации

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

1. Оценить значимость каждого слова по частоте его повторяемости, которая легко вычисляется при формировании словаря. Если слово встречается слишком часто или слишком редко, то с большой вероятностью оно не оказывает существенного влияния на результат сравнения. Таким образом, используя статистические методы оценки (например, доверительный интервал, рассчитанный с применением критериев Стьюдента) [3] , возможно исключить из процесса сравнения незначимые⁷ слова. Это позволит улучшить результаты для обоих описанных методов;
2. Рассчитать хэш для каждого слова, что позволит получить более взвешенные результаты при использовании метода хэширования, т.к. для фразы подобрать хэш-функцию гораздо сложнее, чем для отдельного слова.

Естественно, что вышесказанным возможности оптимизации не исчерпываются и здесь остается пища для ума и открывается простор для эксперимента.

ER диаграмма подсистемы

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

Логическая схема этой базы данных представлена в виде IDEF1X диаграммы и содержит следующие сущности:

Таблица 3. Сущности подсистемы

Сущность	Назначение	Атрибуты
Би-грам индекс рабочего набора	Содержит би-грамы строк рабочего набора	ID элемента Позиция би-грамы Би-грама
Би-грам индекс синонима	Содержит би-грамы синонимов эталонного набора	ID синонима Позиция би-грамы в синониме Би-грама
Вхождение слова в синоним	Содержит информацию о вхождении слов из словаря предметной области в синонимы эталона	ID слова предметной области ID синонима Позиция слова в синониме
Вхождение слова в элемент набора	Содержит информацию о вхождении слов из словаря рабочего набора в строки рабочего набора	ID слова рабочего набора ID элемента Позиция слова строке
Предметная область	Содержит список предметных областей,для которых существуют эталонные наборы	ID предметной области Наименование предметной области
Рабочий набор	Содержит набор записей, которые необходимосопоставить с эталонным набором	ID элемента Элемент рабочего набора Нормализованный элемент
Синоним эталона	Словарь синонимов эталонного набора	ID синонима ID эталона Синоним
Слово из предметной области	Содержит список слов предметной области (словарь предметной области)	ID слова предметной области ID предметной области Слово предметной области Повторяемость слова
Слово из рабочего набора	Содержит список слов рабочего набора (словарь рабочего набора)	ID слова рабочего набора Слово рабочего набора Повторяемость слова
Тип хэширования	Содержит список доступных хэш-преобразований	ID типа хэширования Наименование типа хэширования
Хэш-таблица предметной области	Содержит хэш для каждого слова из словаря предметной области	ID слова предметной области ID типа хэширования Хэш слова
Хэш-таблица рабочего набора	Содержит хэш для каждого слова из словаря рабочего набора	ID типа хэширования ID слова рабочего набора Хэш слова
Эталон	Содержит строки эталонного набора	ID эталона ID предметной области Эталон

Рис.2 IDEF1X диаграмма подсистемы сопоставления записей

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

Таким образом, вся работа по связыванию записей, возлагаемая на РСУБД, сводится к трем этапам:

• Загрузка и инициализация сравниваемых наборов, в ходе которой происходит заполнение нужных таблиц
• Выполнение объединяющих (INNER JOIN) подзапросов к таблицам:
  • "Синоним" и "Рабочий набор" для строгого сравнения
  • "Би-грам индекс синонима" и "Би-грам индекс рабочего набора" для нечеткого сравнения
  • "Хэш-таблица предметной области" и "Хэш-таблица рабочего набора" для нечеткого сравнения
• Добавление записей в набор 'Синоним" - расширение словаря синонимов.

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

Повышение эффективности подсистемы за счет использования доменных знаний

До сих пор речь шла о сопоставлении линейных наборов, сущности рассматривались без учета возможных иерархических отношений - доменных знаний. Однако, можно значительно улучшить эффективность подсистемы, если в процессе связывания записей использовать эти доменные знания. Этот подход применим в случае, если сравниваемые сущности принадлежат некоторой иерархии, что делает возможным использование косвенной идентификации [9].

Так, сравнивая рабочий набор со справочником ОКАТО¹⁰ , где есть некая иерархия, можно использовать знания о принадлежности некоторого подмножества административно-территориальных единиц какому-либо административному центру.

Рассмотрим это на примере Московской области:

Таблица 4. Сравнение рабочего набора с ОКАТО

Эталон		Рабочий образец
Административный центр	Подчиненные объекты	Административный центр	Подчиненные объекты
МОСКОВСКАЯ ОБЛАСТЬ	РЕУТОВ Г.ЗЕЛЕНОГРАД Г.МЫТИЩИ Г.КЛИН Г.ВОЛОКОЛАМСК Г. и т.д.	МОСК. ОБЛ.	Г. РЕУТОВ ЗЕЛЕНОГРАД Г. Г. МЫТИЩИ КЛИН Г. ВОЛОКОЛАМСК Г. и т.д

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

Варианты применения подсистемы

Теперь вкратце о том, как может использоваться подобная подсистема в ХД.

Самой очевидной и, безусловно, важной областью применения подсистемы является, конечно же, интеграция данных из разных подсистем. Можно долго говорить о важности правильного сопоставления записей из различных источников - в конце концов, все сведется к следующему: "В хранилище данных недопустимо наличие логических дубликатов записей". И это так. Однако есть и некоторые другие аспекты применения данной подсистемы:

• Восстановление значений отсутствующих атрибутов (например, восстановление адреса по почтовому индексу);
• Очистка данных от "мусора";
• Синтаксический контроль и исправление текстовых данных.

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

Глоссарий

Логическая идентичность экземпляров сущности - экземпляры сущности, описывающие один и то же объект реального мира.

Эталонный набор (эталон) - набор записей, однозначно трактуемых и синтаксически верных, покрывающий все пространство значений соответствующей предметной области, предназначенный для передачи этих свойств рабочим наборам. Эталонным набором может быть, как стандартный справочник (ISO, ОК¹¹*), так и некий набор записей, полученный из информационной системы и обладающий вышеперечисленными свойствами.

Набор синонимов - набор записей, являющихся установленными (подтвержденными) синонимами эталонного набора.

Рабочий набор - набор записей, требующий сопоставления эталонному набору. Как правило, является входным набором данных, получаемых из внешней информационной системы.

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

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

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

Критерий идентичности - формальное условие схожести двух строк (записей), которое может быть выражено в виде аддитивной величины.

Предметная область - множество объектов, рассматриваемых в пределах данного контекста. Под контекстом, в данном случае, понимается множество всех возможных значений (терминов).

Доменные знания - знания об иерархических отношениях сущностей и правилах формирования значений их атрибутов.

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

Источники информации

1. Э.Спирли, Корпоративные хранилища данных. Планирование, разработка и реализация. т. 1, "Вильямс", 2001 г.
2. Д.Кнут, Искусство программирования, т.3, "Вильямс", 2000 г.
3. Э.Сигел, Практическая бизнес-статистика, "Вильямс", 2002 г.
4. С. Рубцов, Опыт использования стандарта IDEF0, журнал "Открытые системы" №1, 2003 г.
5. Л.Бойцов, Современные поисковые системы: структуры данных и стратегии поиска, www.itman.narod.ru
6. П.Каньковски, "Как ваша фамилия?", или русский MetaPhone, журнал "Программист" №8, 2002 г., http://kankowski.narod.ru
7. Graham A. Stephen, String Search, Technical Report TR-92-gas-01 School of Electronic Engineering Science University College of North Wales Dean Street, Bangor, Gwynedd, UK LL57 1UT, October 1992, русский перевод: http://www.3ka.mipt.ru/vlib/books/Programming/ComputerScience/StryngAnalysis/index.html
8. Proceedings of the Workshop on Exact Matching Methodologies, Arlington, Virginia, Record linkage techniques 1985, May 9-10, 1985
9. R.Ananthakrishna1, S.Chaudhuri, V.Ganti, Eliminating Fuzzy Duplicates in Data Warehouses
10. L.G.Panagiotis, G. Ipeirotis, H. V. Jagadish, Using q-grams in a DBMS for Approximate String Processing

¹ - В данном контексте имеется ввиду не алфавит естественного языка, а набор символов, которые будут участвовать в процессе сравнения, что подразумевает возможность расширения или сужения данного алфавита по сравнению с естественным.
² - Однако необходимо упомянуть, что преобразование данных при инициализации (как эталонных, так и рабочих), включает в себя процесс нормализации строк, т.е. удаления незначимых символов и подмены всех возможных комбинаций разделителей одним пустым символом алфавита, что вполне допустимо, исходя из п.4, и позволяет повысить инвариантность представления атрибутов.
³ - Сравнение с фильтром и термин "фильтрация" использован не случайно, т.к. на каждой стадии происходит отсеивание данных (согласно п.8), что уменьшает нагрузку на каждую последующую стадию. Заметьте - только в последней стадии подразумевается участие оператора-человека, что полностью согласуется с одной из целей создания подсистемы.
⁴ - Величина критерия качества во многом зависит от предметной области, характера данных, полноты эталонных наборов и качества критериев идентичности, используемых при нечетком сравнении, что делает его достаточно объективным.
⁵ - Здесь имеется в виду возможность реализации на диалекте SQL, близком к стандарту SQL-92, т.е. не рассматриваются варианты с применением расширенных хранимых процедур и функций, реализованных на других языках программирования.
⁶ - Курсивом выделены совпадающие подстроки.
⁷ - Однако нужно учесть, что статистика работает с вероятностями, и это не дает 100% уверенности в правомочности исключения из процесса сравнения тех или иных конкретных слов.
⁸ - Не связанные с помощью механизма DRI (Declarative Referential Integrity).
⁹ - Эти таблицы могут быть временными, представлены с помощью VIEW и т.п.
¹⁰ - ОКАТО - Общероссийский классификатор объектов административно-территориального деления.
¹¹ - Общероссийский классификатор.