Перенос унаследованных данных с помощью 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, и это нам также удастся. Таким образом, в созданной нами базе данных из двух таблиц связь "один-ко-многим" фактически отсутствует.
Итак, на этом простейшем примере мы убедились, что подобный перенос данных, несмотря на простоту, не всегда приемлем с точки зрения использования всех возможностей серверной СУБД, особенно в случае большого числа таблиц и связей между ними.
