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