Реляційні бази даних для чайників
Як правило, будь-який веб додаток можна розділити на 2 основні частини: фронт-енд, де відображається вся інформація сайту, і бек-енд, де дана інформація формується і розміщується. У цій статті ми поговоримо про те, що таке реляційні бази даних, і як їх проектувати.
База даних зберігає записи в спеціально організованому вигляді, щоб інформацію можна було легко знайти і витягти. Будь-яка БД складається з однієї або декількох таблиць. Електронна таблиця складається з рядків і стовпців. Всі рядки мають однакові стовпці, а кожен стовпець містить дані. Загалом, для кращого розуміння, визначимося, що таблиці в БД дуже схожі на ті, що ви бачили в Excel-е.
Табличні дані можуть бути вставлені, відновлені, оновлені і видалені. Для пакета цих операцій була створена спеціальна абревіатура CRUD (Create-Read-Update-Delete).
Реляційні бази даних - це бази, де вся інформація зберігається в таблицях, пов'язаних один з одним спеціальними відносинами. Ці відносини дозволяють нам отримувати і об'єднувати дані з однієї або декількох таблиць за допомогою одного запиту.
Але все це всього лише слова. Для того щоб дійсно зрозуміти, що таке реляційні бази даних, вам потрібно більше практикуватися. Давайте ж почнемо і подивимося, з якими даними ми маємо працювати.
Крок 1. Підготовка даних
Для того щоб нам було з чим працювати, я набрав в твіттері запит "#databases" і сформував таблицю з 10 записів:
What do you think about #emailing #campaigns #traffic in #USA? Is it a good market nowadays? do you have #databases?
RT @tisakovich: @NimbusData at the @Barclays Big Data conference in San Francisco today, talking #virtualization, #databases, and #flash memory.
В першу чергу, давайте розберемося з колонками:
- full_name: ім'я користувача
- username: логін в Twitter-е
- text: текст твіти
- created_at: час створення твіти
- following_username: список користувачів, розділених комами, які підписалися на цей твітти. Для стислості я скоротив цей список до 2 імен.
Це реальні дані. Якщо хочете, ви можете їх знайти і оновити.
Добре. Тепер всі наші дані знаходяться в одному місці. Чи дає це нам можливість легко здійснити пошук по ним? Не зовсім. Дана таблиця далека від ідеалу. По-перше, в деяких шпальтах у нас є повторювані записи: наприклад, в х "username" і "following_username". Також колонка "following_username" порушує правила реляційних моделей, тому що її в осередках присутні більше 1 значення (записи розділені комами).
До того ж у нас трапляються дублікати і в рядках.
Повторювані дані дійсно є проблемою, тому що вони ускладнюють процес CRUD. Наприклад, при пошуку по даній таблиці на обробку дублікатів буде йти додатковий час. До того ж, якщо користувач оновить твітти, то нам потрібно буде перезаписати всі дублікати.
Рішення даної проблеми полягає в поділі Таблиці 1 на кілька таблиць. Давайте візьмемося за рішення першої проблеми, а саме - усунення дублікатів в шпальтах.
Крок 2. Позбавляємося від дублікатів в шпальтах
Як було зазначено вище, стовпці "username" і "following_username" містять дублікати даних. Вони виникли в результаті того, що я хотів відобразити відносини між твітти і користувачами. Давайте покращимо нашу структуру БД, розділивши існуючу таблицю на дві: в одній будемо зберігати інформацію, а в іншій - відносини між записами.
Оскільки @Brett_Englebert підписаний на @RealSkipBayless, то в таблиці "following" відобразимо це наступним чином: ім'я @Brett_Englebert помістимо в колонку "from_user", а @RealSkipBayless в "to_user." Давайте подивимося, як буде виглядати таблиця "following" після поділу Таблиці 1:
Таблиця 2. following
Після поділу в таблиці 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
Отже, до цього моменту ми вже багато чого зробили. Позбулися дублюючої інформації в колонках і рядках і вибрали для наших таблиць відповідні колонки на роль первинних і зовнішніх ключів для позначення залежностей між даними. Даний процес називається нормалізацією і призначений для приведення ваших таблиць під реляційну модель. Завдяки нормалізації ми можемо більш простим чином реалізовувати операції CRUD.
Нижче ви можете побачити схему наших таблиць і зв'язків між ними:
Системи Управління Базами Даних
Тепер, коли у нас є реляційна БД, яким чином ми можемо її імплементувати? Для цього ми можемо скористатися системами управління базами даних (СКБД). Існує цілий набір подібних програм, як платних, так і безкоштовних. Серед платних можна виділити Oracle Database. IBM DB2 і Microsoft SQL Server. Безкоштовні: MySQL. SQLite і PostgreSQL.
Найчастіше різні компанії використовують MySQL. Twitter в цьому сенсі - не виняток.
PostgreSQL використовується рідше. Для неї існує корисне розширення PostGIS, яке робить цю СУБД зручною для зберігання геолокаційні даних. Наприклад сервіс OpenStreetMap исользуются PostgreSQL.
Мова структурованих запитів (SQL)
Після того, як ви вибрали відповідну для вас СУБД і встановили її, наступним кроком було б створення таблиць і управління даними. Для цього ми можемо скористатися спеціальним мовою SQL.
Створення БД development:
Створення таблиці Users:
При створенні полів нам необхідно вказати тип інформації, що зберігається і її розмір. Колонки "full_name" і "username" будуть типу VARCHAR, який призначений для зберігання рядків символів. Розмір 100 символів. Список всіх типів ви можете знайти тут.
Витяг всіх записів користувача _DreamLead:
За рахунок отримання інформації відразу по двох каналах (зір і слух) ефективність навчання значно перевершує навчання по книгах. А домашні завдання і онлайн-тести дозволять вам постійно думати на мові, що вивчається і відразу перевіряти свої знання!
Якщо ви давно хочете як слід вивчити HTML, то у мене для Вас є чудова новина!
Якщо ви вже вивчили HTML і хочете рухатися далі, то наступним кроком буде вивчення технології CSS.
Якщо ви хочете розібратися з поняттями домену і хостингу, навчитися створювати бази даних, закачувати файли сайту на сервер по FTP, створювати піддомени, налаштовувати поштові скриньки для свого сайту і стежити за його відвідуваністю, то цей курс створений спеціально для вас!