Об’єктно-реляційна система управління базами даних 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 Основні функції

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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