Засоби доступу до баз даних в Internet і вільно доступна СУБД POSTGRES95 Засоби доступу до баз даних на стороні сервера  CGI        API        FastCGI      

CGI

Common Gateway Interface - це специфікація інтерфейсу взаємодії Web-сервера з зовнішніми прикладними програмами. Головне призначення CGI -- забезпечення однакового потоку даних між сервером і працюють на ньому додатком. CGI визначає:  порядок взаємодії сервера з прикладною програмою, у якому      сервер виступає ініціації стороною;  механізм реального обміну даними і керуючими командами в цьому      взаємодії, що не визначено в протоколі HTTP. Такі поняття, як      метод доступу, змінні заголовка, MIME, типи даних, запозичені з      HTTP і роблять специфікацію прозорою для тих, хто знайомий з самим      протоколом.

Зазвичай гіпертекстові документи, що повертаються за запитом клієнта WWW сервером, містять статичні дані. CGI забезпечує засоби створення динамічних Web-сторінок на основі даних, отриманих від користувача. Програми, написані відповідно до специфікації CGI, називаються CGI-скриптами або шлюзами. Шлюз - це CGI-скрипт, який використовується для обміну даними з іншими інформаційними ресурсами Internet або додатками-демонами такими, як, наприклад, система управління базами даних. Звичайна CGI-програма запускається Web-сервером для виконання певної роботи, повертає результати сервером та завершує своє виконання (рис. 1).

Рис. 1. Схема взаємодії CGI-скрипта.

Шлюз виконується точно також, тільки, фактично, він ініціює взаємодію в якості клієнта з третьою програмою (рис. 2). Якщо ця третя програма є сервером БД, шлюз стає клієнтом СУБД, який надсилає запит за певним порту з'єднання з системою управління базами даних, а після отримання відповіді пересилає його WWW-сервера.

Рис.2. Схема взаємодії CGI-шлюзу.

Обмін даними по специфікації CGI реалізується звичайно через змінні оточення і стандартний ввід/вивід. Вибір механізму передачі параметрів визначається методом доступу, який вказується у формі в атрибуті METHOD. Якщо використовується метод GET, то передача параметрів відбувається за допомогою змінних оточення, які сервер створює при запуску зовнішньої програми. Через них передається додатку як службова інформація (версія програмного забезпечення, доменне ім'я сервера тощо), так самі дані (у змінній QUERY_STRING). При методі POST для передачі використовується стандартний ввід. А в змінних оточення фіксується тип і довжина переданої інформації (CONTENT_TYPE і CONTENT_LENGTH).

Стандартний вивід використовується скриптом для повернення даних сервера. При цьому висновок складається із заголовка і власне даних. Результат роботи скрипта може передаватися клієнтові без будь-яких перетворень з боку сервера, якщо скрипт забезпечує побудову повного HTTP-заголовку, у противному випадку сервер модифікує заголовок відповідно до специфікації HTTP. Обов'язковим для скриптів при генеруванні документів "на льоту", коли реального документа у файловій системі сервера не залишається є тільки HTTP-заголовок Content-type, в якому вказується тип що повертається документа для правильної інтерпретації браузером. Зазвичай в Content-type вказують текстові типи text/plain та text/html. При використанні такого виду скриптів слід враховувати, що не всі сервери та клієнти відпрацьовують так, як видається розробнику скрипта. Так, за умов згадування Content-type: text/html, деякі клієнти не реалізують сканування отриманого тексту на предмет наявності в ньому вбудованої графіки

При застосування специфікації CGI для обміну даними із зовнішніми прикладними програмами можна виділити наступні переваги:  Прозорість використання;  "Мовна" незалежність - CGI-програми можуть бути      написані на будь-якій мові програмування, чи командному мовою, які мають      засоби роботи з рядками;  Процесна ізольованість - при запуску CGI-програми на сервері      породжується окремий процес і хибний CGI-скрипт не може зламати      Web-сервер або отримати доступ до закритої інформації;  Відкритість стандарту - CGI інтерфейс застосовний на кожному      Web-сервер;  Архітектурна незалежність - CGI не залежить від особливостей      реалізації архітектури сервера (однопоточний, багатопоточності і т.д.);

Але CGI має також і суттєві недоліки. Головна проблема полягає у витратах на виконання CGI-додатків: оскільки на сервері для кожного чергового запиту породжується новий процес, який завершується після його виконання, то це призводить до невисокого швидкодією CGI-скрипта і знижує ефективність роботи сервера. При використанні CGI-програм для доступу до баз даних через непідтримки безперервного з'єднання Web-сервера і відповідної СУБД дуже складно зробити процес "ведення" користувача базою даних, тому що кожного разу при генерації чергового запиту потрібно нове підключення. Але в той же час закриття з'єднання після обробки кожного запиту сильно ускладнює діяльність хакерів, тому що при відсутності постійного підключення до БД проникнути в неї набагато складніше. Інша гідність цього "нестачі" полягає в тому, що зв'язок з Web-сервером встановлюється тільки на короткий проміжок часу, в результаті чого він не перевантажується і може виконувати інші завдання.

CGI `також обмежений по здатності функціонування - специфікація передбачає тільки просту" відповідь "роль скрипта при генерації результату на запит користувача. CGI-програми не мають взаємозв'язків з встановленням аутентифікації користувачів та перевірки його вхідних даних.

API

У відповідь на обмеження і недоліки специфікації CGI була розроблена специфікація прикладних модулів API, вбудованих в сервер. Дане розширення Web-сервера запускається як динамічна бібліотека та виконує обробку кожного дзвінка сервера по окремій структурі пам'яті, що значно простіше, ніж створення окремого процесу для кожного клієнтського запиту. Найбільш відомі дві API-інтерфейсу - NSAPI компанії Netscape і ISAPI компанії Microsoft. Вільно поширюваний популярний Unix-сервер Apache також має модуль PHP, який реалізує даний інтерфейс. Програми, які працюють через API, з'єднуються з сервером значно швидше, ніж CGI-програми, тому що API виконується в основному процесі сервера і постійно знаходиться в стані очікування запитів, тому час на запуск програми і породження нового процесу не потрібно. API-інтерфейс надає і більшу функціональність, ніж CGI - можна написати додаткові процедури, що здійснюють контроль доступу до файлів, які отримують доступ до log-файлів сервера і зв'язуються з іншими етапами обробки запиту сервером.

Проте специфікація API не має переваг CGI-інтерфейсу і постачальники API-модулів теж стикаються з цілою низкою проблем:  "Мовна" залежність - прикладні програми можуть бути      написані тільки на мови, які підтримуються в даному API (зазвичай це С/C + +);      Perl, найбільш популярна мова для CGI-скриптів, як правило, не      використовується в існуючих поставляються API-модулях.  Неізолірованность процесу - тому що програми виконуються в      адресному просторі сервера, то помилкові програми можуть      "упустити" сервер або який-небудь додаток. Таким чином цілком      можливо (навмисно чи ні) зламати систему безпеки сервера.  Обмеженість застосування - написання програми відповідно до      даними API можуть використовуватися тільки на цьому сервері.  Архітектурна залежність - API-додатки залежні від архітектури      сервера: якщо сервер підтримує однопоточний, то багатопотокових      додатки не отримують ніякої переваги у швидкодії при      виконання. Також при зміні виробником архітектури сервера, модуль      API зазвичай теж піддається змінам, і прикладні програми      відповідно теж вимагають переробки або навіть можуть бути написані заново.      

FastCGI Інтерфейс FastCGI поєднує в собі найкращі аспекти специфікацій CGI і API. Взаємодія відповідно до FastCGI відбувається схожим чином з CGI. FastCGI-додатки запускаються окремими ізольованими процесами. Відмінність полягає в тому, що ці процеси є постійно працюючими і після виконання запиту не завершуються, а очікують нових запитів. Замість використання змінних оточення операційної системи і стандартних потоків введення/виводу протокол FastCGI об'єднує інформацію середовища, стандартний ввід, висновок і повідомлення про помилки в єдине дуплексне з'єднання. Це дозволяє FastCGI-програмам виконуватися на віддалених машинах, використовуючи TCP-з'єднання між Web-сервером і FasstCGI-модулем.

Таким чином, переваги FastCGI полягають у наступному:  Швидкодія - завдяки постійному функціонуванню      FsatCGI-процесів забезпечується обслуговування одним процесом багатьох      запитів, що вирішує завдання і пов'язані з нею проблеми породження нового      процесу на окремий клієнтський запит.  Простота застосування і легкість міграції з CGI.  "Мовна" незалежність - як і CGI, FastCGI-додатки      можуть бути написані будь-якою мовою програмування або командних мовами.        Ізольованість процесів - "несправні"      FastCGI-програми не можуть зруйнувати ядро сервера або будь-які інші      додатки, а також одержати секретну службову інформацію.  Працює - FastCGI підтримується у всіх відкритих продуктах,      включаючи комерційні сервери Netscape і Microsoft, NCSA сервер і вільно      поширюваний Apache.  Архітектурна незалежність - FastCGI інтерфейс не залежить від      особливостей реалізації серверної архітектури та прикладні програми можуть      бути як одно-, так і багато-.  Розподіленість - FastCGI забезпечує можливість виконувати      програми віддалено, що використовується для розподіленої завантаження і      управління зовнішніми Web-сайтами. Доступ до баз даних на стороні клієнта. Java-технологія

Для забезпечення доступу до баз даних на стороні Web-клієнта застосовується Java-технологія. Java - це сучасний об'єктно-орієнтована мова програмування для розробки додатків, створений спеціально для розподілених середовищ. Технологія Java дозволяє створювати повноцінні програми для роботи з комп'ютерною графікою, файловими системами та комп'ютерними мережами.

Одне з важливих властивостей Java-технології - це мобільність, суть якої полягає в тому, що написаний на Java код може виконуватися на будь-який комп'ютерної платформі. Java-додатки компілюються в особливий код (так званий байт-код), що виконується на віртуальній машині (Java Virtual Machine). Байт-код є універсальним форматом програми, єдиним для всіх апаратних платформ - і для робочих станцій, і для великих універсальних ЕОМ, і для персональних комп'ютерів. Java-технологія забезпечує швидкий цикл компіляції та відлагодження програм. Ще на стадії компіляції проводиться виявлення багатьох помилок і часткова оптимізація програм. Засоби розробки, що містять віртуальну машину всередині себе, забезпечують контроль додатків на стадії виконання (переповнення стека, відстеження кордонів масивів, пошук резервів для оптимізації та ін.)

Користувачеві готових Java-додатків досить мати клієнтську програму, що імітує роботу віртуальної машини. Віртуальна машина являє собою досить компактний інтерпретатор байт-коду Java. Перед першим запуском нової програми віртуальна машина перевіряє його код на приналежність до байт-коду (на правильність інструкцій Java), безпека команд для комп'ютера і локальної мережі, відповідність дозволеним операціями, а також на цілий ряд додаткових умов. Це необхідно, оскільки програми, що розповсюджуються по мережі, створюються різними людьми з різними намірами, причому погані наміри теж не виключені. Безпосередньо перед запуском віртуальна машина виробляє складання модулів і встановлює зв'язки між іменами, при цьому пошук відсутніх модулів проводиться не тільки в системі, але й на серверах Internet. Потім, власне, і починається робота додатків.

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

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

Для взаємодії Java-аплет із зовнішнім сервером баз даних розроблено спеціалізований протокол JDBC, який, фактично, поєднує функції шлюзування між інтерпретатором мобільних Java-кодів і інтерфейсом ODBC (Open Data Base Connectivity). JDBC - це розроблений JavaSoft прикладної SQL програмний інтерфейс API JDBC до баз даних. Цей API дозволяє використовувати стандартний набір процедур високого рівня для доступу до різних БД.

JDBC базується на інтерфейсі рівня викликів X/Open SQL CLI - основі ODBC. Прикладної програмний інтерфейс JDBC реалізується поверх інших SQL-API, включаючи ODBC. Тобто, всі бази даних, що допускають роботу з ODBC, будуть взаємодіяти з JDBC без змін. При використанні JDBC Internet-користувачі підключаються до Web-сервера і завантажують HTML-документ з аплетом. Аплет виконується на клієнтської ЕОМ в середовищі браузера і встановлює зв'язок з сервером бази даних. Механізм зв'язку з базами даних є класом Java.

Архітектура JDBC складається з двох рівнів: JDBC API, який забезпечує зв'язок між додатком і менеджером JDBC і драйвер JDBC API, який підтримує зв'язок між JDBC менеджером і драйвером (рис.3). Розробники мають можливість взаємодіяти безпосередньо з ODBC за допомогою моста JDBC-ODBC.

Рис.3. Схема взаємодії Java-додатків з сервером БД

JDBC API являє собою набір класів (пакет або package) для встановлення з'єднань з базами даних, створення SQL-виразів, обробки результатів. JDBC-драйвера можуть бути написані на Java і завантажені як частина аплету або бути написані використовуючи "рідний" код комп'ютера (як шлюз до існуючим бібліотекам СУБД API). Прикладом такого шлюзу є JDBC-ODBC міст (JDBC-ODBC bridge). Він транслює JDBC запити у виклики ODBC, що дозволяє отримати доступ до величезної безлічі існуючих ODBC драйверів.

Використання Java-аплетів у загальному забезпечує більш гнучке решеніе.Так як аплет - це частина HTML-документа, то для включення нового аплету потрібно всього-на-всього перекомпонувати документ без задіяння Web-cервера. Аплети передаються по мережі тільки в той момент, коли їх треба виконувати. При цьому вони , можна завантажити з різних місць і після завантаження взаємодіяти один з одним.

З іншого боку, байт-код Java виконується інтерпретатором, а не є скомпільованій на цій платформі програмою. Звідси виникає перший очевидний недолік - це швидкість виконання коду, так як інтерпретатор працює набагато повільніше скомпільованій програми. Власне, і інші властивості технології (об'єктна орієнтована, використання багатопоточності, відсутність адресної арифметики і т.п.) у більшості випадків при стандартній комплектації обладнання, тільки гальмують виконання програми.

Основний протокол обміну апплетами - HTTP. Це означає, що вони передаються по мережі так само, як і інші ресурси Website, і здобувають своє особливе значення тільки в момент отримання їх браузером. З огляду на неефективність реалізації HTTP поверх TCP, можна сказати, що і обмін апплетами теж неефективний, якщо для кожного обміну встановлюється своє TCP-з'єднання. У будь-якому випадку завантаження сторінок з Java відбувається набагато повільніше, чем без Java.

Java-технологія є ще технологією, що знаходиться в стадії розробки. Інтерфейс взаємодії прикладних програм CGI має вже достатній досвід у застосуванні для обробки даних і доступу до БД. У порівнянні з Java, він є не тільки налагодженим механізмом, але і більш простим і зручним засобом для розробників CGI-програм, тому що вони можуть бути створені будь-якою мовою, що має засоби роботи з рядками.

Вибір засоби доступу до баз даних багато в чому визначається не тільки ефективністю того чи іншого механізму, але також і найкращим його з'єднання з відповідної СУБД. Від того, які кошти надає сама СУБД для доступу до своїх баз даних із зовнішніх прикладних програм може залежати вибір переваги. Зараз розроблено досить багато комерційних СУБД, але все ж хочеться звернути увагу на вільно поширювані продукти, які часто виявляються не менш ефективними, але через "невідомого" не досить широко використовуються. Одним з таких некомерційних продуктів є СУБД POSTGRES95, яка встановлюється на більшості існуючих платформ-DEC Alpha AXP on OSF/1 2.0, HP PA-RISC on HP-UX 9.0, i386 Solaris, SUN SPARC on Solaris 2.4, SUN SPARC on SunOS 4.1.3, DEC MIPS on Ultrix 4.4, Intel x86 on Linux 1.2 and Linux ELF, BSD/OS 2.0, 2.01, 2.1, IBM on AIX 3.2.5, SGI MIPS on IRIX 5.3, DG/UX 5.4R3.10 та ін Постреляціонная СУБД POSTGRES95

СУБД POSTGRES95 була спроектована і розроблена в Каліфорнійському університеті м. Берклі під керівництвом відомого фахівця в області баз даних професора Стоунбрейкера, який у 1975-1980 рр.. створив досить популярну реляційну СУБД Ingres. Напрямок POSTGRES належить до числа так званих постреляціонних систем - до наступного етапу в розвитку реляційних СУБД. В даний час основним предметом критики останніх є не їх недостатня ефективність, а притаманна цим системам деяка обмеженість (прямий наслідок простоти) при використанні в нетрадиційних областях, в яких потрібні гранично складні структури даних. Іншим, часто відзначаються недоліком реляційних баз даних, є неможливість адекватного відбиття семантики предметної області. Тому сучасні дослідження в області постреляціонних систем, головним чином, присвячені усунення саме цих недоліків, і багато в чому вимоги до цих систем означають просто необхідність реалізації властивостей, відсутніх у більшості поточних реляційних СУБД. До них належать, наприклад, входить повнота системи типів, підтримка ієрархії і успадкування типів, можливість управління складними об'єктами і т.д. СУБД POSTGRES95, будучи постреляціонной системою, зберігає основні властивості реяціонних СУБД і в той же час має свої, відмінні від інших, можливості.

СУБД POSTGRES95 підтримує темпоральних модель зберігання і доступу до даних. Тобто для будь-якого об'єкта даних, створеного в момент часу t1 і знищеного в момент часу t2, в БД зберігаються (і доступні користувачам) всі його стану в часовому інтервалі (t1, t2). Звичайні ж БД зберігають миттєвий знімок моделі предметної області, і будь-яка зміна в момент часу t деякого об'єкта приводить до недоступності цього об'єкта в попередній момент часу. Хоча, насправді, у більшості розвинених СУБД попередній стан об'єкту зберігається в журналі змін, але здійснення доступу з боку користувача немає.

У зв'язку з цим, в POSTGRES95 переглянутий механізм журналізацію змін, відкатів транзакцій та відновлення БД після збою. Особливість системи управління пам'яттю полягає в тому, що не ведеться звичайна журналізацію і миттєво забезпечується коректне стан БД з втратою стану в оперативній пам'яті. Також система управління пам'яттю підтримує історичні дані, відповідні можливості роботи з якими закладені в мову POSTQUEL. Запити можуть містити вибірку даних в певний час, в певному інтервалі часу. Наприклад, результатом запиту SELECT city, population FROM cities [ 'epoch', 'now'] WHERE city = 'Moscow';

буде наступна таблиця:         city          population             Moscow         7 360 000             Moscow         8 950 000     

Крім цього, є можливість створювати версії відносин і допускається їх подальша модифікація з урахуванням змін основних варіантів.

Основне рішення цих аспектів полягає в тому, що при модифікації кортежу зміни здійснюються не на місці його зберігання, а заводиться новий запис, куди поміщаються змінені поля. Ця запис, що містить також і дані, що характеризують транзакцію, виробляла зміни (у тому числі і час її завершення), підшивається до списку до мінливих кортежу.

Одним з основних положень реляційної моделі даних є вимога нормалізації відносин: поля кортежів можуть містити лише атомарні значення. Приведення вихідного табличного подання предметної області до першої нормальної форми є основним кроком у процесі проектування реляційної бази даних. У СУБД POSTGRES95 реалізована "ненормалізованная" реляційна модель даних, яка допускає зберігання в якості елемента кортежу багатовимірних масивів фіксованої і змінної довжини, та інших даних, у тому числі абстрактних, визначених користувачами типів: CREATE TABLE salary (name text, pay_by_quarter int4 [], schedule char16 [] []);

Ця властивість POSTGRES95 зближує її з властивостями об'єктно-орієнтованих СУБД, хоча семантичні можливості моделі даних POPSTGRES95 істотно слабкіше.

Мова запитів СУБД POSTGRES95 - POSTQUEL-є варіантом нового стандарту мови SQL-3. Він має оператори для визначення схеми бази даних (CREATE TABLE, ALTER TABLE), маніпулювання даними (UPDATE-замінити, DELETE - видалити, SELECT-вибрати, INSERT-вставити і ін), оператори управління транзакціями, предоставлений і обмежень доступу та ін POSTQUEL, крім цього, надає багато додаткових можливостей. В їх число входять розширена система типів (крім звичайних типів int, float, real, smallint, char (N), varcha (N), date, time та ін реалізована можливість створення користувачами довільного числа своїх типів), підтримується ієрархія та наслідування класів, надається можливість визначення власних функцій, операторів і агрегатів. У таблицях можуть зберігатися дані розміром більше 8 KB. Це дозволяє здійснювати, так званий, інтерфейс великих об'єктів (Large Objects Interface), який застосовує файл-орієнтований доступ до даних, оголошених як тип large. POSTQUEL не підтримує підзапит, але вони можуть легко бути здійснені за допомогою самостійно написаних SQL-функцій.

POSTQUEL підтримує два типи функцій: SQL-функції та функції, написані на мові програмування, наприклад, на Сі. Окрім функцій, користувач може створювати свої агрегати і оператори. POSTGRES95 дозволяє легко вводити нові структури, використовуючи не фізичну, а логічну модель зберігання даних. У системних каталогах POSTGRES95, на відміну від стандартних реляційних систем, зберігається інформація не тільки про відносини і атрибутах, але також і інформація про типи, функції, методи доступу і т.п. У POSTGRES95 системні каталоги представлені наступними класами: pg_database - бази даних; pg_class - відносини; pg_attribut - атрибути; pg_proc - процедури (і на Сі, і на SQL); pg_type - типи; pg_aggregate - функції та агрегати; та ін Кожен клас розташовується в файлі з відповідним ім'ям, яке починається з pg_, куди містяться всі внесені користувачем зміни при створенні таблиць, типів, функцій і т.д. Між класами встановлені відносини, які дозволяють пов'язувати різні структури і здійснювати внутрішні операції між ними. Архітектура СУБД POSTGRES95

Архітектура СУБД POSTGRES95 заснована на моделі "клієнт-сервер". Сесія з СУБД складається з наступних взаємодіючих процесів:   postmaster - керуючий      процес-демон, який керує взаємодією між зовнішніми та внутрішніми      процесами; він виділяє спільно використовуваний буферу динамічної пам'яті      та виконує інші ініціалізації під час запуску.   postgres - внутрішній      серверний процес бази даних, що виконує запити клієнта. Postmaster      завжди запускає новий postgres-процес для кожного клієнтського      додатки. Цей серверний процес виконується на машині сервера.  зовнішня прикладна програма, яка може знаходитися на іншому      комп'юторі (наприклад, робочої станції). Вона з'єднується з postgres через      postmaster.

Один раз запущений процес-демон postmaster керує встановленим набором баз даних на серевере. Зовнішня прикладна програма, яка бажає отримати доступ до однієї з цих баз даних, викликає бібліотеку функцій прикладного програмного інтерфейсу LIBPQ (рис.4). За допомогою цих функцій запит по мережі передається postmaster'у, який породжує серверний процес і з'єднує зовнішню програму з сервером. З цього моменту клієнтські та серверні процеси взаємодіють без допомоги postmaster'a. Таким чином, postmaster постійно працює, чекаючи запитів, в той час, як відбуваються і завершуються з'єднання із зовнішніми програмами. Прикладної програмний інтерфейс LIBPQ дозволяє однієї клієнтської програмі здійснювати під час однієї сесії множинні з'єднання з сервером БД. Але тим не менше, зовнішня програма - це однопотоковий процес. Нить процесів бібліотекою LIBPQ не підтримується. Іншою особливістю архітектури СУБД POSTGRES95 є те, що postmaster і postgres серверні процеси завжди виконуються на одній і тій же машині - сервер бази даних, тоді як зовнішні програми можуть перебувати на будь-яких машинах мережі.

Рис. 4. Схема взаємодії процесів POSTGRES95

Таким чином, СУБД POSTGRES95 дозволяє здійснювати доступ клієнтських прикладних програм до своїх баз даних не тільки в локальному, а й віддаленому режимі. Але система безпеки СУБД не надає цю можливість всім користувачам. Для вирішення віддаленого з'єднання з базами даних необхідно встановити режим аутентифікації для даного користувача. За замовчуванням у файлі конфігурації цей режим відключений, і доступ дозволений тільки програмами, розташованим в директорії на машині сервера БД. Для встановлення аутентифікації необхідно у файлі pq_hba вказати імена машин, з яких можливий вилучений доступ прикладним програмам, і відповідні бази даних, до яких дозволяється віддалений доступ: # All 127.0.0.1 0.0.0.0 all 194.85.135.66 0.0.0.0

Після цього необхідно провести заново компіляцію системи. Доступ до баз даних під керуванням СУБД POSTGRES95

У СУБД POSTGRES95 реалізовані дві основні можливості доступу до своїх баз даних:  через psql - інтерфейс командного рядка командної оболонки Shell;  з прикладної програми, написаної на мові програмування Сі      (або іншою мовою) з використанням функцій прикладного інтерфейсу LIBPQ.

Psql - це інтерактивний термінальний монітор, що дозволяє користувачеві формулювати, редагувати і виконувати набори команд - операторів мови POSTQUEL. Він запускається в режимі командного рядка ОС UNIX із зазначенням імені бази даних: % Psql polyn

Користувач може безпосередньо з командного рядка монітора вводити одну за одною SQL-команди, а може передавати запит у вигляді файлу з SQL-операторами через командний рядок ОС UNIX: % Psql

Інтерфейс командного рядка psql зазвичай використовують адміністратори баз даних для створення, модифікації і видалення відносин, заклади та надання прав новим користувачам і т.д. Він досить зручний для введення великих масивів інформації до бази даних та виведення простих звітів. Інтерактивний монітор не дозволяє генерувати складні форми звітів, тому що з його допомогою не можна зробити розбирання отриманого результату для формування нових запитів, і тому його використання в прикладних програмах досить обмежено.

LIBPQ - прикладний програмний інтерфейс POSTGRES95. Він представлений набором бібліотечних функцій (підпрограм), які дозволяють клієнтських програм надсилати запити серверу СУБД і отримувати від нього відповідні результати. Для цього в прикладну програму включають головний файл бібліотеки libpq-fe.h, вбудовують функції LIBPQ і виробляють компіляцію коду програми з бібліотеками POSTGRES95. Схема доступу до баз даних із зовнішніх програм достатньо проста. За допомогою спеціальної функції PQsetdb встановлюється TCP-з'єднання з певного порту (як правило, - 5432) прикладної програми з процесом-демоном postmaster'ом. При цьому функції передаються параметри значень імені бази даних, IP-адресу сервера, порту з'єднання. Далі при успішному з'єднанні відбувається виконання в рамках функції PQexec SQL-операторів мови запитів POSTQUEL - відкриття транзакції з базою даних, виконання запиту і закриття транзакції. Після цього відбувається завішане з'єднання з базою даних. При виконанні запиту на вибір даних з БД POSTGRES95 створює тимчасову таблицю, в яку поміщає отриманий результат. Використовуючи SQL-оператори, пов'язані з курсором, і спеціальні функції LIBPQ по роботі з кортежами, полями відносин, достатньо просто здійснюється доступ до елементів результуючої таблиці, що призводить до створення довільних звітів за запитами користувачів. Нижче наведено фрагмент Cі-програми, що реалізує запит до бази даних "polyn": pghost = "ns.polyn.kiae.su" pgport = "5432"; pgoptions = NULL; pgtty = NULL; dbname = "polyn"/* установка з'єднання з базою даних */conn = PQsetdb (pghost, pgport, pgoptions, pgtty , dbname);/* перевірка статусу виконання з'єднання */if (PQstatus (conn) == CONNECTION_BAD) (printf ( "connection to database '% s' failed", dbname); printf ( "% s", PQerrorMessage (conn) ); PQfinish (conn); exit (1 );}/* початок транзакції з БД */res = PQexec (conn, "BEGIN ");/* перевірка статусу виконання функції */if (PQresultStatus (res)! = PGRES_COMMAND_OK) (printf ( "BEGIN command failed"); PQclear (res); PQfinish (conn); exit (1);) PQclear (res);/* виконання SQL-опреатора установки курсору на результат запиту вибору поля isotop з відношення isotop */res = PQexec (conn, "DECLARE myportal CURSOR FOR select isotop.isotop from isotop ");/* виконання оператора читання по курсору */res = PQexec (conn," FETCH ALL in myportal ");/* визначення кількості кортежів та атрибутів в результуючої таблиці */ntups = PQntuples (res); nflds = PQnfields (res);/* висновок імен атрибутів */for (i = 0; i % s ", PQfname (res, i ));}/* висновок елементів результуючого відносини */for (i = 0; i% sn", PQgetvalue (res, i, j));)) PQclear (res);/* закриття курсору */res = PQexec (conn, "CLOSE myportal"); PQclear (res);/* закриття транзакції */res = PQexec (conn, "END"); PQclear (res);/* закриття з'єднання */PQfinish (conn);

Для здійснення доступу до баз даних POSTGRES95 з World Wide Web можна використовувати будь-які описані вище механізми - CGI, FastCGI, API, Java. Наприклад, API-модуль сервера Apache PHP підтримує взаємодію з бібліотеками POSTGRES95, а також розроблені дві ODBC-драйвера, PostODBC і OpenLink ODBC, які спрощують розробку програм-шлюзів. Але все ж не варто забувати і про досить зручному і простому засобі побудови інтерактивних додатків - Common Gataway Interface, який не вимагає ніякого додаткового програмного забезпечення і досить легкий у застосуванні. У Як приклад використання CGI для доступу до баз даних під керуванням POSTGRES95 можна навести створену для РНЦ "Курчатовський інститут" інформаційну систему бази чисельних даних про радіаційний забруднення 30-км зони навколо ЧАЕС "Проба" на Web-сервер Apache. Створення інформаційної системи було спрямовано на виконання наступних завдань:  Введення нової інформації в БД для ведення бази даних.  Генерація звітів по запитам користувачів.

Структура взаємодії програмного забезпечення інформаційної системи виглядає наступним чином (рис. 5). Відповідно до технології WWW, сервер протоколу HTTP Apache, що працює, як правило, по 80-му порту стека протоколів TCP-IP, приймає запити від користувача за допомогою клієнтських програм перегляду гіпертекстових документів (Netscape Navigator, Internet Explorer, Lynx та ін.) Формалізована доступ до даних у рамках інформаційної системи здійснюється на основі HTML-форм. З їх допомогою введені в поля форми дані передаються на сервер Apache, який викликає зазначену у формі CGI-програму для обробки цих параметрів і передає їй управління. CGI-скрипт за допомогою функцій прикладного інтерфейсу СУБД POSTGRES95 перетворить дані в SQL-запит, встановлює з'єднання з сервером СУБД і передає йому запит на виконання. Сервер СУБД виконує запит, звертаючись до БД "Проба" і повертає результат CGI-скрипту, який, у свою чергу, формує "на-льоту" HTML-документ і через сервер Apache передає його клієнту.

Рис. 5. Структура взаємодії програмного забезпечення інформаційної системи

Всі навигаціонние HTML-сторінки інформаційної системи згенерована CGI-програмами, тому що всі HTML-форми -- для введення пошукових критеріїв (рис.6) та введення нових даних для оновлення БД (рис.7) - містять значення з файлів словників, що забезпечує більш зручний інтерфейс і більш швидке заповнення анкети.

Для даної інформаційної системи недоліки CGI, пов'язані з породженням нового процесу не так суттєві -- втрата відбувається лише в незначних витратах часу на очікування відповіді сервера. Але якщо потрібна автентифікація кожного користувача і його ведення під час сеансу взаємодії з базою даних, то, на погляд автора, FastCGI є найкращим вирішенням цього питання. Тобто використання того чи іншого засобу залежить насамперед від поставленого завдання для реалізації - що необхідно в першу чергу забезпечити при її вирішенні

Рис. 6. Інтерфейсна сторінка для пошуку даних

Рис. 7. HTML-сторінка для оновлення бази даних Висновок

Таким чином, на сьогоднішній день існує достатньо засобів, що забезпечують як зберігання накопичених масивів інформації, так і здійснюють зручний доступ до них через інтерфейс World Wide Web. І не завжди їх необхідно купувати за комерційними розцінками. Internet надає багато ресурсів безкоштовно - необхідно мати лише бажання і певну наполегливість для їх отримання. Вільно поширюється СУБД POSTGRES95 є тому очевидним прикладом. А засоби доступу з WWW вибирайте самі - всі вони досить функціональні і вибір залежить в основному від цілей, які ви перед собою ставите. Список літератури  С.Д. Кузнєцов. Введення в      СУБД. "СУБД" 2-3,1996 р.  С. Д. Кузнецов. Доступ до      баз даних з використанням технології WWW. "СУБД" 5-6,      1996  http://oozoo.vnet.net/postgres95/        http://www.fastcgi.com