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

Рассмотрение основных особенностей СУБД Postgre SQL. Оценка возможностей системы, которые упрощают управление базами данных и предохраняют от их потери или повреждения. Прослеживание истории развития системы, описание ее достоинств и сферы применения.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 21.01.2015
Размер файла 154,6 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Введение

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

POSTGRES является пионером во многих объектно-реляционных аспектах, появившихся теперь в некоторых коммерческих СУБД. Традиционные реляционные СУБД (RDBMS) поддерживают модель данных, которая составляет коллекцию поименованных кортежей, содержащих атрибуты заданного типа. В современных коммерческих системах, к возможным типам относятся числа с плавающей точкой, целые числа, символьные строки, денежные типы и даты. Это обычно приводит к тому, что данная модель является неадекватной для будущих приложений обработки данных. Реляционная модель успешно заменяет предыдущие модели отчасти в силу "Спартанской простоты". Однако, такая простота делает реализацию определённых приложений очень трудной. PostgreSQL предлагает существенное увеличение мощи СУБД, через внедрение следующих дополнительных аспектов, которые позволяют пользователям легко расширять систему: наследование, типы данных, функции.

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

Все эти особенности помещают PostgreSQL в категорию СУБД, известную как объектно-реляционные (object-relation). Заметим, что здесь есть отличие от тех объектно-ориентированных (object-oriented) СУБД, которые в основном поддерживают традиционные языки реляционных СУБД. Однако, PostgreSQL имеет некоторые объектно-ориентированные возможности, это важно в мире реляционных СУБД. Фактически, некоторые коммерческие СУБД только недавно заимели встроенные возможности, которые были открыты в PostgreSQL. На современном этапе PostgreSQL постоянно развивается, обновляется и совершенствуется, поэтому необходимо грамотное пользование, именно это обусловило актуальность рассмотрения темы.

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

В связи с этим, необходимо решить следующие задачи:

проследить историю развития;

рассмотреть основные особенности СУБД Postgre SQL;

изучить работу

оценить современные возможности Postgre SQL.

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

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

Глава первая описывает историю развития СУБД PostgreSQL и определяет основные понятия.

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

Третья глава рассматривает сферы применения.

Источниками информации для написания работы по теме послужили базовая учебная литература, статьи и обзоры в специализированных и периодических изданиях, посвященных теме " Система управления базами данных PostgreSQL", справочная литература, прочие актуальные источники информации.

1. Краткая история Postgre SQL

Объектно-реляционная СУБД теперь известная как PostgreSQL (и ранее называемая Postgres95) ведёт свое происхождение от пакета POSTGRES, который был написан в департаменте Беркли, Калифорнийского Университета. Более чем десятилетняя разработка PostgreSQL сделала этот продукт одной из наиболее продвинутых СУБД с открытым исходным кодом в мире, предлагая многоверсионное управление параллельным доступом, поддерживая практически все конструкции SQL (включая подзапросы, транзакции и определяемые пользователем типы и функции) и имея широкий диапазон языков, с помощью которых можно работать с СУБД (включая C, C++, Java, Perl, Tcl и Python).

Проект Postgre SQL департамента Беркли.

Реализация реляционной СУБД POSTGRES началась в 1986. Начальные концепции для этой системы были представлены в The design of POSTGRES, а определение начальной модели данных было осуществлено в The POSTGRES data model. Устройство системы управления на тот момент, было описано в The design of thePOSTGRES rules system. Обоснование архитектуры и менеджеры хранения были детально описаны в The design of the POSTGRES storage system.

Затем вышло несколько версий Postgres. Первая "demoware" система заработала в 1987 и была продемонстрирована в 1988 на Конференции ACM-SIGMOD. Версия 1, описанная в The implementation of POSTGRES была выпущена в июне 1989 года и могла работать с несколькими внешними пользователями. В ответ на критику первого варианта системы управления, был сделан следующий вариант (вариант A commentary on the POSTGRES rules system) был переделан как (On Rules, Procedures, Caching and Views in Database Systems) и Версия 2, выпущенная в Июне 1990 года была основана на новой системе управления. Версия 3 выпущенная в 1991, включала в себя поддержку нескольких менеджеров хранения, улучшенный обработчик запросов и вновь переписанную систему управления. Большинство следующих версий до появления Postgres95 были сфокусированы на вопросах переносимости и стабильности.

POSTGRES был использован для реализации многих различных исследований и написания приложений. Сюда вошли: система анализа финансовых данных, пакет мониторинга производительности струйных установок, база данных перемещений астероидов, база данных медицинской информации и несколько географических информационных систем. POSTGRES также использовался как средство обучения в нескольких университетах. Наконец компания Illustra Information Technologies (позднее влившаяся в компанию Informix, которой теперь владеет IBM.) взяла код этой СУБД и коммерциализировала его. POSTGRES стал приоритетным менеджером данных для проекта научных вычислений Sequoia 2000 после 1992 года.

Размер сообщества пользователей этого продукта удвоился в 1993 году. Стало весьма очевидно, что обслуживание прототипа кода и его поддержка занимают гораздо больше времени, чем сами исследования в области баз данных. Пытаясь снизить нагрузку, связанную с поддержкой, проект Беркли POSTGRES официально прекратил своё существование с выходом версии 4.2.

Postgres95.

В 1994, Эндрю Ю (Andrew Yu) и Джолли Чен (Jolly Chen) добавили в POSTGRES интерпретатор языка SQL. Затем Postgres95 был выложен в Интернет, чтобы найти свой собственный путь в мире продуктов с открытым исходным кодом, как потомок, основанный на оригинальном коде Беркли POSTGRES.

Postgres95 был полностью приведён к стандарту ANSI C и сократил свой размер на 25%. Были внесены многие внутренние изменения, которые увеличили производительность и обслуживаемость кода. Postgres95 версий 1.0.x был быстрее на 30-50% согласно Wisconsin Benchmark по сравнению с POSTGRES, Version 4.2. За исключением исправления ошибок, были сделаны следующие серьёзные расширения:

Язык запросов PostQUEL был заменен на SQL (реализованный в этом сервере). Подзапросы не поддерживались вплоть до выхода P), но в Postgres95 их можно было сымитировать с помощью функций SQL, определяемых пользователем. Агрегаты были переписаны. Также в запросы была добавлена поддержка GROUP BY. Интерфейс libpq остался доступным для программ на C.

В дополнении к программе monitor, была предоставлена новая программа (psql), которая использовала библиотеку GNU Readline и была предназначена для интерактивных SQL запросов.

Создана новая front-end библиотека, libpgtcl, поддерживающая клиентов, основанных на Tcl. Простая оболочка pgtclsh, предоставляющая новые команды Tcl для обеспечения взаимодействия Tcl программ и Postgres95.

Была тщательно пересмотрена работа с большими объектами. Инверсионные большие объекты представляли собой только механизм для хранения больших объектов. (Инверсионная файловая система была удалена).

Была удалена instance-level система управления. Правила были доступны как переписанные правила.

Вместе с исходным кодом стал поставляться краткий учебник по особенностям работы с SQL в Postgres95.

Для построения проекта стал использоваться GNU make (вместо BSD make). Также, Postgres95 был скомпилирован со стандартной версией GCC (выравнивание данных типа double было исправлено).

PostgreSQL.

В 1996 году было решено, что имя "Postgres95" не соответствует настоящему времени и было выбрано новое имя Postgre SQL, чтобы подчеркнуть отличие от оригинального POSTGRES и выход множества версий с поддержкой SQL. Также, вернули старую нумерацию версий, таким образом новая версия стартовала как 6.0.).

В 1997 был предложен слон в качестве логотипа. Слон был предложен Дэвидом Янгом в честь романа Агаты Кристи "Elephants can remember" (Слоны могут вспоминать). До этого, логотипом был бегущий леопард (ягуар)

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

Главные изменения в PostgreSQL включают:

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

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

Были добавлены возможности для обеспечения совместимости со стандартом SQL92, включая первичные ключи, идентификаторы запросов, literal string type coercion, создание типов, а также двоичный и шестнадцатеричный ввод целых чисел.

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

Скорость работы backend кода была увеличена приблизительно на 20-40%, а время запуска backend' было сокращено на 80% по сравнению с версией 6.0.

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

Когда говорят про базы данных, то сразу вспоминают принцип ACID: аттомарность (Аtomicity), консистентность (Consistency), локализация пользовательских процессов (Isolation) и устойчивость к ошибкам (Durability).

Для обеспечения совместной работы множества пользователей (concurrency), в целях следования заветам ACID PostgreSQL, использует систему управления версиями или MVCC (Multi-Version Concurrency Control). Каждому пользователю при подсоединении MVCC «подсовывает» свою версию или мгновенный снимок (snapshot) базы данных. В этом случае, изменения, производимые пользователем, невидимы другими пользователями до тех пор, пока текущая транзакция1(transaction) не подтверждается (commit). Кроме проблем, связанных с ACID, многоверсионность позволяет уменьшить или даже исключить во многих случаях необходимость запретов на изменение данных (locks) при чтении.

Надёжность (reliability) для сохранения данных является одним из основных показателей качества СУБД. Сохранение изменённых данных очень нетривиальная процедура. Всё дело в том, что диски очень медленные, поэтому прежде чем попасть на диск данные проходят через промежуточные буферы (cache), начиная от собственного кэша базы данных (shared buffers), заканчивая кэшом на самом диске. Никто не сможет гарантировать, что всё, что положено, окажется в безопасном постоянном хранилище в случае возникновения каких-либо проблем. Для максимального уменьшения вероятности потери данных PostgreSQL использует журнал транзакций или Write Ahead Log (WAL). Прежде чем записать данные о проведённой транзакции на диск, информация об изменениях пишется в WAL. Если что-то случилось, то данные можно восстановить по журналу. Если данные в журнал не попали, то соответственно исчезнет вся транзакция --жалко конечно, зато консистентность не нарушается. Следствием использования WAL является отсутствие необходимости «скидывать» данные на диск с помощью fsync, так как достаточно убедиться, что записан WAL. Это значительно увеличивает производительность в многопользовательской среде с множеством мелких запросов на изменение данных, так как записать один последовательный файл WAL гораздо проще, чем изменять множество таблиц по всему диску. В качестве бонуса журнал транзакций позволяет организовать непрерывное резервное копирование данных (on-line backup) --мечта администратора и возможность «отката» базы данных на любой момент в прошлом (point-in-time recovery) --своеобразная машина времени

Типы данных.

PostgreSQL поддерживает довольно много стандартных типов данных, как и положено базе данных. Более того, пользователь может определить свои собственные типы данных, если он не найдёт необходимых примитивов среди стандарта.

Числовые типы.

Обычные числовые (numeric) типы представлены целыми числами два (smallint), четыре (integer) или восемь байт длиной (bigint), числа с плавающей точкой в четыре (real) и восемь байт (double precision) длиной. Кроме обычных чисел, в случае плавающей точки поддерживаются значения Infinity, -Infinity и NaN --бесконечность (?), минус бесконечность (??) и «не число» (not-a-number), соответственно. PostgreSQL поддерживает числа с произвольной точностью numeric (precision,scale), где precision --число всех знаков в определяемой величине, а scale --число знаков в дробной части. PostgreSQL позволяет выполнять действия без накопления ошибки с подобными величинами с точностью вплоть до 1000 знаков. Не следует злоупотреблять этим типом данных, так как операции над подобными числами занимают очень много времени.

Битовые поля представлены типами bit(size) --битовая строка фиксированной длины size и bit varying (size) --битовая строка переменной длины с ограничением по размеру size.

К числовым типам PostgreSQL относятся и «псевдотипы» serial и bigserial. Эти типы соответствуют типам integer и bigint за исключением того, что при записи новых данных в таблицу с колонкой этого типа, значение по умолчанию в ней увеличивается на единицу --автоматически создаваемая упорядоченная последовательность.

Символьные типы.

В стандарте SQL символьный тип определяется как строка определённой длины character(size), где size --длина строки. В дополнение к стандарту, PostgreSQL поддерживает строки переменной длины с ограничением varchar (size) и без ограничения -- text.

Бинарные типы.

Бинарную строку можно сохранить используя тип bytea. SQL предполагает, что вся информация передаётся как текст, поэтому при передачи данных следует экранировать некоторые из символов

В PostgreSQL есть специальный тип данных Large Objects. По сути дела, это просто возможность сохранять любые файлы размером вплоть до 2 Гб прямо в базе данных. Операции с подобными объектами выходят за рамки SQL. Для доступа к Large Objects есть специальный программный интерфейс по образу и подобию обычного чтения/записи файла.

Типы даты/времени.

Временем в PostgreSQL заведует тип timestamp или timestamp with time zone--может сохранить дату и время начиная с 4713 г. до н.э. вплоть до 5874897 г. с точностю в одну микросекунду (µс), занимает восемь байт. Второй упомянутый тип включает часовой пояс и позволяет автоматически учитывать переход на летнее/зимнее время. С таким диапазоном и точность проблема типа распиаренной «проблемы 2000 года» случится не скоро. Разница между двумя датами хранится в столбце типа interval --двенадцать байт, поэтому можно хранить информацию о событиях связанных с рождением и смертью вселенной.

Так же есть отдельный тип для календарного времени (date) и просто для времени (time или time with timezone).

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

db=> ?? узнаём текущее время с точностью до секунды

db=>select date_trunc( 'seconds ' ,timestamp with time zone 'now' );

date_trunc 2006?08?26 21:08:14+07

В этом случае, никогда не ошибёшься в порядке следования месяца и дня не зависимо от того, какая локаль используется.

Для типа timestamp определены дополнительные константы:

epoch --начало эпохи с точки зрения юниксового времени (четырёхбайтовый

time_t) 1970-01-01 00:00:00+00

infinity --позже, чем любое возможное из времён,

infinity -- раньше, чем любое возможное из времён,

now -- здесь и сейчас,

today --сегодняшняя полночь, аналогично есть

yesterday --вчерашняя полночь и,

tomorrow --завтрашняя полночь.

Логические типы.

Логические типы представлены типом boolean. Логично, что он содержит значения либо TRUE ('t', 'true', 'y','yes', '1')-- «истина», либо FALSE ('f', 'false', 'n', 'no','0')-- «ложь» . Всё просто, за исключением одного «но»-- есть ещё одна возможность: «значение не определено» (NULL). Собственно говоря, это не особенность типа boolean. С тем что значение может быть не определено при использовании SQL необходимо считаться всегда и везде.

Остальные стандартные типы.

К оставшимся стандартным типам относятся различные геометрические типы данных: типы точки (point), линии (line), отрезка (lseg), прямоугольник (box), пути (path), замкнутого пути (polygon) и окружности (circle). Для системных администраторов будут интересны стандартные типы сетевых IPv4 и IPv6 адресов (cidr или inet) и тип МАС-адреса (macaddr).

Более сложные типы реализуются как дополнения. Яркими примерами служат поддержка географических объектов GIS (http://postgis.refractions.net/) и иерархический тип данных ltree (contrib/ltree). .

Определение пользовательских типов.

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

db=> ??? создаём массив для игры Тик?Так

db=> create table tictactoe ( squares integer [ 3 ] [ 3 ] ) ;

db=> ??? |x00| x = 1 , 0 = ?1

db=> ??? |0xx| вставляем информацию о варианте игры

db=> ??? |x| крестики начинают и выигрывают

db=> insert into tictactoe

db?>values ( '{{1,?1,?1},{?1,1,1},{0,0,1}} ' );

db=> ??? распечатываем сохранённую позицию

db=> select ? from tictactoe ;

squares

?? ????????????????????????????

{{1,?1,?1},{?1,1,1},{0,0,1}}

db=> ?? распечатываем значение первого столбца

db=> select squares [ 1 : 3 ] [ 1 : 1 ] from tictactoe ;

squares

?? ??????????????

{{1},{?1},{0}}

Композитный тип (composite type) представляет из себя аналог структуры:

db=> CREATE TYPE complex AS (Re real ,Im real );

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

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

Функции.

Все стандартные типы имеют свои функции, ведь если есть тип, то с ним нужно работать. Число стандартных функций велико и разнообразно. Одних операторов поиска с использованием регулярных выражений целых три штуки: собственное расширение PostgreSQL (LIKE и ILIKE), оператор соответствующий SQL стандарту SIMILAR TO) и POSIX-совместимый оператор. Всё, что только можно было быстро придумать, уже реализовано. А более сложные случаи, например, модуль для полнотекстового поиска tsearch2 (contrib/tsearch2) в процессе совершенствования. Придумать что-то выходящее за рамки стандарта тяжело. В этом случае, всегда есть возможность создать свои функции. При желании, ссылаясь на уже имеющуюся функцию, с помощью команды CREATE OPERATOR можно определить оператор для своих типов.

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

Для создания новых функций используется оператор CREATE FUNCTION --вполне предсказуемо. Создаваемые таким образом функции исполняются и хранятся на сервере, отсюда и название--«хранимые процедуры»:

db=> ?? Создаём и заполняем таблицу

db=> create table AplusB (A integer , B integer );

db=> insert INTO AplusB VALUES (1 ,1);

db=> insert INTO AplusB VALUES (2 ,2);

db=> insert INTO AplusB VALUES (3 ,3);

db=> ??Создаём новую функцию

db=> CREATE FUNCTION plus ( integer , integer ) RETURNS integer

db?>LANGUAGE SQL as 'SELECT?$1?+?$2; ' ; CREATE FUNCTION

db=> select A,B, plus (A,B) from AplusB ;

a b plus

?? ???+?????+????? ?

1 1 2

2 2 4

3 3 6

(записей : 3)

PostgreSQL поддерживает перегрузку функций. Объектно-ориентированность имеет свои плюсы. Кроме SQL для создания новых функций можно использовать процедурные языки программирования. Для начал работы с процедурным языком его необходимо инициализировать. По умолчанию из соображения безопасности интерфейсы к другим языкам кроме SQL и C недоступны. Для инициализации используется команда createlang. Запустить её может только администратор базы данных --тот, кто имеет право создавать базы:

# Инициализируем язык PL/pgSQL для базы данных db

> createlang plpgsql db

# делаем то же самое , но для языка PL/Perl

> createlang plperl db

Теперь можно создавать функции с использованием всех прелестей процедурного программирования, вместе с циклами, кои по понятной причине в SQL отсутствуют. Ниже продублирована простейшая функция, которая была описана выше, но теперь уже на PL/pgSQL и на PL/Perl:

db=> ??Создаём новую функцию с использование PL/pgSQL

db=>CREATE FUNCTION pgsql_plus ( integer , integer ) RETURNS integer

db?>LANGUAGE PLPGSQL as 'BEGIN?return?$1+$2;?END; ' ;

CREATE FUNCTION

db=> ??Создаём новую функцию с использование PL/Perl

db=>CREATE FUNCTION perl_plus ( integer , integer ) RETURNS integer

db?>LANGUAGE PLPERL AS 'return?$_[0]+$_[1] ' ; CREATE FUNCTION

db=> ??Проверяем , что всё работает

db=>SELECT pgsql_plus (A,B) FROM AplusB ;

db=>SELECT plus (A,B) , pgsql_plus (A,B) , perl_plus (A,B) from AplusB ;

plus | pgsql_plus | perl_plus

?? ????+????????????+??????????

2 | 2 | 2 |

4 | 4 | 4 |

6 | 6 | 6 | |

(записей : 3)

В стандартной документации подробно описаны идущие вместе с дистрибутивом языки PL/pgSQL, PL/Tcl, PL/Perl, PL/Python и, естественно, C/C++ с SQL. Кроме перечисленных есть поддержка.

PL/PHP http://plphp.commandprompt.com/,

PL/java http://gborg.postgresql.org/project/pljava/projdisplay.php,

PL/R http://www.joeconway.com/plr/,

PL/Ruby http://raa.ruby-lang.org/project/pl-ruby,

PL/sh http://plsh.projects.postgresql.org/.

Так же есть возможность подключения своего любимого языка.

Триггеры.

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

CREATE TRIGGER «имя триггера»

{ BEFORE | AFTER } { «событие» [ OR . . .] }

ON «имя таблицы» [ FOR [ EACH ] { ROW | STATEMENT } ]

EXECUTE PROCEDURE «исполняемая функция - реакция»

Реакция на «событие», (вставкой INSERT, изменение UPDATE или удаление DELETE) может производится по выбору до (BEFORE) или после (AFTER) изменения данных. Выполнение процедуры может производиться для каждой записи (ROW) или для каждого запроса (STATEMENT). Для показательного примера создания триггера возьмём следующую выдуманную задачу: при изменении данных в описанной уже таблице AplusB сумма A и B должна автоматически обновляться в таблице ABresult. Следующее решение чрезвычайно не оптимально, зато работает:

db=> ?? Создаём «результирующую» таблицу

db=> create table ABresult ( result integer );

db=> ?? Создаём функцию, очищающую ABresult и

db=> ?? заполняющую всё суммой A и B из AplusB .

db=> create function ABsumm() returns trigger as

db?> 'BEGIN

db'> delete from ABresult ;

db'> insert into ABresult values (AplusB .A+AplusB .B);

db'> return NULL;

db'> END;'

db?> language 'plpgsql ' ;

db=> ?? Создаём триггер

db=> CREATE TRIGGER makeABresult

db=>AFTER INSERT or UPDATE or DELETE on AplusB

db=>FOR EACH STATEMENT execute procedure ABsumm();

CREATE TRIGGER

db=> ?? Добавляем данных в таблицу AplusB

db=> insert into AplusB VALUES (100 ,200);

db=> ?? проверяем , что триггер сработал

db=> select ? from AplusB , ABresult where A+B=result ;

a | b | result

?? ???+?????+???????

1 | 1 | 2

2 | 2 | 4

3 | 3 | 6

100 | 200 | 300

(записей : 4)

Правила.

Кроме триггеров PostgreSQL обладает ещё одним способом управления реакции СУБД на запросы--это Rules или «правила». Для создания «правил» используется команда CREATE RULE. Основным отличием «правила» от триггера в том, что триггер --это реакция системы на изменение данных, а «правило» позволяет изменять сам запрос, в том числе и запрос на получение данных (SELECT). В частности одно из довольно удобных расширений PostgreSQL --представление или виртуальная таблица (view), реализовано с помощью «правил».

Индексы.

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

Создание индексов --это ответственность создателя БД. Создание индекса, как можно догадаться, производится с помощью команды CREATE INDEX:

CREATE [UNIQUE] INDEX «имя индекса» ON table [USING «алгоритм»]

( { «имя столбца» | ( «выражение» ) } [ ,. . . ])

[ WHERE «условие» ]

Индекс при желании может быть уникальным (UNIQUE). В этом случае, при создании индекса и при добавлении данных, накладывается дополнительное требование на уникальность параметра, по которому создаётся индекс.

При создании индекса можно выбрать алгоритм, по которому создаётся индекс. По умолчанию выбирается B-tree, но можно ещё указать hash, R-tree или GiST. Алгоритм GiST (http://www.sai.msu.su/~megera/postgres/gist/) был создан на пару Олегом Бартуновым и Фёдором Сигаевым. GiST является не просто ещё одним алгоритмом--это целый конструктор, позволяющий создавать индексы для принципиально новых типов данных. В версии 8.2 PostgreSQL опять же благодаря Олегу и Фёдору был добавлен ещё один метод GIN, а в 8.3 ожидается добавление bitmap-индекса. По алгоритмам создания индексов PostgreSQL одна из самых продвинутых СУБД.

Индекс можно создавать по какому-то из столбцов--самый простой метод. Также при указании нескольких колонок создаются многоколоночные индексы. Особо следует отметить возможность создания функциональных индексов --в качестве индексы указывается функция от данных таблицы. С помощью функциональных индексов можно реализовать ещё один алгоритм индексации: Reverse index (обращает поле переменной --первый символ считается последним).

Условие (WHERE) при создании индекса позволяет создавать частичные индексы (partial indices). Это полезно в случае если в столбце, по которому создаётся индекс, большинство значений одинаково и поиск надо производить по редким значениям.

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

Целостность данных.

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

Транзакции.

Транзакция --это единый блок операций, который нельзя разорвать. Либо совершается весь блок, либо всё отменяется. PostgreSQL в условиях параллельного доступа распространяет информацию об операциях только по завершению транзакции. Транзакция начинается с оператора BEGIN и заканчивается оператором COMMIT (подтверждение транзакции) или ROLLBACK (отмена транзакции). Возможен режим, когда каждый запрос сам себе транзакция, например, такой режим по умолчанию используется в psql. Для отмены этого режима достаточно набрать BEGIN;. Неудобством при использовании транзакций является то, что в случае ошибки какого-то из запросов приходится отменять всю транзакцию. Для устранения этого недостатка в 8ой версии PostgreSQL были добавлены точки сохранения (savepoints).

db=> ?? начинаем транзакцию

db=> BEGIN;

db=> ?? здесь идёт блок операторов , который удачно завершается

db=> ?? ставим метку

db=> SAVEPOINT savepoint_one ;

db=> ?? здесь идёт блок операторов , в котором произошла ошибка

db=> ?? откатываемся до установленной метки ,

db=> ?? а не отменяем всю транзакцию

db=> ROLLBACK TO savepoint_one ;

db=> ?? повторяем последний блок

db=> ?? завершаем транзакцию

db=> COMMIT;

db=> ?? всё , теперь изменения доступны всем

Ограничения.

Целостность данных обеспечивается не только многоверсионностью PostgreSQL, но и «архитектором» таблиц базы данных. При создании таблицы (CREATE TABLE) или позже можно всегда создать ограничение (CONSTRAINT) на диапазон записываемых в таблицу данных. Это может могут простые арифметические условные выражения, требования уникальности (UNIQUE или PRIMARY KEY), так и более сложные ограничения в виде внешних ключей (FOREIGN KEY).

Если какой-то столбец A является внешним ключом (FOREIGN KEY) по отношению к столбцу B (REFERENCES), то это означает, что только данные представленные в столбце B могут появиться в качестве значений столбца A. В случае внешних ключей PostgreSQL осуществляет автоматический контроль ссылочной целостности3. Это довольно интересный механизм, который, например, позволяет моделировать иерархические структуры.

Блокировки.

Так как пользователь в условиях параллельного доступа к базе данных работает со своим мгновенным снимком (следствие MVCC), то в принципе можно придумать ситуацию, когда полученные данные устаревают, так как во время получения, они были изменены. Если это важно, то PostgreSQL предоставляет полный ассортимент блокировок. С помощью команды LOCK можно заблокировать таблицу, а инструкция SELECT FOR UPDATE позволяет заблокировать отдельные записи. Следует учитывать, что использование блокировок увеличивает шанс взаимной блокировки (deadlock). PostgreSQL умеет определять случаи возникновения взаимной блокировки и разрешать их путём прекращения одной из транзакций, но на это уходит время.

3.Сферы применения Postgre Sql сегодня

Если изначально POSTGRES использовался в основном в академических проектах для исследования алгоритмов баз данных, в университетах как отличная база для обучения, то сейчас PostgreSQL применяется практически повсеместно. Например, зоны .org, .info полностью обслуживаются PostgreSQL, известны многотерабайтные хранилища астрономических данных, Lycos, BASF. Из российских проектов, использующих PostgreSQL, наиболее известными является портал Рамблер, федеральные порталы Минобразования.

Впрочем, ничто не мешает использовать эту СУБД и для web-приложений, например, форума или галереи изображений.

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

Версия 8.1 является новым шагом в сторону больших и нагруженных систем, предназначенных для непрерывной работы в режиме 24x7x365. Это подтверждается тем, что большие компании начинают использовать PostgreSQL в реальном бизнесе. Так, Sony Online Entertainment объявила [SOE05] об инвестировании 1.5 млн. USD в Enterprise DB для перехода с Oracle на PostgreSQL 8.1.

В России крупнейший оператор сотовой связи компания Вымпелком (Beeline) тестирует ПО работающее с PostgreSQL и находится на стадии заключения контракта на поддержку кластера PostgreSQL. Компания Sun Microsystem объявила [SUN05] об официальной поддержке PostgreSQL (входит в Solaris 10), "beta" версия пакетов, оптимизированных для Solaris, уже доступна [SUN06]. Кроме этого, Sun поддерживает PostgreSQL в режиме 24x7.

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

PostgreSQL неоднократно признавалась базой года, например, Linux New Media AWARD 2004, 2003 Editors' Choice Awards, 2004 Editors' Choice Awards.

Традиционно, PostgreSQL широко используется в научных проектах. Так был запущен проект SAI CAS (Catalog Access Service), в рамках международной программы Virtual Observatory (Виртуальная Обсерватория), как часть проекта Астронет, ориентированного на профессиональное астрономическое сообщество и где в качестве СУБД для работы с очень большими астрономическими каталогами (1Tb), используется PostgreSQL 8.1. Сервер БД HP rx1620 (Itanium2) был предоставлен HP Russia

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

Заключение

postgre база данные потеря

Завершая работу, можно прийти к выводу, что SQL - это высокоуровневый язык запросов, предназначен для работы с базами данных.

Она позволяет модифицировать данные, составлять и выполнять запросы, выводить результаты в виде отчетов.

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

Также было выяснено, что сильными сторонами PostgreSQL считаются:

поддержка БД практически неограниченного размера;

мощные и надёжные механизмы транзакций и репликации;

расширяемая система встроенных языков программирования: в стан дартной поставке поддерживается PL/pgSQL, PL/Perl, PL/Python и PL/Tcl;

дополнительно можно использовать PL/Java, PL/PHP, PL/Py, PL/R, PL/Ruby, PL/Scheme, PL/sh и PL/V8,

а также имеется поддержка загрузки C совместимых модулей[];

наследование;

легкая расширяемость.

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

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

1. http://www.postgresql.org/docs/

2. Клим Б.В. Конспект лекций по предмету “Базы данных”

3. В.В. Кириллов Основы проектирования реляционных баз данных. Учебное пособие. - СПб.: ИТМО, 1994.

4. М. Мейер Теория реляционных баз данных. - М.: Мир, 1987.

5. PostgreSQL Reference Manual - Volume 1: SQL Language Reference The PostgreSQL Global Development Group, 2007.

Размещено на Allbest.ru


Подобные документы

  • Программные продукты компании Microsoft: Access, Visual FoxPro7.0, dBASE. Возможности интеграции, совместной работы и использования данных. Системы управления базами данных (СУБД), их основные функции и компоненты. Работа с данными в режиме таблицы.

    курсовая работа [805,5 K], добавлен 15.12.2010

  • Система управления базами данных как составная часть автоматизированного банка данных. Структура и функции системы управления базами данных. Классификация СУБД по способу доступа к базе данных. Язык SQL в системах управления базами данных, СУБД Microsoft.

    реферат [46,4 K], добавлен 01.11.2009

  • Структура и функции системы управления базами данных (СУБД). Управление хранением данных и доступом к ним. Защита и поддержка целостности данных. Надежность хранения данных во внешней памяти. Классификация СУБД по способу доступа к базе данных.

    презентация [3,7 M], добавлен 05.06.2014

  • Понятие и сущность базы данных, их классификация и характеристика. Системы управления базами данных. СУБД структуры "сервер-клиент", его суть. Microsoft Access - функционально полная реляционная СУБД. Предназначение СУБД Access, и описание ее работы.

    реферат [44,3 K], добавлен 27.02.2009

  • Логическая организация данных, файловая модель. Сетевые, иерархические и реляционные модели данных. Системы управления базами данных, их определения и основные понятия. История, тенденции развития, классификация СУБД, свойства и технология использования.

    дипломная работа [51,3 K], добавлен 26.07.2009

  • Назначение и основные функции системы управления базами данных СУБД, особенности и признаки их классификации. Архитектура баз данных (БД). Разработка распределенных БД. Язык структурированных запросов (SQL). Правила Кодда: требования к реляционным БД.

    курсовая работа [376,2 K], добавлен 21.07.2012

  • Краткая история развития СУБД ORACLE, основные понятия и определения, архитектура. Принципы работы с СУБД ORACLE. Разработка баз данных, средства и технологии их реализации; возможности процедурного языка PL/SQL. Приемы администрирования СУБД ORACLE.

    презентация [609,2 K], добавлен 14.02.2014

  • Системы управления базами данных в медицине. Основные идеи, которые лежат в основе концепции базы данных. Требования, предъявляемые к базам данных и системе управления базами данных. Архитектура информационной системы, организованной с помощью базы данных

    реферат [122,5 K], добавлен 11.01.2010

  • Характеристика системы управления базами данных. Принципы классификации СУБД. NoSQL как ряд подходов, проектов, направленных на реализацию моделей баз данных. Методологические обоснования подхода NoSQL. Описание некоторых СУБД из данного движения.

    реферат [18,1 K], добавлен 06.10.2011

  • Предпосылки появления и история эволюции баз данных (БД и СУБД). Основные типы развития систем управления базами данных. Особенности и черты Access. Создание и ввод данных в ячейки таблицы. Сортировка и фильтрация. Запрос на выборку, основные связи.

    презентация [1,2 M], добавлен 01.12.2015

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.