Базы данных и SQL с нуля: от основ к PostgreSQL. Урок 1/9: Что такое реляционная БД: таблицы, строки, столбцы и первичный ключ

Что мы будем делать с базами данных и зачем это нужно

Представь, что ты ведешь список контактов в телефоне. Записал имя, номер, email. А через год у тебя 500 контактов, и ты хочешь найти всех, кто живет в Москве. Или посчитать, сколько друзей добавили за последний месяц. Вручную это делать больно. База данных (БД) решает такие задачи. Она хранит информацию и умеет быстро её искать, сортировать и связывать. Реляционные базы - самый популярный тип. В них данные лежат в таблицах, как в Excel, только гораздо мощнее. На этом уроке мы разберемся, из чего состоит такая таблица и что такое первичный ключ.

Таблицы, строки и столбцы - основа всего

Реляционная база данных - это набор связанных таблиц. Каждая таблица хранит информацию об одном типе объектов. Например, таблица users для пользователей, таблица orders для заказов.

Взгляни на простую таблицу users:

| id | first_name | last_name | email |
|----|------------|-----------|---------------------|
| 1 | Иван | Петров | ivan@example.com |
| 2 | Мария | Сидорова | maria@example.com |
| 3 | Петр | Иванов | petr@example.com |

Что тут есть:

• Столбцы (колонки) - это поля с определенным типом данных. id - число, first_name - текст, email - тоже текст. Ты заранее решаешь, что будет храниться в колонке: число, строка, дата и т.д.
• Строки (записи) - это один объект. В первой строке - данные пользователя Иван Петров, во второй - Мария Сидорова.
• Таблица - это и есть набор строк с одинаковым набором столбцов.

Главное правило: в одной ячейке (на пересечении строки и столбца) хранится только одно значение. Никаких списков через запятую. Если у пользователя несколько телефонов - заводим отдельную таблицу phones.

Первичный ключ - почему без него никуда

Посмотри на таблицу выше. Как гарантировать, что строки не перепутаются? Что если добавить второго пользователя с именем Иван Петров? Нужен уникальный идентификатор каждой записи. Это и есть первичный ключ (primary key, PK).

Первичный ключ - это столбец (или несколько столбцов), который уникально определяет каждую строку.

Требования к PK:

1. Значение не может повторяться в таблице.
2. Значение не может быть пустым (NULL).
3. Лучше, чтобы он был неизменяемым (не менялся со временем).

В таблице users роль PK играет столбец id. У каждого пользователя свой номер. Даже если два Ивана Петрова - у них будут разные id: 1 и 99. База данных сама следит, чтобы ты не вставил дубликат.

Как это выглядит в SQL (языке запросов к базе)? Создадим таблицу с первичным ключом:

CREATE TABLE users (
 id SERIAL PRIMARY KEY,
 first_name VARCHAR(50) NOT NULL,
 last_name VARCHAR(50) NOT NULL,
 email VARCHAR(100) UNIQUE NOT NULL
);

Разберем команду:

• id SERIAL PRIMARY KEY - создаем колонку id, которая автоматически увеличивается (1, 2, 3...) и назначаем её первичным ключом.
• VARCHAR(50) - строковый тип длиной до 50 символов.
• NOT NULL - запрещаем пустые значения.
• UNIQUE - гарантируем, что email не повторится.

Без первичного ключа нельзя связать таблицы. Например, чтобы понять, какие заказы сделал пользователь с id=2, нам нужен этот id. Если бы у пользователей не было уникальных номеров, мы бы путались: "Заказ сделал Иван Петров. Какой именно Иван?"

Практический шаг: придумай свою таблицу

Открой любой текстовый редактор или блокнот. Придумай таблицу для хранения книг в библиотеке. Определи столбцы: какой будет первичным ключом? Какие типы данных? Запиши это в формате, похожем на SQL.

Вот пример, как это может выглядеть:

CREATE TABLE books (
 book_id SERIAL PRIMARY KEY,
 title VARCHAR(200) NOT NULL,
 author VARCHAR(100) NOT NULL,
 year_published INTEGER,
 isbn VARCHAR(13) UNIQUE
);

Попробуй сам. Не бойся ошибиться - это просто тренировка мышления. Потом мы научимся выполнять такие запросы в реальной базе.

Итог

Реляционная база - это таблицы со строками и столбцами. Каждая строка - объект, каждый столбец - свойство. Первичный ключ дает каждой записи уникальный номер, без него таблицы нельзя нормально связывать. Ты теперь видишь, что БД - не магия, а просто аккуратно организованные данные.

В следующем уроке: Связи между таблицами: внешние ключи, один-ко-многим, многие-ко-многим.