48979

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

Курсовая

Информатика, кибернетика и программирование

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

Украинкский

2013-12-18

334 KB

44 чел.

Українська академія банківської справи

Національного банку України

Кафедра економічної кібернетики

КУРСОВА РОБОТА

з дисципліни „Технології реляційних  баз даних ”

на тему:

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

Виконала : студентка ІІІ курсу

Групи ЕК-41

Мусатова Л.О.

Нормоконтроль: Хайлук С.О.

Перевірив: Вахнюк С.В.

Суми  2006


ЗАВДАННЯ НА КУРСОВУ РОБОТОВІ

Студентові групи  ЕК-41   спеціальності  економічна кібернетика__________________________

_________________________Мусатовії Людмилі Олексіївні_____________________________

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

2. Термін здачі студентом закінченої роботи:     "__"_______200_ р.

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

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

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

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

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

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

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

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

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


Зміст

ВСТУП...........................................................................................................................5

РОЗДІЛ 1. Моделювання реляційної бази даних.......................................................9

  1.   Систематизація вимог до бази даних……………………………………………9
    1.   Семантичне моделювання даних…………………………………………….…10
    2.   Нормалізація структури даних………………………………………………….16

РОЗДІЛ  2. Створення бази даних і базових таблиць...............................................22

  1.   Вибір технологічного інструментарію для реалізації проекту..........................22
    1.   Розробка сценаріїв для створення бази даних і базових таблиць...…………..24
    2.   Забезпечення декларативної цілісності реляційних даних................................31

РОЗДІЛ 3  Розробка об’єктів для доступу до реляційним даним ..........................34

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

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

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

ВИСНОВОК.............................................................................................................. ..44

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

ДОДАТОК А................................................................................................................46

ДОДАТОК Б.................................................................................................................47

ДОДАТОК В................................................................................................................48

ДОДАТОК Г.................................................................................................................49

ДОДАТОК Г.................................................................................................................55

 
ВСТУП

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SQL Server 2000 поставляється в шести редакціях: Enterprise, Standard, Personal, Developer, Desktop Engine і SQL Server CE.

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

Версія Microsoft SQL Server 2000 побудована на основі ядра Microsoft SQL Server 7.0. Її відмітними особливостями є підвищена масштабованість, продуктивність і інтеграція з Internet.

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

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

В рамках підтримки посилальної цілісності, в SQL Server 2000 реалізовані каскадні видалення і оновлення (CASCADE DELETE, CASCADE UPDATE).

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

Для підвищення продуктивності тепер можна створювати індекси для уявлень (Indexed Views). У цій версії SQL Server підтримується створення індексів в убиваючому порядку.

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Клієнт готелю (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

2

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

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

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

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

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

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

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

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

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

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

- базу даних можна створити за допомогою програми Query Analyzer.


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

У роботі використається спосіб створення бази даних за допомогою програми Query Analyzer.

 конецформыначалоформыДлДля того щоб створити базу даних за допомогою програми Query Analyzer, варто скористатися оператором Transact-SQL CREATE DATABASE. Незважаючи на те що це один з найскладних способів, він дозволяє досягти найбільшої гнучкості. Слід зазначити, що це не єдина перевага використання програми Query Analyzer для створення бази даних. Оскільки мова побудови запитів 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 = 'E:\УАБС\Технології реляційних баз даних\Hotel_Data.MDF'  визначається місце розташування файлу даних.

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

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

FILENAME = 'E:\УАБС\Технології реляційних баз даних\Hotel_Log.LDF', визначені параметри журналу транзакцій повністю аналогічні відповідним параметрам файлу даних .

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

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

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

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

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

Для створення таблиць за допомогою  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, вказує Query Analyzer на необхідність створення нової таблиці з ім'ям 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, вказує Query Analyzer на необхідність створення нової таблиці з ім'ям 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 2000, можна не турбуватися про це. Сервер сам відслідковує унікальність значень.

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

Обмеження цілісності, які застосовувані на рівні стовпця, впливають тільки на значення, що вводять у цей стовпець. Якщо одне обмеження цілісності застосовується для декількох стовпців, то воно працює на рівні таблиці. Наприклад, якщо обмеження цілісності 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 2000 включає в себе спосіб здатний полегшити розуміння структури бази даних. Цей спосіб називається діаграмою. Використовуючи діаграми можна наглядно представити структуру таблиць і зв’язки між ними.

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

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

 


РОЗДІЛ 3  Розробка об’єктів для доступу до реляційним даним

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

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

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

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

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

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

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

В курсовій роботі  було розроблено 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.

Розмішений далы  код призначений для витягуінформації з інших таблиць бази даних за допомогою використання оператора INТER 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.

 


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

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

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

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

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

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

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

Область застосування тригерів досить широка. Наприклад, при реплікації відомістю тригери використаються для відстеження всіх виконуваних у таблиці змін. Тригери збирають інформацію про вироблені зміни й зберігають її в системних таблицях підтримки реплікації. Тригери також дозволяють створювати складні значення за замовчуванням, обчислюючи їх за допомогою даних декількох стовпців таблиць і функцій 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 2000.

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

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

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


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

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


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


ДОДАТОК Б  


ДОДАТОК В

USE master

GO

CREATE DATABASE Hotel

 ON PRIMARY (NAME = 'Hotel_Data',

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

SIZE = 5MB,

FILEGROWTH = 10%)

LOG ON (NAME = 'Hotel_Log',

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

 SIZE = 5MB,

 FILEGROWTH = 10%)

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,

)

GO

CREATE TABLE Country

(

CountryID INT IDENTITY(1, 1) NOT NULL

CONSTRAINT PK_CountryID

PRIMARY KEY CLUSTERED,

Description VARCHAR(50) NOT NULL

 )

GO

CREATE TABLE City

(

CityID INT IDENTITY(1, 1) NOT NULL

CONSTRAINT PK_CityID

PRIMARY KEY CLUSTERED,

Description VARCHAR(50) NOT NULL

 )

GO

CREATE TABLE AddressType

(

AddressTypeID INT IDENTITY(1, 1) NOT NULL

CONSTRAINT PK_AddressTypeID

PRIMARY KEY CLUSTERED,

Description VARCHAR(50) NOT NULL

 )

GO

CREATE TABLE Address

         (

         PRIMARY KEY CLUSTERED(PersonID,AddressTypeID,CityID,CountryID),

         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)

         )

GO

CREATE TABLE Post

(

PostID INT IDENTITY(1, 1) NOT NULL

CONSTRAINT PK_PostID

PRIMARY KEY CLUSTERED,

Description VARCHAR (50) NOT NULL

)

GO

CREATE TABLE Employee

(

EmployeeID INT IDENTITY(1, 1) NOT NULL

CONSTRAINT PK_EmployeeID

PRIMARY KEY CLUSTERED (EmployeeID),

PersonID INT NOT NULL,

PostID INT NOT NULL,

Salary VARCHAR(50) NOT NULL,

CONSTRAINT FK_Employee_Person

          FOREIGN KEY (PersonID)

          REFERENCES Person(PersonID),

CONSTRAINT FK_Employee_Post

          FOREIGN KEY (PostID)

          REFERENCES Post(PostID),

)

GO

CREATE TABLE Client

(

ClientID INT IDENTITY(1,1)NOT NULL

CONSTRAINT PK_ClientID

PRIMARY KEY CLUSTERED,

PersonID INT NOT NULL,

AddressID INT NOT NULL,

OrderrID INT NOT NULL,

Status VARCHAR(50) NOT NULL

CONSTRAINT FK_Client_Person

            FOREIGN KEY (PersonID)

            REFERENCES Person(PersonID))

GO

CREATE TABLE TypeHotelRoom

(

TypeHotelRoomID INT IDENTITY(1, 1) NOT NULL

CONSTRAINT PK_PaymentTypeID

PRIMARY KEY CLUSTERED,

Description VARCHAR (50) NOT NULL,

PostID INT NOT NULL,

EmployeeID INT NOT NULL,

CONSTRAINT FK_TypeHotelRoom_Employee

          FOREIGN KEY (EmployeeID)

          REFERENCES Employee(EmployeeID)

)

GO

CREATE TABLE Comfort

(

ComfortID INT IDENTITY(1, 1) NOT NULL

CONSTRAINT PK_ComfortID

PRIMARY KEY CLUSTERED,

Description VARCHAR (50) NOT NULL

)

GO

CREATE TABLE Payment

(

PaymentID INT IDENTITY(1, 1) NOT NULL

CONSTRAINT PK_PaymentID

PRIMARY KEY CLUSTERED,

Description VARCHAR (50) NOT NULL

)

GO

CREATE TABLE Orders

(

PRIMARY KEY CLUSTERED (TypeHotelRoomID,ClientID,ComfortID,PaymentID ),

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)

      )

      

GO

CREATE UNIQUE NONCLUSTERED INDEX IDX_Employee_Person

ON Employee(PersonID)

GO

CREATE UNIQUE NONCLUSTERED INDEX IDX_Orders_Comfort

ON Orders(ComfortID)

GO

CREATE UNIQUE NONCLUSTERED INDEX IDX_Orders_Payment

ON Orders(PaymentID)


ДОДАТОК Д  

CREATE PROCEDURE PersonEmpInsert

         @Firstname VARCHAR(50),

         @Surname VARCHAR (50),

         @Address VARCHAR (50),   

         

         @PostID INT = NULL,

         @Salary  INT = NULL

AS

       DECLARE @LocalError INT

       BEGIN TRANSACTION

                 INSERT INTO Person (Firstname, Surname, Address)

                 VALUES (@Firstname, @Surname, @Address)

         SET  @LocalError = @@ERROR

         DECLARE  @PersonID INT

         SET  @PersonID = IDENT_CURRENT('Person')

         INSERT INTO Employee (PersonID, PostID,

                  Salary)             

         VALUES (@PersonID, @PostID,

                  @Salary)

         SET @LocalError = @LocalError + @@ERROR

         IF @LocalError = 0         

         BEGIN

                   COMMIT TRANSACTION

                   PRINT 'Вы успешно добавили нового клиента в список'

         END     

         ELSE

         BEGIN

                   IF @LocalError = 547

                   BEGIN

                               ROLLBACK TRANSACTION

                               PRINT 'Ошибка ввода. Вы должны добавить

                 клиента в таблицу Person перед лобавлением его в таблицу Client'

                   END

                   ELSE

                   BEGIN

                               ROLLBACK TRANSACTION

                               PRINT 'Произошла ошибка, попробуйте повторить ввод '

                   END

         END

CREATE PROCEDURE PersonClientInsert

         @Firstname VARCHAR(50),

         @Surname VARCHAR (50),

        

         @Status  VARCHAR(25) =  NULL,

         

         @AddressTypeID VARCHAR(10),

         @CityID VARCHAR(10),

         @CountryID VARCHAR(10),

         @Address VARCHAR(10)

       

AS

         DECLARE  @PersonID INT

         INSERT INTO Person (Firstname, Surname, Address)

         VALUES (@Firstname, @Surname, @Address)

         SET  @PersonID = IDENT_CURRENT('Person')

         INSERT INTO Client (PersonID, Status)

         VALUES (@PersonID, @Status)

         INSERT INTO Address (AddressTypeID, CityID, CountryID, Address )

         VALUES (@AddressTypeID, @CityID, @CountryID, @Address)

         SET  @PersonID = IDENT_CURRENT('Person')

GO

Create view  OrdersData AS

SELECT

 P.Surname AS 'Фамилия',

               P.FirstName AS 'Имя',

               OT.Description AS 'Тип заказа',

               T.Description AS 'Тип транспорта'

FROM  Orders  O

 INNER JOIN Client C

  ON  O.ClientID = C.ClientID

 INNER JOIN Person P

  ON  C.PersonID = P.PersonID

               INNER JOIN OrderType OT

  ON  OT.OrderTypeID = O.OrderTypeID

               INNER JOIN Transport T

  ON  T.TransportID = O.TransportID

Go

CREATE VIEW PersonAddress AS

SELECT

 P.Firstname,

 P.Surname,

 A.Address,

 AType.Description AS AddressType

FROM  Person  P

 INNER JOIN Address A

  ON  P.PersonID = A.PersonID

 INNER  JOIN AddressType AType

  ON A.AddressTypeID = AType.AddressTypeID

CREATE TRIGGER CheckClientNotInEmployee

 ON Client

 FOR INSERT, UPDATE

 AS

 BEGIN TRANSACTION

      DECLARE @EmployeeID INT

      DECLARE @PersonID INT

      SELECT @PersonID = i.PersonID

      FROM inserted i

      SELECT @EmployeeID = EmployeeID

      FROM Employee E

      WHERE E.PersonID  =  @PersonID

      IF (@EmployeeID IS  NOT  NULL) AND (@EmployeeID > 0)

           BEGIN

                RAISERROR ('Попытка вставить в таблицу Client объект, присутствующий в

                                         таблице Employee.', 16, 1)

                ROLLBACK TRANSACTION

           END

      ELSE

           BEGIN

                COMMIT TRANSACTION

           END

GO

CREATE TRIGGER CheckEmployeeNotInClient

ON    Employee

FOR  INSERT, UPDATE

AS

         BEGIN TRANSACTION

         DECLARE @ClientID INT

         DECLARE @PersonID INT

         SELECT @PersonID = i.PersonID

         FROM inserted i

       SELECT @ClientID = ClientID

       FROM Client C

       WHERE C.PersonID = @PersonID

       IF (@ClientID IS NOT NULL) AND (@ClientID > 0)

          BEGIN

                   RAISERROR ('Попытка вставить в таблицу Employee объект,

                                         присутствующий в таблице Client.',                               

                                         16, 1)

                   ROLLBACK TRANSACTION

          END

       ELSE

          BEGIN

                   COMMIT TRANSACTION

          END


B

Post

FerstName

FerstName

Address

SurName

TypeHotelRoom

Payment

Comfort

SurName

Address

Orders

Employee

Client

TimeResidence


 

А также другие работы, которые могут Вас заинтересовать

18693. Схематичная конструкция жесткого диска (понятия цилиндр, дорожка, поверхность, сектор) 67.39 KB
  Схематичная конструкция жесткого диска понятия цилиндр дорожка поверхность сектор Говоря о магнитных дисках и жестких и гибких нельзя не сказать об их внутренней структуре. Ее составляют дорожки цилиндры и сектора. Дорожки tracks это концентрические окружности п
18694. Учет труда и заработной платы, регистры учета, среднемесячная заработная плата 16.41 KB
  Учет труда и заработной платы регистры учета среднемесячная заработная плата. Заработная плата это вознаграждение за труд в зависимости от квалификации работника сложности количества качества и условий выполняемой работы а также выплаты компенсационного и сти...
18695. Применение CASE-технологий при создании информационной системы 13.87 KB
  Применение CASEтехнологий при создании информационной системы. CASEтехнология представляет собой совокупность методологий анализа проектирования разработки и сопровождения сложных систем и поддерживается комплексом взаимоувязанных средств автоматизации. CASEтехноло...
18696. Анализ средств управления пакетом 16.36 KB
  Анализ средств управления пакетом. Система управления пакетами набор программного обеспечения позволяющего управлять процессом установки удаления настройки и обновления различных компонентов программного обеспечения. Системы управления пакетами активно исполь...
18697. Учет основных фондов 14.6 KB
  Учет основных фондов Учет наличия и движения основных фондов осуществляется бухгалтерией предприятия по состоянию на первое число каждого месяца и в среднем за год или другой анализируемый период. Учет наличия осуществляется по балансовой стоимости. Наличие основны
18698. Классификация источников информации в Интернете может производиться по разным основаниям 13.9 KB
  Классификация источников информации в Интернете может производиться по разным основаниям: 1. Webстраницы – наиболее распространенный и используемый из информационных ресурсов. Представляет собой страницы связанные гипертекстом. 2. Файловые серверы – представляют со...
18699. Проектирование логики модуля 16.07 KB
  Проектирование логики модуля Внутреннее проектирование один из последних этапов в длинной цепи процесса проектирования программного обеспечения. Оно представляет собой подробное внутреннее конструирование программного продукта разработку внутренней логики каж
18700. Показатели использования основных фондов и фондовооруженности труда 19.64 KB
  Показатели использования основных фондов и фондовооруженности труда Фондоотдача фондоемкость фондовооруженность являются основными показателями уровня использования основных фондов. Экономическим эффектом улучшения использования основных фондов является рост п
18701. Plug and Play (PnP) 13.42 KB
  Plug and Play сокр. PnP дословно переводится как включил и играй работай технология предназначенная для быстрого определения и конфигурирования устройств в компьютере и других технических устройствах. Изначальная технология называлась NuBus и была разработана Western Digital. Ш