Об’єктно-реляційна система управління базами даних PostgreSQL. Курсовая работа (т). Информационное обеспечение, программирование.
🛑 👉🏻👉🏻👉🏻 ИНФОРМАЦИЯ ДОСТУПНА ЗДЕСЬ ЖМИТЕ 👈🏻👈🏻👈🏻
Информационное обеспечение, программирование
Вы можете узнать стоимость помощи в написании студенческой работы.
Помощь в написании работы, которую точно примут!
Похожие работы на - Об’єктно-реляційна система управління базами даних PostgreSQL
Скачать Скачать документ
Информация о работе Информация о работе
Скачать Скачать документ
Информация о работе Информация о работе
Скачать Скачать документ
Информация о работе Информация о работе
Скачать Скачать документ
Информация о работе Информация о работе
Скачать Скачать документ
Информация о работе Информация о работе
Скачать Скачать документ
Информация о работе Информация о работе
Скачать Скачать документ
Информация о работе Информация о работе
Нужна качественная работа без плагиата?
Не нашел материал для своей работы?
Поможем написать качественную работу Без плагиата!
КРЕМЕНЧУЦЬКИЙ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ
ЕЛЕКТРОНІКИ ТА КОМП’ЮТЕРНОЇ ІНЖЕНЕРІЇ
КАФЕДРА
ІНФОРМАТИКИ І ВИЩОЇ МАТЕМАТИКИ
ТЕМА:
«Об’єктно-реляційна система управління базами даних PostgreSQL »
Пояснювальна записка до курсової
роботи: 34
сторінки, 11 рисунків, 8
літературних джерел.
Метою роботи є вивчення
об’єктно-реляційної моделі даних та її особливостей. Об’єкт дослідження -
об’єктно-реляційна модель даних, а предмет - реалізація бази даних факультету
на основі цієї моделі.
Дослідження об’єктно-реляційної моделі
та власне побудова бази даних проводилися в інструментальній системі управління
базами даних PostgreSQL.
Практичним результатом даної роботи
є готова функціонуюча база даних факультету, що має у підпорядкуванні кілька
кафедр, на яких працюють викладачі, викладаючи різні предмети різним
академічним групам. Кожен зі студентів групи отримує оцінки з різних предметів,
які також фіксуються у базі. База даних заповнена реальними даними,
протестована та готова для роботи.
Пояснительная записка к курсовой работе: 34
страницы,
11
рисунков, 8 литературных
источников.
Целью работы является изучение
объектно-реляционной модели данных и ее особенностей. Объект исследования -
объектно-реляционная модель данных, а предмет -
реализация базы данных факультета на основе этой модели.
Исследования объектно-реляционной модели и
собственно построение базы данных проводились в инструментальной системе
управления базами данных PostgreSQL.
Практическим результатом данной работы является
готовая функционирующая база данных факультета, что имеет в подчинении
несколько кафедр, на которых работают преподаватели, преподавая различные
предметы различным академическим группам. Каждый из студентов группы получает
оценки по разным предметам, которые также фиксируются в базе. База данных
заполнена реальными данными, протестирована и готовая для работы.
Об’єктно-реляційна система
управління базами даних PostgreSQL
.2.5 Механізм «Multiversion
Concurrency Control»
Реалізація бази даних
факультету засобами ОРСУБД PostgreSQL
Сприйняття реального світу будується
як послідовність різних, іноді і взаємозалежних, явищ. Ще в давнину люди
різними способами описували ці явища, часто навіть не розуміючи їх суті.
Сьогодні цей опис називається даними. До даних відносяться: факти, явища,
події, ідеї чи предмети.
Фіксація даних традиційно
відбувається через конкретні засоби спілкування - природної мови чи зображень,
на конкретному носії: камені чи папері. Враховуючи той факт, що природна мова
володіє достатньою гнучкістю, дані та їх інтерпретація (семантика) фіксуються
спільно. Наприклад, розглянемо твердження "Вартість квитка на електричку
147". Тут "147" - дане, а "Вартість квитка на
електричку" - його семантика.
Дуже часто дані та інтерпретація
розділяються. Наприклад, "Розклад руху поїздів" подається у вигляді
таблиці, в якій у верхній частині окремо від даних буде наведена їх
інтерпретація, а це ускладнює роботу з даними і призводить до складності
отримання відомості з нижньої частини таблиці.
Поділ даних та інтерпретації стає ще
більш відчутним, коли ЕОМ застосовується для введення й обробки даних. Це
відбувається тому, що ЕОМ може мати справу тільки з даними. Велика частина
інформації, що інтерпретується, не фіксується в явній формі (ЕОМ не
"розуміє", "22.50" є вартістю авіаквитка або часом
вильоту). Чому так відбувається?
Існують як мінімум дві історичні
причини, що сприяють тому, що активне використання ЕОМ сприяло тому, що
відбулося розділення даних та інтерпретації:
– ЕОМ не мала достатніх
можливостей, щоб обробляти тексти природною мовою - переважно мовою
інтерпретації даних;
– висока вартість пам'яті ЕОМ.
Пам'ять використовували для того,
щоб зберігати самі дані, а інтерпретацією займалися безпосередньо користувачі.
Процес виглядав наступним чином, інтерпретацію даних закладали в програму, яка
"розуміла", наприклад, що п'яте введене значення пов'язане з часом
прибуття поїзда, а шосте - з часом його відправлення. Така послідовність дій
робила програму незамінною, бо без інтерпретації дані - лише сукупність бітів
на запам'ятовуючому пристрої.
Всі серйозні проблеми, які виникають
при введенні даних, пов'язані з тим, що між даними і програмами, які
використовують їх, існує дуже міцний зв'язок.
Як показує практика, спільне
використання одних і тих же даних, приносить масу проблем. Наприклад, дуже
часто буває так, що при використанні однієї і тієї ж ЕОМ користувачами
створюються і використовуються в програмах різні набори даних, що містять
подібну інформацію. Це можна пояснити тим, що користувач просто не має інформації
про те, що співробітник, який працює поруч, давно ввів в ЕОМ потрібні дані.
Дуже зручно при використанні, коли
розробники прикладних програм, розміщують потрібні їм дані у файлах. Треба
враховувати, що однакові дані в різних додатках відрізняються організацією,
тобто володіють різною послідовністю розміщення в запису, різні формати одних і
тих же полів і т.п. Тому узагальнити всі дані дуже складно. Це пов'язано з тим,
що якщо один розробник виробляє зміну структури запису файлу, то й інший
розробник повинен провести зміни в програмах, що використовують записи цього
файлу.
Система управління базами даних
(СУБД) призначена для надання доступу до даних різних користувачів, причому,
навіть для тих, які не мають уявлення про те, якими функціями володіють СУБД.
СИСТЕМА УПРАВЛІННЯ БАЗАМИ ДАНИХ
Система управління базами даних -
сукупність програмних і лінгвістичних засобів загального або спеціального
призначення, що забезпечують управління створенням та використанням баз даних.
– керування даними,
що
знаходяться
в зовнішній пам'яті (на дисках);
– запис змін до журналу,
резервне копіювання і відновлення бази даних після збоїв;
– підтримка мов БД (мова
визначення даних, мова маніпулювання даними).
Зазвичай сучасна СУБД містить
наступні компоненти:
– ядро, яке відповідає за
управління даними у зовнішній і оперативній пам'яті, та журналізацію;
– процесор мови бази даних, що
забезпечує оптимізацію запитів на вилучення та зміну даних і створення, як
правило, машинно-незалежного виконуваного внутрішнього коду;
– підсистему підтримки часу
виконання, яка інтерпретує програми маніпуляції даними, створюють
користувальницький інтерфейс з СУБД;
– а також сервісні програми
(зовнішні утиліти), що забезпечують ряд додаткових можливостей по
обслуговуванню інформаційної системи.
За моделлю даних СУБД поділяються
на:
Ієрархічні СУБД підтримують
деревоподібну організацію інформації. Зв'язки між записами виражаються у
вигляді відносин предок/нащадок, а у кожного запису є рівно один батьківський
запис. Це допомагає підтримувати посилальну цілісність. Коли запис видаляється
з дерева, всі його нащадки також повинні бути видалені. Ієрархічні бази даних
мають централізовану структуру, тобто безпеку даних легко контролювати. На
жаль, певні знання про фізичний порядок зберігання записів все ж необхідні, так
як відносини предок/нащадок реалізуються у вигляді фізичних покажчиків з одного
запису на інший. Це означає, що пошук запису здійснюється методом прямого
обходу дерева. Записи, розташовані в одній половині дерева, шукаються швидше,
ніж в іншій. Звідси випливає необхідність правильно впорядковувати записи, щоб
час їх пошуку був мінімальним. Це важко, так як не всі відносини, що існують в
реальному світі, можна виразити в ієрархічній базі даних. Відношення "один
до багатьох" є природними, але практично неможливо описати відносини
"багато до багатьох" або ситуації, коли запис має кілька предків. До
тих пір поки в додатках будуть кодуватися відомості про фізичну структуру
даних, будь-які зміни цієї структури будуть загрожувати перекомпіляцією.
Мережеві розширюють ієрархічну
модель СУБД, дозволяючи групувати зв'язки між записами у множину. З логічної
точки зору зв'язок - це не сам запис. Зв'язки лише виражають відносини між
записами. Як і в ієрархічній моделі, зв'язки ведуть від батьківського запису до
дочірнього, але на цей раз підтримується множинне спадкування. Слідуючи
специфікації 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
Об'єктно-реляційна СУБД (ОРСУБД) -
реляційна СУБД (РСУБД), підтримуюча деякі технології, які реалізують
об'єктно-орієнтований підхід: об'єкти, класи і спадкування реалізовані в
структурі баз даних і мовою запитів.- це вільно розповсюджувана ОРСУБД та
найбільш розвинута з відкритих баз даних у світі і є реальною альтернативою
комерційним базам даних.
Спочатку була некомерційна СУБД
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 допускає використання
функцій, які повертають набір записів, який можна використовувати так само, як
і результат виконання звичайного запиту.
Функції можуть виконуватися як з
правами їх творця, так і з правами поточного користувача.
Іноді функції ототожнюються з
збереженими процедурами, однак між цими поняттями є різниця.
Тригери визначаються як функції,
ініційовані DML-операціями. Наприклад, операція INSERT може запускати тригер,
який перевіряє доданий запис на відповідності певним умовам. При написанні
функцій для тригерів можуть використовуватися різні мови програмування.
Тригери асоціюються з таблицями.
Множинні тригери виконуються в алфавітному порядку.
Механізм правил (англ. rules) являє
собою механізм створення користувацьких обробників не тільки DML-операцій, але
і операції вибірки. Основна відмінність від механізму тригерів полягає в тому,
що правила спрацьовують на етапі розбору запиту, до вибору оптимального плану
виконання і самого процесу виконання. Правила дозволяють змінити поведінку
системи при виконанні SQL-операції до таблиці.
Хорошим прикладом є реалізація
механізму представлень (англ. views): при створенні представлення створюється
правило, яке визначає, що замість виконання операції вибірки до представлення
система повинна виконувати операцію вибірки до базової таблиці/таблиці з
урахуванням умов вибірки, що лежать в основі визначення уявлення. Для створення
уявлень, які підтримують операції оновлення правила для операцій вставки, зміни
і видалення рядків повинні бути визначені користувачем.
В PostgreSQL є підтримка індексів
наступних типів: B-дерево, хеш, R-дерево, GiST, GIN(4). При необхідності можна
створювати нові типи індексів, хоча це далеко не тривіальний процес. Індекси в
PostgreSQL володіють наступними властивостями:
– можливе створення індексу
над кількома стовпцями таблиці, в тому числі над стовпцями різних типів даних;
– індекси можуть бути функціональними,
тобто будуватися не на базі набору значень певного стовпця/стовпців, а на базі
набору значень функції від набору значень;
– індекси можуть бути
частковими, тобто будуватися тільки по частині таблиці за деякою її проекції);
у деяких випадках це допомагає створювати більш компактні індекси або досягати
покращення продуктивності за рахунок використання різних типів індексів для
різних (наприклад, з точки зору частоти оновлення) частин таблиці;
– планувальник запитів може
використовувати кілька індексів одночасно для виконання складних запитів.
2.2.5 Механізм «Multiversion
Concurrency Control»підтримує одночасну модифікацію БД багатьма користувачами з
допомогою механізму Multiversion Concurrency Control (MVCC). Завдяки цьому
дотримуються вимоги ACID, і практично відпадає потреба у блокуванні читання [8].
2.2.6 Типи данихпідтримує великий
набір вбудованих типів даних:
г) Грошовий тип (відрізняється
спеціальним форматом виводу, а в іншому аналогічний числам з фіксованою точкою
з двома знаками після коми)
. Символьні типи довільної довжини
3. Двійкові типи (включаючи
BLOB)
. Типи дата/час» (повністю
підтримують різні формати, точність, формати виводу, включаючи останні зміни в
часових поясах)
Більш того, користувач може
самостійно створювати нові необхідні йому типи і програмувати для них механізми
індексування за допомогою GiST.
.2.7 Користувальницькі об’єктиможе
бути розширений користувачем для власних потреб практично в будь-якому аспекті.
Є можливість додавати власні:
– домени (користувальницькі
типи спочатку з накладеними обмеженнями);
– функції (включаючи
агрегатні);
– оператори (включаючи
перевизначення вже існуючих);
Таблиці можуть успадковувати
характеристики та набори від інших таблиць (батьківських). При цьому дані,
додані в породжену таблицю, автоматично будуть брати участь (якщо це не
зазначено окремо) в запитах до батьківської таблиці [8].
Даний функціонал в поточний час не є
повністю завершеним. Однак він достатній для практичного використання.
– відповідності стандартам
ANSI SQL-92 і SQL-99;
– підтримки запитів з OUTER
JOIN, UNION, UNION ALL EXCEPT, INTERSECT і підпорядкованого;
– загальні табличні вирази і
рекурсивні запити;
– підтримка регулярних виразів
в стилі Perl;
– вбудована підтримка SSL і
Kerberos;
– протокол поділюваних
блокувань;
– завантажувані розширення, що
підтримують SHA1, MD5, XML та іншу функціональність (API відкритий);
– засоби для генерації
сумісного з іншими системами SQL-коду та імпорту з інших систем.
Згідно з результатами автоматизованого
дослідження різного ПЗ на предмет помилок, у вихідному коді PostgreSQL було
знайдено 20 проблемних місць на 775 000 рядків вихідного коду (в середньому,
одна помилка на 39 000 рядків коду). Для порівняння: MySQL - 97 проблем, одна
помилка на 4 000 рядків коду; FreeBSD (цілком) - 306 проблем, одна помилка на 4
000 рядків коду; Linux (тільки ядро) - 950 проблем, одна помилка на 10 000
рядків коду.
3 РЕАЛІЗАЦІЯ БАЗИ ДАНИХ ФАКУЛЬТЕТУ
ЗАСОБАМИ ОРСУБД POSTGRESQL
Необхідно спроектувати базу даних
факультету (електроніки та комп’ютерної інженерії), яка б задовольняла
наступним умовам:
. Факультет представлений чотирма
кафедрами.
2. За кожною кафедрою
закріплені певні викладачі, причому один викладач може працювати одночасно на
кількох кафедрах.
. Кожен викладач викладає
певний набір дисциплін, причому одна дисципліна може викладатися кількома
викладачами.
. На факультеті є кілька
академічних груп.
. Студенти закріплені за
певною групою.
. Кожен студент під час сесії
отримує оцінки з певних дисциплін. Одній дисципліні може відповідати кілька
оцінок одного й того ж студента (наприклад, якщо дисципліна викладається кілька
семестрів).
Інформація про викладача має
включати прізвище, ім’я та по-батькові, дату народження, дату початку та кінця
роботи. Також має вказуватися, на якій кафедрі працює викладач та які
дисципліни викладає.
Інформація про студента містить
прізвище, ім’я та по-батькові, дату народження, стать, дату початку та
завершення навчання, групу, у якій він навчається, та оцінки, які отримав
впродовж навчання.
Для дисципліни обов’язковими даними
є її назва та кількість годин.
Оцінки мають бути виставлені за
трьома шкалами: національною (5-бальною), 100-бальною, та шкалою ECTS.
Також необхідно знати, з якої дисципліни ця оцінка, якою була форма контролю та
хто її отримав.
Таблиця «teachers»
(викладачі) має основну інформацію про викладачів: прізвище, ім’я та
по-батькові, дата народження, початок роботи на кафедрі та у випадку звільнення
чи виходу на пенсію - дату закінчення роботи. Для роботи з нашою базою цієї
інформації буде достатньо, тому інші дані є другорядними, і ми їх враховувати
не будемо.
Зрозуміло, що для таблиці «students»
(студенти)
поля будуть майже ті самі, проте слід ще вказати стать. Це поле буде корисним,
наприклад, для запитів про хлопців призовного віку.
Наступна таблиця «departments»
(кафедри) буде зберігати відомості про кафедру. Проте нам треба зафіксувати не
усі відомі дані, а лише ті, які будуть використовуватися для досягнення певних
цілей, що ми визначили у постановці задачі. Назва кафедри - це все, що нам
потрібно знати про неї.
Визначальними рисами для «subject»
(дисципліни) є їх назва та кількість годин, що
відводиться на їх вивчення. Оцінки, окрім власне оцінок за різними шкалами,
також мають нести інформацію про форму контролю, за яку вони були виставлені,
оскільки це випливає, наприклад, на середній бал студента.
Визначені об’єкти не є незалежними,
вони мають певні зв’язки. Визначимо останні, розглядаючи отриману базу даних.
Очевидно, що таблиця «departments»
пов’язана з викладачами, що працюють на ній, при чому тип цього зв’язку -
«багато до багатьох». В свою чергу викладачі пов’язані не лише з кафедрою або
кафедрами, за якими вони закріплені, а й з дисциплінами, які викладають. Зі
студентами, групами чи оцінками за даною постановкою задачі у викладачів немає
прямого зв’язку. Отже, переходимо до таблиці «subject».
Як було визначено вище, за дисципліну виставляється оцінка (одна або декілька),
тому маємо зв'язок між дисциплінами та оцінками («один до багатьох»). Оцінки
виставляються за дисципліну певному студенту, отже, наступним буде зв'я
Похожие работы на - Об’єктно-реляційна система управління базами даних PostgreSQL Курсовая работа (т). Информационное обеспечение, программирование.
Дипломная работа: Методы активизации познавательной деятельности учащихся в процессе изучения курса "Физическая география материков и океанов"
Курсовая работа: Механизация технологического процесса водоснабжения и поения на откормочной свиноферме
Реферат по теме Технологія вирощування кролів
Кредо Эссе
Правильно Оформление Отчета По Практике
Реферат по теме Подключение по ISDN, высокоскоростное подключение по аналоговым каналам
Иогп Скачать Реферат
Сочинение По Рисунку Про Двух Козлят
Реферат по теме Первобытно-общинный строй
Сочинение В Жанре Интервью Примеры
Предметно Развивающая Среда В Доу Реферат
Реферат: Финансовый бухучет УрГСХА
Алгоритмы трассировки
Курсовая работа по теме Кейнсианская теория занятости
Реферат по теме Гучковы
Новый Мир Эссе Лем
Легкое Дыхание Любовь Сочинение
Реферат по теме Урегулирование конфликтов
Реферат: Этруски. Скачать бесплатно и без регистрации
Дипломная работа по теме Переоборудование зернового комбайна "Енисей 1200" на уборку подсолнечника в ООО "Дружба" Острогожского района Воронежской области
Похожие работы на - Задача о бесконечной ортотропной пластинке с эллиптическим отверстием и анализ НДС вблизи отверстия
Реферат: Дагестан
Статья: Квантитативная лексикология испанского языка