Data-Science-For-Beginners/translations/uk/2-Working-With-Data/05-relational-databases/README.md

<!--
CO_OP_TRANSLATOR_METADATA:
{
  "original_hash": "9399d7b4767e75068f95ce5c660b285c",
  "translation_date": "2025-09-05T19:53:14+00:00",
  "source_file": "2-Working-With-Data/05-relational-databases/README.md",
  "language_code": "uk"
}
-->
# Робота з даними: реляційні бази даних

|![ Скетчноут від [(@sketchthedocs)](https://sketchthedocs.dev) ](../../sketchnotes/05-RelationalData.png)|
|:---:|
| Робота з даними: реляційні бази даних - _Скетчноут від [@nitya](https://twitter.com/nitya)_ |

Можливо, ви раніше використовували електронну таблицю для зберігання інформації. У вас був набір рядків і стовпців, де рядки містили інформацію (або дані), а стовпці описували цю інформацію (іноді це називається метаданими). Реляційна база даних побудована на цьому основному принципі стовпців і рядків у таблицях, що дозволяє вам розподіляти інформацію між кількома таблицями. Це дає змогу працювати зі складнішими даними, уникати дублювання та мати гнучкість у способах дослідження даних. Давайте розглянемо концепції реляційної бази даних.

## [Тест перед лекцією](https://ff-quizzes.netlify.app/en/ds/quiz/8)

## Все починається з таблиць

У центрі реляційної бази даних знаходяться таблиці. Як і в електронній таблиці, таблиця — це набір стовпців і рядків. Рядок містить дані або інформацію, з якою ми хочемо працювати, наприклад, назву міста або кількість опадів. Стовпці описують дані, які вони зберігають.

Давайте почнемо наше дослідження, створивши таблицю для зберігання інформації про міста. Ми можемо почати з їхньої назви та країни. Ви могли б зберігати це в таблиці, як показано нижче:

| Місто    | Країна        |
| -------- | ------------- |
| Токіо    | Японія        |
| Атланта  | Сполучені Штати |
| Окленд   | Нова Зеландія |

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

## Недоліки підходу з однією таблицею

Можливо, наведена вище таблиця здається вам досить знайомою. Давайте додамо додаткові дані до нашої бази даних, що розвивається, — річну кількість опадів (у міліметрах). Ми зосередимося на роках 2018, 2019 і 2020. Якщо ми додамо дані для Токіо, це може виглядати приблизно так:

| Місто | Країна | Рік  | Кількість |
| ----- | ------- | ---- | -------- |
| Токіо | Японія  | 2020 | 1690     |
| Токіо | Японія  | 2019 | 1874     |
| Токіо | Японія  | 2018 | 1445     |

Що ви помітили в нашій таблиці? Ви могли помітити, що ми дублюємо назву та країну міста знову і знову. Це може займати досить багато місця для зберігання і здебільшого є непотрібним. Адже Токіо має лише одну назву, яка нас цікавить.

Добре, спробуймо щось інше. Додамо нові стовпці для кожного року:

| Місто    | Країна        | 2018 | 2019 | 2020 |
| -------- | ------------- | ---- | ---- | ---- |
| Токіо    | Японія        | 1445 | 1874 | 1690 |
| Атланта  | Сполучені Штати | 1779 | 1111 | 1683 |
| Окленд   | Нова Зеландія | 1386 | 942  | 1176 |

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

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

## Концепція зв’язків

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

| Місто    | Країна        |
| -------- | ------------- |
| Токіо    | Японія        |
| Атланта  | Сполучені Штати |
| Окленд   | Нова Зеландія |

Але перед тим, як створити наступну таблицю, нам потрібно зрозуміти, як посилатися на кожне місто. Нам потрібен якийсь ідентифікатор, ID або (у технічних термінах баз даних) первинний ключ. Первинний ключ — це значення, яке використовується для ідентифікації одного конкретного рядка в таблиці. Хоча це може бути засноване на самому значенні (наприклад, ми могли б використовувати назву міста), це майже завжди має бути число або інший ідентифікатор. Ми не хочемо, щоб ID змінювався, оскільки це порушить зв’язок. У більшості випадків первинний ключ або ID буде автоматично згенерованим числом.

> ✅ Первинний ключ часто скорочується як PK

### міста

| city_id | Місто    | Країна        |
| ------- | -------- | ------------- |
| 1       | Токіо    | Японія        |
| 2       | Атланта  | Сполучені Штати |
| 3       | Окленд   | Нова Зеландія |

> ✅ Ви помітите, що ми використовуємо терміни "id" і "первинний ключ" взаємозамінно протягом цього уроку. Ці концепції також застосовуються до DataFrames, які ви досліджуватимете пізніше. DataFrames не використовують термінологію "первинний ключ", однак ви помітите, що вони поводяться дуже схоже.

Створивши таблицю міст, давайте збережемо дані про опади. Замість дублювання повної інформації про місто ми можемо використовувати ID. Ми також повинні переконатися, що новостворена таблиця має стовпець *id*, оскільки всі таблиці повинні мати ID або первинний ключ.

### опади

| rainfall_id | city_id | Рік  | Кількість |
| ----------- | ------- | ---- | -------- |
| 1           | 1       | 2018 | 1445     |
| 2           | 1       | 2019 | 1874     |
| 3           | 1       | 2020 | 1690     |
| 4           | 2       | 2018 | 1779     |
| 5           | 2       | 2019 | 1111     |
| 6           | 2       | 2020 | 1683     |
| 7           | 3       | 2018 | 1386     |
| 8           | 3       | 2019 | 942      |
| 9           | 3       | 2020 | 1176     |

Зверніть увагу на стовпець **city_id** у новоствореній таблиці **опади**. Цей стовпець містить значення, які посилаються на ID у таблиці **міста**. У технічних термінах реляційних даних це називається **зовнішнім ключем**; це первинний ключ з іншої таблиці. Ви можете просто думати про це як про посилання або вказівник. **city_id** 1 посилається на Токіо.

> [!NOTE] Зовнішній ключ часто скорочується як FK

## Отримання даних

Розділивши наші дані на дві таблиці, ви можете запитати, як їх отримати. Якщо ми використовуємо реляційну базу даних, таку як MySQL, SQL Server або Oracle, ми можемо використовувати мову під назвою Structured Query Language або SQL. SQL (іноді вимовляється як "сіквел") — це стандартна мова, яка використовується для отримання та модифікації даних у реляційній базі даних.

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

```sql
SELECT city
FROM cities;

-- Output:
-- Tokyo
-- Atlanta
-- Auckland
```

`SELECT` — це місце, де ви вказуєте стовпці, а `FROM` — де ви вказуєте таблиці.

> [NOTE] Синтаксис SQL нечутливий до регістру, тобто `select` і `SELECT` означають одне й те ж. Однак, залежно від типу бази даних, яку ви використовуєте, стовпці та таблиці можуть бути чутливими до регістру. Тому найкращою практикою є завжди ставитися до всього в програмуванні так, ніби це чутливе до регістру. Під час написання SQL-запитів загальноприйнято писати ключові слова великими літерами.

Запит вище відобразить усі міста. Уявімо, що ми хочемо відобразити лише міста в Новій Зеландії. Нам потрібен якийсь фільтр. Ключове слово SQL для цього — `WHERE`, або "де щось є істинним".

```sql
SELECT city
FROM cities
WHERE country = 'New Zealand';

-- Output:
-- Auckland
```

## Об’єднання даних

До цього моменту ми отримували дані з однієї таблиці. Тепер ми хочемо об’єднати дані з таблиць **міста** та **опади**. Це робиться шляхом *об’єднання* їх разом. Ви фактично створите зв’язок між двома таблицями та зіставите значення зі стовпця кожної таблиці.

У нашому прикладі ми зіставимо стовпець **city_id** у таблиці **опади** зі стовпцем **city_id** у таблиці **міста**. Це дозволить зіставити значення опадів із відповідним містом. Тип об’єднання, який ми виконаємо, називається *внутрішнім* об’єднанням, тобто якщо будь-які рядки не відповідають жодному з іншої таблиці, вони не будуть відображені. У нашому випадку кожне місто має дані про опади, тому все буде відображено.

Давайте отримаємо дані про опади за 2019 рік для всіх наших міст.

Ми зробимо це поетапно. Перший крок — об’єднати дані, вказавши стовпці для зв’язку — **city_id**, як зазначено раніше.

```sql
SELECT cities.city
    rainfall.amount
FROM cities
    INNER JOIN rainfall ON cities.city_id = rainfall.city_id
```

Ми виділили два стовпці, які нам потрібні, і факт, що ми хочемо об’єднати таблиці за **city_id**. Тепер ми можемо додати оператор `WHERE`, щоб відфільтрувати лише рік 2019.

```sql
SELECT cities.city
    rainfall.amount
FROM cities
    INNER JOIN rainfall ON cities.city_id = rainfall.city_id
WHERE rainfall.year = 2019

-- Output

-- city     | amount
-- -------- | ------
-- Tokyo    | 1874
-- Atlanta  | 1111
-- Auckland |  942
```

## Підсумок

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

## 🚀 Виклик

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

## Тест після лекції

## [Тест після лекції](https://ff-quizzes.netlify.app/en/ds/quiz/9)

## Огляд і самостійне навчання

На [Microsoft Learn](https://docs.microsoft.com/learn?WT.mc_id=academic-77958-bethanycheum) доступно кілька ресурсів, щоб продовжити ваше дослідження SQL і концепцій реляційних баз даних:

- [Опис концепцій реляційних даних](https://docs.microsoft.com//learn/modules/describe-concepts-of-relational-data?WT.mc_id=academic-77958-bethanycheum)
- [Початок роботи з запитами в Transact-SQL](https://docs.microsoft.com//learn/paths/get-started-querying-with-transact-sql?WT.mc_id=academic-77958-bethanycheum) (Transact-SQL — це версія SQL)
- [Контент SQL на Microsoft Learn](https://docs.microsoft.com/learn/browse/?products=azure-sql-database%2Csql-server&expanded=azure&WT.mc_id=academic-77958-bethanycheum)

## Завдання

[Назва завдання](assignment.md)

---

**Відмова від відповідальності**:  
Цей документ був перекладений за допомогою сервісу автоматичного перекладу [Co-op Translator](https://github.com/Azure/co-op-translator). Хоча ми прагнемо до точності, будь ласка, майте на увазі, що автоматичні переклади можуть містити помилки або неточності. Оригінальний документ на його рідній мові слід вважати авторитетним джерелом. Для критичної інформації рекомендується професійний людський переклад. Ми не несемо відповідальності за будь-які непорозуміння або неправильні тлумачення, що виникають внаслідок використання цього перекладу.