Курсовая работа: Реляційна база данних трудової книжки
Курсовая работа: Реляційна база данних трудової книжки
Міністерство освіти науки України
ФАКУЛЬТЕТ ІНФОРМАТИКИ
КАФЕДРА
Реєстраційний №________
Дата ___________________
КУРСОВА РОБОТА
Тема:
Реляційна база данних трудової книжки
Рекомендована до захисту
“____” __________ 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 за рахунок автоматичного виконання синхронизационных захватів (багато хто воліють використати термін "блокування") стосовно всім измененяемым об'єктам бази даних. Є ряд тонкостей, пов'язаних з такою синхронізацією, на яких ми зупинимося нижче.
Одним з основних вимог до СУБД, взагалі, і до System R, зокрема, є забезпечення надійності баз даних стосовно різного роду збоям. До таких збоїв можуть ставитися програмні помилки прикладного й системного рівня, збої процесора, поломки зовнішніх носіїв і т.д. Зокрема, до одному з видів збоїв можна віднести згадувані вище порушення цілісності бази даних й автоматичний, ініциіруємий системою відкіт транзакції - це системний засіб відновлення бази даних після збоїв такого роду. Як ми відзначали, відновлення відбувається шляхом зворотного виконання транзакції на основі інформації про внесені нею змінах, зафіксованих у журналі. На інформації журналу засноване відновлення бази даних і після збоїв іншого роду. Керування журнализацией відновленням в System R досить цікаво, застосовувані методи в ряді випадків відрізняються від методів, використовуваних в інших СУБД.
Що стосується природних вимог до ефективності системи, те тут основні рішення зв'язані зі специфікою фізичної організації баз даних на зовнішній пам'яті, буферизацієй використовуваних сторінок бази даних в оперативній пам'яті й розвитий технікою оптимізації запитів, сформульованих на SQL, виробленої на стадії їхньої компіляції.
Структурна організація System R цілком погодиться з поставленими при її розробці цілями й обраними рішеннями. Основними структурними компонентами System R є система керування реляционной пам'яттю (Relational Storage System - RSS) і компілятор запитів мови SQL. RSS забезпечу нтерфейс досить низького, але достатнього для реалізації SQL рівня для доступу до збережених даних. Синхронізація транзакцій, журнализация змін і відновлення баз даних після збоїв також ставляться до числа функцій RSS. Компілятор запитів використає інтерфейс RSS для доступу до різноманітної довідкової інформац (каталоги відносин, індексів, прав доступу, умов цілісності, умовних впливів т.д.) і робить робочі програми, виконувані надалі також з використанням нтерфейсу RSS. Таким чином, система природно розділяється на два рівні: рівень керування пам'яттю й синхронізацією, фактично, що не залежить від базової мови запитів системи, і мовний рівень (рівень SQL), на якому вирішується більшість проблем System R. Помітимо, що ця незалежність скоріше умовна, чим абсолютна: мова SQL можна замінити на іншу мову, але він повинен мати приблизно таку ж семантику.
Далі ми послідовно розглянемо особливості організації RSS, процес компіляції й оптимізації запитів і техніку виконання відкомпільованих транзакцій (включаючи відзначену вище можливість динамічної компіляц запитів).
Практична частина
Лістінг програм
Головний програма БД – ТРУДОВА КНИЖКА.
//---------------------------------------------------------------------------
#include <vcl.h>
#pragma hdrstop
#include "Unit9.h"
#include "Unit22.h"
#include "Unit23.h"
#include "Unit4.h"
#include "Unit24.h"
#include "Unit27.h"
#include "Unit28.h"
//---------------------------------------------------------------------------
#pragma package(smart_init)
#pragma resource "*.dfm"
Tzarplata *zarplata;
Tz_nastr *z_nastr;
extern TOKBottomDlg *OKBottomDlg;
extern TForm4 *Form4;
extern Talgo *algo;
//---------------------------------------------------------------------------
__fastcall Tzarplata::Tzarplata(TComponent* Owner)
: TForm(Owner)
{
}
//---------------------------------------------------------------------------
void __fastcall Tzarplata::N9Click(TObject *Sender)
{
z_nastr->Table1->Close();
z_nastr->Table1->TableName = "z_nastr_const_nar";
z_nastr->Table1->Open();
z_nastr->Caption = "Настроювання констант нарахування";
z_nastr->ShowModal();
}
//---------------------------------------------------------------------------
void __fastcall Tzarplata::N6Click(TObject *Sender)
{
z_nastr->Table1->Close();
z_nastr->Table1->TableName = "z_nastr_vch_stavka_osv";
z_nastr->Table1->Open();
z_nastr->Caption = "Ставка за освітою";
z_nastr->ShowModal();
}
//---------------------------------------------------------------------------
void __fastcall Tzarplata::N10Click(TObject *Sender)
{
z_nastr->Table1->Close();
z_nastr->Table1->TableName = "z_nastr_vch_visluga";
z_nastr->Table1->Open();
z_nastr->Caption = "Надбавка за вислугу років";
z_nastr->ShowModal();
}
//---------------------------------------------------------------------------
void __fastcall Tzarplata::N13Click(TObject *Sender)
{
z_nastr->Table1->Close();
z_nastr->Table1->TableName = "z_nastr_const_vidr";
z_nastr->Table1->Open();
z_nastr->Caption = "Настроювання констант відрахування";
z_nastr->ShowModal();
}
//---------------------------------------------------------------------------
void __fastcall Tzarplata::N12Click(TObject *Sender)
{
z_nastr->Table1->Close();
z_nastr->Table1->TableName = "z_nastr_likarnyani";
z_nastr->Table1->Open();
z_nastr->Caption = "Нарахування лікарняних";
z_nastr->ShowModal();
}
//---------------------------------------------------------------------------
void __fastcall Tzarplata::N14Click(TObject *Sender)
{
z_nastr->Table1->Close();
z_nastr->Table1->TableName = "z_nastr_derzsluz_visluga";
z_nastr->Table1->Open();
z_nastr->Caption = "Держслужбовц - вислуга";
z_nastr->ShowModal();
}
//---------------------------------------------------------------------------
void __fastcall Tzarplata::N7Click(TObject *Sender)
{
z_nastr->Table1->Close();
z_nastr->Table1->TableName = "z_nastr_vch_kateg";
Страницы: 1, 2
