Базы данных. Принципы построения. Жизненный цикл БД.

Базы данных. Принципы построения. Жизненный цикл БД.

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

Система управления базами данных (СУБД) — это комплекс языковых и программных средств, предназначенный для создания, ведения и совместного использования БД многими пользователями. Обычно СУБД различают по модели данных.

К современным базам данных, а следовательно, и к СУБД, на которых они строятся, предъявляются следующие основные требования:

- Высокое быстродействие (малое время отклика на запрос).

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

- Простота обновления данных.

- Независимость данных.

- Совместное использование данных многими пользователями.

- Безопасность данных - защита данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения.

- Стандартизация построения и эксплуатации БД (фактически СУБД).

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

- Дружелюбный интерфейс пользователя.

Жизненный цикл БД. Как и любой программный продукт, база данных обладает собственным жизненным циклом (ЖЦБД). Главной составляющей в жизненном цикле бд является создание единой базы данных и программ, необходимых для ее работы. Жизненный цикл системы базы данных определяет и жизненный цикл всей информационной системы организации, поскольку база данных является фундаментальным компонентом информационной системы.

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

Этап концептуального проектирования заключается в описании и синтезе информационных требований пользователей в первоначальный проект БД. Исходными данными могут быть совокупность документов пользователя при классическом подходе или алгоритмы приложений (алгоритмы бизнеса) при современном подходе. Результатом этого этапа является высокоуровневое представление (в виде системы таблиц БД) информационных требований пользователей на основе различных подходов.

Технология оперативной обработки транзакции ( OLTP-технология).

Технология оперативной обработки транзакций (OLTP-технология) применяется в информационных системах для ввода, структурированного хранения и обработки информации в режиме реального времени. OLTP системы позволяют сгенерировать запросы типа: сколько? Где? И т.д. OLTP системы охватывают такие сферы как: автоматизация бухгалтерского и складского учета, банковская деятельность. Основная функция таких систем заключается в одновременном выполнении большого количества коротких транзакций от большого числа пользователей. Основным критерием при разработке таких систем является скорость и надежность выполнения транзакций.

Методология RAD

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

· небольшую команду программистов (от 2 до 10 человек);

· короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

1. фаза анализа и планирования требований;

2. фаза проектирования;

3. фаза построения;

4. фаза внедрения.

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

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

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

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

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

Каноническое проектирование ИС. Стадии и этапы процесса проектирования ИС. Состав работ на предпроектной стадии, стадии технического и рабочего проектирования, стадии ввода в действие ИС, эксплуатации и сопровождения.

Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.

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

Стадия 1. Формирование требований к ИС.

На начальной стадии проектирования выделяют следующие этапы работ:

· обследование объекта и обоснование необходимости создания ИС;

· формирование требований пользователей к ИС;

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

Стадия 2. Разработка концепции ИС.

· изучение объекта автоматизации;

· проведение необходимых научно-исследовательских работ;

· разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;

· оформление отчета и утверждение концепции.

Стадия 3. Техническое задание.

· разработка и утверждение технического задания на создание ИС.

Стадия 4. Эскизный проект.

· разработка предварительных проектных решений по системе и ее частям;

· разработка эскизной документации на ИС и ее части.

Стадия 5. Технический проект.

· разработка проектных решений по системе и ее частям;

· разработка документации на ИС и ее части;

· разработка и оформление документации на поставку комплектующих изделий;

· разработка заданий на проектирование в смежных частях проекта.

Стадия 6. Рабочая документация.

· разработка рабочей документации на ИС и ее части;

· разработка и адаптация программ.

Стадия 7. Ввод в действие.

· подготовка объекта автоматизации;

· подготовка персонала;

· комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

· строительно-монтажные работы;

· пусконаладочные работы;

· проведение предварительных испытаний;

· проведение опытной эксплуатации;

· проведение приемочных испытаний.

Стадия 8. Сопровождение ИС.

· выполнение работ в соответствии с гарантийными обязательствами;

· послегарантийное обслуживание.

Стадии и этапы создания ИС, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ

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

При разработке технического задания необходимо решить следующие задачи:

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

· разработать и обосновать требования, предъявляемые к подсистемам;

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

· установить общие требования к проектируемой системе;

· определить перечень задач создания системы и исполнителей;

· определить этапы создания системы и сроки их выполнения;

· провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.

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

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

В завершение стадии технического проектирования производится разработка документации на поставку серийно выпускаемых изделий для комплектования ИС, а также определяются технические требования и составляются ТЗ на разработку изделий, не изготовляемых серийно.

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

Для планирования проведения всех видов испытаний разрабатывается документ "Программа и методика испытаний". Разработчик документа устанавливается в договоре или ТЗ. В качестве приложения в документ могут включаться тесты или контрольные примеры.

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

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

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

9. Состав, содержание и принципы организации информационного обеспечения ИС.

Информационное обеспечение ИС является средством для решения следующих задач:

- однозначного и экономичного представления информации в системе;

- организации процедур анализа и обработки информации с учетом характера связей между объектами;

- организации взаимодействия пользователей с системой (на основе экранных форм ввода-вывода данных);

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

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

Информационное обеспечение ИС можно определить как совокупность единой системы классификации, унифицированной системы документации и информационной базы.

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

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

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

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

По сфере действия выделяют следующие виды классификаторов: международные, общегосударственные (общесистемные), отраслевые и локальные классификаторы.

Международные классификаторы входят в состав Системы международных экономических стандартов (СМЭС) и обязательны для передачи информации между организациями разных стран мирового сообщества.

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

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

Локальные классификаторы используют в пределах отдельных предприятий.

Каждая система классификации характеризуется следующими свойствами:

- гибкостью системы;

- емкостью системы;

- степенью заполненности системы.

Гибкость системы — это способность допускать включение новых признаков, объектов без разрушения структуры классификатора. Необходимая гибкость определяется временем жизни системы.

Емкость системы — это наибольшее количество классификационных группировок, допускаемое в данной системе классификации.

Степень заполненности системы определяется как частное от деления фактического количества группировок на величину емкости системы.

В настоящее время чаще всего применяются два типа систем классификации: иерархическая и многоаспектная.

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

Характерными особенностями иерархической системы являются:

1. возможность использования неограниченного количества признаков классификации;

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

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

Назначение:

· Формирование общероссийской базы данных резерва управленческих кадров для обеспечения потребностей кадровых служб органов государственной власти.

· Создание единой открытой базы данных вакансий по позициям государственной гражданской службы Российской Федерации.

· Информирование граждан о возможностях и перспективах государственной службы.

· Создание тематического информационного пространства для граждан России и государственных служащих.

Область применения: формирование кадрового состава государственной гражданской службы

Функции:

1. Публикация кадровыми службами государственных органов информации о вакантных должностях государственной гражданской службы, замещаемых как на конкурсной основе, так без нее.

2. Выдвижение государственными органами своих кандидатов (выдвиженцев) в кандидаты на включение в резерв управленческих кадров Российской Федерации.

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

4. Проверка Минздравсоцразвития России поданного кадровой службой государственного органа, комплекта документов и включение выдвиженца в резерв управленческих кадров Российской Федерации.

5. Заполнение и размещение кандидатами – гражданами России анкет (резюме) для включения их в состав кандидатов на включение в резерв управленческих кадров Российской Федерации.

6. Мониторинг кандидатами открытых вакансий в базе данных Портала.

7. Поиск кадровыми службами государственных органов кандидатов на открытые ею вакансии в базе данных Портала.

8. Обмен кандидатов и кадровых служб государственных органов положительными/отрицательными откликами на вакансии и анкеты (резюме).

9. Получение всеми посетителями Портала всесторонней информации о системе государственной гражданской службы Российской Федерации.

Пока только пять регионов РФ полностью закончили проектирование системы электронного межведомственного взаимодействия по услугам органов власти субъектов РФ. А 30% российских регионов даже не приступили к практическим шагам по переходу на "одну инстанцию".

Об этом свидетельствуют данные еженедельного мониторинга перехода на систему межведомственного взаимодействия.

Согласно мониторингу, на данный момент 70% субъектов РФ проводят практические мероприятия, необходимые для перевода с 1 июля госуслуг на принцип "одной инстанции". Полностью проектирование системы межведомственного взаимодействия госуслуг завершили пока только Башкирия, Кабардино-Балкария, Орловская, Волгоградская и Тюменская области.

В Самарской, Новгородской областях и Алтайском крае спроектировано от 90% до 100% госуслуг. Еще в 50 субъектах РФ эта доля колеблется от 1% (Петербург) до 85% (Республика Алтай). 24 региона пока не предприняли никаких действий по проектированию услуг органов власти субъектов РФ, предполагающих межведомственное взаимодействие. Среди них Якутия, Дагестан, Ленинградская, Нижегородская, Владимирская, Тульская области и т.д.

В среднем российскими регионами спроектировано около 30% из более 5,5 тыс. госуслуг органов власти субъектов РФ, предполагающих межведомственное взаимодействие. К примеру, Петербург, где проектирование услуг пока выполнено только на 1%, должен больше всего перевести госуслуг на межведомственное взаимодействие (181). Ростовская область из 145 госуслуг спроектировала электронное взаимодействие на 31%, Коми - на 22% из 138.

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

Все регионы России должны быть готовы по техническим стандартам к переходу на электронное межведомственное взаимодействие до 1 марта 2012 г., а с 1 июля следующего года должен быть осуществлен полный переход на эту систему с подключением всех муниципалитетов. Согласно Федеральному закону №210 "Об организации предоставления государственных и муниципальных услуг", с 1 октября 2011 г. ведомства не имеют права запрашивать у получателей госуслуг документы, имеющиеся в распоряжении других госорганов. Ведомства должны будут получать все необходимые документы друг у друга через систему межведомственного взаимодействия (см. новость ComNews от 20 сентября 2011 г.).

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

Сервис-ориентированная архитектура. Интеграция и взаимодействие информационных систем предприятия. Концепция сервис-ориентированной архитектуры. Типовое инфраструктурное программное обеспечение для интеграции данных.

Сервис-ориентированная архитектура: основные понятия

Очень часто становление того или иного подхода сопровождается появлением неверных или ошибочных трактовок, как это было, например, с концепцией федеративного Хранилища данных. Не миновала "сия чаша" и сервис-ориентированную архитектуру. Так, по крайне мере, считает представитель компании BEA Джерими Уэстерман (Jeremy Westerman). Именно поэтому в одной из своих статей, посвященных SOA, он специально останавливается на "проблемных местах" и приводит подробные пояснения:

SOA не является чем-то новым: IT-отделы компаний успешно создавали и развертывали приложения, поддерживающие сервис-ориентированную архитектуру, уже много лет - задолго до появления XML и Web-сервисов.

SOA - это не технология, а способ проектирования и организации информационной архитектуры и бизнес-функциональности.

Покупка самых новых продуктов, реализующих XML и Web-сервисы, не означает построения приложений в соответствии с принципами SOA.

Джерими Уэстерман дает следующее определение SOA: это парадигма, предназначенная для проектирования, разработки и управления дискретных единиц логики (сервисов) в вычислительной среде. Применение этого подхода требует от разработчиков проектирования приложений как набора сервисов, даже если преимущества такого решения сразу неочевидны. Разработчики должны "выйти за границы" своих приложений и подумать, как воспользоваться уже существующими сервисами, или изучить, как их сервисы могут быть использованы их коллегами.

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

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

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

Действительно, открытые стандарты, описывающие XML и Web-сервисы, позволяют применять SOA ко всем технологиям и приложениям, установленным в компании. Как известно, Web-сервисы базируются на широко распространенных и открытых протоколах: HTTP, XML, UDDI, WSDL и SOAP. Именно эти стандарты реализуют основные требования SOA - во-первых, сервис должен поддаваться динамическому обнаружению и вызову (UDDI, WSDL и SOAP), во-вторых, должен использоваться независящий от платформы интерфейс (XML). Наконец, HTTP обеспечивает функциональную совместимость.

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

Следствиями отсутствие должного решения проблемы интеграции являются:

· повторный ручной ввод данных (справочники, данные об отгрузках, финансовые транзакции и т.п.);

· многократные и бесконечные «сверки и корректировки» не исключающие ошибок;

· непомерные затраты на формирование сводной отчетности;

· неприемлемые сроки и себестоимость выполнения даже обыденных задач.

Общие цели интеграции приложений можно сформулировать следующим образом:

· уменьшить стоимость эксплуатации совокупности приложений предприятия;

· увеличить скорость выполнения типичных задач или гарантировать сроки их выполнения;

· поднять качество выполнения задач за счет формализации процессов и минимизации человеческого фактора, как основного источника ошибок.

В качестве целей конкретных интеграционных проектов обычно фигурируют более четкие формулировки. Например: «обеспечить формирование финансовой отчетности предприятия в срок не более одной недели после завершения финансового периода»; «уменьшить время оформления продажи с одного часа до 15 минут»; «уменьшить количество персонала, задействованного для поддержания в актуальном состоянии справочников и классификаторов, с 20 до пяти человек». Но обычно все, в конце концов, сводится к общим целям, которые можно сформулировать в еще более общем виде — уменьшить операционные расходы предприятия или организации. Поэтому интеграционные проекты часто оказываются в выигрышном положении с точки зрения обоснования перед людьми, принимающими решение о финансировании проектов: расчет показателей возврата инвестиций для таких проектов может выглядеть достаточно привлекательным.

Кто должен инициировать и стимулировать интеграционные проекты — бизнес или ИТ? Автор, выступая в качестве исполнителя работ, сталкивался с разными вариантами «спонсорства» таких проектов. Для любого ИТ-проекта чем сильнее заинтересованность в нем со стороны бизнес-подразделения, тем лучше. Однако для интеграционных проектов такая заинтересованность жизненно необходима. Дело в том, что подобрыне проекты обычно затрагивают интересы многих подразделений, каждое из которых видит только свою часть бизнес-процессов — одни готовят документацию, вторые оформляют накладные, третьи занимаются финансовыми операциями и т.д. Согласование и формализация требований разных подразделений становится очень трудной задачей; отсутствие среди «идеологических лидеров» проекта человека, которому подотчетны все задействованные подразделения, обычно означает провал проекта. Представители ИТ-служб в большинстве случаев не обладают необходимым уровнем влияния.

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

Интеграция данных (англ. — Data integration) — процесс объединения данных из различных источников для получения их согласованного представления, в широком смысле — процесс организации регулярного обмена данными между различными ИС предприятия.

Залогом успешной интеграции приложений и бизнес-процессов является интеграция данных и систем баз данных. Стандартами интеграции являются те форматы, которые поддерживают использование и распространение информации и бизнес данных, т.е. стандарты являются основой для проведения интеграции корпоративных приложений. К ним относятся COM+/DCOM, CORBA, EDI, JavaRMI и XML.

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