КАФЕДРА
Дата ___________________
Тема:
Реляційна база данних трудової книжки
“____” __________ 2008р.
Робота захищена
“____” __________ 2008р.
з оцінкою
_____________________
Підписи членів комісії
Зміст
Вступ
Головною задачею нашою роботи є створення програми роботи реляційної БД трудової книжки, причому в якості мови реалізації була вибрана мова програмування С++.
Що стосується загальної термінології реляційного підходу, ми будемо активно користуватися відповідними термінами. До таких термінів ставляться назви реляційних операцій: селекція, проекція, з'єднання; назви теоретико-множинних операцій: об'єднання, перетинання, різниця й т.д.
ТЕОРІЯ
Основні цілі розроблювачів БД можна сформулювати в такий спосіб:
1. забезпечити ненавігаційний інтерфейс високого рівня користувача із системою, що дозволяє досягти незалежності даних і дати можливість користувачам працювати максимально ефективно;
2. забезпечити різноманіття припустимих способів використання СУБД, включаючи програмувальні транзакції, діалогові транзакції й генерацію звітів;
3. підтримувати динамічно змінюване середовище баз даних, у якій відносини, індекси, подання, транзакції й інші об'єкти можуть легко додаватися й знищуватися без припинення нормального функціонування системи;
4. забезпечити можливість паралельної роботи з однією базою даних багатьох користувачів з допущенням паралельної модифікації об'єктів бази даних при наявності необхідних засобів захисту цілісності бази даних;
5. забезпечити засобу відновлення погодженого стану баз даних після різного роду збоїв апаратури або програмне забезпечення;
6. забезпечити гнучкий механізм, що дозволяє визначати різні подання збережених даних й обмежувати цими поданнями доступ користувачів до бази даних по вибірці й модифікації на основі механізму авторизації;
7. забезпечити продуктивність системи при виконанні згаданих функцій, порівнянну із продуктивністю існуючих СУБД низького рівня (наприклад, ієрархічних або мережних).
Насамперед відзначимо, що в переважній більшості поставлені цілі при розробці System R були досягнуті. Розглянемо тепер, якими засобами були досягнуті ці мети і як більш точно можна інтерпретувати їх у контексті System R.
Основою System R є реляційна мова SQL. Іноді його називають мовою запитів або мовою маніпулювання даними, але насправді його можливості набагато ширше. Засобами SQL (з відповідною системною підтримкою) вирішуються багато хто з поставлених цілей. Мова SQL включає засобу динамічної компіляції запитів, на основі чого можлива побудова діалогових систем обробки запитів. Допускається динамічна параметризація статично відкомпільованих запитів, у результаті чого можливе побудова ефективних (не потребуючої динамічної компіляції) діалогових систем зі стандартними наборами (параметризуємих) запитів.
Засобами SQL визначаються всі доступні користувачеві об'єкти баз даних: таблиці, індекси, подання. В System R були й засобу для знищення будь-якого такого об'єкта. Відповідні оператори мови можуть виконуватися в будь-який момент, і можливість виконання операції цим користувачем залежить від раніше наданих йому прав.
Що стосується цілісності баз даних, то в System R під цілісним станом бази даних розуміється стан, що задовольняє набору даних предикатів, що зберігають при базі, цілісності. Ці предикати, називані в System R умовами цілісності (assertions), задаються також засобами мови SQL. Будь-яка пропозиція мови виконується в межах деякої транзакції - неподільної в змісті стану бази дані послідовності операторів мови. Неподільність означає, що всі зміни, зроблені в межах однієї транзакції, або цілком відображаються в стані бази даних, або повністю в ньому відсутні. Остання можливість виникає при відкоті транзакції, що може відбутися з ініціативи користувача (при виконанні відповідного оператора SQL) або з ініціативи системи. Однієї із причин відкоту транзакції з ініціативи системи є саме порушення цілісності бази даних у результаті дій даної транзакції (інші можливі умови відкоту транзакції з ініціативи системи ми розглянемо пізніше). Мова SQL System R містить засіб установки так званих крапок збереження (savepoint). При ініциируємом користувачем відкоті транзакції можна вказати номер крапки збереження, вище якої відкіт не поширюється. Ініциіруємий системою відкіт транзакції виробляється до найближчої крапки збереження, у якій умова, що викликала відкіт, уже відсутній. Зокрема, відкіт, ініційований через порушення умови цілісності, виробляється до найближчої крапки збереження, у якій умови цілісності дотримані. (Помітимо, що засобу установки крапок збереження відсутні в комерційних розширеннях System R.)
Природно, що для реального виконання відкоту транзакції необхідне запам'ятовування деякої інформації про виконання транзакції. В System R для цих й інших цілей використається спеціальний набір даних - журнал, у який містяться записи об всіх змініючих стан бази даних операціях всіх транзакцій. При відкоті транзакції відбувається процес зворотного виконання транзакції (undo), у ході якого у зворотному порядку виконуються всі зміни, зафіксовані в журналі.
У мові SQL є засіб визначення так званих умовних впливів (triggers), що дозволяють автоматично підтримувати цілісність бази даних при модифікаціях її об'єктів. В System R умовний вплив - це каталогізована операція модифікації, для якої задане умова її автоматичного виконання. Особливо істотна наявність такого апарата у зв'язку з наявністю розглянутих нижче подань бази даних, який може бути обмежений доступ до бази даних для ряду користувачів. Можлива ситуація, коли такі користувачі просто не можуть дотримувати цілісності бази даних без автоматичного виконання умовних впливів, оскільки вони "не бачать" всієї бази даних й, зокрема, не можуть представити всіх обмежень її цілісності. Помітимо, що за винятком ранніх публікацій по System R реалізація механізму умовних впливів ніде не описувалася, хоча в принципі підходи до реалізації досить зрозумілі. Цей механізм не реалізований у комерційних системах, що виникли на базі System R. Видимо, це пов'язане з виникаючими додатковими непередбаченими для користувачів накладними витратами при виконанні транзакцій. (Помітимо, що деякі еквівалентні по можливостях засобу реалізовані, наприклад, у СУБД Ingres й Oracle, а тепер обговорюється можливість включення подібних механізмів у наступний стандарт мови SQL - SQL-3.)
Мова SQL містить засобу визначення подань. Подання - іменований запит, що зберігає це в базі даних, на вибірку даних (з однієї або декількох таблиць). Оскільки SQL - це реляционный мова, то результатом виконання будь-якого запиту на вибірку є таблиця, і тому концептуально можна ставитися до будь-якого подання як до таблиці (при визначенні подання можна, зокрема, привласнити імена полям цієї таблиці). У мові допускається використання раніше певних подань практично скрізь, де допускається використання таблиць (з деякими обмеженнями із приводу можливостей модифікації бази даних через подання). Наявність можливості визначати подання в сукупності з розвитий системою авторизації дозволяє обмежити доступ деяких користувачів до бази даних виділеним набором подань.
Авторизація доступу до бази даних заснована також на засобах SQL. При створенні будь-якого об'єкта бази даних виконуючу цю операцію користувач стає повновладним власником цього об'єкта, тобто може виконувати стосовно цього об'єкта будь-яку функцію з визначеного набору. Далі цей користувач може виконати оператор SQL, що робить передачу всіх його прав на цей об'єкт (або їхньої підмножини) будь-якому іншому користувачеві. Зокрема, цьому користувачеві може бути передане право на передачу всіх переданих йому прав (або їхньої частини) третьому користувачеві й т.д. Одним із прав користувача стосовно об'єкта є право на вилучення в інших користувачів всіх або деяких прав, які раніше їм були передані. Ця операція поширюється транзитивно на всіх подальших спадкоємців цих прав.
Наявність у мові засобів визначення подань й авторизації в принципі дозволяє обійтися при експлуатації System R без традиційного адміністратора баз даних, оскільки практично всі системні дії виробляються на основі засобів SQL. Проте якщо організаційно адміністратор баз даних потрібно, то його робота досить спрощується за рахунок уніфікованого набору засобів керування. Крім того, в System R каталоги баз даних підтримуються також у вигляді таблиць, і до них застосовані всі запити мови SQL. Помітимо, що в комерційних СУБД з'явився ряд додаткових утиліт, не пов'язаних з мовою SQL (наприклад, утиліти збору статистики або масове завантаження бази даних), і в цих системах, видимо, без адміністратора бази даних не обійтися.
Що стосується забезпечення паралельної роботи багатьох користувачів з однією базою даних, те основний підхід System R полягає в тому, що користувач не зобов'язаний знати про наявність інших, конкуруючих з ним за доступ до бази даних, користувачів, тобто система відповідальна за забезпечення ізольованості користувачів з гарантією їхнього взаємного невпливу в межах транзакцій. Із цього треба, по-перше, що в інтерфейсі користувача із системою (тобто в мові SQL) не повинне бути засобів регулювання взаємодій з іншими користувачами й, по-друге, що система повинна забезпечити автоматичну сериализацию набору транзакцій, тобто забезпечити режим виконання цього набору транзакцій, еквівалентний за кінцевим результатом деякому послідовному виконанню цих транзакцій. Ця проблема вирішується в System R за рахунок автоматичного виконання синхронизационных захватів (багато хто воліють використати термін "блокування") стосовно всім измененяемым об'єктам бази даних. Є ряд тонкостей, пов'язаних з такою синхронізацією, на яких ми зупинимося нижче.