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


Содержание

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

  • Главная
  • Типовые ошибки установки сервера 1С:Предприятие и PostgreSQL на платформе Linux.

Типовые ошибки установки сервера 1С:Предприятие и PostgreSQL на платформе Linux.

  • Автор: Уваров А.С.
  • 22.05.2014

Связка сервера 1С:Предприятие и PostgreSQL вторая по популярности среди установок 1С и самое используемое решение на платформе Linux. В отличии внедрений на базе Windows и MSSQL, где трудно сделать так, чтобы не заработало, внедрения на базе Linux таят множество подводных камней для неопытного администратора. Часто бывает так, что вроде бы все сделано правильно, но ошибка следует за ошибкой. Сегодня мы рассмотрим самые типовые из них.

Общая информация

Перед тем, как начинать искать ошибки установки и, вообще, приступать к внедрению серверной версии 1С:Предприятия было бы неплохо освежить представление как это работает:

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

В нашем распоряжении имеются два сервера под управлением Ubuntu 12.04 x64, на одном из них установлен сервер 1С:Предприятие версии 8.3, на другом PostgreSQL 9.04 от Ethersoft, а также клиент под управлением Windows. Напоминаем, что клиент работает только с сервером 1С, который, в свою очередь, формирует необходимые запросы к серверу СУБД. Никаких запросов от клиента к серверу управления базами данных не происходит.

Сервер баз данных не обнаружен
ВАЖНО: пользователь «postgres» не прошёл проверку подлинности (Ident)

Данная ошибка возникает при разнесении серверов по разным ПК из-за неправильно настроеной проверки подлинности в локальной сети. Для устранения откройте /var/lib/pgsql/data/pg_hba.conf, найдите строку:

и приведите ее к виду:

где 192.168.31.0/24 — диапазон вашей локальной сети. Если такой строки нет, ее следует создать в секции IPv4 local connections.

Сервер баз данных не обнаружен
could not translate host name «NAME» to address: Temporary failure in name resolution

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

А теперь вспоминаем, о чем было сказано несколько раньше. Клиентом сервера СУБД является сервер 1С, но никак не клиентский ПК, следовательно запись нужно добавлять на сервере 1С:Предприятие в файл /etc/hosts на платформе Linux или в C:\Windows\System32\drivers\etc\hosts на платформе Windows.

Аналогичная ошибка будет возникать, если вы забыли добавить запись типа A для сервера СУБД на локальном DNS-сервере.

Ошибка при выполнении операции с информационной базой
server_addr=NAME descr=11001(0x00002AF9): Этот хост неизвестен.

Как и прошлая, эта ошибка связана с неправильным разрешением клиентом имени сервера. На этот раз именно клиентским ПК. В качестве решения добавляем в файл /etc/hosts на платформе Linux или в C:\Windows\System32\drivers\etc\hosts на платформе Windows запись вида:

где указываете адрес и имя вашего сервера 1С:Предприятия. В случае использования локального DNS следует добавить A-запись для сервера 1С.

Ошибка СУБД: DATABASE не пригоден для использования

Гораздо более серьезная ошибка, которая говорит о том, что вы установили несовместимую с 1С:Предприятие версию PostgreSQL или допустили грубые ошибки при установке, например не установили все необходимые зависимости, в частности библиотеку libICU.

Если вы имеете достаточный опыт администрирования Linux систем, то можете попробовать доустановить необходимые библиотеки и заново инициализировать кластер СУБД. В противном случае PostgreSQL лучше переустановить, не забыв удалить содержимое папки /var/lib/pgsql.

Также данная ошибка может возникать при использовании сборок 9.1.x и 9.2.x Postgre@Etersoft, подробности смотрите ниже.

Ошибка СУБД:
ERROR: could not load library «/usr/lib/x86_64-linux-gnu/postgresql/fasttrun.so»

Довольно специфичная ошибка, характерная для сборок 9.1.x и 9.2.x Postgre@Etersoft, также может приводить предыдущей ошибке. Причина кроется в неисправленной ошибке в библиотеке fasttrun.so. Решение — откатиться на сборку 9.0.x Postgre@Etersoft.

Ошибка СУБД
ERROR: type «mvarchar» does not exist at character 31

Возникает если база данных была создана без помощи системы 1С:Предприятия. Помните, для работы с 1С базы данных следует создавать только с использованием инструментов платформы 1С: через консоль Администрирование серверов 1С Предприятия

или через средство запуска 1С.

Сервер баз данных не обнаружен
ВАЖНО: пользователь «postgres» не прошёл проверку подлинности (по паролю)

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

Сервер баз данных не обнаружен
FATAL: database «NAME» does not exist

Еще одна очень простая ошибка. Смысл ее сводится к тому, что указанная БД не существует. Чаще всего возникает из-за ошибки в указании имени базы. Следует помнить, что информационная база 1С в кластере и база данных СУБД — две разные сущности и могут иметь различные имена. Также следует помнить, что Linux системы чувствительны к регистру и для них unf83 и UNF83 два разных имени.

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

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

Информация о файле
Название файла Средства доступа к базам данных в Internet и свободно доступная СУБД POSTGRES95 от пользователя z3rg
Дата добавления 14.4.2009, 13:32
Дата обновления 14.4.2009, 13:32
Тип файла (zip — application/zip)
Скриншот Не доступно
Статистика
Размер файла 161,38 килобайт (Примерное время скачивания)
Просмотров 1586
Скачиваний
Оценить файл

Описание работы:

Реклама от Google
Доступные действия
  • Найти все файлы пользователя
  • Прокомментировать файл

Текст работы:

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

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

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»;

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

city population
Moscow 7 360 000
Moscow 8 950 000

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

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

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

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

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

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

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

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

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

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

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

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

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

# all 127.0.0.1 0.0.0.0 all 194.85.135.66 0.0.0.0

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

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

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

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

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

Пользователь может непосредственно из командной строки монитора вводить одну за другой 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 %s «,PQfname(res,i));>/* вывод элементов результирующего отношения */for(i=0; i%sn»,PQgetvalue(res,i,j)); > >PQclear(res);/* закрытие курсора */res=PQexec(conn,»CLOSE myportal»);PQclear(res);/* закрытие транзакции */res=PQexec(conn,»END»);PQclear(res); /* закрытие соединения*/PQfinish(conn);

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

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

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

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

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

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

Рис. 6. Интерфейсная страница для поиска данных

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

Таким образом, на сегодняшний день существует достаточно средств, обеспечивающих как хранение накопленных массивов информации, так и осуществляющих удобный доступ к ним через интерфейс World Wide Web. И не всегда их необходимо приобретать по коммерческим расценкам. Internet предоставляет много ресурсов бесплатно — необходимо иметь только желание и определенную настойчивость для их получения. Свободно распространяемая СУБД POSTGRES95 является тому очевидным примером. А средства доступа из WWW выбирайте сами — все они достаточно функциональны и выбор зависит в основном от целей, которые вы преследуете.

Использование ролей и управление доступом в PostgreSQL

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

Данное руководство научит вас управлять правами доступа PostgreSQL.

Примечание: Руководство выполнено на облачном сервере Ubuntu 12.04, однако все инструкции, кроме раздела по установке, можно применить и в других современных дистрибутивах Linux.

Установка PostgreSQL

Если СУБД PostgreSQL не была установлена ранее, установите её сейчас. Для этого используйте команды:

sudo apt-get update
sudo apt-get install postgresql postgresql-contrib

Во время установки PostgreSQL создает стандартного пользователя для работы. Перейдите в сессию этого пользователя.

sudo su — postgres

Права доступа PostgreSQL

PostgreSQL управляет доступом при помощи так называемых ролей.

Роли похожи на обычные системные права доступа Unix, однако, в отличие от Unix, они не делятся на пользователей и группы.

Роли могут быть членами других ролей, что позволяет им наследовать параметры привилегий определённых ранее ролей.

Просмотр ролей

Чтобы просмотреть существующие роли PostgreSQL, нужно открыть командную строку СУБД:

а затем ввести команду:

\du
List of roles
Role name | Attributes | Member of
————+————————————————+————
postgres | Superuser, Create role, Create DB, Replication | <>

Как видите, после установки в PostgreSQL существует всего одна роль, которая обладает широкими правами доступа.

Создание ролей PostgreSQL

Существует два базовых способа создания ролей: в командной строке PostgreSQL и в командной строке системы.

Создание роли в PostgreSQL

Проще всего создавать новые роли в командной строке PostgreSQL.

Для этого используется следующий синтаксис:

CREATE ROLE new_role_name;

Попробуйте создать новую роль (в руководстве она условно называется demo_role):

CREATE ROLE demo_role;
CREATE ROLE

Проверьте список существующих ролей:

\du
List of roles
Role name | Attributes | Member of
————+————————————————+————
demo_role | Cannot login | <>
postgres | Superuser, Create role, Create DB, Replication | <>

Как видите, в списке появилась новая роль. Обратите внимание: на данный момент у неё нет привилегий входа.

Создание роли в командной строке системы

Также можно создать роль при помощи команды createuser.

Закройте командную строку PostgreSQL:

Чтобы создать роль в командной строке системы, введите следующую команду (в руководстве эта роль будет условно называться test_user):

createuser test_user
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n

Команда задаст ряд вопросов, которые определят начальные привилегии данной роли.

Снова откройте командную строку Postgres и запросите список существующих ролей:

psql
\du
List of roles
Role name | Attributes | Member of
————+————————————————+————
demo_role | Cannot login | <>
postgres | Superuser, Create role, Create DB, Replication | <>
test_user | | <>

Как видите, роли, созданные разными методами, не идентичны. Роль, созданная в командной строке системы, имеет привилегии входа.

Удаление ролей PostgreSQL

Теперь попробуйте уровнять привилегии ролей demo_role и test_user. Это можно сделать во время создания роли (то есть нужно удалить и заново создать demo_role). Также можно просто отредактировать привилегии существующей роли.

Но прежде чем приступить к управлению привилегиями PostgreSQL, нужно научиться удалять роли.

Для этого используется следующий синтаксис:

DROP ROLE role_name;
Delete the «demo_role» role by typing:
DROP ROLE demo_role;
DROP ROLE

Если заданной в команде роли не существует, команда вернёт ошибку:

DROP ROLE demo_role;
ERROR: role «demo_role» does not exist

Оператор IF EXISTS позволяет избежать этой ошибки; команда с таким оператором удалит роль, если она существует. Если указанной роли нет, команда не вернёт ошибку.

DROP ROLE IF EXISTS role_name;

То есть, в любом случае команда будет выполнена успешно и не вернёт ошибку.

DROP ROLE IF EXISTS demo_role;
NOTICE: role «demo_role» does not exist, skipping
DROP ROLE

Определение привилегий во время создания роли

Теперь попробуйте снова создать роль demo_role, заранее установив её права доступа. Права роли можно указать сразу после главного оператора create.

Синтаксис выглядит так:

CREATE ROLE role_name WITH optional_permissions;

Полный список опций доступа можно просмотреть при помощи команды:

Чтобы у пользователя, связанного с этой ролью, были привилегии входа, введите:

CREATE ROLE demo_role WITH LOGIN;
CREATE ROLE

Проверьте список существующих ролей и обратите внимание на то, что теперь обе роли имеют одинаковые привилегии:

\du
List of roles
Role name | Attributes | Member of
————+————————————————+————
demo_role | | <>
postgres | Superuser, Create role, Create DB, Replication | <>
test_user | | <>

Чтобы роль имела права входа без аргумента login, используйте вместо CREATE ROLE такую команду:

CREATE USER role_name;

Команда CREATE USER отличается только тем, что автоматически даёт роли привилегии входа.

Управление правами роли PostgreSQL

Чтобы изменить права доступа уже существующей роли, используйте команду ALTER ROLE.

Её базовый синтаксис:

ALTER ROLE role_name WITH attribute_options;

Для примера попробуйте вернуть роли demo_role её исходные привилегии:

ALTER ROLE demo_role WITH NOLOGIN;
ALTER ROLE

Просмотрите список ролей:

\du
List of roles
Role name | Attributes | Member of
————+————————————————+————
demo_role | Cannot login | <>
postgres | Superuser, Create role, Create DB, Replication | <>
test_user | | <>

Теперь у роли demo_role нет привилегий входа.

Вернуть привилегии входа можно при помощи команды:

ALTER ROLE demo_role WITH LOGIN;


Смена пользователя PostgreSQL

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

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

Рассмотрим второй вариант.

Для начала нужно установить пароль для пользователя, в сессию которого нужно перейти.

Установите пароль для test_user:

Команда предложит ввести и подтвердить пароль. Затем закройте интерфейс PostgreSQL и вернитесь в сессию системного пользователя.

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

Но в данном случае это не так, потому нужно явно указать опции. Для этого используйте синтаксис:

psql -U user_name -d database_name -h 127.0.0.1 -W

Примечание: Вместо user_name укажите имя пользователя, при помощи которого нужно установить соединение; вместо database_name укажите имя БД, к которой нужно подключиться.

Оператор -h 127.0.0.1 указывает, что нужно подключиться к локальной машине по сетевому интерфейсу. Это позволит проходить аутентификацию, даже если имя пользователя и имя роли не совпадают. Флаг –W значит, что при входе в PostgreSQL нужно ввести пароль.

Чтобы открыть сессию пользователя test_user, введите:

psql -U test_user -d postgres -h 127.0.0.1 -W
Password for user test_user:

Программа запросит установленный ранее пароль.

Примечание: Данная команда подключит пользователя к БД postgres, стандартной БД, созданной во время установки.

Попробуйте поработать в этой сессии; как видите, данный пользователь имеет довольно узкие привилегии.

Вернитесь в сессию администратора:

\q
sudo su — postgres
psql

Управление привилегиями PostgreSQL

Как передать привилегии

Как правило, при создании БД или таблицы права доступа к ней есть только у создавшей её роли. Но такое поведение можно изменить.

Передавать права доступа другим ролям можно при помощи команды GRANT; её базовый синтаксис:

GRANT permission_type ON table_name TO role_name;

Для примера создайте таблицу:

CREATE TABLE demo (
name varchar(25),
id serial,
start_date date);
NOTICE: CREATE TABLE will create implicit sequence «demo_id_seq» for serial column «demo.id»
CREATE TABLE

\d
List of relations
Schema | Name | Type | Owner
———+————-+———-+———-
public | demo | table | postgres
public | demo_id_seq | sequence | postgres
(2 rows)

Теперь попробуйте передать некоторые права доступа к таблице demo роли demo_role (пусть это будет право на обновление, UPDATE).

GRANT UPDATE ON demo TO demo_role;

Чтобы передать полные права на таблицу, используйте оператор ALL:

GRANT ALL ON demo TO test_user;

Чтобы передать права доступа всем пользователям системы, вместо имени пользователя укажите PUBLIC:

GRANT INSERT ON demo TO PUBLIC;

Чтобы просмотреть назначенные привилегии доступа, введите:

\z
Access privileges
Schema | Name | Type | Access privileges | Column access privileges
———+————-+———-+—————————-+—————————
public | demo | table | postgres=arwdDxt/postgres +|
| | | demo_role=w/postgres +|
| | | test_user=arwdDxt/postgres+|
| | | =a/postgres |
public | demo_id_seq | sequence | |
(2 rows)

Как отнять привилегии

Команда REVOKE отнимает привилегии.

REVOKE permission_type ON table_name FROM user_name;

Данная команда тоже может использовать операторы all и public.

REVOKE INSERT ON demo FROM PUBLIC;

Групповые роли PostgreSQL

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

Для примера можно создать роль temporary_users и добавить в неё роли demo_role и test_user:

CREATE ROLE temporary_users;
GRANT temporary_users TO demo_role;
GRANT temporary_users TO test_user;

Теперь групповая роль temporary_users управлят привилегиями ролей demo_role и test_user.

Чтобы просмотреть сведения о принадлежности ролей можно с помощью команды:

\du
List of roles
Role name | Attributes | Member of
——————+————————————————+——————-
demo_role | |
postgres | Superuser, Create role, Create DB, Replication | <>
temporary_users | Cannot login | <>
test_user | |

Команда set role позволяет выбрать групповую роль, права которой нужно использовать.

Например, текущий пользователь postgres имеет права суперпользователя. Даже несмотря на то, что этот пользователь не является членом роли temporary_users, он может использовать её права:

SET ROLE temporary_users;

Теперь любая созданная таблица будет принадлежать групповой роли temporary_users.

CREATE TABLE hello (
name varchar(25),
id serial,
start_date date);

Просмотреть владельцев таблиц можно с помощью команды:

\d
List of relations
Schema | Name | Type | Owner
———+—————+———-+——————
public | demo | table | postgres
public | demo_id_seq | sequence | postgres
public | hello | table | temporary_users
public | hello_id_seq | sequence | temporary_users
(4 rows)

Как видите, новая таблица принадлежит роли temporary_users.

Чтобы вернуть оригинальные права текущей роли, введите:

Чтобы передать пользователю привилегии всех ролей, членом которых он является, используйте команду:

ALTER ROLE test_user INHERIT;

Чтобы удалить групповую роль (или любую роль), используйте:

DROP ROLE temporary_users;
ERROR: role «temporary_users» cannot be dropped because some objects depend on it
DETAIL: owner of table hello
owner of sequence hello_id_seq

Эта команда вернёт ошибку, потому что роли temporary_users принадлежит таблица. Сначала нужно передать права на таблицу другой роли:

ALTER TABLE hello OWNER TO demo_role;

Теперь роль таблица принадлежит роли demo_role.

\d
List of relations
Schema | Name | Type | Owner
———+—————+———-+————
public | demo | table | postgres
public | demo_id_seq | sequence | postgres
public | hello | table | demo_role
public | hello_id_seq | sequence | demo_role
(4 rows)

После этого роль temporary_users можно удалить:

DROP ROLE temporary_users;

Это удалит роль temporary_users; члены этой групповой роли не будут удалены.

Заключение

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

Всё так подробно и понятно, спасибо! А можно у Вас ещё поинтересоваться, вот кроме создания роли и разрешения на вход, нужно ещё установить временное ограничение (например, что данный пользователь может заходить в БД только до 31 декабря 2020). как такое можно сделать?

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

Чтобы кто-либо смог обратиться к базе данных, необходимо сначала запустить сервер баз данных. Программа сервера называется postgres . Для работы программа postgres должна знать, где найти данные, которые она будет использовать. Указать это местоположение позволяет параметр -D . Таким образом, проще всего запустить сервер, выполнив команду:

в результате которой сервер продолжит работу в качестве процесса переднего плана. Запускать эту команду следует под именем учётной записи PostgreSQL . Без параметра -D сервер попытается использовать каталог данных, указанный в переменной окружения PGDATA . Если и эта переменная не определена, сервер не будет запущен.

Однако обычно лучше запускать postgres в фоновом режиме. Для этого можно применить обычный синтаксис, принятый в оболочке Unix:

Важно где-либо сохранять информацию, которую выводит сервер в каналы stdout и stderr , как показано выше. Это полезно и для целей аудита, и для диагностики проблем. (Более глубоко работа с файлами журналов рассматривается в Разделе 24.3.)

Программа postgres также принимает несколько других параметров командной строки. За дополнительными сведениями обратитесь к справочной странице postgres и к следующей Главе 19.

Такой вариант запуска довольно быстро может оказаться неудобным. Поэтому для упрощения подобных задач предлагается вспомогательная программа pg_ctl . Например:

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

Обычно возникает желание, чтобы сервер баз данных сам запускался при загрузке операционной системы. Скрипты автозапуска для разных систем разные, но в составе PostgreSQL предлагается несколько типовых скриптов в каталоге contrib/start-scripts . Для установки такого скрипта в систему требуются права root.

В различных системах приняты разные соглашения о порядке запуска служб в процессе загрузки. Во многих системах для этого используется файл /etc/rc.local или /etc/rc.d/rc.local . В других применяются каталоги init.d или rc.d . Однако при любом варианте запускаться сервер должен от имени пользователя PostgreSQL , но не root или какого-либо другого пользователя. Поэтому команду запуска обычно следует записывать в форме su postgres -c ‘. ‘ . Например:

Ниже приведены более конкретные предложения для нескольких основных ОС. (Вместо указанных нами шаблонных значений необходимо подставить правильный путь к каталогу данных и фактическое имя пользователя.)

Для запуска во FreeBSD воспользуйтесь файлом contrib/start-scripts/freebsd в дереве исходного кода PostgreSQL .

В OpenBSD , добавьте в файл /etc/rc.local следующие строки:

В системах Linux вы можете либо добавить

в /etc/rc.d/rc.local или в /etc/rc.local , либо воспользоваться файлом contrib/start-scripts/linux в дереве исходного кода PostgreSQL .

Используя systemd , вы можете применить следующий файл описания службы (например, /etc/systemd/system/postgresql.service ):

Для использования Type=notify требуется, чтобы сервер был скомпилирован с указанием configure —with-systemd .

Особого внимания заслуживает значение тайм-аута. На момент написания этой документации по умолчанию в systemd принят тайм-аут 90 секунд, так что процесс, не сообщивший о своей готовности за это время, будет уничтожен. Но серверу PostgreSQL при запуске может потребоваться выполнить восстановление после сбоя, так что переход в состояние готовности может занять гораздо больше времени. Предлагаемое значение 0 отключает логику тайм-аута.

В NetBSD можно использовать скрипт запуска для FreeBSD или для Linux , в зависимости от предпочтений.

В Solaris , создайте файл с именем /etc/init.d/postgresql , содержащий следующую стоку:

Затем создайте символическую ссылку на него в каталоге /etc/rc3.d с именем S99postgresql .

18.3.1. Сбои при запуске сервера

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

Это обычно означает именно то, что написано: вы пытаетесь запустить сервер на том же порту, на котором уже работает другой. Однако, если сообщение ядра не Address already in use или подобное, возможна и другая проблема. Например, при попытке запустить сервер с номером зарезервированного порта будут выданы такие сообщения:

может означать, что установленный для вашего ядра предельный размер разделяемой памяти слишком мал для рабочей области, которую пытается создать PostgreSQL (в данном примере 4011376640 байт). Возможно также, что в вашем ядре вообще отсутствует поддержка разделяемой памяти в стиле System-V. В качестве временного решения можно попытаться запустить сервер с меньшим числом буферов (shared_buffers), но в итоге вам, скорее всего, придётся переконфигурировать ядро и увеличить допустимый размер разделяемой памяти. Вы также можете увидеть это сообщение при попытке запустить несколько серверов на одном компьютере, если запрошенный ими объём разделяемой памяти в сумме превышает этот предел.

не означает, что у вас закончилось место на диске. Это значит, что установленное в вашем ядре предельное число семафоров System V меньше, чем количество семафоров, которое пытается создать PostgreSQL . Как и в предыдущем случае можно попытаться обойти эту проблему, запустив сервер с меньшим числом допустимых подключений (max_connections), но в конце концов вам придётся увеличить этот предел в ядре.

Если вы получаете ошибку « illegal system call » (неверный системный вызов), то, вероятнее всего, ваше ядро вовсе не поддерживает разделяемую память или семафоры. В этом случае вам остаётся только переконфигурировать ядро и включить их поддержку.

18.3.2. Проблемы с подключениями клиентов

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

Это общая проблема « я не могу найти сервер и начать взаимодействие с ним » . Показанное выше сообщение говорит о попытке установить подключение по TCP/IP. Очень часто объясняется это тем, что сервер просто забыли настроить для работы по протоколу TCP/IP.

Кроме того, при попытке установить подключение к локальному серверу через Unix-сокет можно получить такое сообщение:

Путь в последней строке помогает понять, к правильному ли адресу пытается подключиться клиент. Если сервер на самом деле не принимает подключения по этому адресу, обычно выдаётся сообщение ядра Connection refused (В соединении отказано) или No such file or directory (Нет такого файла или каталога), приведённое выше. (Важно понимать, что Connection refused в данном контексте не означает, что сервер получил запрос на подключение и отверг его. В этом случае были бы выданы другие сообщения, например, показанные в Разделе 20.4.) Другие сообщения об ошибках, например Connection timed out (Тайм-аут соединения) могут сигнализировать о более фундаментальных проблемах, например, о нарушениях сетевых соединений.

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

Как вывести список баз данных и таблиц PostgreSQL с помощью psql

Главное меню » Базы данных » База данных PostgreSQL » Как вывести список баз данных и таблиц PostgreSQL с помощью psql

PostgreSQL поставляется с интерактивным инструментом, psqlкоторый позволяет вам подключаться к серверу и выполнять запросы к нему. При использовании psqlвы также можете воспользоваться его мета-командами. Эти команды полезны для сценариев и администрирования командной строки. Все мета-команды начинаются с обратного слэша без кавычек и также известны как команды обратного слэша.

В этой статье объясняется, как использовать базы данных и таблицы на сервере PostgreSQL psql.

Листинг баз данных

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

Когда пакет PostgreSQL установлен, создается административный пользователь с именем «postgres». По умолчанию этот пользователь может подключиться к локальному серверу PostgreSQL без пароля.

Чтобы получить доступ к psqlтерминалу как пользователь «postgres», запустите:

Из терминала psql выполните мета-команду \l или \list, чтобы вывести список всех баз данных:

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

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

Если вы хотите получить информацию о размерах баз данных, табличных пространствах по умолчанию и описаниях, используйте \l+ или \list+. Размер базы данных будет показан, только если текущий пользователь может подключиться к нему.

Чтобы получить список всех баз данных без доступа к оболочке psql, используйте переключатель -c, как показано ниже:

Другой способ составить список баз данных – использовать следующий оператор SQL:

В отличие от мета-команды \l, приведенный выше запрос покажет только имена баз данных:

Таблицы списков

Чтобы получить список всех таблиц конкретной базы данных сначала необходимо подключиться к нему с помощью мета-команды \c или \connect. Пользователь, вошедший в систему как терминал psql, должен иметь возможность подключаться к базе данных.

Например, чтобы подключиться к базе данных с именем «odoo», вы должны набрать:

Как только база данных переключена, используйте мета-команду \dt для вывода списка всех таблиц базы данных:

Вывод будет включать количество таблиц, имя каждой таблицы и ее схему, тип и владельца:

Если база данных пуста, вывод будет выглядеть так:

Для получения информации о размерах таблиц и описаний используйте \dt+.

Заключение

Вы узнали, как составлять список баз данных и таблиц PostgreSQL с помощью команды psql.

Не стесняйтесь оставлять комментарии, если у вас есть какие-либо вопросы.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

АйТи бубен

Инструменты пользователя

Инструменты сайта

Содержание

PostgreSQL

PostgreSQL (произносится «Постгре-Эс-Кю-Эль», коротко называется «Постгрес») — свободная объектно-реляционная система управления базами данных (СУБД система управления базами данных). Использует порт 5432/tcp/udp. PostgreSQL использует только один механизм хранения данных под названием Postgres storage system (система хранения Postgres), в котором транзакции и внешние ключи полностью функциональны, в отличии от MySQL, в котором InnoDB и BDB являются единственными типами таблиц, которые поддерживают транзакции.

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

MVCC — одна из ключевых технологий доступа к данным, которая используется в PostgreSQL. Она позволяет осуществлять параллельное чтение и изменение записей (tuples) одних и тех же таблиц без блокировки этих таблиц. Чтобы иметь такую возможность, данные из таблицы сразу не удаляются, а лишь помечаются как удаленные. Изменение записей осуществляется путем маркировки этих записей как удаленных, и созданием новых записей с измененными полями. Таким образом, история изменений одной записи сохраняется в базе данных и доступна для чтения другими транзакциями. Этот способ хранения записей позволяет параллельным процессам иметь неблокирующий доступ к записям, которые были удалены или изменены в параллельных незакрытых транзакциях. Техника, используемая в этом подходе, относительно простая. У каждой записи в таблицы есть системные скрытые поля xmin, xmax.

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

pg_hba.conf идентификация пользователей

pg_hba.conf — настройка политики доступа к базам данных и идентификации пользователей сервера PostgreSQL .

В этом файле описываются клиентские компьютеры сети, с которых разрешен доступ к SQL серверу PostgreSQL , а также методы идентификации клиентов. Этот файл может содержать два вида записей:

Примеры записей pg_hba.conf:

Кодировка БД PostgreSQL и locale

PostgreSQL поддерживает только общую для всех баз кластера кодировку, которая должна совпадать с локальной кодировкой (Настройка переменных локализации в Linux), иначе не будут работать строковые функции сортировки, upper/lower и т.п. Локаль общая для всех процессов сервера — соответственно он не может создать две базы в разных кодировках — кодировка всегда одна для всего сервера и всех его БД.

Посмотреть кодировку сервера (show server_encoding) и клиента(show client_encoding):

Т.е. создать базу в другой кодировке можно, но тогда в ней будут неправильно работать функции обработки строк и сортировка строк.

Указывать список кодировок нужно не для createdb (create database), а для подключения клиента к серверу (client_encoding), если кодировка символов которую ожидает программа-клиент не совпадает с её (программы-клиента) текущей системной локалью, с которой она была запущена.

Клиенты администрирования PostgreSQL

psql — PostgreSQL interactive terminal.

В директории /usr/share/doc/postgresql* можно найти дополнительную информацию по запуску.

Посмотреть и удалить активные запросы

Если запрос запущен из интерфейса pgsql, то завершение работы сервера не поможет — запрос все равно продолжит свое выполнение, необходимо вызывать функцию pg_cancel_backend.

SELECT запросы можно снимать из ОС командой kill

Транзакции в PostgreSQL

В PostgreSQL Транзакция — это список команд SQL, которые находятся внутри блока, начинающегося командой BEGIN и заканчивающегося командой COMMIT.

PostgreSQL фактически считает каждый оператор SQL запущенным в транзакции. Если вы не указываете команду BEGIN, то каждый отдельный оператор имеет неявную команду BEGIN перед оператором и (при успешной отработке оператора) команду COMMIT после оператора. Группа операторов заключаемая в блок между BEGIN и COMMIT иногда называется транзакционным блоком.

Пример запуска транзакции из файла delprices.sql, которая удаляет в БД test777 из таблиц prices и ratesheets строки с >


Выполним транзакцию для test777:

Мониторинг, логи, размер БД PostgreSQL

Лог файлы

Лог файлы PostgreSQL находятся в директории pg_log, для Fedora полный путь /var/lib/pgsql/data/pg_log. Детализация лог файлов настраивается в postgresql.conf.

Мониторинг

Текущую активность базы данных легко оценить с помощью команды ps, для вывода в реальном времени (с задержкой 1 секунда) можно использовать утилиту watch:

Так как для каждого клиента создаётся своя копия процесса postmaster, то это позволяет подсчитать число активных клиентов. Статусная строка даёт информацию о состоянии клиента. Фразы writer process, stats buffer process и stats collector process соответствуют системным процессам, запущенным самим PostgreSQL при старте. Пользовательские процессы имеют статусную строку вида:

«пользователь», «база» и «хост» соответствуют имени пользователя «пользователь» подсоединявшегося к базе «база» с компьютера «хост». «статус» может принимать следующие параметры:

Views сборщик статистики

Представления (Views) сборщика статистики.

Если в PostgreSql postgresql.conf разрешён сбор статистики (logging_collector = on), то информация об активности базы данных собирается в специальных системных таблицах.

Информация собранная «статистическим сборником» может оказаться полезной для оценки эффективности базы данных и запросов. Из этих представлений можно узнать, например

Стандартные Statistics Views. Вывести все представления каталога

Вывести соотношение hit/read. При выполнении запроса PostgreSQL сначала смотрит, есть ли нужные в запросе данные в разделяемой памяти (shared buffers). Если они найдены, засчитывается hit, если нет — делается сравнительно медленный системный вызов fread для поднятия данных с диска или из дискового кеша операционной системы и засчитывается read. В среднем, верно правило: чем больше отношение hit/read, тем лучше настроен PostgreSQL, так как он очень мало читает с диска, в основном извлекая данные из разделяемой памяти. Для большинства не очень больших баз это отношение должно лежать в пределах 5000-10000. Не стремитесь, однако, искусственно завысить настройку shared_buffers, которая прямо определяет hit/read: слишком большие размеры разделяемой памяти ведут к потере производительности в базах с интенсивной записью. Также стоит помнить, что fread может быть довольно быстрым, если данные находятся в дисковом кеше ОС.

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

Статистика по индексам. Список по индексам: сколько записей из индекса были использованы в запросах по этому индексу; сколько рядов при этом получилось достать из родительской таблицы; разность этих двух чисел. Суть данной статистики проста: если у вас большая разница read-ов и fetch-ей, значит индекс устарел и ссылается на уже несуществующие данные, т.е. не всякий просмотр индекса и чтение из него соответствующего указателя на данные из таблицы (read) вызывает чтение самих данных из таблицы (fetch). В этом случае необходимо перестроить данный индекс, чтобы он соответствовал реальным данным в таблице.

Уровни блокировок таблиц

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

Некоторые команды SQL автоматически устанавливают блокировку для выполнения своих функций; в таких случаях PostgreSQL всегда выбирает минимально необходимый уровень блокировки. После завершения транзакции блокировка немедленно снимается.

Команда LOCK TABLE без параметра устанавливает максимально жесткий режим блокировки (ACCESS EXCLUSIVE). Чтобы ограничения были менее жесткими, следует явно задать нужный режим.

Ситуация взаимной блокировки (deadlock) возникает в там случае, когда каждая из двух транзакций ожидает снятия блокировки другой транзакцией. Хотя PostgreSQL распознает взаимные блокировки и завершает их командой ROLLBACK, это все равно причиняет определенные неудобства. Приложения не должны сталкиваться с проблемой взаимных блокировок, поэтому проектируйте их так, чтобы объекты всегда блокировались в одинаковом порядке.

Automatic Vacuuming

Автоматическая сборка мусора (Automatic Vacuuming).

Синтаксис VACUUM:

Синтаксис ANALYZE:

Кроме сборки мусора (VACUUM) производится ещё и анализ (ANALYZE). Периодическое выполнение команды ANALYZE необходимо для нормального функционирования планировщика. Собранная с помощью этой команды статистика позволяет значительно ускорить выполнение SQL- запросов. То есть, если не хочется настраивать автоматическую сборку мусора, то в любом случае её придётся делать только теперь в ручную. Процесс обычной сборки мусора в PostgreSQL (VACUUM без приставки FULL) не блокирует таблиц и может выполняться в фоне, не мешая выполнению запросов. Регулярное исполнение команд VACUUM и ANALYZE обязательно. Это необходимо по той причине, что иначе не получится заново использовать дисковое пространство, которое занимают ранее удалённые или изменённые строки и не удастся обновить статистику для планировщика запросов. И то и другое отрицательно сказывается на эффективности использования ресурсов и производительности запросов. Начиная с версии PostgreSQL 8.1 сервер может самостоятельно автоматически запускать ещё один системный процесс, который, соответственно, так и называется autovacuum daemon. Все настройки для этого процесса хранятся в PostgreSql postgresql.conf. К значениям этих параметров следует отнестись крайне внимательно. Если по каким-то причинам демон было решено не запускать, то в любом случае необходимо производить сборку мусора и набор статистики в ручную.

Основным средством физического и аналитического сопровождения баз данных в PostgreSQL является команда SQL VACUUM и ее аналог — сценарий vacuumdb. Оба средства выполняют две общие функции:

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

Практика показала, что без более-менее регулярных запусков vacuum full analyze производительность системы постепенно падает, причем чем дальше, тем больше. Разница между vacuum и vacuum full заключается в том, что full физически переписывает на диске всю таблицу таким образом, чтобы в ней не оставалось «дырок» от удаленных или обновленных записей. Но его недостаток в том, что во время работы таблица полностью блокируется(включая и select запросы), что может привести к проблемам на популярном сервере — начнет скапливаться очередь запросов, ожидающих доступа к базе, каждый запрос требует памяти, память кончается, начинается запись в Как посмотреть информацию о swap?, из-за отсутствия памяти сам vacuum тоже начинает использовать swap и все начинает работать очень-очень медленно. Простой VACUUM (Без FULL) просто восстанавливает пространство и делает его доступным для повторного использования. Эта форма команды умеет работать параллельно с обычными чтение и запись таблицы, без монопольной блокировки.

Чтобы определить необходимость использования индекса для какой-либо таблицы, PostgreSQL должен иметь статистику по этой таблице. Эта статистика собирается при использовании VACUUM ANALYZE или просто ANALYZE. Используя статистику, оптимизатор узнает о том как много строк в таблице и если он должен использовать индексы, то он может принимать лучшие решения. Статистика также влияет на определение оптимального порядка соединений таблиц и метода соединения. При изменении содержимого таблицы должен периодически выполнятся сбор статистики.

Получение >

lcr_id — колонка автоинкрементная (lcr_id | integer | not null default nextval(‘df_lcr_list_lcr_id_seq’::regclass)). Запрос возвращает значение колонки lcr_id для вставленной записи, в этом случае id записи.

Системные таблицы pg_

Системные таблицы(System Catalogs) PostgreSQL начинаются с префикса pg_.

Имя таблицы Назначение таблицы
1 pg_aggregate aggregate functions
2 pg_am index access methods
3 pg_amop access method operators
4 pg_amproc access method support procedures
5 pg_attrdef column default values
6 pg_attribute table columns («attributes»)
7 pg_authid authorization identifiers (roles)
8 pg_auth_members authorization identifier membership relationships
9 pg_cast casts (data type conversions)
10 pg_class PostgreSQL System Catalogs tables, indexes, sequences, views («relations»)
11 pg_constraint check constraints, unique constraints, primary key constraints, foreign key constraints
12 pg_conversion encoding conversion information
13 pg_database databases within this database cluster Хранятся имена доступных баз данных
14 pg_depend dependencies between database objects
15 pg_description descriptions or comments on database objects В таблице хранятся описания объектов, для которых была применена функция COMMENT (расширение PostgreSQL). Например COMMENT ON TABLE mytable IS ‘Эта строка будет сохранена в системной таблице pg_description.’;
16 pg_enum enum label and value definitions
17 pg_foreign_data_wrapper foreign-data wrapper definitions
18 pg_foreign_server foreign server definitions
19 pg_index additional index information
20 pg_inherits table inheritance hierarchy
21 pg_language languages for writing functions
22 pg_largeobject large objects
23 PostgreSQL pg_listener asynchronous notification support Используется механизмом LISTEN/NOTIFY. pg_listener существует в версиях PostgreSQL меньше 9.
24 pg_namespace schemas
25 pg_opclass access method operator classes
26 pg_operator operators
27 pg_opfamily access method operator families
28 pg_pltemplate template data for procedural languages
29 pg_proc functions and procedures
30 pg_rewrite query rewrite rules
31 pg_shdepend dependencies on shared objects
32 pg_shdescription comments on shared objects
33 pg_statistic planner statistics
34 pg_tablespace tablespaces within this database cluster
35 pg_trigger triggers Триггеры хранятся в системной таблице pg_trigger, что позволяет получить информацию о существующих триггерах на программном уровне.
36 pg_ts_config text search configurations
37 pg_ts_config_map text search configurations’ token mappings
38 pg_ts_dict text search dictionaries
39 pg_ts_parser text search parsers
40 pg_ts_template text search templates
41 pg_type data types
42 pg_user_mapping mappings of users to foreign servers
Представления (View) Назначение
43 pg_cursors open cursors
44 pg_group groups of database users
45 pg_indexes indexes
46 pg_locks блокировки в PostgreSQL currently held locks Содержит информацию о блокировках. Уровни блокировок таблиц .
47 pg_prepared_statements prepared statements
48 pg_prepared_xacts prepared transactions
49 pg_roles database roles
50 pg_rules rules
51 pg_settings parameter settings
52 pg_shadow database users Существует для обратной совместимости, она имитирует каталог, который существовал в PostgreSQL до версии 8.1.
53 pg_stats planner statistics
54 pg_tables tables
55 pg_timezone_abbrevs time zone abbreviations
56 pg_timezone_names time zone names
57 pg_user database users Информативный характер о пользователях, пароль содержится в таблице pg_shadow
58 pg_user_mappings user mappings
59 pg_views views

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

Partitioning (партицирование, секционирование).

Управление доступом к данным в PosgreSQL

Условные обозначения, используемые при описания синтаксиса команд:

ТЕКСТ ПРОПИСНЫМИ БУКВАМИ — зарезервированные слова.

Тексткурсивом и строчными буквами — элементы, определяемые пользователем.

[текст в квадратных скобках] — необязательный элемент.

<текст в фигурных скобках>— элемент повторяющийся неопределенное количество раз, включая нулевое.

| — это разделитель «или» для выбора одного из нескольких элементов.

Содержание

Введение

Управление доступом к данным в сервере PostgreSQL осуществляется с помощью нескольких механизмов. Таких как: Конфигурационные файлы: postgresql.conf и pghba.conf.

С помощью этих файлов настраивается подключение к серверу Postgres.

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

Определение прав доступа к объектам баз данных для пользователей или групп с помощью SQL команд GRANT и REVOKE.

Конфигурационный файл pghba.conf

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

Синтаксис файла pghba.config должен удовлетворять ряду правил. В каждой строке файла находится одна хостовая запись. Перенос записи на другую строку не разрешается. Каждая запись состоит из нескольких полей, разделенных пробелами или знаками табуляции. Количество полей определяется типом хостовой записи и способом задания адреса. Тип хостовой записи определяется первым ключевым словом и может быть 4 видов. Коментарии должны начинаться с символа #.

Формат строки файла pg_hba:

1. Первое ключевое слово определяет тип подключения и соответственно тип хостовой записи:

local — для клиентских подключений с того же компьютера, на котором работает сервер

host — сетевое подключение

hostssl — для подключений локальных или удаленных хостов к серверу, с использованием ssl протокола, обеспечивающим шифрование всех взаимодействий с сервером.

Протокол ssl должен поддерживаться как клиентом, так и сервером.

2. Второй параметр database обозначает базы данных, к которым можно подключаться:

all — для разрешения подключения ко всем базам данных.

sameuser — для разрешения подключения только к базе данных имя которой совпадает с именем пользователя.

Имя базы данных или список баз данных, разделенный запятыми — для разрешения подключения к конкретной базе данных.

user — имена пользователей или групп, которым разрешается подключение с этого компьютера:

all — все пользователи

имя пользователя — имя конкретного пользователя +имя группы — имя группы

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

3. CIDR-address или IP адрес и IP маска — адрес хоста.

4. Тип аутентификации:

6. Опции, в зависимости от типа аутентификации.

Подробнее можно почитать в самом файле pg_hba или в документации к postgres [1] в разделе Server administration — Client authentication Пример:

Данная запись разрешает подключение пользователю postgres ко всем базам данных, причем пользователь postgres может подключаться только с локального адреса (127.0.0.1). Метод md5 означает, что обязательно использование пароля при установлении подключения. Тоже самое можно было бы задать и с помощью такой строки в pg_hba.config: local all «postgres» md5

Регистрация пользователя на сервере

Подключиться к серверу может только пользователь, имеющий учетную запись на сервере. Учетная запись на сервере создается в результате создания пользователя. В процессе аутентификации сервер postgres проверяет был ли зарегистрирован пользователь на сервере и правильно ли введен пароль. Для регистрации пользователя используется команда CREATE USER [1]. Синтаксис команды

где option может быть:

Так же пользователь может быть создан с использованием сценария createuser [2]. Для этого нужно в командной строке запустить файл createuser.exe. Этот файл находится в директории Program

FilesPostgreSQL8.2bin. Команда createuser выполняется с аргументами. Если аргументы не заданы первоначально, то они будут запрошены самой командой в процессе выполнения.

Пользователи и группы существуют как глобальные объекты баз данных, а это значит, что они не связаны с какой-то конкретной базой данных [2].

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

Группы существуют как вспомогательное средство, упрощающее представление этих прав.

Каждому пользователю postgres создается внутренний системный идентификатор sysid и пароль. Пароль не всегда обязателен — это настраивается в конфигурационном файле pg_hba.conf. Системный идентификатор связывает объекты базы данных с владельцем.

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

Суперпользователь — это пользователь, обладающий всеми правами во всех базах данных, включая право создания других пользователей. Глобальные права могут быть в любой момент изменены текущим суперпользователем.

В Postgres по умолчанию создается один суперпользователь postgres. Все остальные пользователи создаются этим пользователем или другими пользователями, созданными позже.

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

Для обычных пользователей информация об учетных записях (без паролей) хранится в таблице pg_user.

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

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

Не допускается совпадение имен пользователей и групп (ролей).

Группу может создать пользователь у которого есть права на создание ролей (CREATEROLE).

Пользователь не может создать группу или пользователя, обладающими большими правами, чем он сам.

Для создания группы используется команда CREATE ROLE. Синтаксис команды:

где option может быть:

Для добавления пользователя в группу используется команда ALTER GROUP. Синтаксис команды:

Для удаления пользователя из группы:

Для переименования группы: ALTER GROUP groupname RENAME TO newname

Предоставление привилегий

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

В postgres учет привилегий ведется при помощи списков управления доступом (ACL — Access Control List).

Информация, хранящаяся в списках, указывает каким пользователям разрешена выборка, обновления и другие способы модификации какого-либо объекта базы данных.

Таким образом для каждого объекта существует набор привилегий и ограничений доступа.

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

Команда для установки привилегий — GRANT.

Команда для установки ограничений — REVOKE.

Привилегии для объектов:

  • SELECT — выборка данных
  • INSERT — добавление, удаление данных
  • UPDATE — модификация объекта
  • DELETE — удаление объекта
  • REFERENCES — ссылка на таблицу
  • TRIGGER — создание триггеров
  • ALL — включает в себя все выше перечисленные
  • WITH GRANT OPTION — опция, позволяющая пользователю наделять других пользователей привилегиями к этому объекту, но не более тех, которыми он обладает сам.

Привилегии для объектов устанавливают или изменяют суперпользователи, владельцы объектов или пользователи, которым выданы привилегии к объекту с опцией WITH GRANT OPTION.

Команда GRANT имеет 2 базовых варианта:

  • привилегии на объекты базы данных (таблицы, представления, последовательности, базу данных, функции, процедурные языки, схему, tablespace).

-привилегии на членство в группе (роли) — в этом варианте команда перенаправляет привилегии роли тому пользователю или группе, которые указаны в команде. Наделение такой привилегией аналогично добавлению пользователя или группы в группу.

Синтаксис команды GRANT для таблиц и представлений:

Команда REVOKE предназначена для отзыва привилегий, выданных ранее.

Синтаксис команды REVOKE для таблиц и представлений:

Отзыв привилегий для PUBLIC влияет только на группу PUBLIC. Привилегии, выданные персонально (с указанием конкретных имен пользователей или групп) в этом случае остаются.

Сводка прав ACL просматривается в psql с помощью команды z. Для того, чтобы посмотреть сводку прав по какому-то конкретному объекту нужно указать его имя после команды z. Например:

Всех пользователей и группы можно посмотреть с помощью команды du

Про владельцев объектов

Владельцем объектов может быть пользователь или группа.

У каждого объекта базы данных может быть владелец, отличный от владельца базы данных.

Владельца объекта можно изменить после создания объекта. Это может сделать либо владелец объекта, либо суперпользователь.

Если у базы данных — один владелец, а у некоторого объекта этой базы данных другой, то владельца на этом объекте может сменить, только владелец объекта или суперпользователь и не может — владелец базы данных.

Владелец может раздавать привилегии на свой объект и изменять его.

Установка и настройка PostgreSQL

Устанавливаем мета-пакет postgresql, который подтянет все зависимости.

Теперь нам надо получить доступ к нашему серверу.

Первой строчкой мы представляемся системе как пользователь postgres. Это необходимо для того, чтобы попасть в консоль postgre, т.к. по-умолчанию туда пускает только такого пользователя. Второй строчкой мы входим в эту консоль. И затем уже в ней выполняем команду (alter user postgres with password ‘postgres’;), которая устанавливает пароль ‘postgres’ для пользователя ‘postgres’.

Теперь необходимо сделать так, чтобы нас пускало в postgres по паролю, а не так, как мы ранее сюда вошли. Для надо отредактировать файлик /etc/postgresql/8.3/main/pg_hba.conf

Там в конце пара изменений:

1. комментим строчку «local all postgres ident sameuser» 2. и строчку «local all all ident sameuser» заменяем на «local all all md5″. Т.е. мы указали сделали так, чтобы авторизация была по паролю (md5).

Получилось что-то типа такого:

Теперь необходимо перезагрузить сервер:

Всё, теперь можно пользоваться. Для входа в консоль postgresql:

Для postgresql есть аналог phpmyadmin под названием phppgadmin. Устанавливаем его:

Но сразу он вас туда под пользователем ‘postgres’ с паролем ‘postgres’ (что мы настроили ранее) не пустит. Исправим это. Отредактируем конфиг phppgadmin’а:

Находим в нём переменную «$conf[‘extra_login_security’]» и устанавливаем её значение в false.

База данных по умолчанию с именем postgres на сервере Postgresql

По-видимому, существует база данных «postgres», которая создается по умолчанию для каждой установки сервера postgresql. Может ли кто-нибудь сказать мне или указать мне на документацию, для чего он используется?

Похоже, что у него действительно нет четко определенной цели. Согласно документам:

Создание кластера базы данных состоит из создания каталогов, в которых будут храниться данные базы данных, создания общих таблиц каталога (таблиц, принадлежащих всему кластеру, а не какой-либо конкретной базе данных) и создания «шаблона1» и «postgres».

База данных postgres — это база данных по умолчанию, предназначенная для пользователей, утилит и сторонних приложений.

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

Когда вы запустите эту команду, psql подключается к серверу и запрашивает pg_database для списка имен баз данных. Однако, поскольку psql является клиентским приложением Postgres, он не может подключиться к серверу, не зная имя хотя бы одной базы данных: Catch-22. Таким образом, psql жестко закодирован для подключения к базе данных с именем «postgres» при запуске «psql -l».

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

С другой стороны, байт-код Java исполняется интерпретатором, а не является откомпилированной на данной платформе программой. Отсюда возникает первый очевидный недостаток — это скорость выполнения кода, так как интерпретатор работает гораздо медленнее откомпилированной программы. Собственно, и другие свойства технологии (объектная ориентируемость, использование многопоточности, отсутствие адресной арифметики и т.п.) в большинстве случаев при стандартной комплектации оборудования, только тормозят выполнение программы.

Основной протокол обмена апплетами — HTTP. Это значит, что они передаются по сети точно также, как и другие ресурсы Website, и приобретают свое особое значение только в момент получения их браузером. Учитывая неэффективность реализации HTTP поверх TCP, можно сказать, что и обмен апплетами тоже неэффективен, если для каждого обмена устанавливается свое TCP-соединение. В любом случае загрузка страниц с Java происходит гораздо медленнее, чем без Java.

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

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

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

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

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

В связи с этим, в POSTGRES95 пересмотрен механизм журнализации изменений, откатов транзакций и восстановления БД после сбоя. Особенность системы управления памятью заключается в том, что не ведется обычная журнализация и мгновенно обеспечивается корректное состояние БД с утратой состояния в оперативной памяти. Также система управления памятью поддерживает исторические данные, соответствующие возможности работы с которыми заложены в язык POSTQUEL. Запросы могут содержать выборку данных в определенное время, в определенном интервале времени. Например, результатом запроса

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

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

city population
Moscow 7 360 000
Moscow 8 950 000

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

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

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

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

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

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

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

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

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

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

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

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

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

# all 127.0.0.1 0.0.0.0 all 194.85.135.66 0.0.0.0

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

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

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

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

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

Пользователь может непосредственно из командной строки монитора вводить одну за другой 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 %s «,PQfname(res,i));>/* вывод элементов результирующего отношения

Похожие рефераты:

Серверы и клиенты. Функция GetSockName.

Понятие и характеристика открытой системы образовательных тестов (ОСОТ). Ее преимущества и недостатки, их сущность. Алгоритм работы с системой, детальное описание процесса. Установка системы на сервер и ее использование. Изложение алгоритма решения.

Уральский Государственный Технический Университет – УПИ Физико – Технический факультет Кафедра ФМПК “Разработка и создание СКС на базе сетей Ethernet при подключении пользователей жилого дома к глобальной сети INTERNET”

Московский государственный институт электроники и математики кафедра САПР Пояснительная записка к курсовому проекту по дисциплине «разработка САПР» на тему

Гипертекст — текст со вставленными в него словами (командами) разметки, ссылающимися на другие места этого текста, другие документы, картинки и т.д.

Анализ предметной области «Ремонт часов», с использованием СУБД MySQL, языка HTML, технологии PHP и ADO и выбора скриптовых языков VBScript или JavaScript. Нормализация базы данных. Пошаговое описание нормализации базы данных (методом ER-диаграмм).

WWW (World Wide Web) и средства интерактивного взаимодействия. Спецификация CGI. Последовательность действий для обработки входных данных cgi-модуля для разных методов запроса GET и POST.

На безопасность работы Веб-сервера влияют некоторые настройки, устанавливаемые вами в файлах конфигурации. Я буду говорить в основном о сервере Apache, хотя все замечания в равной степени применимы и к другим серверам.

Средства работы с ресурсами Internet. Программы-интерфейсы – www, Lynx, SlipKnot и I-com. Системы Arena, Netscape и Internet Explorer. Отечественная программа Ariadna. JavaScript — средство создания «оживших» страниц Web. Печать документов Internet.

Доступ в Internet. Mdaemon V2.7 sp5. Web-server Apache 1.3.9

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

Две архитектуры систем доступа к базам данных через Web. Доступ к базе данных на стороне клиента. Доступ к базе данных на стороне сервера. Технология Oracle Web deployment.Технология с использованием интерфейса CGI.

Переменные окружения интерфейса CGI. Работа с сокетами. Функции для работы с DNS.

Интерактивные формы. Системы оперативного управления сайтом. Системы типа Модель – Вид – Управление (Модель 2).

Русский Apache. Установка. Настройка. Файл access.conf.

Рекурсия — это обращение функции к самой себе. Многие не понимают, как же использовать рекурсию на практике.

Принцип работы и назначение сервлетов Java, их значение в повышении функциональности Web-серверов и улучшении их программирования, преимущества и недостатки использования. Способы вызова сервлетов с браузера и страницы. Запись и чтение атрибутов сессии.

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

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

В работе рассмотрены два простейших вида программирования: применение 1.CGI-скриптов и 2. JAVA-скриптов.

Илон Маск рекомендует:  B жирный шрифт
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL