СУБД Postgre SQL. История, современные возможности

Автор работы: Пользователь скрыл имя, 18 Января 2015 в 23:26, курсовая работа

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

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

Содержание работы

Введение………………………………………………………….…………3
1. Краткая история POSTGRE SQL. 6
1.1. Проект Postgre SQL департамента Беркли. 6
1.2. . Postgres95. 7
1.3. . PostgreSQL. 9
2. Основные возможности и функциональность. 11
2.1. Типы данных. 12
2.1.1. Числовые типы. 12
2.1.2. Символьные типы. 13
2.1.3. Бинарные типы. 13
2.1.4. Типы даты/времени. 13
2.1.5. Логические типы. 14
2.1.6. Остальные стандартные типы. 15
2.1.7. Определение пользовательских типов. 15
2.2. Функции. 17
2.2.1. Хранимые процедуры. 17
2.2.2. Триггеры. 20
2.2.3. Правила. 22
2.3. Индексы. 22
2.4. Целостность данных. 24
2.4.1. Транзакции. 24
2.4.2. Ограничения. 25
2.4.3. Блокировки. 26
3. Сферы применения Postgre SQL сегодня. 27
Заключение 30
Список использованной литературы 31

Файлы: 1 файл

курсовая_работа испр.docx

— 312.69 Кб (Скачать файл)

Содержание

. Введение………………………………………………………….…………3

 

 

Введение

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

    1. Проект 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.

    1. .  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 было исправлено).
    1. .  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.
    •  
  1. основные возможности и функциональность.

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

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

Обычные числовые (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.

Информация о работе СУБД Postgre SQL. История, современные возможности