BorlandC++Builder1

      Перенос унаследованных данных с помощью Data Migration Wizard

Способов  переноса данных может быть несколько. Первый, самый примитивный, и, к сожалению, весьма распространенный, представляет собой перенос структур данных и самих данных "как есть" с одной платформы на другую с заменой типов данных настольной СУБД на эквивалентные им типы данных сервера. Этой цели служит утилита Data Migration Wizard, входящая в комплект поставки C++Builder. Рассмотрим ее работу на простом примере из двух связанных таблиц. Для этой цели вполне подойдут таблицы CLIENTS.DBF (список клиентов) и HOLDINGS.DBF (список зданий), связанные отношением "один ко многим". Такой пример выбран потому, что таблица CLIENTS содержит графические и мемо-поля, при переносе которых с платформы на платформу нередко возникают проблемы (в отличие от символьных и числовых полей, для которых обычно можно подобрать эквивалентный тип данных). В качестве серверной СУБД используем 90-дневную trial-версию Personal Oracle 7.2 для Windows 95 или Oracle Workgroup Server 7.2.для Windows NT (в принципе подобный пример можно выполнить и с помощью входящего в комплект поставки С++Builder локального сервера InterBase). Перед тем как выполнить данный пример, запустим сервер и с помощью входящей в комплект поставки утилиты администрирования сервера (в нашем случае Personal Oracle Navigator) опишем пользователя USER1, от имени которого будут создаваться таблицы, проверив заодно наличие соединения с базой данных.

Рис 6. Создание пользователя с помощью Personal Oracle Navigator

    Далее опишем параметры псевдонима используемой базы данных:

Рис.7. Создание псевдонима для доступа  к данным Oracle

    Отметим, что 2: - имя локального сервера Oracle (при  работе с Oracle Workgroup Server for Windows NT, расположенном  на том же компьютере, что и С++Builder, можно использовать такое же имя сервера). В случае удаленного сервера следует описать местоположение и доступ к базе данных (имя БД, сетевой протокол, IP-адрес или сетевое имя компьютера) с помощью утилиты SQL*Net Easy Configuration, входящей в комплект поставки серверов Oracle последних версий.

    После описания доступа к БД рекомендуется  проверить правильность настроек BDE. Это можно сделать, запустив SQL Explorer и попытавшись открыть какую-либо из таблиц Oracle (любая современная  серверная СУБД, как правило, содержит какие-либо таблицы в качестве примера). Если список таблиц получить не удается, следует проверить, есть ли в переменной окружения PATH каталог типа С:\ORAWIN95\BIN, и есть ли в каталоге WINDOWS\SYSTEM файлы типа ORA72.DLL или ORANT71.DLL.

    После проверки настроек BDE можно приступить непосредственно к переносу таблиц. Запустим Data Migration Wizard:

Рис.8. Выбор исходной БД в Data Migration Wizard

    Далее выберем псевдоним БД, в которую  мы осуществляем экспорт данных, и  затем выберем имена экспортируемых таблиц:

Рис.9. Выбор таблиц для переноса данных с помощью Data Migration Wizard

    После этого получим экран, содержащий список таблиц и индексов, подлежащих переносу.

Рис.10. Список таблиц и индексов, подлежащих переносу.

    Если  нажать кнопку Modify Mapping Information For Selected Item, получим сведения о том, в какие  типы данных будут преобразованы  поля исходных таблиц. При необходимости  в эти сведения можно внести правки.

Рис.11. Внесение правок в правила преобразования полей

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

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

    Для создания такого приложения воспользуемся  инструментом под названием Database Form Wizard. Запустим C++Builder, создадим новый  проект, удалим из него пустую форму  и выберем со страницы Forms репозитария  объект Database Form:

Рис.12. Выбор Database Form из репозитария С++Builder

    Далее выберем создание формы master/detail c использованием объектов TTable:

Рис.13. Выбор типа будущей главной формы  приложения

    После выбора псевдонима базы данных Oracle из списка псевдонимов определим master-таблицу. В нашем случае это только что  созданная таблица CLIENTS:

Рис.14. Выбор master-таблицы

    Затем определим, какие поля этой таблицы  нам нужны (можно выбрать все), и как они будут расположены  на форме (выберем горизонтальное расположение полей). Затем определим detail-таблицу (в данном случае HOLDINGS), выберем все поля и в качестве способа их отображения выберем размещение их в TDBGrid. Наконец, укажем, что таблицы связаны по полю ACCT_NBR:

Рис.15. Установка связи между таблицами

    Далее выбираем опцию Generate a Main Form и в результате получим форму, похожую на представленную на рис. 16:

Рис.16. Вот что обычно получается при  использовании Database Form Wizard

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

Рис.17. Главная форма приложения после "приведения в порядок"

    Скомпилируем  и запустим созданное приложение и рассмотрим, каким образом созданная информационная система реагирует на изменение данных.

    Если  мы попытаемся удалить первую запись в таблице CLIENTS, нам это удастся, несмотря на то, что в таблице HOLDINGS есть связанные с ней записи. Точно  так же можно добавить запись с  произвольным значением поля ACC_NBR в таблицу HOLDINGS, и это нам также удастся. Таким образом, в созданной нами базе данных из двух таблиц связь "один-ко-многим" фактически отсутствует.

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

      Перенос унаследованных данных с использованием CASE-средств

Рассмотрим  альтернативный способ переноса данных на сервер, более дорогой и сложный, но приводящий в целом к более качественному результату. Этот способ базируется на использовании CASE-средств (CASE расшифровывается как Computer-Aided System Engineering) для восстановления схемы базы данных по имеющимся таблицам (так называемого обратного проектирования), замены платформы и описания связей между таблицами с точки зрения реакции сервера на попытки того или иного изменения данных со стороны клиентского приложения. В качестве такого средства рассмотрим, например, ERwin 3.0 - CASE-средство компании Logic Works, предназначенное для проектирования баз данных и на сегодняшний день являющееся одним из наиболее простых и доступных по цене средств такого класса.

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

Рис.18. Описание ODBC-источника с помощью  панели управления Windows

    Попробуем осуществить обратное проектирование с помощью ERwin , используя созданный ODBC-источник. Для этого из меню главного окна ERwin выберем опцию Tasks/Reverse Engineering .

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

    Выберем в качестве исходной платформы Clipper, ответим на вопросы, предлагаемые в  последующем диалоге (можно оставить то, что предложено по умолчанию) и в результате получим модель данных, похожую на изображенную на рис.19 (она содержит описание всех dBase-таблиц из каталога, содержащего данные для примеров, поставляемых с C++Builder):

Рис.19. Результат обратного проектирования каталога CBUILDER\EXAMPLES\DATA

    Отредактируем полученную модель данных, убрав все  таблицы, кроме CLIENTS и HOLDINGS, определив ACC_NBR первичный ключ таблицы CLIENTS и изменив тип данных поля IMAGE на МЕМО (опция Column Editor контекстного меню таблицы). Создадим также неидентифицирующую связь "один-ко-многим" между таблицами CLIENTS и HOLDINGS, выбрав для этой цели соответствующую пиктограмму на "плавающей" инструментальной панели.

    Далее следует выбрать другую целевую  платформу (в нашем случае Oracle). В  результате получим примерно следующий  вид модели данных:

Рис.20. Примерный вид модели данных для  генерации БД в Oracle

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

Рис.21. Определение реакции сервера  на попытки нарушения ссылочной  целостности

    После этого можно выбрать из меню опцию Tasks/Forward Engineer/Schema Generation и после установки соединения с Oracle сгенерировать базу данных, выбрав в появившейся диалоговой панели опции для генерации структуры. Можно также просмотреть и сохранить скрипт на языке PL/SQL (это процедурное расширение SQL, используемое для написания триггеров и хранимых процедур Oracle), называемый также DDL-сценарием (DDL расшифровывается как Data Definition Language).

Рис.22. DDL-сценарий генерации схемы базы данных

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