Напередодні старту чергового потоку за курсом підготували невеликий авторський матеріал із важливими порадами щодо конструювання БД. Сподіваємось цей матеріал буде корисний для вас.
Бази даних всюди: від найпростіших блогів та директорій до надійних інформаційних систем та великих соціальних мереж. Не настільки важливо, проста чи складна база даних, наскільки суттєво спроектувати її правильно. Коли база спроектована бездумно і без чіткого розуміння мети, вона не просто не ефективна, а й подальша робота з базою буде реальною мукою, непрохідним лісом для користувачів. Ось кілька порад щодо конструювання бази даних, які допоможуть створити корисний та простий у використанні продукт.
1. Визначте, для чого таблиця та яка її структура
Сьогодні такі методи розробки, як Scrum або RAD (швидка розробка програми), допомагають ІТ-команд швидко розробляти бази даних. Однак, у гонитві за часом дуже велика спокуса поринути відразу в побудову бази, неясно уявляючи, в чому ж сама мета, які мають бути кінцеві результати.
Наче команда націлена на ефективну, швидкісну роботу, але це міраж. Чим далі і швидше занурюватися вглиб проекту, тим більше буде потрібно часу, щоб виявити та змінити помилки у проекті бази.
Тому перше, що потрібно вирішити, — визначити ціль для вашої бази даних. Якого типу програми розробляється база? Користувач лише працюватиме із записами і потрібно приділити увагу транзакціям або його більше цікавить аналітика даних? Де база має бути розгорнута? Чи буде вона відстежувати поведінку клієнтів чи просто управляти відносинами між ними?
Чим раніше команда проектування відповість на ці питання, тим м'якше, плавніше пройде процес проектування бази даних.
2. Які дані вибрати для зберігання?
Плануйте наперед. Думки про те, що в майбутньому робитиме сайт чи система, для яких проектується база даних. Важливо виходити за межі простих вимог технічного завдання. Тільки будь ласка, не починайте розмірковувати відразу про всі можливі типи даних, які будь-коли зберігатиме користувач. Краще подумайте про те, чи зможуть користувачі писати пости, завантажувати документи чи фотографії чи обмінюватися повідомленнями. Якщо це так, то в основі необхідно виділити місце під них.
Працюйте з командою, департаментом чи організацією, для яких у майбутньому підтримуватиметься база, що проектується. Спілкуйтеся з людьми різних рівнів, від фахівців роботи з клієнтами до керівників відділів. Так, за допомогою зворотного зв'язку ви отримаєте чітке уявлення про вимоги компанії.
Неминуче потреби користувачів у рамках навіть одного департаменту будуть конфліктувати. Якщо ви зіткнетеся з цим, не бійтеся спертися на власний досвід і знайти компроміс, який влаштує всі сторони і задовольнятиме кінцеву мету БД. Будьте впевнені: у майбутньому вам прилетить +100500 у карму та гора печінок.
3. Моделюйте дані з обережністю
Є кілька ключових моментів, на які варто звернути увагу під час моделювання даних. Як ми вже говорили, від призначення бази даних залежить, які методи використовувати при моделюванні. Якщо ми проектуємо базу даних для оперативної обробки записів (OLTP), тобто для їх створення, редагування та видалення, то використовуємо моделювання транзакцій. Якщо ж база даних має бути реляційною, то найкраще застосовувати багатовимірне моделювання.
Під час моделювання будуються концептуальні (CDM), фізичні (PDM) та логічні (LDM) моделі даних.
Концептуальні моделі описують сутності та типи даних, які вони включають, а також відносини між ними. Ділить ваші дані на логічні шматки - так набагато простіше жити.
Головне — міра, не перестарайтеся.
Якщо сутність дуже складно класифікувати одним словом чи фразою, настав час використовувати підтипи (дочірні сутності).
Якщо ж сутність веде власне життя, має атрибути, які описують її поведінку та її вигляд, а також відносини з іншими об'єктами, то сміливо можна використовувати не лише підтип, а й супертип (батьківська сутність).
Якщо знехтувати цим правилом, інші розробники заплутаються у вашій моделі і не до кінця розумітимуть дані та правила, як їх збирати.
Реалізуються концептуальні моделі за допомогою логічних. Ці моделі як дорожня карта для проектування фізичної бази даних. У логічній моделі виділяються сутності бізнес-даних, визначаються типи даних, статус ключа правила, що регулюють відносини між даними.
Потім Логічна модель даних зіставляється з заздалегідь обраною платформою СУБД (системи управління базами даних) і виходить Фізична модель. Вона визначає спосіб фізичного зберігання даних.
4. Використовуйте відповідні типи даних
Застосування неправильного типу даних може призвести до менш точних даних, труднощів у поєднанні таблиць, синхронізації атрибутів та роздмухуванні розмірів файлів.
Щоб гарантувати цілісність інформації, атрибут повинен містити лише прийнятні для нього типи даних. Якщо в базу даних вноситься вік, то переконайтеся, що в колонці зберігаються цілі числа максимум 3 цифр.
Створюйте мінімум порожніх стовпців із значенням NULL. Якщо ви створюєте всі стовпці, як NULL, це груба помилка. Якщо ж вам потрібен порожній стовпець для виконання конкретної бізнес-функції, коли дані невідомі або ще не мають сенсу, сміливо створюйте. Адже ми не можемо заздалегідь заповнити стовпці "Дата смерті" або "Дата звільнення", ми ж не провісники тикати пальцем у небо :-).
Більшість софту для моделювання (ER/Studio, MySQL Workbench, SQL DBM, gliffy.com) даних дозволяє створювати прототипи областей даних. Так гарантується не тільки правильний тип даних, логіка програми та хороша продуктивність, але також і обов'язкове завдання значення.
5. Вважайте за краще природне
Коли ви вирішуєте, який стовпець у таблиці вибрати ключем, завжди звертайте увагу, які поля може редагувати користувач. Ніколи не вибирайте їх як ключ — погана ідея. Відбутися може все, що завгодно, а ви повинні гарантувати унікальність.
Найкраще використовувати природний, чи бізнес, ключ (natural key). Він має смислове значення, так ви уникнете дублювання в базі даних.
Якщо тільки бізнес-ключ не є унікальним (ім'я, прізвище, посада) і повторюється в різних рядках таблиці або він повинен змінюватися, то первинним ключем варто призначити згенерований штучний, сурогатний ключ (artificial key).
6. Нормалізуйте в міру
Щоб ефективно організувати дані в БД, необхідно дотримуватися набору рекомендацій та нормалізувати базу даних. Існує п'ять нормальних форм, які слід слідувати.
За допомогою нормалізації ви уникнете надмірності та забезпечите цілісність даних, що використовуються в додатку або на сайті.
Як завжди, все має бути в міру навіть нормалізації. Якщо у БД занадто багато таблиць з однаковими унікальними ключами, то ви захопилися та надмірно нормалізували базу даних. Надмірна нормалізація негативно впливає на продуктивність бази даних.
7. Тестуйте раніше, тестуйте частіше
Тестовий план та належне тестування мають бути частиною проектування бази даних.
Найкраще тестувати базу даних шляхом Continuous Integration (безперервної інтеграції). Моделюйте сценарій “Один день із життя бази даних” та перевіряйте, чи всі граничні випадки обробляються, які взаємодії користувачів можливі. Чим раніше ви знайдете баги, тим більше заощадите часу і грошей.
Це лише сім порад, за допомогою яких ви можете спроектувати відмінну базу даних щодо продуктивності та ефективності. Якщо слідуватимете їм, ви уникнете більшості головного болю в майбутньому. Ці поради — лише верхівка айсберга в моделюванні бази даних. Існує безліч лайфхаків. Якими ви користуєтеся?
Джерело: habr.com