Postgres95 заключение доступ к базам данных под управлением субд postgres95

Содержание

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

Описание файла

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

Онлайн просмотр документа «25655-1»

Текст 2 страницы из документа «25655-1»

Рис.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’;

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

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

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

Одним из основных положений реляционной модели данных является требование нормализации отношений: поля кортежей могут содержать лишь атомарные значения. Приведение исходного табличного представления предметной области к первой нормальной форме является основным шагом в процессе проектирования реляционной базы данных. В СУБД 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»:

Средства доступа к базам данных в Internet и свободно доступная СУБД POSTGRES95 (стр. 3 из 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 серверные процессы всегда выполняются на одной и той же машине — сервере базы данных, тогда как внешние программы могут находиться на любых машинах сети.

Таким образом, СУБД 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. Создание информационной системы было направлено на выполнение следующих задач:

SQLite, MySQL и PostgreSQL: сравниваем популярные реляционные СУБД

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

Системы управления базами данных

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

Чтобы лучше разобраться в СУБД, ознакомьтесь с этой статьёй.

Реляционные системы управления базами данных

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

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

Отношения и типы данных

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

Level.Travel, Москва, до 200 000 ₽

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

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

Популярные РСУБД

В этой статье мы расскажем о 3 наиболее популярных РСУБД:

  • SQLite: очень мощная встраиваемая РСУБД.
  • MySQL: самая популярная и часто используемая РСУБД.
  • PostgreSQL: самая продвинутая и гибкая РСУБД.

SQLite

SQLite — это изумительная библиотека, встраиваемая в приложение, которое её использует. Будучи файловой БД, она предоставляет отличный набор инструментов для более простой (в сравнении с серверными БД) обработки любых видов данных.

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

Поддерживаемые типы данных

  • NULL: NULL-значение.
  • INTEGER: целое со знаком, хранящееся в 1, 2, 3, 4, 6, или 8 байтах.
  • REAL: число с плавающей запятой, хранящееся в 8-байтовом формате IEEE.
  • TEXT: текстовая строка с кодировкойUTF-8, UTF-16BE или UTF-16LE.
  • BLOB: тип данных, хранящийся точно в таком же виде, в каком и был получен.

Note: для получения более подробной информации ознакомьтесь с документацией.

Преимущества

  • Файловая: вся база данных хранится в одном файле, что облегчает перемещение.
  • Стандартизированная: SQLite использует SQL; некоторые функции опущены ( RIGHT OUTER JOIN или FOR EACH STATEMENT ), однако, есть и некоторые новые.
  • Отлично подходит для разработки и даже тестирования: во время этапа разработки большинству требуется масштабируемое решение. SQLite, со своим богатым набором функций, может предоставить более чем достаточный функционал, при этом будучи достаточно простой для работы с одним файлом и связанной сишной библиотекой.

Недостатки

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

Когда стоит использовать SQLite

  • Встроенные приложения: все портируемые не предназначенные для масштабирования приложения — например, локальные однопользовательские приложения, мобильные приложения или игры.
  • Система доступа к дисковой памяти: в большинстве случаев приложения, часто производящие прямые операции чтения/записи на диск, можно перевести на SQLite для повышения производительности.
  • Тестирование: отлично подойдёт для большинства приложений, частью функционала которых является тестирование бизнес-логики.

Когда не стоит использовать SQLite

  • Многопользовательские приложения: если вы работаете над приложением, доступом к БД в котором будут одновременно пользоваться несколько человек, лучше выбрать полнофункциональную РСУБД — например, MySQL.
  • Приложения, записывающие большие объёмы данных: одним из ограничений SQLite являются операции записи. Эта РСУБД допускает единовременное исполнение лишь одной операции записи.

MySQL

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

Поддерживаемые типы данных

  • TINYINT: очень маленькое целое.
  • SMALLINT: маленькое целое.
  • MEDIUMINT: целое среднего размера.
  • INT или INTEGER: целое нормального размера.
  • BIGINT: большое целое.
  • FLOAT: знаковое число с плавающей запятой одинарной точности.
  • DOUBLE, DOUBLE PRECISION, REAL: знаковое число с плавающей запятой двойной точности.
  • DECIMAL, NUMERIC: знаковое число с плавающей запятой.
  • DATE: дата.
  • DATETIME: комбинация даты и времени.
  • TIMESTAMP: отметка времени.
  • TIME: время.
  • YEAR: год в формате YY или YYYY.
  • CHAR: строка фиксированного размера, дополняемая справа пробелами до максимальной длины.
  • VARCHAR: строка переменной длины.
  • TINYBLOB, TINYTEXT: BLOB- или TEXT-столбец длиной максимум 255 (2^8 – 1) символов.
  • BLOB, TEXT: BLOB- или TEXT-столбец длиной максимум 65535 (2^16 – 1) символов.
  • MEDIUMBLOB, MEDIUMTEXT: BLOB- или TEXT-столбец длиной максимум 16777215 (2^24 – 1) символов.
  • LONGBLOB, LONGTEXT: BLOB- или TEXT-столбец длиной максимум 4294967295 (2^32 – 1) символов.
  • ENUM: перечисление.
  • SET: множества.

Преимущества

  • Простота: MySQL легко устанавливается. Существует много сторонних инструментов, включая визуальные, облегчающих начало работы с БД.
  • Много функций: MySQL поддерживает большую часть функционала SQL.
  • Безопасность: в MySQL встроено много функций безопасности.
  • Мощность и масштабируемость: MySQL может работать с действительно большими объёмами данных, и неплохо походит для масштабируемых приложений.
  • Скорость: пренебрежение некоторыми стандартами позволяет MySQL работать производительнее, местами срезая на поворотах.

Недостатки

  • Известные ограничения: по определению, MySQL не может сделать всё, что угодно, и в ней присутствуют определённые ограничения функциональности.
  • Вопросы надёжности: некоторые операции реализованы менее надёжно, чем в других РСУБД.
  • Застой в разработке: хотя MySQL и является open-source продуктом, работа над ней сильно заторможена. Тем не менее, существует несколько БД, полностью основанных на MySQL (например, MariaDB). Кстати, подробнее о родстве MariaDB и MySQL можно из нашего интервью с создателем обеих РСУБД — Джеймсом Боттомли.

Когда стоит использовать MySQL

  • Распределённые операции: когда вам нужен функционал бо́льший, чем может предоставить SQLite, стоит использовать MySQL.
  • Высокая безопасность: функции безопасности MySQL предоставляют надёжную защиту доступа и использования данных.
  • Веб-сайты и приложения: большая часть веб-ресурсов вполне может работать с MySQL, несмотря на ограничения. Этот инструмент весьма гибок и прост в обращении, что только на руку в длительной перспективе.
  • Кастомные решения: если вы работаете над очень специфичным продуктом, MySQL подстроится под ваши потребности благодаря широкому спектру настроек и режимов работы.

Когда не стоит использовать MySQL

  • SQL-совместимость: поскольку MySQL не пытается полностью реализовать стандарты SQL, она не является полностью совместимой с SQL. Из-за этого могут возникнуть проблемы при интеграции с другими РСУБД.
  • Конкурентность: хотя MySQL неплохо справляется с операциями чтения, одновременные операции чтения-записи могут вызвать проблемы.
  • Недостаток функций: в зависимости от выбора движка MySQL может недоставать некоторых функций.

PostgreSQL

PostgreSQL — это самая продвинутая РСУБД, ориентирующаяся в первую очередь на полное соответствие стандартам и расширяемость. PostgreSQL, или Postgres, пытается полностью соответствовать SQL-стандартам ANSI/ISO.

PostgreSQL отличается от других РСУБД тем, что обладает объектно-ориентированным функционалом, в том числе полной поддержкой концепта ACID (Atomicity, Consistency, Isolation, Durability).

Будучи основанным на мощной технологии Postgres отлично справляется с одновременной обработкой нескольких заданий. Поддержка конкурентности реализована с использованием MVCC (Multiversion Concurrency Control), что также обеспечивает совместимость с ACID.

Хотя эта РСУБД не так популярна, как MySQL, существует много сторонних инструментов и библиотек для облегчения работы с PostgreSQL.

Что такое 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

Анализ основных вариантов сценариев реализации 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 и свободно доступная СУБД POSTGRES 95

Осталось ждать: 20 сек.

Установите безопасный браузер

Предпросмотр документа

-3810381000Бинго! Ты только что нашел решение своей проблемы! Только давай договоримся – ты прочтешь текст до конца, окей? :)

Давай начистоту — тут один шлак, лучше закажи работу на HYPERLINK «http://author-24.site/» author-24.site и не парься – мы все сделаем за тебя! Даже если остался день до сдачи работы – мы справимся, и ты получишь «Отлично» по своему предмету! Только представь: ты занимаешься своим любимым делом, пока твои лохи-одногруппники теряют свои нервные клетки…

Проникнись… Это бесценное ощущение :)

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

Еще сомневаешься? Мы готовы подарить тебе сотни часов свободного времени за смешную цену – что тут думать-то? Жизнь одна – не трать ее на всякую фигню!

Перейди на наш сайт HYPERLINK «http://author-24.site/» author-24.site — обещаю, тебе понравится! :)

А работа, которую ты искал, находится ниже :)

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

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

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

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

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

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

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

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

Рис.2. Схема взаимодействия CGI-шлюза.

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

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

При применение спецификаци CGI для обмена данными с внешними прикладными программами можно выделить следующие преимущества:

«Языковая» независимость — CGI-программы могут быть написаны на любом языке программирования или командном языке, имеющим средства работы со строками;

Процессная изолированность — при запуске CGI-програмы на сервере порождается отдельный процесс и ошибочный CGI-скрипт не может сломать Web-сервер или получить доступ к закрытой информации;

Открытость стандарта — CGI интерфейс применим на каждом Web-сервере;

Архитектурная независимость — CGI не зависит от особенностей реализации архитектуры сервера (однопоточности, многопоточности и т.д.);

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

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

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

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

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

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

Одним из основных положений реляционной модели данных является требование нормализации отношений: поля кортежей могут содержать лишь атомарные значения. Приведение исходного табличного представления предметной области к первой нормальной форме является основным шагом в процессе проектирования реляционной базы данных. В СУБД 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

Читайте также:

  1. A.2.1.4 Недоступные интерфейсы
  2. C. Этап 3. Подготовка данных
  3. Corporate Information Factory, Корпоративное хранилище данных
  4. D. Очистка данных
  5. Data Mart — Витрины данных
  6. Data Mining (DM) — интеллектуальный анализ данных
  7. Data Warehouse – хранилище данных — ХД — систем обработки данных
  8. I. Создание HTML-страницы доступа к данным
  9. I. Создание баз данных
  10. If используется для разветвления процесса обработки данных на два направления.
  11. II. Несанкционированный доступ
  12. L ТРИПС регулирует вопросы правовой охраны произведений, созданных с применением новых технологий, а также новейшие способы использования произведений.

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

· через psql — интерфейс командной строки командной оболочки Shell;

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

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

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

% psql

| следующая лекция ==>
Архитектура СУБД POSTGRES95 | Для осуществления доступа к базам данных POSTGRES95 из World Wide Web

Дата добавления: 2014-01-11 ; Просмотров: 166 ; Нарушение авторских прав? ;

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

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

Система управления базами данных PostgreSQL

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

История MySQL начинается в 1979 г., у ее истоков стояла небольшая компания во главе с Monty Widenius. В 1996 г. появился первый релиз 3.11 под солярис с публичной лицензией. Затем MySQL была портирована под другие операционные системы, появилась специальная коммерческая лицензия. В 2000 г., после добавления интерфейса, аналогичного Berkeley DB, база стала транзакционной. Примерно тогда же была добавлена репликация. В 2001 г. в версии 4.0 был добавлен движок InnoDB к уже имеющемуся MyISAM, в результате чего появилось кеширование и возросла производительность. В 2004 г. вышла версия 4.1, в которой появились подзапросы, парциальная индексация для MyISAM, юникод. В версии 5.0 в 2005 г. появились хранимые процедуры, курсоры, триггеры, представления (views). В MySQL развиваются коммерческие тенденции: в 2009 г. MySQL стала торговой маркой компании Oracle.

История постгрес началась в 1977 г. с базы данных Ingress.

В 1986 г. в университете Беркли, Калифорния, она была переименована в PostgreSQL.

В 1995 г. постгрес стала открытой базой данных. Появился интерактивный psql.

В 1996 г. Postgres95 была переименована в PostgreSQL версии 6.0.

У постгреса несколько сотен разработчиков по всему миру.

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

PostgreSQL – унифицированный сервер баз данных, имеющий единый движок – storage engine. Постгрес использует клиент-серверную модель.

Для каждого клиента на сервере создается новый процесс (не поток !). Для работы с такими клиентскими процессами сервер использует семафоры.

Клиентский запрос проходит следующие стадии.

  1. Коннект.
  2. Парсинг: проверяется корректность запроса и создается дерево запроса (query tree). В основу парсера положены базовые юниксовые утилиты yacc и lex.
  3. Rewrite: берется дерево запросов и проверяется наличие в нем правил (rules), которые лежат в системных каталогах. Всякий раз пользовательский запрос переписывается на запрос, получающий доступ к таблицам базы данных.
  4. Оптимизатор: на каждый запрос создается план запроса – query plan, который передается исполнителю – executor. Смысл плана в том, что в нем перебираются все возможные варианты получения результата (использовать ли индексы, джойны и т.д.), и выбирается самый быстрый вариант.
  5. Выполнение запроса: исполнитель рекурсивно проходит по дереву и получает результат, используя при этом сортировку, джойны и т.д., и возвращает строки. Постгрес – обьектно-реляционная база данных, каждая таблица в ней представляет класс, между таблицами реализовано наследование. Реализованы стандарты SQL92 и SQL99.

Транзакционная модель построена на основе так называемого multi-version concurrency control (MVCC), что дает максимальную производительность. Ссылочная целостность обеспечена наличием первичных и вторичных ключей.

MySQL имеет два слоя – внешний слой sql и внутренний набор движков, из которых наиболее часто используется движок InnoDb, как наиболее полно поддерживающий ACID.

Реализован стандарт SQL92.

С модульной точки зрения код MySQL можно разделить на следующие модули.

  1. Инициализация сервера.
  2. Менеджер коннектов.
  3. Менеджер потоков.
  4. Обработчик команд.
  5. Аутентификация.
  6. Парсер.
  7. Кеш.
  8. Оптимизатор.
  9. Табличный менеджер.
  10. Движки (MyISAM, InnoDB, MEMORY, Berkeley DB).
  11. Логирование.
  12. Репликация.
  13. Сетевое API.
  14. API ядра.

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

Когда клиент подсоединяется к базе, управление передается менеджеру потоков, который создает поток (не процесс!) для клиента, и проверяется его аутентификация.

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

Организация СУБД PostgreSQL

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

В Windows управляет всем файл службы pg_ctl.exe (останавливает, запускает, перезапускает).

Сам движок базы – это postgres.exe.

Оптимизатор запросов мало подвержен управлению со стороны разработчиков, поэтому к нему вернемся лишь косвенно в разделе анализа быстродействия.
Зато управление дисковым пространством имеет весомое значение. Как и в любой СУБД, для баз данных PostgreSQL лучше использовать RAID 10 для баз данных и отдельный дисковый массив под логии. Применение STORAGE систем может также положительно сказаться на всем быстродействии. Еще одна фича, ускоряющая работу за счет расположения данных на разных дисках, это табличные пространства (tablespaces).

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

У PostgreSQL есть особенность в реализации хранения – это так называемый “кластер”. В данном случаи речь идет месте расположения каталога для баз данных. Плюс PostgreSQL организует единую файловую структуру, в которой отдельные файлы не соответствуют непосредственно таблицам или другим объектам базы данных.

При установке вы указываете “кластер” (читай каталог).

При установке PostgreSQL создает системную базу postgres и базу template1 как шаблон настроек для всех новых баз. Обычно в Linux-среде в каталоге /var/postgres/data находится некоторое количество служебных файлов для PostgreSQL, а в каталоге /var/postgres/data/base размещаются базы данных, каждая в своем отдельном каталоге.

К сожалению, реализованный в PostgreSQL способ хранения данных требует дополнительного обслуживания — периодической дефрагментации базы данных командой VACUUM.Примечание. Материализованные запросы (представления пользователя) view платформой не используются.

Размеры базы данных

На данный момент (версия 9.1.2), в PostgreSQL имеются следующие ограничения:

Максимальный размер базы данных

Нет ограничений

Максимальный размер таблицы

Максимальный размер записи

1,6 ТБайт

Максимальный размер поля

Максимум записей в таблице

Ограничено размером таблицы

Максимум полей в таблице

250—1600, в зависимости от типов полей

Максимум индексов в таблице

Нет ограничений

Сильными сторонами PostgreSQL считаются:

  • поддержка БД практически неограниченного размера;
  • мощные и надёжные механизмы транзакций и репликации ;
  • расширяемая система встроенных языков программирования: в стандартной поставке поддерживаются PL/pgSQL , PL/Perl , PL/Python и PL/Tcl ; дополнительно можно использовать PL/Java , PL/PHP , PL/Py , PL/R , PL/Ruby , PL/Scheme и PL/sh , а также имеется поддержка загрузки C -совместимых модулей [4] ;
  • наследование ;
  • легкая расширяемость.

Утилита администрирования баз данных PostgreSQL

pgAdmin — графическая оболочка проектирования и административная СУБД PostgreSQL для *nix и системы Windows.

pgAdmin пишется на языке программирования C и использует превосходный пакет разработчика платформы wxWidgets (когда-то wxWindows).

pgAdmin распространяется по лицензии PostgreSQL, т.е. также является свободным ПО.

PosgreSQL в 1С 8.0

1С:Предприятие 8 имеет некоторые особенности работы с СУБД PostgreSQL, связанные с использованием транзакционных блокировок:

режиме автоматического управления блокировками в транзакции используются табличные блокировки СУБД;

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

Управление соединениями с других компьютеров

По умолчанию, PostgreSQL разрешает только соединения на локальной машине через сокеты домена Unix или TCP/IP соединения. Для того, чтобы другие машины смогли подключиться к базе вы должны изменить в postgresql.conf , разрешить host-авторизация в файле $PGDATA/pg_hba.conf и перестартовать сервер.

Сравнительный Анализ PostgreSQL с MySQL

Заинтересовал меня СУБД PostgreSQL тремя моментами:

  • что-то новенькое (до этого в вебе все мои проекты бегали под mysql), интересно было пощупать что за зверь
  • более богатая возможность работы с R-деревьями (на практике — богатый набор возможностей работы с географическими данными)
  • ярые поклонники постгреса, заявляли что он стабильнее и надежнее (чем mysql)

Ниже приводится таблица сравнения основных возможностей этих СУБД. Критерии сравнения выбирались сугубо из моих интересов/опыта и обзоров в инете.

MySQL

PostgreSQL

Ответственный за код

компания MySQL AB

разные разработчики

Сжатие данных при передаче

Поддержка модели ACID

+/- (InnoDB, Falcon)

Поддержка SQL команд: insert ignore / replace

Поддержка внешних ключей

+/- (InnoDB)

Репликации

+ (говорят в 8.4 стало все хорошо)

Под запросы

Полнотекстовые индексы

+ (MyISAM)

Частичное индексирование

Чистка после работы команд UPDATE и DELETE

не нуждается

VACUUM

Система привилегий

+/- (проще чем в MySQL)

Хранение таблиц в файлах

Хранение/обработка географических данных

Лицензирование

GNU GPL

ACID-стандарт


Производительность (performance)

Базы данных часто оптимизируются в зависимости от окружения, в котором они работают. Обе базы имеют различные технологии для улучшения производительности. Исторически так сложилось, что MySQL начинала разрабатываться с прицелом на скорость, а PostgreSQL с самого начала разрабатывалась как база с большим числом настроек и соответствием стандарту. PostgreSQL имеет ряд настроек, которые повышают скорость доступа:

  • парциальные индексы;
  • компрессия данных;
  • выделение памяти;
  • улучшенный кеш.

MySQL имеет частичную поддержку парциальных индексов в InnoDB. Если взять MySQL-ский движок ISAM, он оказывается быстрее на плоских запросах, при этом нет блокировок на инсерты, нет поддержки транзакций, foreign key.

Компрессия

PostgreSQL лучше сжимает и разжимает данные, позволяя сохранить больше данных на дисковом пространстве. При этом компрессионные данные читаются быстрее с диска.

MySQL-компрессия для разных движков частично поддерживается, частично нет, и это зависит от конкретной версии конкретного движка.

На мульти-процессорности PostgreSQL имеет преимущество над MySQL. Даже сами разработчики MySQL признают, что их движок в этом плане не так хорош.

Типы данных

MySQL: для хранения бинарных данных использует типы TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB, которые отличаются размером (до 4 ГБ).

Character: четыре типа – TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT.

PostgreSQL: поддерживает механизм пользовательских данных с помощью команды CREATE TYPE, тип BOOLEAN, геометрические типы.

Character: TEXT (ограничение – max row size).

Для хранения бинарных данных есть тип BLOB, который хранится в файловой системе. Столбцы таблицы могут быть определены как многомерный массив переменной длины. Обьектно-реляционное расширение: структура таблицы может быть унаследована от другой таблицы.

Хранимые процедуры

И PostgreSQL , и MySQL поддерживают хранимые процедуры. PostgreSQL придерживается стандарта Oracle PL/SQL, MySQL – IBM DB2. MySQL поддерживает extend SQL для написания функций на языке C/C++ с версии 5.1. PostgreSQL: PL/PGSQL, PL/TCL, PL/Perl, SQL, C для написания хранимых процедур.

Ключи

И PostgreSQL , и MySQL поддерживают уникальность Primary Key и Foreign Key. MySQL не поддерживает check constraint плюс вторичные ключи реализованы частично. PostgreSQL: полная реализация плюс поддержка ON DELETE CASCADE и ON UPDATE CASCADE.

Триггеры

MySQL: рудиментарная поддержка. PostgreSQL: декларативные триггеры: SELECT, INSERT, DELETE, UPDATE, INSTEAD OF; процедурные триггеры: CONSTRAINT TRIGGER. События: BEFORE или AFTER на IN SERT, DELETE , UPDATE.

Автоинкремент

MySQL: в таблице может быть только один такой столбец, который должен быть проиндексирован. PostgreSQL: SERIAL data type.

Репликации

Поддерживаются и в MySQL, и в PostgreSQL. PostgreSQL имеет модульную архитектуру, и репликация входит в отдельные модули:

Репликация в PostgreSQL основана на триггерах и более медленная, чем в MySQL. В ядро репликацию планируется добавить, начиная с версии 8.4.

В MySQL репликация входит в ядро и имеет две разновидности, начиная с версии 5.1:

  • SBR – statement based replication;
  • RBR – row based replication.

Первый тип основан на логировании записей в бинарный лог, второй – на логировании изменений. Начиная с версии 5.5, в MySQL поддерживается так называемая полусинхронная репликация, при которой основной сервер (master) делает сброс данных на другой сервер (slave) при каждом коммите. Движок NDB делает полную синхронную двухфазную репликацию.

Транзакции

MySQL: только для для InnoDB. Поддержка SAVEPOINT, ROLLBACK TO SAVE POINT. Уровни блокировки: table level (MyISAM). PostgreSQL: поддерживается плюс read committed и уровни изоляции. Поддержка ROLLBACK, ROLLBACK TO SAVEPOINT. Уровни блокировки: row level, table level.

Уровни привилегий

PostgreSQL: для пользователя или группы пользователей могут быть назначены привилегии.

Экспорт-импорт данных

MySQL: набор утилит для экспорта: mysqldump, mysqlhotcopy, mysqlsnapshot. Импорт из текстовых файлов, html, dbf. PostgreSQL: экспорт – утилита pg_dump. Импорт между базами данных и файловой системой.

Вложенные запросы

Есть и в MySQL, и в PostgreSQL, но в MySQL могут работать непроизводительно.

Индексация

Хэширование индексов: в MySQL– частичное, в PostgreSQL – полное. Полнотекстовый поиск: в MySQL– частичный, в PostgreSQL – полный. Парциальные индексы: в MySQL не поддерживаются, в PostgreSQL поддерживаются. Многостолбцовые индексы: в MySQL ограничение 16 столбцов, в PostgreSQL – 32. Expression-индексы: в MySQL– эмуляция, в PostgreSQL – полное. Неблокирующий create index: в MySQL – частичное, в PostgreSQL – полное.

Партиционирование (Partitioning)

MySQL поддерживает горизонтальное партиционирование: range, list, hash, key, композитное партиционирование. PostgreSQL поддерживает RANGE и LIST. Автоматическое партиционирование для таблиц и индексов.

Автоматическое восстановление после сбоев

MySQL: частичное для InnoDB – нужно вручную сделать backup. PostgreSQL: Write Ahead Logging (WAL).

Data Storage Engines

PostgreSQL поддерживает один движок – Postgres Storage System. В MySQL 5.1 их несколько:

  • MyISAM – используется для хранения системных таблиц;
  • InnoDB – максимальное соответствие AC >
  • NDB Cluster – движок, ориентированный на работу с памятью, кластерная архитектура, использующая синхронную репликацию;
  • ARCHIVE – поддерживает компрессию, не использует индексы;
  • а также: MERGE, MEMORY (HEAP), CSV.

InnoDB разрабатывается компанией InnoBase, являющейся дочерней компанией Oracle. В 6-й версии должны появиться два движка – Maria и Falcon. Falcon – движок, основанный на ACID-транзакциях.

Лицензирование

PostgreSQL: BSD (Berkeley Software Distribution) open source. MySQL: GPL (Gnu General Public License ) или Commercial. MySQL – это open-source продукт. Postgres – это open-source проект.

Подводя итоги, можно сказать следующее: MySQL и PostgreSQL – две наиболее популярные open-source базы данных в мире. Каждая база имеет свои особенности и отличия. Если вам нужно быстрое хранилище для простых запросов с минимальной настройкой, я бы порекомендовал MySQL. Если вам нужно надежное хранилище для большого объема данных с возможностью расширения, репликации, полностью соответствующее современным стандартам языка SQL, я бы предложил использовать PostgreSQL.

Доступ к базам данных под управлением СУБД 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 );

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

if ( PQstatus ( conn )== CONNECTION_BAD )

printf ( %s , PQerrorMessage ( conn ));

/* начало транзакции с БД*/

res = PQexec ( conn , BEGIN );

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

if ( PQresultStatus ( res )!= PGRES_COMMAND_OK )

/* выполнение 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 nflds ; i ++) <

printf (

,

PQfname ( res , i ));

/* вывод элементов результирующего отношения */

for( i = 0 ; i ntups ; i ++) <

for ( j = 0 ; j nflds ; j ++) <

printf (

n ,

PQgetvalue ( res , i , j ));

res = PQexec ( conn , CLOSE myportal );

res = PQexec ( conn , END );

Для осуществления доступа к базам данных 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 является наилучшим решением этого вопроса. То есть использование того или иного средства зависит прежде всего от поставленной задачи для реализации — что необходимо в первую очередь обеспечить при ее решении

Илон Маск рекомендует:  Stat читать статус файла
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL
h3> %slt; %s