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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Курсова робота

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

з дисципліни «Технологія проектування та адміністрування БД і СД»

Арєхов М.М.

Суми 2013

Завдання на курсову роботу

1. Тема роботи: Проектування бази даних готельного комплексу

2. Початкові данні, позначка роботи:

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

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

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

Готельний комплекс збирає відомості про клієнтів: ім'я, прізвище, адреса, статус.

В готелі необхідно реєструвати, замовлення з моменту його прийому співробітником(адміністратором) до оплати послуг клієнтом. У замовленні необхідно враховувати відомості про тип номера, комфортність, клієнта, що проживатиме в номері, робітника, що обслуговуватиме даний номер, число замовлень одним клієнтом, та період проживання клієнта в готелі, спосіб оплати й спосіб замовлення.

Способи оплати бувають: готівкою, чеком і за допомогою кредитної картки. Способів замовлення чотири: 1) замовлення підлягає відправці, 2) замовлення буде одержане особисто, 3) замовлення відправлене й 4) замовлення одержане. У замовленні фігурує тільки клієнт й один співробітник.

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

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

Зміст

Вступ

Розділ 1. Моделювання реляційної бази даних

1.1 Систематизація вимог до бази даних

1.2 Семантичне моделювання даних

1.3 Нормалізація структури даних

Розділ 2. Створення бази даних і базових таблиць

2.1 Вибір технологічного інструментарію для реалізації проекту

2.2 Розробка сценаріїв для створення бази даних і базових таблиць

2.3 Забезпечення декларативної цілісності реляційних даних

Розділ 3. Розробка об'єктів для доступу до реляційним даним

3.1 Розробка об'єктів для маніпулювання даними

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

3.3 Розробка об'єктів для відображення реляційних даних

Висновок

Список використаної літератури

Додатки

Вступ

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

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

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

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

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

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

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

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

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

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

Готельний комплекс збирає відомості про клієнтів: ім'я, прізвище, адреса, статус.

В готелі необхідно реєструвати, замовлення з моменту його прийому співробітником(адміністратором) до оплати послуг клієнтом. У замовленні необхідно враховувати відомості про тип номера, комфортність, клієнта, що проживатиме в номері, робітника, що обслуговуватиме даний номер, число замовлень одним клієнтом, та період проживання клієнта в готелі, спосіб оплати й спосіб замовлення.

Способи оплати бувають: готівкою, чеком і за допомогою кредитної картки. Способів замовлення чотири: 1) замовлення підлягає відправці, 2) замовлення буде одержане особисто, 3) замовлення відправлене й 4) замовлення одержане. У замовленні фігурує тільки клієнт й один співробітник.

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

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

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

При розробці даного проекту бази даних були визначені наступні цілі як:

- Забезпечити можливість ефективного керування інформацією про співробітників і клієнтів готельного комплексу;

- Реалізувати механізм ефективного розподілу ресурсів між різними клієнтськими заявками на обслуговування;

- Якісно й вчасно обслужити всі заявки клієнтів.

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

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

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

Для реалізації цього проекту обрана MS SQL 2005.

Однією з переваг SQL Server є простота його застосування, зокрема адміністрування. SQL Server Manager є повно функціональний і достатньо простий засіб для адміністрування цієї СУБД.

Сервер баз даних SQL Server 2005 дозволяє використовувати на одному комп'ютері декілька одночасно працюючих серверів.

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

Існує підтримка мови XML, включаючи ключове слово FOR XML для витягання даних у вигляді XML-потоків.

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

Розширені можливості фільтрації публікованих даних, існує можливість трансформації публікованих даних із застосуванням сервісів трансформації даних (Data Transformation Services).

У SQL Server 2005 підтримується можливість завдання альтернативних публікаторів інформації, що дозволяє синхронізувати дані навіть в тих випадках, коли первинний публікатор недоступний.

Розділ 1. Моделювання реляційної структури БД

1.1 Систематизація вимог до бази даних

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

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

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

При розробці даного проекту бази даних були визначені наступні цілі як:

- Забезпечити можливість ефективного керування інформацією про співробітників і клієнтів готельного комплексу;

- Реалізувати механізм ефективного розподілу ресурсів між різними клієнтськими заявками на обслуговування;

- Якісно й вчасно обслужити всі заявки клієнтів.

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

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

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

Кожній людині ставляться у відповідність властивості (properties), або атрибути (attributes), які можуть містити в собі ім'я, суспільне становище, адреса проживання, а також рід занять людини.

Підсумовуючи сказане, необхідно деталізувати використовувані сутності:

- "Співробітники готелю" - ім'я, прізвище, посада й заробітна плата, індефікаційній код,;

- "Клієнти готелю" - ім'я,прізвище, адреса, замовлення;

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

1.2 Семантичне моделювання даних

проектування база дані готельний

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

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

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

Отже важливим етапом даної курсової роботи є розробка діаграми відносин між об'єктами, або, як її ще називають, діаграми "сутність-зв'язок" (Entity Relationship Diagram- ERD). Так, як необхідно зберігати інформацію про співробітників готелю, то логічніше всього було б представити її в відповідній таблиці. Це ж відноситься і до інформації про клієнтів готелю. Процес визначення структур даних, необхідних для зберігання інформації проекту, називається моделюванням даних.

Моделювання даних - це процес наочного зображення схеми бази даних, потоків даних, а також способу зв'язку окремих таблиць бази даних. Моделювання даних здійснюється із застосуванням різних засобів, включаючи діаграму діаграму "сутність-зв'язок" (Entity Relationship Diagram- ERD).

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

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

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

Бази даних класифікують за моделями (або структурі) даних.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

№ Атрибута	Назва атрибута	Тип даних	Призначення атрибута
1	FirstName	Рядковий тип даних зі зміною довжиною	Призначений для виведення ім'я клієнта
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 - збереження цілих чисел	Індифікаційний стовпець таблиці
2	Description	Рядковий тип даних зі зміною довжиною	Призначений для виведення назв міст

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

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

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

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

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

№ Атрибута	Назва атрибута	Тип даних	Призначення атрибута
1	PersonID	Int - збереження цілих чисел	Індифікаційний стовпець таблиці
2	AddressTypeID	Int - збереження цілих чисел	Індифікаційний стовпець таблиці
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, що зберігається безпосередньо на сервері, що представляє собою, даних. Завдяки зберігаючим процедурам користувачеві не доводиться знову й знову вводити той самий набір команд для виконання якої-небудь дії. Якщо, ви часто виконуєте однотипні операції з досить більшою кількістю команд, ви рано або пізно захочете полегшити собі життя, реалізувавши цей набір команд у вигляді збереженої процедури. У результаті сервер буде послідовно виконувати всі команди, включені в процедуру.

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