Основні завдання під час проектування баз даних

1. Вступ

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

Ось які завдання зазвичай стоять перед розробником під час проєктування бази даних:

1. Забезпечення зберігання до БД всієї необхідної інформації.
2. Забезпечення можливості отримання даних за всіма необхідними запитами.
3. Скорочення надмірності та дублювання даних.
4. Забезпечення цілісності бази даних
5. Оптимізація швидкості доступу до даних

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

1. Структура має бути досить гарною.
2. У всьому має бути логіка, зрозуміла іншим людям.
3. Завчасна оптимізація — корінь усіх проблем.

Не потрібно робити найкращу у світі структуру бази даних. Вона все одно змінюватиметься. Твоє завдання — стежити за тим, щоб після 20 змін структури твоєї бази в ній було досить просто розібратися.

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

Не оптимізуй базу даних, поки це не потрібно. Якщо в таблиці всього кілька сотень рядків, то швидше за все СУБД триматиме її в пам'яті і кешуватиме запити до неї.

З іншого боку, ти маєш вміти прискорити роботу важливих запитів у десятки, а то й сотні разів. І добре тобі знати, як це робиться. Як там кажуть у виші на першому курсі? «Забудьте все, чому вас навчали у школі…»

Якщо ти знаєш, що таке нормалізація баз даних, то поспішу тебе порадувати: у своїй роботі ти швидше за все займатимешся денормалізацією. Для замовників проєкту немає нічого важливішого за швидкість роботи бази даних. І якщо для того, щоб прискорити вибірку даних з бази, потрібно об'єднати 200(!) таблиць в одну (з жахливою надмірністю), тобі доведеться це зробити.

2. Проєктування бібліотеки

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

Основне завдання будь-якої бібліотеки — обробка книжкового фонду. Неважко виділити три основні групи користувачів системи: читач, бібліотекар, адміністратор. Діяльність кожного з них показана на діаграмі варіантів використання.

Вже зараз можна виділити деякі сутності та відносини майбутньої бази даних:

При такому підході не зрозуміло, як саме зв'язати читача з книгою (у читача не проставлена арність щодо «видача/прийом». Якщо книга має кілька екземплярів, її можна видати декільком читачам. Навіть якщо під книгою розуміти один екземпляр, під час збереження в таблиці книг поточного читача призведе до неможливості отримання інформації про те, хто (і скільки разів) брав цю книгу раніше.

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

При бронюванні літератури читачем також заводиться картка, якщо заброньована література не взята читачем у визначений термін — картка знищується. Існує обмеження кількості книг, які може забронювати читач.

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

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

Можна виділити такі основні сутності предметної області:

• користувач (бібліотекарі та адміністратори);
• читач;
• читальний зал;
• книга;
• картка видачі книги;
• картка бронювання книги.

Допрацьована ER-діаграма бази даних наведена на малюнку.

Відповідно до прецедентів, показаних на малюнку 1, база даних повинна реалізовувати наступні запити (не повний перелік):

• відобразити книги, що відповідають зазначеним умовам;
• відобразити користувачів, які мають незакриті вчасно картки видачі книг (бібліотекар шукає боржників);
• відобразити всі книги, що відповідають незакритим вчасно карткам видачі книг вказаного користувача (користувач прийшов до бібліотеки за новими книгами — треба подивитися, чи є він боржником і повідомити його про це);
• видалити всі картки бронювання, створені більш ніж N секунд тому;
• відобразити всі книги, що відповідають незакритим карткам бронювання книг вказаного користувача (читач замовив книги та прийшов до бібліотеки за ними — бібліотекарю треба отримати цей список, щоб видати).

3. Формування схеми даних

Для формування схеми даних необхідно спочатку доповнити ER-діаграму реквізитами сутностей (уточнити її). Іноді, водночас, вдається знайти помилки побудови ER-діаграми — у цьому завданні було виявлено, що книгу необхідно «якось» пов'язати із залом бібліотеки.

Зробити це можна, якщо помістити в книгу реквізит «номер залу», проте за такого підходу одну й ту саму книгу доведеться описувати в базі кілька разів (якщо вона зустрічається у різних залах). Більш правильний підхід полягає у запровадження додаткової сутності «розміщення книги». На малюнку показана ER-діаграма з доданою сутністю та реквізитами.

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

При цьому на наступній схемі:

• для зв'язків використовується нотація Мартіна («воронячі лапки»);
• таблиці зображені прямокутниками, розділеними на 3 секції:

• ім'я таблиці;
• внутрішні ключі (позначаються маркером);
• Інші поля, при цьому обов'язкові позначаються маркером.

Під час розробки цієї моделі виникало бажання об'єднати таблицю адміністраторів з таблицею бібліотекарів — додати таблицю users, проте:

• адміністратор не пов'язаний із конкретним залом (довелося б заповнювати відповідне поле null-значеннями);
• ймовірно, це ускладнило б розподіл прав доступу: зараз доступ до таблиці administrators має лише адміністратор бази даних (працюючий через спеціальну панель СУБД і не має облікового запису в системі, що розробляється). Однак при з'єднанні таблиць запити користувача вимагали б доступу до нової таблиці.

При побудові цієї діаграми було знайдено та виправлено недолік ER-діаграми — додано таблицю librarians_rooms, що об'єднує бібліотекарів та зали. Це потрібно, оскільки один бібліотекар може працювати в кількох залах, але кілька бібліотекарів можуть працювати в тому самому залі.

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

---

Проєктування баз даних