Postgres95 постреляционная субд postgres95


Содержание

Доступ к базам данных под управлением СУБД POSTGRES95

В СУБД POSTGRES95 реализованы две основные возможности доступа к своим базам данных:

— через psql — интерфейс командной строки командной оболочки Shell;
— из прикладной программы, написанной на языке программирования Си (или другом языке) с использованием функций прикладного интерфейса LIBPQ.

Psql — это интерактивный терминальный монитор, позволяющий пользователю формулировать, редактировать и выполнять наборы команд — операторов языка POSTQUEL. Он запускается в режиме командной строки ОС UNIX с указанием имени базы данных:

Пользователь может непосредственно из командной строки монитора вводить одну за другой SQL-команды, а может передавать запрос в виде файла с SQL-операторами через командную строку ОС UNIX:

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

LIBPQ — прикладной программный интерфейс POSTGRES95. Он представлен набором библиотечных функций (подпрограмм), которые позволяют клиентским программам посылать запросы серверу СУБД и получать от него соответствующие результаты. Для этого в прикладную программу включают главный файл библиотеки libpq-fe.h , встраивают функции LIBPQ и производят компиляцию кода программы с библиотеками POSTGRES95. Схема доступа к базам данных из внешних программ достаточно простая. С помощью специальной функции PQsetdb устанавливается TCP-соединение по определенному порту (как правило, — 5432) прикладной программы с процессом-демоном postmaster’ом. При этом функции передаются параметры значений имени базы данных, IP-адреса сервера, порта соединения. Далее при успешном соединении происходит выполнение в рамках функции PQexec SQL-операторов языка запросов POSTQUEL — открытие транзакции с базой данных, выполнение запроса и закрытие транзакции. После этого происходит завешение соединения с базой данных. При выполнении запроса по выбору данных из БД POSTGRES95 создает временную таблицу, в которую помещает полученный результат. Используя SQL-операторы, связанные с курсорами, и специальные функции LIBPQ по работе с кортежами, полями отношений, достаточно просто осуществляется доступ к элементам результирующей таблицы, что приводит к генерации произвольных отчетов по запросам пользователей. Ниже приведен фрагмент Cи-программы, реализующей запрос к базе данных «polyn»:

Для осуществления доступа к базам данных 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 передает его клиенту.

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

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

Реферат: Средства доступа к базам данных в Internet и свободно доступная СУБД POSTGRES95

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

  • CGI
  • API
  • FastCGI

Common Gateway Interface — это спецификация интерфейса взаимодействия Web-сервера с внешними прикладными программами. Главное назначение CGI — обеспечение единообразного потока данных между сервером и работающим на нем приложением. CGI определяет:

  1. порядок взаимодействия сервера с прикладной программой, в котором сервер выступает инициирующей стороной;
  2. механизм реального обмена данными и управляющими командами в этом взаимодействии, что не определено в протоколе 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-программы не имеют взаимосвязей с установлением аутентификации пользователя и проверки его входных данных.

В ответ на ограничения и недостатки спецификации 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’;

будет являться следующая таблица:

Название: Средства доступа к базам данных в Internet и свободно доступная СУБД POSTGRES95
Раздел: Рефераты по информатике, программированию
Тип: реферат Добавлен 22:44:20 28 февраля 2002 Похожие работы
Просмотров: 803 Комментариев: 14 Оценило: 7 человек Средний балл: 4.4 Оценка: 4 Скачать
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 указать имена машин, с которых возможен удаленный доступ прикладным программам, и соответствующие базы данных, к которым разрешается удаленный доступ:


После этого необходимо произвести заново компиляцию системы.

Доступ к базам данных под управлением СУБД POSTGRES95

В СУБД POSTGRES95 реализованы две основные возможности доступа к своим базам данных:

  • через psql — интерфейс командной строки командной оболочки Shell;
  • из прикладной программы, написанной на языке программирования Си (или другом языке) с использованием функций прикладного интерфейса LIBPQ.

Psql — это интерактивный терминальный монитор, позволяющий пользователю формулировать, редактировать и выполнять наборы команд — операторов языка POSTQUEL. Он запускается в режиме командной строки ОС UNIX с указанием имени базы данных:

Пользователь может непосредственно из командной строки монитора вводить одну за другой SQL-команды, а может передавать запрос в виде файла с SQL-операторами через командную строку ОС UNIX:

Интерфейс командной строки 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

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

  1. Ввод новой информации в БД для ведения базы данных.
  2. Генерация отчетов по запросам пользователей.

Структура взаимодействия программного обеспечения информационной системы выглядит следующим образом (рис. 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 выбирайте сами — все они достаточно функциональны и выбор зависит в основном от целей, которые вы преследуете.

Средства доступа к базам данных в Internet и свободно доступная СУБД POSTGRES95 (стр. 2 из 4)

Одно из важных свойств 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.

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. Запросы могут содержать выборку данных в определенное время, в определенном интервале времени. Например, результатом запроса

Postgres95 постреляционная субд postgres95

PostgreSQL — это свободно распространяемая объектно-реляционная система управления базами данных (ORDBMS), наиболее развитая из открытых СУБД в мире и являющаяся реальной альтернативой коммерческим базам данных.

История развития PostgreSQL

Краткую историю PostgreSQL можно прочитать в документации, распространяемой с дистрибутивом или на сайте. Также, есть перевод на русский язык. Из нее следует, что современный проект PostgreSQL ведет происхождение из проекта POSTGRES, который разрабатывался под руководством Майкла Стоунбрейкера (Michael Stonebraker), профессора Калифорнийского университета в Беркли (UCB). Мне захотелось несколько подробнее показать взаимосвязи родословных баз данных, чтобы лучше понять место PostgreSQL среди основных игроков современного рынка баз данных.

Я попытался графически ( большая версия картинки откроется в новом окне) отобразить все наиболее заметные RDBMS и связи между ними и приблизительно привел даты их создания и конца. Пересечение объектов означает поглощение, при этом поглощаемый объект более бледен и не окантован. Знак доллара означает, что база данных является коммерческой. При этом, я основывался на информации, доступной в интернете, в частности в Wikipedia, в научных статьях, которые я читал и комментариях непосредственных пользователей БД, которые я получил после публикации этой картинки в интернете.

Надо сказать, что несмотря на то, что вся история реляционных баз данных насчитывает менее 4 десятков лет, многие факты из истории создания трактуются по-разному, даты не согласуются, а сами участники событий зачастую просто вольно трактуют прошлое.Здесь надо принимать во внимание тот факт, что базы данных — это большой бизнес, в котором развитие одних БД часто связано с концом других. Кроме того, БД в то время были предметом научных исследований, поэтому приоритетность работ является не последним аргументом при написании воспоминаний и интервью. Наверное, учитывая такую запутанность, премия ACM Software System Award #6 была присуждена одновременно двум соперничающим группам исследователей из IBM за работу над «System R» и Беркли — за INGRES, хотя Стоунбрейкер получил награду от ACM SIGMOD (сейчас это премия названа в честь Теда Кодда — автора реляционной теории баз данных) #1 в 1992 г., а Грей (Jim Gray, Microsoft) — #2 в 1993 году.

Итак, как следует из рисунка, видно две ветви развития баз данных — одна следует из «System R», которая разрабатывалась в IBM в начале 70-х, и другая из проекта «INGRES», которым руководил Стоунбрейкер приблизительно в тоже время. Эти два проекта начались как необходимость практического использования реляционной модели баз данных, разработанной Тедом Коддом (Ted Codd) из IBM в 1969,1970 годах. Надо помнить, что в то время имелось две альтернативные модели баз данных — сетевая и иерархическая, причем за ними стояли мощные силы — CODASYL Data Base Task Group (сетевая) и сама IBM с ее базой IMS (Information Management System с иерархической моделью данных). Немного в стороне стоит «Oracle», взлет которой во многом связан с коммерческим талантом Эллисона быть в нужном месте и в нужное время, как сказал Стоунбрейкер в своем интервью, хотя она вместе с IBM сыграла большую роль в создании и продвижении SQL.

«System R» сыграла большую роль в развитии реляционных баз данных, создании языка SQL (изначально SEQUEL, но из-за проблем с уже существующей торговой маркой пришлось выкинуть все гласные буквы). Из «System R» развилась SQL/DS и DB2. На самом деле, в IBM было еще несколько проектов, но они были чисто внутренними. Подробнее об этой ветви можно прочитать в весьма поучительном документе «The 1995 SQL Reunion: People, Projects, and Politics», также доступен русский перевод.

INGRES (или Ingres89), в отличие от «System R», вполне в духе Беркли развивалась как открытая база данных, коды которой распространялись на лентах практически бесплатно (оплачивались почтовые расходы и стоимость ленты). К 1980 году было распространено порядка 1000 копий. Название расшифровывается как «INteractive Graphics (and) REtrieval System» и совершенно случайно связано с французским художником Jean Auguste Dominique Ingres. Отличительной особенностью этой системы являлось то, что она разрабатывалась для операционной системы UNIX, которая работала на распространенных тогда PDP 11, что и предопределило ее популярность, в то время как «System R» работала только на больших и дорогих mainframe. Был разработан язык запросов QUEL, который, как писал Стоунбрейкер, похож на SEQUEL в том отношении, что программист свободен от знания о структуре данных и алгоритмах, что способствует значительной степени независимости от данных. Доступность INGRES и очень либеральная лицензия BSD, а также творческая деятельность, способствовали появлению большого количества реляционных баз данных, как показано на рисунке.

Стоунбрейкер лично способствовал их появлению, так он конце 70-х он организовал компанию Ingres Corporation (как он сам объясняет, ему пришлось на это пойти, так как Аризонский университет, потребовал поддержки), которая выпустила коммерческую версию Ingres, в 1994 году она была куплена CA (Computer Associates) и которая в 2004 году стала открытой как Ingres r3.

«NonStop SQL» компании Tandem Computers являлась модифицированной версией Ingres, которая эффективно работала на параллельных компьютерах и с распределенными данными. Она умела выполнять запросы параллельно и масштабировалась почти линейно с количеством процессоров. Ее авторами были выпускники из Беркли. Впоследствии, Tandem Computers была куплена компанией Compaq (2000 г.), а затем компанией HP.

Компания Sybase тоже была организована человеком из Беркли (Роберт Эпстейн) и на основе Ingres. Известно, что база данных компании Мaйкрософт «SQL Server» — это не что иное как база данных Sybase, которая была лицензирована для Windows NT. С 1993 года пути Sybase и Mirosoft разошлись и уже в 1995 году Sybase переименовывает свою базу данных в ASE (Adaptive Server Enterprise), а Microsoft стала продолжать развивать MS SQL.

Informix тоже возник из Ingres, но на это раз людьми не из Беркли, хотя Стоунбрейкер все-таки поработал в ней CEO после того, как Informix купила в 1995 году компанию Ilustra, чтобы прибавить себе объектно-реляционности и расширяемости (DataBlade), которую организовал все тот же Майкл Стоунбрейкер как результат коммерциализации Postgres в 1992 году. В 2001 году она была куплена IBM, которая приобретала немалое количество пользователей Informix и технологию. Таким образом, DB2 также приобрела немного объектно-реляционности.

Проект Postgres возник как результат осмысления ошибок Ingres и желания преодолеть ограниченность типов данных, за счет возможности определения новых типов данных. Работа над проектом началась в 1985 и в период 1985-1988 было опубликовано несколько статей, описывающих модель данных, язык запросов POSTQUEL, и хранилище Postgres. POSTGRES иногда еще относят к так называемым постреляционным СУБД. Ограниченность реляционной модели всегда являлась предметом критики, хотя все понимали, что это является следствием ее простоты и ее заслугой. Однако, проникновение компьютерных технологий во все сферы жизни требовали новых приложений, а от баз данных — поддержки новых типов данных и возможностей, например, поддержка наследования, создание и управление сложными объектами.

Еще при проектировании оригинальной версии POSTGRES основное внимание было уделено расширяемости и объектно-ориентированным возможностям. Уже тогда было ясна необходимость расширения функциональности DMBS от управления данными (data management) в сторону управления объектами (object management) и знаниями (knowledge management). При этом объектная функциональность позволит эффективно хранить и манипулировать нетрадиционными типами данных, а управление знаниями позволяет хранить и обеспечивать выполнения коллекции правил (rules), которые несут семантику приложения. Стоунбрейкер так и определил основную задачу POSTGRES как «обеспечить поддержку приложений, которые требуют службы управления данными, объектами и знаниями«.

Одним из фундаментальным понятием POSTGRES является class. Class есть именованная коллекция экземпляров (instances) объектов. Каждый экземпляр имеет коллекцию именованных атрибутов и каждый атрибут имеет определенный тип. Классы могут быть трех типов — это основной класс, чьи экземпляры хранятся в базе данных, виртуальный (view), чьи экземпляры материализуются только при запросе (они поддерживаются системой управления правилами), и может быть версией другого (parent) класса.

Первая версия была выпущена в 1989 году, затем последовало еще несколько переписываний системы правил (rule system). Отметим, что коды Ingres и Postgres не имели ничего общего ! В POSTGRES была реализована поддержка таких типов как многомерные массивы, что уже шло в противоречие с реляционной моделью, timetravel — хранение версионности объектов (впоследствии, в версии 6.3 этот тип был удален, так как его поддержка требовала больших усилий, а версионность могла быть реализована на стороне приложения с помощью триггеров). В 1992 году была образована компания Illustra, а сам проект был закрыт в 1993 году выпуcком версии 4.2. Однако, несмотря на официальное закрытие проекта, открытый код и BSD лицензия сподвигли выпускников Беркли Andrew Yu и Jolly Chen в 1994 году взяться за его дальнейшее развитие. В 1995 году они заменили язык запросов POSTQUEL на общепринятый SQL, проект получил название Postgres95, изменилась нумерация версий, был создан веб сайт проекта и появились много новых пользователей (среди которых был и автор).

К 1996 году стало ясно, что название «Postgres95» не выдержит испытанием временем и было выбрано новое имя — «PostgreSQL», которое отражает связь с оригинальным проектом POSTGRES и приобретением SQL. Также, вернули старую нумерацию версий, таким образом новая версия стартовала как 6.0. В 1997 был предложен слон в качестве логотипа, сохранилось письмо в архивах рассылки -hackers за 3 марта 1997 года и последующая дискуссия. Слон был предложен Дэвидом Янгом в честь романа Агаты Кристи «Elephants can remember» (Слоны могут вспоминать). До этого, логотипом был бегущий леопард (ягуар). Проект стал большой и управление на себя взяла небольшая вначале группа инициативных пользователей и разработчиков, которая и получила название PGDG (PostgreSQL Global Development Group). Дальнейшее развитие проекта полностью документировано в документации и отражено в архивах списка рассылки -hackers.

Что есть PostgreSQL сегодня ?

На сегодняшний день выпущена версия PostgreSQL v8 (19 января 2005 года), которая является значительным событием в мире баз данных, так как количество новых возможностей добавленных в этой версии, позволяет говорить о возникновении интереса крупного бизнеса как в использовании, так и его продвижении. Так, крупнейшая компания в мире, Fujitsu поддержала работы над версией 8, выпустила коммерческий модуль Extended Storage Management. Либеральная BSD-лицензия позволяет коммерческим компаниям выпускать свои версии PostgreSQL под своим именем и осуществлять коммерческую поддержку. Например, компания Pervasive объявила о выпуске Pervasive Postgres.

PostgreSQL поддерживается на всех современных Unix системах (34 платформы), включая наиболее распространенные, такие как Linux, FreeBSD, NetBSD, OpenBSD, SunOS, Solaris, DUX, а также под Mac OS X. Начиная с версии 8.X PostgreSQL работает в «native» режиме под MS Windows NT, Win2000, WinXP, Win2003. Известно, что есть успешные попытки работать с PostgreSQL под Novell Netware 6 и OS2.

PostgreSQL используется как полигон для исследований нового типа баз данных, ориентированных на работу с потоками данных — это проект TelegraphCQ, стартовавший в 2002 году в Беркли после успешного проекта Telegraph (название главной улицы в Беркли). Интересно, что компания Streambase, которая была основана Майком Стоунбрейкером в 2003 году (изначально «Grassy Brook») для коммерческого продвижения этого нового поколения баз данных, никаким образом не ассоциируется с проектом Беркли.

Основные возможности и функциональность

create index idx_partial on foo (x) where x > 0;

Функциональные индексы (expressional indices) позволяют создавать индексы используя значения функции от параметра, например,

create index idx_functional on foo ( length(x) );

  • Планировщик запросов основывается на стоимости различных планов, учитывая множество факторов. Он предоставляет возможность пользователю отлаживать запросы и настраивать систему.
  • Система блокировок поддерживает блокировки на нижнем уровне, что позволяет сохранять высокий уровень конкурентности при защите целостности данных. Блокировка поддерживается на уровне таблиц и записей. На нижнем уровне, блокировка для общих ресурсов оптимизирована под конкретную ОС и архитектуру.
  • Управление буферами и кэширование используют сложные алгоритмы для поддержания эффективности использования выделенных ресурсов памяти.
  • Tablespaces (табличные пространства) для управления хранения данных на уровне объектов, таких как базы данных, схемы, таблицы и индексы. Это позволяет гибко использовать дисковое пространство и повышает надежность, производительность, а также способствует масштабируемости системы.
  • Масштабируемость основывается на описанных выше возможностях. Низкая требовательность PostgreSQL к ресурсам и гибкая система блокировок обеспечивают его шкалирование, в то время как индексы и управление буферами обеспечивают хорошую управляемость системы даже при высоких загрузках.
  • Расширяемость PostgreSQL означает, что пользователь может настраивать систему путем определения новых функций, агрегатов, типов,языков, индексов и операторов. Объектно-ориентированность PostgreSQL позволяет перенести логику приложения на уровень базы данных, что сильно упрощает разработку клиентов, так как вся бизнес логика находится в базе данных. Функции в PostgreSQL однозначно определяются названием, количеством и типами аргументов.


    На рисунке приведена ER диаграмма системного каталога PostgreSQL, в котором заложены все сведения об объектах системы, операторах и методах доступа к ним. При инициализации PostgreSQL кластера (команда initdb) создаются две базы данных — template0 и template1, которые содержат предопределенный по умолчанию набор функциональностей. Любая другая база данных наследует template1, таким образом, часто используемые объекты и методы можно добавить в системный каталог template1.

    PostgreSQL предоставляет командный интерфейс для работы с системным каталогом, с помощью которого можно не только получать информацию об объектах системы, но и создавать новые. Например, создавать базы данных с помощью CREATE DATABASE, новый домен — CREATE DOMAIN, оператор — CREATE OPERATOR, тип данных — CREATE TYPE.

    Для создания нового типа данных и индексных методов доступа достаточно:

    • Написать функции ввода/вывода и зарегистрировать их в системном каталоге с помощью CREATE FUNCTION
    • Определить тип в системном каталоге с помощью CREATE TYPE
    • Создать операторы для этого типа данных с помощью CREATE OPERATOR
    • Написать функции сравнения и зарегистрировать их в системном каталоге с помощью CREATE FUNCTION
    • Создать оператор по умолчанию, который будет использоваться для создания индекса по primary keyCREATE OPERATOR CLASS

    Описанный сценарий использует существующих вид индекса. Для создания новых индексов надо использовать GiST.

    Одной из примечательных особенностью PostgreSQL является обобщенное поисковое дерево или GiST (домашняя страница проекта), которое дает возможность специалистам в конкретной области знаний создавать специализированные типы данных и обеспечивает индексный доступ к ним не будучи экспертами в области баз данных. Аналогом GiST является технология DataBlade, которой сейчас владеет IBM (см. историческую справку выше). Идея GiST была придумана профессором Беркли Джозефом Хеллерстейном(Joseph M. Hellerstein) и опубликована в статье Generalized Search Trees for Database Systems. Оригинальная версия GiST была разработана в Беркли как патч к POSTGRES и позднее была инкорпорирована в PostgreSQL. Позже, в 2001 году код был сильно модифицирован для поддержки ключей переменной длины, много-атрибутных индексов и безопасной работы с NULL, также были исправлено несколько ошибок. К настоящему времени написано довольно много интересных расширений на основе GiST, в том числе:

    • модуль полнотекстового поиска tsearch2. С версии 8.3 полнотекстовый поиск будет встроен в ядро PostgreSQL (см. Введение в полнотекстовый поиск).
    • модуль для работы с иерархическими данными (tree-like) ltree
    • модуль для работы с массивами целых чисел intarray

    GiST представляет собой сбалансированное (по высоте) дерево, листья которого содержат пары (key, rid), где key — ключ, а rid — указатель на соответствующую запись на странице данных. Внутренние узлы содержат пары (p,ptr), где p — это некий предикат (используется как поисковый ключ), выполняющийся для всех наследных узлов, а ptr — указатель на другой узел в дереве. Для этого дерева определены базовые методы SEARCH, INSERT, DELETE, и интерфейс для написания 6-ти пользовательских методов, которыми можно управлять работой этих (базовых методов). Метод SEARCH управляется функцией Consistent, возвращающая ‘true’, если узел удовлетворяет предикату, метод INSERT — функциями penalty, picksplit и union, которые позволяют оценить сложность операции вставки в узел, разделить узел при переполнении и перестроить дерево при необходимости, метод DELETE находит лист дерева, содержащий ключ, удаляет пару (key, rid) и, если нужно, с помощью функции union подстраивает родительские узлы. Дополнительные функции compress, decompress используются для оптимизации хранения ключей.

    Дистрибутив PostgreSQL в поддиректории contrib/ содержит большое количество (около 80) так называемых контриб-модулей, реализующих разнообразную дополнительную функциональность, такую как, полнотекстовый поиск, работа с xml, функции математической статистики, поиск с ошибками, криптографические модули и т.д. Также, есть утилиты, облегчающие миграцию с mysql, oracle, для административных работ.

  • Поддержка SQL, кроме основных возможностей, присущих любой SQL базе данных, PostgreSQL поддерживает:
    • Очень высокий уровень соответствия ANSI SQL 92, ANSI SQL 99 и ANSI SQL 2003. Подробнее можно прочитать в документации.
    • Схемы, которые обеспечивают пространство имен на уровне SQL. Схемы содержат таблицы, в них можно определять типы данных, функции и операторы. Используя полное имя объекта можно одновременно работать с несколькими схемами. Схемы позволяют организовать базы данных совокупность нескольких логических частей, каждая их которых имеет свою политику доступа, типы данных. Для приложений, которые создают новые объекты в базе данных удобно и безопасно создавать отдельную схему (и включать ее в SEARCH_PATH) с тем, чтобы избежать возможной коллизии с именами объектов и удобством обновления приложения.
    • Subqueries — подзапросы (subselects), полная поддержка SQL92. Подзапросы делают язык SQL более гибким и зачастую более эффективным.
    • Outer Joins — внешние связки (LEFT,RIGHT, FULL)
    • Rules — правила, согласно которым модифицируется исходный запрос. Главное отличие от триггеров состоит в том, что rule работает на уровне запроса и перед исполнением запроса, а триггер — это реакция системы на изменение данных, т.е. триггер запускается в процессе исполнения запроса для каждой измененной записи (PER ROW). Правила используются для указания системе, какие действия надо произвести при попытке обновления view.
    • Views — представления, виртуальные таблицы. Реальных экземпляров этих таблиц не существуют, они материализуются только при запросе. Одним из основных предназначений ‘view’ является разделение прав доступа к родительским таблицам и к ‘view, а также обеспечение постоянства пользовательского интерфейса при изменении родительских таблиц. Обновление ‘view’ (материализация) возможно в PostgreSQL с помощью pl/pgsql.
    • Cursors — курсоры, позволяют уменьшить трафик между клиентом и сервером, а также память на клиенте, если требуется получить не весь результат запроса, а только его часть.
    • Table Inheritance — наследование таблиц, позволяющее создавать объекты, которые наследуют структуру родительского объекта и добавлять свои специфические атрибуты. При этом наследуются значения атрибутов по умолчанию (DEFAULTS) и ограничение целостности (CONSTRAINTS). Поиск по родительской таблице автоматически включает поиск по дочерним объектам, при этом сохраняется возможность поиска только по ней (only). Наследование можно использовать для работы с очень большими таблицами для эмуляции partitioning.
    • Prepared Statements (преподготовленные запросы) — это объекты, живущие на стороне сервера, которые представляют собой оригинальный запрос после команды PREPARE, который уже прошел стадии разбора запроса (parser), модификации запроса (rewriting rules) и создания плана выполнения запроса (planner), в результате чего, можно использовать команду EXECUTE, которая уже не требует прохождения этих стадий. Для сложных запросов это может быть большим выигрышем.
    • Stored Procedures — серверные (хранимые) процедуры позволяют реализовывать бизнес логику приложения на стороне сервера. Кроме того, они позволяют сильно уменьшить трафик между клиентом и сервером.
    • Savepoints(nested transactions) — в отличие от «плоских транзакций», которые не имеют промежуточных точек фиксации, использование savepoints позволяет отменять работу части транзакции, например вследствии ошибочно введенной команды, без влияния на оставшуюся часть транзакции. Это бывает очень полезно для транзакций, которые работают с большими объемами данных.
    • Права доступа к объектам системы на основе системы привилегий. Владелец объекта или суперюзер может как разрешать доступ (GRANT), так и отменять (REVOKE).
    • Система обмена сообщениями между процессами — LISTEN и NOTIFY позволяют организовывать событийную модель взаимодействия между клиентом и сервером (клиенту передается название события, назначенное командой notify и PID процесса).
    • Триггеры позволяют управлять реакцией системы на изменение данных (INSERT,UPDATE,DELETE), как перед самой операцией (BEFORE), так и после (AFTER). Во время выполнения триггера доступны специальные переменные NEW (запись, которая будет вставлена или обновлена) и OLD (запись перед обновлением).
    • Cluster table — упорядочивание записей таблицы на диске согласно индексу, что иногда за счет уменьшения доступа к диску ускоряет выполнение запроса.
  • Богатый набор типов данных PostgreSQL включает:
    • Символьные типы (character(n)) как определено в стандарте SQL и тип text с практически неограниченной длиной.
    • Numeric тип поддерживает произвольную точность, очень востребованную в научных и финансовых приложениях.
    • Массивы согласно стандарту SQL:2003
    • Большие объекты (Large Objects) позволяют хранить в базе данных бинарные данные размером до 2Gb
    • Геометрические типы (point, line, circle,polygon, box. ) позволяют работать с пространственными данными на плоскости.
    • ГИС (GIS) типы в PostgreSQL являются доказательством расширяемости PostgreSQL и позволяют эффективно работать с трехмерными данными. Подробности можно найти на сайте проекта PostGis.
    • Сетевые типы (Network types) поддерживают типы данных inet для IPV4, IPV6, а также cidr (Classless Internet Domain Routing) блоки и macaddr
    • Композитные типы (composite types) объединяют один или несколько элементарных типов и позволяют пользователям манипулировать со сложными объектами.
    • Временные типы (timestamp, interval, date, time) реализованы с очень большой точностью
    • Псевдотипы serial и bigserial позволяют организовать упорядоченную последовательность целых чисел (AUTO_INCREMENT у некоторых СУБД).
  • PostgreSQL имеет очень богатый набор встроенных функций и операторов для работы с данными, полный список которых можно посмотреть в документации.
  • Поддержка 25 различных наборов символов (charsets), включая ASCII, LATIN, WIN, KOI8 и UNICODE, а также поддержка locale, что позволяет корректно работать с данными на разных языках.
  • Поддержка NLS(Native Language Support) — документация, сообщения об ошибках доступны на различных языках, включая японский, немецкий, итальянский, французский, русский, испанский, португальский, словенский, словацкий и несколько диалектов китайского языков.
  • Интерфейсы в PostgreSQL реализованы для доступа к базе данных из ряда языков (C,C++,C#,python,perl,ruby,php,Lisp и другие) и методов доступа к данным (JDBC, ODBC).
  • Процедурные языки позволяют пользователям разрабатывать свои функции на стороне сервера, тем самым переносить логику приложения на сторону базы данных, используя языки программирования, отличные от встроенных SQL и C. К настоящему времени поддерживаются (включены в стандартный дистрибутив) PL/pgSQL, pl/Tcl, Pl/Perl и pl/Python. Кроме них, существует поддержка PHP, Java, Ruby, R, shell.
  • Простота использования всегда являлась важным фактором для разработчиков.

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

    phpPgAdmin (лицензия GPL) представляет возможность с помощью веб браузера администрировать PostgreSQL кластер.

    pgAdmin III (GNU Artistic license) предоставляет удобный интерфейс для работы с базами данных PostgreSQL и работает под Linux, FreeBSD и Windows 2000/XP.

    PgEdit — программная среда для разработки приложений и SQL-редактор, доступна для Windows и Mac.

  • Безопасность данных также является важнейшим аспектом любой СУБД. В PostgreSQL она обеспечивается 4-мя уровнями безопасности:
    • PostgreSQL нельзя запустить под привилегированным пользователем — системный контекст
    • SSL,SSH шифрование трафика между клиентом и сервером — сетевой контекст
    • сложная система аутентификации на уровне хоста или IP адреса/подсети. Система аутентификации поддерживает пароли, шифрованные пароли, Kerberos, >
      Название Значение Максимальный размер БД Unlimited Максимальный размер таблицы 32 TB Максимальная длина записи 1.6 TB Максимальная длина записи 400Gb Максимальный длина атрибута 1 GB Максимальное количество записей в таблице Unlimited Максимальное количество атрибутов в таблице 250 — 1600 в зависимости от типа атрибута Максимальное количество индексов на таблицу Unlimited

    Сводная таблица основных реляционных баз данных

    За основу взяты данные из Wikipedia

    4

    Название ASE DB2 FireBird InterBase MS SQL MySQL Oracle PostgreSQL
    Лицензия $$$ $$$ IPL 2 $$$ $$$ GPL/$$$ $$$ BSD
    ACID Yes Yes Yes Yes Yes Depends 1 Yes Yes
    Referential integrity Yes Yes Yes Yes Yes Depends 1 Yes Yes
    Transaction Yes Yes Yes Yes Yes Depends 1 Yes Yes
    Unicode Yes Yes Yes Yes Yes Yes Yes Yes
    Schema Yes Yes Yes Yes No 5 No Yes Yes
    Temporary table No Yes No Yes Yes Yes Yes Yes
    View Yes Yes Yes Yes Yes No Yes Yes
    Materialized view No Yes No No No No Yes No 3
    Expression index No No No No No No Yes Yes
    Partial index No No No No No No Yes Yes
    Inverted index No No No No No Yes Yes Yes 6
    Bitmap index No Yes No No No No Yes No
    Domain No No Yes Yes No No Yes Yes
    Cursor Yes Yes Yes Yes Yes No Yes Yes
    User Defined Functions Yes Yes Yes Yes Yes No 4 Yes Yes
    Trigger Yes Yes Yes Yes Yes No 4 Yes Yes
    Stored procedure Yes Yes Yes Yes Yes No 4 Yes Yes
    Yes No
    Tablespace Yes Yes No ? No 5 No 1 Yes Yes
    Название ASE DB2 FireBird InterBase MS SQL MySQL Oracle PostgreSQL

    Замечания:

    • 1 — для поддержки транзакций и ссылочной целостности требуется InnoDB (не является типом таблицы по умолчанию)
    • 2 — Interbase Public License
    • 3 — Materialized view (обновляемые представления) могут быть эмулированы на PL/pgSQL
    • 4 — только в MySQL 5.0, которая является экспериментальной версией
    • 5 — только в MS SQL Server 2005 (Yukon)
    • 6 — GIN (Generalized Inverted Index) с версии 8.2

    Что ожидается в будущих версиях

    Вышла версия 8.0.2, в которой, помимо исправления ошибок и изменения версии библиотеки libpq (ВНИМАНИЕ ! Все клиентские приложения, которые используют libpq, требуется пересобрать, например DBD::Pg), алгоритм кэширования страниц «ARC», которым владеет IBM, был заменен на другой, «патентно-чистый» алгоритм «2Q».

    Поскольку история с заменой алгоритма «ARC» в PostgreSQL вызвала большой интерес и обсуждение в сети (а она связана с очень «горячей» темой выдачи и использования патентов на программное обеспечение), я остановлюсь подробнее на описании механизма кэширования (buffer management) в PostgreSQL. Я использовал архив обсуждений, оригинальные работы и статью Элейн Мустэйн (A. Elein Mustain) The Saga of the ARC Algorithm and Patent.

    Управление буферами в PostgreSQL

    Кэширование страниц, или сохранение прочитанных с диска страниц в памяти, очень важно для эффективной работы любой СУБД, так как времена доступа к диску и памяти отличаются на многие порядки. В идеале, мы хотим, чтобы все страницы, к которым происходит обращение, попадали в память, с тем, чтобы последующее ее использование не требовало обращения к диску. Однако, так как количество доступной памяти ограниченно, то возникает ситуация, когда требуется принимать решение, какую страницу надо освободить (заместить) для того, чтобы поместить в кэш новую страницу. Практически все коммерческие системы используют ту или иную вариацию LRU (Least Recently Used) алгоритма, в котором высвобождается та страница, к которой дольше всего не обращались. В чистом виде этот алгоритм не очень хорош для использования в СУБД в силу большой разнообразности последовательности запросов, например, не учитывает частоту обращения к странице, не защищен от «cache flooding», когда всего одно единичное последовательное чтение большого количества страниц (sequential scan) может заполнить кэш страницами, к которым может не быть больше обращения, т.е., к полной потере эффективности кэширования. Иногда, используют термин «scan-resistant», когда говорят, что хороший алгоритм должет быть устойчив по отношению к «cache flooding».

    PostgreSQL использовал разновидность этого алгоритма, известную как LRU/K, реализованную Томом Лайном (Tom Lane). В этом алгоритме используется история K-последних обращений к странице (именно последних, что позволяет этому алгоритму адаптироваться к изменениям шаблона запросов, в отличие от LFU алгоритма), которая позволяет отличить популярные страницы от давно не используемых. Для этого строится упорядоченная очередь (priority queue) указателей на страницы в кэше на основе времени обращения к странице по правилу: если у страницы P1 K-тое обращение (предпоследнее, для наиболее важного случая K=2, LRU/2 ) является более свежим чем у P2, то P1 будет замещено после P2. Классический LRU алгоритм можно рассматривать как LRU/1, так как он использовал информацию только об одном (последнем) обращении к странице. Важным является не то, что произошло единичное обращение к странице, а то, насколько эта страница была популярна в течение некоторого времени. Однако, этот алгоритм требовал нетривиальной настройки и время на построение очереди растет логарифмически в зависимости от размера буфера.

    ARC (Adaptive Replacement Cache) алгоритм был привлекателен тем, что он учитывал не только как часто страница была использована, но и насколько недавно это происходило и не сильно «нагружал» процессор, как это происходило с LRU/K алгоритмом. Он динамически поддерживает баланс между часто используемыми и недавно используемыми страницами. Этот алгоритм был реализован Яном Виком (Jan Wieck) для версии 7.5 (впоследствии 8.0), который впоследствии был несколько улучшен после статьи, описывающей CAR (Clock with Adaptive Replacement) алгоритм. Однако, незадолго (за два дня) до выхода PostgreSQL 8.0 было обнаружено (см. постинг Нейла Конвея (Neil Conway) и последующее обсуждение), что IBM подала заявку на алгоритм ARC еще в 2002 году. Так как было уже поздно что-либо менять было решено выпустить 8.0 версию как есть, а потом заняться решением проблемы. Несмотря на то, что IBM еще не получила патент на ARC алгоритм и то, что IBM имеет хорошую практику поддержки OSS проектов, и можно было надеяться на получения официального разрешения на его использование в PostgreSQL, как предлагали многие, было решено исследовать вопрос о действительном нарушение патента и выяснить возможность замены ARC алгоритма на «патентно-чистый» алгоритм.

    Основным аргументов в пользу замены алгоритма было желание сохранить PostgreSQL доступным для «любого использования» согласно BSD лицензии, которая позволяет коммерческое использование PostgreSQL без каких-либо лицензионных отчислений. В начале февраля 2005 года Том Лэйн предложил измененную версию ARC алгоритма, близкую к 2Q и опубликованную в 1994 году задолго до ARC, и которая решала проблему «cache flooding» («scan resistant») и не требовала больших изменений в коде (в основном удаление кода), которая и была реализована в версии 8.0.2. 2Q алгоритм (Two Queue) почти также эффективен как LRU/K, но проще, не требует настройки и быстрее. Он добивается этого тем, что хранит в основном буфере только «горячие» страницы, а не занимается очищением «холодных» страниц в основном буфере как LRU/2. Упрощенно алгоритм выглядит так: при первом обращении указатель на страницу помещается в очередь A1 (FIFO), и если во время второго обращения страница еще находилась в A1, то страница называется горячей и помещается в основной буфер, который уже контролируется как LRU очередь. Если к странице не обращались пока она была в A1, то страница, вероятно, «холодная» и 2Q алгоритм удаляет ее из буфера.

    PGDG — PostgreSQL Global Development Group

    PostgreSQL развивается силами международной группы разработчиков (PGDG), в которую входят как непосредственно программисты, так и те, кто отвечают за продвижение PostgreSQL (Public Relation), за поддержание серверов и сервисов, написание и перевод документации, всего на 2005 год насчитывается около 200 человек. Другими словами, PGDG — это сложившийся коллектив, который полностью самодостаточен и устойчив. Проект развивается по общепринятой среди открытых проектов схеме, когда приоритеты определяются реальными нуждами и возможностями. При этом, практикуется публичное обсуждение всех вопросов в списке рассылке, что практически исключает возможность неправильных и несогласованных решений.

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

    Цикл разработки

    Цикл работой над новой версией обычно длится 10-12 месяцев (сейчас ведется дискуссия о более коротком цикле 2-3 месяца) и состоит из нескольких этапов (упрощенная версия):

    • Обсуждение предложений в списке -hackers. На собственном опыте могу заверить, что это очень непростой процесс и плохо подготовленный proposal не пройдет. Учитываются много факторов — алгоритмы, структуры данных, совместимость с существующей архитектурой, совместимость с SQL и так далее.
    • После принятия решения о работе над новой версией в CVS открывается новая ветка и с этого момента все изменения, касающиеся новых возможностей, вносятся туда. Также, анализируются патчи, которые присылаются в список -patches. Все изменения протоколируются и доступны любому для рассмотрения (anonymous CVS, -commiters лист рассылки или через веб-интерфейс к CVS). Иногда, в процессе работы над новой версией вскрываются или исправляются старые ошибки, в этом случае, наиболее критические исправляются и в предыдущих версиях (backporting). По мере накопления таких исправлений принимается решение о выпуске новой стабильной версии, которая совместима со старой и не требует обновления хранилища. Например, 7.4.7 — является bugfix-ом стабильной версии 7.4.
    • В некоторый момент объявляется этап code freeze(замораживания кода), после которого в CVS не допускается новая функциональность, а только исправление или улучшение кода. Граница между новой функциональностью и улучшением кода не описана и иногда возникают разногласия на этот счет, к документации и расширениям (contribution modules в поддиректории contrib/) обычно относятся более либерально. Замечу, что все это время все CVS версия проходит непрерывное тестирование на большом количестве машин, под разными архитектурами, операционными системами и компиляторами. Все это стало возможно благодаря проекту pgbuildfarm, который является распределенной системой тестирования, объединяющая добровольцев, которые предоставляют свои машины для тестирования. Проверяется не только корректность сборки, но и, благодаря обширному набору тестов (regression test), и правильность работы. Текущий статус (всех поддерживаемых версий, не только CVS) можно посмотреть на этой странице. Исходные тексты CVS версии PostgreSQL проходят тестирование в OSDL что помогает в обнаружении систематических изменений производительности (в обе стороны), иногда такие обнаружения приводят к необходимости «размораживания кода». Начиная с версии 8 такие тестирования будут регулярно проводиться в OSDL STP и PLM (STP — Scalable Test Platform и PLM — Patch Lifecycle Manager).
    • После внутреннего тестирования «собирается» дистрибутив и объявляется выход бета версии, на тестирование и исправление ошибок отводится 1-3 месяца. Бета версия не рекомендуется для использования в продакшн проектах (production), но практика показала хорошее качество таких версий и многие начинают ее использовать ради апробирования новой функциональности. Как правило, окончательная версия совместима с бета-версией и не требует обновления хранилища. По мере исправления замеченных ошибок выпускаются новые бета-версии.
    • После исправления всех замеченных ошибок, выпускается релиз-кандидат, который уже практически ничем не отличается от окончательной версии, разве что не хватает документации и списка изменений.
    • В течении месяца выходит окончательная версия, которая анонсируется на главном веб-сайте проекта и его зеркалах, мэйлинг листах. Также, PR группа, которая к этому моменту подготовила анонсы на разных языках, распространяет их по всем ведущим сайтам и СМИ. Они принимают участие в конференциях, семинарах и прочих общественных мероприятиях.

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

    Структура

    • Управляющий комитет (6 человек).
      Принимает решение о планах развития и выпусках новых версий.
    • Заслуженные разработчики ( 2 человека ).
      Бывшие члены управляющего комитета, которые отошли от участия в проекте.
    • Основные разработчики (23).
    • Разработчики (22)

    Кроме PGDG, значительное участие в развитии PostgreSQL принимает некоммерческая организация «The PostgreSQL Foundation», созданная для продвижения и поддержки PostgreSQL. Сайт фонда находится по адресу www.thepostgresqlfoundation.org.

    Спонсорская помощь на развитие PostgreSQL поступает как от частных лиц, так и от коммерческих компаний, которые:

    • принимают на работу членов PGDG
    • оплачивают разработку каких-либо новых возможностей
    • предоставляют услуги в виде хостинга или оплаты трафика
    • поддерживают публичные мероприятия PGDG
    • выделяют своих программистов на участие в разработке

    Кроме того, некоторые разработки поддерживаются государственными фондами, например, Российский Фонд Фундаментальных Исследований.

    Где используется


    Сообщество


    Поддержка

    • Основной источник актуальной информации о PostgreSQL является его официальный сайтwww.postgresql.org, который имеет зеркала по всему миру. На нем публикуются сведения о всех событиях (анонсы релизов, семинаров, конференций), поддерживается список ресурсов, относящихся к PostgreSQL.
    • Основная поддержка осуществляется через почтовую рассылку, архивы которой доступны через Web по адресам:
      • archives.postgresql.org
        Архив pgsql-ru-general — русскоязычного списка рассылки,как подписаться.
      • www.pgsql.ru/db/mw

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

      Небольшая статистика списков рассылок PostgreSQL по данным www.pgsql.ru на 1 апреля 2005 года.

      Первая 20-ка мэйлинг листов
      по количеству постингов
      Распределение постингов по годам
    • Поисковая системаPGsearch (разработана при поддержке РФФИ и Дельта-Софт) предоставляет поиск по сайтам сообщества. На момент написания этой статьи проиндексировано 480000 страниц из 67 сайтов, индекс обновляется еженедельно.
    • Много полезной информации по PostgreSQL можно найти на сайтах
      • techdocs.postgresql.org
      • Varlena
      • Powerpostgresql
      • PGnotes
    • Документация на русском (переводы и оригинальные статьи) доступны на сайте русскоязычного сообщества http://www.linuxshare.ru/postgresql/.
    • Ответы на ваши вопросы можно найти в «PostgreSQL FAQ « (часто задаваемые вопросы):
      • Оригинальная версия
      • на русском языке
    • Дистрибутивы PostgreSQL доступны для скачивания с основного ftp-сервера проекта и его зеркал. Подробная информация доступна со страницы http://www.postgresql.org/download/. Кроме того, многие дистрибутивы Linux распространяются с бинарной версией PostgreSQL и обеспечивают поддержку обновлений. Для ознакомления с PostgreSQL можно скачать образ загрузочного CD (Live CD) — bittorent формат или в ISO формате. Информацию о том, как инсталлировать PostgreSQL под Mac OS X можно найти здесь. Инсталлятор для Win32 можно скачать с сайта проекта Pginstaller.
    • Коммерческая поддержка осуществляется рядом компаний, список которых доступен по адресу www.postgresql.org/support/. Также на российском сайте ведется список российских компаний, которые заявили о поддержке PostgreSQL.

    Разработка


    Заключение



    Благодарности

    Текст написан Олегом Бартуновым в 2005 году, поправки и комментарии приветствуются.

    Будь умным!

    Работа добавлена на сайт samzan.ru: 2020-06-09

    Заказать написание уникльной работы

    Средства доступа к базам данных в Internet и свободно доступная СУБД POSTGRES95

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

    • ;font-family:’Times New Roman’;text-decoration:underline» xml:lang=»ru-RU» lang=»ru-RU»>CGI ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>
    • ;font-family:’Times New Roman’;text-decoration:underline» xml:lang=»ru-RU» lang=»ru-RU»>API ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>
    • ;font-family:’Times New Roman’;text-decoration:underline» xml:lang=»ru-RU» lang=»ru-RU»>FastCGI ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>

    Common Gateway Interface — это спецификация интерфейса взаимодействия Web-сервера с внешними прикладными программами. Главное назначение CGI — обеспечение единообразного потока данных между сервером и работающим на нем приложением. CGI определяет:

    1. ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>порядок взаимодействия сервера с прикладной программой, в котором сервер выступает инициирующей стороной;
    2. ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>механизм реального обмена данными и управляющими командами в этом взаимодействии, что не определено в протоколе 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 для обмена данными с внешними прикладными программами можно выделить следующие преимущества:

    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>Прозрачность использования;
    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>»Языковая» независимость — CGI-программы могут быть написаны на любом языке программирования или командном языке, имеющим средства работы со строками;
    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>Процессная изолированность — при запуске CGI-програмы на сервере порождается отдельный процесс и ошибочный CGI-скрипт не может сломать Web-сервер или получить доступ к закрытой информации;
    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>Открытость стандарта — CGI интерфейс применим на каждом Web-сервере;
    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>Архитектурная независимость — CGI не зависит от особенностей реализации архитектуры сервера (однопоточности, многопоточности и т.д. ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>);

    Но CGI имеет также и существенные недостатки. Главная проблема заключается в затратах на выполнение CGI-приложений: поскольку на сервере для каждого очередного запроса порождается новый процесс, который завершается после его выполнения, то это приводит к невысокому быстродействию CGI-скрипта и снижает эффективность работы сервера. При использовании CGI-программ для доступа к базам данных из-за неподдержки непрерывного соединения Web-сервера и соответствующей СУБД очень сложно произвести процесс «ведения» пользователя базой данных, так как каждый раз при генерации очередного запроса требуется новое подключение. Но в то же время закрытие соединения после обработки каждого запроса сильно осложняет деятельность хакеров, так как при отсутствии постоянного подключения к БД проникнуть в нее гораздо сложнее. Другое достоинство этого «недостатка» состоит в том, что связь с Web-сервером устанавливается только на короткий промежуток времени, в результате чего он не перегружается и может выполнять другие задачи.

    CGI `также ограничен по способности функционирования — спецификация предусматривает только простую «ответную» роль скрипта при генерации результата на запрос пользователя. CGI-программы не имеют взаимосвязей с установлением аутентификации пользователя и проверки его входных данных.

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

    Тем не менее спецификация API не имеет преимуществ CGI-интерфейса и поставщики API-модулей тоже сталкиваются с целым рядом проблем:

    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>»Языковая» зависимость — прикладные программы могут быть написаны только на языках, поддерживаемых в данном API (обычно это С/C++); Perl, наиболее популярный язык для CGI-скриптов, как правило, не используется в существующих поставляемых API-модулях.
    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>Неизолированность процесса — так как приложения выполняются в адресном пространстве сервера, то ошибочные программы могут «уронить» сервер или какое-либо приложение. Таким образом вполне возможно (намеренно или нет) сломать систему безопасности сервера.
    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>Ограниченность применения — написанные программы в соответствии с данным API могут использоваться только на данном сервере.
    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>Архитектурная зависимость — API-приложения зависимы от архитектуры сервера: если сервер поддерживает однопоточность, то многопотоковые приложения не получают никакого преимущества в быстродействии при выполнении. Также при изменении производителем архитектуры сервера, модуль API обычно тоже подвергается изменениям, и прикладные программы соответственно тоже требуют переделки или даже могут быть написаны заново.

    FastCGI Интерфейс FastCGI сочетает в себе наилучшие аспекты спецификаций CGI и API. Взаимодействие в соответствии с FastCGI происходит сходным образом с CGI. FastCGI-приложения запускаются отдельными изолированными процессами. Отличие состоит в том, что эти процессы являются постоянно работающими и после выполнения запроса не завершаются, а ожидают новых запросов. Вместо использования переменных окружения операционной системы и стандартных потоков ввода/вывода протокол FastCGI объединяет информацию среды, стандартный ввод, вывод и сообщения об ошибках в единственное дуплексное соединение. Это позволяет FastCGI-программам выполняться на удаленных машинах, используя TCP-соединения между Web-сервером и FasstCGI-модулем.

    Таким образом, преимущества FastCGI состоят в следующем:

    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>Быстродействие — благодаря постоянному функционированию FsatCGI-процессов обеспечивается обслуживание одним процессом многих запросов, что решает задачу и связанные с ней проблемы порождения нового процесса на отдельный клиентский запрос. ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>
    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>Простота применения и легкость миграции из CGI.
    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>»Языковая» независимость — как и CGI, FastCGI-приложения могут быть написаны на любых языках программирования или командных языках.
    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>Изолированность процессов — «неисправные» FastCGI-программы не могут разрушить ядро сервера или какие-либо другие приложения, а также получить секретную служебную информацию.
    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>Совместимость — FastCGI поддерживается во всех открытых продуктах, включая коммерческие серверы Netscape и Microsoft, NCSA сервер и свободно распространяемый Apache.
    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>Архитектурная независимость — FastCGI интерфейс не зависит от особенностей реализации серверной архитектуры и прикладные программы могут быть как одно-, так и многопоточными.
    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>Распределенность — 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. Запросы могут содержать выборку данных в определенное время, в определенном интервале времени. Например, результатом запроса

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»> SELECT city, population FROM cities[‘epoch’,’now’] WHERE city=’Moscow’;

    будет являться следующая таблица:

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>city

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>population

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>Moscow

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>7 360 000

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>Moscow

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>8 950 000

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

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

    Одним из основных положений реляционной модели данных является требование нормализации отношений: поля кортежей могут содержать лишь атомарные значения. Приведение исходного табличного представления предметной области к первой нормальной форме является основным шагом в процессе проектирования реляционной базы данных. В СУБД POSTGRES95 реализована «ненормализованная» реляционная модель данных, которая допускает хранение в качестве элемента кортежа многомерных массивов фиксированной и переменной длины, и других данных, в том числе абстрактных, определенных пользователями типов:

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»> 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 основана на модели «клиент-сервер». Сессия с СУБД состоит из следующих взаимодействующих процессов:

    • ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>postmaster ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»> — управляющий процесс-демон, который руководит взаимодействием между внешними и внутренними процессами; он выделяет совместно используемый буффер динамической памяти и выполняет другие инициализации во время запуска.
    • ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>postgres ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»> — внутренний серверный процесс базы данных, исполняющий запросы клиента. Postmaster всегда запускает новый postgres-процесс для каждого клиентского приложения. Этот серверный процесс выполняется на машине сервера.
    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>внешняя прикладная программа, которая может находиться на другом компьюторе (например, рабочей станции). Она соединяется с postgres через postmaster.

    Один раз запущенный процесс-демон postmaster управляет установленным набором баз данных на серевере. Внешняя прикладная программа, желающая получить доступ к одной из этих баз данных, вызывает библиотеку функций прикладного программного интерфейса LIBPQ (рис.4). С помощью этих функций запрос по сети передается postmaster’у, который порождает серверный процесс и соединяет внешнюю программу с сервером. С этого момента клиентские и серверные процессы взаимодействуют без помощи postmaster’a. Таким образом, postmaster постоянно работает, ожидая запросов, в то время, как происходят и завершаются соединения с внешними приложениями. Прикладной программный интерфейс LIBPQ позволяет одной клиентской программе совершать во время одной сессии множественные соединения с сервером БД. Но тем не менее, внешняя программа — это однопотоковый процесс. Многопоточность процессов библиотекой LIBPQ не поддерживается. Другой особенностью архитектуры СУБД POSTGRES95 является то, что postmaster и postgres серверные процессы всегда выполняются на одной и той же машине — сервере базы данных, тогда как внешние программы могут находиться на любых машинах сети.

    Рис. 4. Схема взаимодействия процессов POSTGRES95

    Таким образом, СУБД POSTGRES95 позволяет осуществлять доступ клиентским прикладным программам к своим базам данных не только в локальном, но и удаленном режиме. Но система безопасности СУБД не предоставляет эту возможность всем пользователям. Для разрешения удаленного соединения с базами данных необходимо установить режим аутентификации для данного пользователя. По умолчанию в файле конфигурации этот режим отключен, и доступ разрешен только программам, расположенным в директории на машине сервера БД. Для установления аутентификации необходимо в файле pq_hba указать имена машин, с которых возможен удаленный доступ прикладным программам, и соответствующие базы данных, к которым разрешается удаленный доступ:

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>#

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»> all 127.0.0.1 0.0.0.0

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»> all 194.85.135.66 0.0.0.0

    После этого необходимо произвести заново компиляцию системы.

    Доступ к базам данных под управлением СУБД POSTGRES95


    В СУБД POSTGRES95 реализованы две основные возможности доступа к своим базам данных:

    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>через psql — интерфейс командной строки командной оболочки Shell;
    • ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>из прикладной программы, написанной на языке программирования Си (или другом языке) с использованием функций прикладного интерфейса LIBPQ.

    P sql — это интерактивный терминальный монитор, позволяющий пользователю формулировать, редактировать и выполнять наборы команд — операторов языка POSTQUEL. Он запускается в режиме командной строки ОС UNIX с указанием имени базы данных:

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»> % psql polyn

    Пользователь может непосредственно из командной строки монитора вводить одну за другой SQL-команды, а может передавать запрос в виде файла с SQL-операторами через командную строку ОС UNIX:

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»> % psql <>

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

    LIBPQ — прикладной программный интерфейс POSTGRES95. Он представлен набором библиотечных функций (подпрограмм), которые позволяют клиентским программам посылать запросы серверу СУБД и получать от него соответствующие результаты. Для этого в прикладную программу включают главный файл библиотеки libpq-fe.h , встраивают функции LIBPQ и производят компиляцию кода программы с библиотеками POSTGRES95. Схема доступа к базам данных из внешних программ достаточно простая. С помощью специальной функции PQsetdb устанавливается TCP-соединение по определенному порту (как правило, — 5432) прикладной программы с процессом-демоном postmaster’ом. При этом функции передаются параметры значений имени базы данных, IP-адреса сервера, порта соединения. Далее при успешном соединении происходит выполнение в рамках функции PQexec SQL-операторов языка запросов POSTQUEL — открытие транзакции с базой данных, выполнение запроса и закрытие транзакции. После этого происходит завешение соединения с базой данных. При выполнении запроса по выбору данных из БД POSTGRES95 создает временную таблицу, в которую помещает полученный результат. Используя SQL-операторы, связанные с курсорами, и специальные функции LIBPQ по работе с кортежами, полями отношений, достаточно просто осуществляется доступ к элементам результирующей таблицы, что приводит к генерации произвольных отчетов по запросам пользователей. Ниже приведен фрагмент Cи-программы, реализующей запрос к базе данных «polyn»:

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>pghost= «ns.polyn.kiae.su»

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>pgport= «5432»;

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>pgoptions=NULL;

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>pgtty=NULL;

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>dbname= «polyn»

    ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>/*установка соединения с базой данных */

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>conn = PQsetdb(pghost, pgport, pgoptions, pgtty, dbname);

    ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>/* проверка статуса выполнения соединения */

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>if (PQstatus(conn)== CONNECTION_BAD)

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»> printf(«%s», PQerrorMessage(conn));

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»> PQfinish(conn);

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»> exit(1);

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>>

    ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>/* начало транзакции с БД*/

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>res=PQexec(conn,»BEGIN»);

    ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>/* проверка статуса выполнения функции */

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>if (PQresultStatus(res)!=PGRES_COMMAND_OK)

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»> PQclear(res);

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»> PQfinish(conn);

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»> exit(1); >

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>PQclear(res);

    ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>/* выполнение SQL-опреатора установки курсора на результат запроса выбора поля isotop из отношения isotop */

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>res=PQexec(conn,»DECLARE myportal CURSOR FOR select isotop.isotop from isotop «);

    ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>/* выполнение оператора чтения по курсору */

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>res=PQexec(conn,»FETCH ALL in myportal»);

    ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>/* определение количества кортежей и атрибутов в результирующей таблице */

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>ntups = PQntuples(res);

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>nflds = PQnfields(res);

    ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>/* вывод имен атрибутов */

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>for (i=0; i

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>%s

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>»,PQfname(res,i));

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>>

    ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>/* вывод элементов результирующего отношения */

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>for(i=0; i%s\n»,PQgetvalue(res,i,j));

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»> >

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>>

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>PQclear(res);

    ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>/* закрытие курсора */

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>res=PQexec(conn,»CLOSE myportal»);

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>PQclear(res);

    ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>/* закрытие транзакции */

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>res=PQexec(conn,»END»);

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>PQclear(res);

    ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>/* закрытие соединения*/

    ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>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. Создание информационной системы было направлено на выполнение следующих задач:

    1. ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>Ввод новой информации в БД для ведения базы данных.
    2. ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>Генерация отчетов по запросам пользователей.

    Структура взаимодействия программного обеспечения информационной системы выглядит следующим образом (рис. 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 выбирайте сами — все они достаточно функциональны и выбор зависит в основном от целей, которые вы преследуете.

    1. ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>С.Д. Кузнецов. ;font-family:’Times New Roman Cyr’;text-decoration:underline» xml:lang=»ru-RU» lang=»ru-RU»>Введение в СУБД ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>. «СУБД» 2-3,1996г.
    2. ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>С.Д.Кузнецов. ;font-family:’Times New Roman Cyr’;text-decoration:underline» xml:lang=»ru-RU» lang=»ru-RU»>Доступ к базам данных с использованием технологии WWW ;font-family:’Times New Roman Cyr'» xml:lang=»ru-RU» lang=»ru-RU»>. «СУБД» 5-6, 1996 г.
    3. ;font-family:’Times New Roman’;text-decoration:underline» xml:lang=»ru-RU» lang=»ru-RU»>http://oozoo.vnet.net/postgres95/ ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>
    4. ;font-family:’Times New Roman’;text-decoration:underline» xml:lang=»ru-RU» lang=»ru-RU»>http://www.fastcgi.com ;font-family:’Times New Roman'» xml:lang=»ru-RU» lang=»ru-RU»>

    Заказать написание уникльной работы

    Материалы собраны группой SamZan и находятся в свободном доступе

    Что такое PostgreSQL? Плюсы и минусы бесплатной базы данных

    Пришло время рассказать о том, что же такое PostgreSQL. Это СУБД, которая использует реляционную модель для своих баз данных и поддерживает стандартный язык запросов SQL.

    PostgreSQL предоставляет множество различных возможностей, достаточно надежна и имеет хорошие характеристики по производительности. Она работает практически на всех UNIX-платформах, включая UNIX-подобные системы, такие как FreeBSD и Linux. Ее можно применять на Windows NT Server и Windows 2000 Server, а для разработки годятся даже такие системы Microsoft для рабочих станций, как ME. Кроме того, PostgreSQL свободно распространяется и имеет открытый исходный код.

    PostgreSQL выгодно отличается от многих других СУБД. Она обладает практически всеми возможностями, которые есть в других базах данных (коммерческих или Open Source), а также некоторыми дополнительными.

    Приведем перечень функциональных возможностей PostgreSQL (представлен в ответах на часто задаваемые вопросы по PostgreSQL):

    • Транзакции
    • Вложенные запросы
    • Представления
    • Ссылочная целостность — внешние ключи
    • Сложные блокировки
    • Типы, определяемые пользователем
    • Наследственность
    • Правила
    • Проверка совместимости версий

    Начиная с версии 6.5 PostgreSQL представляет собой весьма устойчивую систему, каждая следующая версия проходит процедуру регрессивного тестирования, обеспечивающего стабильность. Версия 7.x PostgreSQL как никогда близка к соответствию стандарту SQL92, устранено раздражавшее ограничение размера строки.


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

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

    Короткий экскурс в историю PostgreSQL

    Генеалогическое древо PostgreSQL начинается в 1977 году в Калифорнийском университете Беркли. Реляционная база данных Ingres разрабатывалась в Беркли в 1977-85 годах. Ingres была очень популярна за пределами стен Калифорнийского университета, она появилась на многих компьютерах в университетских и исследовательских кругах. На свободный рынок Ingres была выведена Relational Technologies/Ingres Corporation, так она стала одной из первых коммерчески доступных реляционных систем управления базами данных. В наши дни Ingres превратилась в CA-INGRES II, продукт Computer Associates.

    Тем временем в Беркли не прекращается работа над сервером реляционной базы данных (под названием Postgres), это продолжается с 1986 по 1994 год. Как и раньше, код приобретается коммерческой компанией и продукт на его основе выставляется на продажу. После поглощения компанией Informix он стал называться Illustra. Где-то в 1994 году в Postgres были добавлены возможности SQL, и возникло новое имя — Postgres95.

    К 1996 году Postgres стала приобретать необыкновенную популярность, и было принято решение открыть ее код для некоторого количества программистов по списку рассылки, так началось весьма успешное сотрудничество добровольцев, направленное на продвижение Postgres. Тогда продукт в последний раз сменил имя, отбросив окончание «95» и заменив его на «SQL», которое лучше отражало поддержку стандартного языка запросов SQL в Postgres. Так родилась PostgreSQL.

    Сейчас PostgreSQL развивается группой интернет-разработчиков, приблизительно тем же способом, что и другое программное обеспечение Open Source: Perl, Apache и PHP. Пользователи имеют доступ к исходным кодам, они исправляют ошибки, занимаются совершенствованием продукта, предлагают введение новых возможностей. Официальные версии PostgreSQL выпускаются на http://www.postgresql.org.

    GreatBridge осуществляет коммерческую поддержку проекта, а также предоставляет работу некоторым PostgreSQL-разработчикам.

    Архитектура PostgreSQL

    Одной из сильных сторон PostgreSQL является ее архитектура. Как и многие коммерческие СУБД, PostgreSQL может применяться в среде клиент-сервер, что дает массу преимуществ как пользователям, так и разработчикам.

    Основа PostgreSQL составляет серверный процесс базы данных. Он выполняется на одном сервере. (В этой СУБД еще не реализована технология высокой готовности, как в некоторых других коммерческих системах уровня предприятия, которые могут распределять нагрузку между несколькими серверами, добиваясь таким образом дополнительной масштабируемости и устойчивости к внешним воздействиям.)

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

    Такое разделение клиентов и сервера позволяет построить распределенную систему. Можно отделить клиентов от сервера посредством сети и разрабатывать клиентские приложения в среде, удобной для пользователя. Например, можно реализовать базу данных под UNIX и создать клиентские приложения, которые будут работать в системе Microsoft Windows.

    Приведенная ниже схема (рис. 1) показывает типичную модель распределенного приложения PostgreSQL:

    Рис. 1. Работа типичного приложения PostgreSQL

    Несколько клиентов подсоединяются к серверу по сети. PostgreSQL ориентирован на протокол TCP/IP — это может быть локальная сеть или Интернет. Каждый клиент соединяется с основным серверным процессом базы данных (на схеме — Postmaster), который создает новый серверный процесс специально для обслуживания запросов на доступ к данным конкретного клиента.

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

    Клиентские приложения соединяются с базой по специальному протоколу PostgreSQL. Однако можно установить на стороне клиента программное обеспечение, предоставляющее стандартный интерфейс для работы с нужным приложением, например, по стандарту ODBC или JDBC. Доступность ODBC-драйвера позволяет применять PostgreSQL в качестве базы данных для многих существующих приложений, включая такие продукты Microsoft Office, как Excel и Access. Способность взаимодействия PostgreSQL с приложениями будет подробнее рассмотрена в следующих главах.

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

    Open Source-лицензированная база данных

    В начале XXI века многие компьютерные системы создаются на основе свободно распространяемых программ с открытыми исходными кодами. К их числу относится и PostgreSQL. Что же это означает в действительности?

    Когда понятие Open Source применяется к программному обеспечению, оно приобретает специальный смысл. Такое программное обеспечение поставляется вместе с исходными кодами. Это не обязательно значит, что на его применение не налагаются никакие условия. Оно все-таки лицензируется в том смысле, что вы получаете право некоторым образом использовать это программное обеспечение.

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

    Если с программным обеспечением Open Source возникают проблемы, пользователь может или исправить ошибки сам (поскольку у него есть исходные тексты), или же передать код кому-то другому для исправления. Сейчас многие коммерческие компании предлагают поддержку продуктов Open Source, поэтому, приобретая такой продукт, не стоит чувствовать себя «забытым».

    Существует несколько разновидностей лицензий Open Source, некоторые из них имеют большее число ограничений на распространение, другие меньшее. Тем не менее все они придерживаются принципа доступности исходных кодов программ и разрешают дальнейшее их распространение.

    Наиболее либеральной является лицензия Berkeley Software Distribution (BSD), разрешающая делать с программным обеспечением все что угодно, не предоставляя при этом никаких гарантий. Лицензия на использование PostgreSQL по сути своей аналогична лицензии BSD, она представляет собой заявление об авторских правах, в котором говорится: «Настоящим предоставляется право на использование, копирование, модификацию и распространение данного программного продукта и относящейся к нему документации в любых целях, без оплаты и без подписания соответствующих соглашений при условии, что во всех копиях будет присутствовать уведомление об авторских правах, указанное выше, данный абзац и два последующих». Два следующих абзаца посвящены отказу от каких бы то ни было обязательств и гарантий.

    Ресурсы по обучению PostgreSQL

    1. Информация о базах данных в целом и о PostgreSQL в частности может быть получена из множества источников, как печатных, так и доступных через Интернет.
    2. Подробно о теоретических основах баз данных рассказано в разделе Tech Talk на сайте Дэвида Фрика (Dav >

    Postgres95 постреляционная субд postgres95

    Появление глобальной сети Internet ознаменовало новый этап в развити человечества. С этого момента наш век действительно стал информационным, так как Internet позволил осуществлять быстрый обмен информацией между людьми, находящимися в различных местах земного шара, предоставляя свои многочисленные сервисы — электронную почту, телеконференции, передачу файлов (FTP), доступ в режиме удаленного терминала и др. Но все же основным шагом к открытию Internet для массового пользователя стало появление технологии World W >В настоящий момент в мире существует масса информационных источников, доминирующим средством хранения которых являются системы управления базами данных. Но открытость информации во многих базах данных отнюдь не означает легкость доступа к данным для непрофессионального пользователя, так как для этого необходим не только физический доступ к соответствующей СУБД, но также и знания об используемой модели данных, схемы бызы данных, умения пользоваться языком запросов. Поэтому сегодня данная проблема предоставления удобного доступа к имеющимся в наличии базам данных остается очень актуальной для многих организаций, компаний, научных учереждений, и решение ее видится только в свете применения Web-технологии.

    World Wide Web позволяет осуществлять доступ к базам данных, предоставляя средства для разработки простого, удобного интерфейса пользователя и средства взаимодействия с прикладными программами. Интерфейс пользователя разрабатывается на основе языка гипертекстовой разметки HTML, и в частности, с использованием HTML-форм, которые являются наиболее удобным механизмом представления и передачи запросов к базам данных. Средства по обеспечению доступа к базам данных можно классифицировать по месту обработки данных внешними программами на:

    • обеспечивающие доступ к базе данных на стороне Web-сервера (средства подключения внешнего программного обеспечения — спецификация CGI, FastCGI и API-интерфейс прикладных модулей);
    • работающие на стороне клиента (средства программирования приложений — интерпретируемые языки Javascript и Java).

    База знаний студента. Реферат, курсовая, контрольная, диплом на заказ

    Средства доступа к базам данных в Internet и свободно доступная СУБД POSTGRES95 — Информатика, программирование

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

    • CGI
    • API
    • FastCGI

    Common Gateway Interface — это спецификация интерфейса взаимодействия Web-сервера с внешними прикладными программами. Главное назначение CGI — обеспечение единообразного потока данных между сервером и работающим на нем приложением. CGI определяет:

    1. порядок взаимодействия сервера с прикладной программой, в котором сервер выступает инициирующей стороной;
    2. механизм реального обмена данными и управляющими командами в этом взаимодействии, что не определено в протоколе 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-программы не имеют взаимосвязей с установлением аутентификации пользователя и проверки его входных данных.

    В ответ на ограничения и недостатки спецификации 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’;

    будет являться следующая таблица:

    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 с указанием имени базы данных:

    Пользователь может непосредственно из командной строки монитора вводить одну за другой SQL-команды, а может передавать запрос в виде файла с SQL-операторами через командную строку ОС UNIX:

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

    LIBPQ — прикладной программный интерфейс POSTGRES95. Он представлен набором библиотечных функций (подпрограмм), которые позволяют клиентским программам посылать запросы серверу СУБД и получать от него соответствующие результаты. Для этого в прикладную программу включают главный файл библиотеки libpq-fe.h , встраивают функции LIBPQ и производят компиляцию кода программы с библиотеками POSTGRES95. Схема доступа к базам данных из внешних программ достаточно простая. С помощью специальной функции PQsetdb устанавливается TCP-соединение по определенному порту (как правило, — 5432) прикладной программы с процессом-демоном postmaster’ом. При этом функции передаются параметры значений имени базы данных, IP-адреса сервера, порта соединения. Далее при успешном соединении происходит выполнение в рамках функции PQexec SQL-операторов языка запросов POSTQUEL — открытие транзакции с базой данных, выполнение запроса и закрытие транзакции. После этого происходит завешение соединения с базой данных. При выполнении запроса по выбору данных из БД POSTGRES95 создает временную таблицу, в которую помещает полученный результат. Используя SQL-операторы, связанные с курсорами, и специальные функции LIBPQ по работе с кортежами, полями отношений, достаточно просто осуществляется доступ к элементам результирующей таблицы, что приводит к генерации произвольных отчетов по запросам пользователей. Ниже приведен фрагмент Cи-программы, реализующей запрос к базе данных «polyn»:

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

    conn = PQsetdb(pghost, pgport, pgoptions, pgtty, dbname);

    /* проверка статуса выполнения соединения */

    Постреляционная СУБД POSTGRES95

    Анализ основных вариантов сценариев реализации WWW-доступа к БД

    При обеспечении WWW-доступа к существующим БД, возможен ряд альтернативных путей — комплексов технологических и организационных решений. Практика использования WWW-технологии для доступа к существующим БД предоставляет в настоящее время широкий спектр технологических решений, по разному связанных между собой — перекрывающих, взаимодействующих и т.д. Выбор конкретных решений при обеспечении доступа зависит от специфики конкретной СУБД и от ряда других факторов, например таких как: наличие специалистов, способных с минимальными издержками освоить определенную ветвь технологических решений, существование других БД, WWW-доступ к которым должен осуществляться с минимальными дополнительными затратами и т.д.

    WWW — доступ к существующим базам данных может осуществляться по одному из трех основных сценариев. Рассмотрим их краткое описание и основные характеристики.

    6.5.1. Однократное или периодическое преобразование содержимого БД в статические документы

    В этом варианте содержимое БД просматривает специальная программа (преобразователь), создающая множество файлов – связных HTML-документов (рис.5-1). Полученные файлы копируются на WWW-сервер. Доступ к ним осуществляется как к статическим гипертекстовым документам сервера.

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

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

    6.5.2. Динамическое создание гипертекстовых документов на основе содержимого БД

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

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

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

    Для реализации такой технологии необходимо использовать взаимодействие WWW-сервера с запускаемыми программами CGI (Common Gateway Interface). Выбор программных средств для их реализации в настоящее время достаточно широк – это универсальные языки программирования (C, Perl), интегрированные средства типа генераторов отчетов. При использовании современных реляционных СУБД с внутренними языками программирования возможно использования этого языка для генерации документов.

    6.5.3. Создание информационного хранилища на основе высокопроизводительной СУБД с языком запросов SQL

    Наиболее предпочтительным вариантом с точки зрения перспективы развития для рассматриваемой системы является использование технологии, получившей название «информационного хранилища» (ИХ), с периодической загрузкой данных в хранилище из основных СУБД. Для обработки разнообразных запросов, в том числе и от WWW-сервера, используется промежуточная БД высокой производительности. Информационное наполнение промежуточной БД осуществляется специализированным программным обеспечением на основе содержимого основных баз данных и включает два этапа:

    · перегрузка данных (рис.5-3);

    · обработка запросов (рис.5-4)

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

    Основой повышения производительности обработки WWW-запросов и резкого увеличения скорости разработки WWW-интерфейсов является использование внутренних языков СУБД информационного хранилища для создания гипертекстовых документов.

    Для загрузки содержимого основной БД в информационное хранилище могут использоваться все перечисленные решения (языки программирования, интегрированные средства), а также специализированные средства перегрузки, поставляемые с SQL-сервером и продукты поддержки информационных хранилищ.

    1) СУБД POSTGRES95 была спроектирована и разработана в Калифорнийском университете г. Беркли под руководством известного специалиста в области баз данных профессора Стоунбрейкера, который в 1975-1980 гг. создал довольно популярную реляционную СУБД Ingres.

    2) Направление POSTGRES принадлежит к числу так называемых постреляционных систем — к следующему этапу в развитии реляционных СУБД. В настоящее время основным предметом критики последних является не их недостаточная эффективность, а присущая этим системам некоторая ограниченность (прямое следствие простоты) при использовании в нетрадиционных областях, в которых требуются предельно сложные структуры данных. Другим, часто отмечаемым недостатком реляционных баз данных, является невозможность адекватного отражения семантики предметной области.

    2-1) Поэтому современные исследования в области постреляционных систем, главным образом, посвящены устранению именно этих недостатков, и во многом требования к этим системам означают просто необходимость реализации свойств, отсутствующих в большинстве текущих реляционных СУБД. В их число, например, входит полнота системы типов, поддержка иерархии и наследования типов, возможность управления сложными объектами и т.д.

    7.2. Основные особенности СУБД

    СУБД POSTGRES95, являясь пост реляционной системой, сохраняет основные свойства реляционных СУБД и в то же время имеет свои, отличные от других, возможности.

    1) СУБД POSTGRES95 поддерживает темпоральную модель хранения и доступа к данным. То есть для любого объекта данных, созданного в момент времени t1 и уничтоженного в момент времени t2, в БД сохраняются (и доступны пользователям) все его состояния во временном интервале (t1,t2).

    Обычные же БД хранят мгновенный снимок модели предметной области, и любое изменение в момент времени t некоторого объекта приводит к недоступности этого объекта в предыдущий момент времени. Хотя, на самом деле, в большинстве развитых СУБД предыдущее состояние объекта сохраняется в журнале изменений, но осуществления доступа со стороны пользователя нет.

    2-1) В связи с этим, в POSTGRES95 пересмотрен механизм журнализации изменений, откатов транзакций и восстановления БД после сбоя. Особенность системы управления памятью заключается в том, что не ведется обычная журнализация и мгновенно обеспечивается корректное состояние БД с утратой состояния в оперативной памяти.

    2-2) Также система управления памятью поддерживает исторические данные, соответствующие возможности работы с которыми заложены в язык POSTQUEL. Запросы могут содержать выборку данных в определенное время, в определенном интервале времени. Например, результатом запроса

    SELECT city, population FROM cities[‘epoch’,’now’] WHERE city=’Moscow’;

    будет являться следующая таблица:

    Moscow 7 360 000

    Moscow 8 950 000

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

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

    3) Одним из основных положений реляционной модели данных является требование нормализации отношений: поля кортежей могут содержать лишь атомарные значения. Приведение исходного табличного представления предметной области к первой нормальной форме является основным шагом в процессе проектирования реляционной базы данных. В СУБД POSTGRES95 реализована «ненормализованная» реляционная модель данных, которая допускает хранение в качестве элемента кортежа многомерных массивов фиксированной и переменной длины, и других данных, в том числе абстрактных, определенных пользователями типов:

    CREATE TABLE salary (name text,pay_by_quarter int4[ ], schedule char16[ ][ ]);

    Это свойство POSTGRES95 сближает ее со свойствами объектно-ориентированных СУБД, хотя семантические возможности модели данных POPSTGRES95 существенно слабее.

    4) Язык запросов СУБД 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-функций.

    4-1) POSTQUEL поддерживает два типа функций: SQL-функции и функции, написанные на языке программирования, например, на Си. Кроме функций, пользователь может создавать свои агрегаты и операторы. POSTGRES95 позволяет легко вводить новые структуры, используя не физическую, а логическую модель хранения данных. В системных каталогах POSTGRES95, в отличие от стандартных реляционных систем, хранится информация не только об отношениях и атрибутах, но также и информация о типах, функциях, методах доступа и т.п. В POSTGRES95 системные каталоги представлены следующими классами: pg_database — базы данных; pg_class — отношения; pg_attribut — атрибуты; pg_proc — процедуры (и на Си, и на SQL); pg_type — типы; pg_aggregate – функции и агрегаты; и др. Каждый класс располагается в файле с соответствующим именем, которое начинается с pg_, куда помещаются все вносимые пользователем изменения при создании таблиц, типов, функций и т.д. Между классами установлены отношения, которые позволяют связывать различные структуры и осуществлять внутренние операции между ними.

    7.3. Архитектура СУБД POSTGRES95


    Архитектура СУБД POSTGRES95 основана на модели «клиент-сервер». Сессия с СУБД состоит из следующих взаимодействующих процессов:

    · postmaster — управляющий процесс-демон, который руководит взаимодействием между внешними и внутренними процессами; он выделяет совместно используемый буффер динамической памяти и выполняет другие инициализации во время запуска.

    · postgres — внутренний серверный процесс базы данных, исполняющий запросы клиента. Postmaster всегда запускает новый postgres-процесс для каждого клиентского приложения. Этот серверный процесс выполняется на машине сервера.

    · внешняя прикладная программа, которая может находиться на другом компьюторе (например, рабочей станции). Она соединяется с postgres через postmaster.

    Один раз запущенный процесс-демон postmaster управляет установленным набором баз данных на серевере.

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

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

    Таким образом, postmaster постоянно работает, ожидая запросов, в то время, как происходят и завершаются соединения с внешними приложениями. Прикладной программный интерфейс LIBPQ позволяет одной клиентской программе совершать во время одной сессии множественные соединения с сервером БД. Но тем не менее, внешняя программа — это однопотоковый процесс. Многопоточность процессов библиотекой LIBPQ не поддерживается.

    Другой особенностью архитектуры СУБД POSTGRES95 является то, что postmaster и postgres серверные процессы всегда выполняются на одной и той же машине — сервере базы данных, тогда как внешние программы могут находиться на любых машинах сети.

    Таким образом, СУБД POSTGRES95 позволяет осуществлять доступ клиентским прикладным программам к своим базам данных не только в локальном, но и удаленном режиме. Но система безопасности СУБД не предоставляет эту возможность всем пользователям. Для разрешения удаленного соединения с базами данных необходимо установить режим аутентификации для данного пользователя. По умолчанию в файле конфигурации этот режим отключен, и доступ разрешен только программам, расположенным в директории на машине сервера БД. Для установления аутентификации необходимо в файле pq_hba указать имена машин, с которых возможен удаленный доступ прикладным программам, и соответствующие базы данных, к которым разрешается удаленный доступ:

    all 127.0.0.1 0.0.0.0

    all 194.85.135.66 0.0.0.0

    После этого необходимо произвести заново компиляцию системы.

    Средства доступа к базам данных в Internet и свободно доступная СУБД POSTGRES95

    Средства доступа к базам данных в Internet и свободно доступная СУБД POSTGRES95

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

    Common Gateway Interface — это спецификация интерфейса взаимодействия Web-сервера с внешними прикладными программами. Главное назначение CGI — обеспечение единообразного потока данных между сервером и работающим на нем приложением. CGI определяет:

    1. порядок взаимодействия сервера с прикладной программой, в котором сервер выступает инициирующей стороной;
    2. механизм реального обмена данными и управляющими командами в этом взаимодействии, что не определено в протоколе 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-программы не имеют взаимосвязей с установлением аутентификации пользователя и проверки его входных данных.

    В ответ на ограничения и недостатки спецификации 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. Запросы могут содержать выборку данных в определенное время, в определенном интервале времени. Например, результатом запроса

    будет являться следующая таблица:

    city population
    Moscow 7 360 000
    Moscow 8 950 000

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

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

    Одним из основных положений реляционной модели данных является требование нормализации отношений: поля кортежей могут содержать лишь атомарные значения. Приведение исходного табличного представления предметной области к первой нормальной форме является основным шагом в процессе проектирования реляционной базы данных. В СУБД POSTGRES95 реализована «ненормализованная» реляционная модель данных, которая допускает хранение в качестве элемента кортежа многомерных массивов фиксированной и переменной длины, и других данных, в том числе абстрактных, определенных пользователями типов:

    Это свойство 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 указать имена машин, с которых возможен удаленный доступ прикладным программам, и соответствующие базы данных, к которым разрешается удаленный доступ:

    После этого необходимо произвести заново компиляцию системы.

    Доступ к базам данных под управлением СУБД POSTGRES95

    В СУБД POSTGRES95 реализованы две основные возможности доступа к своим базам данных:

    • через psql — интерфейс командной строки командной оболочки Shell;
    • из прикладной программы, написанной на языке программирования Си (или другом языке) с использованием функций прикладного интерфейса LIBPQ.

    Psql — это интерактивный терминальный монитор, позволяющий пользователю формулировать, редактировать и выполнять наборы команд — операторов языка POSTQUEL. Он запускается в режиме командной строки ОС UNIX с указанием имени базы данных:

    Пользователь может непосредственно из командной строки монитора вводить одну за другой SQL-команды, а может передавать запрос в виде файла с SQL-операторами через командную строку ОС UNIX:

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

    LIBPQ — прикладной программный интерфейс POSTGRES95. Он представлен набором библиотечных функций (подпрограмм), которые позволяют клиентским программам посылать запросы серверу СУБД и получать от него соответствующие результаты. Для этого в прикладную программу включают главный файл библиотеки libpq-fe.h , встраивают функции LIBPQ и производят компиляцию кода программы с библиотеками POSTGRES95. Схема доступа к базам данных из внешних программ достаточно простая. С помощью специальной функции PQsetdb устанавливается TCP-соединение по определенному порту (как правило, — 5432) прикладной программы с процессом-демоном postmaster’ом. При этом функции передаются параметры значений имени базы данных, IP-адреса сервера, порта соединения. Далее при успешном соединении происходит выполнение в рамках функции PQexec SQL-операторов языка запросов POSTQUEL — открытие транзакции с базой данных, выполнение запроса и закрытие транзакции. После этого происходит завешение соединения с базой данных. При выполнении запроса по выбору данных из БД POSTGRES95 создает временную таблицу, в которую помещает полученный результат. Используя SQL-операторы, связанные с курсорами, и специальные функции LIBPQ по работе с кортежами, полями отношений, достаточно просто осуществляется доступ к элементам результирующей таблицы, что приводит к генерации произвольных отчетов по запросам пользователей. Ниже приведен фрагмент Cи-программы, реализующей запрос к базе данных «polyn»:

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

    1. Ввод новой информации в БД для ведения базы данных.
    2. Генерация отчетов по запросам пользователей.

    Структура взаимодействия программного обеспечения информационной системы выглядит следующим образом (рис. 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 выбирайте сами — все они достаточно функциональны и выбор зависит в основном от целей, которые вы преследуете.

    Илон Маск рекомендует:  Правильное сочетание цветов
  • Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL