Введение в базы данных: от Excel к реляционным системам

Природа данных: почему Excel не всегда достаточно

Представьте, что вы открыли небольшой интернет-магазин. В первый месяц у вас 10 заказов в день. Вы заносите их в обычную таблицу Excel: имя клиента, телефон, товар, сумма. Все наглядно, удобно, можно быстро раскрасить ячейки с должниками в красный цвет.

Но прошел год. В Черную пятницу на сайт падает 5 000 заказов. Пять менеджеров одновременно пытаются обновить статусы доставок. Таблица зависает, выдает ошибку «Файл заблокирован другим пользователем», а курьер увозит заказ по несуществующему адресу, потому что кто-то случайно удалил цифру из номера дома.

Этот момент — классическая точка роста. Инструмент, который идеально подходил для старта, превратился в узкое горлышко. Чтобы понять, зачем миру понадобились базы данных (и такие системы, как PostgreSQL или MySQL), нужно разобраться, где именно заканчиваются возможности обычных электронных таблиц.

Когда таблица начинает «трещать по швам»

Excel, Google Sheets и Apple Numbers — это гениальные инструменты. Их главная сила в гибкости: вы можете в любой момент добавить новый столбец, написать формулу сбоку от данных или вставить график прямо поверх ячеек. Но эта же гибкость становится фатальной, когда данные превращаются в фундамент бизнеса.

Существуют три фундаментальные проблемы, с которыми сталкивается любая растущая таблица:

1. Многопользовательская работа (Конкурентность) Файл таблицы — это документ. Если два человека одновременно попытаются изменить одну и ту же строку, система либо заблокирует файл для одного из них, либо создаст конфликт версий. В современных приложениях (например, при бронировании билетов на самолет) сотни людей обращаются к одним и тем же данным в одну и ту же секунду.
2. Объем и скорость Excel имеет жесткий физический лимит — чуть больше 1 миллиона строк на листе. Но на практике таблица начинает мучительно долго открываться и зависать при фильтрации уже на сотнях тысяч строк. Для банковских транзакций или логов поведения пользователей на сайте миллион строк — это объем данных за пару часов.
3. Целостность данных (Защита от «дурака») В колонку «Дата рождения» в Excel можно случайно вписать слово «Завтра» или вставить картинку. Можно написать город как «Москва», «москва», «Мск» или «Масква». Для человека это одно и то же, но для компьютера — четыре разных города. Свести точный отчет по таким данным становится невозможно.

База данных: от документа к сервису

Чтобы решить эти проблемы, инженеры придумали базы данных (БД).

Главный сдвиг в мышлении, который нужно сделать при переходе от Excel к базам данных: база данных — это не файл, который вы открываете двойным кликом. Это непрерывно работающий сервис (программа), с которым вы общаетесь.

Здесь нам нужно разделить два понятия, которые часто путают:

• База данных (БД) — это сами данные, организованные по строгим правилам.
• СУБД (Система управления базами данных) — это программа-посредник, которая эти данные хранит, защищает и выдает по вашему запросу.

PostgreSQL, MySQL, Oracle, SQLite — всё это названия конкретных СУБД. Они как разные марки двигателей: устроены немного по-разному, но выполняют одну задачу — надежно управляют вашими данными.

Когда менеджер нажимает кнопку «Оплачено» в интерфейсе магазина, программа отправляет в СУБД строгую команду. СУБД сама решает, как безопасно записать это изменение на жесткий диск, даже если в эту же долю секунды другой менеджер тоже пытается изменить этот заказ.

Реляционные базы данных: знакомые таблицы, строгие правила

Существуют разные типы баз данных, но стандартом де-факто в мире бизнеса являются реляционные базы данных (от английского relation — отношение, что в математике баз данных означает двумерную таблицу). И PostgreSQL, и MySQL относятся именно к этому типу.

Хорошая новость: внутри реляционной базы данных информация хранится в виде таблиц, которые концептуально очень похожи на листы Excel.

Однако терминология и правила игры меняются:

Понятие в Excel	Понятие в БД	В чем фундаментальная разница?
Лист	Таблица	В БД таблица хранит только сущности одного типа (например, только «Клиенты» или только «Заказы»). Нельзя сбоку приписать заметки или нарисовать график.
Строка	Запись (Record)	Каждая строка — это один конкретный объект (один клиент). В БД нельзя пропустить строку для красоты или сделать пустой отступ.
Столбец	Поле (Field)	Каждое поле имеет строгий тип данных. Если поле названо «Цена» и настроено как число, СУБД выдаст ошибку и откажется сохранять туда текст «дорого».

Реляционная база данных жертвует визуальной свободой Excel ради абсолютной предсказуемости. Вы не можете раскрасить ячейку в желтый цвет, чтобы пометить важного клиента. Вместо этого вы создаете специальное поле is_important и ставите там логическое значение «да» или «нет».

Такая строгость гарантирует, что даже если в базе накопятся десятки миллионов записей, программа сможет мгновенно найти всех важных клиентов, не спотыкаясь об опечатки и пустые ячейки.

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

Анатомия реляционной таблицы: строки, столбцы и типы данных

Представьте, что менеджер интернет-магазина вносит новый товар в таблицу и в колонке «Цена» вместо числа пишет «по запросу». Для электронной таблицы это нормальная ситуация — она стерпит любой текст. Но когда ночью скрипт попытается применить к этой колонке скидку в 10%, математическая операция над словом «по запросу» приведет к сбою, и сайт магазина перестанет работать.

Реляционные базы данных спроектированы так, чтобы предотвращать подобные катастрофы на самом нижнем уровне. Таблица в СУБД — это не просто сетка для текста, это строгий таможенный контроль. И главные инструменты этого контроля — типы данных и ограничения.

Столбец как жесткий контракт

В базе данных каждый столбец (поле) имеет одну единственную задачу: хранить данные строго определенного формата. Вы не можете создать колонку просто для «какой-нибудь информации». В момент создания таблицы вы заключаете контракт с СУБД, указывая тип данных для каждого столбца.

Базовые типы данных, которые есть в PostgreSQL, MySQL и любой другой реляционной системе:

Тип данных	Что хранит	Пример значения	Зачем нужен именно он
INTEGER	Целые числа	42, -15, 0	Позволяет выполнять математические операции и сортировку по размеру.
VARCHAR	Текст ограниченной длины	"Иван", "Москва"	Экономит память, ограничивая максимальное количество символов.
BOOLEAN	Логическое значение	Истина (True) или Ложь (False)	Идеально для флагов: "оплачено", "в наличии", "аккаунт удален".
TIMESTAMP	Дата и точное время	2023-10-25 14:30:00	Позволяет вычислять интервалы (например, сколько дней прошло с момента заказа).

Если столбец объявлен как INTEGER, попытка записать туда слово «бесплатно» будет мгновенно отвергнута базой данных. СУБД просто не пропустит такую строку.

Ограничения (Constraints): когда типа данных недостаточно

Тип данных защищает от грубых ошибок, но не спасает от логических. Возраст человека может быть числом (INTEGER), но он не может быть отрицательным. Имя пользователя — это текст (VARCHAR), но оно не должно быть пустым.

Для внедрения бизнес-логики прямо в структуру таблицы используются ограничения (constraints). Это дополнительные правила, которые навешиваются на столбцы.

1. Обязательность: NOT NULL

По умолчанию СУБД позволяет оставить поле пустым (записать туда специальное значение NULL — «данные отсутствуют»). Если вы делаете систему регистрации, поле с email не может быть пустым. Добавление правила NOT NULL к столбцу гарантирует, что база отклонит любую запись без указания адреса.

2. Уникальность: UNIQUE

Если два пользователя зарегистрируются с одинаковым email, система авторизации не поймет, кого из них пускать в личный кабинет. Правило UNIQUE заставляет СУБД проверять всю колонку перед добавлением новой строки. Если такой email уже существует, операция будет прервана.

3. Пользовательские проверки: CHECK

Позволяет задать математическое или логическое условие. Например, для колонки price (цена) мы можем установить правило $price \geq 0$. Теперь база данных пропустит бесплатный товар (0 руб.), но выдаст ошибку, если кто-то попытается установить цену в -500 руб.

Ограничения переносят ответственность за качество данных с программиста на саму базу. Даже если в коде приложения есть ошибка, СУБД станет последним рубежом обороны и не даст испортить таблицу.

Строка как единое целое

Столбцы задают правила, но данные в базу поступают строками (записями). Строка описывает один конкретный объект целиком: один товар, одного пользователя, один заказ.

Важнейшее свойство реляционной базы данных заключается в том, что строка неделима при записи.

Такая строгость делает реляционные базы данных невероятно надежными. Вы всегда уверены, что структура данных внутри таблицы идеальна и соответствует вашим правилам.

Однако, если мы попытаемся описать сложный процесс — например, покупку товара пользователем — в одной таблице, нам придется дублировать массу информации. Данные о пользователе будут повторяться в каждой строке его заказа. Чтобы избежать этого, реляционная модель предлагает разбивать сущности на разные таблицы.

Связи и ключи: как разрозненные таблицы становятся единой базой

Мы научились создавать идеальные столбцы со строгими типами данных и логическими ограничениями. Кажется, теперь можно взять всю информацию бизнеса — клиентов, их покупки, адреса доставки — и сложить в одну большую, надежно защищенную таблицу.

Представим, как выглядит такая таблица заказов книжного магазина:

Дата	Покупатель	Email	Товар	Цена
10 мая	Иван	ivan@mail.ru	Гарри Поттер	1000 руб.
11 мая	Анна	anna@test.com	Властелин Колец	1500 руб.
12 мая	Иван	ivan@mail.ru	Хоббит	800 руб.
15 мая	Иван	ivan@mail.ru	Сильмариллион	1200 руб.

Иван сделал три заказа. Его имя и email скопированы трижды. Пока заказов мало, это не кажется проблемой. Но представьте, что Иван решил сменить почту на ivan@new.ru.

Чтобы обновить данные, базе придется просканировать миллионы строк, найти все заказы Ивана и изменить email в каждом из них. Если во время этого процесса произойдет сбой и обновится только часть строк, возникнет аномалия обновления: в одних заказах почта будет старой, в других — новой. База перестанет отражать реальность.

Чтобы избежать дублирования и аномалий, реляционные базы данных используют принцип декомпозиции: данные разбиваются на смысловые блоки. Вместо одной гигантской таблицы мы создаем две: Customers (Клиенты) и Orders (Заказы). В первой хранится только информация о людях, во второй — только факты покупок.

Но если мы разделим данные, как база поймет, какой заказ принадлежит Ивану? Нам нужен механизм, который намертво свяжет строки из разных таблиц.

Первичный ключ (Primary Key): якорь для данных

Чтобы сослаться на конкретного клиента, мы должны уметь однозначно его идентифицировать. Имя для этого не подходит (в базе могут быть сотни Иванов). Email тоже не идеален — он длинный, и пользователь может его изменить.

Для надежной идентификации в таблицу Customers добавляют специальный столбец — Первичный ключ (Primary Key, или PK). Чаще всего его называют просто id.

Это искусственный номер, который СУБД генерирует автоматически при добавлении новой строки. Он обладает тремя фундаментальными свойствами:

1. Уникальность: двух одинаковых id в одной таблице быть не может.
2. Неизменность: получив id один раз, строка сохраняет его навсегда.
3. Отсутствие бизнес-смысла: id — это просто порядковый номер или случайный набор символов, он не зависит от реальных характеристик объекта.

Таблица Customers теперь выглядит так:

id (PK)	Имя	Email
1	Иван	ivan@mail.ru
2	Анна	anna@test.com

Внешний ключ (Foreign Key): мост между таблицами

Теперь у Ивана есть уникальный неизменный идентификатор — 1. Чтобы привязать к нему заказы, мы добавляем в таблицу Orders новый столбец, который будет хранить этот идентификатор.

Таблица Orders принимает следующий вид:

order_id (PK)	customer_id (FK)	Товар	Цена
101	1	Гарри Поттер	1000 руб.
102	2	Властелин Колец	1500 руб.
103	1	Хоббит	800 руб.

Столбец customer_id в таблице заказов называется Внешним ключом (Foreign Key, или FK).

Внешний ключ — это указатель. Он говорит СУБД: «Значение в этой ячейке — это не просто цифра, это ссылка на первичный ключ в таблице Customers».

Объявление столбца внешним ключом включает мощный защитный механизм — ссылочную целостность. СУБД начинает строго следить за тем, чтобы связи не обрывались:

• Вы не сможете добавить заказ с customer_id = 99, если клиента с id = 99 не существует в таблице Customers. База выдаст ошибку.
• Вы не сможете случайно удалить Ивана из базы, пока на него ссылается хотя бы один заказ. СУБД заблокирует удаление, чтобы заказы не превратились в «сирот», указывающих в пустоту.

Отношение «Один-ко-многим»

Связка Primary Key и Foreign Key создает между таблицами логическое отношение (по-английски — relation). Именно поэтому такие базы данных называются реляционными.

В нашем примере один клиент может сделать много заказов, но каждый конкретный заказ принадлежит только одному клиенту. Такая архитектура называется связью «один-ко-многим» и является самым частым паттерном в проектировании баз данных.

Теперь, если Иван захочет сменить email, нам нужно обновить ровно одну ячейку в одной строке таблицы Customers. Все его заказы в таблице Orders автоматически останутся актуальными, потому что они ссылаются не на сам email, а на неизменный id Ивана. Разрозненные таблицы превратились в единую, непротиворечивую систему.

Экосистема СУБД: роль PostgreSQL и MySQL в современном мире

Мы спроектировали идеальную структуру: данные разбиты на таблицы, защищены строгими типами, а дублирование исключено благодаря первичным и внешним ключам. Но возникает практический вопрос: где физически «живут» эти таблицы?

Файл Excel можно просто открыть двойным кликом мыши. С базой данных так не получится. Реляционная база данных — это не просто файл на флешке, это часть сложной экосистемы, работающей по своим законам.

Невидимый двигатель: клиент-серверная модель

Современные СУБД работают по клиент-серверной архитектуре. Это значит, что система управления базами данных запускается на мощном компьютере (сервере) и работает там непрерывно, как фоновая служба. У нее нет привычного графического интерфейса с кнопочками. Она просто «слушает» сеть и ждет команд.

Кто же отдает команды? Клиенты. В роли клиента почти никогда не выступает живой человек. Клиентом является другая программа:

• Код интернет-магазина, который просит СУБД: «Дай мне список товаров для главной страницы».
• Мобильное приложение банка, которое передает: «Спиши 500 руб. со счета А и зачисли на счет Б».
• Аналитический дашборд, запрашивающий выручку за месяц.

Разделение на клиента и сервер дает колоссальное преимущество. К одной СУБД могут одновременно подключаться тысячи разных клиентов. Веб-сайт, мобильное приложение и программа на компьютере бухгалтера могут работать с одной и той же базой данных параллельно, а СУБД сама разрулит их запросы, не позволив данным перемешаться.

SQL: универсальный язык общения

Если клиент (например, сайт на языке Python) и сервер (СУБД) — это разные программы, как они понимают друг друга? Им нужен язык-посредник.

Таким стандартом стал SQL (Structured Query Language — язык структурированных запросов). Это текстовый язык, который понимают все реляционные СУБД.

Вместо того чтобы писать сложный программный код для поиска нужной строки в файлах, клиент отправляет СУБД короткую текстовую команду на SQL. Например: SELECT email FROM Customers WHERE city = 'Москва'

СУБД получает этот текст, сама придумывает оптимальный маршрут поиска по таблицам (используя индексы и ключи, которые мы обсуждали ранее), извлекает данные и возвращает клиенту готовый результат. SQL описывает что нужно получить, а как это сделать — решает сама СУБД.

Два титана: PostgreSQL и MySQL

Хотя SQL — это стандарт, сами «движки» (СУБД) бывают разными. В мире реляционных баз данных с открытым исходным кодом (Open Source) безоговорочно доминируют две системы: MySQL и PostgreSQL.

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

MySQL: скорость и простота веба

Исторически MySQL создавалась как максимально быстрая и простая база данных для чтения информации. Она стала фундаментом современного интернета. Если вы заходите на сайт, написанный на WordPress, или читаете старый форум — почти наверняка под капотом работает MySQL.

• Плюсы: Легко устанавливается, потребляет мало ресурсов, феноменально быстро работает с простыми запросами (например, «показать статью по ее ID»).
• Идеология: «Лучше я быстро отдам данные, даже если придется немного пожертвовать строгими проверками».

PostgreSQL: строгий аналитический комбайн

PostgreSQL (часто называют просто «Постгрес») изначально проектировалась в академической среде с упором на абсолютную надежность, математическую строгость и соответствие стандартам.

• Плюсы: Поддерживает сложнейшие аналитические запросы, умеет работать с неструктурированными данными (например, форматом JSON, сохраняя при этом реляционную природу), обладает мощнейшей системой ограничений (Constraints).
• Идеология: «Я лучше выдам ошибку и остановлю операцию, чем позволю записать в базу некорректные данные».

Сравнительная таблица

Характеристика	MySQL	PostgreSQL
Главный фокус	Скорость простых операций и массовый веб	Сложная бизнес-логика и аналитика
Отношение к ошибкам	Исторически склонна «сглаживать» ошибки (например, обрезать слишком длинный текст)	Максимально строгая: при малейшем несоответствии типу данных прервет транзакцию
Сложные типы данных	Базовый набор	Огромный выбор, включая массивы, геоданные, JSON
Где чаще встречается	Блоги, интернет-магазины, простые веб-сервисы	Финтех, корпоративные ERP-системы, геоинформационные сервисы

Сегодня границы между ними размываются: MySQL учится быть строже, а PostgreSQL становится быстрее. Выбор между ними часто зависит от привычек команды разработчиков, но для старта в профессии аналитика или инженера данных обе СУБД подходят идеально. Изучив SQL на примере PostgreSQL, вы без труда сможете работать и в MySQL, так как фундаментальные принципы реляционной модели у них идентичны.

На этом мы завершаем знакомство с теорией баз данных. Мы прошли путь от ограничений обычных таблиц до понимания экосистемы, в которой живут современные данные. Фундамент заложен — впереди практика.