ЗМІСТ

ЗМІСТ ................................................................................................................... 3
ВСТУП ................................................................................................................. 4
ЗАВДАННЯ НА ДИПЛОМНУ РОБОТУ ..............................................................
5 1. ТЕОРЕТИЧНА ЧАСТИНА .............................................................................
7 1.1 Microsoft SQL Server .....................................................................................
7 1.2 Створення реляційної бази даних ................................................................
7 1.3 Етапи проектування реляційної бази даних ............................................... 9
1.3.1 Визначення вимог....................................................................................... 9
1.3.2 Логічна модель. ER – діаграми. ............................................................... 10
1.3.3 Об’єкти, атрибути і ключі ........................................................................ 10
1.3.4 Нормалізація таблиць................................................................................ 11
1.3.5 Зв’язки ........................................................................................................ 12
1.3.6 Обмеження цілісності даних .................................................................... 13
1.4 Тригери .......................................................................................................... 13
1.5 Подання ......................................................................................................... 14
1.6 Збережені процедури ................................................................................... 15
1.7 Функції .......................................................................................................... 15
1.8 Курсори ......................................................................................................... 16
2. ПРАКТИЧНА ЧАСТИНА ............................................................................. 18
2.1 Створення нової бази даних ........................................................................ 18
2.2 Створення нового користувача ................................................................... 19
2.3 Створення таблиць ....................................................................................... 20
2.4 Зв’язування таблиць ..................................................................................... 21
2.5 Обмеження цілісності .................................................................................. 21
2.6 Використання тригерів ................................................................................ 22
2.8 Створення збережених процедур ............................................................... 23
ВИСНОВКИ ....................................................................................................... 25
СПИСОК ВІКОРИСТАНОЇ ЛІТЕРАТУРИ .................................................... 26

ВСТУП
 2

Будь-яке підприємство не може повноцінно функціонувати без

налагодженого і ефективного механізму контролю даних. Внаслідок розвитку
інформаційних технологій, розповсюдження мереж Internet/intranet роль баз
даних (БД) суттєво змінюється — зростає об’єм інформації та кількість
одночасно працюючих користувачів, ускладняється структура даних, зростає
кількість різноманітних функцій. Змінюється уява про будову та керування
додатками, які працюють з БД — вони містять бізнес-правила та опис логіки
у вигляді сценарних мов, відіграють значну роль при формуванні активних та
діагностичних Web-сторінок. Однією з ключових складових механізму
зберігання, обробки та аналізу інформації є системи керування базами даних
(СКБД). Сучасна СКБД являє собою потужне інтегруюче середовище, яке
потребує для роботи значних апаратних ресурсів та кваліфікованих
спеціалістів. На сьогоднішній день існує багато СКБД, які відрізняються за
своїми характеристиками. Незважаючи на існуючі відмінності між ними,
вони забезпечують наступні вимоги:  безперебійну роботу з даними; 
підтримку мов програмування для отримання інформації та розробки
додатків;  підтримку багатьох платформ;  можливість використання
даних з інших СКБД;  можливість швидкого відновлення даних;  надійну
систему безпеки та цілісність даних та ін.
В зв’язку з потребою виконання нових задач СКБД постійно
змінюються і вдосконалюються. СКБД MS SQL Server широко
використовуються для роботи з базами даних розміром від персональних до
великих баз даних масштабу підприємства; достойно конкурує з іншими
СКБД в цьому сегменті ринку. Це закінчене рішення для керування та
аналізу даних, що дозволяє оперативне розгортати Web-додатки нового
покоління, інтерактивні ділові додатки та сховища даних, забезпечує
масштабування, необхідне для підтримки зростаючих, динамічних
інформаційних середовищ.

1. ТЕОРЕТИЧНА ЧАСТИНА
 3

1.1 Microsoft SQL Server

На даний момент я використовую версію серверу баз даних від

Microsoft є SQL Server 2017, яка розповсюджується в наступних редакціях:
Enterprise, Standard, Web, Express та Developer. Редакція Enterprise надає
повний набір можливостей для найстрогіших вимог до баз даних і бізнес-
аналітики та забезпечує найвищі рівні обслуговування і продуктивності для
робочих навантажень першого рівня. Це найдорожча редакція. Редакція
Standard надає ключові можливості керування даними і бізнес-аналітики для
невеликих навантажень з використанням мінімальних ресурсів. Редакція Web
надається тільки стороннім сервіс-провайдерам. Це безпечна, економічна і
добре масштабована платформа для обробки даних загальнодоступних
сайтів. Безкоштовна редакція початкового рівня Express ідеально підходить
для навчання і створення додатків для обробки даних на настільних
комп'ютерах і невеликих серверах (розміром до 10 ГБ). Безкоштовна редакція
Developer дозволяє розробникам створювати, тестувати і демонструвати
додатки, які вимагають повного набору функціональних можливостей
серверу баз даних, що надає редакція Enterprise. Редакція Developer не
призначена для застосування в робочому середовищі — тільки для цілей
розробки. Таким чином, для цілей навчання підходять дві редакції SQL
Server 2017 — Express та Developer. Для визначеності зупинимо вибір на
редакції Express. Пакет установки Microsoft SQL Server 2017 Express Edition
не містить ніяких утиліт для адміністрування й написання скриптів SQL. Для
цього необхідно встановити SQL Server Management Studio версією не нижче
17 (SSMS). Ця утиліта для конфігурування, керування і адміністрування всіх
компонентів SQL Server має скриптовий редактор та інтерфейс користувача,
який дозволяє працювати з об'єктами і налаштуваннями сервера.

1.2 Створення реляційної бази даних

 4

Базою даних (БД) називається організована у відповідності з певними

правилами і підтримувана в пам'яті комп'ютера сукупність відомостей про
об'єкти, процеси, події або явища, які відносяться до певної предметної
області, теми або задачі. Вона організована таким чином, щоб забезпечити
інформаційні потреби користувачів, а також зручне зберігання цієї
сукупності даних, як в цілому, так і будь-якої її частини. Реляційна база
даних представляє собою множину взаємозв'язаних таблиць, кожна з яких
містить інформацію про об'єкти певного виду. Кожний рядок таблиці містить
дані про один об'єкт (наприклад, автомобіль, комп'ютер, клієнт), а стовпці
таблиці містять різні характеристики цих об'єктів — атрибути (наприклад,
номер двигуна, марка процесора, телефони фірм або клієнтів). Рядки таблиці
називають записами. Всі записи мають однакову структуру — вони
складаються з полів (елементів даних), в яких зберігаються атрибути об'єктів.
Кожне поле запису містить одну характеристику об'єкту і являє собою
заданий тип даних (наприклад, текстовий рядок, число, дата). Для
ідентифікації записів використовується первинний ключ. Первинним ключем
називається набір полів таблиці, комбінація значень яких однозначно
визначає кожний запис в таблиці. Для роботи з даними використовуються
системи управління базами даних (СУБД). Основні функції СУБД:
- визначення даних (опис структури баз даних);
- обробка даних;
- управління (керування) даними. Розробка структури БД —
найважливіша задача, яка вирішується при проектуванні БД. Структура БД
(набір, форма і зв'язки її таблиць) — це одне з основних проектних рішень
при створенні додатків з використанням БД. Створена розробником
структура БД описується мовою визначення даних СУБД. Будь-яка СУБД
дозволяє виконати наступні операції з даними:
- додавання записів в таблиці;
- видалення записів таблиці;
 5

- оновлення значень деяких полів в одному або декількох записах в

таблицях БД;
- пошук одного або декількох записів, які задовольняють певній умові.
Для виконання цих операцій застосовується механізм запитів.
Результатом виконання запитів є або відібрана за певними критеріями
множина записів, або зміни в таблицях. Запити до бази формуються на
спеціально створеній для цього мові, яка так і називається — мова
структурованих запитів (SQL — Structured Query Language).
Під керуванням даними звичайно розуміють захист даних від
несанкціонованого доступу, підтримку режиму роботи багатьох користувачів
з даними і забезпечення цілісності і узгодженості даних.
1.3 Етапи проектування реляційної бази даних Основна причина
складності проектування бази даних полягає в тому, що об'єкти реального
світу і взаємозв'язки між ними зовсім не повинні мати і, як правило, не мають
структури, узгодженої з реляційною моделлю даних. Розробник при
проектуванні повинен придумати представлення для реальних об'єктів і їх
зв'язків в термінах таблиць, полів, атрибутів, записів і т.д., тобто в термінах
абстракцій реляційної моделі даних. Тому в даному контексті термін
"проектування" можна розуміти і як процес, результатом якого є проект, і як
процес, результатом якого є проекція. Розробка ефективної бази даних
складається з декількох етапів. Процес розробки БД починається з аналізу
вимог. Проектувальник на цьому етапі розробки повинен найти відповіді на
наступні питання: які елементи даних повинні зберігатись, хто і як буде до
них звертатись. На другому етапі створюється логічна структура БД. Для
цього визначають, як дані будуть згруповані логічно. Структура БД на цьому
етапі виражається в термінах прикладних об'єктів і відношень між ними. На
заключному (третьому) етапі логічна структура БД перетворюється в фізичну
з урахуванням аспектів продуктивності. Елементи даних на цьому етапі
отримують атрибути і визначаються як стовпці в таблицях обраної для
реалізації БД СУБД.
 6

1.3.1 Визначення вимог

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

1.3.2 Логічна модель. ER – діаграми.

Загальним способом представлення логічної моделі БД є побудова ER–
діаграм(Entity-Relationship — сутність-зв'язок). В цій моделі сутність
визначається як дискретний об'єкт, для якого зберігаються елементи даних, а
зв'язок описує відношення між двома об'єктами.
1.3.3 Об’єкти, атрибути і ключі
 7

Далі модель розвивається шляхом визначення атрибутів для кожного

об'єкта. Атрибути об'єкта — це елементи даних, які відносяться до певного
об'єкту і повинні зберігатись. Аналізуємо складений словник даних,
виділяємо в ньому об'єкти та їх атрибути, розширюємо словник при
необхідності. Реляційна модель характеризується використанням ключів і
відношень. Є різниця в контексті реляційної бази даних між термінами
relation (відношення) і relationship (схема даних). Відношення розглядається
як невпорядкована, двовимірна таблиця з незв'язаними рядками. Схема даних
формується між відношеннями (таблицями) через загальні атрибути, які є
ключами. Існує декілька типів ключів, і вони іноді відрізняються тільки з
точки зору їх взаємозв'язку з іншими атрибутами і відношеннями. Первинний
ключ унікально ідентифікує рядок у відношенні (таблиці), і кожне
відношення може мати тільки один первинний ключ, навіть якщо більш ніж
один атрибут є унікальним. В деяких випадках потрібно більше одного
атрибута для ідентифікації рядків у відношенні. Сукупність цих атрибутів
називається складеним ключем. В інших випадках первинний ключ повинен
бути спеціально створений (згенерований). Наприклад, у відношенні
"Туристи" є сенс додати унікальний ідентифікатор туриста (код туриста) у
вигляді первинного ключа цього відношення для організації зв'язків з іншими
відношеннями БД. Інший тип ключа, зовнішній ключ, існує тільки в термінах
схеми даних між двома відношеннями. Зовнішній ключ у відношенні — це
атрибут, який є первинним ключем (або частиною первинного ключа) в
іншому відношення. Це — розподілений атрибут, який формує схему даних
між двома відношеннями в БД.
1.3.4 Нормалізація таблиць
Функціональні залежності проявляються, коли значення одного
атрибута може бути визначено із значення іншого атрибута. Атрибут, який
може бути визначений, називається функціонально залежним від атрибута,
який є детермінантом. Отже, за визначенням, всі неключові (без ключа)
атрибути будуть функціонально залежати від первинного ключа у кожному
 8

відношенні (так як первинний ключ унікально визначає кожний рядок). Коли

один атрибут відношення унікально не визначає інший атрибут, але обмежує
його набором зумовлених значень, це називається багатозначною
залежністю. Часткова залежність має місце, коли атрибут відношення
функціонально залежить від одного атрибута складеного ключа. Транзитивні
залежності спостерігаються, коли неключовий атрибут функціонально
залежить від одного або декількох інших неключових атрибутів у
відношенні. Всього існує 5 нормальних форм (НФ) схем відносин. Процес
нормалізації полягає в покроковій побудові БД в нормальній формі (НФ). -
Перша нормальна форма (1НФ). Всі таблиці БД повинні задовольняти єдиній
вимогі — кожне поле в таблицях повинне містити атомарне значення,
іншими словами, значення в рамках предметної області додатку БД не
повинно мати внутрішньої структури, елементи якої можуть знадобитись
додатку. - Друга нормальна форма (2НФ) — відношення знаходиться в 1НФ
і кожний непервинний атрибут повністю залежить від первинного ключа.
Якщо у відношеннях немає ніяких складених ключів, то цей рівень
нормалізації легко досягається.
- Третя нормальна форма (3НФ) — відношення знаходиться в 2НФ і
кожен непервинний атрибут не містить транзитивних залежностей від
первинного ключа. - Нормальна форма Бойса-Кодда (НФБК) — відношення
знаходиться в 3НФ і в ньому відсутні залежності первинних атрибутів від
непервинних, тобто всі домени є можливими ключами. - Четверта нормальна
форма (4НФ) — відношення знаходиться в НФБК і в ньому відсутні
багатозначні залежності, які не є функціональними. - П'ята нормальна форма
(5НФ) досягнена тоді і тільки тоді, коли будь-яка залежність по з'єднанню у
відношенні визначається можливими ключами. Ця НФ визначає умови, при
яких вихідне відношення може бути відновлено без втрат інформації
1.3.5 Зв’язки
 9

Для зв'язування таблиць бази даних необхідно викликати контекстне

меню на вузлі Діаграми баз даних і обрати пункт Створити діаграму бази
даних (рис. 1.1).

У вікні, що з'явилось, потрібно виділити всі таблиці і натиснути

відповідно кнопки "Додати" і "Закрити". У вікні діаграми додані таблиці
можна перетягувати, розташовуючи їх зручним чином. Після цього їх
потрібно зв'язати. В результаті такого зв'язування таблиці будуть змінені —
до таблиць будуть додані зовнішні ключі (рис. 1.2).

1.3.6 Обмеження цілісності даних

Планування і створення таблиць вимагає задання допустимих значень
для стовпців і визначення способів примусового забезпечення цілісності
 10

даних в них. SQL Server надає наступні механізми для примусового

забезпечення цілісності даних в стовпці: - Визначення значень за умовчанням
(DEFAULT); - Дозвіл на зберігання значень NULL; - Обмеження первинного
ключа (PRIMARY KEY); - Обмеження зовнішнього ключа (FOREIGN KEY);
- Обмеження на унікальність значень (UNIQUE); - Обмеження на умову
(CHECK). Обмеження задають правила допустимості певних значень в
стовпцях і є одним зі стандартних механізмів забезпечення цілісності.
1.4 Тригери
Тригер — це збережена процедура, що починає свою роботу у випадку
виконання дії, на яку тригер налаштований. Тригери застосовуються для
рішення завдань підтримки цілісності (коректності) даних, коли за певних
причин неможливо (незручно) використовувати обмеження FOREIGN KEY
(або обмеження на значення стовпців), і безпеки, коли, наприклад,
неприпустимі які-небудь зміни в даних. Тригери бувають декількох типів:
DML, DDL і LOGON. DML тригери можуть спрацьовувати при виконанні
(після виконання або замість виконання) команд INSERT, UPDATE і
DELETE для таблиць або подань. DDL тригери можуть спрацьовувати при
виконанні, після виконання команд CREATE, ALTER, DROP, GRANT,
DENY, REVOKE, UPDATE STATISTICS і деяких системних процедур.
LOGON тригери спрацьовують після установки з'єднання з MS SQL Server.
1.5 Подання
Подання можна вважати віртуальною таблицею або збереженим
запитом. Якщо подання не індексовано, його дані не зберігаються в базі
даних у вигляді окремого об'єкта. В базі даних зберігається тільки інструкція
SELECT. Результуючий набір інструкції SELECT формує віртуальну
таблицю, яка повертається поданням. Як і справжня таблиця, подання
складається із сукупності іменованих стовпців і рядків даних. Поки подання
не буде проіндексовано, воно не існує в базі даних як сукупність значень, яка
зберігається окремо. Рядки і стовпці даних вибираються з таблиць, які
вказані у запиті, що визначає подання, і динамічно створюються при
 11

зверненні до подання. Подання виконує функцію фільтра базових таблиць, на

які воно посилається. Запит, що визначає подання, може бути ініційований в
одній або декількох таблицях або в інших поданнях поточної або інших баз
даних. Крім того, для визначення подань з даними із декількох різнорідних
джерел можна використовувати розподілені запити. Це корисно, наприклад,
якщо потрібно об'єднати структуровані подібним чином дані, які відносяться
до різних серверів, кожний з яких зберігає дані окремого відділу організації.
На запити даних через подання не накладаються ніякі обмеження; є тільки
декілька обмежень на зміну даних з допомогою подань. Подання звичайно
використовуються для направлення, спрощення і налаштування сприйняття
кожним користувачем інформації бази даних. Подання можуть
використовуватись як механізми безпеки, даючи можливість користувачам
звертатись до даних через подання, але не надаючи їм дозволу на
безпосередній доступ до базових таблиць, які лежать в основі подання.
Подання можуть використовуватись для забезпечення інтерфейсу зворотної
сумісності, що моделює таблицю, яка існує, але схема якої змінилась.
Подання можуть також використовуватись для копіювання даних на
Microsoft SQL Server і з нього для підвищення продуктивності і
секціонування даних.
1.6 Збережені процедури
Збережена процедура — це збережена колекція інструкцій мови
Transact-SQL, яка може приймати і повертати надані користувачем
параметри. Використання збережених процедур забезпечує наступні
переваги: - Роблять можливим модульне програмування. Можна, один раз
створивши процедуру, зберегти її в базі даних, а потім багато разів викликати
її із своєї програми. - Дозволяють прискорити виконання. Збережені
процедури знижують вартість компіляції коду Transact-SQL, кешуючи і
повторно використовуючи плани виконання. Це означає, що для збережених
процедур немає потреби виконувати повторний синтаксичний аналіз і
оптимізацію при кожному виклику, що значно прискорює їх виконання. -
 12

Дозволяють зменшити мережевий трафік. Замість передачі на сервер текстів

великих запитів Transact-SQL, запити можна оформити у вигляді збережених
процедур. При цьому для їх виконання будуть передаватись тільки імена
процедур і значення параметрів.
Збережені процедури не можна використовувати в запитах SELECT
напряму. Збережені процедури можуть бути вкладеними — одна збережена
процедура може викликати іншу. Рівень вкладеності збільшується на 1, коли
починається виконання викликаної процедури, і зменшується на 1, коли
викликана процедура завершується. Рівень вкладеності збережених процедур
може досягати 32.
1.7 Функції
Подібно функціям мов програмування, визначені користувачем
функції Microsoft SQL Server є підпрограмами, які приймають параметри,
виконують дії, такі як складні обчислення, і потім повертають результат
виконання у вигляді значення. Значення, що повертає функція, може бути або
одиничним скалярним значенням, або результуючим набором. SQL Server
підтримує функції, які визначає користувач, і вбудовані (системні) функції.
Використання функцій, які визначає користувач, забезпечує такі ж переваги,
як і використання збережених процедур. Крім того, операція, яка фільтрує
дані на основі якого-небудь складного обмеження і не може бути виражена
одним скалярним виразом, може бути реалізована у вигляді функції. Її можна
викликати з виразу WHERE, щоб зменшити кількість рядків, що
повертаються клієнту. Будь-яка функція, яка визначається користувачем,
складається з двох частин: заголовку і тексту. Функція приймає нуль і більше
параметрів і повертає або скалярне значення, або таблицю. Заголовок
визначає: - ім'я функції з необов'язковим іменем схеми або власника; - ім'я і
тип даних параметрів функції; - тип даних значення, що повертається, і
необов'язкове ім'я. Текст визначає дію або логіку, яку виконує функція, і
може містити одну або декілька інструкцій Transact-SQL, які реалізують
логіку функції. Функції користувача в MS SQL Server діляться на 3 категорії:
 13

- скалярні функції; - функції, що повертають табличне значення; - вбудовані

функції.
1.8 Курсори
Команди маніпулювання даними SELECT, UPDATE, DELETE
працюють відразу з групами рядків. Ці групи, аж до окремих рядків, можна
вибрати з допомогою опції WHERE. А якщо потрібно перебрати рядки деякої
вибірки послідовно, один за одним? На цей випадок існують курсори. Курсор
(current set of record) — тимчасовий набір рядків, який можна перебирати
послідовно, з першого до останнього. При роботі з курсорами
використовуються наступні команди. Оголошення курсора: DECLARE
ім'я_курсора CURSOR FOR SELECT текст_запиту Відкриття курсора: OPEN
ім'я_курсора Для того, щоб з допомогою курсору можна було читати рядки,
його потрібно обов'язково відкрити. Читання наступного рядка з курсору:
FETCH ім'я_курсора INTO список_змінних Змінні в списку повинні бути в
тому ж числі і того ж типу, що і стовпці курсора. Глобальна змінна
@@FETCH_STATUS приймає ненульове значення, якщо рядків в курсорі
більше немає. Якщо набір рядків ще не вичерпаний, то @@FETCH_STATUS
дорівнює 0, і оператор FETCH перепише значення з поточного рядку в
змінні. Закриття курсора: CLOSE ім'я_курсора Для видалення курсора з
пам'яті використовується команда DEALLOCATE ім'я_курсора
 14

2. ПРАКТИЧНА ЧАСТИНА
2.1 Створення нової бази даних
У кожного екземпляра SQL Server є чотири системних БД (master,
tempdb, msdb і model) і одна або декілька, призначених для користувача. Для
створення нової бази даних потрібно виконаємо наступні дії: 1. На вкладці
Бази даних натиснемо праву кнопку миші і виберемо в спливаючому меню
пункт Створити базу даних. У результаті вибору цього пункту меню
з'являється діалогове вікно, що містить 3 сторінки.
2. На першій сторінці міститься рядок уведення, у який потрібно ввести
ім'я нової БД. У наступному рядку уведення задається ім'я власника
створюваної БД (за замовчуванням — default — це поточний активний
користувач). Нижче знаходиться вікно, у якому задаються імена файлів БД і
логу транзакцій, а також їхній початковий розмір. Створимо базу даних,
залишивши інші параметри за замовчанням.

Рисунок 2.1. Створення бази даних.

 15

2.2 Створення нового користувача

Ця операція виконується в наступний спосіб:
1. Розкриваємо вузол Безпека і виберемо пункт Імена для входу. 2.
Натиснемо праву кнопку миші й виберемо пункт меню Створити ім'я для
входу. При виборі цього пункту з'являється діалогове вікно, що складається
із трьох сторінок. 3. На сторінці Загальні вводимо ім'я для входу (login);
виберемо аутентифікацію SQL Server, вказавши пароль, виберемо створену
раніше базу даних при підключенні до SQL Server та російську мову.
Оскільки при першому підключенні для створюваного логіна немає
необхідності зміни пароля, то приберемо галочку з опції Задати строк
закінчення дії паролю.

Рисунок 2.2 Налаштування загальних параметрів нового користувача.

4. На сторінці Зіставлення користувачів (рис. 2.3) біля відповідного
імені БД у верхньому вікні поставити галочку, що автоматично дасть
користувачеві роль public, що не дає можливості виконувати SQL команди,
інакше не буде можливості вибрати БД як поточну або звертатися до її
 16

об'єктів. Варто звернути увагу, що до БД master користувач має доступ у

будь-якому разі. Крім ролі public, яка не може бути скинута, виберемо роль
db_owner, яка надасть користувачеві можливість виконувати команди
CREATE, ALTER, DROP, TRUNCATE, 5. Натиснемо кнопку OK та
завершимо створення нового користувача.

Рисунок 2.3
2.3 Створення таблиць
Виконаємо вхід до сервера баз даних під іменем нового створеного
користувача. В процесі проектування реляційної БД з предметної області
«Автосалон» було створено 13 таблиць (рис. 2.4).
 17

Рисунок 2.4 Список створених таблиць

Створені таблиці та їх стовпці будуть зображені нижче на рисунку 2.5.

2.4 Зв’язування таблиць

Усі таблиці були зв’язані за допомогою зовнішніх ключів,
використовуючи ключові поля. Створені зовнішні ключі та первинні ключі
показано на рис. 2.5.
2.5 Обмеження цілісності
- Обмеження первинного ключа (PRIMARY KEY). При створенні
таблиць в SQL Server Management Studio у кожній таблиці було додано
стовпець [Код] та створено для нього обмеження PK (рис. 2.6)
- Обмеження зовнішнього ключа (FOREIGN KEY). При створенні
зв’язків в діаграмі таблиць бази даних автоматично створюються обмеження
зовнішнього ключа для відповідних стовпців.
 18

Рисунок 2.5 Діаграма зв’язків бази даних.

2.6 Використання тригерів

До бази даних було додано DDL-тригер drop_deny, який запобігає
випадковому видаленню таблиць, виводить відповідне попередження і
виконує відкат транзакції.
CREATE OR ALTER TRIGGER [drop_deny] ON DATABASE FOR
DROP_TABLE AS
PRINT N'Удаление таблиц запрещено триггером drop_deny!'
ROLLBACK; GO
Для перевірки роботи створеного тригера створимо таблицю [Test] з
одним полем [Поле] за допомогою наступного запиту:
CREATE TABLE dbo.Test (Поле NCHAR(10));
GO
 19

Рис. 2.6. Створена таблиця Test.

Далі спробуємо видалити створену таблицю за допомогою наступного
запиту:
DROP TABLE dbo.Test GO

Вимкнемо створений тригер та пробуємо видалити за допомогою

запиту:
DISABLE TRIGGER [drop_deny] ON DATABASE DROP TABLE
dbo.Test GO

До бази даних було додано DDL-тригер drop_deny_constraint, який

запобігає випадковому видаленню первинних та зовнішніх ключів, виводить
відповідне попередження і виконує відкат транзакції.
CREATE OR ALTER TRIGGER [drop_deny_constraint]
ON DATABASE FOR ALTER_TABLE AS
BEGIN
DECLARE
@command VARCHAR(8000),
@word VARCHAR(20);
SET @command =
LTRIM(eventdata().value('(EVENT_INSTANCE/TSQLCommand)[1]',
'varchar(8000)'))
 20

IF (CHARINDEX(UPPER('drop'), UPPER(@command)) > 0

AND CHARINDEX(UPPER('constraint'), UPPER(@command)) > 0)
BEGIN
PRINT N'Запрещено удаление первичных и внешних ключей
триггером' ROLLBACK
END
END
Для перевірки роботи створеного тригера створимо таблицю [Test1] з
одним полем [Id] та таблицю [Test2] з одним полями [Id] та [TestId], що
зв’язані за допомогою зовнішнього ключа [FK_Test1_Test2], за допомогою
наступного запиту:
CREATE TABLE dbo.Test2 (Id INT CONSTRAINT PK_Test2_Id
PRIMARY KEY IDENTITY);
CREATE TABLE dbo.Test1 (Id INT CONSTRAINT PK_Test1_Id
PRIMARY KEY IDENTITY,
TestId INT CONSTRAINT FK_Test1_Test2 FOREIGN KEY
REFERENCES dbo.Test2 (Id)); GO

Рис. 2.9. Створені таблиці та ключі.

Далі спробуємо видалити створений первинний та зовнішній ключі
таблиці [Test1] за допомогою наступного запиту:
ALTER TABLE dbo.Test1 DROP CONSTRAINT PK_Test1_Id;
ALTER TABLE dbo.Test1 DROP CONSTRAINT FK_Test1_Test2; GO
 21

2.7 Створення подань

Подання Співробітники
CREATE VIEW [dbo].[WorkersView] AS SELECT dbo.Workers.surname,
dbo.Workers.name, dbo.Workers.birthday, dbo.Workers.sex, dbo.Workers.phone,
dbo.Positions.title, dbo.Positions.salary, dbo.Addreses.city, dbo.Addreses.street,
dbo.Addreses.house FROM dbo.Workers INNER JOIN dbo.Positions ON
dbo.Workers.position = dbo.Positions.id INNER JOIN dbo.Addreses ON
dbo.Workers.address = dbo.Addreses.id GO

Рис. 2.13. Вибірка з подання

Cтворено таблицу Покупці :

 22

Рис. 2.13. Створення табл

Рис. 2.14. Заповнення

Рис. 2.14 Вибірка з подання

Рис. 2.15 Вибірка з подання посада

2.8 Створення процедури

• Процедура getEmptyTables, виводить пусті таблиці з БД:
CREATE PROCEDURE getEmptyTables AS SELECT
OBJECT_NAME(T.OBJECT_ID) AS TABLE_NAME, SUM(P.ROWS) AS
 23

TOTAL_ROWS FROM SYS.TABLES T INNER JOIN SYS.PARTITIONS P

ON T.OBJECT_ID = P.OBJECT_ID WHERE P.INDEX_ID IN (0,1) GROUP BY
T.OBJECT_ID HAVING SUM(P.ROWS) = 0 RETURN GO
Збережена процедура Працівники
CREATE PROCEDURE [dbo].[AddWorker]
@passport NVARCHAR(50),
@surname NVARCHAR(50),
@name NVARCHAR(50),
@birthday DATE,
@sex BIT, -- address
@city NVARCHAR(50),
@street NVARCHAR(50),
@house NVARCHAR(50),
@apartament INT, -- next vars
@phone NVARCHAR(15),
@position int AS BEGIN
-- Add address this produser EXEC AddAddress @city,
@street,
@house,
@apartament;
DECLARE
@idAddress int;
-- Get id this address SET
@idAddress = ( SELECT TOP 1 Addreses.id FROM Addreses WHERE
Addreses.city = @city AND Addreses.house = @house AND Addreses.street
= @street AND Addreses.apartament = @apartament );
-- Insert worker
INSERT INTO
dbo.Workers(passport, surname, name, birthday, sex, address, phone, position)
 24

VALUES(@passport, @surname, @name, @birthday, @sex, @idAddress,

@phone, @position);
END GO
3.12 Створення функції
• Функція getEmpCount, виводить кількість співробітників:
CREATE FUNCTION getEmpCount() RETURNS int AS BEGIN
DECLARE @emp_count int; SELECT @emp_count = COUNT(*) FROM
dbo.Employees IF (@emp_count IS NULL) SET @emp_count = 0; RETURN
@emp_count; END; GO
 25

ВИСНОВКИ
У ході даної дипломної роботи була досліджена предметна область
«Ріелтерська компанія» та розроблена база даних, яка відображає робочий
процес у компанії. Дану базу даних можна використовувати як основу для
створення інформаційної системи реальної організації або в навчальних
цілях. Були набуті навички проектування бази даних, групування даних за
сукупністю суттєвих ознак з погляду мінімізації витрат на зберігання
інформації на гнучкості при подальшій модифікації структури даних. Було
закріплено на практиці використання основних можливостей СКБД MS SQL
Server 2017 та язика T-SQL, такі як тригери, подання, збереженні процедури.
 26

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

1. Навчально-методичний посібник до дипломного проектування з

дисципліни «Організація баз даних» / Л. Г. Ахметшина, А. О. Єгоров, В. В.
Герасимов. — Дніпро, 2018. — 68 с.
2. Документация по SQL Server [Електронний ресурс]. Режим доступу:
https://docs.microsoft.com/ru-ru/sql/sql-server/sql-servertechnicaldocumentation?
view=sql-server-2017