1.1 Вступ

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

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

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

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

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

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

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

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

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

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

1.2 Проектування бібліотеки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вебінар JavaRush