Реляційні бази даних для чайників

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

База даних зберігає записи у спеціально організованому вигляді, щоб інформацію можна було легко знайти та отримати. Будь-яка БД складається з однієї чи кількох таблиць. Електронна таблиця складається з рядків та стовпців. Всі рядки мають стовпці, а кожен стовпець містить дані. Загалом, для кращого розуміння, визначимося, що таблиці БД дуже схожі на ті, що ви бачили в Excel-і.

Fig. 1

Табличні дані можуть бути вставлені, відновлені, оновлені та видалені. Для пакету цих операцій було створено спеціальну абревіатуру CRUD (Create-Read-Update-Delete).

Реляційні бази даних - це бази, де вся інформація зберігається в таблицях, пов'язаних один з одним спеціальними відносинами. Ці відносини дозволяють нам отримувати та об'єднувати дані з однієї або декількох таблиць за допомогою одного запиту.

Але все це лише слова. Для того, щоб дійсно зрозуміти, що таке реляційні бази даних, вам потрібно більше практикуватися. Давайте почнемо і подивимося, з якими даними нам доведеться працювати.

Крок 1: Підготовка даних

Для того, щоб нам було з чим працювати, я набрав у твіттері запит "#databases" і сформував таблицю з 10 записів:

Таблиця 1

Насамперед, давайте розберемося з колонками:

full_name : ім'я користувача
username : логін у Twitter-і
text : текст твіту
created_at : час створення твіту
following_username :список користувачів, розділених комами, які підписалися на цей твіт. Для стислості я скоротив цей список до 2 імен

Це справжні дані. Якщо хочете, ви можете їх знайти та оновити.

Добре. Тепер усі наші дані знаходяться в одному місці. Чи дає нам можливість легко здійснити пошук по них? Не зовсім. Ця таблиця далека від ідеалу. По-перше, в деяких стовпцях у нас є записи, що повторюються: наприклад, в х "username" і "following_username". Також стовпчик “following_username” порушує правила реляційних моделей, т.к. її в осередках присутня більше 1 значення (записи розділені комами).

До того ж, у нас трапляються дублікати і в рядках.

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

Розв'язання цієї проблеми полягає у розділенніТаблиці 1 на кілька таблиць. Давайте візьмемося за вирішення першої проблеми, а саме – усунення дублікатів у стовпцях.

Крок 2: Позбавляємося дублікатів у стовпцях

Як було зазначено вище, стовпці "username" і "following_username" містять дублікати даних. Вони виникли внаслідок того, що я хотів відобразити стосунки між твіттами та користувачами. Давайте покращимо нашу структуру БД, розділивши існуючу таблицю на дві: в одній зберігатимемо інформацію, а в іншій - відносини між записами.

Fig. 2

Оскільки @Brett_Englebert підписаний на @RealSkipBayless, то таблиці “following” відобразимо це так: ім'я @Brett_Englebert помістимо в колонку “from_user”, а @RealSkipBayless в"to_user." Давайте подивимося, як виглядатиме таблиця “following” після поділуТаблиці 1 :

Таблиця 2: following

Таблиця 3: users

Вже краще. Тепер у таблиці “users” (Таблиця 3 ) у нас зберігається лише інформація про твітти, а в таблиці following (Таблиця 2 ) - залежність користувачів.

Засновник теорії реляційних баз даних, Едгар Кодд, назвав би цей процес (видалення повторень зі стовпців таблиць) приведенням БД до першої нормальної форми.

Крок 3: Видалення повторень із рядків

Тепер ми займемося усуненням інших проблем, а саме, позбавимося дублікатів у рядках таблиці “users”. Оскільки користувачі @AndyRyder5 та @Brett_Englebert розмістили по кілька твіттів, їх імена в таблиці “users” (Таблиця 3 ) дублюються в колонці full_name. Ця проблема також вирішується поділом таблиці “users”.

Fig. 3

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

Таблиця 4: tweets

Таблиця 5: users

Після поділу в таблиці users (Таблиця 5 ) у нас є унікальні (не повторювані) рядки.

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

Крок 4: Об'єднуємо таблиці на основі ключів

Отже, внаслідок наших дій,Таблиця 1 була розбита на 3 частини: following (Таблиця 2 ), tweets (Таблиця 4 ), users (Таблиця 5 ). Усі дублікати усунуті. Для того, щоб надалі ми могли з легкістю отримувати дані з цієї структури, незалежні один віддруга таблиці ми повинні пов'язати спеціальними відносинами, які будуть давати нам інформацію про те, якому користувачеві належить якийсь твіт, і хто на кого підписаний.

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

Взагалі кажучи, у Таблиці 4 та 5 ми вже це зробили. У таблиці "users" первинним ключем є колонка "username", тому що логін користувача має бути унікальним значенням і не може повторюватися. У таблиці “tweets” ми використовуємо цей ключ для позначення зв'язку між користувачем та твітом. Колонка “username” у таблиці “tweets” називається зовнішнім ключем.

Якщо ви колись працювали з базами даних, то може виникнути питання: чи можемо ми використовувати колонку “username” як первинний ключ?

З одного боку, це може спростити процес пошуку, адже ми не використовуємо жодних цифрових ID. З іншого боку, якщо користувач захоче поміняти свій логін? Це може призвести до величезної кількості проблем. Для того, щоб не потрапити в подібну ситуацію, краще скористатися числовими ID. Все залежить від вашої системи. Якщо ви надаєте вашим користувачам можливість змінювати логіни, то краще як первинний ключ використовувати автоінкрементоване числове поле ID. В іншому випадку, колонка "username" цілком підійде для цієї ролі. Я залишу все як є.

Таблиця 6: tweets з колонкою id