Ирина Эланс

Автор который поможет с любыми образовательными и учебными заданиями

Об’єктно-реляційна система управління базами даних PostgreSQL

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

КРЕМЕНЧУЦЬКИЙ НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ

ІМЕНІ МИХАЙЛА ОСТРОГРАДСЬКОГО

ФАКУЛЬТЕТ ЕЛЕКТРОНІКИ ТА КОМП’ЮТЕРНОЇ ІНЖЕНЕРІЇ

КАФЕДРА ІНФОРМАТИКИ І ВИЩОЇ МАТЕМАТИКИ

КУРСОВА РОБОТА

З ДИСЦИПЛІНИ «БАЗИ ДАНИХ ТА ІНФОРМАЦІЙНІ СИСТЕМИ»

ТЕМА: «Об’єктно-реляційна система управління базами даних PostgreSQL»

ЗАВІДУВАЧ КАФЕДРИ В.П. Ляшенко

КЕРІВНИК РОБОТИ А.І. Дерієнко

ВИКОНАЛА студентка групи І-11-1

Роман О.В.

КРЕМЕНЧУК 2014

РЕФЕРАТ

Пояснювальна записка до курсової роботи: 34 сторінки, 11 рисунків, 8 літературних джерел.

Метою роботи є вивчення об’єктно-реляційної моделі даних та її особливостей. Об’єкт дослідження – об’єктно-реляційна модель даних, а предмет – реалізація бази даних факультету на основі цієї моделі.

Дослідження об’єктно-реляційної моделі та власне побудова бази даних проводилися в інструментальній системі управління базами даних PostgreSQL.

Практичним результатом даної роботи є готова функціонуюча база даних факультету, що має у підпорядкуванні кілька кафедр, на яких працюють викладачі, викладаючи різні предмети різним академічним групам. Кожен зі студентів групи отримує оцінки з різних предметів, які також фіксуються у базі. База даних заповнена реальними даними, протестована та готова для роботи.

РЕФЕРАТ

Пояснительная записка к курсовой работе: 34 страницы, 11 рисунков, 8 литературных источников.

Целью работы является изучение объектно-реляционной модели данных и ее особенностей. Объект исследования – объектно-реляционная модель данных, а предмет – реализация базы данных факультета на основе этой модели.

Исследования объектно-реляционной модели и собственно построение базы данных проводились в инструментальной системе управления базами данных PostgreSQL.

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

ЗМІСТ

ЗАВДАННЯ ДО КУРСОВОЇ РОБОТИ6

ВСТУП7

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

1.1 Основні функції9

1.2 Класифікація СУБД9

1.2.1 По моделі даних9

1.2.2 За ступенем роздрібненості14

1.2.3 За способом доступу до БД14

2 Об’єктно-реляційна система управління базами даних PostgreSQL17

2.1 Історія розвитку17

2.2 Основні можливості18

2.2.1 Функції18

2.2.2 Тригери18

2.2.3 Правила і представлення19

2.2.4 Індекси19

2.2.5 Механізм «Multiversion Concurrency Control»20

2.2.6 Типи даних20

2.2.7 Користувальницькі об’єкти21

2.2.8 Наслідування21

2.2.9 Інші можливості22

2.2.10 Надійність22

3 Реалізація бази даних факультету засобами ОРСУБД PostgreSQL23

3.1 Постановка задачі23

3.2 Розробка бази даних24

3.2.1 Концептуальна модель даних24

3.2.2 Фізична модель даних25

3.3 Тестування БД30

ВИСНОВКИ33

ПЕРЕЛІК ПОСИЛАНЬ34

ВСТУП

Сприйняття реального світу будується як послідовність різних, іноді і взаємозалежних, явищ. Ще в давнину люди різними способами описували ці явища, часто навіть не розуміючи їх суті. Сьогодні цей опис називається даними. До даних відносяться: факти, явища, події, ідеї чи предмети.

Фіксація даних традиційно відбувається через конкретні засоби спілкування – природної мови чи зображень, на конкретному носії: камені чи папері. Враховуючи той факт, що природна мова володіє достатньою гнучкістю, дані та їх інтерпретація (семантика) фіксуються спільно. Наприклад, розглянемо твердження "Вартість квитка на електричку 147". Тут "147" – дане, а "Вартість квитка на електричку" – його семантика.

Дуже часто дані та інтерпретація розділяються. Наприклад, "Розклад руху поїздів" подається у вигляді таблиці, в якій у верхній частині окремо від даних буде наведена їх інтерпретація, а це ускладнює роботу з даними і призводить до складності отримання відомості з нижньої частини таблиці.

Поділ даних та інтерпретації стає ще більш відчутним, коли ЕОМ застосовується для введення й обробки даних. Це відбувається тому, що ЕОМ може мати справу тільки з даними. Велика частина інформації, що інтерпретується, не фіксується в явній формі (ЕОМ не "розуміє", "22.50" є вартістю авіаквитка або часом вильоту). Чому так відбувається?

Існують як мінімум дві історичні причини, що сприяють тому, що активне використання ЕОМ сприяло тому, що відбулося розділення даних та інтерпретації:

ЕОМ не мала достатніх можливостей, щоб обробляти тексти природною мовою – переважно мовою інтерпретації даних;
висока вартість пам'яті ЕОМ.

Пам'ять використовували для того, щоб зберігати самі дані, а інтерпретацією займалися безпосередньо користувачі. Процес виглядав наступним чином, інтерпретацію даних закладали в програму, яка "розуміла", наприклад, що п'яте введене значення пов'язане з часом прибуття поїзда, а шосте – з часом його відправлення. Така послідовність дій робила програму незамінною, бо без інтерпретації дані – лише сукупність бітів на запам'ятовуючому пристрої.

Всі серйозні проблеми, які виникають при введенні даних, пов'язані з тим, що між даними і програмами, які використовують їх, існує дуже міцний зв'язок.

Як показує практика, спільне використання одних і тих же даних, приносить масу проблем. Наприклад, дуже часто буває так, що при використанні однієї і тієї ж ЕОМ користувачами створюються і використовуються в програмах різні набори даних, що містять подібну інформацію. Це можна пояснити тим, що користувач просто не має інформації про те, що співробітник, який працює поруч, давно ввів в ЕОМ потрібні дані.

Дуже зручно при використанні, коли розробники прикладних програм, розміщують потрібні їм дані у файлах. Треба враховувати, що однакові дані в різних додатках відрізняються організацією, тобто володіють різною послідовністю розміщення в запису, різні формати одних і тих же полів і т.п. Тому узагальнити всі дані дуже складно. Це пов'язано з тим, що якщо один розробник виробляє зміну структури запису файлу, то й інший розробник повинен провести зміни в програмах, що використовують записи цього файлу.

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

СИСТЕМА УПРАВЛІННЯ БАЗАМИ ДАНИХ

1.1 Основні функції

Система управління базами даних – сукупність програмних і лінгвістичних засобів загального або спеціального призначення, що забезпечують управління створенням та використанням баз даних.

Основними функціями СУБД є:

керування даними, що знаходяться в зовнішній пам'яті (на дисках);
керування даними, що знаходяться в оперативній пам'яті з використанням дискового кеша;
запис змін до журналу, резервне копіювання і відновлення бази даних після збоїв;
підтримка мов БД (мова визначення даних, мова маніпулювання даними).

Зазвичай сучасна СУБД містить наступні компоненти:

ядро, яке відповідає за управління даними у зовнішній і оперативній пам'яті, та журналізацію;
процесор мови бази даних, що забезпечує оптимізацію запитів на вилучення та зміну даних і створення, як правило, машинно-незалежного виконуваного внутрішнього коду;
підсистему підтримки часу виконання, яка інтерпретує програми маніпуляції даними, створюють користувальницький інтерфейс з СУБД;
а також сервісні програми (зовнішні утиліти), що забезпечують ряд додаткових можливостей по обслуговуванню інформаційної системи.

1.2 Класифікація СУБД

1.2.1 За моделлю даних

За моделлю даних СУБД поділяються на:

ієрархічні;
мережеві;
реляційні;
об’єктно-орієнтовані;
об’єктно-реляційні.

Ієрархічні СУБД підтримують деревоподібну організацію інформації. Зв'язки між записами виражаються у вигляді відносин предок/нащадок, а у кожного запису є рівно один батьківський запис. Це допомагає підтримувати посилальну цілісність. Коли запис видаляється з дерева, всі його нащадки також повинні бути видалені. Ієрархічні бази даних мають централізовану структуру, тобто безпеку даних легко контролювати. На жаль, певні знання про фізичний порядок зберігання записів все ж необхідні, так як відносини предок/нащадок реалізуються у вигляді фізичних покажчиків з одного запису на інший. Це означає, що пошук запису здійснюється методом прямого обходу дерева. Записи, розташовані в одній половині дерева, шукаються швидше, ніж в іншій. Звідси випливає необхідність правильно впорядковувати записи, щоб час їх пошуку був мінімальним. Це важко, так як не всі відносини, що існують в реальному світі, можна виразити в ієрархічній базі даних. Відношення "один до багатьох" є природними, але практично неможливо описати відносини "багато до багатьох" або ситуації, коли запис має кілька предків. До тих пір поки в додатках будуть кодуватися відомості про фізичну структуру даних, будь-які зміни цієї структури будуть загрожувати перекомпіляцією.

Мережеві розширюють ієрархічну модель СУБД, дозволяючи групувати зв'язки між записами у множину. З логічної точки зору зв'язок – це не сам запис. Зв'язки лише виражають відносини між записами. Як і в ієрархічній моделі, зв'язки ведуть від батьківського запису до дочірнього, але на цей раз підтримується множинне спадкування. Слідуючи специфікації CODASYL, мережева модель підтримує DDL (Data Definition Language – мова визначення даних) і DML (Data Manipulation Language – мова обробки даних). Це спеціальні мови, призначені для визначення структури бази даних і складання запитів. Незважаючи на їх наявність програміст раніше повинен знати структуру бази даних.

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

Програмісту не потрібно, при проектуванні СУБД, піклуватися про те, як організовується фізичне зберігання даних на диску. Це послаблює залежність додатків і даних. Але у мережевій моделі потрібно, щоб програміст пам'ятав структуру даних при формуванні запитів. Оптимальну структуру бази даних складно сформувати, а готову структуру важко змінювати. Якщо вигляд таблиці зазнає зміни, всі відносини з іншими таблицями повинні бути встановлені заново, щоб не порушилася цілісність даних. Складність такого завдання призводить до того, що програмісти часто скасовують деякі обмеження цілісності заради спрощення додатків.

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

Реляційна модель бази даних являє собою централізоване сховище таблиць, що забезпечує безпечний доступ до інформації з боку багатьох користувачів. У рядках таблиць частина полів містить дані, стосовні безпосередньо до запису, а частина - посилання на записи інших таблиць. Таким чином, зв'язки між записами є невід'ємною властивістю реляційної моделі.

Кожен запис таблиці має однакову структуру. Наприклад, у таблиці, що містить описи автомобілів, у всіх записів буде один і той же набір полів: виробник, модель, рік випуску, пробіг і т.д. Такі таблиці легко зображувати в графічному вигляді.

У реляційній моделі СУБД досягається інформаційна та структурна незалежність. Записи не пов'язані між собою настільки, щоб зміна однієї з них торкнулася іншої, а змінена структура СУБД не обов'язково призводить до перекомпіляції працюючих з нею додатків. У реляційних СУБД використовується мова SQL, що дозволяє формулювати довільні, нерегламентовані запити. Це мова четвертого покоління, тому будь-який користувач може швидко навчитися складати запити. До того ж, існує безліч програм, що дозволяють будувати логічні схеми запитів в графічному вигляді. Все це відбувається за рахунок посилення вимог до продуктивності комп'ютерів. На щастя, сучасні обчислювальні потужності більш ніж адекватні.

Реляційні бази даних страждають від відмінностей у реалізації мови SQL, хоча це і не проблема реляційної моделі. Кожна реляційна СУБД реалізує якусь частину стандарту SQL і набір унікальних команд, що ускладнює завдання програмістам, які намагаються перейти від однієї СУБД на іншу. Доводиться робити нелегкий вибір між максимальною експортністю і максимальною продуктивністю. У першому випадку потрібно дотримуватися мінімального загального набору команд, підтримуються у кожній СУБД. У другому випадку програміст просто зосереджується на роботі в даній конкретній СУБД, використовуючи переваги її унікальних команд і функцій СУБД [1].

Об'єктно-орієнтовані СУБД дозволяють програмістам, які працюють з мовами третього покоління, інтерпретувати всі свої інформаційні сутності як об'єкти, що зберігаються в оперативній пам'яті. Додатковий інтерфейсний рівень абстракції забезпечує перехоплення запитів, що звертаються до тих частин бази даних, які знаходяться в постійному сховищі на диску. Зміни, що вносяться в об'єкти, оптимальним чином переносяться з пам'яті на диск. Перевагою ООСУБД є спрощений код. Програми отримують можливість інтерпретувати дані в контексті мови програмування, на якому вони написані. Реляційна база даних повертає значення всіх полів в текстовому вигляді, а потім вони приводяться до локальних типів даних. У ООБД цей етап ліквідовано. Методи маніпулювання даними завжди залишаються однаковими незалежно від того, чи знаходяться дані на диску або в пам'яті.

Дані в ООСУБД здатні прийняти вигляд будь-якої структури, яку можна висловити на використовуваній мові програмування. Відносини між сутностями також можуть бути довільно складними. ООБД керує кеш-буфером об'єктів, переміщуючи об'єкти між буфером і дисковим сховищем по мірі необхідності.

З допомогою ООСУБД вирішуються дві проблеми. По-перше, складні інформаційні структури виражаються у них краще, ніж у реляційних базах даних, а по-друге, усувається необхідність транслювати дані з формату, який підтримується в СУБД. Наприклад, в реляційній СУБД розмірність цілих чисел може становити 11 цифр, а у використовуваній мові програмування – 16. Програмісту доведеться враховувати цю ситуацію[4].

Об'єктно-орієнтовані СУБД виконують багато додаткових функцій. Це вигідно, якщо відносини між даними дуже складні. В такому випадку продуктивність ООСУБД виявляється вище, ніж у реляційних СУБД. Якщо ж дані менш складні, додаткові функції виявляються надлишковими.

В об'єктній моделі даних підтримуються нерегламентовані запити, але мовою їх складання не обов'язково є SQL. Логічне представлення даних може не відповідати реляційній моделі, тому застосування мови SQL стане безглуздим. Часто зручніше обробляти об'єкти в пам'яті, виконуючи відповідні види пошуку.

Великим недоліком об'єктно-орієнтованих баз даних є їх тісний зв'язок з застосовуваною мовою програмування. До даних, що зберігаються в реляційній СУБД, можуть звертатися будь-які додатки, тоді як, наприклад, Java-об'єкт, поміщений в ООСУБД, буде представляти інтерес лише для додатків, написаних на Java.

Об’єктно-реляційні поєднують у собі риси реляційної та об'єктної моделей. Їх виникнення пояснюється тим, що реляційні бази даних добре працюють з вбудованими типами даних і набагато гірше – з користувацькими, нестандартними. Коли з'являється новий важливий тип даних, доводиться або включати його підтримку в СУБД, або змушувати програміста самостійно управляти даними в додатку. Не всяку інформацію має сенс інтерпретувати у вигляді ланцюжків символів або цифр. Уявімо собі музичну базу даних. Пісню, закодовану у вигляді аудіофайлу, можна помістити в текстовому полі великого розміру, але як в такому разі буде здійснюватися текстовий пошук?

Перебудова архітектури СУБД з метою включення в неї підтримки нового типу даних – не кращий вихід з положення. Замість цього об'єктно-реляційна СУБД дозволяє завантажувати код, призначений для обробки "нетипових" даних. Таким чином, база даних зберігає свою табличну структуру, але спосіб обробки деяких полів таблиць визначається ззовні, тобто програмістом[6].

За ступенем роздрібненості

За ступенем роздрібненості СУБД поділяються на:

локальні СУБД (всі частини локальної СУБД розміщуються на одному комп'ютері);
розподілені СУБД (частини СУБД можуть розміщуватися на двох та більше комп'ютерах).

За способом доступу до БД

За способом доступу до БД СУБД поділяються на:

файл-серверні;
клієнт-серверні;
вбудовані.

У файл-серверних СУБД файли даних розташовуються централізовано на файл-сервері. СУБД розташовується на кожному клієнтському комп'ютері (робочої станції). Доступ до СУБД даними здійснюється через локальну мережу. Синхронізація читань і оновлень здійснюється за допомогою файлових блокувань. Перевагою цієї архітектури є низька навантаження на ЦП сервера. Недоліки: потенційно висока завантаження локальної мережі; утрудненість централізованого управління; утрудненість забезпечення таких важливих характеристик як висока надійність, висока доступність і висока безпека. Застосовуються найчастіше в локальних додатках, які використовують функції управління БД. На даний момент файл-серверна технологія вважається застарілою. Приклади: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

Клієнт-серверна СУБД розташовується на сервері разом з БД і здійснює доступ до БД безпосередньо, у монопольному режимі. Всі клієнтські запити на обробку даних обробляються клієнт-серверної СУБД централізовано. Недолік клієнт-серверних СУБД полягає в підвищених вимогах до сервера. Переваги: потенційно більш низьке завантаження локальної мережі; зручність централізованого управління; зручність забезпечення таких важливих характеристик як висока надійність, висока доступність і висока безпека. Приклади: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛІНТЕР.

Вбудована СУБД – СУБД, яка може поставлятися як складова частина деякого програмного продукту, не вимагаючи процедури самостійної установки. Вбудована СУБД призначена для локального зберігання даних програми і не розрахована на колективне використання в мережі. Фізично вбудована СУБД найчастіше реалізована у вигляді підключається бібліотеки. Доступ до даних з боку програми може відбуватися через SQL або через спеціальні програмні інтерфейси. Приклади: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Sav Zigzag, Microsoft SQL Server Compact, ЛІНТЕР.

Основні ідеї сучасної інформаційної технології базуються на концепції баз даних (БД). Відповідно до даної концепції основою інформаційної технології є дані, організовані в БД, адекватно відбивають реалії дійсності в тій або іншій предметній області і забезпечують користувача актуальною інформацією у відповідній предметній області. Перші БД з'явилися вже на початку 1-го покоління ЕОМ, представляючи собою окремі файли даних або їх прості сукупності. По мірі збільшення об'єму і структурної складності збереженої інформації, а також розширення кола споживачів; інформації визначилася необхідність створення зручних ефективних систем інтеграції збережених даних і управління ними. В кінці 60-х років це призвело до створення перших комерційних систем управління базами даних (СУБД), які підтримують організацію і ведення БД. Перед обговоренням подальшого матеріалу, нам буде потрібно ряд основних понять, які використовуються в інформаційних системах різного призначення.

2 ОБ’ЄКТНО-РЕЛЯЦІЙНА СИСТЕМА УПРАВЛІННЯ БАЗАМИ ДАНИХ POSTGRESQL

2.1 Історія розвитку

Об'єктно-реляційна СУБД (ОРСУБД) – реляційна СУБД (РСУБД), підтримуюча деякі технології, які реалізують об'єктно-орієнтований підхід: об'єкти, класи і спадкування реалізовані в структурі баз даних і мовою запитів.

PostgreSQL – це вільно розповсюджувана ОРСУБД та найбільш розвинута з відкритих баз даних у світі і є реальною альтернативою комерційним базам даних.

Спочатку була некомерційна СУБД Postgres, розроблена, як і багато open-source проектів, в Каліфорнійському університеті в Берклі. До розробки Postgres, що почалася в 1986 році, мав безпосереднє відношення Майкл Стоунбрейкера, керівник більш раннього проекту Ingres, на той момент вже придбаного компанією Computer Associates. Сама назва «Postgres» розшифровується як «Post Ingres», відповідно, при створенні Postgres були застосовані раніше зроблені напрацювання.

Стоунбрейкер і його студенти розробляли нову СУБД протягом восьми років, з 1986 по 1994 рік. За цей період в синтаксис були введені процедури, правила, користувацькі типи й багато інших компонентів. Робота не пройшла марно – в 1995 році розробка знову розділилася: Стоунбрейкер використовував отриманий досвід у створенні комерційної СУБД Illustra, а його студенти розробили нову версію Postgres – Postgres95, в якій мова запитів POSTQUEL – спадщина Ingres – була замінена на SQL.

У цей момент розробка Postgres95 була виведена за межі університету і передана команді ентузіастів. З цього моменту СУБД отримала ім'я, під яким вона відома і розвивається в поточний момент - PostgreSQL.

2.2 Основні можливості ОРСУБД PostgreSQL

Функції

Функції є блоками коду, що виконуються на сервері, а не на клієнті БД. Хоча вони можуть бути написані на чистому SQL, реалізація додаткової логіки, наприклад, умовних переходів і циклів, виходить за рамки власне SQL і вимагає використання деяких мовних розширень. Функції можуть писатися з використанням однієї з наступних мов:

вбудованої процедурної мови PL/pgSQL, яка багато в чому аналогічна мові PL/SQL, що використовується в СУБД Oracle;
скриптової мови – PL/Lua, PL/LOLCODE, PL/Perl, plPHP, PL/Python, PL/Ruby, PL/sh, PL/Tcl і PL/Scheme;
класичної мови – C, C++, Java (через модуль PL/Java);
статистичної мови R (через модуль PL/R).

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

Функції можуть виконуватися як з правами їх творця, так і з правами поточного користувача.

Іноді функції ототожнюються з збереженими процедурами, однак між цими поняттями є різниця.

2.2.2 Тригери

Тригери визначаються як функції, ініційовані DML-операціями. Наприклад, операція INSERT може запускати тригер, який перевіряє доданий запис на відповідності певним умовам. При написанні функцій для тригерів можуть використовуватися різні мови програмування.

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

2.2.3 Правила та представлення

Механізм правил (англ. rules) являє собою механізм створення користувацьких обробників не тільки DML-операцій, але і операції вибірки. Основна відмінність від механізму тригерів полягає в тому, що правила спрацьовують на етапі розбору запиту, до вибору оптимального плану виконання і самого процесу виконання. Правила дозволяють змінити поведінку системи при виконанні SQL-операції до таблиці.

Хорошим прикладом є реалізація механізму представлень (англ. views): при створенні представлення створюється правило, яке визначає, що замість виконання операції вибірки до представлення система повинна виконувати операцію вибірки до базової таблиці/таблиці з урахуванням умов вибірки, що лежать в основі визначення уявлення. Для створення уявлень, які підтримують операції оновлення правила для операцій вставки, зміни і видалення рядків повинні бути визначені користувачем.

Індекси

В PostgreSQL є підтримка індексів наступних типів: B-дерево, хеш, R-дерево, GiST, GIN(4). При необхідності можна створювати нові типи індексів, хоча це далеко не тривіальний процес. Індекси в PostgreSQL володіють наступними властивостями:

можливий перегляд індексу не тільки в прямому, але й у зворотному порядку – створення окремого індексу для роботи конструкції ORDER BY ... DESC не потрібно;
можливе створення індексу над кількома стовпцями таблиці, в тому числі над стовпцями різних типів даних;
індекси можуть бути функціональними, тобто будуватися не на базі набору значень певного стовпця/стовпців, а на базі набору значень функції від набору значень;
індекси можуть бути частковими, тобто будуватися тільки по частині таблиці за деякою її проекції); у деяких випадках це допомагає створювати більш компактні індекси або досягати покращення продуктивності за рахунок використання різних типів індексів для різних (наприклад, з точки зору частоти оновлення) частин таблиці;
планувальник запитів може використовувати кілька індексів одночасно для виконання складних запитів.

2.2.5 Механізм «Multiversion Concurrency Control»

PostgreSQL підтримує одночасну модифікацію БД багатьма користувачами з допомогою механізму Multiversion Concurrency Control (MVCC). Завдяки цьому дотримуються вимоги ACID, і практично відпадає потреба у блокуванні читання [8].

Об’єктно-реляційна система управління базами даних PostgreSQL 📙 Курсовая → 🆔 144373