„Проектування бази даних готельного комплексу сторінка 2

1 2 3

Ім'я файлу: Курсова бази даних готельного комплексу.doc
Розширення: doc
Розмір: 357кб.
Дата: 16.10.2020
скачати

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

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

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

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

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

Об'єкт - елементи реального часу, які існують незалежно.

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

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

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

Клієнт готелю (Client) - його модель буде дуже схожа на модель співробітника готелю має практично аналогічний набір атрибутів: ім'я, прізвище, адреса.

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

На основі представленої сутності будується таблиця, яка матиме вигляд

Таблиця 1.1 - Стовпці таблиці Client

№ Атрибута	Назва атрибута	Тип даних	Призначення атрибута
1	FirstName	Рядковий тип даних зі зміною довжиною	Призначений для виведення ім’я клієнта

Продовження таблиці 1.1

2	SurName	Рядковий тип даних зі зміною довжиною	Призначений для виведення прізвища клієнта
3	Address	Рядковий тип даних зі зміною довжиною	Призначений для виведення адреси клієнта

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

Таблиця 1.2 - Стовпці таблиці Employee

№ Атрибута	Назва атрибута	Тип даних	Призначення атрибута
1	FirstName	Рядковий тип даних зі зміною довжиною	Призначений для виведення ім’я працівника готелю
2	SurName	Рядковий тип даних зі зміною довжиною	Призначений для виведення прізвища працівника
3	Address	Рядковий тип даних зі зміною довжиною	Призначений для виведення адреси працівника
4	Post	Рядковий тип даних зі зміною довжиною	Призначений для виведення адреси працівника

Тип відносини між сутностями "співробітник готелю" й "клієнт готелю "- "багато до багатьох".

Сутність «замовлення» (Orders) буде зберігати інформацію про взаємодію між співробітниками готелю та його клієнтами.
Таблиця 1.3 - Стовпці таблиці Orders

№ Атрибута	Назва атрибута	Тип даних	Призначення атрибута
1	TypeHotelRoom	Рядковий тип даних зі зміною довжиною	Призначений для виведення типів кімнат в готелі
2	Payment	Рядковий тип даних зі зміною довжиною	Призначений для виведення видів оплати послуг
3	Comfort	Рядковий тип даних зі зміною довжиною	Призначений для виведення комфортності готельних номерів
4	TimeRecedens	Рядковий тип даних зі зміною довжиною	Призначений для виведення даних пов’язаних з періодом проживання в готелі

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

1.3 Нормалізація структури даних
Джерела терміну нормалізація варто шукати в реляційної теорії, де це поняття було вперше сформульоване й запропоноване батьком реляційної теорії Е. Ф. Коддом. Нормалізація - це процес організації таблиць і даних, що зберігаються в них, таким чином, щоб максимально зменшити число зайвих залежностей і неефективних структур. Нормалізація лінійна , тобто кожне наступне правило може бути застосовано лише після виконання всіх попередніх правил. Використається для визначення найбільш оптимальної структури бази даних, що можлива в заданих умовах. У процесі нормалізації визначаються шість нормальних форм, або етапів. Улюбленою нормальною формою більшості розроблювачів баз даних є 3НФ (3NF). Як правило, до цієї форми приводиться більша частина всіх існуючих баз даних. Третя нормальна форма являє собою оптимальний компроміс між двома протилежними тенденціями - прагненням до нормалізації як способу підвищення функціональних можливостей і наочністю реалізації. До того ж більшість розроблювачів затверджують, що 3НФ цілком достатньо для забезпечення належного рівня несуперечності даних.

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

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

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

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

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

Так, як співробітники готелю й клієнти готелю - це люди, які до того ж мають досить багато загальних характеристик (ім'я, прізвище, адресу) то простіше об'єднати ці сутності в одну загальну таблицю, Person.
Таблиця 1.4 - Стовпці таблиці Person

№ Атрибута	Назва атрибута	Тип даних	Призначення атрибута
1	FirstName	Рядковий тип даних зі зміною довжиною	Призначений для виведення ім’я людини
2	SurName	Рядковий тип даних зі зміною довжиною	Призначений для виведення прізвища людини
3	Address	Рядковий тип даних зі зміною довжиною	Призначений для виведення адреси людини

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

Таблиця 1.5 - Стовпці таблиці Post

№ Атрибута	Назва атрибута	Тип даних	Призначення атрибута
1	Post ID	Int - збереження цілих чисел	Індифікаційний стовпець таблиці
2	Description	Рядковий тип даних зі зміною довжиною	Призначений для виведення назв посад

Співробітники готелю й клієнти готелю - люди, які мають декілька видів адрес (домашню адресу, робочу, поштову та інші), то можна представити перелік адрес в окрему таблицю. Ця таблиця матиме таку структуру:

Таблиця 1.6 - Стовпці таблиці AddressType

№ Атрибута	Назва атрибута	Тип даних	Призначення атрибута
1	AddressTypeID	Int - збереження цілих чисел	Індифікаційний стовпець таблиці
2	Description	Рядковий тип даних зі зміною довжиною	Призначений для виведення типів адрес.

Доречно, також виділити назви міст, в яки можуть проживати, як працівники готелю так і клієнти в окрему таблицю City Вона матиме наступну структуру:

Таблиця 1.7 - Стовпці таблиці City

№ Атрибута	Назва атрибута	Тип даних	Призначення атрибута
1	City ID	Int - збереження цілих чисел	Індифікаційний стовпець таблиці

Продовження таблиці 1.7

Description

Рядковий тип даних зі зміною довжиною

Призначений для виведення назв міст

Таблиця Country призначена для переліку країн в яких можуть проживати співробітники та клієнти готелю.

Таблиця 1.8 - Стовпці таблиці Country

№ Атрибута	Назва атрибута	Тип даних	Призначення атрибута
1	CountryID	Int - для введення та збереження цілих чисел	Індифікаційний стовпець таблиці
2	Description	Рядковий тип даних зі зміною довжиною	Призначений для виведення виведення назв країн

Доречно об’єднати таблиці Country, City, AddressType в одну загальну таблицю Address, в якій буде вказано адресу проживання ( роботи, поштову адресу) клієнта об співробітника. Дана таблиця представлена наступним чином.

Таблиця 1.9 - Стовпці таблиці Address

№ Атрибута	Назва атрибута	Тип даних	Призначення атрибута
1	PersonID	Int - збереження цілих чисел	Індифікаційний стовпець таблиці
2	AddressTypeID	Int - збереження цілих чисел	Індифікаційний стовпець таблиці

Продовження таблиці 1.9

3	City ID	Int - збереження цілих чисел	Індифікаційний стовпець таблиці
4	CountryID	Int - для введення та збереження цілих чисел	Індифікаційний стовпець таблиці
5	Address	Рядковий тип даних зі зміною довжиною	Призначений для виведення виведення адрес

Доречно, також виділити види комфортності кімнат в готелі в окрему таблицю Comfort Вона складатиметься з атрибутів ComfortID, та Description матиме наступну структуру:

Таблиця 1.10 - Стовпці таблиці Comfort

№ Атрибута	Назва атрибута	Тип даних	Призначення атрибута
1	ComfortID	Int - для введення та збереження цілих чисел	Індифікаційний стовпець таблиці
2	Description	Рядковий тип даних зі зміною довжиною	Призначений для виведення видів комфортності готельних номерів

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

Таблиця 1.11 - Стовпці таблиці Paymant

№ Атрибута	Назва атрибута	Тип даних	Призначення атрибута
1	Paymant ID	Int - для введення та збереження цілих чисел	Індифікаційний стовпець таблиці
2	Description	Рядковий тип даних зі зміною довжиною	Призначений для виведення видів оплати послуг

Також в кожному готелю представлені різні типи кімнат (для однієї особи, для двох осіб та інші), а так, як

Таблиця 1.12 - Стовпці таблиці TypeHotelRoom

№ Атрибута	Назва атрибута	Тип даних	Призначення атрибута
1	TypeHotelRoom ID	Int - збереження цілих чисел	Індифікаційний стовпець таблиці
2	Description ID	Int - збереження цілих чисел	Індифікаційний стовпець таблиці
3	Post ID	Int - збереження цілих чисел	Індифікаційний стовпець таблиці
4	EmployeeID	Int - для введення та збереження цілих чисел	Індифікаційний стовпець таблиці

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

Був прийнятий, а потім доповнений офіційний міжнародний стандарт на SQL. Мова SQL є важливою ланкою в архітектурі систем керування базами даних, що випускають всіма провідними постачальниками програмних продуктів, і служить стратегічним напрямком розробок компанії Microsoft в області баз даних. Зародившись у результаті виконання другорядного дослідницького проекту компанії IBM, SQL сьогодні широко відомий й у якості потужного ринкового фактору.

SQL є інструментом, призначеним для обробки й читання даних, що знаходяться в комп'ютерній базі даних. SQL - це скорочена назва структурованої мови запитів (Structured Query Language).

SQL Server 2005 - це реляційна СУБД, що використає мову Transact-SQL для пересилання повідомлень між комп'ютером клієнта й комп'ютером, на якому працює SQL Server 2005. Реляційна СУБД складається з механізму баз даних, властивого базы даних та додаткам, необхідним для керування даними й компонентами реляційноъ СУБД. Реляційна СУБД організує дані у вигляді зв'язаних рядків і стовпців, що становлять базу даних. Реляційна СУБД відповідає за підтримку структури бази даних і вирішує наступні задачі:

- підтримує зв'язки між даними в базі;

- гарантує коректне зберігання даних і виконання правил, що регламентують зв'язки між ними;

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

База даних (БД) SQL Server 2005 являє собою реляційну базу даних, сумісну з SQL (Structured Query Language) з інтегрованою підтримкою XML для Інтернет-додатків. SQL

Microsoft SQL Server 2005 - це остаточне рішення для керування й аналізу даних, що дозволяє оперативно розгортати масштабовані Web-додатки нового покоління. SQL Server 2005 - ключовий компонент підтримки електронної комерції, інтерактивних ділових додатків і сховищ даних, що забезпечує масштабованість, необхідну для підтримки зростаючих, динамічних середовищ. В SQL Server 2005 передбачена найширша підтримка XML (Extensible Markup Language) і інших форматів, використовуваних в Інтернеті, функцій продуктивності й доступності, що гарантують своєчасне рішення поставлених задач, а також розвитої функціональності керування й настроювання, що дозволяє автоматизувати виконання рутинних задач і знизити сукупну вартість володіння.

конецформыначалоформыЯЯк правило, більша частина операцій в MS SQL Server може бути виконана декількома способами. Вони умовно діляться на дві групи: способи, виконувані за допомогою графічного інтерфейсу користувача, і способи, що припускають необхідність виконання запиту Transact-SQL. Мова запитів Transact-SQL - це надзвичайно гнучкий засіб керування базою даних.

Нижче наведені три основних способи, які можна використати для створення бази даних в MS SQL Server.

- конецформыначалоформыБданих може бути створена шляхом запуску у вікні Enterprise Manager майстри Database Creation Wizard (Майстер створення бази даних);

- база даних може бути створена за допомогою графічного інтерфейсу користувача програми Enterprise Manager;

- базу даних можна створити за допомогою програми Query Analyzer.
2.2 Розробка сценаріїв для створення бази даних і базових таблиць
конецформыначалоформыДлДля того щоб створити базу даних, варто скористатися оператором Transact-SQL CREATE DATABASE. Незважаючи на те що це один з найскладніших способів, він дозволяє досягти найбільшої гнучкості. Слід зазначити, що це не єдина перевага для створення бази даних. Оскільки мова побудови запитів SQL є міжнародним стандартом, знання базового синтаксису його операторів допоможе при переході на іншу СУБД.

Код створення бази даних представлений у додатку.

Проаналізуємо код Transact-SQL для створення бази даних (додаток В)

В рядку "USE master" вказується необхідність використання при виконанні всіх наступних операторів Transact-SQL бази даних master.

Команда GO використається в тих випадках, коли необхідно негайно виконати який-небудь фрагмент коду Transact-SQL не чекаючи виконання всього блоку. Команда GO є однієї з особливостей всіх версій SQL Server

Розташований в наступному рядку оператор DDL, "CREATE DATABASE Hotel" використовується для створення бази даних. Єдиним параметром, що передається цьому операторові, є її ім'я бази даних - "Hotel".

"ON PRIMARY (NAME = 'Hotel_Data', вказується використовувана група файлів, а також ім'я файлу даних. Відкриваюча кругла дужка позначає початок визначення параметрів файлу даних. Параметр NAME = дозволяє задати ім'я, що буде використатися MS SQL Server при звертанні до файлу даних.

FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\ Hotel_Data.MDF',

визначається місце розташування файлу даних.

Для визначення початкового розміру файлу даних, а також параметрів його приросту вказується "SIZE = 5MB", і FILEGROWTH = 10%). Закриваюча кругла дужка позначає закінчення визначення параметрів файлу даних.

В наступному рядку LOG ON (NAME = 'Hotel_Log', вказуються параметри журналу транзакцій. Параметр NAME = дозволяє задати ім'я, що буде використатися MS SQL Server при звертанні до журналу транзакцій.

FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\ Hotel_Log.LDF', визначені параметри журналу транзакцій повністю аналогічні відповідним параметрам файлу даних .

"GO" вказує на необхідність виконання попереднього блоку коду Transact-SQL (починаючи від останнього виклику команди GO). У цьому випадку цей блок охоплює всі рядки коду, починаючи з рядка з оператором CREATE DATABASE.

Важливим елементом розроблювальної бази даних є таблиці, які зберігають інформацію про клієнтів, співробітників готель, різні види адрес (домашня, службова), замовлення і т.д. Будь – які об’єкти не можуть зберігати дані, але вони можуть звертатися до таблиць.

Таблиці SQL Server 2005 мають таку ж структуру як інші таблиці інших баз даних. Таблиця складається зі стовпців і рядків.

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

Таблиця має ім'я, унікальне всередині бази даних. Таблиця відбиває тип об'єкта реального часу (сутність), а кожен її рядок— конкретний об'єкт.

Для створення таблиць за допомогою Transact-SQL використовується команда CREATE TABLE.

Таблиця Person призначена для збереження інформації про різних людей (клієнтів та співробітників). Дана таблиця буде складатися з наступних стовпців: ідентифікаційним стовпець PersonID, а також стовпців FirstName, SurName, Address, що зберігатимуть ім'я, прізвище та адресу відповідно. Код створення таблиці Person представлений у додатку Г

USE Hotel в даному рядку вказується необхідність використання при виконанні всіх наступних операторів Transact-SQL бази даних Hotel.

Оператор DDL, "CREATE TABLE Person" призначена для створення таблиці Person.

Визначений стовпець PersonID є ідентифікаційним стовпцем таблиці Person. Розташований наприкінці цього рядка оператор NOT NULL, визначає обмеження, відповідно до якого стовпець PersonID не може зберігати значення NULL. Подібне обмеження накладається на всі ідентифікаційні стовпці й первинні ключі таблиць.

Далі визначається ім'я обмеження первинного ключа таблиці Person.

В наступних рядках коду визначаються стовпці FirstName, SurName, Address. Вони призначений для зберігання даних типу VARCHAR довжиною до 50 символів й, подібно стовпцю Personl, не може зберігати значення NULL.

В курсовій роботі були застосовані довідкові таблиці - Country, City, AddressType, Paymant, Comfort, Post. Ця назва, з одного боку, виправдується наявністю в них лише декількох стовпців. Ці таблиці використовуються для зберігання різних типів даних (наприклад таблиця AddressType використовується для збереження різних типів адрес, які може мати людина, наприклад домашню та службову). Перевага використання довідкових таблиць полягає в тому, що, якщо згодом буде потрібно додати ще кілька типів даних, це можна зробити без зміни моделі даних.

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

Таблиця Country використовується для зберігання різних назв країн, в яких може проживати людина. Дана таблиця міститиме 2 стовпці: ідентифікаційний стовпць CountryID, та Description, де і представлено перелік різних країн.

Створення таблиці Country реалізується за допомогою наступного коду CREATE TABLE Country (додаток Г )

Проаналізуємо даний код: оператор DDL, "CREATE DATABASE Country" призначений для створення таблиці Country, стовпець CountryID є ідентифікаційним стовпцем таблиці Country. Розташований наприкінці оператор NOT NULL, визначає обмеження, відповідно до якого стовпець CountryID не може зберігати значення NULL. Далі представлене обмеження первинного ключа таблиці Country. конецформыначалоформыВ наступному рядку В наступному рядку визначається другий стовпець таблиці Country, що має ім'я Description. Він призначений для зберігання даних типу VARCHAR довжиною до 50 символів й, не може зберігати значення NULL.

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

Створення таблиці City реалізується наступним чином за допомогою коду CREATE TABLE City(див. додаток Г)

Оголошення таблиці City багато в чому подібно оголошенню попередньої таблиці Country.

Ще одна довідкова таблиця представлена у курсовій роботі - AddressType, вона використовується для зберігання різних типів адрес.

Код створення таблиці AddressType представлений у додатку Г:

Майже всі характеристики таблиць Country і City повністю збігаються з характеристиками таблиці AddressType,

Таблиця Address використається для зберігання адрес людини Таблиця складається з наступних стовпців PersonID, AddressTypeID, CatyID, CountryID, Address. Стовпці PersonID, AddressTypeID, CatyID, CountryID є ідентифікаційними стовпцями. Стовпець Address при значений для виводу адрес.

Код створення таблиці Address представлений наступним чином:

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

Необхідно також створити таблицю Post. Ця таблиця призначена для зберігання назв посад, які може займати співробітник в готелі. Код за допомогою якого була створена дана таблиця приведений в додатку Г

Оголошення таблиці Post багато в чому подібно оголошенню таблиць Country, AddressType та City.

Наступна таблиця яку необхідно створити – таблиця Employee. В курсовій роботі вона використовується для збереження інформації про співробітників готелю Дана таблиця маститиму 7 стовпців: EmployeeID, PersonID, TypeHotelRoom, IdentCodeEmployee, PostID, TypeHotelRoomID, Salary. Код створення таблиці Employee представлений у додатку Г.

Оператор CREATE TABLE, вказує на необхідність створення нової таблиці з ім'ям Employee.

Далі визначається перший стовпець таблиці Employee. Це стовпець типу INT, що носить ім'я EmployeeID. Стовпець EmployeeID є ідентифікаційним стовпцем таблиці Employee. Оператор NOT NULL, визначає обмеження, відповідно до якого стовпець EmployeeID не може зберігати значення NULL.

Наступний крок визначання ім'я обмеження первинного ключа таблиці Employee. Визначаємо власне ім'я обмеження первинного ключа - PK_ EmployeeID.

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

Необхідно, також, вказати стовпці, що належатимуть таблиці Employee, ці стовпці матимуть ім'я PersonID, TypeHotelRoom, IdentCodeEmployee, PostID, TypeHotelRoomID, Salary відповідно. Вони подібно стовпцю Employee, не можуть зберігати значення NULL.

Наступним кроком є необхідність додавання в таблицю Employee нового обмеження з ім'ям FK_Employee_Person (зовнішній ключ, що зв'язує таблиці Employee й Person).

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

Необхідно вказати, що створений зовнішній ключ таблиці Employee буде посилатися на стовпець PersonID таблиці Person.

Наступний крок - вказується необхідність додавання в таблицю Employee обмеження з ім'ям FK_Employee_Post. Та визначається тип обмеження FK_Employee_ Post.

Далі вказується, що створений зовнішній ключ таблиці Employee буде посилатися на стовпець PostID таблиці Post.

Для таблиці Emploee необхідно створит унікальне індексування. Реалізується за наступним кодом CREATE UNIQUE NONCLUSTERED INDEX представленого у додатку Г.

Щоб зберегти та відобразити інформацію про клієнтів готелю необхідно в базі даних створити таблицю Client. Дана таблиці призначена для збереження інформації про клієнта, вона буде включати стовпці: PersonID, AddressID, OrderrID,ClientID.

Для створення цієї таблиці використовується наступний код CREATE TABLE Client представлений у додатку Г.

Оголошення таблиці Client багато в чому схоже до оголошення таблиці Employee.

Наступним кроком в розробці проекту є створення таблиці Orders, яка буде зберігати інформацію про клієнтські замовлення. Але так, як дана таблиця є зв’язаною з таблицями Comfort, Payment, TypeHotelRoom, то спочатку необхідно створити визначені таблиці.

Таблиця TypeHotelRoom призначена для збереження інформації про тип номерів готелі. Дана таблиця буде включати наступні стовпці TypeHotelRoomID, Decription, PostID, EmployeeID. TypeHotelRoomID представляє собою ідентифікаційний стовпець. В стовпці Decription призначений для виведення типів номерів представлених у готелі

Створення цієї таблиці реалізується за допомогою коду CREATE TABLE TypeHotelRoom, представленого в додатку Г.

Таблиця Comfort є довідкові таблицею вона призначена для збереження інформації про тип комфортності номерів готельного комплексу дана таблиця складається з двох стовпців Comfort ID, та Description, де і представлено перелік різних типів комфортності готельних номерів.

Створення таблиці Comfort реалізується за допомогою коду CREATE TABLE Comfort представленому в додатку Г.

Майже, всі характеристики раніше використаних довідкових таблиць повністю збігаються з характеристиками таблиці Comfort.

Наступна таблиця яка є необхідною в даній роботі – це таблиця Payment, яка зберігає тип оплати клієнтами готельних послуг. Створення таблиці Payment реалізується з використанням коду CREATE TABLE Payment (додаток Г)

Оголошення цієї таблиці подібне оголошень всіх раніше використаних довідкових таблиць.

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

Оператор CREATE TABLE, вказує на необхідність створення нової таблиці з ім'ям Orders.

Далі вказується, що первинний ключ таблиці Orders, що був визначений. Ключове слово CLUSTERED установлює порядок фізичного зберігання даних.

Необхідно, також визначити стовпці таблиці Orders, які мають назви TypeHotelRoomID, ClientID, ComfortID, PaymantID, TimeResidence відповідно. Вони не можуть зберігати значення NULL.

Наступний крок - вказується необхідність додавання в таблицю Orders нового обмеження з ім'ям FK_Orders_TypeHotelRoom (зовнішній ключ, що зв'язує таблиці Orders й TypeHotelRoom).

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

Вказується, що створений зовнішній ключ таблиці Orders буде посилатися на стовпець TypeHotelRoom ID таблиці TypeHotelRoom.

Аналогічно оголошенню обмеження FK_Orders_TypeHotelRoom в таблицю Orders додаються обмеження FK_Orders_Client, FK_Orders_Comfort, CONSTRAINT FK_Orders_Paymant.

2.3 Забезпечення декларативної цілісності реляційних даних
Забезпечення декларативної цілісності реляційних даних здійснюється на основі використання обмежень: PRIMARY KEY, UNIQUE, FOREIGN KEY й CHECK.

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

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

Перші механізми обмеження цілісності були уведені з версії SQL Server 7.0. У більше ранніх версіях СУБД доводилося вручну перевіряти унікальність значень (або використати унікальні індекси), перебираючи всі рядки, або генерувати унікальні значення по спеціальних алгоритмах. Працюючи з SQL Server 2005, можна не турбуватися про це. Сервер сам відслідковує унікальність значень.

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

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

Є п'ять класів обмежень цілісності, що розрізняються по функціональності й області застосування:

- Обмеження цілісності PRIMERY KEY (первинний ключ). Діє на рівні стовпця або таблиці. Первинний ключ складається з одного або декількох стовпців, що унікально ідентифікують рядок у межах таблиці. Якщо для генерації первинного ключа використається єдиний стовпець, то для цього стовпця повинне бути встановлене обмеження цілісності UNIQUE для гарантії унікальності значень у стовпці. Ні для одного зі стовпців, включених у первинний ключ, не повинне бути встановлене властивість NULL. В якості унікального ключа у таблиці може бути використаний один з декількох стовпців або їхніх комбінацій. Всі ці комбінації є кандидатами на первинний ключ (можливими ключами). Адміністратор вибирає тільки одного кандидата й створює на його базі первинний ключ. Таким чином, у таблиці може бути створений тільки один первинний ключ.

- Обмеження цілісності UNIQUE (унікальність). Діє на рівні стовпця й гарантує унікальність значень у стовпці. У таблиці не може бути двох рядків, що мають однакове значення в стовпці із установленим обмеженням цілісності UNIQUE. На відміну від первинного ключа, обмеження цілісності UNIQUE допускає зберігання значень NULL.

Обмеження цілісності NULL. Діє на рівні стовпця й користувальницького типу даних. Встановлюючи обмеження цілісності NULL або NOT NULL, можна відповідно дозволяти або забороняти зберігання значень NULL.

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

- Обмеження цілісності FOREING KEY (зовнішній ключ). Створюється на рівні таблиці. Зовнішній ключ зв'язується з одним з кандидатом на первинний ключ в іншій таблиці. Таблиця, у якій визначений зовнішній ключ, називається залежною, а таблиця з кандидатом на первинний ключ — головною. У залежну таблицю не можна вставити рядок, якщо зовнішній ключ не має відповідного значення в головній таблиці. Крім того, з головної таблиці не можна видалити рядок, якщо з нею зв'язаний хоча б один рядок у залежній таблиці. Перед видаленням рядка з головної таблиці необхідно попередньо видалити всі рядки із залежної таблиці.

- Обмеження цілісності СНЕСК (перевірка). Це обмеження цілісності діє на рівні стовпця й обмежує діапазон значень, які можуть бути збережені в стовпці. При визначенні цього обмеження цілісності вказується логічна умова для даних, що вводять. При введенні або зміні даних уводиться значення, що підставляється в умову. Якщо в результаті перевірки повертається значення «істина» (TRUE), то зміни даних приймаються. Якщо ж перевірка повертає «неправда» (FALSE), то зміни даних відкидаються й генерується повідомлення про помилку. Для одного стовпця можна створити кілька обмежень цілісності CHECK.

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

Діаграми використовуються лише на рівні Enterprise Manager. Тому не можна створити діаграму за допомогою команд Transact – SQL. Призначення діаграми полягає в тому, щоб полегшити адміністрування бази даних.

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

РОЗДІЛ 3 Розробка об’єктів для доступу до реляційним даним
3.1 Розробка об'єктів для маніпулювання даними
Зберігаюча процедура – іменований набір команд Transact – SQL, що зберігається безпосередньо на сервері, що представляє собою, даних. Завдяки зберігаючим процедурам користувачеві не доводиться знову й знову вводити той самий набір команд для виконання якої-небудь дії. Якщо, ви часто виконуєте однотипні операції з досить більшою кількістю команд, ви рано або пізно захочете полегшити собі життя, реалізувавши цей набір команд у вигляді збереженої процедури. У результаті сервер буде послідовно виконувати всі команди, включені в процедуру

Зберігаючі процедури існують незалежно від таблиць або яких-небудь інших об'єктів баз даних. Зберігаюча процедура може бути викликана клієнтською
програмою, іншою збереженою процедурою або тригером. Можна управляти правами доступу користувачів до збережених процедур, дозволяючи або заборонити її виконання. Змінювати ж код збереженої процедури може тільки її власник або члени фіксованої ролі бази даних. При необхідності можна передати права володіння зберігаючою процедурою від одного користувача до іншого.
Використання збережених процедур має багато переваг:

- Перш ніж виконати зберігаючу процедуру, SQL Server 2005 генерує для неї так званий план виконання, виконує її оптимізацію й компіляцію. Таким чином, при першому виклику зберігаючої процедури сервер витрачає час і ресурси не тільки на виконання команд процедури, але й на підготовку їх до виконання, що вимагає чимало ресурсів. Для підвищення продуктивності SQL Server 2005 виконує кешування плану виконання процедури, а також оптимізованого й відкомпільованого коду. При повторному виклику тієї ж процедури сервер не витрачає ресурси на підготовку, а відразу ж приступає до виконання команд, скориставшись уже наявними даними Таким чином, збережені процедури дозволяють підвищити швидкість виконання операцій, тому що при повторному використанні вони вже завантажені в пам’яті, де знайти їх можна набагато легше, ніж на диску, до того ж не потрібна повторна компіляція й оптимізація.

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

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

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

В курсовій роботі було розроблено 2 зберігаючих процедури: CREATE PROCEDURE PersonClientInsert та CREATE PROCEDURE PersonEmpInsert. Коди розробки зберігаючих процедури представлені в додатку Д

Найменші труднощі при розгляді наведеного вище коду викликає знайомий оператор INSERT. Єдиною відмінністю від класичного варіанта використання цього оператора є наявність змінних у пропозиції VALUES, що дозволяє змінювати внесену в таблиці Person й Employee інформацію, не переписуючи всього оператора Transact-SQL. Оскільки в заголовку збереженої процедури були визначені типи всіх змінних, можна не піклуватися про висновок у лапки внесених у таблицю строкових значень.

Розглянемо спосіб внесення інформації в таблицю Employee.

Найбільш важливий момент, що стосуються внесення інформації в таблицю Employee - необхідність добування з таблиці Person значення відповідного тільки що внесеним даним первинного ключа Personl.

Необхідно звернути увагу на оголошення змінної @PersonID у. розташований далі оператор, привласнює значення цієї змінної, рівне значенню стовпця PersonID у тільки що внесеної в таблицю Person нового запису. Оскільки Рersonl є ідентифікаційним стовпцем таблиці Person, варто скористатися деяким спеціальним методом добування інформації із цього стовпця.

MS SQL Server надає кілька різних методів добування інформації з ідентифікаційного стовпця таблиці, однак у цьому випадку для виконання цієї операції скористаємося функцією IDENT_CURRENT. Як аргумент ця функція приймає ім'я таблиці, а як результат повертає значення первинного ключа останньої внесеної в таблицю запису.

Значення первинного ключа PersonID останньої внесеної в таблицю Person запису необхідно для створення відповідного йому зовнішнього ключа таблиці Employee, що дозволить встановити зв'язок між записами обох таблиць. Наявність такого зв'язку надто важливо для цілісності бази даних взагалі й для проведення об'єднань таблиці Employee з іншими таблицями зокрема. Значите первинного ключа таблиці Person привласнюється локальної змінної @PersonID і передається як параметр у наступний оператор INSERT.

Оператор INSERT, здійснює внесення інформації в таблицю Employee. Виконаєте код, у результаті чого MS SQL Server поверне повідомлення, що підтверджує успішне створення збереженої процедури.

Для того щоб упевнитися в працездатності тільки що створеної збереженої процедури, її необхідно хоча б один раз виконати. Але перед цим давайте здійснимо додаткову перевірку зберігаюча в таблицях Person й Employee інформації й переконаємося в тім, що її внесення, принаймні теоретично, пройде коректно. Процедура CREATE PROCEDURE PersonClientInsert дуже схожа на попередню.
3.2 Розробка об'єктів для відображення реляційних даних
Представлення для кінцевих користувачів виглядає як таблиця але при цьому не містить даних, а лише представляє дані, розташовані в таблиці. Фізично Представлення реалізоване у вигляді запиту SQL, на основі якого виробляється вибірка даних з однієї або декількох таблиць або подань. Таким чином, Представлення - це віртуальні таблиці, обумовлені запитом. Подібно реальним таблицям, представлення містять іменовані стовпці й рядки з даними, які вони динамічно вибирають із таблиць і пропонують користувачеві як самостійні дані.

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

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

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

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

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

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

Завдяки схожому з таблицею поводженню, представлення дозволяє виконати стосовно нього характерні для таблиць функції. Це має на увазі можливість використання таких операторів керування даними, як INSERT, UPDATE й DELETE, хоча тут існують деякі специфічні обмеження.

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

- можливість приречення структури даних для перегляду кінцевим користувачем;

- можливість обмеження прав на перегляд представлення;

- можливість використання представлення для створення звітності.

В даній курсовій роботі використано 2 представлення PersonAddress та OrdersData. Код використання представлення розмішений в додатку Д.

Оператор CREATE VIEW вказує СУБД на створення представлення PersonAddress. Ключове слово AS вказує на початок оператора. Увесь наступний за цим словом код визначає поведінку данного представлення.

Далі йде перелік стовпців, які необхідно витягти з бази даних . Наявність додаткових префіксів (Р., А. і т.п.) перед кожним ім'ям стовпця. Подібна практика іменування стовпців відома як використання псевдонімів. Використання псевдонімів (aliasing) - досить розповсюджений термін у більшості мов програмування. Цей термін позначає присвоєння об'єкту "дружнього" імені (як правило, скороченого). Використання псевдоніма дозволяє на короткий період змінити ім'я об'єкта. MS SQL Server допускає призначення псевдонімів для досить великої кількості об'єктів бази даних, підтвердженням тому може служити призначення псевдонімів для таблиць (наприклад, псевдонім 'А' позначає таблицю Address) і для стовпців (наприклад, псевдонім 'Country' відповідає стовпцю С.Description) у наведеному вище визначенні подання PersonAddress.

Використання псевдонімів в іменах стовпців дозволяє явно вказати таблиці, з яких були взяті ці стовпці. Слід зазначити, що в цьому твердженні криється невелика неточність, тому що, наприклад, у наведеному вище коді був використаний псевдонім А, хоча в дійсності таблиці з таким ім'ям у базі даних немає. Визначення псевдоніма стовпця дозволяє призначити ім'я, яке цей стовпець буде мати в представленні. У цьому випадку стовпцю Description таблиці Country був призначений псевдонім Country, а стовпцю Description таблиці AddressType - псевдонім AddiessType.

Далі визначається рядок що являється джерелом даних для оператора SELECT.

Розмішений далі код призначений для витягу інформації з інших таблиць бази даних за допомогою використання оператора INNER JOIN. Цей оператор указує MS SQL Server на необхідність об'єднання результатів запиту з даними, які зберігаються в таблиці, зазначеної безпосередньо після ключового слова INNER JOIN. Наприклад, вказується необхідність об'єднання таблиці Person з таблицею Address. Використовуючи оператор INNER JOIN, варто обов'язково вказати спосіб об'єднання двох таблиць. У випадку з таблицями Person й Address об'єднання здійснюється по первинному ключу таблиці Person (P.Personl) і зовнішньому ключу таблиці Address (A. Personl). Таким чином ми вказуємо MS SQL Server на необхідність об'єднання інформації, що зберігається в таблицях.

Оператори INNER JOIN виконують об'єднання таблиці Address із двома іншими таблицями, які містять первинний ключ, що відповідає зовнішньому ключу таблиці Address.

Далі виконується об'єднання таблиць Address й AddressType. Це досягається шляхом зв'язування первинного ключа таблиці AddressType (AddressTypel) і зовнішнього ключа таблиці Address (AddressTypel). Аналогічним образом (тобто використовуючи зовнішній ключ однієї й первинний ключ іншої таблиці) у рядках 6 й 6а виконується об'єднання таблиць Address й Country.

Розробка об'єктів для обробки подій в базі даних

Залежно від виконуваних користувачем дій, що приводять до запуску тригера, вони діляться на три категорії:

- тригери зміни (UPDATE TRIGGER);

- тригери вставки (INSERT TRIGGER);

- тригери видалення (DELETE TRIGGER).

Починаючи з SQL Server 7.0., з'явилася можливість визначати для таблиці кілька тригерів кожного типу. У попередніх версіях SQL Server для кожної таблиці можна було створити тільки один тригер кожного типу. Крім того, дії, виконувані в одному тригері, можуть привести до виклику інших тригерів. У цьому випадку використаються вкладені тригери

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

Область застосування тригерів досить широка. Наприклад, при реплікації відомістю тригери використаються для відстеження всіх виконуваних у таблиці змін. Тригери збирають інформацію про вироблені зміни й зберігають її в системних таблицях підтримки реплікації. Тригери також дозволяють створювати складні значення за замовчуванням, обчислюючи їх за допомогою даних декількох стовпців таблиць і функцій Transact - SQL. Іншим прикладом використання тригерів є забезпечення нестандартної цілісності посилань, підтримка якої звичайними засобами SQL Server неможливо. Крім того, за допомогою тригерів можна виконувати каскадні зміни в декількох зв'язаних таблицях

Область застосування тригерів не обмежується якимись строго обкресленими рамками. Можна вільно застосовувати тригери за своїм розсудом виходячи з вимог до зручності й продуктивності.

В курсовій роботі було використано 2 тригери CREATE TRIGGER CheckEmployeeNotInClient та CREATE TRIGGER CheckClientNotInEmployee. Код використання тригерів пердставлений у додатку Д.

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

Далі визначаються події, з якими повинен бути асоційований тригер. Тригер CheckClientNotInEmployee асоціюється відразу із двома подіями таблиці Client - INSERT й UPDATE. При бажанні можна зв'язати тригер з усіма подіями таблиці (DELETE, INSERT й UPDATE) або ж тільки з одним з них.

Ключові слова AS повністю збігається з його призначенням в оголошеннях подань і збережених процедур.

Розташований далі спеціальний оператор, головна функція якого - гарантувати можливість повернення до попереднього стану таблиці у випадку внесення (INSERT)в неї некоректної інформації.

Далі оголошуються змінні , які будуть використані для зберігання значення стовпця PersonID тільки що внесеної в таблицю запису й значення стовпця Employeel таблиці Employee.

Майже всю частину, що залишилася, тригера займає оператор SELECT, призначений для перевірки наявності запису із заданим ідентифікаційним номером у таблиці Employee. Розташований у далі оператор SELECT виконує функцію присвоєння змінної @PersonID значення стовпця PersonID тільки що внесеної в таблицю Client запису.

Керуючий оператор IF, здійснює перевірку значення змінної @EmployeeID. Якщо змінна не має ніякого значення, то виконання тригера переходить у рядок ELSE. COMMIT TRANSACTION оператор, що підтверджує правочинність зміни інформації в таблиці.

Код, RAISERROR ('Попытка вставить в таблицу Employee объект, присутствующий в таблице Client.'16, 1) ROLLBACK TRANSACTION, повідомляє користувача про помилку що виникла. Для цього використається убудована функція MS SQL Server RAISERROR.

ВИСНОВОК
В процесі розробки даного проекту було створено базу даних, що веде облік замовлень клієнтів та містить всю поточну інформацію про готельний комплекс.

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

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

В даній роботі як інструмент створення та ведення БД використовувався програмний продукт MS SQL 2005.

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

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

В ході курсової роботи були використані збережені процедури, тригери, представлення.

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

Хансен Г., Хансен Дж. Базы данных: разработка и управление: англ.- М.: БИНОМ, 2000.- 704 c.- ISBN 5-7989-0015-0.
Дейт К.Дж. Введение в системы баз данных: англ: .- 6-е изд..- К.-М.: Диалектика, 1998.- 784 c.- ISBN 966-506-124-0.
Мамаев Е., Шкарина Л. Microsoft SQL Server 2000 для профессионалов.- СПб.: Питер, 2001.- 1088 c.- ISBN 5-272-00339- Х.
Галузинський Г.П., Гордієнко І.В. Перспективні технологічні засоби оброблення інформації: Навчально-методичний посібник: Навчальне видання.- К.: КНЕУ, 2002.- 280 c.- ISBN 966-574-359-7.
Когаловский М.Р. Энциклопедия технологий баз данных.- М.: Финансы и статистика, 2002.- 800 c.- ISBN 5-279-02276-4.
Косенко Е. Реванш встроенных СУБД. Часть первая. Выбор подхода или подход к выбору? // Компьютеры + программы (рус.).- 2002.- № 4.- C.50-54.
Хоторн Р. Разработка баз данных Microsoft SQL Server 2000 на примерах: англ.- М.: Вильямс, 2001.- 464 c.- ISBN 5-8459-0187-1. УДК – 004.65
Литвин І.С. Інформаційні технології в економіці: Навчальний посібник.- Тернопіль: Економічна думка, 2001.- 296 c.- ISBN 5-7763-0459-8
1.Астахова И.Ф., Толстобров А.П. Мельников В.М. SQL в примерах и задачах: Учебное пособие: Навчальне видання.- Минск: Новое знание, 2002.- 176 c.- ISBN 985-475-004-3.
Лизун А. Работа с датами в MS-SQL // ARGC & ARGV (рус.).- 2001.- № 6.- C.42-45.

ДОДАТОК А. ER – модель “сутність-зв'язок”

1 2 3

скачати