Знакомство с базами данных
Разработчику
Аналитику
Тестировщику
Архитектору
Инженеру
Знакомство с базами данных
Мы уже разобрались с данными, информацией, сайтами и программами. Слова БД и СУБД встречались по ходу — здесь разложим их по полочкам без перегруза формулами.
База данных (БД) — сами данные и правила, по которым они организованы. СУБД (система управления базами данных) — программа, которая хранит эти данные на диске, принимает запросы, следит за целостностью и даёт доступ нескольким приложениям одновременно. В разговоре "база MySQL" обычно означает и данные, и СУБД — в учебниках различие полезно помнить.
Дальше — от простого к моделям хранения и выбору SQL / NoSQL / NewSQL.
Что такое база данных?
★ База данных — упорядоченное хранилище информации по заданной схеме — какие сущности есть, какие у них поля, какие связи и ограничения допустимы.
В нормативных и учебных источниках формулировки различаются, но сходятся в трёх признаках:
- Хранение и обработка в вычислительной системе — архивы, библиотечные каталоги или электронные таблицы без СУБД обычно БД не называют, хотя в них тоже есть упорядоченные данные.
- Логическая структурированность — явно выделены элементы, связи между ними, типы и допустимые операции (поиск, изменение, отчёт).
- Схема (метаданные) — формальное описание содержания, структуры и ограничений целостности. По ГОСТ Р ИСО МЭК ТО 10032-2007 (эталонная модель управления данными) постоянные данные в среде БД состоят из схемы и собственно базы данных; СУБД использует определения в схеме для доступа и контроля прав.
Типичные определения из литературы:
- совокупность данных, организованных по правилам и поддерживаемых в памяти компьютера для отражения предметной области;
- совместно используемый набор логически связанных данных и описания этих данных (схемы), удовлетворяющий информационным потребностям организации.
Удобная аналогия — записная книжка коллег — имя, телефон, отдел. В IT то же самое на другом масштабе — пользователи, товары, заказы, посты, логи.
Часто говорят "база MySQL", имея в виду и данные, и программу-менеджер. В учебниках база данных — содержимое и правила организации; СУБД — программный комплекс, который это содержимое создаёт, хранит и обслуживает. Подробнее — в главе СУБД.
Базы данных помогают:
- быстро искать и менять записи;
- не терять данные при сбоях (если СУБД настроена правильно);
- дать нескольким программам доступ к одним и тем же данным без "каши каждый в своём файле".
Типичный сценарий: сайт отправляет запрос "список пользователей с пагинацией", СУБД находит строки и отдаёт результат за миллисекунды — даже при миллионах записей, если есть индексы и разумная схема.
Схема базы данных
★ Схема базы данных (англ. database schema) — формальное описание содержания, структуры и ограничений целостности, по которым создают и сопровождают БД. В реляционных СУБД схема задаёт таблицы (отношения), столбцы с типами и обязательностью, первичные и внешние ключи, проверочные ограничения. Текст схемы хранится в словаре данных (каталоге системы); на диаграммах схему часто рисуют как таблицы и линии связей по внешним ключам.
Три уровня схемы (классическая схема проектирования):
| Уровень | Что описывает | Пример артефакта |
|---|---|---|
| Концептуальная | Понятия предметной области и связи между ними | ER-диаграмма без типов SQL |
| Логическая | Сущности, атрибуты, ключи, кардинальность | Логическая модель перед CREATE TABLE |
| Физическая | Как логика ложится на файлы, индексы, разбиения | DDL, партиции, индексы в PostgreSQL |
На концептуальном уровне говорят о сущностях (наборах однотипных фактов), атрибутах (свойствах) и связях между сущностями. Логическая схема переводит это в отношения и ключи; физическая — в конкретные объекты СУБД на диске.
В Oracle и SQL Server schema — ещё и пространство имён объектов (набор таблиц, представлений, процедур у пользователя или в БД). В PostgreSQL CREATE SCHEMA создаёт такое пространство (public, app, …). Это имя контейнера внутри одной БД, отдельно от "схемы данных" как описания структуры предметной области. См. мини-глоссарий.
Play ITЗагрузка интерактивного демо…
Модели данных и связи
Модель данных в классической теории БД — формальная теория представления и обработки данных в СУБД. Она включает три аспекта (по Э. Ф. Кодду и К. Дж. Дейту):
| Аспект | Содержание |
|---|---|
| Структура | Какие типы объектов и логические структуры допустимы (отношения, сегменты, документы…) |
| Манипуляция | Как переходить между состояниями БД и извлекать данные (алгебра, навигация по указателям, API) |
| Целостность | Какие ограничения должны выполняться всегда (ключи, домены, ссылочная целостность) |
Каждая СУБД построена на явной или неявной модели — реляционные — на реляционной модели данных (РМД), MongoDB — на документной, Redis — на "ключ–значение" и т.д.
Модель данных — инструмент и теория (как язык программирования). Схема конкретной БД — результат проектирования на этом инструменте (как программа на языке). Путать "модель данных" со "схемой таблиц" — распространённая ошибка; подчёркивали Дейт, Когаловский, Кузнецов.
На практике до DDL это "карта" сущностей, полей и связей. Теория реляционной модели — в Теоретических основах и в разделе SQL.
Два разных слова "relation"
| Термин | Откуда | Что значит |
|---|---|---|
| relation | реляционная модель Кодда | Отношение — таблица как набор кортежей (строк). Отсюда слово реляционная БД. |
| relationship | ER-моделирование | Связь между сущностями на диаграмме ("покупатель размещает заказ"). |
Реляционная СУБД хранит данные в отношениях (таблицах) и связывает их через ключи и JOIN. Связи в ER — проектный язык; в SQL они становятся внешними ключами (FOREIGN KEY) и запросами.
Подробнее: Entity Relationship, Теоретические основы, Реляционная модель.
На схеме выше — сущности "Пользователь" и "Группа". У пользователя есть поле с ID группы: так реализуется связь один ко многим.
Такие рисунки называют ER-диаграммами (Entity-Relationship; ERD в карте нотаций). Их рисуют на этапе проектирования; в работающей БД те же сущности — таблицы и ограничения.
Реляционные базы данных
★ Реляционные СУБД хранят данные в таблицах (отношениях). Схема задаёт столбцы, типы и ограничения; запросы чаще всего пишут на SQL.
Внешне таблица похожа на лист Excel — у СУБД при этом есть транзакции, одновременный доступ многих клиентов, внешние ключи, индексы, права доступа.
Пример таблицы users:
| ID | Имя | Возраст | |
|---|---|---|---|
| 1 | Анна | anna@mail.com | 25 |
| 2 | Иван | ivan@mail.com | 30 |
У каждого столбца — свой тип (INTEGER, VARCHAR, DATE и т.д.) и правила (NOT NULL, уникальность).
Примеры реляционных СУБД — PostgreSQL, MySQL, Microsoft SQL Server, SQLite.
Сила модели — в связях между таблицами: заказ ссылается на клиента, строка заказа — на товар. Ниже — упрощённая ER-схема магазина:
Нереляционные и специализированные хранилища
★ NoSQL — Not Only SQL — семейство СУБД под другие компромиссы — гибкая схема, горизонтальное масштабирование, низкая задержка, граф, кэш.
Документ в MongoDB может выглядеть так:
{
"id": 1,
"name": "Анна",
"email": "anna@mail.com",
"hobbies": ["рисование", "путешествия"]
}
У соседней записи может не быть поля hobbies — для документной модели это нормально.
Примеры NoSQL-СУБД — MongoDB, Redis, Cassandra, Neo4j.
В примерах названы СУБД (продукты), как MySQL или PostgreSQL.
Как выбирать
| Задача | Частый выбор | Почему |
|---|---|---|
| Учёт, платежи, строгие инварианты | Реляционная СУБД + SQL | ACID, FK, нормализация |
| Кэш, сессии, счётчики | Redis и т.п. | Скорость, TTL |
| Каталог с разной структурой полей | MongoDB и др. | Гибкая схема |
| SQL + масштаб кластера | NewSQL | NewSQL |
На реальных проектах часто несколько хранилищ: PostgreSQL для заказов, Redis для сессий — разделение нагрузок.
Дальше по маршруту раздела: роль БД в организации → теория и WAL → правила Кодда → ER-модель.
Четыре основных типа баз данных
В учебниках и на схемах архитектуры часто выделяют четыре семейства хранилищ — по тому, как устроены записи и связи между ними. Реляционные СУБД держат строгую схему таблиц и сильны в транзакциях; NoSQL даёт гибкую схему и горизонтальное масштабирование под высоконагруженные веб-сервисы; иерархические удобны для деревьев "родитель → потомок"; объектно-ориентированные хранят данные как объекты в духе ООП. На реальном проекте часто сочетают несколько типов — заказы в PostgreSQL, сессии в Redis.
| Тип | Суть | Типичные задачи | Примеры |
|---|---|---|---|
| Реляционные (SQL) | Таблицы, строки, столбцы; связи через ключи и JOIN | Финансы, e-commerce, CRM, ERP, банки, складской учёт | PostgreSQL, MySQL, Oracle, SQL Server |
| NoSQL | Гибкая или отсутствующая схема; упор на масштаб и скорость простых операций | Веб в реальном времени, big data, CMS, IoT | MongoDB, Cassandra, Redis, DynamoDB |
| Иерархические | Дерево: у потомка один родитель, поток данных вниз по ветке | Файловые системы, XML, оргструктуры | IBM IMS, реестр Windows, LDAP |
| Объектно-ориентированные | Объекты с полями, наследованием и связями "как в коде" | CAD, мультимедиа, сложное моделирование | ObjectDB, db4o, Versant, GemStone |
Подробнее про реляционную и NoSQL-модели — в разделах выше и ниже; углубление — SQL, NoSQL.
Реляционные (SQL) — особенности и выбор
★ Реляционные СУБД хранят структурированные данные в таблицах (отношениях), связанных ключами. Запросы пишут на SQL; транзакции обычно подчиняются ACID.
Сильные стороны:
- декларативный SQL и зрелая экосистема инструментов;
- ACID — надёжные транзакции при переводах, заказах, остатках;
- сложные выборки с JOIN по многим таблицам;
- сильная согласованность данных при одновременной работе клиентов;
- стандартизированный язык запросов.
Когда выбирают: учёт денег и товаров, CRM, ERP, банковские системы, любая предметная область с жёсткими инвариантами и отчётами "как в Excel, но на миллионах строк".
Примеры продуктов — PostgreSQL, MySQL, Oracle, Microsoft SQL Server, SQLite (встраиваемая).
NoSQL — особенности и выбор
★ NoSQL (Not Only SQL) — семейство СУБД под другие компромиссы — горизонтальное масштабирование (шардирование), гибкая схема, высокая скорость простых чтений и записей. Внутри NoSQL выделяют документные, ключ–значение, колоночные и графовые модели — см. Основы NoSQL.
Сильные стороны:
- масштабирование добавлением узлов, а не только более мощным сервером;
- схема может меняться по записям (особенно в документных БД);
- высокая производительность простых запросов по ключу или документу;
- заточенность под современные веб-приложения и потоки событий.
Когда выбирают: ленты и чаты, каталоги с разной структурой полей, кэш и сессии, аналитика больших логов, датчики IoT.
Примеры — MongoDB, Cassandra, Redis, DynamoDB, Neo4j (граф).
PostgreSQL для заказов и Redis для сессий — обычная схема. Спор "что лучше" заменяют вопросом "какая нагрузка и какие гарантии нужны для этой части данных".
Иерархические
★ Иерархическая модель — данные как дерево: у каждого узла-потомка ровно один предок; у родителя может быть много детей. Движение по связям в основном вниз по заранее заданным путям.
Сильные стороны:
- быстрый доступ, если путь известен ("все файлы в каталоге", "все подразделения отдела");
- простые связи один ко многим;
- эффективность при чтении по дереву;
- понятная структура без лишних связей "вбок".
Когда выбирают: файловые системы, XML-хранилища, каталоги LDAP, организационные деревья, наследники мейнфреймовых систем.
Примеры: IBM IMS (классическая СУБД), реестр Windows, LDAP-каталоги. Близкая аналогия без отдельной СУБД — каталоги и подкаталоги на диске.
Запрос вверх по дереву или произвольные связи между ветками реализуют сложнее, чем в реляционной модели с JOIN — одна из причин, почему в корпоративном учёте победили таблицы SQL.
Объектно-ориентированные
★ Объектно-ориентированная СУБД (ООСУБД) хранит объекты — структуры с полями и методами, близкие к классам в Java, C# или Python. Поддерживаются наследование и полиморфизм на уровне хранилища.
Сильные стороны:
- сложные связи между сущностями без "размазывания" по десяткам таблиц;
- прямое сохранение объектов приложения;
- богатое моделирование (вложенные структуры, наследники одного базового типа);
- меньше слоя ORM между кодом и БД.
Когда выбирают: CAD/САПР, мультимедийные проекты, научное и инженерное моделирование с глубокой объектной моделью.
Примеры: ObjectDB, db4o, Versant, GemStone. В массовой веб-разработке чаще берут реляционную БД + ORM или документную MongoDB; ООСУБД остаются в узких нишах.
Другие модели и подтипы
Помимо четырёх "учебных" типов в истории и в специализации встречаются ещё варианты.
| Тип | Суть | Примеры |
|---|---|---|
| Документная (подтип NoSQL) | Записи в JSON/BSON, гибкая структура полей | MongoDB |
| Ключ–значение (подтип NoSQL) | Пары ключ → значение, часто в памяти | Redis |
| Графовая (подтип NoSQL) | Вершины и рёбра, обход связей | Neo4j |
| Сетевая (историческая) | Граф записей; у потомка несколько предков | IDMS, IDS |
Сетевая модель
Расширение иерархии: у потомка может быть несколько предков. Записи связаны типами связей; навигация — переход по указателям от предка к потомку и обратно. Модель была эффективна на железе 1960–70-х, но жёстко привязана к физической организации — смена структуры часто требовала переписывания приложений. Стандарт CODASYL; спор Кодда и Бахмана (1974) показал преимущество декларативной реляционной модели.
Реляционная модель — почему стала основой корпоративного учёта
Э. Ф. Кодд (1969–1970) предложил хранить всё в отношениях и оперировать ими через реляционную алгебру. Информационный принцип: содержимое БД задаётся только значениями в кортежах, без скрытых указателей между ячейками. Отсюда декларативный SQL и ограничения целостности в DDL. Иерархия, сеть и ООСУБД остались в нишах; реляционные БД — опора банков, ERP и большинства бизнес-приложений.
История носителей — от перфокарт до облачных СХД — в разделе "Данные и информация" и в внутреннем устройстве.