Лабораторна робота

Концептуальне проектування бази даних

Цілі
Навчитись аналізувати предметну область.
Сформувати уявлення про об’єкти, їх атрибути та бізнес-процеси
предметної області за обраною темою.
Навчитись створювати Use Case – діаграми та різні варіанти ER-
діаграм.

Теоретичні відомості
Етапи проектування бази даних та їх процедури
Проектування бази даних здійснюється в три етапи:
1) концептуальне проектування;
2) логічне проектування;
3) фізичне проектування.

Процедури концептуального проектування

Мета етапу концептуального проектування - створення
концептуальної моделі даних виходячи з уявлень користувачів про
предметну область. Для її досягнення виконується ряд послідовних
процедур.
1. Визначення сутностей та їх документування. Для ідентифікації
сутностей визначаються об'єкти, які існують незалежно від інших. Такі
об'єкти є сутностями. Кожній сутності присвоюється осмислене ім'я,
зрозуміле користувачам. Імена та опису сутностей заносяться в словник
даних. Якщо можливо, то встановлюється очікувана кількість екземплярів
кожної сутності.
2. Визначення зв'язків між сутностями і їх документування.
Визначаються тільки ті зв'язки між сутностями, які необхідні для
задоволення вимог до проекту бази даних. Встановлюється тип кожної з
них. Визначається клас приналежності сутностей. Зв'язкам присвоюються
осмислені імена, виражені дієсловами. Розгорнутий опис кожного зв'язку
із зазначенням його типу і класу приналежності сутностей, що беруть
участь в зв'язку, заноситься в словник даних.
3. Створення ER-моделі предметної області. Для подання сутностей і
зв'язків між ними використовуються ER-діаграми. На їх основі створюється
єдиний наочний образ моделі предметної області - ER-модель предметної
області.
 4. Визначення атрибутів і їх документування. Виявляються всі
атрибути, що описують сутність створеної ER-моделі. Кожному атрибуту
присвоюється осмислене ім'я, зрозуміле користувачам. По кожному
атрибуту в словник даних поміщаються такі відомості:
 ім'я атрибута і його опис;
 тип і розмірність значень;
 значення, яке приймається для атрибута за замовчуванням (якщо
таке є);
 чи може атрибут мати Null-значення;
 чи є атрибут складовим, і якщо це так, то з яких простих атрибутів
він складається. Наприклад, атрибут "П.І.Б. студента" може
складатися з простих атрибутів "Прізвище", "Ім'я", "По батькові",
а може бути простим, що містить єдині значення, як-то "Колесник
Іван Тимофійович". Якщо користувач не потребує доступу до
окремих елементів "П.І.Б.", то атрибут представляється як
простий;
 чи є атрибут розрахунковим, і якщо це так, то як обчислюються
його значення.
5. Визначення значень атрибутів і їх документування. Для кожного
атрибута сутності, що бере участь в ER-моделі, визначається набір
допустимих значень і йому присвоюється ім'я. Наприклад, атрибут "форма
навчання" може мати тільки значення "денна", "заочна", "дистанційна".
Оновлюються записи словника даних, що відносяться до атрибутів, - в них
заносяться імена наборів значень атрибутів.
6. Визначення первинних ключів для сутностей та їх
документування. На цьому кроці займаються визначенням первинного
ключа - як атрибуту або набору атрибутів сутності, що дозволяє
унікальним чином ідентифікувати її екземпляри. Відомості по первинних
ключах поміщаються в словник даних.
7. Обговорення концептуальної моделі даних з кінцевими
користувачами. Концептуальна модель даних представляється ER-
моделлю із супровідною документацією, що містить опис розробленої
моделі даних. Якщо будуть виявлені невідповідності предметної області,
то в модель вносяться зміни до тих пір, поки користувачі не підтвердять,
що запропонована ним модель адекватно відображає їх особисті уявлення.

Процедури логічного проектування

Мета етапу логічного проектування - перетворення концептуальної
моделі на основі обраної моделі даних в логічну модель, яка не залежатиме
від особливостей використовуваної в подальшому СУБД для фізичної
реалізації бази даних. Для її досягнення виконуються наступні процедури.
 1. Вибір моделі даних. Найчастіше вибирається реляційна модель
даних в зв'язку з наочністю табличного представлення даних і зручності
роботи з ними.
2. Визначення набору таблиць виходячи з ER-моделі і їх
документування. Для кожної сутності ER-моделі створюється таблиця. Ім'я
сутності - ім'я таблиці. Здійснюється формування структури таблиць на
підставі визначених в концептуальній моделі правил. Встановлюються
зв'язки між таблицями за допомогою механізму первинних і зовнішніх
ключів. Структури таблиць і встановлені зв'язки між ними документуються.
3. Нормалізація таблиць. Для правильного виконання нормалізації
проектувальник повинен глибоко вивчити семантику і особливості
використання даних. На цьому кроці він перевіряє коректність структури
таблиць, створених на попередньому кроці, за допомогою застосування до
них процедури нормалізації. Вона полягає у приведенні кожної з таблиць,
щонайменше, до 3НФ. В результаті нормалізації виходить дуже гнучкий
проект бази даних, що дозволяє легко вносити в неї необхідні розширення.
4. Перевірка логічної моделі даних на предмет можливості виконання
всіх транзакцій, передбачених користувачами. Транзакція - це набір дій,
виконуваних користувачем або прикладною програмою з метою зміни
вмісту бази даних. Так, прикладом транзакції в проекті БАНК може бути
передача права розпоряджатися рахунками деякого клієнта іншому
клієнту. В цьому випадку в базу даних буде потрібно внести відразу кілька
змін. Якщо під час виконання транзакції відбудеться збій в роботі
комп'ютера, то база даних виявиться в суперечливому стані, так як деякі
зміни вже будуть внесені, а решта ще ні. Тому всі часткові зміни повинні
бути скасовані для повернення бази даних в попередній несуперечливий
стан.
Перелік транзакцій визначається діями користувачів в предметній
області. Використовуючи ER-модель, словник даних і встановлені зв'язки
між первинними і зовнішніми ключами, проводиться спроба виконати всі
необхідні операції доступу до даних вручну. Якщо будь-яку операцію
виконати вручну не вдається, то складена логічна модель даних є
неадекватною і містить помилки, які треба усунути. Можливо, вони
пов'язані з пропуском в моделі сутності, зв'язку або атрибута.
5. Визначення вимог підтримки цілісності даних і їх документування.
Ці вимоги є обмеженнями, які вводяться з метою запобігти занесення в
базу даних суперечливих даних. На цьому кроці питання цілісності даних
висвітлюються безвідносно до конкретних аспектів її реалізації. Повинні
бути розглянуті наступні типи обмежень:
 обов'язкові дані. З'ясовується, чи є атрибути, які не можуть
мати null-значень;
 обмеження для значень атрибутів. Визначаються допустимі
значення для атрибутів;
  цілісність сутностей. Вона досягається, якщо первинний ключ
сутності не містить null-значень;
 цілісність посилань. Вона розуміється так, що значення
зовнішнього ключа повинно обов'язково бути присутнім в
первинному ключі одному з рядків таблиці для батьківської
сутності;
 обмеження, що накладаються бізнес-правилами. Наприклад, у
випадку з проектом БАНК може бути прийнято правило, що
забороняє клієнту розпоряджатися, скажімо, більш ніж трьома
рахунками.
Відомості про всі встановлені обмеження цілісності даних
поміщаються в словник даних.
6. Створення остаточного варіанту логічної моделі даних і
обговорення його з користувачами. На цьому кроці готується остаточний
варіант ER-моделі, що представляє логічну модель даних. Сама модель і
оновлена документація, включаючи словник даних і реляційну схему
зв'язку таблиць, представляється для перегляду та аналізу користувачам,
які повинні переконатися, що вона точно відображає предметну область.

Процедури фізичного проектування

Мета етапу фізичного проектування - опис конкретної реалізації бази
даних, що розміщується в зовнішній пам'яті комп'ютера. Це опис структури
зберігання даних і ефективних методів доступу до даних бази. При
логічному проектуванні відповідають на питання - що треба зробити, а при
фізичному - вибирається спосіб, як це зробити. Процедури фізичного
проектування наступні.
1. Проектування таблиць бази даних засобами обраної СУБД.
Здійснюється вибір реляційної СУБД, яка буде використовуватися для
створення бази даних, що розміщується на машинних носіях. Глибоко
вивчаються її функціональні можливості з проектування таблиць. Потім
виконується проектування таблиць і схеми їх зв'язку в середовищі СУБД.
Підготовлений проект бази даних описується в документації.
2. Реалізація бізнес-правил у середовищі обраної СУБД. Оновлення
інформації в таблицях може бути обмежена бізнес-правилами. Спосіб їх
реалізації залежить від обраної СУБД. Одні системи для реалізації вимог
предметної області пропонують більше можливостей, інші - менше. У
деяких системах взагалі відсутня підтримка реалізації бізнес-правил. В
такому випадку розробляються програми для реалізації цих обмежень.
Всі рішення, прийняті в зв'язку з реалізацією бізнес-правил
предметної області, детально описуються в супровідній документації.
3. Проектування фізичної організації бази даних. На цьому кроці
обирається найкраща файлова організація для таблиць. Визначаються
транзакції, які будуть виконуватися в проектованій базі даних, і
виділяються найбільш важливі з них. Аналізується пропускна здатність
транзакцій - кількість транзакцій, які можуть бути оброблені за заданий
інтервал часу, і час відповіді - проміжок часу, необхідний для виконання
однієї транзакції. Намагаються підвищити пропускну спроможність
транзакцій і зменшити час відповіді. На підставі зазначених показників
приймаються рішення про оптимізацію продуктивності бази даних шляхом
визначення індексів в таблицях, що прискорюють вибірку даних з бази,
або зниження вимог до рівня нормалізації таблиць. Проводиться оцінка
дискового обсягу пам'яті, необхідного для розміщення створюваної бази
даних. Намагаються його мінімізувати.
Прийняті рішення по викладеним питань документуються.
4. Розробка стратегії захисту бази даних. База даних являє собою
цінний корпоративний ресурс, і організації її захисту приділяється велика
увага. Для цього проектувальники повинні мати повне і чітке уявлення про
всі засоби захисту, що надаються обраною СУБД.
5. Організація моніторингу функціонування бази даних і її
налаштування. Після створення фізичного проекту бази даних
організовується безперервне спостереження за її функціонуванням.
Отримані відомості про рівень продуктивності бази даних
використовуються для її налаштування. Для цього залучаються також
засоби обраної СУБД.
Рішення про внесення будь-яких змін в функціонуючу базу даних
повинні бути обдуманими і всебічно зваженими.

Інструменти
Варіант 1 - оптимальний. Ви можете використовувати будь-які зручні
для вас оффлайнові(наприклад MS Visio | SAP PowerDesigner) або олайнові
(наприклад https://creately.com | https://www.draw.io) інструменти
побудови діаграм.
Варіант 2 - прийнятний. Також ви можете використовувати будь-які
не спеціалізовані програми (MS Word, Paint, Adobe Photoshop, Corel Draw,
і т.п.), проте це те саме, що забивати цвяхи мікроскопом.
Варіант 3 – «олдскульний». Нарешті, ви можете користуватись
звичайним умовним олівцем та папером для виконання даної лабораторної
роботи, але наприкінці все одно треба буде оцифрувати результати вашої
роботи, відсканувавши або сфотографувавши їх.

Завдання
1. Уважно прочитати дані рекомендації до лабораторної роботи.
2. Обрати тему предметної області. Проаналізувати предметну
область.
3. Замислитись над майбутньою інформаційною системою(ІС).
Для простоти пропонується в якості ІС обирати веб-додаток.
4. Описати завдання майбутньої інформаційної системи. Приклад:
Завдання. ІС «ПОСТАЧАННЯ ТОВАРІВ»

Завод "Sun" поставляє товари (виріб А, виріб В, виріб С і ін.)

Замовникам за договорами. Для кожного товару визначені
плани поставок.

Необхідно спроектувати базу даних delivery_of_goods,

інформація якої буде використовуватися для аналізу
виконання заводом планів поставок.

В БД повинна зберігатися інформація:

 про товари: код товару, найменування товару, ціна
товару (тис. грн.);
 замовлення на поставку товарів: код замовлення,
найменування замовника, адреса замовника, телефон,
номер договору, дата укладення договору, найменування
товару, планова поставка (шт.);
 фактичне відвантаження товарів: код відвантаження, код
замовлення, дата відвантаження, відвантажено товару
(шт.).
При проектуванні БД необхідно враховувати наступне:
 товар має кілька замовлень на поставку. Замовлення
відповідає одному товару;
 товару можуть відповідати кілька відвантажень. У
відвантаження можуть брати участь кілька товарів.
Крім того слід врахувати:
 товар не обов'язково має замовлення. Кожному
замовленню обов'язково відповідає товар;
 товар не обов'язково відвантажується замовнику. Кожне
відвантаження обов'язково відповідає деякому товару.

5. Виділити ролі користувачів для майбутньої ІС. Наприклад:

гість, адміністратор сайту, редактор, адміністратор БД, тощо.
6. Створити діаграму сценаріїв використання (Use Case).
Приклад:
Рисунок 1.1 – Приклад Use Case діаграми для ресторану/кафе
7. Визначити об’єкти(сутності) предметної області.
8. Визначити взаємозв’язки між сутностями.
9. Створити спрощену ER-діаграму. Приклад:

Рисунок 1.2 –Приклад спрощенної ER-діаграми

10. Виділити атрибути кожної сутності.
11. Додати отримані атрибути в існуючу ER-діаграму. Приклад:
 Рисунок 1.3 –Приклад ER-діаграми з атрибутами
12. Визначити всі необхідні відомості по кодному атрибуту (див.
процедуру 4 концептуального проектування). Додати відомості
до ER-діаграми.
13. Виділити первинні та зовнішні ключі. Сформувати остаточні
зв’язки між сутностями. Внести відповідні зміни до ER-діаграми.
Приклад фінального варінту на цьому етапі має виглядати
приблизно так:

Рисунок 1.3 –Приклад ER-діаграми з атрибутами

14. Написати звіт.

Теми
1. Аптека. 3. Магазин електроніки.
2. Чемпіонат з 4. Ресторан.
комп’ютерної гри CS 1.6. 5. Бібліотека.
 6. Автосалон. 21. Зоопарк.
7. Спортзал. 22. Готельний комплекс.
8. Банк. 23. Туристичний клуб.
9. Чемпіонат з футболу. 24. Військовий округ.
10. Меблевий салон. 25. Магазин автозапчастин.
11. Чемпіонат з хокею. 26. Фотоцентр.
12. Архітектура ПК. 27. Залізнична
13. Університет. пасажирська станція
14. Кінотеатр. 28. Аеропорт.
15. Прем'єр ліга. 29. Спортивна організація
16. Електронний каталог. 30. Оператор мобільного
17. Автопідприємство. зв’язку.
18. Будівельна організація.
19. Бухгалтерія.
20. Театр.

Оцінювання
Оцінюватись будуть наступні фактори: своєчасність здачі та захисту
лабораторної роботи; правильність виконання завдань; відповіді на
захисті.

Посилання
Entity Relationship Diagram (ERD) Tutorial – part 1
Entity Relationship Diagram (ERD) Tutorial - part 2
UML Use Case Diagram Tutorial
Entity-Relationship Diagrams – інший погляд
Модель сутність-зв'язок, ER-діаграма
Аналіз предметної області