Дипломная работа: Использование Internet/intranet технологий для организации доступа к базам данных

Министерство общего и профессионального образования РФ

Дипломная работа

Исполнитель Апанасенко Е.В.

Челябинский государственный университет

Факультет математический

1. Введение

Базы данных настолько тесно вошли в нашу жизнь, что без их помощи не мыслится деятельность ни одной организации. С появлением локальных сетей, подключением таких сетей к Internet, созданием внутрикорпоративных сетей на базе intranet, появляется возможность с любого рабочего места организации получить доступ к информационному ресурсу сети, такому как база данных. Однако, при попытке использовать существующие базы данных возникают проблемы связанные с требованием однородности рабочих мест (для запуска "родных" интерфейсов), большим трафиком в сети (доступ идет напрямую к файлам базы данных), загрузкой файлового сервера и невозможностью удаленной работы (например, командированных сотрудников). Так, для каждой используемой базы данных необходим свой специфический клиент, такой как модуль времени исполнения или исполняемый файл, реализующий функциональность клиента. Клиентский компьютер должен быть достаточно мощным, для того чтобы справиться с обработкой функциональности клиента. Решением проблемы является использование унифицированного интерфейса WWW для доступа к информационным ресурсам организации [4].

Среди преимуществ такого подхода возможность доступа к базе данных посредством так называемого ⌠тонкого клиента■ - компьютера с установленной на нем стандартной программой-обозревателем Internet (Netscape Communicator, Microsoft Internet Explorer, и т.п.) вместо использования специфических программ-клиентов;

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

мобильность клиента: в качестве клиента может использоваться любой компьютер, под управлением любой ОС, имеющий обозреватель Internet;

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

В данной дипломной работе делается попытка проанализировать существующие технологии организации Web-ориентированных интерфейсов к базам данных и разработать такого рода систему, взяв в качестве прототипа реально существующую базу данных ⌠Библиографический каталог■, функционирующую в среде Microsoft Access [2].

Постановка задачи. Провести анализ имеющихся технологий разработки Web-ориентированных интерфейсов к базам данных и разработать справочно-библиографическую систему с WWW-интерфейсом, реализующую алфавитный и систематический каталоги публикаций на базе СУБД Oracle [7].

Для этой цели решались следующие задачи:

разработать структуру базы данных;

реализовать два варианта архитектуры WWW-интерфейса к базе данных и провести их сравнение;

разработать технологию импорта данных из формата СУБД MS Access в формат СУБД Oracle.

2. Две архитектуры систем доступа к базам данных через Web

В традиционной архитектуре клиент/сервер [1] действует принцип разделения задач, когда используется более чем один компьютер, и каждый из них выполняет строго определенные ему задачи. Такой подход уменьшает загрузку каждого узла системы, позволяя ему сконцентрироваться на выполнении ⌠своих■ задач и, следовательно, увеличивает производительность и возможности системы в целом.

В СУБД Oracle система баз данных разделена на две части: клиентскую часть и серверную часть [7] (Рис. 1).

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

Серверная часть, работающая на программном обеспечении Oracle, обслуживает задачи, необходимые для параллельного общего доступа к данным. Серверная часть принимает и обрабатывает SQL и PL/SQL запросы, посылаемые клиентскими приложениями [13]. Компьютер, обслуживающий серверную часть, должен быть оптимизирован для решения своих специфических задач √ он должен иметь большую дисковую память и быстрый процессор [8].

Связь между сервером и клиентом осуществляется посредством SQL*Net √ сетевого интерфейса Oracle [9]. SQL*Net позволяет программам Oracle, запущенным на сетевых клиентских рабочих станциях и серверах, организовать доступ, модификацию, разделение и хранение данных на других серверах.

При построении Web-интерфейсов к базам данных различают два подхода: доступ к базе данных на стороне клиента, и доступ к базе данных на стороне сервера.

2.1 Доступ к базе данных на стороне клиента

Доступ к базе данных на стороне клиента обеспечивает язык Java [10]. Java - это объектно-ориентированный язык программирования, являющийся, по сути дела, "безопасным" подмножеством языка Си++. В частности, Java не содержит средств адресной арифметики, не поддерживает механизм множественного наследования и т. д. Для языка Java существуют компиляторы в так называемый "мобильный код" (машинно-независимый код, который может интерпретироваться или из которого могут генерироваться машинные коды на разных платформах).

Технология разработки HTML-документа позволяет написать произвольное количество Java-программ, откомпилировать их в мобильные коды и поставить ссылки на соответствующие коды в теле HTML-документа. Такие дополнительные Java-программы называются апплетами (Java-applets). Получив доступ к документу, содержащему ссылки на апплеты, клиентская программа просмотра запрашивает у Web-сервера все мобильные коды. Коды могут начать выполняться сразу после размещения в компьютере клиента или быть активизированы с помощью специальных команд.

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

Для взаимодействия Java-апплета с внешним сервером баз данных разработан специализированный протокол JDBC, который, фактически, сочетает функции шлюзования между интерпретатором мобильных Java-кодов и ODBC, а также включает ODBC.

По сути дела, Web-интерфейс с доступом к базе данных на стороне клиента практически ничем не отличается от традиционной клиент/серверной архитектуры. Просто роль клиентского приложения здесь играет Java-апплет √ программа на псевдокоде, способная через Internet/intranet загрузиться и выполниться на вашем компьютере.

2.2 Доступ к базе данных на стороне сервера

Более интересной реализацией является механизм доступа к базе данных на стороне сервера. Существует два основных различия между работой приложения в клиент/серверной реализации Oracle и в Web реализации с доступом к базе данных на стороне сервера [6]:

Клиент/сервер (Рис. 1). Архитектура системы состоит из двух частей: Клиента и сервера баз данных. Модуль форм времени исполнения (и все прикладные функции) устанавливаются на настольные компьютеры пользователя. Хотя приложение теоретически может включать триггеры и прикладные функции на стороне сервера баз данных, на практике эта возможность используется редко, поэтому вся обработка интерфейса пользователя и триггеров, как правило, происходит на клиентских машинах [6].

Web (Рис. 2). Архитектура системы является трехзвенной и состоит из следующих частей: клиент(ы), сервер приложений, сервер баз данных. Все прикладные функции устанавливаются на сервере приложений, а не на клиентах. Вся обработка интерфейса пользователя выполняется клиентом, в то время как обработка триггеров происходит на сервере баз данных и сервере приложений.

2.2.1 Технология Oracle Web deployment

Модуль форм времени исполнения (Forms Runtime Engine) представляет собой программу, выполняющую формы приложения. В ее задачи входит запуск, отображение и обработка функциональности формы.

Сервер приложений (Application Server) представляет собой звено архитектуры, отвечающее за хранение и обработку прикладных функций приложения. Реализован в виде WWW-сервер. WWW сервер - это такая часть глобальной или внутрикорпоративной сети, которая дает возможность пользователям сети получать доступ к гипертекстовым документам, расположенным на данном сервере. Для взаимодействия с WWW сервером пользователь сети должен использовать специализированное программное обеспечение √ обозреватель Internet.

Клиент форм (Forms Client) реализован в виде Java-апплета, загружаемого в реальном времени в Web-обозреватель пользователя с сервера Приложений. Web-обозреватель, посредством экранных форм, отображает интерфейс пользователя и управляет взаимодействием конечного пользователя с сервером форм. Клиент форм принимает пакеты интерфейсных команд от сервера форм и транслирует их в интерфейсные объекты для конечного пользователя. Некоторые интерфейсные события (такие как ввод символов в текстовых полях или перемещение по элементам диалогового окна), которые в клиент/серверной реализации обрабатывались модулем времени исполнения сервера форм, в Web реализации обрабатываются клиентом форм без взаимодействия с сервером форм.

В числе достоинств клиента форм:

Общность. Нет необходимости каждый раз разрабатывать отдельный Java-апплет для каждого приложения, которое Вы хотите поместить в Web.

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

Богатый набор интерфейсных элементов. Клиент форм поддерживает все элементы интерфейса пользователя, доступные в клиент/серверной реализации. Благодаря стандартизированным Java-объектам, вид и поведение интерфейсных элементов формы в Web практически не отличается от их в клиент/серверной реализации.

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

Сервер форм (Forms Server) состоит из двух компонент:

Слушатель (Listener). Слушатель сервера форм инициирует сессию сервера форм и обеспечивает связь между клиентом форм и обработчиком времени исполнения сервера форм.

Обработчик (Модуль) времени исполнения (Forms Runtime Engine). Обработчик времени исполнения форм представляет собой модифицированную версию обработчика времени исполнения для клиент/серверной реализации с функциональностью интерфейса пользователя, перенаправленной на клиента форм. Обработчик времени исполнения реализует всю функциональность формы, за исключением взаимодействия интерфейса пользователя; в его задачу входит обработка триггеров и транзакций, управление записями и общее взаимодействие с базой данных.

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

Запросы клиента форм представляют собой события (такие как ⌠нажать кнопку■ или ⌠отобразить элемент■). Ответы сервера форм √ это инструкции по изменению пользовательского интерфейса (такие как изменение значения элемента или добавление/удаление объекта), которые клиент форм преобразует в изображение объектов. Например, если клиент форм получает ответ от сервера форм ⌠создать текстовый элемент зеленого цвета в канве Canva1■, то клиент форм транслирует ответ в изображение реальных интерфейсных объектов (в нашем случае цветной текстовый элемент).

Клиент форм запрашивает сервер форм, когда пользователь выполняет:

высокоуровневые операции (такие как подтверждение или отмена диалога);

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

Для запуска приложения Oracle через Web, конечный пользователь должен, используя Java-совместимый Web-обозреватель, вызвать URL (Uniform Resource Locator) приложения. После этого порождается следующая цепочка:

URL соответствует HTML-странице (Hypertext Markup Language), содержащей ссылку на апплет клиента форм и параметры его запуска.

HTML страница, а затем и апплет клиента форм загружаются с сервера приложений в обозреватель клиента.

Клиент форм посылает запрос слушателю сервера форм (который запущен на определенном порту машины, с которой загрузился клиент форм).

Слушатель связывается с обработчиком времени исполнения сервера форм и подключается к процессу сервера форм (стартует новый процесс, либо подключается к уже существующему). Если в HTML странице указаны параметры командной строки запуска формы (такие как имя формы, идентификатор и пароль пользователя, SID базы данных, название меню и т.д.) и другие определенные пользователем параметры, то они передаются процессу через Слушатель.

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

Также как и в клиент/серверной реализации, Обработчик времени исполнения напрямую связывается с базой данных через SQL*Net (или другой драйвер для связи с источниками данных не Oracle).

Данные, проходящие между базой данных, сервером форм и клиентом форм автоматически шифруются перед посылкой и дешифруются после приема согласно протоколам RSA RC4 40-битное шифрование (для передачи между клиентом форм и сервером форм) и SQL*Net SNS/ANO (для передачи между сервером форм и сервером баз данных) [13].

2.2.2 Технология с использованием интерфейса CGI

В качестве более распространенного варианта разработки Web-ориентировных интерфейсов к базам данных выступает механизм CGI (Common Gateway Interface √ Общий Интерфейс Шлюзования). Система строится с использованием трехзвенной архитектуры, составляющими которой являются:

Web-сервер (сервер приложений) √ программно-аппаратный комплекс, который дает возможность пользователям сети получать доступ к гипертекстовым документам, расположенным на данном сервере;

Сервер баз данных;

Web-обозреватель клиента.

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

Если рассматривать технологию CGI применительно к организации интерфейса к базам данных, то CGI-скрипт должен, обработав запрос пользователя, передать его серверу баз данных и затем на основе результата сформировать HTML-документ, который и увидит пользователь (Рис. 4).

Таким образом, общая схема реализации доступа к базе данных выглядит следующим образом [4]:

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

клиент запрашивает эту страницу; помимо незаполненных форм страница содержит общую информацию о базе данных и о назначении предлагаемых форм;

клиент заполняет одну из форм и отправляет заполненную форму на сервер;

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

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

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

Web-сервер передает HTML-страницу в клиентский обозреватель.

CGI-скрипт взаимодействует с базой данных Oracle по протоколу SQL* Net [7] √ сетевому протоколу Oracle. В задачи CGI-скрипта входит получение данных от пользователя, их обработка и формирование на их основе запроса к базе данных. После получения результата запроса CGI-скрипт создает HTML-страницу и передает ее Web-серверу. Web-сервер, в свою очередь, пересылает HTML-страницу клиенту, инициировавшему сеанс. Ввод данных клиентом осуществляется с помощью механизма HTML-форм.

3. Технология разработки Web-интерфейсов к базам данных

Как было описано в главе 2, архитектура приложений баз данных с WWW-интерфейсом базируется на трехзвенной архитектуре (Рис. 5), включающей:

Сервер баз данных;

Сервер приложений;

Клиентов.

Рассмотрим технологический цикл построения таких систем.

3.1 Технология Oracle Web-delpoyment доступа к базам данных на стороне сервера

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

Сервер баз данных представляет самую массивную часть архитектуры. Находясь на этом уровне, необходимо создать собственно Базу Данных, то есть совокупность взаимосвязанных данных, хранимых в ЭВМ [1]. Проектирование базы данных включает инфологическое проектирование (определение предметной области системы и др.), логическое проектирование (создание схемы базы данных) и физическое проектирование (отображение ⌠логической■ структуры в структуру хранения и др.) [1].

Сервер приложений; Настройка сервера приложений включает следующие этапы:

создание и помещение FMX-файла на сервер приложений;

запуск Слушателя сервера форм;

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

настройка клиента форм.

создание и помещение FMX-файла на сервер приложений

На этом этапе необходимо создать форму (формы) приложения в формате FMB-файла и сгенерировать исполняемый FMX-файл. Это связано с тем, что Oracle генерирует приложения в псевдокоде (файлы с расширением FMX), запуск которых возможен посредством Forms Runtime √ небольшого пакета, устанавливаемого на клиентскую машину. Генерация FMX-файлов должна производится на той же платформе, на которой установлен сервер приложений.

Сгенерированный FMX-файл можно поместить в любой каталог сервера приложений √ главное, чтобы на него была корректная ссылка в HTML файле для обеспечения доступа к нему пользователям. В случае если указано только имя файла (без специфицирования пути), то Модуль Времени Исполнения сервера форм ищет файл в двух местах (в порядке перечисления):

в каталоге ORACLE_HOME\BIN\;

в каталоге FORMS50_PATH (если переменная среды установлена),

где ORACLE_HOME и FORMS50_PATH √ переменные среды операционной системы.

2. запуск Слушателя сервера форм

Для запуска Слушателя сервера форм необходимо выбрать пункт Start->Run на панели задач Windows NT (описывается реализация для платформы Windows NT 4.0). Далее необходимо набрать

<ORACLE_HOME>\bin\f50srv32 port=номер_порта и нажать Enter.

После этого будет запущен процесс слушателя на указанном порту. При опускании номера порта, процесс стартует, используя по умолчанию порт 9000. Этот номер должен совпадать с номером порта, который указывается в HTML файле (см. п.3 обеспечение конечным пользователям доступа к приложению).

Для проверки состояния запущенного сервера форм можно посмотреть вкладку Processes в окне Менеджера задач NT. Если прослушивающий процесс запущен, то будет присутствовать процесс с именем F50SRV32.EXE, а также несколько процессов F50WEB32.EXE (один для каждого активного соединения).

Для остановки Слушателя сервера форм необходимо выбрать пункт End Process в окне Менеджера задач NT.

3. обеспечение конечным пользователям доступа к приложению

3.1. создание виртуальных каталогов на Web-сервере

Виртуальные каталоги представляют собой отображение физических каталогов сервера приложений. Для работы сервера форм необходимо создать 3 виртуальных каталога. Имена каталогов могут быть любыми √ они указываются в HTML файле в качестве параметров апплета клиента форм. Виртуальные каталоги используются для скрытия длинных путей к файлам на сервере приложений, а также для упрощения переноса системы (в случае переноса системы на другой сервер или перемещения файлов приложения в другие каталоги, необходимо будет лишь создать/модифицировать соответствующие виртуальные каталоги на Web-сервере, вместо того, чтобы модифицировать существующие HTML файлы).

Ниже разъясняется семантика создаваемых виртуальных каталогов:

Applet codebase (является тэгом, т.е. ключевым словом HTML, в описании апплета). Указывает на основной URL апплета - задает каталог, содержащий код апплета (Java-классы).

ORACLE_HOME\forms50\java (например, c:\orant\forms50\java).

Нельзя устанавливать этот виртуальный каталог на /ORACLE/.

HTML файлы. Указывает на каталог, где Web-сервер будет искать HTML файлы приложения.

JAR-файлы. Указывает на физический каталог, где находятся JAR-файлы (Java Archives) Oracle.

Пример настройки виртуальных каталогов:

Назначение	Пример Физических Каталогов	Пример Виртуальных Каталогов
Applet codebase	c:\orant\forms50\java\	/web_code/
HTML файлы	c:\web_forms\html\	/web_html/
JAR-файлы	c:\orant\forms50\java\	/web_jars/

3.2. выбор метода создания HTML файла (динамический или статический)

Когда конечный пользователь стартует Web приложение Oracle (выбрав URL приложения), с ссервера приложений в обозреватель пользователя загружается HTML файл. Этот файл содержит все необходимые тэги апплета, параметры и их значения, требуемые для работы выбранного приложения в Web. Инициирующий приложение HTML файл может быть создан двумя способами:

Динамически. HTML файл динамически создается обработчиком картриджей форм. Этот метод требует установки Oracle Web Server в качестве сервера Приложений. В описываемой работе использовался и будет описываться другой метод √ статический.

Статически. Требует создания HTML файла, содержащего всю необходимую информацию для приложения. В качестве сервера приложений может использоваться любой Web-сервер. Дистрибутив Oracle Developer/2000 R2.0 содержит пример статического файла √ static.htm. При разработке приложения необходимо модифицировать этот файл, указав соответствующие значения тэгов апплета, такие как имя файла формы (.FMX) и др. После создания файла, необходимо поместить его в физический каталог, связанный с виртуальным каталогом, определенным для HTML файлов (см. п. 3.1).

3.3. обеспечение доступа к приложению Web через URL

После создания HTML файла приложения и размещения соответствующего FMX-файла, требуется предоставить конечным пользователям доступ к приложению. Для этого необходимо просто обеспечить пользователей URL HTML файла приложения. Конечные пользователи будут вызывать URL в Java-совместимом Web-обозревателе и запускать соответствующее приложение. Для этого можно создать HTML-страницу, содержащую URL-ссылку на HTML файл приложения. Пример URL:

http://gemini.math.cgu.chel.su/web_html/bibliogr.htm

Расшифровка URL: Протокол: http

Домен: gemini.csu.ac.ru

Виртуальный каталог

для HTML файлов: /web_html

Статический HTML файл: bibliogr.htm

4. настройка клиента форм

Когда конечный пользователь запускает Web приложение Oracle, с сервера приложений в его обозреватель загружается клиент форм (и файлы родственных Java-классов). В процессе работы пользователя с приложением, по мере необходимости могут подгружаться файлы дополнительные Java-классы. Существует возможность управления тем, как файлы классов будут загружаться в обозреватель пользователя. Есть два метода загрузки:

Инкрементная (Increment). Является настройкой по умолчанию и обеспечивает загрузку только тех файлов с Java-классами, которые необходимы для отображения начального состояния приложения.

Архивная (Bundled). В момент запуска приложения, на клиентскую машину загружаются один или несколько архивов с Java-классами. Преимущество архивов в том, что каждый архив загружается за одну сетевую транзакцию. Для использования этого варианта необходимо указать имена соответствующих JAR-файлов в HTML файле приложения.

Клиенты. Клиентская часть системы практически не требует настройки, так как базируется на ⌠тонком клиенте■ - Java-совместимом Web-обозревателе. Необходимо использовать обозреватель, имеющий поддержку JDK (Java Development Kit √ стандарт Java) версии 1.1.x или выше.

3.2 Технология доступа к базам данных на стороне сервера с использованием механизма CGI

В соответствии с идеологией CGI-интерфейсов, вся функциональность размещается на сервере приложений. Ее реализует один или несколько CGI-скриптов, которые получают от Web-сервера запрос пользователя. Результатом выполнения скрипта является HTML-документ, содержащий информацию из базы данных. Этот документ передается Web-серверу, а затем отправляется в клиентский обозреватель по протоколу HTTP. Дополнительно, в результате выполнения скрипта возможно изменение информации в базе данных.

Для реализации взаимодействия "клиент-сервер" важно, какой метод HTTP запроса использует клиентская часть при обращении к WWW серверу. В общем случае, запрос - это сообщение, посылаемое клиентом серверу. Первая строка HTTP запроса включает в себя метод, который должен быть применен к запрашиваемому ресурсу, идентификатор ресурса (URI - Uniform Resource Identifier), и используемую версию HTTP-протокола. Применительно к CGI, клиентская часть использует методы запроса POST и GET. Метод POST применяется для запроса серверу, чтобы тот принял информацию, включенную в запрос, как относящуюся к ресурсу, указанному идентификатором ресурса. Метод GET используется для получения любой информации, идентифицированной идентификатором ресурса в HTTP запросе.

Согласно спецификации, CGI определяет 4 информационных потока:

Переменные окружения;

Стандартный выходной поток;

Стандартный входной поток;

Командная строка.

Переменные окружения

Ниже приводится значение некоторых переменных, объявленных в стандарте CGI:

CONTENT_LENGTH - значение этой переменной соответствует длине стандартного входного потока в символах;

QUERY_STRING - значение этой переменной соответствует строке символов следующей за знаком "?" в URL соответствующему данному запросу. Эта информация не декодируется сервером.

2. Стандартный вывод

CGI - модуль выводит информацию в стандартный выходной поток. Этот вывод может представлять собой или документ, сгенерированный cgi-модулем, или инструкцию серверу, где получить необходимый документ. Обычно cgi-модуль производит свой вывод. Преимущество такого подхода в том, что cgi-модуль не должен формировать полный HTTP заголовок на каждый запрос.

Вывод cgi-модуля должен начинаться с заголовка содержащего определенные строки и завершаться двумя символами CR (0x10). Любые строки не являющиеся директивами сервера, посылаются непосредственно клиенту. На данный момент, CGI спецификация определяет три директивы сервера:

Content-type

MIME или тип возвращаемого документа. Например:

Content-type: text/html <CR><CR>

сообщает серверу, что следующие за этим сообщением данные - есть документ в формате HTML;

Location

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

Status

задает серверу HTTP/1.0 строку-статус, которая будет послана клиенту в формате: nnn xxxxx

где: nnn - 3-х цифровой код статуса

ххххх - строка причины

Например: HTTP/1.0 200 OK

Server: NCSA/1.0a6

Content-type: text/plain

<динамически генерируемый текст сообщения3. Стандартный входной поток

В случае метода запроса POST данные передаются как содержимое HTTP запроса и будут посланы в стандартный входной поток. Данные передаются cgi-модулю в следующей форме:

name=value&name1=value1&...&nameN=valueN

где name - имя переменной,

value - значение переменной,

N - количество переменных

На файловый дескриптор стандартного потока ввода посылается CONTENT_LENGTH байт. Так же сервер передает cgi-модулю CONTENT_TYPE (типданных). Сервер не посылает символ конца файла после передачи CONTENT_LENGTH байт данных или после того, как cgi-модуль их прочитает. Переменные окружения CONTENT_LENGTH и CONTENT_TYPE устанавливаются в тот момент, когда сервер выполняет cgi-модуль. Таким образом, если в результате исполнения формы с аргументом тега FORM - METHOD="POST" сформирована строка данных firm=МММ&price=100023, то сервер установит значение CONTENT_LENGTH равным 21 и CONTENT_TYPE в

application/x-www-form-urlencoded, а в стандартный поток ввода посылается блок данных.

В случае метода GET, строка данных передается как часть URL.

Например

http://host/cgi-bin/script?name1=value1&name2=value2

В этом случае переменная окружения QUERY_STRING принимает значение

name1=value1&name2=value2

4. Аргументы командной строки

СGI-модуль в командной строке от сервера получает:

остаток URL после имени cgi-модуля в качестве первого параметра (первый параметр будет пуст, если присутствовало только имя cgi-модуля);

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

Ключевые слова, имена и значения полей формы передаются декодированными (из HTTP-URL формата кодирования) и перекодированными в соответствии с правилами кодирования Bourne shell [12] так, что cgi-модуль в командной строке получит информацию без необходимости осуществлять дополнительные преобразования (рассматривается реализация на Unix-платформе).

Исходя из разницы методов запросов GET и POST, можно определить последовательность действий для обработки входных данных cgi-модуля для разных типов запросов.

I. Для метода GET

Получить значение переменной QUERY_STRING;

Декодировать имена и их значения (учитывая, что все пробелы при декодировании сервером были заменены символом "+" и все символы с десятичным кодом больше 128 преобразованы в символ "%" и следующим за ним шестнадцатеричным кодом символа.);

Сформировать структуру соответствия "имя - значение" для дальнейшего использования в cgi-модуле.

II. Для метода POST

Получить из стандартного входного потока CONTENT_LENGTH символов;

Сформировать структуру соответствия "имя-значение" для дальнейшего использования в cgi-модуле.

После формирования структуры "имя-значение" можно приступить к решению задач, ради которых, собственно, создавался cgi-модуль. Следующим важным моментом является динамическое формирование cgi-модулем HTML-документа (оформление результата работы модуля). Например, таблицы выборки из базы данных.

Для этого cgi-модуль должен выдать в стандартный выходной поток заголовок, состоящий из строки:

Content-type: text/html и пустой строки (двух символов CR).

После этого заголовка можно выдавать любой текст в формате HTML.

Как уже говорилось ранее, CGI-скрипт играет роль посредника между Web-сервером и другими видами серверов, в частности с сервером баз данных. В качестве языка CGI-скриптов часто выступает язык Perl [11] (Practical Extraction and Report Language)- интерпретируемый язык, приспособленный для обработки произвольных текстовых файлов, извлечения из них необходимой информации и выдачи сообщений. Здесь будет освящен вопрос доступа к базе данных Oracle из языка perl.

Это возможно благодаря наличию в свободно-доступной библиотеке Perl-модулей (доступна на http://www.perl.com/CPAN/) пакетов для работы с базами данных: DBI и DBD-Oracle. DBI представляет собой абстрагированный от конкретного SQL-сервера интерфейс-надстройку над интерфейсом DBD-xxxx, который закреплен за конкретным SQL-сервером.

Ниже приводятся описание некоторых функций из пакета DBI:

$dbh = DBI->connect('dbi:Oracle:'.'db_alias', 'db_user', 'db_pwd', {RaiseError => 1});

$dbh->{RaiseError} = 1; # do this, or check every call for errors

- установка соединения с базой данных Oracle

$cursor = $dbh->prepare("SELECT Fie1d, Field2 FROM Table1 ORDER BY Field2");

$cursor->execute;

while (@row = $cursor->fetchrow_array) {

print "$row[0], $row[1] \n";

}

- выполнение запроса к базе данных (значения полей Field1, Filed2 помещаются в массив @row)

my($Field1, $Field2, $Field3);

$cursor = $dbh->prepare("SELECT Field1, Field2, Field3 FROM Table1");

$cursor->bind_columns(undef, \($Field1, $Field2, $Field3));

$cursor->execute;

while $cursor->fetch) {

print "$Field1, $Field2, $Field3 \n";

}

- выполнение запроса к базе данных (значения полей Field1, Field2, Field3 помещаются в переменные $Field1, $Field2, $Field3)

$rc = $cursor->finish;

$rc = $dbh->disconnect;

- закрытие курсора и отсоединение от базы данных.

Рассмотрим реализацию, базирующуюся на Web-сервере Apache для Unix-систем. Для того чтобы Web-сервер мог выполнять CGI-скрипты, написанные на языке perl, файл с perl-программой должен иметь атрибут ⌠исполняемый■. Если файлы с программой расположены в каталоге, отличном от каталога, прописанного в директиве ScriptAlias (обычно cgi-bin) файла конфигурации Web-сервера srm.conf, то дополнительно необходимо создать строку, вида

AddHandler cgi-script .cgi

в файле srm.conf (предполагается, что файлы будут иметь расширение .cgi). После внесения любых изменений в файлы конфигурации Web-сервера, его необходимо перезапустить командой

$ Apache_HOME/sbin/apachectl restart

где Apache_HOME √ каталог, где расположен Web-сервер.

Первой строкой perl-программы должна быть строка, вида

#!/usr/local/bin/perl

задающая путь до интерпретатора языка perl в системе.

4. Приложения технологогии доступа к базам данных через Web

4.1 Реализация информационно-поисковой системы ⌠Библиографический каталог по программированию и базам данных■ с помощью технологии Oracle Web deployment

Ключевым моментом в вопросе реализации системы является выбор инструментальных средств. В качестве СУБД для реализации была выбрана реляционная СУБД Oracle для Windows NT. Это связано с мощностью и гибкостью сервера Oracle как многопользовательского сервера баз данных, а также с широким набором средств разработки для этой системы. Немаловажно также было и то, что Oracle поставляет технологию, называемую Web deployment, которая позволяет легко помещать работающие приложения Oracle в Web.

Согласно технологическому циклу разработки приложений для Web, описанному в главе 3, процесс реализации разбился на подзадачи реализации отдельных частей (на сервере баз данных, на сервере приложений и на клиенте):

Перенос базы данных

Были подготовлены текстовые файлы SQL-сценариев (SQL - Structure Query Language √ базовый язык Oracle [7]), создающие структуру базы данных (см. Приложение). В системе MS Access реализована служебная программа Import, генерирующая файл SQL-сценария с данными из базы данных MS Access. Такой подход делает базу данных легко переносимой, так как она может быть представлена как совокупность текстовых файлов, содержащих SQL инструкции. Для создания структуры базы данных и занесения данных необходимо выполнить эти файлы, работающие в пакетном режиме, с помощью инструментов SQL *Plus (или SQL Worksheet), представляющих собой SQL-консоль Oracle.

Для упрощения процесса переноса базы данных были созданы командные файлы MS-DOS (а для CGI-реализации √ командные файлы Unix), вызывающие утилиту SQL *Plus с необходимыми параметрами.

Настройка сервера приложений

разработка и тестирование формы; В качестве основного инструментария использовался пакет Forms Builder 5.0, входящий в систему разработки Oracle Developer/2000 R2.0. С его помощью была разработана клиентская часть системы (и сгененрирован FMX-файл), работающая в среде Developer/2000 Forms Runtime (см. Приложение).

настройка сервера приложений (создание виртуальных каталогов); В качестве сервера приложений использовался Microsoft Internet Information Server.

запуск и настройка сервера форм;

обеспечение доступа к приложению через сервер приложений (создание ссылки на приложение, регистрация специального пользователя). Был создан пользователь Oracle (с именем Bibl), имеющий право только на чтение данных из таблиц базы данных.

Клиентская часть

В качестве клиентов, были опробованы следующие Web-обозреватели:

Microsoft Internet Explorer 4.0,

Netscape Communicator 4.04 (более ранние версии не рассматривались, в силу того, что они заведомо несовместимы со стандартом JDK 1.1.x).

Корректная поддержка руского языка в Java-апплетах существовала лишь в Microsoft Internet Explorer 4.0 rus, поэтому в качестве клиентской части было решено взять этот обозреватель. Однако, интерфейс с использованием Java является недостаточно эффективным в силу низких скоростных характеристик имеющихся каналов связи, а также недостаточной надежности построенных на основе описаной технологии приложений. Поэтому, для рализации было решено использовать интерфейс на базе CGI, который является более эффективным в данном контексте.

4.2 Реализация информационно-поисковой системы ⌠Библиографический каталог по программированию и базам данных■ с использованием механизма CGI

В данной разработке в качестве Web-сервера выступала машина под управлением ОС Linux и Web-сервером Apache. На этой же машине была установлена СУБД Oracle в объеме клиентской инсталляции (около 30 Мб). Сервер баз данных под управлением СУБД Oracle был установлен на машине с системой Windows NT.

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

search.cgi √ скрипт, который выполняет поиск и печатает его результаты в форматированном виде (может передавать управление скрипту card.cgi)

Параметрывызова:

search.cgi?search_string=search_string&search_type=search_type&portion=portion

где search_string √ искомая подстрока (или код записи при поиске по ссылке),

search_type √ тип поиска (1 √ шифр, 2 √ автор, 3 √ название, 4 - ключевое слово, 5 √ тема),

portion √ указатель текущего блока записей относительно всех записей, возвращенных запросом

card.cgi √ скрипт, выводящий информацию по выбранной единице библиографического каталога

Параметры вызова:

card.cgi?code

где code √ код записи, хранящей информацию о выбранной единице

reference.cgi √ скрипт, создающий выпадающий список для выбора библиографической единицы по ссылке (затем передает управление скрипту search.cgi)

Параметры вызова: нет

subject.cgi √ скрипт, ответственный за представление 3-х уровневого систематического каталога (затем передает управление скрипту search.cgi)

Параметры вызова:

subject.cgi √ первый уровень систематического каталога,

subject.cgi?code1 √ второй уровень систематического каталога,

subject.cgi?code1&code2 √ третий уровень систематического каталога,

subject.cgi?code1&code2&code3 √ выдача библиографических единиц, подходящих под текущую классификацию,

где code1, code2, code3 √ коды соответствующих тем систематического каталога

common.cgi, module.cgi √ модули, содержащие общие для всей системы подпрограммы и константы

Кроме того, система содержит несколько HTML-форм, хранящихся в файлах author.html, index.shtml, keyword.html, title.html. CGI-скрипты вызываются как напрямую, так и из этих форм. Для предотвращения ввода пустой строки поиска, в формы встроен код на языке Java-Script, препятствующий этому.

В случае если результат запроса содержит много записей, предусмотрена постраничная передача результата запроса клиенту.

4.3 Реализация системы отчетности по торгам на Южно-Уральской Фондовой Бирже с использованием механизма CGI

Торги на Южно-Уральской Фондовой Бирже проходят с использованием электронной Торговой Системы. Торговая Система Южно-Уральской Фондовой Биржи предназначена для организации биржевых торгов ценными бумагами на ЮУФБ в соответствии с ⌠Правилами совершения операций с ценными бумагами в НП ЮУФБ■. В системе реализована работа с областными краткосрочными облигациями (ОКО) Челябинской области, регламентируемая ⌠Положением о выпуске и обращении ОКО■. Торговая система работает под управлением СУБД Oracle 7.3.2 для SCO Unix Open Server Enterprise v.5.0.4. Клиентские рабочие места организованы под управлением SQL*Oracle Forms 3.0, SQL*Oracle Menu 5.0 и SQL*Oracle Reports Writer 1.1.

Была поставлена задача расширить существующую систему автоматического предоставления отчетности по торгам в соответствии с ⌠Положением о представлении отчетности организаторами торговли на рынке ценных бумаг■, утвержденном постановлением Федеральной комиссии по рынку ценных бумаг (ФКЦБ).

Разработанная система соответствует ⌠Положению о представлении отчетности организаторами торговли на рынке ценных бумаг■, утвержденному постановлением ФКЦБ и представляет собой программный комплекс, написанный на языке perl и работающий через обозреватель Internet. В системе реализованы ежедневный и ежемесячный отчеты: ⌠Итоги торгов эмиссионными ценными бумагами за торговый день■ и ⌠Сведения о участниках торгов, имеющих наибольшую сумму совершенных сделок с ценными бумагами, допущенными к обращению через организатора торговли■. В систему интегрирован ⌠электронный календарь■, с помощью которого можно выбрать дату для отчета. Это позволяет получить отчет за любой период времени, используя базу данных Торговой Системы.

Система работает под управлением системы SCO Unix Open Server Enterprise v.5.0.4. и представляет собой набор CGI-скриптов, т.е. внешних по отношению к Web-серверу программ. При наборе URL (Uniform Resource Locator) скрипта, Web-сервер запускает программу и передает ей соответствующие параметры вызова. Программа, в свою очередь, соединяется по протоколу SQL*Net с сервером Oracle (который в данной реализации расположен на отдельной машине) и выбирает необходимые ей для отчета данные. Затем на основе полученных данных CGI-скрипт генерирует HTML-код и возвращает его Web-серверу. Web-сервер пересылает полученный от программы-скрипта HTML-код Internet-обозревателю клиента, который и выводит его в своем окне. Физически система находится в 4-х файлах (1 модуль с общими функциями и 3 файла, реализующие функциональность электронного календаря■ и 2-х отчетов соответственно).

Заключение

При выполнении дипломного проекта были получены следующие основные результаты:

освоена технология разработки приложений на базе СУБД Oracle с использованием системы разработки Oracle Developer/2000 R2.0;

изучена технология создания Oracle приложений с WWW-интерфейсом на базе механизма OracleWeb deployment;

используя технологию Web deployment, при использовании системы разработки приложений Oracle Developer/2000 R2.0 создано приложение ⌠Справочно-библиографическая система■;

предложена технология создания Web-ориентированных интерфейсов к базам данных с использованием интерфейса CGI;

на основе описанной CGI-технологии создана Internet версия аннотированного ⌠библиографического каталога по программированию и базам данных■;

разработан и реализован механизм переноса данных из базы данных библиографического каталога в формате MS-Access в новую базу данных в формате Oracle;

осуществлено внедрение в промышленную эксплуатацию Internet версии библиографического каталога по программированию и базам данных на математическом факультете Челябинского государственного университета: http://reindeer.math.cgu.chel.su/oracle/bibl (акт о внедрении прилагается);

на основе описанной CGI-технологии реализована и внедрена в промышленную эксплуатацию система отчетности по торгам на Южно-Уральской фондовой бирже: http://www.suse.ru:8001/ (акт о внедрении прилагается);

по теме дипломной работы выполнена одна публикация: Соколинский Л.Б., Апанасенко Е.В. Технологические аспекты разработки Internet версии аннотированного библиографического каталога по программированию и базам данных // Телематика'99: Тез. докл. Всерос. конф. Санкт-Петербург. 1999.

Список литературы

Когаловский М.Р. Технология баз данных на персональных ЭВМ. - М.: ⌠Финансы и статистика■. 1992. - 256 с.

Разработка приложений Microsoft Access 7.0 для Windows 95. - Microsoft Corp. Publ. - 1996. 898 с.

Сайгин Ю., Филимонов Б., Глонти Н. Создание приложений Web к базам данных Oracle // СУБД 1996. √ N 5-6

Кузнецов С.Д. Доступ к базам данных посредством технологии WWW // СУБД 1996.- N 5-6

Oracle Developer/2000. Forms 4.5 Reference Manual. - Oracle Corp. - 1995. Vol 1-2

Developer/2000 Guidelines for Building Applications Release 2.0 √ - Oracle Corp. - 1997.

Oracle Server V2, 3, ..., 7.0, 7.1 ... and Counting. // EOUG Oracle User Forum 94 17-20 April 1994, Maastriht, The Netherlands.

The Committee for Advanced DBMS Function. Third Generation Database Manifesto. // SIGMOD Record, 1990. - Vol. 19, N 3, pp. 31-44

Лашманов А. ORACLE √ история, состояние и перспективы // СУБД 1995.- N1, C.55

В. Цишевский, Языкиархитектура Java, Jet Infosystems - electronic version

Wall L., Christiansen T., Schwartz R. Programming Perl. 2nd ed. O'Reilly & Associates, 1996.

Кристиан К. Введение в операционную систему UNIX. - М.: Финансы и статистика. 1985. √ 318 с.

Oracle Product Documentation Library. √ Oracle Corp. - 1995.

Приложение 1. Описание структуры базы данных ⌠Библиографического каталога■

Соответствие названий таблиц в базе данных-прототипе (MS Access) и в разработанной базе данных (Oracle).

Microsoft Access	Oracle
Алфавитныйкаталог	Alphabetical_Catalogue
Систематический каталог	Systematic_Catalogue
СК-2 (подчиненная)	SC-2
СК-3 (подчиненная)	SC-3

Исходный текст файла-сценария SQL, создающего структуру базы данных и хранимые процедуры:

DROP TABLE Alphabetical_Catalogue;

DROP TABLE SC2;

DROP TABLE SC3;

DROP TABLE Systematic_Catalogue;

CREATE TABLE Alphabetical_Catalogue

(Code NUMBER(6) NOT NULL,

Reference VARCHAR2(25) NULL,

Authors VARCHAR2(120) NULL,

Title VARCHAR2(250) NULL,

Is_Article NUMBER(1) NULL,

Magazine_Or_Publisher VARCHAR2(200) NULL,

Year VARCHAR2(20) NULL,

Volume NUMBER(2) NULL,

Issue VARCHAR2(20) NULL,

From_Page NUMBER(4) NULL,

Till_Page NUMBER(4) NULL,

Is_Russian NUMBER(1) NULL,

Abstract LONG NULL,

Paper VARCHAR2(50) NULL,

Code1 NUMBER(6) NULL,

Code2 NUMBER(6) NULL,

Code3 NUMBER(3) NULL,

Keyword1 VARCHAR2(50) NULL,

Keyword2 VARCHAR2(50) NULL,

Keyword3 VARCHAR2(50) NULL,

Keyword4 VARCHAR2(50) NULL,

Keyword5 VARCHAR2(50) NULL,

Keyword6 VARCHAR2(50) NULL,

Keyword7 VARCHAR2(50) NULL,

Keyword8 VARCHAR2(50) NULL,

Priority NUMBER(2) NULL,

Home_Library NUMBER(1) NULL,

CSU_Library NUMBER(1) NULL) ;

CREATE TABLE SC2

(Code2 NUMBER(6) NOT NULL,

Title2 VARCHAR2(40) NULL,

Code1 NUMBER(6) NULL) ;

CREATE TABLE SC3

(CODE3 NUMBER(6) NOT NULL,

TITLE3 VARCHAR2(35) NULL,

CODE2 NUMBER(6) NULL) ;

CREATE TABLE Systematic_Catalogue

(Title1 VARCHAR2(30) NULL,

Code1 NUMBER(6) NOT NULL) ;

CREATE OR REPLACE VIEW A_C AS

SELECT

Code,

Reference,

Authors,

Title,

Is_Article,

Magazine_Or_Publisher,

Year,

Volume,

Issue,

From_Page,

Till_Page,

Is_Russian,

Abstract,

Paper,

Keyword1,

Keyword2,

Keyword3,

Keyword4,

Keyword5,

Keyword6,

Keyword7,

Keyword8,

Priority,

Home_Library,

CSU_Library,

Title1,

Title2,

Title3

FROM Alphabetical_Catalogue, Systematic_Catalogue, SC2, SC3

WHERE Alphabetical_Catalogue.Code1=Systematic_Catalogue.Code1 AND

Alphabetical_Catalogue.Code2=SC2.Code2 AND

Alphabetical_Catalogue.Code3=SC3.Code3

WITH READ ONLY;

CREATE INDEX iA_C1 ON Alphabetical_Catalogue

(Code);

CREATE INDEX iA_C2 ON Alphabetical_Catalogue

(Reference);

CREATE INDEX iA_C3 ON Alphabetical_Catalogue

(Keyword1);

CREATE INDEX iA_C4 ON Alphabetical_Catalogue

(Keyword2);

CREATE INDEX iA_C5 ON Alphabetical_Catalogue

(Keyword3);

CREATE INDEX iA_C6 ON Alphabetical_Catalogue

(Keyword4);

CREATE INDEX iA_C7 ON Alphabetical_Catalogue

(Keyword5);

CREATE INDEX iA_C8 ON Alphabetical_Catalogue

(Keyword6);

CREATE INDEX iA_C9 ON Alphabetical_Catalogue

(Keyword7);

CREATE INDEX iA_C10 ON Alphabetical_Catalogue

(Keyword8);

CREATE INDEX iA_C11 ON Alphabetical_Catalogue

(Authors);

CREATE INDEX iSystematic_Catalogue_1 ON Systematic_Catalogue

(Code1);

CREATE INDEX iSystematic_Catalogue_2 ON Systematic_Catalogue

(Title1);

CREATE INDEX iSC2_1 ON SC2

(Code2);

CREATE INDEX iSC2_2 ON SC2

(Title2);

CREATE INDEX iSC3_1 ON SC3

(CODE3);

CREATE INDEX iSC3_2 ON SC3

(Title3);

CREATE OR REPLACE PACKAGE bibl

FUNCTION GetYear (S VARCHAR2)

RETURN NUMBER;

PRAGMA RESTRICT_REFERENCES (GetYear, WNDS, WNPS);

END bibl;

CREATE OR REPLACE PACKAGE BODY bibl

FUNCTION GetYear (S VARCHAR2)

RETURN NUMBER

i NUMBER;

done BOOLEAN;

BEGIN

done := FALSE;

i := LENGTH (S);

WHILE NOT done AND (i>1) LOOP

IF SUBSTR (S, i, 1) NOT IN ('0','1','2','3','4','5','6','7','8','9') THEN

done := TRUE;

ELSE

i := i-1;

END IF;

END LOOP;

IF done THEN

RETURN TO_NUMBER (SUBSTR (S, i+1));

ELSE

RETURN TO_NUMBER (SUBSTR (S, i));

END IF;

END;

ENDbibl;

Приложение 2. Спецификации переноса базы данных из MS Access в Oracle

Деструктуризация процесса переноса базы данных

Перенос осуществляется в 4 этапа:

экспорт из MS Access в файл SQL-сценария import.sql (в каталог c:\), осуществляемый программой export.mdb;

сжатие полученного файла сценария с помощью программы gzip;

передача сжатого файла по протоколу FTP на Unix-машину;

импорт из созданного файла в базу данных Oracle (запуск файла loaddata.sh).

Ограничения на данные в исходных таблицах

Для правильного экспорта таблиц из MS Access в файл длина MEMO-поля - Алфавитный каталог. Аннотация не должна превышать 2000 символов (строки имеющие MEMO-поля длиной больше 2000 символов автоматически урезаются до этой длины при экспорте во внешний файл).

Импорт

Импорт производится запуском файла loaddata.sh на Unix-машине, из каталога, где находится сжатый файл SQL-сценария import.sql.gz. Следует быть уверенным, что в файле имеются корректные имя пользователя, его пароль, а также строка соединения (алиас) с базой данных, в виде user_name/user_password@connect_string. После окончания импорта следует проверить созданный .log файл на предмет ошибок и отвергнутых записей. Кроме того, необходимо наличие на Unix-машине установленной и сконфигурированной клиентской части Oracle.

Дипломная работа: Использование Internet/intranet технологий для организации доступа к базам данных

Похожие рефераты: