Содержание к диссертации
Введение
1. Обзор инструментов и схем интеграции 9
1.1 Классификация инструментов интеграции 9
1.1.1 Мировой опыт в интеграции корпоративных систем 9
1.1.2 Уровни интеграции 11
1.2 Классификация участвующих в интеграции систем 15
1.3 Территориально распределённые организации 17
1.4 Интеграция с базами данных неподдерживаемых систем 18
1.4.1 Односторонняя интеграция информационных систем на уровне данных 18
1.4.2 Неподдерживаемые базы данных 20
1.5 Обзор инструментов интеллектуального извлечения данных 24
1.6 Постановка задачи диссертационной работы 29
2. Модель неподдерживаемой бд и алгоритм извлечения данных 31
2.1 Односторонняя интеграция информационных систем 31
2.2 Неподдерживаемая реляционная модель данных 31
2.2.1 Реляционная модель данных 31
2.2.2 Влияние проблем неподдерживаемых баз данных на схему отношения 33
2.2.3 Схема результирующего отношения 35
2.3 Извлечение данных из неподдерживаемой БД 40
2.3.1 Алгоритм извлечения данных из неподдерживаемой БД 40
2.3.2 Степень доверия запросу 41
2.3.3 Вероятность достоверности атрибута 45
2.3.5 Вероятность искажения атрибута в схеме 46
2.3.6 Индекс соответствия запросу 47
2.3.7 Особенности работы алгоритма 52
3. Методика и программный модуль односторонней интеграции 54
3.1 Методика односторонней интеграции 54
3.1.1 Исследование возможностей использования с другими моделями БД 54
3.1.2 Условия применения методики 59
3.1.3 Расширения алгоритма 62
3.1.4 Интеграция с промышленными СУБД 67
3.1.5 Основные этапы методики 73
3.1.6 Сравнение с Knowledge Discovery in Database 75
3.1.7 Параметризация 79
3.2 Программный модуль односторонней интеграции 84
3.2.1 Выбор инструментальных средств интеграции 86
3.2.2 Взаимодействие с БД 86
3.2.3 Реализация внешних вызовов 90
3.2.4 Разбор файлов 93
3.2.5 Архитектура программного модуля 94
3.2.6 Функциональные возможности модуля 97
4. Практический опыт односторонней интеграции 100
4.1 Практические задачи интеграции 100
4.2 Одностороння интеграция ЭАПУ и ПТК СПУ 102
4.2.1 Представление данных в ПТК СПУ 105
4.2.2 Проблемы и требования организации интеграции ЭАПУ и ПТК СПУ 106
4.2.3 Параметризация задачи поиска входящего номера в ПТК СПУ 107
4.2.4 Оптимизация методики под задачу интеграции ЭАПУ и ПТК СПУ 110
4.2.5 Пользовательский интерфейс поиска входящих номеров в ЭАПУ 111
4.2.6 Результаты односторонней интеграции ЭАПУ и ПТК СПУ 115
Заключение 117
Литература.. 119
Приложение 127
- Односторонняя интеграция информационных систем на уровне данных
- Влияние проблем неподдерживаемых баз данных на схему отношения
- Сравнение с Knowledge Discovery in Database
- Проблемы и требования организации интеграции ЭАПУ и ПТК СПУ
Введение к работе
В процессе увеличения масштаба, усложнения архитектуры, наращивания функциональных возможностей и автоматизации новых сфер деятельности многие информационные системы (далее ИС) сталкиваются с проблемой интеграции с другими ИС. Часто возникают ситуации, в которых несколько ИС становятся частью одного бизнес процесса, хотя изначально никакого взаимодействия между ними не планировалось. В этой ситуации появляется задача организации необходимого взаимодействия минимальными изменениями в существующих информационных системах предприятия (далее корпоративной ИС).
Сейчас на рынке предлагается огромное количество инструментов для интеграции от разных производителей. При рассмотрении вопроса внедрения новой ИС в существующую корпоративную ИС предприятия, требования к интеграции, заложенные в новую ИС, в настоящее время являются одними из ключевых. На данный момент, сегмент услуг по интеграции корпоративных приложений считается одним из самых бурно .развивающихся сегментов ИТ-индустрии (см. по [1, 2, 3, 4, 68, 69, 70, 73]). По прогнозам IDC, рынок программного обеспечения, предназначенного для решения интеграционных задач, составит в 2008 году 8,2 $млрд. против 4,3 $млрд. в 2001 году [4, 73]. ,
Проблемы интеграции внедряемых и уже внедрённых ИС не удается избежать ни одной территориально распределённой компании, обладающей развитой структурой приложений в каждом региональном представительстве. Существует несколько основных способов организации взаимодействия, но если нельзя вносить изменения в код уже внедрённых систем, многие из них не подходят. В таком случае, организация доступа к базам данных (БД) внедрённой ИС напрямую становится практически единственным возможным способом интеграции.
Каждая ИС имеет вход и выход в рамках общего бизнес процесса. Вход и выход неизменяемой. внедрённой системы тоже не меняется. Поэтому, в силу сложившихся обстоятельств, внедряемой системе остаётся научиться работать с входом и выходом из системы внедрённой. В случае, когда вся работа по организации интеграции проводится в одной системе имеет, место односторонняя интеграция.
Не редка , ситуация, что при неправильной эксплуатации системы, наличии материальных, технических трудностей, большой географической распределенности компании с БД такой РІС становится трудно работать. Возможны нарушения и ошибки при вводе данных, появление избыточной или дублирующей информации в БД, несоответствие реально хранящейся в БД информации об объектах понятийным и декларативным знаниям о них. Трудно извлекать какую либо информацию из таких БД, даже если их формат известен. Такие БД называются неподдерживаемыми. На рынке существует ряд программных средств решающих, в том числе, и описанные проблемы. Большинство из них относятся к классу Data Mining. Обычно их разделяют на аналитические платформы и СУБД с набором алгоритмов Data Mining. Ориентированность первых из них на более широкий круг задач и анализ всего массива данных приводит к невозможности использования их динамически, с многократными обращениями к БД, накладывает существенные ресурсные и временные ограничения. Вторые показывают отличные результаты только на СУБД определённых производителей и требуют дополнительной разработки при интеграции с существующими системами.
Кроме того, проблемы односторонней интеграции и задача поиска и извлечения данных из неподдерживаемой реляционной БД не обладают достаточной теоретической проработкой и характеризуются отсутствием концептуального подхода к решению. Отсюда и вытекает актуальность предложенной темы диссертации.
Односторонняя интеграция информационных систем на уровне данных
Вернёмся к рассмотрению исходной ситуации— необходимо интегрировать внедряемую систему в уже существующий бизнес процесс предприятия. Ясно, что в эту систему изначально должны быть заложены возможности интеграции с внедрённым ранее парком программного обеспечения с учётом того на сколько возможно изменение уже внедрённых систем. Если внедрённые системы, участвующие в интеграции, не поддаются модификации или поддаются с трудом, то имеет место «односторонняя интеграция». Остановимся на этом понятии подробней.
Что означает термин «односторонняя интеграция»? Чаще всего это выражение встречается в новостях, когда она политическая сила предпринимает шаги к сближению, а другая нет. В случае информационных технологий картина похожая. Но в данном контексте вектор такой интеграции всегда или почти всегда идёт от внедрённого приложения к внедряемому. Каждая ИС имеет вход и выход в рамках общего бизнес процесса. Вход и выход неизменяемой внедрённой системы тоже не меняется. Поэтому, в силу сложившихся обстоятельств, внедряемой системе остаётся научиться работать с входом и выходом из системы внедрённой. В случае, когда вся работа по организации интеграции проводится в одной системе, имеет место односторонняя интеграция [14] . Более формальное определение этому термину будет дано во второй главе диссертации.
Во многих случаях этих входов и выходов оказывается недостаточно для реализации необходимые; функциональных возможностей. Нужно внести изменения в внедрённую ИС для того, чтобы у нее появились дополнительные входы и выходы. Здесь нужно чётко понимать, какие изменения возможны в рамках рассматриваемых систем [14]: Предоставить внешний интерфейс для доступа к функционалу внедрённой системы. Требуется изменение кода внедрённой системы. Требуется интеграция более высокого уровня, чем интеграция на уровне данных. Разработать дополнительный модуль для существующей системы, который будет обмениваться данными с внедряемой системой через специализированный формат обмена. Изменение кода самой внедряемой системы, возможно, не потребуется, но необходима разработка дополнительного модуля. Типичное решение интеграции на уровне данных. Реализовать во внедряемой ИС прямой доступ к базе данных внедрённой ИС. Изменение кода внедрённой системы не требуется. Каждый из способов имеет свои достоинства и недостатки. Первое и второе решение может оказаться невозможным в случае, если внедрённая ИС в принципе не поддерживается. Важно отметить, что третий подход может оказаться не только самым простым в реализации, но и самым эффективным, если необходимо только извлекать данные из базы данных внедрённой ИС, и нет необходимости изменять эти данные (необходим режим «только для чтения»). Третье решение имеет несколько аспектов [14]: Оно может оказаться крайне сложным из-за того, что внедряемая ИС использует устаревшую СУБД и/или устаревшую платформу (например, внедрённая ИС использует СУБД типа Clarion или Clipper под MS-DOS, а новая разрабатывается под Windows с применением промышленной СУБД). Оно приводит к тому, что часть кода будет дублироваться — она будет реализована и во внедрённой, и во внедряемой ИС. Эти две реализации могут оказаться не полностью идентичными, и тогда в базе данных внедрённой ИС может возникнуть несогласованность. Оно требует решения вопроса с защитой данных в базе внедрённой ИС. Может потребоваться создание дополнительных пользователей, создание представлений, расстановка прав доступа. Т.е. несмотря на то, что внедрённая ИС в целом не модифицируется, на уровне базы данных может потребоваться внесение изменений. Основой реализации прямого доступа к данным не поддерживаемой внедрённой системы является поиск необходимой информации в её базе данных. Естественно, сам процесс поиска зависит от типа базы данных и от используемой в ней модели данных. Обычно их классифицируют по времени появления. Перечислим наиболее популярные: 1. Иерархическая. Схема базы данных представляет собой обобщенное дерево. Доступ к данным только навигационный, язык запросов отсутствует [27, 29, 30]. 2. Сетевая. Модель состоит из записей, элементов данных и связей типа «один ко многим», установленных между записями. Также как и в иерархической модели, доступ к данным только навигационный, язык запросов отсутствует [27]. 3. Реляционная. Наиболее распространенная в настоящее время модель. Язык запросов реляционных СУБД — SQL (Structured Query Language). Практически каждая реализация имеет собственный диалект этого языка, но общее ядро достаточно велико, чтобы рассматривать все реляционные СУБД как SQL-совместимые [27, 29, 30]. 4. Объектно-ориентированная. Развивающееся в последние годы направление. В настоящее время вышла уже третья редакция стандарта ODMG, описывающего ООСУБД и 00 хранилища. Язык запросов ООСУБД - OQL (Object Query Language), который позиционируется авторами как объектное расширение языка SQL. [27, 28, 29]. 5. Объектно-реляционная. Под объектно-реляционными СУБД понимаются, как правило, реляционные СУБД, имеющие разного рода объектные расширения над реляционными данными. Получили развитие одновременно с появлением ООСУБД, как более простая альтернатива БД с 00 структурой. Язык запросов -SQL [27]. 6. Документная. Это новое направление в области СУБД. Оно появилось после того, как достаточно широкое распространение получил язык XML и связанные с ним стандарты. Документная база данных - это хранилище XML-документов [27]. 1 и 2 практически не используются. В диссертации наибольшее внимание уделено поиску в БД с реляционной моделью, как наиболее распространённой на данный момент. Именно реляционные БД чаще всего используются в неподдерживаемых внедрённых системах. Кроме повсеместно распространённых реляционных СУБД растёт популярность объектно-ориентированных и объектно-реляционных СУБД. Следовательно, имеет смысл изучить и возможности интеграции с БД не только с реляционной моделью данных. Существует несколько способов доступа к СУБД из программы: Интерфейсы программного доступа. Они позволяют использовать произвольную СУБД без перекомпиляции системы. Более того, возможна даже поддержка СУБД, которой не существовало на момент написания программного комплекса. Существует несколько видов программных интерфейсов: о Частный API конкретной СУБД. о ODBC/JDBC (Open DataBase Connectivity). о ШАРІ (Integrated DataBase API). Встроенный (embedded) SQL. Позволяет получить максимальное быстродействие благодаря прекомпиляции запросов и использованию параметризованных запросов. Однако модули со встроенным SQL невозможно переключить на другую СУБД, поскольку требуются изменения в исходных текстах и перекомпиляция системы.
Влияние проблем неподдерживаемых баз данных на схему отношения
Описанные выше механизмы реляционной алгебры обладают одним важным свойством: они замгагуты относительно понятия отношения. Это означает, что выражения реляционной алгебры и формулы реляционного исчисления определяются над отношениями реляционных БД и результатом их «вычисления» также являются отношения. В результате любое выражение или формула могут интерпретироваться как отношения, что позволяет использовать их в других выражениях или формулах. Ряд проблем приводят к тому, что хранящаяся в БД информация неадекватно описывает предметную область. Рассмотрим влияние проблем неподдерживаемых БД в территориально распределённых организациях, подробно описанных в 1-ой главе, на схемы (заголовок) отношений более детально.
Частичное отсутствие информации о схеме БД. Необходимо сказать, что под словами «отсутствие информации о схеме БД» подразумевается отсутствие информации у пользователя (информационной системы) о схеме отношений в БД. При этом в самой БД будут корректные и вполне содержательные данные, удовлетворяющие требованиям её целостности. Покажем это на простом примере: есть отношение СОТРУДНИКИ, схема которого состоит из следующих атрибутов {НОМЕР_СОТРУДНИКА, ИМЯ_СОТРУДНИКА, ФАМИЛИЯ_СОТРУДНИКА, ВРЕМЯ_НА_РАБОТЕ}. В процессе использования БД филиалом А компании возникла потребность в хранении информации о зарплате сотрудников, для этого было добавлен новый атрибут ЗАРПЛАТА. При этом другим отделам, работающим с этой БД ничего про новый атрибут в схеме СОТРУДНИКИ неизвестно. Они могут использовать для тех же самых целей отношение ЗАРПЛАТА{НОМЕР_СОТРУДНИКА, ЗАРПЛАТА}, про которое, в свою очередь ничего не знают в филиале А. Тем самым схема базы данных становится избыточна (появляется дублирующая информация). Проще говоря, в схему БД добавляются новые атрибуты или целые отношения. Технические трудности. Рассмотрим отношение из предыдущего примера. В филиале Б компании в отношении СОТРУДНИКИ интенсивно обновляется значение атрибута ВРЕМЯ_НА_РАБОТЕ в процессе работы, что затрудняет доступ сразу нескольких пользователей к данным отношения. Для того, чтобы можно было осуществлять работу с именами сотрудников, в БД создаётся новое отношение ИМЕНА_СОТРУДНИКОВ{ НОМЕР_СОТРУДНИКА, ИМЯ_СОТРУДНИКА, ФАМИЛИЯ_СОТРУДНИКА}, а аналогичные атрибуты в отношении СОТРУДНИКИ либо перестают заполняться и использоваться, либо вообще удаляются из отношения. Очевидны проблемы при работе с этой БД пользователей из других филиалов компании и других ИС, которые ничего не знают про отсутствие атрибутов или целых отношений изначально в схеме присутствовавших. Неоднородность наполнения. Вернёмся опять к отношению СОТРУДНИКИ. В филиале В было принято решение, что удобнее использовать для хранения имени, фамилии и отчества сотрудника один атрибут ИМЯ_СОТРУДНИКА. Поэтому домен (тип) атрибута ИМЯ_СОТРУДНИКА меняется. Теперь это не множество всех возможных имён, а множество всех возможных сочетаний фамилии, отчества и имени. Изменение домена, на котором определён атрибут схемы в отношении назовём изменение атрибута. Здесь приведены простые примеры того, что происходит со схемой в неподдерживаемой БД. Любая из перечисленных проблем, подробнее описанных в первой главе диссертации, может привести к добавлению, отсутствию атрибутов и отношений в схеме БД или их изменению. Рассмотрим подробнее изменение атрибута: атрибут может изменить имя или домен. На практике изменение домена происходит очень часто. Перечислим основные виды изменения домена атрибута в схеме отношения: Отсутствие полноты информации. Например, в одном ведомстве реквизит имеет принципиальное значение и заполняется полностью, а в другом ведомстве этот же реквизит не носит обязательного характера и может заполняться нерегулярно или отсутствовать. Пример: в одной из баз данных имя и отчество заполняют не полностью, а только инициалы. Ошибки при вводе. В одной из БД значение атрибута может быть занесено с ошибкой или опечаткой. Отсутствие актуальности информации. В одной из БД значение атрибута актуализировано, а в другой нет. Например, гражданин поменял фамилию - в одну из БД информация уже попала, а в другую еще нет. Выше были определены «элементарные» действия, которые выполняются со схемой и приводят базу данных в неподдерживаемое состояние. Описывая схему неподдерживаемых баз данных, необходимо знать, как менялась схема всех отношений в базе данных: какие атрибуты обновлялись, удалялись и искажались. Имея «наглядный» формат записи изменений, удобней сравнивать и выявлять все проблемы, возникающие во время эксплуатации БД. Определение 1. Удалённым атрибутом а" в заголовке Нг отношения г называется атрибут, который был удалён из начального заголовка Нг. Определение 2. Добавленным атрибутом а+ в заголовке Нг отношения г называется атрибут, который был добавлен в начальный заголовок Нг отношения. Перед тем, как определить искажения атрибута, нужно помнить, что атрибут в схеме отношения это пара - имя и домен. Следовательно, изменять можно как домен, так и имя атрибута. Отдельно стоит рассмотреть причины изменения домена. При реальной эксплуатации БД, в понятие домена вкладывается гораздо больше, чем просто множество допустимых значений. Определение 3. Искажённым атрибутом af в заголовке Нг отношения г называется атрибут, у которого был изменён тип: Определение 4. Переименованным атрибутом ал в заголовке Нг отношения г называется атрибут, у которого было изменено имя: Удалённым, добавленным, переименованным или искажённым может быть как один атрибут, так и все атрибуты, входящие в заголовок отношения. Возможно одновременное искажение - несколько искажений в одной БД: Одновременное добавление, переименование и удаление в одной БД не возможны. В территориально распределённых организациях одна схема отношения может использоваться в физически разных БД. Чтобы отобразить все изменения начальной схемы нужно последовательно учесть изменения во всех заголовках отношений во всех использующігх данную схему базах данных. Начальная схема Нг отношения г использовалась в трёх базах данных, где в процессе её изменения образовалось три новых схемы Нгх, Нг2, Нгг. Затем все изменения всех трёх схем были отражены в результирующей схеме Нгд. Для всех изменений атрибутов возможны параллельные изменения. Несколько параллельных изменений одно и того же атрибута не возможны в одной БД: Определение 5. Результирующим заголовком НгЛ отношения г называется заголовок, в котором последовательно отражены все изменения атрибутов (добавление, удаление, переименование и искажение) относительно начального заголовка Нг. Если в процессе эксплуатации БД заголовок отношения не менялся, то НгЛ = Нг. В процессе эксплуатации разных баз данных с одной и той же схемой могут произойти разные изменения одного и того же атрибута в схеме. В этом случае в результирующий заголовок попадут все изменения.
Сравнение с Knowledge Discovery in Database
Перед тем, как перейти к рассмотрению технических особенностей реализации методики, нужно уделить внимание основным её отличиям от стандартного Knowledge Discovery in Database (KDD). Knowledge Discovery in Databases - это процесс поиска полезных знаний в «сырых» данных. KDD включает в себя вопросы: подготовки данных, выбора информативных признаков, очистки данных, применения методов Data Mining (DM), постобработки данных и интерпретации полученных результатов. Безусловно, «сердцем» всего этого процесса являются методы DM, позволяющие обнаруживать знания. Сейчас KDD является стандартом, которого так или иначе придерживаются все современные методики, применяющие инструментарий DM. Процесс Knowledge Discovery in Databases, состоит из следующих шагов: 1. Подготовка исходного набора данных. Этот этап заключается в создании набора данных, в том числе из различных источников, выбора обучающей выборки и т.д. Для этого должны существовать развитые инструменты доступа к различным источникам данных. Желательно иметь поддержку работы с хранилищами данных и наличие семантического слоя, позволяющего использовать для подготовки исходных данных не технические термины, а бизнес понятия. 2. Предобработка данных. Для того чтобы эффективно применять методы Data Mining, следует обратить внимание на вопросы предобработки данных. Данные могут содержать пропуски, шумы, аномальные значения и т.д. Кроме того, данные могут быть избыточны, недостаточны и т.д. В некоторых задачах требуется дополнить данные некоторой априорной информацией. Наивно предполагать, что если подать данные на вход системы в существующем виде, то на выходе получим полезные знания. Данные должны быть качественны и корректны с точки зрения используемого метода DM. Поэтому первый этап KDD заключается в предобработке данных. Более того, иногда размерность исходного пространства может быть очень большой, и тогда желательно применять специальные алгоритмы понижения размерности. Это как отбор значимых признаков, так и отображение данных в пространство меньшей размерности. 3. Трансформация, нормализация данных. Этот шаг необходим для приведения информации к пригодному для последующего анализа виду.
Для чего нужно проделать такие операции, как приведение типов, квантование, приведение к «скользящему окну» и прочее. Кроме того, некоторые методы анализа, которые требуют, чтобы исходные данные были в каком-то определенном виде. Нейронные сети, скажем, работают только с числовыми данными, причем они должны быть нормализованы. 4. Data Mining. На этом шаге применяются различные алгоритмы для нахождения знаний. Это нейронные сети, деревья решений, алгоритмы кластеризации, установления ассоциаций и т.д. 5. Постобработка данных. Интерпретация результатов и применение полученных знаний в бизнес приложениях. 6. Knowledge Discovery in Databases не задает набор методов обработки или пригодные для анализа алгоритмы, он определяет последовательность действий, которую необходимо выполнить для того, чтобы из исходных данных получить знания. Данный подход универсальный и не зависит от предметной области, что является его несомненным достоинством. Описанная в диссертации методика односторонней интеграции во многом повторяет основные этапы KDD, но и имеет свои уникальные отличия. В методике так же выделяется 5 основных этапов: 1. Постановка задачи 2. Предварительный анализ 3. Первичная выборка 4. Работа алгоритма 5. Постобработка и интерпретация Рисунок 14. Методика односторонней интеграции н KDD Но они во многом сильно различаются: В методике существует довольно продолжительный этап подготовки, выделяющий исходные данные. Тем самым, первых два этапа методики соответствуют одному этапу «Подготовка исходного набора данных» в KDD. В KDD делается предобработка данных, как правило, полная выборка исходных данных. В случае методики, как таковой предобработки нет. Делается лишь первичная выборка, которая существенно уменьшает количество рассматриваемых данных. Этот этап в методике может и отсутствовать. Этапа «трансформации» нет в методике, в отличие от KDD. В методике данные для анализа в алгоритме поиска имеют тот же вид, что и в самой БД, поэтому смысла в этом этапе нет. Напомним, что исключение предварительной выгрузки всех данных - одна из задач при разработке инструмента интеграции на основе представленной в работе методики. Этапу Data Mining в KDD соответствует этап применения алгоритма поиска в неподдерживаемой БД В KDD этап «постобработки» и «интерпретации» соединены в один. В методике постобработки может и не быть, всё зависит от условий исходной задачи. А под «интерпретацией» понимается совсем другое: в KDD это не только полученный результат, но и параметры исследуемой задачи, которые выгружаются в некоторый шаблон для последующего применения в других местах. В методике же такой шаблон создаётся на первом и втором этапе. А под «интерпретацией» понимается простая передача результата в приложение в виде отсортированного отношения search, прошедшего постобработку. Видно, что за счёт предварительного анализа задачи удалось исключить такие подготовительные этапы как трансформацию данных.
Сердцем методики, как в KDD Data Mining, является алгоритм, по которому вычисляется QCI с последующей постобработкой. Преимущества данной методики: Во время анализа и постановки задачи не нужно обращаться к самим данным. Необходима только проверка схемы анализируемого отношения. Число запросов сведено к минимуму. Есть несколько вариантов увеличения скорости работы за счёт использования первичной выборки, сортировки, группировки и дополнительных вычислений прямо в SQL или собственной реализаций этих действий. Есть несколько механизмов проверки результатов запросов: слияние нескольких результатов в один, использование упрощённых режимов работы, таких как, идентификация. Проверка по заведомо известным атрибутам. Нет предварительной выгрузки, возможность работы с данными напрямую - «на лету». Недостатки: Не удалось разработать систему без обратной связи (автоматическое нахождение оптимальных параметров и коэффицентов). В качестве меры, позволяющей уменьшить влияние эксперта, предполагается ввести некоторый элемент «обучения» в процессе работы. Алгоритм сам не меняет начальные коэффициенты доверия запросу в случае необходимости. Качественно проработать такую «обратную связь» мешает слишком сильная зависимость её от конкретной задачи поиска. Коэффициент доверия отражает лишь зависимость объекта поиска от атрибута и условия на него «в целом». Другое условие на этот атрибут может иметь совсем другой коэффициент. Но хранить и использовать всю историю изменения коэффициентов, а так же анализировать и проверять, как эти изменения влияют на результат без предварительной выгрузки и многократного прохода по данным тяжело. Зависимость от правильной оценки эксперта. Методика не решает главных проблем при поиске в БД: проблемы определения функциональных зависимостей. Если эти зависимости определены не верно, то с большой долей вероятности алгоритм будет не эффективен. Использование коэффициентов доверия для определения зависимости результата поиска от его условий является достаточно грубой оценкой. Алгоритм предполагает, что эти коэффициенты определяются экспертом предметной области. Нет никакой гарантии эффективной работы алгоритма, в случае ошибки эксперта.
Проблемы и требования организации интеграции ЭАПУ и ПТК СПУ
Несколько особенностей хранения пачек в ПТК СПУ существенно усложняют задачу интеграции: 1. Для некоторых типов документов (например, ведомость уплаты страховых взносов) информация об описи отсутствует в базе ПТК СПУ. 2. Возможны случаи, когда в документном представлении отсутствует информация о пачке совсем или об отдельных документах пачки. 3. Нет точного соответствия представления в базе данных и типа документа в пачке. Например, информация о документах из пачки индивидуальных сведений может содержаться как в одном из двух представлений («старые» и «новые» индивидуальные сведения). 4. Существует трудность в установлении уникальности записи по документным представлениям. Каждое из представлений имеет свой набор полей и особенности их заполнения. В некоторых региональных представительствах поля сумм, фамилий и имён не заполняются или заполняются по-разному. 5. Существует семь версий форматов файлов персонифицированного учета (четыре текстовых формата и три XML формата). При обращении к представлениям ПТК СПУ необходимо разбирать все типы документов во всех форматах. 6. Проблема производительности.
В региональных базах ПТК СПУ представления могут содержать по несколько десятков тысяч записей, по этому «цена» каждого запроса к базе ПТК СПУ очень высока. 7. Неоднородность региональных баз ПТК СПУ. На некоторых региональных серверах отсутствуют представления для некоторых типов документов. Не всегда актуальна информация, представленная в разных представлениях. Из описания проблематики и общего устройства представлений ПТК СПУ видна сложность однозначного поиска входящего номера для пачки при вводе в Архив. Отсюда, вытекает несколько очевидных требований по организации поиска: Согласно пунктам 1 и 2 предыдущего списка, нужно осуществлять отдельно поиск по таблице описей и отдельно по таблице документов. Т.е. модулю интеграции в качестве параметров указывается минимум два запроса. Результатом поиска обоих является один и тот же объект, пара код района и входящий номер. Согласно пунктам 3 и 4 предыдущего списка, необходимо строить результирующие схемы для представления по описям (VPRM) и для представлений, соответствующим всем искомым типам документов. А так же нужно анализировать возможность изменения каждого атрибута в этих представлениях, поскольку почти каждый из них может быть полезен при определении входящих номеров пачки. Пункт 5 предыдущего списка накладывает необходимость более детального разбора и доступа к информации из файлов с ЭЦП всех форматов. Это требование не касается задачи поиска непосредственно, но очень важно при формировании условий запроса по документам. Пункт 7 заставляет обязательно проверять, существует ли необходимое представление, все его атрибуты и делать запрос к нему максимально оптимизированным.
При поиске по описи в представлении VPRM есть три реквизита, который никак не изменяются в результирующей схеме: страховой номер, отчётный период, дата ввода. Но этих трёх реквизитов не достаточно, чтобы определить однозначно номер пачки, т.к. от одного и того же страхователя в один и тот же период времени может поступить несколько пачек. Можно было бы для поиска описей применить упрощённый вариант оценки для идентификации пачки по весам атрибутов, но остальные атрибуты меняют своё состояние в результирующей схеме, поэтому задача усложняется. Помимо трудностей, упомянутых в предыдущем разделе, существует ещё несколько проблем, возникающих в региональных БД ПТК СПУ. Реквизиты, в которых хранится тип и количество документов в представлении об описи пачки, могут отсутствовать в схеме и в них может быть ошибка при вводе. Реквизит номер пачки может вообще не заполнятся или быть не актуальным. С представлениями, в которых хранится информация о документах пачки, тоже существует ряд проблем. Индивидуальные сведенья делятся на два типа: новые и старые. Вводя файл индивидуальных сведений в ЭАПУ не попятно, к какому именно типу он относится. По этому, необходимо делать два запроса к каждому из отношений, а результаты каким-то образом складывать. Существует проблема ввода сумм в индивидуальных сведеньях и ведомостях уплаты. Часто эти суммы вводятся без копеек, хотя форматом ввода положено вводить с копейками. Даже если таковых нет. Более того, в некоторых случаях происходит округление сумм с точность до десятков копеек. Природу этого «округления» установить не удалось. Похожая проблема с именами в документных представлениях, а точнее в индивидуальных сведениях и анкетах. Во-первых, не факт, что в разных документах фигурирует один и тот же человек. В региональных представительствах возможно появление не только однофамильцев, но и людей у которых совпадают имена и отчества. Некоторые документы в пачках могут быть признаны не действительными и не принимаются. Но в целом пачка проходит проверку и вводится в БД ПТК СПУ. Отсутствие одного из документов, а так же неверное количество документов в пачке не должно полностью определять результат поиска этой пачки в БД. Необходимость гибких настроек для каждого из запросов при поиске и его параметризация была очевидна уже при постановке задачи односторонней интеграции ЭАПУ и ПТК СПУ. В ЭАПУ для этого используется текстовый файл - PfrArchiveUser.ini. По каждому запросу вычисляется степень доверия. Для запросов к документным представлениям оно чуть выше (больше 0.95), так как в каждом представлении большое количество атрибутов, по которым можно определить пачку. А ошибки в суммах или фамилии не сильно влияют на конечный результат. Для запросов по- описи степень соответствия запросу ниже, так как многие важные для идентификации пачки поля вообще не заполнялись.
