Загрузка и выгрузка данных

в этой главе:

Работа с внегатит састе.иа.мп

Вопросы совместимости II датпнх

Этапы переноса данных

Трансформация данных

Форматы файлов

Упорядочение, восстаиовлепне

и настоша фиксации

Иеполмование SQL*Londer

Ии Oracle? в Oracle?: особый случаи

Выходные данные

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

Работа с внешними системами

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

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

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

Типы интерфейсов

Внешние интерфейсы можно разбить на две категории:

осуществляющие одноразовый (не считая тестовых прогонов) прием исходных данных;

поддерживающие периодический обмен данными с другими действующими системами.

Если обмен данными должен осуществляться в условиях, приближенных к режиму реального времени, и не может выполняться регулярно, то его следует рассматривать как составную часть общей стратегии распределенной базы данных, а не просто как задачу подачи данных. Этой теме посвящена глава 12. Здесь же мы просто отметим, что использование реально-временного канала связи с унаследованными данными позволяет исключить из операций обмена определенную группу сущностей, если требуемая скорость доступа может быть обеспечена распределенной технологией.

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

Задачи проектировщика

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

определить, каким системам нужен интерфейс;

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

установить, какая требуется степень синхронизации двух систем;

исследовать методы транспортировки данных (файловые, коммуникационные и т.д.);

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

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

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

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

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

создать обшие правила регистрации операций пересылки данных (в систему и из системы);

начать составление плана ночных пакетных операций для периодического обмена. Закончить составление плана можно только при рассмотрении его в контексте с другими пакетными операциями в системе;

согласовать график разработки, стратегию и план тестирования с проектировщиками другой системы;

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

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

Работая вльесте с противоположной стороной

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

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

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

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