Односторонняя интеграция информационных систем в территориально распределённых организациях

• Автор: Тарханов, Иван Александрович
• Шифр специальности: 05.13.10
• Научная степень: Кандидатская
• Год защиты: 2009
• Место защиты: Москва
• Количество страниц: 134 с. : ил.

Оглавление
ВСТУПЛЕНИЕ

1. ОБЗОР ИНСТРУМЕНТОВ И СХЕМ ИНТЕГРАЦИИ.

1.1 Классификация инструментов интеграции.

1.1.1 Мировой опыт в интеграции корпоративных систем

1.1.2 Уровни интеграции .

1.2 Классификация участвующих в интеграции систем.

1.3 Территориально распределнные организации.

1.4 Интеграция с базами данных неподдерживаемых систем

1.4.1 Односторонняя интеграция информационных систем на уровне данных.

1.4.2 Неподдерживаемые базы данных

1.5 Обзор инструментов интеллектуального извлечения данных
1.6 Постановка задачи диссертационной работы
2. МОДЕЛЬ НЕПОДДЕРЖИВАЕМОЙ БД И АЛГОРИТМ ИЗВЛЕЧЕНИЯ ДАННЫХ
2.1 Односторонняя интеграция информационных систем
2.2 Неподдерживаемая реляционная модель данных
2.2.1 Реляционная модель данных.
2.2.2 Влияние проблем неподдерживаемых баз данных на схему отношения
2.2.3 Схема результирующего отношения.
2.3 Извлечение данных из неподдерживаемой БД
2.3.1 Алгоритм извлечения данных из неподдерживаемой БД.
2.3.2 Степень доверия запросу.
2.3.3 Вероятность достоверности атрибута
2.3.5 Вероятность искажения атрибута в схеме
2.3.6 Индекс соответствия запросу.
2.3.7 Особенности работы алгоритма
3. МЕТОДИКА И ПРОГРАММНЫЙ МОДУЛЬ ОДНОСТОРОННЕЙ ИНТЕГРАЦИИ
3.1 Методика односторонней интеграции.
3.1.1 Исследование возможностей использования с другими моделями БД.
3.1.2 Условия применения методики.
3.1.3 Расширения алгоритма
3.1.4 Интеграция с промышленными СУБД.
3.1.5 Основные этапы методики.
3.1.6 Сравнение с iv i .


л л
.
АО
.
.
.
.
.
.
3.1.7 Параметризация.
3.2 Программный модуль односторонней интеграции
3.2.1 Выбор инструментальных средств интеграции
3.2.2 Взаимодействие с БД
3.2.3 Реализация внешних вызовов.
3.2.4 Разбор файлов
3.2.5 Архитектура программного модуля
3.2.6 Функциональные возможности модуля
4. ПРАКТИЧЕСКИЙ ОПЫТ ОДНОСТОРОННЕЙ ИНТЕГРАЦИИ
4.1 Практические задачи интеграции
4.2 Одиостороння интеграция ЭАПУ и НТК СНУ
4.2.1 Представление данных в ПТК СПУ
4.2.2 Проблемы и требования организации интеграции ЭАПУ и ПТК СПУ.
4.2.3 Параметризация задачи поиска входящего номера в ПТК СПУ.
4.2.4 Оптимизация методики иод задачу интеграции ЭАПУ и ПТК СПУ.
4.2.5 Пользовательский интерфейс поиска входящих номеров в ЭАПУ1.
4.2.6 Результаты односторонней интеграции ЭАПУ и ПТК СПУ
ЗАКЛЮЧЕНИЕ
ЛИТЕРАТУРА


Свою задач}' 1С видит в продвижении идей интеграции - посредством обучения и «просвещения», а также через «продуманное лидерство». Под «продуманным лидерством» в 1С понимают предоставление возможности участвовать в деятельности консорциума не только крупнейшим игрокам на рынке ЕА1, но и наиболее выдающимся компаниям. Кроме того, для представителей бизнес-сообщества Ю является проводником их идей и ожиданий, поскольку они могут обращаться с поставщиками, «толкать» их на разработку продуктов, предназначенных для решения практических задач. Поэтому деятельность консорциума включает проведение семинаров, конференций, подготовку обучающих программ, написание методических пособий [1,2, 3, , ]. Организационно 1С состоит из ряда комитетов, которые занимаются различными направлениями интеграционных технологий. Как и в большинстве международных организаций но стандартизации, основная работа в консорциуме 1С осуществляется в-этих комитетах [1, , ]. Если же говорить об отечественной 1Т-индустрии, то наиболее ярким примером актуальности проблемы интеграции ИС является проведение ряда мероприятий в рамках федерально-целевой программы «Электронная Россия» [, , , ]. Задачей развития процедур электронного взаимодействия, разработки концепций информатизации в регионах [, , , ] является расширение возможностей обмена информацией и услугами между информационными системами органов государственной власти и хозяйствующих субъектов, развигие инфраструктуры, позволяющей максимально эффективно интегрировать их ресурсы и функции. Развитие единого стандартизованного механизма взаимодействия через среду прикладных информационных систем - перспективных, а также созданных, или создаваемых разработчиками на основе различных платформ и технологий. В многочисленных публикациях [2, 3, 4, 5, б], посвящённых современным решениям для EAI, принято все продукты разделять на классы или уровни. Для наглядности в данном обзоре речь пойдёт об уровнях интеграции. Будем считать, что программное решение относится к тому или иному уровню интеграции, если его функциональность полностью или частично удовлетворяет основным требованиям, предъявляемым к любому решению, инструменту на этом уровне. Эти требования, как правило, не имеют чёткой формулировки. Из-за этого часто возникает путаница, к какому уровню интеграции относить, гот или иной продукт и относить ли вообще. Приведённая ниже классификация является попыткой обобщения информации из различных источников, как связанных с IC, так и нет. Уровни интеграции явно устанавливают, как тесно должны интегрироваться программные продукты друг с другом, как сильно удалось абстрагироваться от технических особенностей используемого программного обеспечения, и насколько сильно связаны бизнес процессы интегрируемых систем. Естественно, всё это отражается на стоимости разработки и внедрения этих систем. Иерархия уровней интеграции, но идее, подразумевает, что если программный продукт удовлетворяет требованию определённого уровня, то он также удовлетворяет требованиям всех нижних уровней интеграции. Но на практике не всё так просто, в первую очередь, из-за огромного разнообразия инструментов интеграции и из-за серьёзных различий в их реализации [, ]. Не стоит забывать, что задача интеграции на предприятии усложняется ещё и необходимостью интеграции уже существующих и перспективных приложений в единую корпоративную ИС. В диссертации рассматривался именно такой случай. Возможно использование поэтапного, постепенного подхода к интеграции. Например, сначала добиться интеграции данных, а после успешного завершения этого этапа работ приступить к внедрению продуктов интеграции более высоких уровней [1, 3, 4, ]. Интеграция на уровне платформ это исходная точка интеграции практически для любых ИС, поэтому в многочисленных публикациях посвящённых интеграции [3, , , ], как правило, ничего по этому поводу не говорится. В частности, IC рассматривает только гораздо более сложные случаи интеграции. Но в диссертации необходимо упомянуть об этом, для того чтобы лучше представлять себе сам предмет исследования.