Обмен данными с внешними системами

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

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

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

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

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

а также:

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

Следует отметить, что при наследовании данных из старой системы проектировщикам не приходится надеяться на то, что кто-то создаст утилиту, позволяющую достать данные из старой системы, – обычно это становится задачей самих проектировщиков новой системы. Может случиться так, что вам придется работать в жестких условиях, когда не будет возможности выделить время для тестирования новой программы извлечения данных. В этом случае нужно разработать набор тестовых данных. Если в старой системе имеется какое-то средство извлечения данных – используйте его; часто это самый разумный выход.
При загрузке данных из старой системы проектировщики могут столкнуться с большим объемом неочищенных данных – с нарушениями целостности данных, возникшими из-за сбоев системы, «заплаток» разработчиков, иных неприятностей. Возможно, что на вас будет оказано давление с тем, чтобы допустить наличие неочищенных данных в новой системе. Если не принять мер по очистке данных, то, вероятно, большинство спроектированных ограничений целостности нужно будет ослабить, чтобы загрузить хоть какую-то часть данных. Цена такой уступки достаточно высока: данные вы приняли, но ослабленные ранее ограничения уже нельзя восстановить, так как они уже нарушены (это отслеживается СУБД автоматически). Отсюда следует вывод: поддаваться давлению нельзя, так как несколько дней, потраченных на очистку данных, стоят так мало по сравнению с наличием в информационной системе данных, не обладающих элементарной целостностью.
Что делать с данными, которые содержат ошибки или не согласованы? Самое простое решение -  пропускать такие данные, собирать их отдельно и анализировать. Здесь вас могут ждать некоторые проблемы: не все СУБД при загрузке данных их собственными утилитами позволяют в случае  возврата кода ошибки указать запись, на которой произошел сбой. Если это так, то данные следует загружать небольшими порциями, чтобы можно было легче найти запись, которая повлекла сбой. Можно разместить данные с нарушениями целостности в отдельных таблицах, а потом обработать их. Подобную операцию (которую аналитики, как правило, не предусматривают) лучше автоматизировать посредством отдельного компонента. Проектировщикам придется либо озадачить аналитиков исследованием правил корректности данных, либо выполнить эту работу самим, причем необходима помощь опытных пользователей старой информационной системы. Здесь крайне важно найти данные, которые являются надежными, то есть те, которые с большой вероятностью указаны правильно. От таких данных и надо отталкиваться при создании программ проверки корректности данных.
Далеко не все СУБД предоставляют средства, позволяющие выгрузить схему данных, хранимые процедуры и триггеры, но имеется достаточное количество ПО сторонних фирм, способного на это. Самым привлекательным будет ПО, осуществляющее выгрузку указанных объектов в виде скриптов, описывающих их создание. Если ПО позволяет сначала создать объекты данных без ограничений ссылочной целостности, а потом изменить их, добавив эти ограничения, то такой опцией рекомендуется пользоваться всегда. Дело в том, что большинство утилит выгрузки схемы опрашивают системный каталог и генерируют скрипт создания таблиц в том порядке, в котором имена таблиц встречаются в системном каталоге. Но вы не застрахованы от того, что имя таблицы-потомка будет считано раньше имени таблицы-предка. От исправления операций создания объектов данных вы также не застрахованы, так как у большинства СУБД разный синтаксис определения ограничений ссылочной целостности, серверных ограничений, индексов. Например, перечисленные ниже определения ссылочной целостности для таблицы tx:

create table t(id int primary key, name char(10);  

create table tx(i int, j int references t(id));  

create table tx(i int, j int references t(id) on delete no action on update no action);  

create table tx(i int, j int, foreign key j references t(id) on delete no action on update no action);  

create table tx(i int, j int, foreign key j references t on delete no action on update no action);  

create table tx(i int, j int, constraint t_ref_cascade foreign key j references t(id) on delete no action on update no action);  

все означают в точности одно и то же, но синтаксис у них разный. Для преобразования предложений SQL в требуемый формат могут быть созданы специальные утилиты. Поскольку в этом случае требуется разбор текста, то весьма нецелесообразно применение инструмента Perl. К сожалению, операция переноса хранимых процедур и триггеров не может быть в такой же степени автоматизирована вследствие существенных различий в языках их написания в разных СУБД. Некоторые СУБД совместимы по синтаксису хотя бы частично, но если этого нет, то большой доли ручной работы не избежать.