Міністерство освіти і науки України

ЖДТУ Житомирський державний технологічний університет

Затверджено науково-
методичною
радою ЖДТУ
протокол від
«__»_______ 20__ р.
№__

МЕТОДИЧНІ РЕКОМЕНДАЦІЇ
До лабораторних робот студентів з дисципліни
«_БАЗИ ДАНИХ»

для студентів освітнього рівня «БАКАЛАВР»

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

Робочу програму схвалено

на засіданні кафедри
інженерії програмного
забезпечення протокол від
«28» серпня 2017 р. № 1
Завідувач кафедри ІПЗ
________________ А.В.
Панішев

Розробники: старший викладач кафедри ІПЗ Данильченко А.О,

к.т.н. доц. кафедри ІПЗ Сугоняк Інна Іванівна

Житомир
2017 – 2018 н.р.
Методичні вказівки до лабораторного практикуму з дисципліни
«Бази даних» для студентів спеціальності «Програмне
забезпечення систем» / Укладачі А.О. Данильченко, І.І.Сугоняк. –
Житомир: ЖДТУ, 2016. – 24с.

Укладачі: Данильченко Анна Олександрівна, старший викладач

кафедри програмної інженерії, Сугоняк Інна Іванівна, доцент
кафедри програмного забезпечення систем

Відповідальний редактор: Панішев Анатолій Васильович,

завідувач кафедри програмного забезпечення систем, д.т.н.,
професор
Рецензент: Ковальчук Андрій Михайлович, доцент кафедри ПЗС,
к.т.н, доцент

2
 ВСТУП
В сучасних умовах для всіх сфер людської діяльності
інформація є одним із вирішальних чинників успіху. Збільшення
інформаційних потоків і посилення вимог до швидкості обробки
даних вимагає застосування комп’ютерних технологій
аналітичної обробки даних та підтримки прийняття рішень. Для
оцінки ситуації, в якій приймається рішення, враховуються сотні
чинників, що постійно змінюються, а ступінь обґрунтованості
рішень має забезпечити безпомилковий вибір на множині
альтернатив. Тому обійтися без інформаційної моделі об’єкта та
процесу, для яких приймається рішення, не можливо. Сучасний
світ інформаційних технологій важко уявити собі без
використання баз даних. Практично всі комп’ютеризовані
системи для успішного функціонування реалізують функції
довготривалого зберігання й обробки інформації. Тому питання
ефективного проектування та експлуатації систем на основі баз
даних без сумніву заслуговують на увагу спеціалістів з
комп’ютерних технологій.
Курс «Системи управління базами даних» є нормативною
дисципліною в навчальних програмах для студентів старших
курсів, які спеціалізуються у галузі автоматизованих
інформаційних та інтелектуальних систем. Мови програмування
та системи управління базами даних (надалі СУБД) на
сьогоднішній день об’єднані в єдине програмне середовище, що
базується на об’єктно-орієнтованому та візуальному підходах.
Такий підхід значно розширив функціональні можливості
розробки комп’ютеризованих інформаційних систем. У
посібнику розглядаються питання проектування баз даних
(надалі БД) та знань. Наведені основи теоретичних та
практичних знань з побудови баз даних під керуванням
локальних та промислових СУБД.
В результаті виконання лабораторних робіт студент може:
– знати основні поняття, які використовуються в ході
розробки БД, функції СУБД, рівні абстракції БД;
– уміти проектувати концептуальні моделі БД у формі
діаграм Чена або Мартіна;

3
 – знати фізичну організацію даних, структуру моделей даних
та їх ознаки, архітектуру баз даних;
– мати уявлення з основних та допоміжних операцій
реляційної алгебри;
– використовувати CASE-засоби проектування баз даних;
– володіти навиками створення інструкцій обробки та
визначення даних на мові SQL;
– знати методи та засоби інтегрованих середовищ розробки
MS Visual Studio та SQL-серверів і вміти їх використовувати у
ході розробки додатків, які основані на БД.

4
 Лабораторна робота №1. Концептуальне
моделювання БД
Мета: набуття практичних навичок щодо побудови
концептуальних моделей баз даних із використанням діаграмних
технологій (модель сутність-зв‘язок).
Обладнання: ПЕОМ, CASE Allfusion ERWin Data Modeler
Теоретичні відомості
База даних  сукупність взаємозв’язаних даних, що
зберігаються разом на одному носії та описують якусь предметну
область із мінімальною надмірністю, що допускає їх оптимальне
використання для виконання одного або декількох завдань.
База даних – сумісно використовуваний набір логічно пов’язаних
даних та опис цих даних (системний каталог або словник), що
призначені для задоволення інформаційних потреб організації.
Сховище даних – це агрегований інформаційний ресурс, що
містить консолідовану інформацію з усієї проблемної сфери та
використовується для підтримки прийняття рішень.
Транзакція - є набором дій, виконуваних окремим
користувачем або прикладною програмою з метою доступу або
зміни вмісту бази даних.
Система управління базами даних (СУБД) – програмне
забезпечення, за допомогою якого користувачі можуть визначати,
створювати та підтримувати базу даних, а також здійснювати до
неї контрольований доступ.
Основна мета функціонування СУБД полягає в тому, щоб
запропонувати користувачу абстрактне представлення даних,
приховавши конкретні особливості зберігання й управління ними.
Основні функції та можливості СУБД:
1. Зберігання, обробка й оновлення даних.
2. Системний каталог, доступний користувачам.
3. Підтримка транзакцій.
4. Сервіси управління паралельністю.
5. Сервіси відновлення.
6. Сервіси контролю доступу до даних.

5
 7. Підтримка обміну даними.
8. Служби підтримки цілісності даних.
9. Служби підтримки незалежності від даних.
10. Допоміжні служби.
Модель даних – це поєднання трьох компонентів:
 структурна частина  набір правил, за якими може бути
побудована база даних;
 керуюча частина визначає типи допустимих операцій з
даними (сюди відносяться операції оновлення і добування даних, а
також операції зміни структури бази даних);
 набір обмежень підтримки цілісності даних (необов’язково),
що гарантують коректність використаних даних.

Моделі
даних

Інфологічні Даталогічні Фізичні моделі

моделі моделі

Об’єктно- Документальні Основані на

орієнтовані файлових
структурах

На основі Основані на
Моделі сторінково-
записів
«сутність- сегментній
(фактографічні)
зв‘язок» організації

Теоретико- Теоретико- Об’єктно-

множинні графові орієнтовані

Рис. 1.1. Моделі даних БД

Для відображення трирівневої архітектури БД можна
ідентифікувати три взаємопов’язані моделі даних (рис.1.3):
 зовнішню модель даних, що відображає представлення
кожного існуючого в організації типу користувачів;
 концептуальну модель даних, що відображає логічне (або
узагальнене) представлення даних, незалежне від типу обраної

6
СУБД;
 внутрішню модель даних, що відображає концептуальну
схему способом, зрозумілим вибраній СУБД.
Фізичні моделі даних - описують те, як дані зберігаються в
комп’ютері, уявляючи інформацію про структуру записів, їх
впорядкованість та існуючі шляхи доступу.
Даталогічна модель даних - відображує взаємозв’язки між
елементами даних незалежно від їх вмісту та фізичної організації.
При цьому даталогічна модель враховує особливості обраної
СУБД та специфіку предметної області.
У моделі на основі записів база даних складається з декількох
записів фіксованого формату, які можуть мати різні типи. Кожен
тип запису визначає фіксовану кількість полів, кожне з яких має
фіксовану довжину. Існує три основні типи моделей даних на
основі записів: реляційна модель даних (relational data model),
мережна модель даних (network data model) та ієрархічна модель
даних.
Інфологічна модель даних дозволяє відображати інформацію, яку
необхідно зберігати в базі даних з метою представлення семантики
бази даних без урахування особливостей СУБД.
Під час побудови інфологічих (об’єктних) моделей даних
використовуються такі поняття: сутність, атрибути і зв’язки.
Сутність – це окремий елемент (співробітник, місце або річ,
поняття або подія) організації, який повинен бути представлений в
базі даних.
Атрибут – це властивість, що описує деякий аспект об’єкта,
значення якого слід зафіксувати, а зв’язок є асоціативним
відношенням між сутностями.
Зв’язки - використовують для ідентифікації вимог, відповідно
до яких визначаються взаємозалежності сутностей. Кожен зв’язок
сполучає сутність і відношення і може бути направленим тільки
від відношення до сутності.
Існують такі типи зв’язків:
1. 1:1 (один-до-одного). Зв’язки даного типу
використовуються, як правило, на верхніх рівнях ієрархії моделі
даних, а на нижніх рівнях зустрічаються порівняно рідко.
2. 1:∞ (один-до-багатьох). Зв’язки даного типу є найчастіше

7
використовуваними.
3. ∞:∞ (багато-до-багатьох). Зв’язки даного типу звичайно
використовуються на ранніх етапах проектування з метою
прояснення ситуації. Надалі кожний з таких зв’язків слід
перетворити в комбінацію відношень типів 1 і 2 (можливо, з
додаванням допоміжної сутності), оскільки вони не підтримуються
в реляційних моделях.
Значення зв’язку характеризує його тип і, як правило,
вибирається з такої множини: {«0 або 1», «0 або більш», «1», «1
або більш», «p:q» ( діапазони можливих сполучень )}.

Незалежна Залежна Асоційована

сутність сутність сутність

Необмежене
відношення Обмежене
відношення
Істотно-
обмежене
відношення
Атрибут

Незалежна 1 Необмежене 1…m Залежна

сутність відношення сутність

Рис. 1.2 Елементи діаграми Чена

ноль
один

багато
Назва сутності Назва сутності
Ключовий Ключовий атрибут
атрибут

8
Атрибут 2 Атрибут 2
Атрибут3 Атрибут3
... ...
Атрибут n Атрибут n

Рис. 1.3. Елементи діаграми Баркера

Модель «сутність-зв’язок (Entity-Relationship model, або ER-
модель) є високорівневою концептуальною моделлю даних, яка
була розроблена Пітером Пін-Шен Ченом (нотація Чена) в 1976
році з метою спрощення задачі проектування баз даних (рис.1.2).
Дана модель даних є набором концепцій, які описують структуру
бази даних і пов’язані з нею транзакції оновлення і добування
даних. Надалі концепція моделювання набула розвитку та нових
нотацій (див.рис.1.3) у роботах Мартіна, Еджворта та Баркера.

Хід роботи
1. Аналіз предметної області – процесу рейтингового оцінювання
знань студентів визначає наступне:
Оцінювання знань студентів в умовах кредитно-модульної
системи організації навчального процесу проводиться за
рейтингової системою оцінювання. Виконання задачі можна
розбити на наступні основні етапи:
- Ведення основних даних навчального процесу;
- Уведення навчального розкладу груп;
- Введення поточних рейтингових оцінок студентів та визначення
підсумкових;
- Підготовка і друк звітів.
Необхідно передбачити збереження наступних даних:
1) Відомості про навчальні групи, що складаються з назви групи,
курсу та спеціальності.
2) Відомості про студентів, які містять П.І.Б студента, номер
навчальної групи, номер залікової книжки.
3) Відомості про дисципліни, що викладаються у вузі – назва
дисципліни, форми проведення занять тощо.
4) Відомості розкладу – дата, час, група, предмет, вид заняття
тощо.

9
5) Відомості про поточну рейтингову успішність студента –
дисципліна, заняття, ПІБ студента та оцінка, яку він отримав.
Система повинна підтримувати виконання наступних
транзакцій:
- введення, оновлення та знищення даних про дисципліни,
навчальні групи та їх склад, розклад занять, поточні оцінки
студентів, що отримані ними під час навчання.
- визначення сумарного рейтинг окремого студента за окремою
дисципліною у розрізі модулів, та підсумкової;
- визначення успішності навчальної групи;
- розрахунок середнього балу навчання у розрізах студентів та
навчальних груп;
- визначення абсолютної та якісної успішності групи за
дисципліною;
- формування друкованих форм звітів, зокрема відомостей,
екзаменаційних листів тощо.
2. Для побудови діаграми можна виділити наступні сутності
системи:
- групи;
- студенти;
- предмети;
- вид заняття;
- пара;
- рейтинг.
Аналіз зв‘язків між ними дозволяє побудувати наступну ER-
діаграму (рис.1.4):
Діаграма в нотації Чена є ефективним інструментом
моделювання логічних зв‘язків предметної області, однак
деталізація атрибутів сутностей є ускладненої надмірним
завантаженням зображення графічними елементами атрибутів,
тому визначення структури сутностей доцільно використати
нотацію Мартина(Баркера).

10
 Група Вид занять Предмет

1
1 1
має
проводить
Навчають
ся
ся (1...10000
)
Пара
(1...40) (10000) (1...150)
1
Студенти
визначаєт
1 ься

(0...40)
Отримують Рейтинг

(0...10000000)

Рис.1.4 ER-діаграмма

2. Логічна модель БД „Рейтинг” в нотації Баркера має вигляд:

Рис.1.5 Логічна модель БД „Рейтинг”

3. Перейдемо до побудови інфологічної та дата логічної моделі БД
„Рейтинг” засобами ERWin. Для цього:

11
- запускаємо програму та створюємо нову модель на основі
шаблону „Logical/Physical”, в пункті Target Database обираємо MS
Access.
- створюємо інфологічну та даталогічну моделі даних, результат
наведено на рис.4.
4. Для створення фізичної моделі БД необхідно:
- Завантажити MS Access та створити нову БД.
- В ERWin обрати пункт DataBase->Choose Database та
пересвідчитись, що обраним є формат СУБД MS Access.
- В пункті DataBase->Сonnection зазначити ім’я користувача
“admin” та шлях до створеною в MS Access бази даних.
- За умови вдалого під’єднання обрати пункт Tools->Forvard
Engineer/Shema Generation та здійснити кодогенерацію БД.
- Результат показати викладачу.
5. За виданим викладачем індивідуальним варіантом, здійснити
аналіз предметної області визначити базові сутності та побудувати
діаграму Чена у першому наближенні.

Рис.1.6. Вікно обрання типу моделі

12
 Рис.1.7. Приклад збудованої діаграми

Вимоги до звіту
Звіт містить:
1. Назву, тему і мету лабораторної роботи.
2. Зразок документа за індивідуальним завданням.
3. Виконану діаграму Чена (за зразком із лабораторної
роботи).

13
 Лабораторна робота №2. Проектування баз даних
методом нормалізації відношень
Мета заняття: набуття практичних навичок щодо
побудови моделей баз даних із використанням методу нормалізації
відношень.
Програмне та технічне забезпечення: ПЕОМ, MS Office
(Excel).
Завдання: здійснити розробку структури бази даних на
основі методу нормалізації відношень. Реалізувати схему бази
даних на основі елементів рахунку за телефоні переговори.
Теоретичні відомості
Для визначення понять у термінах реляційної моделі даних
визначимо відповідність між термінами різних рівнів моделювання
БД (табл. 1.1):
Таблиця 1.1
Відповідність термінології
Реляційні БД ERD Реляційні MS SQL
СУБД
Відношення Сутність Файл Таблиця
Кортеж Запис Запис Рядок
Атрибут Характеристика Поле Стовпчик

Реляційна база даних – набір логічно зв’язаних відношень,

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

14
просту і регулярну структуру. Результатом нормалізаії є логічна
модель БД.
Функціональна залежність А–>В є повною функціональною
залежністю, якщо знищення якого-небудь атрибута з А приводить
до втрати цієї залежності. Частковою функціональною залежністю
називається така залежність А–>В, яка зберігається у разі
знищення якогось атрибута в А.
Транзитивна залежність. Якщо для атрибутів А, В і С
деякого відношення існують залежності вигляду А–>В і В–>С, то
вважають, що атрибут С транзитивно залежить від атрибута А
через атрибут В (за умови, що атрибут А функціонально не
залежить ні від атрибута В, ні від атрибута С).
Надлишковість даних в БД є небажаним явищем, оскільки
призводить до збільшення об'єму пам'яті, уповільнює роботу БД.
Надлишковість даних є результатом в першу чергу дублювання
даних. Розрізняють незбиткове та збиткове дублювання даних.
Повністю усувати надлишковість не потрібно, оскільки при цьому
неможливо буде підтримувати БД як єдине ціле. Слід тільки
мінімізувати надлишковість, залишивши необхідне дублювання
даних.
Дублювання даних створює проблеми при виконанні операцій з
БД. Ці проблеми виникають при спробі зробити операції:
редагування, додавання або вилучення даних.
Аномаліями називається така ситуація в БД, яка призводить до
протирічь у БД, або суттєво ускладнює обробку даних.
Розрізняють аномалії модифікації, додавання і вилучення.

15
 Ненормалізована форма (UNF)

Знищення груп, що повторюються

Перша нормальна форма (1НФ)

Знищення залежностей від

частини первинного ключа

Друга нормальна форма (2НФ)

Знищення транзитивних залежностей

Третя нормальна форма (3НФ)

Знищення функціональних
залежностей аномалій, що залишились

Нормальна форма Бойса-Кодда (НФБК)

Рис. 2.1. Схема нормалізації відношень

Приклад. Розглянемо відношення Студент:

16
 Аномалія модифікації виникає при спробі змінити прізвище
декана. В цій ситуації необхідно переглянути всі кортежі. При
великих розмірах БД це потребує значного часу, при цьому
можливі помилки (у разі невірного введення прізвища), які
порушать цілісність БД.
Аномалія додавання виникає при додаванні інформації про
нового студента, при цьому необхідно вводити інформацію, яка
вже є в БД: назва факультету, прізвище декана. Крім того
неможливо створити нову групу поки не існує студентів, які в ній
займаються.
Аномалія вилучення виникає при спробі вилучити дані про
студента, який в групі поки ще один, наприклад Лемешко. В цьому
випадку зникне інформація про групу ІУСТ-22. Виконання
декомпозиції наведеного відношення дозволяє позбутися
вищеозначених аномалій.
Перша нормальна форма. Відношення знаходиться в 1НФ тоді
і тільки тоді, коли всі його атрибути є атомарними. Значення
атрибуту вважається атомарним, якщо воно є неподільним у всіх
застосуваннях.
Друга нормальна форма. Відношення знаходиться в 2НФ,
якщо воно знаходиться в 1НФ і кожен його непервинний атрибут
функціонально повно залежить від первинного ключа.
Неповною функціональною залежністю називається залежність
неключового атрибуту від частини ключа, що складається з
декількох атрибутів. Повна функціональна залежність передбачає
залежність неключового атрибуту від всіх атрибутів одночасно, що
входять до складу ключа.
Відношення знаходиться в 3НФ, якщо воно знаходиться в 2НФ і
жоден з непервинних атрибутів у відношенні не є транзитивно
залежним від первинного ключа.
Атрибут C транзитивно залежить від атрибуту A, якщо для
атрибутів A, B, C виконуються такі умови A > B і B > C, але
зворотня залежність відсутня.

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

Хід роботи
1. На основі інформаційних полів типового рахунку за телефонні
переговори будуємо ненормалізоване відношення. Виконуємо
перехід до першої нормальної форми.
2. Аналіз залежностей атрибутів відношення від первинного
ключа у першій нормальній формі дозволяє визначити наявні
неповні функціональні залежності атрибутів «П.І.Б»., «Адреса» з
детермінантом «№ р.р.» та «Дата початку періоду», «Дата
закінчення періоду» з детермінантом «Період» та «Вид
переговорів»  «Тариф». Виконаємо перехід у 2НФ.
3. Аналіз залежностей атрибутів відношення від первинного
ключа у другій нормальній формі дозволяє визначити відсутність

18
транзитивнозалежих атрибутів. Отже відношення існують у 3НФ.
4. Враховуючи, що у відношеннях немає потенційних ключів,
які перекриваються, то перевірку на НФБК здійснювати
недоцільно.
5. Наступним кроком є заміна природних ключів на штучні
для зменшення обсягів збереження інформації (через зменшення
розмірності полів-дублікатів).

Вимоги до звіту
Звіт містить:
1. Назву, тему і мету лабораторної роботи.
2. Зразок документа за індивідуальним завданням.
3. Виконану нормалізацію БД індивідуального завдання у
вигляді таблиць із позначеннями (за зразком із
лабораторної роботи).

19
 Лабораторна робота №3. Створення схем БД на
мові SQL.

Мета роботи: дослідження запитових технологій

створення схем БД на мові SQL в середовище MS SQL Server
Програмне та технічне забезпечення: ПЕОМ, MS SQL
Завдання: створити базу даних у середовищі програмування
MS SQL.
1. Створити базу даних за індивідуальним варіантом.
2. У відповідності до схеми БД спроектованої в лабораторній
роботі № 1 створити таблиці бази даних та визначити
зв’язки між ними.
3. Створити схему даних.
4. Виконати генерацію БД «Рейтинг» з AllFussion Data
Modeler (ERWin) в середовище MS SQL Server.
5. Відредагувати отриману БД.
Теоретичні відомості
Реляційна СУБД – СУБД, що керує базами даних на основі
реляційних моделей. Вимоги до реляційних СУБД:
Правило 0  фундаментальне правило. Будь-яка система, яка є
реляційною СУБД, повинна бути здатна управляти базами даних
виключно за допомогою її реляційних функцій.
Правило 1  правило заборони обхідних шляхів. Якщо
реляційна система має низькорівневу мову (з послідовною
порядковою обробкою даних), вона не може бути використана для
відміни або обходу правил і обмежень цілісності, складених на
реляційній мові вищого рівня (з обробкою відразу декількох
рядків).
Правило 2  представлення інформації. Вся інформація в
реляційній базі даних представляється в явному вигляді на
логічному рівні і лише єдиним чином – у вигляді значень у
таблицях.
Правило 3  оновлення представлень. Всі представлення, які є
теоретично оновлюваними, повинні оновлютися і в даній системі.

20
 Правило 4  незалежність обмежень цілісності. Специфічні
для даної РСУБД обмеження цілісності повинні визначатися на
мові реляційних даних і зберігатися в системному каталозі, а не у
прикладних програмах.
Правило 5  гарантований доступ. Для всіх і кожного елемента
даних реляційної бази даних повинен бути гарантований логічний
доступ на основі комбінації імені таблиці, значення первинного
ключа і значення імені стовпця.
Правило 6  динамічний інтерактивний каталог, побудований
за правилами реляційної моделі. Опис бази даних повинен бути
представленим на логічному рівні таким же чином, як і звичні дані,
що дозволить санкціонованим користувачам використовувати для
звернень до метаданих ту ж реляційну мову, що і в разі звернення
до даних.
Правило 7  універсальна мова даних. Реляційна система може
підтримувати декілька мов і різні режими роботи з терміналами.
Проте повинна існувати принаймні одна мова, оператори якої
дозволяють визначати такі конструкції: 1) визначення даних; 2) ви-
значення представлень; 3) маніпулювання даними; 4) обмеження
цілісності; 5) авторизація користувачів; 6) організація транзакцій
(запуск, фіксація і відміна).
Правило 8  високорівневі операції вставки, оновлення і
видалення. Здатність обробляти базові або похідні відношення
(представлення) як єдиний операнд повинна відноситися не лише
до процедур добування даних, але і до операцій вставки,
оновлення і видалення даних.
Правило 9  фізична незалежність від даних. Прикладні
програми і засоби роботи з терміналами повинні залишатися
логічно незмінними у разі внесення будь-яких змін у способи
зберігання даних або методи доступу до них.

Хід роботи

1. Запустити SQL Server Manager Studio Express.

2. Оновити реєстрацію локального сервера або зареєструвати
новий сервер баз даних (Server Register…) у вікні
„Зареєстровані сервери”.

21
3. У вікні оглядача об‘єктів виконати під‘єднання до сервера
(рис.3.1).

Рис.3.1
в Вікно SQL Server Manager Studio Express

1.1 Створення БД

Рис.3.2.Інфологічна модель БД

4. Створити БД (приклад Торгівельна фірма, схема рис. 3.2)

22
 Рис.3.3. Головне вікно БД та редактор запитів

Для створення БД конструктором середовища розробки баз

даних необхідно виконати наступні дії.
1. Натиснути правою кнопкою миші на «Бази даних» та
обрати пункт «Создать базу данных»(рис.3.4)

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

2. У вікні «Имя базы данных» написати назву бази також можна
обмежити розмір файлів бд (рис.3.5). Натиснути кнопку ОК.

23
 Рис.3.5. Обмеження розмірів БД.
3. У вікні «»Обозреватель объектов» обрати створену БД та
натиснувши кнопку + відкрити елементи БД (рис.3.6)

Рис.3.6. Елементи БД
4. Натиснути правою кнопкою миші на пункт «Таблиці» та
обрати Создать-> Таблицу (рис.3.7)

Визначення полів та типів данних в таблиці

24
Визначення властивостей таблиці

Визначення властивостей окремого поля, зокрема

встановлення ідентифікатора на поле id_postach.
5. Таким чином створити всі інші таблиці.

1.2 Генерація БД
1. Створити нову базу даних (контейнер) (DatabaseCreate
database…) Reiting.mdf (рис.3.4).

25
 Рис.3.4. Діалогове вікно створення БД

2. Відкрити схему даних БД «Рейтинг» в ALLFussion Process

Modeler.
3. Налаштувати джерело даних ODBC (рис. 3.5):

26
 Рис.3.5 Налаштувати джерело даних ODBC

4. В ERWin обрати БД (Choоse Database …) та визначити

під’єднання (DataBase Connect …)

27
 6. Перевірити модель і згенерувати БД:

Перейти в MS SQL Management Studio перевірити результат та

відредагувати базу дани.

Вимоги до звіту
Звіт з лабораторної роботи містить:
1. Тема та мета роботи
2. Лістинг SQL –scripts для БД за індивідуальним
варіантом
3. Схему створеної БД в середовище MS SQL
Management Studio
4. Схему сгенерованої БД «Рейтинг»

28
 Література
1. Коннолли Т. Базы данных. Проектирование, реализация и
сопровождение. Теория и практика / Т. Коннолли , К. Бегг – [3-е
издание. : пер. с англ.] – Спб. : БХВ-Петербург, 2003. – 1440 с.
2. Дейт К. Дж. Введение в системы баз данных / К. Дж. Дейт –
[8-е издание; пер. с англ.] – М.: Издательский дом «Вильямс»,
2005. – 1328 с.
3. Харрингтон Дж. Л. Проектирование реляционных баз
данных/ Дж. Л. Харрингтон [пер. с англ.] – М.: Издательство
«Лори», 2006. – 232 с.
4. Хомоненко А. Д. Базы данных: учебник для высших
учебных заведений / В. М. Цыганков, М. Г. Мальцев; под ред.
проф. А. Л. Хомоненко. – [4-е изд., доп. и перераб.] – СПб.:
«KOPOНА-принт», 2004.  736 с.
5. Райордам Р. Основы реляционных баз данных/ Р. Райордам
 [пер.с англ.] – М.: Издательско-торговый дом «Русская
Редакция», 2001. – 384 с.
6. Уолтерс Роберт. SQL Server 2008: ускоренный курс для
профессионалов/ Уолтерс Роберт, Коулс Майкл.  [пер. с англ.] –
М.: Издательский дом «Вильямс», 2008.  768 c.
7. Чкалов А. П. Базы данных: от проектирования до
разработки приложений / А.П. Чкалов. – СПб: BHV-Петербург,
2003. – 384 с.

29
 ДОДАТКИ
Додаток А

Варіант 1. «Ведення бази даних студентського містечка»

Всі студенти інституту, яким потрібен гуртожиток, реєструються у
студмістечку. Під час поселення в гуртожиток на студента заводиться
ОСОБИСТА КАРТКА, у якій зберігається така інформація: номер
картки, ПІБ, дата народження, факультет, група, № гуртожитку, №
кімнати, адреса батьків. У студмістечку є довідники: ФАКУЛЬТЕТИ, де
для кожного факультету зберігається назва факультету, телефон
деканату, ПІБ декана; ГРУПИ, де зазначені шифр групи і код
факультету; ГУРТОЖИТКИ, де зазначений номер гуртожитку, адреса,
телефон, ПІБ коменданта. Інформаційна система, що автоматизує роботу
адміністрації студмістечка, повинна виконувати хоча б такі задачі:
– формувати список студентів потрібного факультету з указівкою
номера гуртожитку, в якому вони мешкають;
– формувати список вільних місць по гуртожитках;
– формувати звіт про кількість студентів, що мешкають у
гуртожитку по кожному факультету;
– сформувати список студентів, які мешкають в обраному
гуртожитку за обраним номером кімнати.

Варіант 2. «Ведення бази даних обліку продукції, що випускається

підприємством» мс
Підприємство випускає декілька найменувань ПРОДУКЦІЇ
різноманітних марок. Кожна марка виробу визначеного найменування
має свою вартість і код.
Споживачами цієї продукції є підприємства, що замовляють
визначену кількість виробів різних марок до зазначеного ними терміну
(місяць одержання). Підприємства-споживачі складають свої
ЗАМОВЛЕННЯ. У замовленні зазначений код виробу, місяць одержання,
найменування підприємства. Списки підприємств-СПОЖИВАЧІВ із
своїми реквізитами (адреса, телефон, розрахунковий рахунок у банку)
зберігаються у підприємства-виробника.
На підприємстві ведеться облік кількості відправлених виробів по
кожному замовленню. Місячні і річні плани виробництва продукції
складаються на основі замовлень, що отримані підприємством від
замовників до 1 січня поточного року.
Задачі, які повинна вирішувати система, що проектується:

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

Варіант 3. «Ведення бази даних студентів»

У деканаті зберігаються основні дані про студента (ОСОБИСТА
КАРТКА), а саме: прізвище, ім’я, по батькові; дата народження;
домашня адреса; адреса проживання; рік вступу до інституту; вид
навчання (денне бюджетне, денне за контрактом, заочне бюджетне,
заочне за контрактом, екстернат); спеціальність (бакалаврат);
випускаюча кафедра; група; № залікової книжки; дата і причина
відрахування.
Студент може бути відрахований з таких причин: за заявою,
академічна неуспішність, грубе правопорушення правил поведінки в
інституті, закінчення інституту.
За кожною СПЕЦІАЛЬНІСТЮ зберігаються такі відомості:
державний № фаху, назва, кваліфікація, що присвоюється студенту-
випускнику. Система, що проектується, повинна вирішувати такі задачі:
– формувати список студентів за зазначенною групою,
бакалавратом, спеціальністю;
– видати списки відрахованих студентів з групуванням за
причинами відрахування;
– підрахувати кількість студентів у кожній групі за спеціальністю;
– формувати список спеціальності.

Варіант 4. «Ведення бази даних обліку сировини і матері алів на

складі»
Підприємство взуттєвої промисловості укладає ДОГОВОРИ з
постачальниками на постачання СИРОВИНИ і МАТЕРІАЛІВ для
нормальної роботи підприємства. У договорах указується, скільки
сировини або матеріалів повинні поставити кожний постачальник за
місяць. Одну і ту ж сировину або матеріал можуть постачати одночасно
декілька ПОСТАЧАЛЬНИКІВ.
Під час надходження сировини і матеріалів на склад оформляють
ПРИБУТКОВІ НАКЛАДНІ, в яких указують: постачальника, дату

31
надходження, вид сировини (матеріалів), кількість.
Сировина і матеріали відпускаються цехам для виконання
виробничої програми. Під час відвантаження сировини і матеріалів у
цеху оформляється ВИДАТКОВА НАКЛАДНА, у якій вказують: цех,
вид сировини (матеріалів), дату відвантаження, кількість.
Інформаційна система, що проектується, повинна вирішувати такі
задачі:
– визначати загальну кількість кожного виду сировини (матеріалів),
що повинна надійти відповідно до договорів за місяць на склад;
– визначити залишки сировини і матеріалів на поточний день
місяця, що повинні надійти від постачальників до кінця місяця;
– визначити кількість сировини і матеріалів, що надійшли в цех на
дане число;
– відобразити кількість сировини і матеріалів, що надійшли в цех
за вказаний період. Списки згрупувати за типами сировини.

Варіант 5. «Ведення бази даних обліку товарів у супермарк еті»

Супермаркет відправляє вироби різноманітним споживачам відповідно
до заздалегідь укладених договорів. У ДОГОВОРІ вказується така
інформація: номер договору, код споживача, дата підписання договору,
вид і кількість виробів на постачання, які визначені у договорі.
Кожний ВИРІБ має свій код, найменування, ціну, номер
прейскуранта.
Під час відправлення виробів споживачу заповнюється ТОВАРНО-
ТРАНСПОРТНА НАКЛАДНА (ТТН). До ТТН вносяться такі дані: номер
договору, по якому здійснюється відправлення виробів, вид виробу, його
кількість, дата відправлення. Потім ТТН передається у фінансовий
відділ, і на її підставі друкуються платіжні відомості, що направляються
за юридичними адресами споживача (адреса, розрахунковий рахунок у
банку).
Наприклад: розрахунковий рахунок 926530928 у Кіровському
відділенні Промбудбанку м. Донецька, адреса: 03495, м. Донецьк, вул.
Бережкова, 2.
Якщо вантаж відправлений автотранспортом, то в ТТН записується
номер машини, номер шляхового листа, сума автопослуг.
Якщо вантаж відправлений залізницею, то записується номер
контейнера або номер вагона, номер квитанції, сума послуг.
Якщо вантаж відправлений літаком, то записується номер рейса,
номер авіаквитанції, сума авіапослуг. Інформаційна система, що
проектується, може виконувати такі задачі:

32
 – формування списку виробів та їх споживачів;
– роздрукування звіту про відвантаження виробів за добу;
– роздрукування звіту про відвантаження виробів за місяць;
– сформування списку виробів для окремого споживача.

Варіант 6. «Ведення бази даних для автоматизації роботи бюро

діловодства»
Бюро діловодства організації, що складається з декількох ВІДДІЛІВ
(відділ технічної інформації, планово-економічний, відділ
перспективного проектування, конструкторський відділ, відділ
технічного супроводу), веде ділове листування з різноманітними
організаціями і підприємствами-замовниками, зберігає їхні реквізити
(найменування організації, адреса, телефон, номер розрахункового
рахунку, прізвище директора або представника).
Бюро діловодства веде облік вихідної КОРЕСПОНДЕНЦІЇ
(вихідний номер; дата; відділ, що відправляє кореспонденцію;
організація, до якої вона направляється), а також облік вхідної
кореспонденції (вхідний номер, дата одержання, відділ організації, якому
потрібно підготувати відповідь (за візою керівника), термін виконання).
Бюро діловодства веде облік тривалості і вартості міжміських
телефонних ПЕРЕГОВОРІВ відділів організації із різноманітними
організаціями (фіксуються номер телефону відділу, що замовляє
розмову, місто і номер телефону підприємства-абонента, тривалість
розмови).
Бюро діловодства друкує НАКАЗИ, веде їх облік (номер, прізвище
виконавця, дата виконання) і передає для виконання в той відділ, де
працює виконавець; контролює фактичну дату виконання наказу (оцінка
про передачу наказу і про його виконання).
Задачі, які може вирішувати система:
– формування помісячного звіту про міжміські телефонні розмови
кожного із відділів організації із вказівкою організацій-абонентів, дат,
тривалості розмов і з підбиттям підсумків щодо вартості переговорів;
– формує список вхідної кореспонденції за місяць.
– формує список вихідної кореспонденції за місяць.
– формує звіт про невиконані в термін накази по відділах
організації за рік.

Варіант 7. «Ведення бази даних обліку відряджень та лікарняних

листів»
Під час працевлаштування співробітники підприємства заповнюють

33
особисту картку, де зберігаються такі дані: прізвище, ім’я, по батькові,
рік народження, дата зарахування на роботу, посада, оклад, підрозділ,
ідентифікаційний код і т.д. Кожна людина має свій табельний номер. На
підприємстві декілька підрозділів.
Якщо співробітник хворів, він повинен подати лікарняний лист (Л
/Л) до табельної служби. У Л /Л зазначені ПІБ людини, дата початку
лікарняного, дата кінця лікарняного.
Якщо співробітник був у відрядженні, то відрядження теж
оформлюється через табельну службу, де вказується початок і кінець
відрядження.
Щомісяця система може формувати звіти за такими даними:
– довідник підрозділів;
– кількість людей, які мали відрядження по кожному підрозділу;
– кількість людей, які хворіли та мають лікарняні листи у
поточному місяці;
– загальний список людей, які мають лікарняні листи (за
алфавітом).

Варіант 8. «Ведення бази даних для аналізу захворюваності

студентів»
У студентській поліклініці зберігаються КАРТКИ студентів, де
зазначені такі дані: номер картки, ПІБ, факультет, група, адреса
проживання.
Під час відвідування студентом поліклініки лікар ставить йому
ДІАГНОЗ. Лікар заносить діагноз і дату ВІДВІДУВАННЯ поліклініки до
картотеки захворюваності студентів.
Система повинна здійснювати підбиття підсумків щодо
захворюваності студентів та готувати такі вихідні дані:
– списки студентів, що відвідували поліклініку у кожному місяці;
– списки студентів, що хворіли за згаданим діагнозом;
– формування звіту про загальну кількість студентів, що хворіли
грипом у заданому місяці по кожному факультету;
– загальна кількість студентів, що хворіли за згаданим діагнозом
протягом року по кожному факультету.

Варіант 9. «Ведення бази даних формування груп навчання»

На початку кожного семестру студенти мають можливість ознайомитись
з КАТАЛОГОМ курсів, який містить список предметів, що вивчаються в
цьому семестрі. Інформація про курси повинна містити прізвище
викладача, назву факультету і короткий опис, що допомагає СТУДЕНТУ

34
зробити вибір.
Система, що проектується, дозволить студенту обрати чотири курси у
наступному семестрі. Крім того, кожному студенту необхідно додатково
вказати ще два варіанти, на випадок якщо курс буде переповнений чи
відмінений. На курс не повинно бути записано більше двадцяти чи
менше п’яти студентів. Курс, на який запишеться менше п’яти студентів,
буде відмінено. По завершенні РЕЄСТРАЦІЇ система направляє
інформацію до системи оплати для встановлення РАХУНКІВ студентам.
ВИКЛАДАЧІ повинні мати можливість доступу до системи для обрання
курсу, який вони будуть викладати.
У кожному семестрі виділяється певний час, протягом якого студенти
можуть міняти свій розклад і отримувати доступ до системи для
додавання чи відміни обраних курсів. Система повинна мати можливості
видати:
– список курсів;
– список груп, що сформовані для курсу;
– список зайнятих викладачів;
– список відмінених курсів.

Варіант 10. «Ведення бази даних формування розкладу

занять»
На факультеті існує одна або декілька СПЕЦІАЛЬНОСТЕЙ. На
кожній спеціальності навчаються не менше однієї ГРУПИ на кожному з
6 курсів. Для кожної спеціальності на кожний семестр складається
НАВЧАЛЬНИЙ ПЛАН, за яким проводяться заняття за видами та
відповідної тривалості. На факультеті працюють ВИКЛАДАЧІ, які
можуть викладати від одного предмета до декількох предметів.
Поставлена задача розробити інформаційну систему, призначення
якої таке:
– формування довідника спеціальностей факультету;
– формування списків груп на спеціальностях;
– формування списку викладачів та дисциплін, які вони
викладають;
– формування розкладу проведення занять для окремої групи
спеціальності;
– формування розкладу проведення занять викладачами кафедри.

Варіант 11. «Ведення бази даних завантаження обладнання цехів»

На підприємстві існує декілька ЦЕХІВ. У кожному цеху працює
декілька БРИГАД. Для кожної бригади на місяць складається ПЛАН

35
ВИРОБІТКУ із зазначенням кількості ВИРОБІВ та ОБЛАДНАННЯ, на
якому вони виготовляються. Для кожного виробу визначений час
обробки обладнанням певного типу. Під час роботи ведеться відомість
обліку робочого часу робітників на певних видах обладнання, із
зазначенням дати та часу початку та закінчення роботи і ПІБ працівника.
Система повинна формувати таку звітність:
 список робітників, упорядкований за цехами та бригадами;
 список обладнання, встановленого в цеху;
 підсумки за кількістю відпрацьованого кожним робітником часу;
 загальні простої обладнання по цеху за певний місяць,
враховуючи двозмінну роботу.

Варіант 12. «Ведення бази даних обліку викладацього складу ВНЗ»

Система має забезпечувати аналіз участі ВИКЛАДАЧІВ у
навчальному процесі вузу і підтримку з ними офіційної комунікації. Під
викладацьким складом ВНЗ розуміються як штатні, так і запрошені
викладачі. ІС повинна підтримувати внесення даних нового викладача
(ПІБ, адреса, телефони, домашній та робочий, родинне становище, дата
народження, науковий ступінь, вчене звання, дисципліни, що
викладаються, та НАВАНТАЖЕННЯ (групи, курси, години, за всіма
видами навантаження)). ВИДИ НАВАНТАЖЕННЯ: викладання лекцій,
практичних, семінарів, лабораторних робіт, приймання модульних
контролів, іспитів, заліків, консультації, керівництво дипломними та
курсовими роботами.
Система має формувати таку звітність:
 перелік штатних та запрошених викладачів;
 перелік викладачів з науковим ступенем;
 загальне навантаження викладачів за рік;
 картку навантаження окремого викладача.

Варіант 13. «Ведення бази даних обліку викладацього складу ВНЗ»

ВНЗ надає громадянам України платні навчальні послуги. Для цього
укладаються ДОГОВОРИ, в яких визначаються суми, терміни оплати,
умови навчання та інші дані, що регламентують взаємовідносини ВНЗ з
клієнтами. Враховуючи, що термін договору становить не менше 2 років,
ВНЗ має змогу переглядати умови та розміри оплати.
Система веде облік клієнтів ВНЗ. Під клієнтами розуміються фізичні
особи, що беруть участь у навчальному процесі вузу, та їх поручителі –
як фізичні, так і юридичні особи. Необхідно забезпечити зберігання
інформації про КЛІЄНТІВ (вигляд, назва (ПІБ), адреса тощо), інформації

36
про укладені ДОГОВОРИ (№, дата, сума, термін), передбачити
можливість зберігання змін суми контракту і поточний СТАН
РОЗРАХУНКІВ.
Система формує такі види звітів:
 список клієнтів ВНЗ за категоріями;
 список боржників на поточну дату;
 список договорів, які закінчуються у поточному році;
 динаміка взаєморозрахунків по кожному клієнту.

Варіант 14. «Ведення бази даних бібліотечних видань»

База даних призначена для зберігання даних про придбані
бібліотекою ВИДАННЯ (монографії, довідники, збірники статей тощо),
інформації про місцезнаходження окремих ЕКЗЕМПЛЯРІВ (палітурок)
кожного видання і ВІДОМОСТЕЙ про ЧИТАЧІВ.
Для ведення бібліотечних каталогів, організації пошуку необхідних
видань і бібліотечної статистики у базі повинні зберігатися відомості,
велика частина яких розміщується в анотованих каталожних картках.
Слід виділити такі атрибути КАТАЛОЖНОЇ КАРТКИ: автор, назва,
номер тому, вид видання (збірка, довідник, монографія, ...), за чиєю
редакцією, повторність видання (друге, одинадцяте тощо), характер
перевидання (виправлене, доповнене, перероблене, стереотипне тощо),
місто видання, видавництво, рік випуску видання, видавнича анотація
або реферат, бібліотечний шифр (наприклад, ББК 32.973), авторський
знак (наприклад, Д27).
До об’єктів та атрибутів, що дозволяють охарактеризувати окремі
ЕКЗЕМПЛЯРИ видань (палітурки), місця їх зберігання і читачів, можна
віднести: номер кімнати (приміщення для зберігання палітурок), номер
стелажу в кімнаті, номер полиці на стелажі, номер (інвентарний номер)
палітурки, дата придбання конкретної палітурки, ціна конкретної
палітурки, дата розміщення конкретної палітурки на конкретному місці,
дата вилучення палітурки зі встановленого місця.
Для зберігання ВІДОМОСТЕЙ про ЧИТАЧА слід знати такі дані:
номер читацького квитка (формуляру), прізвище читача, ім’я читача, по
батькові читача, адреса читача, телефон читача, дата видачі читачу
конкретної палітурки, термін, на який конкретну палітурку видано
читачу, дата повернення палітурки.
Система повинна формувати таку звітність:
 перелік куплених за період видань;
 дані про книгу (пошук за автором і назвою);
 загальна кількість прочитаної читачем літератури за період;

37
  кількість запитів книги за рік  середня за всіма екземплярами
одного видання.

Варіант 15. Ведення бази даних управління проектами

впровадження ЛКМ
Розробити БД управління проектами та обліку вартості виконаних
робіт у проектному відділі ЛКМ. Звітність системи є вхідними даними
для бухгалтерського розрахунку собівартості виконаних замовлень та
оплати праці персоналу. Ефективне виконання поставлених задач не
можливе без створення бази даних, що зберігає відомості про
ПЕРСОНАЛ, ПРОЕКТИ, виконані проектні РОБОТИ, НОРМАТИВИ
часу та оплати персоналу, відомості про оплату та ЗАЙНЯТІСТЬ
персоналу на проектах.
Дана система має забезпечити формування такої звітності:
 розрахунок тривалості проектних робіт;
 розрахунок вартості окремих етапів виконання проектів;
 розподіл персоналу за проектами;
 розрахунок витрат часу у розрізі персоналу та проекту.

Варіант 16. Ведення бази даних АТС

На вхід системи надходить інформація з АТС: номер абонента, дата
дзвінка, тип дзвінка, час початку та закінчення розмови та інформація з
платіжних систем про СТАН ОПЛАТИ послуг: номер абонента, період
та сума оплати.
Ведення бази даних вузла зв’язку повинне забезпечувати виконання
таких функцій: реєстрація ДЗВІНКІВ; визначення параметрів дзвінків
(номери абонентів, дата, час дзвінка, тривалість, тарифна група);
коригування та відстеження ТАРИФІВ.
Система повинна формувати таку звітність:
 перелік даних абонентів вузла зв’язку;
 перелік дзвінків визначеного абонента за певний період;
 підбиття підсумків за звітний період за використаний трафік,
згрупований за видами послуг та за окремими абонентами;
 перелік боржників на певну дату періоду.

Варіант 17. Ведення бази даних лікарні

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

38
звітності роботи поліклінічних закладів, облік здійснюється на базі
затвердженої форми «Талона амбулаторного обслуговування».
Впровадження комп’ютерної інформаційної системи дозволить
прискорити роботу щодо аналізу роботи ЛІКАРІВ та обліку
ЗАХВОРЮВАНЬ, підвищить достовірність результату, дозволить
упровадити методи прогнозу захворювань, покращити обслуговування
населення.
Вхідні дані системи формуються на базі ТАЛОНА амбулаторного
ПАЦІЄНТА, який містить дані: ПІБ, дата народження, адреса пацієнта,
дата відвідування, лікар, кабінет, діагноз, лікування. ДОВІДНИК
захворювань організувати згідно із затвердженим довідником Мінздраву.
Також система зберігає відомості про графіки роботи ЛІКАРІВ, зокрема
ПІБ лікаря, фах, дату, зміну, кабінет прийому тощо.
Перелік запитів, що повинні виконуватися у режимі on-line:
 графік роботи лікарів;
 перелік пацієнтів певного лікаря за період;
 кількість захворювань вказаного діагнозу на зазначений період
часу;
 показники роботи лікаря за цілями відвідування пацієнтів
(лікувальна, профогляд) тощо.

Варіант 18. Ведення бази даних обліку відряджень

На підставі наказу кожному СПІВРОБІТНИКУ, направленому у
відрядження, виписується посвідчення про відрядження.
ПОСВІДЧЕННЯ ідентифікується номером і датою видачі. У ньому
також указується ПІБ відрядженого, назва відділу, у якому він працює,
пункт призначення і термін відрядження (дата початку і дата закінчення).
На підставі посвідчення про відрядження відділом бухгалтерського
обліку проводиться попередній РОЗРАХУНОК витрат для видачі авансу.
Попередній розрахунок ведеться за трьома статтями: проїзд, квартирні,
добові.
Для розрахунку проїзду є ДОВІДНИК, у якому зазначена вартість
проїзду до пункту призначення. У розрахунку суми авансу проїзд
оплачується на прямий і зворотний шлях за вартістю купейного квитка.
Сума квартирних і добових розраховується виходячи з категорії
міста: у столиці  50 грн. на добу; у звичайному місті  40 грн. на добу;
районний центр  35 грн. на добу.
Співробітник одержує розрахункову суму авансу в касі бухгалтерії
відповідно до місця призначення і тривалості відрядження.
Задачі:

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

Варіант 19. Ведення бази даних «Банки даних»

У Національній академії наук України створена асоціація з розвитку
і використання інформаційних ресурсів «ІНФОНАУКА». Основними
цілями своєї діяльності «ІНФОНАУКА» вважає поліпшення якості
інформаційного обслуговування, у першу чергу наукових досліджень, а
також підвищення ефективності використання автоматизованих
інформаційних систем і банків даних.
З цією метою організуються банки даних за науковими напрямами.
Існує КЛАСИФІКАТОР наукових напрямків, що містить код і
найменування. Список наукових напрямків (для прикладу: застосування
ЕОМ; розробка і використання пакетів прикладних програм; порошкова
металургія; устаткування для зварювання; інформаційне забезпечення
процесів; управління наукою).
За кожним з наукових напрямків організовується БАНК ДАНИХ.
Власниками банку даних є, як правило, наукові ОРГАНІЗАЦІЇ (інститут
кібернетики; інститут електрозварювання; інститут матеріалознавства;
інститут теоретичної фізики; УкрЦНТІ тощо). ОРГАНІЗАЦІЯ може
бути власником тільки одного банку даних. ОРГАНІЗАЦІЯ має
юридичну адресу, розрахунковий рахунок, ПІБ керівника і головного
бухгалтера.
БАНК ДАНИХ має свій код, назву, відповідального за його ведення.
Приклади назв банків даних: пакет прикладних програм для ЕОМ;
устаткування для зварювання; наукові досягнення НАН України;
порошкова металургія.
Асоціація «Інфонаука» збирає ЗАЯВКИ на інформаційне
обслуговування від організацій НАН України та інших відомств, які є
замовниками, що також повідомляють свої юридичні адреси.
В одній ЗАЯВЦІ міститься прохання про задоволення інформаційної
потреби за певним напрямком. За заявкою складається запит, що може

40
бути реалізований на декількох банках даних. Задачі:
 видати кількість заявок, виконаних кожним банком даних;
 видати кількість заявок за кожним науковим напрямком;
 видати список існуючих наукових напрямків;
 відобразити список заявок за обраним науковим напрямком.

Варіант 20. Ведення бази даних «Житлово-комунальне

господарство»
Мінімальний список характеристик МЕШКАНЦІВ: номер під’їзду,
номер квартири, загальна площа, корисна площа, кількість кімнат,
прізвище квартиронаймача, дата прописки, кількість членів сім’ї,
кількість дітей у сім’ї, наявність заборгованості по комунальних
платежах, примітка. Крім того, зберігається ПЕРЕЛІК ПОСЛУГ, описи
будівель та прибудинкових територій, ведеться РЕЄСТР наданих послуг
та формується вартість витрат на житло.
Задачі:
 видати список мешканців будинку;
 видати перелік зареєстрованих осіб за період;
 визначити вартість 1 кв. м житлової площі для окремих будинків
за переліком наданих послуг;
 визначити квартирну плату мешканців окремих квартир.

41
 Додаток Б
Таблиця 1
Ненормалізоване відношення
№ р.р ПІБ Адреса Вид Тариф Кількість Вартість Період Дата початку Дата закінчення
переговорів хвилин періоду періоду
341 Петров Василь вул. Корольова, 21, міські 0,05 240 12.00 1 01.01.09 31.01.09
Сергійович кв.17 міжміські 0,50 25 12.50
міжнародні 1,50 15 22.50
452 Волошин вул. Космонавтів, 24, міські 0,05 342 17.10 1 01.01.09 01.02.09
Андрій Якович кв.45 міжміські 0,50 32 16.00
міжнародні 1,50 15 22.50
341 Петров Василь вул. Корольова, 21, міські 0,05 300 15.00 2 01.02.09 28.02.09
Сергійович кв.17 міжміські 0,50 12 6.00
міжнародні 1,50 18 27.00
Первинний ключ
№ р.р ПІБ Адреса Вид Тариф Кількість Вартість Період Дата початку Дата
переговорів хвилин періоду закінчення
періоду
341 Петров Василь Сергійович вул. Корольова, 21, кв.17 міські 0,05 240 12 1 01.01.2009 31.01.2009
341 Петров Василь Сергійович вул. Корольова, 21, кв.18 міжміські 0,50 25 12.5 1 01.01.2009 31.01.2009

341 Петров Василь Сергійович вул. Корольова, 21, кв.19 міжнародні 1,50 15 22.5 1 01.01.2009 31.01.2009
452 Волошин Андрій Якович вул. Космонавтів, 24, кв.45 міські 0,05 342 17.1 1 01.01.2009 01.02.2009
452 Волошин Андрій Якович вул. Космонавтів, 24, кв.46 міжміські 0,50 32 16 1 01.01.2009 01.02.2009
452 Волошин Андрій Якович вул. Космонавтів, 24, кв.47 міжнародні 1,50 15 22.5 1 01.01.2009 01.02.2009
341 Петров Василь Сергійович вул. Корольова, 21, кв.17 міські 0,05 300 15 2 01.02.2009 28.02.2009
341 Петров Василь Сергійович вул. Корольова, 21, кв.18 міжміські 0,50 12 6 2 01.02.2009 28.02.2009
343 Петров Василь Сергійович вул. Корольова, 21, кв.19 міжнародні 1,50 18 27 2 01.02.2009 28.02.2009

Неповна функціональна Неповна функціональна Неповна функціональна

залежність залежність залежність
Рис. 1. 1. Перша нормальна форма (1 НФ)

42
 Міністерство освіти і науки України
ЖДТУ Житомирський державний технологічний університет

№ Вид Кількість
Період Вартість
р.р переговорів хвилин
341 1 міські 240 12
341 1 міжміські 25 12.5
341 1 міжнародні 15 22.5
452 1 міські 342 17.1
452 1 міжміські 32 16
452 1 міжнародні 15 22.5
341 2 міські 300 15
341 2 міжміські 12 6
343 2 міжнародні 18 27

Транзитивна
залежність
Дата початку Дата закінчення
Період
періоду періоду
1 01.01.2009 31.01.2009
2 01.02.2009 28.02.2009

№ р.р ПІБ Адреса

341 Петров Василь Сергійович вул. Корольова, 21, кв.17
452 Волошин Андрій Якович вул. Космонавтів, 24, кв.47

Вид
Тариф
переговорів
міські 0,05
міжміські 0,50
міжнародні 1,50
Рис. 1.2. Друга нормальна форма (2 НФ) і (ЗНФ – так як немає
транзитивних залежностей)
 Первинний ключ
№ р.р Код виду
Вид Кількість Вартіст Вид
Період перегово Тариф
переговорів хвилин ь переговорів
рів
341 1 1 240 12 1 міські 0,05
341 1 2 25 12.5 2 міжміські 0,50
341 1 3 15 22.5 3 міжнародні 1,50
452 1 1 342 17.1
452 1 2 32 16
452 1 3 15 22.5
341 2 1 300 15
341 2 2 12 6
341 2 3 18 27

Період Дата початку Дата закінчення

періоду періоду
1 01.01.2009 31.01.2009
2 01.02.2009 28.02.2009

№ р.р ПІБ Адреса

341 Петров Василь Сергійович вул. Корольова, 21, кв.17
452 Волошин Андрій Якович вул. Лятошинського, 24, кв.45

Рис. 1.3. Заміна природного ключа штучним

2
 Зміст
ВСТУП ................................................................................................... 3

Лабораторна робота №1. Концептуальне моделювання БД ............. 5

Лабораторна робота №2. Проектування баз даних методом

нормалізації відношень ...................................................................... 14

Лабораторна робота №3. Створення схем БД на мові SQL. ........... 20

Література ............................................................................................ 29

ДОДАТКИ ........................................................................................... 30

Додаток А ........................................................................................ 30

Додаток Б ......................................................................................... 42