Министерство общего и профессиональногообразования РФ
Дипломная работа
Исполнитель Апанасенко Е.В.
Челябинский государственный университет
Факультет математический
1. Введение
Базыданных настолько тесно вошли в нашу жизнь, что без их помощи не мыслитсядеятельность ни одной организации. С появлением локальных сетей, подключениемтаких сетей к Internet, созданием внутрикорпоративных сетей на базе intranet,появляется возможность с любого рабочего места организации получить доступ кинформационному ресурсу сети, такому как база данных. Однако, при попытке использоватьсуществующие базы данных возникают проблемы связанные с требованиемоднородности рабочих мест (для запуска «родных» интерфейсов), большимтрафиком в сети (доступ идет напрямую к файлам базы данных), загрузкойфайлового сервера и невозможностью удаленной работы (например, командированныхсотрудников). Так, для каждой используемой базы данных необходим свойспецифический клиент, такой как модуль времени исполнения или исполняемый файл,реализующий функциональность клиента. Клиентский компьютер должен бытьдостаточно мощным, для того чтобы справиться с обработкой функциональностиклиента. Решением проблемы является использование унифицированного интерфейсаWWW для доступа к информационным ресурсам организации [4].
Средипреимуществ такого подхода возможность доступа к базе данных посредством такназываемого ⌠тонкого клиента■ — компьютера с установленной на немстандартной программой-обозревателем Internet (Netscape Communicator, MicrosoftInternet 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 RC440-битное шифрование (для передачи между клиентом форм и сервером форм) и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). Далеенеобходимо набрать
\bin\f50srv32port=номер_порта и нажать Enter.
Послеэтого будет запущен процесс слушателя на указанном порту. При опускании номерапорта, процесс стартует, используя по умолчанию порт 9000. Этот номер долженсовпадать с номером порта, который указывается в HTML файле (см. п.3обеспечение конечным пользователям доступа к приложению).
Дляпроверки состояния запущенного сервера форм можно посмотреть вкладку Processesв окне Менеджера задач NT. Если прослушивающий процесс запущен, то будетприсутствовать процесс с именем F50SRV32.EXE, а также несколько процессовF50WEB32.EXE (один для каждого активного соединения).
Дляостановки Слушателя сервера форм необходимо выбрать пункт End Process в окнеМенеджера задач NT.
3.обеспечение конечным пользователям доступа к приложению
3.1. создание виртуальных каталогов наWeb-сервере
Виртуальныекаталоги представляют собой отображение физических каталогов сервераприложений. Для работы сервера форм необходимо создать 3 виртуальных каталога.Имена каталогов могут быть любыми √ они указываются в HTML файле вкачестве параметров апплета клиента форм. Виртуальные каталоги используются дляскрытия длинных путей к файлам на сервере приложений, а также для упрощенияпереноса системы (в случае переноса системы на другой сервер или перемещенияфайлов приложения в другие каталоги, необходимо будет лишьсоздать/модифицировать соответствующие виртуальные каталоги на Web-сервере,вместо того, чтобы модифицировать существующие HTML файлы).
Нижеразъясняется семантика создаваемых виртуальных каталогов:
Appletcodebase (является тэгом, т.е. ключевым словом 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:
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
сообщаетсерверу, что следующие за этим сообщением данные — есть документ в форматеHTML;
Location
указываетсерверу, что возвращается не сам документ, а ссылка на него. Если аргументомявляется URL, то сервер передаст указание клиенту на перенаправление запроса.Если аргумент представляет собой виртуальный путь, сервер вернет клиентузаданный этим путем документ, как если бы клиент запрашивал этот документнепосредственно.
Status
задаетсерверу HTTP/1.0 строку-статус, которая будет послана клиенту в формате: nnnxxxxx
где:nnn — 3-х цифровой код статуса
ххххх- строка причины
Например:HTTP/1.0 200 OK
Server: NCSA/1.0a6
Content-type: text/plain
Вслучае метода запроса 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.
Например
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 символов;
Декодироватьимена и их значения (учитывая, что все пробелы при декодировании сервером былизаменены символом “+” и все символы с десятичным кодом больше 128преобразованы в символ “%” и следующим за ним шестнадцатеричным кодомсимвола.);
Сформироватьструктуру соответствия «имя-значение» для дальнейшего использования вcgi-модуле.
Послеформирования структуры «имя-значение» можно приступить к решениюзадач, ради которых, собственно, создавался cgi-модуль. Следующим важныммоментом является динамическое формирование cgi-модулем HTML-документа(оформление результата работы модуля). Например, таблицы выборки из базыданных.
Дляэтого cgi-модуль должен выдать в стандартный выходной поток заголовок,состоящий из строки:
Content-type:text/html и пустой строки (двух символов CR).
Послеэтого заголовка можно выдавать любой текст в формате HTML.
Какуже говорилось ранее, CGI-скрипт играет роль посредника между Web-сервером и другимивидами серверов, в частности с сервером баз данных. В качестве языкаCGI-скриптов часто выступает язык Perl [11] (Practical Extraction and ReportLanguage)- интерпретируемый язык, приспособленный для обработки произвольныхтекстовых файлов, извлечения из них необходимой информации и выдачи сообщений.Здесь будет освящен вопрос доступа к базе данных Oracle из языка perl.
Этовозможно благодаря наличию в свободно-доступной библиотеке Perl-модулей(доступна на 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 forerrors
— установка соединения с базой данных Oracle
$cursor = $dbh->prepare(«SELECT Fie1d, Field2 FROM Table1 ORDERBY 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, Field3FROM 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 для WindowsNT. Это связано с мощностью и гибкостью сервера 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,
NetscapeCommunicator 4.04 (более ранние версии не рассматривались, в силу того, что онизаведомо несовместимы со стандартом JDK 1.1.x).
Корректнаяподдержка руского языка в Java-апплетах существовала лишь в Microsoft InternetExplorer 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 ServerEnterprise 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 версии библиографическогокаталога по программированию и базам данных на математическом факультетеЧелябинского государственного университета:reindeer.math.cgu.chel.su/oracle/bibl (акт о внедрении прилагается);
наоснове описанной CGI-технологии реализована и внедрена в промышленнуюэксплуатацию система отчетности по торгам на Южно-Уральской фондовой бирже: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. // EOUGOracle User Forum 94 17-20 April 1994, Maastriht, The Netherlands.
The Committee for Advanced DBMS Function. Third GenerationDatabase 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
IS
FUNCTION GetYear (S VARCHAR2)
RETURN NUMBER;
PRAGMA RESTRICT_REFERENCES (GetYear, WNDS, WNPS);
END bibl;
/
CREATE OR REPLACE PACKAGE BODY bibl
IS
FUNCTION GetYear (S VARCHAR2)
RETURN NUMBER
IS
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;
END bibl;
/
Приложение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.
Список литературы
Дляподготовки данной работы были использованы материалы с сайта www.csu.ac.ru