Міністерство загальної та професійної освіти РФ
Виконавець Апанасенко Є.В.
Челябінський державний університет
Факультет математичний
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]:
при перегляді документа клієнт зустрічає посилання на сторінку, що містить одну або декілька форм, призначених для запиту даних з бази даних;
клієнт запрошує цю сторінку; крім незаповнених форм сторінка містить загальну інформацію про базу даних і про призначення пропонованих форм;
| Призначення | Приклад Фізичних Каталогів | Приклад Віртуальних Каталогів |
| Applet codebase | c: orantforms50java | / Web_code / |
| HTML файли | c: web_formshtml | / Web_html / |
| JAR-файли | c: orantforms50java | / 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
повідомляє серверу, що наступні за цим повідомленням дані - є документ у форматі HTML;
Location
вказує серверу, що повертається не сам документ, а посилання на нього. Якщо аргументом є URL, то сервер передасть вказівку клієнту на перенаправлення запиту. Якщо аргумент являє собою віртуальний шлях, сервер поверне клієнтові заданий цим шляхом документ, як якби клієнт запитував цей документ безпосередньо.
Status
задає серверу HTTP/1.0 рядок-статус, яка буде надіслана клієнта у форматі: nnn xxxxx
де: nnn - 3-х цифровий код статусу
ххххх - рядок причини
Наприклад: HTTP/1.0 200 OK
Server: NCSA/1.0a6
Content-type: text / plain
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-> divpare ("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-> divpare ("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 1994 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
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 - технологій для доступу до існуючих баз даних
Основи використання WWW - технологій для доступу до існуючих баз даних
Досвід використання ADO для доступу до баз даних форматів MS Access xBase і Paradox
Використання баз даних та інформаційно пошукових систем для раціона
Використання баз даних та інформаційно-пошукових систем для раціонального ведення діловодства
Засоби доступу до баз даних в Internet і вільно доступна СУБД POSTGRES95
Правова охорона програм для ЕОМ і баз даних
Використання баз даних математичних задач у процесі підготовки учнів 11 х класів до ЄДІ з
Використання баз даних математичних задач у процесі підготовки учнів 11-х класів до ЄДІ з
написати до нас