Сьогодні поговоримо про реляційні бази даних. Розпочнемо з основ для тих, хто тільки починає вивчати БД.
Реляційні бази даних відображають інформацію у вигляді таблиць. Саме тих таблиць, які схожі на ексель: з колонками, рядками. Таблиці можуть бути пов’язані між собою ключами.
Уявіть, що у вас є невеликий магазин взуття.
Все йде гаразд, магазинчик процвітає, продажі йдуть. Неважливо як, вам потрібно мати записи про кількість взуття, деякі витрати та інші дрібниці. Припустимо, ви зберігаєте записи у своєму зошиті в найпростішому вигляді: Чоловічі кросівки, розмір 42, 3 пари, ціна 100 $.
Коли ви найняли ще одного продавця, окрім вас, інша людина почала писати в зошиті. Щоб навчити його єдиному стилю, ви вирішили зробити в зошиті колонки: Найменування, Розмір, Ціна, Кількість на складі. Вам це здалося дуже зручним. Тепер легше вести облік взуття, продавцям зручно вести записи, і всі щасливі.
Ваш бізнес почав рости і вдалось відкрити ще одне відділення в іншому кінці міста.
Тепер, щоб переглянути, як йдуть справи в магазинах, потрібно їздити одразу в два відділення, брати зошит і порівнювати цифри. Розумієте, про що йдеться?
Стає зрозуміло, що мати централізоване сховище записів про кросівки було б набагато зручніше. Якби ще можна було отримувати дані, не виходячи з дому, в зручному форматі, з графіками продажів та цін – було б просто чудово.
На думку відразу спадають гугл таблиці. Чому б не створити таблицю гугл, дати доступ до неї всім продавцям і відповідальним за записи людям і мати єдине центральне середовище даних?
Можна й так. Однак дані з часом будуть розростатись. Настане момент, коли таблиця буде настільки великою, що її завантаження буде ускладнене. Більше того, що якщо певні продавці внесуть помилкові дані чи взагалі хтось видалить записи з необережності?
Треба побудувати якийсь інтерфейс, де продавці будуть мати доступ тільки для додавання даних про кількість кросівок, а ви як менеджер зможете додавати дані про нові товари і виставляти ціни. Ви створюєте додаток (може навіть на Java), який буде слугувати вам системою ведення обліку товарів вашого магазину. Однак де зберігати дані?
На допомогу приходять реляційні бази даних. По суті, це той самий зошит, але цифровий. Оскільки мова йде про реляційні бази даних, я далі буду просто вживати термін “бази даних” без вказівки на тип.
Як уже було сказано вище, бази даних зберігають інформацію у таблицях. У таблицях є стовпці, в стовпцях – інформація. Для маніпулювання даними була придумана єдина мова SQL, яка дозволяє робити з даними все, що завгодно. Погодьтесь, дуже зручно, коли весь світ користується єдиним стандартом і всі розуміють, про що йдеться. Різні компанії створили системи управління базами даних: програмне забезпечення для роботи з базами даних. Є як платні, так і безкоштовні СУБД:
- Oracle
- MySql
- PostgreSQL
Цих систем дуже багато, і перераховувати їх нема сенсу. Вам потрібно лише знати SQL – Structured query language (мова структурованих запитів), і ви зможете працювати з будь-якою СУБД.
Перейдемо до нашого магазину.
Ви вирішили перенести дані з зошита в єдине сховище. Але не поспішайте вмикати комп’ютер! Спочатку просто потрібно уявити, в якому вигляді буде зберігатися інформація:
- які стовпці будуть у таблиці
- в якому форматі будуть представлені дані (текст, числа, зображення)
- відношення між таблицями
Кожного разу, коли вам знадобиться створити базу даних, її потрібно спроектувати. Це схоже на будівництво будинку. Неможливо почати будівництво без плану. Для проектування баз даних існує безліч інструментів та сервісів. Але найпростіший і швидкий для розуміння: ручка та папір.
Беремо папір і малюємо таблицю. Додаємо до неї стовпці.
Вийшло пристойно. Не поспішайте переносити все на комп’ютер. Бази даних це як фундамент будинку – його потрібно закласти один раз і краще не переробляти. Ви потім зрозумієте, що зміни архітектури бази даних спричиняють серйозні наслідки для додатку.
А що як нам потрібно буде знати більше інформації про постачальника? Ім’я, адреса, номер телефону. Адже нам треба буде замовляти ще взуття, коли розкуплять те, що на складі.
Пропоную винести постачальника в окрему таблицю. Тепер ви запитаєте, як ми знатимемо якого постачальника має кожне взуття? Для цього ми домовимось, що ім’я постачальника в таблиці взуття збігатиметься з колонкою “Назва” в таблиці постачальник.
Приклад вище – реляційна модель бази даних. Коли ми побудували реляційну модель, йде процес, який називається нормалізація. Після цього, модель перетворюють на SQL скрипти і переносять на певну СУБД. А далі вже займаються вставкою і вибіркою даних. Однак це вже зовсім інша історія яка виходить за рамки даного матеріалу 😉
Це все, що стосується теми реляційні бази даних. Реляційні бази даних – основа майже будь якого веб додатку. Тому їх розуміння і основи SQL необхідні кожному, хто планує програмувати web на Java.
Залишити відповідь