2.3 Забезпечення декларативної цілісності реляційних даних
Забезпечення декларативної цілісності реляційних даних здійснюється на основі використання обмежень: PRIMARY KEY, UNIQUE, FOREIGN KEY й CHECK.
Обмеження цілісності - це механізм, що забезпечує автоматичний контроль даних за допомогою деяких установлених умов, або обмежень. Тобто обмеження цілісності використаються для забезпечення цілісності даних на логічному рівні.
Наприклад, якщо є дві таблиці, що зберігають логічно зв'язані дані, то можна визначити між ними зв'язок, щоб гарантувати, що з головної таблиці не будуть вилучені рядки, яким відповідають рядки в залежній таблиці. SQL Server забезпечує автоматичне відстеження зв'язків між таблицями, не видаляючи дані доти, доки не будуть вилучені всі зв'язані рядки із залежної таблиці. Іншим прикладом застосування обмежень цілісності є забезпечення унікальності ідентифікаційного номера службовця.
Перші механізми обмеження цілісності були уведені з версії SQL Server 7.0. У більше ранніх версіях СУБД доводилося вручну перевіряти унікальність значень (або використати унікальні індекси), перебираючи всі рядки, або генерувати унікальні значення по спеціальних алгоритмах. Працюючи з SQL Server 2000, можна не турбуватися про це. Сервер сам відслідковує унікальність значень.
Оптимізатор запитів використає обмеження цілісності для побудови оптимального плану виконання запиту. Обмеження цілісності може застосовуватися на рівні стовпця або на рівні таблиці.
Обмеження цілісності, які застосовувані на рівні стовпця, впливають тільки на значення, що вводять у цей стовпець. Якщо одне обмеження цілісності застосовується для декількох стовпців, то воно працює на рівні таблиці. Наприклад, якщо обмеження цілісності PRIMERY KEY включає один стовпець, то воно працює на рівні стовпця. Якщо ж PRIMERY KEY включає декілька стовпців, то це обмеження цілісності працює на рівні таблиці.
Є п'ять класів обмежень цілісності, що розрізняються по функціональності й області застосування.
Обмеження цілісності PRIMERY KEY (первинний ключ). Діє на рівні стовпця або таблиці. Первинний ключ складається з одного або декількох стовпців, що унікально ідентифікують рядок у межах таблиці. Якщо для генерації первинного ключа використається єдиний стовпець, то для цього стовпця повинне бути встановлене обмеження цілісності UNIQUE для гарантії унікальності значень у стовпці. Ні для одного зі стовпців, включених у первинний ключ, не повинне бути встановлене властивість NULL. В якості унікального ключа у таблиці може бути використаний один з декількох стовпців або їхніх комбінацій. Всі ці комбінації є кандидатами на первинний ключ (можливими ключами). Адміністратор вибирає тільки одного кандидата й створює на його базі первинний ключ. Таким чином, у таблиці може бути створений тільки один первинний ключ.
Обмеження цілісності UNIQUE (унікальність). Діє на рівні стовпця й гарантує унікальність значень у стовпці. У таблиці не може бути двох рядків, що мають однакове значення в стовпці із установленим обмеженням цілісності UNIQUE. На відміну від первинного ключа, обмеження цілісності UNIQUE допускає зберігання значень NULL.
Обмеження цілісності FOREING KEY (зовнішній ключ). Створюється на рівні таблиці. Зовнішній ключ зв'язується з одним з кандидатом на первинний ключ в іншій таблиці. Таблиця, у якій визначений зовнішній ключ, називається залежною, а таблиця з кандидатом на первинний ключ — головною. У залежну таблицю не можна вставити рядок, якщо зовнішній ключ не має відповідного значення в головній таблиці. Крім того, з головної таблиці не можна видалити рядок, якщо з нею зв'язаний хоча б один рядок у залежній таблиці. Перед видаленням рядка з головної таблиці необхідно попередньо видалити всі рядки із залежної таблиці.
Обмеження цілісності NULL. Діє на рівні стовпця й користувальницького типу даних. Встановлюючи обмеження цілісності NULL або NOT NULL, можна відповідно дозволяти або забороняти зберігання значень NULL.
Якщо стовпець забороняє зберігання значень NULL, то не можна вставляти рядки, що мають значення NULL для цього стовпця. NULL - це спеціальне значення, що представляє собою відсутність будь-якого значення.
Обмеження цілісності СНЕСК (перевірка). Це обмеження цілісності діє на рівні стовпця й обмежує діапазон значень, які можуть бути збережені в стовпці. При визначенні цього обмеження цілісності вказується логічна умова для даних, що вводять. При введенні або зміні даних уводиться значення, що підставляється в умову. Якщо в результаті перевірки повертається значення «істина» (TRUE), то зміни даних приймаються. Якщо ж перевірка повертає «неправда» (FALSE), то зміни даних відкидаються й генерується повідомлення про помилку. Для одного стовпця можна створити кілька обмежень цілісності CHECK.
В випадку, коли база даних включає велику кількість таблиць, що містять велику кількість індексів, об’єднаних в складну систему, досить складно представити всю її структуру. SQL Server 2000 включає в себе спосіб здатний полегшити розуміння структури бази даних. Цей спосіб називається діаграмою. Використовуючи діаграми можна наглядно представити структуру таблиць і зв’язки між ними.
Діаграми використовуються лише на рівні Enterprise Manager. Тому не можна створити діаграму за допомогою команд Transact – SQL. Призначення діаграми полягає в тому, щоб полегшити адміністрування бази даних.
Для відображення цілісної структури реляційних даних необхідно створити за допомогою редактора діаграм діаграму, у якій відображені всі таблиці бази даних, їхні атрибути, ключі й зв'язки між ними (додаток).
РОЗДІЛ 3 Розробка об’єктів для доступу до реляційним даним
3.1 Розробка об'єктів для маніпулювання даними
Збережена процедура – іменований набір команд Transact – SQL, що зберігається безпосередньо на сервері, що представляє собою, даних. Завдяки збереженим процедурам користувачеві не доводиться знову й знову вводити той самий набір команд для виконання якої-небудь дії. Якщо, ви часто виконуєте однотипні операції з досить більшою кількістю команд, ви рано або пізно захочете полегшити собі життя, реалізувавши цей набір команд у вигляді збереженої процедури. У результаті сервер буде послідовно виконувати всі команди, включені в процедуру
Збережені процедури існують незалежно від таблиць або яких-небудь інших об'єктів баз даних. Збережена процедура може бути викликана клієнтською програмою, іншою збереженою процедурою або тригером. Можна управляти правами доступу користувачів до збережених процедур, дозволяючи або заборонити її виконання. Змінювати ж код збереженої процедури може тільки її власник або члени фіксованої ролі бази даних dr_ower. При необхідності можна передати права володіння збереженою процедурою від одного користувача до іншого. Використання збережених процедур має багато переваг:
Перш ніж виконати збережену процедуру, SQL Server 2000 генерує для неї так званий план виконання, виконує її оптимізацію й компіляцію. Таким чином, при першому виклику збереженої процедури сервер витрачає час і ресурси не тільки на виконання команд процедури, але й на підготовку їх до виконання, що вимагає чимало ресурсів. Для підвищення продуктивності SQL Server 2000 виконує кешування плану виконання процедури, а також оптимізованого й відкомпілюваного коду. При повторному виклику тієї ж процедури сервер не витрачає ресурси на підготовку, а відразу ж приступає до виконання команд, скориставшись уже наявними даними Таким чином, збережені процедури дозволяють підвищити швидкість виконання операцій, тому що при повторному використанні вони вже завантажені в пам’яті, де знайти їх можна набагато легше, ніж на диску, до того ж не потрібна повторна компіляція й оптимізація.
Збережені процедури можуть складатися з десятків і сотень команд, але для їхнього запуску досить указати всього лише ім'я потрібної збереженої процедури. Це дозволяє зменшити розмір запиту, що посилає по мережі від клієнта на сервер. Таким чином, при використанні збережених процедур можливе зменшення навантаження на мережу
Використання збережених процедур реалізує принцип модульного проектування, тому що процедури дозволяють розбивати більші задачі на самостійні, більше дрібні й зручні в управлінні частини.
Таким чином, збережені процедури мають багато переваг у порівнянні зі звичайними пакетами, які зберігаються безпосередньо на робочій станції клієнта. При цьому процес взаємодії зводиться до послідовної передачі пакетів команд на сервер й одержанню результатів. Недоліки цього підходу очевидні, оскільки час доступу до даних значно збільшується, до того ж на додаток клієнта лягає додаткове навантаження. При використанні ж I збережених процедур клієнт здійснює тільки виклик збереженої процедури по її імені, потім сервер бази даних виконує блок команд, що становлять тіло викликаної процедури, і повертає клієнтові результат.
Залежно від виконуваних користувачем дій, що приводять до запуску тригера, вони діляться на три категорії:
тригери зміни (UPDATE TRIGGER);
тригери вставки (INSERT TRIGGER);
тригери видалення (DELETE TRIGGER).
Починаючи з SQL Server 7.0., з'явилася можливість визначати для таблиці кілька тригерів кожного типу. У попередніх версіях SQL Server 7.0 для кожної таблиці можна було створити тільки один тригер кожного типу. Крім того, дії, виконувані в одному тригері, можуть привести до виклику інших тригерів. У цьому випадку використаються вкладені тригери
Розробка об'єктів для відображення реляційних даних
Представлення для кінцевих користувачів виглядає як таблиця але при цьому не містить даних, а лише представляє дані, розташовані в таблиці. Фізично Представлення реалізоване у вигляді запиту SQL, на основі якого виробляється вибірка даних з однієї або декількох таблиць або подань. Таким чином, Представлення— це віртуальні таблиці, обумовлені запитом. Подібно реальним таблицям Представлення містять іменовані стовпці й рядки з даними, які вони динамічно вибирають із таблиць і пропонують користувачеві як самостійні дані.
Найпростіше подання, створене на основі однієї таблиці й не має фільтрів, містить точно такий же набір даних, як і вихідна таблиця. Більше" складні Представлення містять інформацію з декількох таблиць, причому можна фільтрувати список рядків, які будуть включені в подання.
Представлення можна розглядати як фільтр, що накладає на таблицю. Запит, що визначає подання, може вибирати дані з однієї або декількох таблиць, а також інших подань у поточній або іншій базі даних. Для визначення подання, що поєднує дані із множини різних джерел, можуть бути використані розподілені запити.
Представлення є потужним і зручним інструментом керування даними. Представлення часто застосовується для обмеження доступу користувачів до конфіденційних даних у таблиці. Якщо один зі стовпців таблиці необхідно сховати від користувачів (наприклад, дані про зарплату співробітників), то найпростішим виходом буде створення подання, що включає всі стовпці крім одного. Користувачі можуть працювати з поданням, не підозрюючи про існування у вихідній таблиці додаткового стовпця. Коли в Представлення не включається стовпець вихідної таблиці, говорять, що на таблицю накладений вертикальний фільтр. Якщо в SQL - коді запиту встановлено одне або кілька умов для вибірки рядків, говорять, що на таблицю накладений горизонтальний фільтр.
Представлення може бути використане для об'єднання даних з декількох взаємозалежних таблиць. Наприклад, нехай у першій таблиці втримуються ідентифікаційний номер що служить, його ім'я й прізвище, а в другий - ідентифікаційні номери проектів, у яких службовець брав участь.
с третьою таблицею по ідентифікаційному номері проекту. Третя таблиця містить ідентифікаційні номери проектів, їхньої назви, інформацію про керівників, строки завершення й т.д. Необхідно одержати список всіх проектів, у яких брав участь конкретний службовець. Можна спроектувати представлення таким чином, щоб воно містило ім'я й прізвище службовця й список проектів, у яких він брав участь. Проміжні дані (ідентифікаційні номери службовця й проектів) не будуть включені в представлення.
При звертанні до представлення сервер перевіряє правильність всіх посилань у запиті. Перевіряється, чи існують об'єкти, які потрібні для виконання визначальне представлення запиту. Якщо одна з таблиць, на які посилається запит, була знищена, то представлення виявиться непрацездатним, і при спробі звернутися до нього користувачі одержать повідомлення про помилку. Якщо ж замість вилученої таблиці створюється нова таблиця з таким же ім'ям і структурою, то Представлення можна буде використати знову. Якщо нова таблиця має структуру, відмінну від структури первісної таблиці, то Представлення повинне бути знищене й створене заново
Розробка об'єктів для обробки подій в базі даних
Тригер— це спеціальний тип збережених процедур, що запускають сервером автоматично при виконанні тих або інших дій з даними таблиці. Кожен тригер прив’язаний до конкретної таблиці. Коли користувач намагається, наприклад, змінити дані в таблиці, сервер автоматично запускає тригер й, якщо він завершується успішно, дозволяється виконання змін. Всі вироблені тригером модифікації даних розглядаються як одна транзакція. У випадку виявлення помилки або порушенні цілісності даних відбувається відкат цієї транзакції. Тим самим внесення змін забороняється. Скасовуються також всі зміни, уже зроблені тригером.
Область застосування тригерів досить широка. Наприклад, при реплікації відомістю тригери використаються для відстеження всіх виконуваних у таблиці змін. Тригери збирають інформацію про вироблені зміни й зберігають її в системних таблицях підтримки реплікації. Тригери також дозволяють створювати складні значення за замовчуванням, обчислюючи їх за допомогою даних декількох стовпців таблиць і функцій Transact - SQL. Іншим прикладом використання тригерів є забезпечення нестандартної цілісності посилань, підтримка якої звичайними засобами SQL Server неможливо. Крім того, за допомогою тригерів можна виконувати каскадні зміни в декількох зв'язаних таблицях
Область застосування тригерів не обмежується якимись строго обкресленими рамками. Можна вільно застосовувати тригери за своїм розсудом виходячи з вимог до зручності й продуктивності
СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ
Хансен Г., Хансен Дж. Базы данных: разработка и управление: англ.- М.: БИНОМ, 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)USEmaster
GO
CREATEDATABASEHotel
ONPRIMARY(NAME= 'Hotel_Data',
FILENAME='E:\УАБС\Технології реляційних баз даних\Hotel_Data.MDF',
SIZE = 5MB,
FILEGROWTH = 10%)
LOG ON (NAME = 'Hotel_Log',
FILENAME = 'E:\УАБС\Технології реляційних баз даних\Hotel_Log.LDF',
SIZE = 5MB,
FILEGROWTH = 10%)
GO
2) USE Hotel
GO
CREATE TABLE Person
(
PersonID INT IDENTITY(1,1)NOT NULL
PRIMARY KEY CLUSTERED,
FirstName VARCHAR(50)NOT NULL,
SurName VARCHAR(50) NOT NULL,
Address VARCHAR(50) NOT NULL,
)
3) CREATE TABLE Country
(
CountryID INT IDENTITY(1, 1) NOT NULL
CONSTRAINT PK_CountryID
PRIMARY KEY CLUSTERED,
Description VARCHAR(50) NOT NULL
)
4) CREATE TABLE City
(
CityID INT IDENTITY(1, 1) NOT NULL
CONSTRAINT PK_CityID
PRIMARY KEY CLUSTERED,
Description VARCHAR(50) NOT NULL
)
5) CREATE TABLE AddressType
(
AddressTypeID INT IDENTITY(1, 1) NOT NULL
CONSTRAINT PK_AddressTypeID
PRIMARY KEY CLUSTERED,
Description VARCHAR(50) NOT NULL
)
6) CREATE TABLE Address
(
PRIMARY KEY CLUSTERED(PersonID),
PersonID INT IDENTITY(1,1)NOT NULL,
AddressTypeID INT NOT NULL,
CityID INT NOT NULL,
CountryID INT NOT NULL,
Address VARCHAR(50)NOT NULL,
CONSTRAINT FK_Address_Person
FOREIGN KEY (PersonID)
REFERENCES Person(PersonID),
CONSTRAINT FK_Address_AddressType
FOREIGN KEY (AddressTypeID)
REFERENCES AddressType(AddressTypeID),
CONSTRAINT FK_Address_City
FOREIGN KEY (CityID)
REFERENCES City(CityID),
CONSTRAINT FK_Address_Country
FOREIGN KEY (CountryID)
REFERENCES Country(CountryID)
)
7)CREATE UNIQUE NONCLUSTERED INDEX IDX_Address_Person
ON Address(PersonID)7) CREATE TABLE Post
(
8) CREATE TABLE Post
(
PostID INT IDENTITY(1, 1) NOT NULL
CONSTRAINT PK_PostID
PRIMARY KEY CLUSTERED,
Description VARCHAR (50) NOT NULL
)
9) CREATE UNIQUE NONCLUSTERED INDEX IDX_Employee_Person
ON Employee(PersonID)
10) CREATE TABLE Employee
(
EmployeeID INT IDENTITY(1, 1) NOT NULL
CONSTRAINT PK_EmployeeID
PRIMARY KEY CLUSTERED (EmployeeID),
PersonID INT NOT NULL,
TypeHotelRoom INT NOT NULL,
IdentCodeEmployee VARCHAR(10) NULL,
PostID INT NOT NULL,
TypeHotelRoomID INT NOT NULL,
Salary MONEY NOT NULL,
CONSTRAINT FK_Employee_Person
FOREIGN KEY (PersonID)
REFERENCES Person(PersonID),
CONSTRAINT FK_Employee_Post
FOREIGN KEY (PostID)
REFERENCES Post(PostID),
)
11) CREATE UNIQUE NONCLUSTERED INDEX IDX_Client_Person
ON Client(PersonID)
12)CREATE TABLE TypeHotelRoom
(
TypeHotelRoomID INT IDENTITY(1, 1) NOT NULL
CONSTRAINT PK_PaymentTypeID
PRIMARY KEY CLUSTERED,
Decription VARCHAR (50) NOT NULL,
PostID INT NOT NULL,
EmployeeID INT NOT NULL,
CONSTRAINT FK_TypeHotelRoom_Employee
FOREIGN KEY (EmployeeID)
REFERENCES Employee(EmployeeID)
)
13) CREATE TABLE Comfort
(
ComfortID INT IDENTITY(1, 1) NOT NULL
CONSTRAINT PK_ComfortID
PRIMARY KEY CLUSTERED,
Description VARCHAR (50) NOT NULL
)
14) CREATE TABLE Payment
(
PaymentID INT IDENTITY(1, 1) NOT NULL
CONSTRAINT PK_PaymentID
PRIMARY KEY CLUSTERED,
Description VARCHAR (50) NOT NULL
)
15) CREATE TABLE Orders
(
PRIMARY KEY CLUSTERED (TypeHotelRoomID),
TypeHotelRoomID INT NOT NULL,
ClientID INT NOT NULL,
ComfortID INT NOT NULL,
PaymentID INT NOT NULL,
TimeResidence DATETIME NOT NULL
CONSTRAINT FK_Orders_TypeHotelRoom
FOREIGN KEY (TypeHotelRoomID)
REFERENCES TypeHotelRoom(TypeHotelRoomID),
CONSTRAINT FK_Orders_Client
FOREIGN KEY (ClientID)
REFERENCES Client(ClientID),
CONSTRAINT FK_Orders_Comfort
FOREIGN KEY (ComfortID)
REFERENCES Comfort(ComfortID),
CONSTRAINT FK_Orders_Payment
FOREIGN KEY (PaymentID)
REFERENCES Payment(PaymentID)
)
16) CREATE UNIQUE NONCLUSTERED INDEX IDX_Orders_Comfort
ON Orders(ComfortID)
17) CREATE UNIQUE NONCLUSTERED INDEX IDX_Orders_Paymant
ON Orders(PaymantID)
18) CREATE UNIQUE NONCLUSTERED INDEX IDX_Orders_TypeHotelRoom
ON Orders(TypeHotelRoomID)