3. База данных

1.

Типы БД

2.

Типы БД
Реляционные базы данных (SQL) хранят данные в виде таблиц с чётко
заданной структурой — как таблица в Excel: строгие колонки, всё по порядку.
Примеры СУБД: PostgreSQL, MySQL, Oracle, MS SQL Server.
Нереляционные базы данных (NoSQL) хранят данные в гибком формате — как
Google Docs: можно писать в свободной форме, без жёстких правил.
Форматы хранения и примеры СУБД:
•Документы (JSON) — MongoDB, CouchDB
•Ключ-значение — Redis, DynamoDB
•Графы — Neo4j, Amazon Neptune
•Колонки — Cassandra, HBase

3.

Нереляционные базы данных
Нереляционные БД (NoSQL) хранят данные без строгой структуры — в формате
JSON, ключ-значение, графах или колонках.
Примеры СУБД: MongoDB, Cassandra, Redis, Neo4j.
Когда использовать:
• Данные слабо структурированы или часто меняют формат
• Требуется горизонтальное масштабирование и высокая скорость
• Нет жёсткой необходимости в транзакциях
Примеры применения: соцсети, онлайн-игры, чаты, big data, кэши.

4.

Реляционные базы данных
Реляционные БД (SQL) — самый распространённый тип. Хранят данные в
таблицах с чёткой структурой и связями между ними.
Примеры СУБД: MySQL, PostgreSQL, MS SQL, Oracle.
Когда использовать:
• Данные структурированы и редко меняют формат
• Важны связи между таблицами (JOIN), целостность и транзакции (ACID)
• Нужны сложные аналитические запросы
Примеры применения: финансы, бухгалтерия, медицинские карты, ERPсистемы.

5.

SQL vs NoSQL
SQL
NoSQL
Структура
Жёсткая схема, таблицы
Гибкая: JSON, ключзначение, графы
Масштабирование
Вертикальное
Горизонтальное
Транзакции
ACID
Частично (BASE)
Связи
JOIN между таблицами
Как правило,
денормализованные
данные
Скорость записи
Медленнее при высокой
нагрузке
Быстрее при высокой
нагрузке
Когда использовать
Чёткая структура, важна
целостность
Большие объёмы, гибкая
схема, скорость
Примеры
PostgreSQL, MySQL, MS SQL MongoDB, Redis, Cassandra

6.

Типы данных в БД

7.

Числовые типы
• INTEGER (INT) — целое число от -2 147 483 648 до 2 147 483 647.
Пример: количество товаров в заказе, возраст, ID записи.
• REAL / FLOAT — число с плавающей точкой, точность ~7 значащих цифр.
Пример: цены, проценты, измерения, любые вычисляемые значения.

8.

Строковые типы
• CHAR(n) — фиксированная длина, всегда занимает n символов, короткие строки
дополняются пробелами.
Пример: коды стран, артикулы.
• VARCHAR(n) — переменная длина до n символов, занимает ровно столько,
сколько нужно. Использовать по умолчанию для строк.
• TEXT — неограниченный текст, но работает медленнее и не поддерживает
некоторые индексы.
Пример: описания, комментарии, статьи.
Правило выбора: CHAR — короткие фиксированные значения, VARCHAR — по
умолчанию, TEXT — длинные описания.

9.

Типы даты и времени
• DATE — только дата без времени.
Пример: 2023-11-30. Использовать для дат рождения, дат заказов.
• TIME — только время без даты.
Пример: 15:30:00. Использовать для расписаний, времени работы.
• TIMESTAMP / DATETIME — дата и время вместе.
Пример: 2023-11-30 15:30:00. Использовать для логов, истории изменений,
меток создания записи.

10.

Логический тип
BOOLEAN — хранит одно из двух значений: true
или false.
Пример: подписан ли пользователь на рассылку,
включены ли уведомления, активен ли аккаунт.

11.

Бинарные типы
• BYTEA (PostgreSQL) — хранение файлов,
изображений, зашифрованных данных.
• BINARY(n) / VARBINARY(n) (MySQL, MS SQL) —
фиксированная и переменная длина бинарных
данных.
• BLOB (MySQL, MS SQL) — большие бинарные
объекты: файлы, медиа, документы.

12.

Уникальный идентификатор
UUID (PostgreSQL) / UNIQUEIDENTIFIER (MS SQL) /
CHAR(36) (MySQL) — строка вида 550e8400-e29b-41d4-a716446655440000, уникальная для каждого объекта в системе.
Пример: ID заказа, ID пользователя, ID транзакции.

13.

Перечисляемый тип
ENUM (PostgreSQL, MySQL) — фиксированный набор допустимых значений.
Пример: статус заказа NEW, PROCESSING, DONE; пол MALE, FEMALE; роль ADMIN,
USER, GUEST.
В MS SQL аналога нет — ограничение реализуется через CHECK или справочную
таблицу.

14.

Массив
ARRAY (массив) (PostgreSQL) — набор элементов
одного типа, расположенных в строгом порядке и
доступных по индексу.
Пример: список телефонов пользователя
{"+79001234567", "+79007654321"}, теги статьи
{"sql", "база данных", "postgresql"}.
В MySQL и MS SQL встроенного типа массив нет —
реализуется через отдельную таблицу.

15.

Основные свойства массива
Свойства массива:
• Нумерация элементов начинается с 0
• Все элементы массива должны быть одного типа
• Доступ к элементу осуществляется по индексу
Пример из жизни: Журнал группы — список студентов, где каждый занимает
определённое место. Чтобы найти Петрова, преподаватель смотрит его номер в
списке — это и есть индекс.
Индекс
Студент
0
Иванов
1
Петров
2
Сидоров

16.

Типы данных PostgreSQL
Группа
Тип
Описание
Целые числа
INTEGER
4-байтовое целое число
Числа с плавающей
точкой
REAL
4 байта, меньшая точность
CHAR(n)
Строка фиксированной длины
VARCHAR(n)
Строка переменной длины
TEXT
Неограниченный текст
DATE
Дата (год, месяц, день)
TIME
Время (часы, минуты, секунды)
TIMESTAMP
Дата и время без часового пояса
TIMESTAMPTZ
Дата и время с часовым поясом
Булев тип
BOOLEAN
Логическое значение (true/false)
Двоичные данные
BYTEA
Бинарные данные: изображения, файлы
Массивы
INTEGER[], TEXT[]
Массив значений одного типа
Уникальный
идентификатор
UUID
Уникальный идентификатор записи
Перечисление
ENUM
Фиксированный набор допустимых значений
Текстовые строки
Дата и время

17.

Типы данных MySQL vs PostgreSQL vs MS
SQL
Группа
PostgreSQL
MySQL
MS SQL
Целые числа
INTEGER, BIGINT
INT, BIGINT
INT, BIGINT
Дробные числа
REAL, NUMERIC
FLOAT, DECIMAL
FLOAT, DECIMAL
Строки
VARCHAR(n), TEXT
VARCHAR(n), TEXT
VARCHAR(n),
NVARCHAR(n)
Дата и время
DATE, TIMESTAMP,
TIMESTAMPTZ
DATE, DATETIME
DATE, DATETIME,
DATETIME2
Булев тип
BOOLEAN
TINYINT(1)
BIT
Бинарные данные
BYTEA
BLOB
VARBINARY
UUID
UUID
CHAR(36)
UNIQUEIDENTIFIER
Перечисление
ENUM
ENUM
CHECK / справочник
Массив
INTEGER[], TEXT[]
Нет
Нет
JSON
JSON, JSONB
JSON
NVARCHAR + JSONфункции

18.

NULL в БД
NULL — отсутствие значения. Не то же самое, что 0 или пустая строка.
Значение
Смысл
NULL
Значение неизвестно или отсутствует
0
Числовое значение ноль
''
Пустая строка — значение есть, но оно пустое
Особенности NULL:
• NULL не равен NULL — сравнение NULL = NULL всегда возвращает false
• Для проверки используется IS NULL / IS NOT NULL
• Агрегатные функции (COUNT, SUM) игнорируют NULL
• NULL в арифметике даёт NULL: 5 + NULL = NULL
Пример:
-- Неправильно
WHERE phone = NULL
-- Правильно
WHERE phone IS NULL

19.

Структура БД

20.

Физическая структура БД
Физическая структура БД — это то, как данные фактически хранятся на диске:
файлы, механизмы хранения, индексы и другие низкоуровневые детали.
Включает:
• Файлы данных — физические файлы на диске, в которых хранятся таблицы и
индексы
• Механизмы хранения — движок, управляющий записью и чтением данных
(например, InnoDB в MySQL)
• Индексы — структуры для ускорения поиска данных
• Журналы транзакций — файлы для обеспечения целостности и
восстановления данных
• Табличные пространства — логические контейнеры для группировки файлов
данных

21.

Логическая структура БД
Логическая структура БД — описывает организацию данных с точки зрения
таблиц, полей, связей и ограничений. Не зависит от того, как данные хранятся
физически.
Включает:
• Таблицы — основные единицы хранения данных, состоят из строк и столбцов
• Поля (столбцы) — атрибуты сущности с заданным типом данных
• Первичный ключ (PK) — уникальный идентификатор каждой записи в таблице
• Внешний ключ (FK) — поле, связывающее таблицу с другой таблицей
• Связи — отношения между таблицами: один-к-одному, один-ко-многим, многиеко-многим
• Ограничения — правила целостности данных: NOT NULL, UNIQUE, CHECK

22.

Сущность
Сущность (Entity) — объект реального мира, данные о котором мы храним в базе
данных.
В БД каждая сущность представлена в виде таблицы, а её свойства — в виде
столбцов.
Из жизни: в магазине есть покупатели, товары и заказы — это сущности. У
каждого покупателя есть имя и email, у каждого товара — название и цена. В базе
данных каждая из них становится отдельной таблицей.
Системные примеры:
• Пользователь — ID, имя, email, дата регистрации
• Товар — ID, название, цена, остаток на складе
• Заказ — ID, дата, статус, итоговая сумма
• Автомобиль — ID, марка, модель, год выпуска

23.

Как определить, что объект — это
сущность?
• Это объект реального мира? (Пользователь, товар, заказ — да)
• У объекта есть уникальные свойства? (Имя, email, цена)
• Объект можно описать атрибутами и хранить в таблице?
Если на все три вопроса ответ «да» — перед вами сущность.
Аналогия: Сущность — это автомобиль. Атрибуты — цвет, марка, модель, год
выпуска. База данных — гараж, где хранятся все автомобили.

24.

Атрибуты сущности
Атрибут — свойство сущности, которое хранится в БД как столбец таблицы.
Типы атрибутов:
• Простой — неделимое значение. Пример: age, price, status.
• Составной — состоит из нескольких частей, которые можно разделить. Пример:
полное имя → first_name + last_name + middle_name.
• Многозначный — может иметь несколько значений. Пример: у пользователя
несколько телефонов → выносится в отдельную таблицу.
• Вычисляемый — значение вычисляется на основе других атрибутов. Пример:
age можно вычислить из birth_date, total = price * quantity.
Правило: вычисляемые атрибуты лучше не хранить в БД — считать на лету,
чтобы не допустить рассинхронизации.

25.

Практическое задание
по выделению сущностей и их
атрибутов
Щенки бывают пушистые и гладкошерстные. Все пушистые
щенки любят играть. Если щенок устал, он лежит в будке.
Все гладкошерстные щенки любят бегать по двору.

26.

ERD

27.

ER-диаграмма
ER-диаграмма (Entity-Relationship) — визуальная
модель логической структуры данных, которая
описывает сущности и их взаимосвязи.
Из чего состоит:
• Сущности — объекты реального мира (таблицы в
БД)
• Атрибуты — свойства сущностей (столбцы таблицы)
• Связи — отношения между сущностями
Зачем нужна:
• Визуализировать структуру БД до её создания
• Согласовать модель данных с командой и заказчиком
• Выявить связи и зависимости между объектами
• Служит основой для проектирования таблиц

28.

Пример ERD

29.

Типы связей
Один к одному (1:1)
Один к одному (1:1) — одной записи в первой таблице соответствует ровно одна
запись во второй.
Пример: пациент — медицинская карта. У каждого пациента одна медицинская
карта, у каждой медицинской карты один владелец.

30.

Типы связей
Один ко многим (1:М)
Один ко многим (1:М) — одной записи в первой таблице соответствует
несколько записей во второй. Самый распространённый тип связи.
Пример: клиент — адерса. У одного клиента может быть много адресов, но
каждый адрес принадлежит только одному клиенту.

31.

Типы связей
Многие ко многим (М:М)
Многие ко многим (М:М) — многим записям первой таблицы соответствуют
многие записи второй. В БД реализуется через промежуточную таблицу.
Пример: театры — фильмы. Один театр может показывать много фильмов, один
фильм могут показывать во многих театрах.

32.

Как построить ER-диаграмму
1. Определить сущности — выделить объекты реального мира, которые нужно
хранить в БД.
Пример: Пользователь, Заказ, Товар.
2. Определить связи — установить, как сущности связаны между собой и какого
типа эти связи (1:1, 1:М, М:М).
Пример: Пользователь размещает Заказы.
3. Определить атрибуты — задать свойства каждой сущности и выделить
первичный ключ.
Пример: у Пользователя — ID, имя, email.
Результат: ER-диаграмма становится основой для создания БД — сущности
превращаются в таблицы, связи реализуются через внешние ключи.

33.

Ключи: Primary Key
Primary Key (первичный ключ) — уникальный идентификатор каждой записи в
таблице. Как правило, называется id.
Используется для однозначной идентификации строки и обеспечения
уникальности данных.
Характеристики:
• Уникальность — два разных объекта не могут иметь одинаковый PK
• Неизменяемость — значение PK не меняется после создания записи
• Не пустой — PK не может быть NULL
Пример: в таблице пользователей каждый пользователь имеет уникальный id —
даже если два пользователя зовут Иван Иванов, их id будут разными.

34.

Ключи: Foreign Key
Foreign Key (внешний ключ) — это Primary Key из другой таблицы,
размещённый в текущей таблице для создания связи между ними.
Основные функции:
• Связь между таблицами — внешний ключ связывает таблицу-потомок с
таблицей-родителем. Значение FK в таблице-потомке всегда ссылается на
существующий PK в таблице-родителе.
• Контроль целостности данных — при добавлении, изменении или удалении
записей СУБД автоматически проверяет существование связанных данных.
Пример: в таблице Заказов есть поле user_id — это внешний ключ, который
ссылается на id в таблице Пользователей. Нельзя создать заказ для
несуществующего пользователя.

35.

Ограничения
Ограничения (Constraints) — правила, которые СУБД автоматически проверяет
при добавлении или изменении данных.
1. Тип данных — каждый столбец принимает только значения заданного типа.
Нельзя записать «двадцать лет» в числовое поле age.
2. Длина строки — максимальное количество символов в строковом поле.
Предотвращает ошибки и экономит память.
3. UNIQUE — значение в столбце должно быть уникальным среди всех записей.
Пример: два пользователя не могут зарегистрироваться с одинаковым email.
4. NOT NULL — поле не может быть пустым.
Пример: user_id в таблице заказов обязателен — заказ не может существовать
без пользователя.
5. CHECK — ограничение, которое проверяет значение по заданному условию
перед записью.
6. DEFAULT — значение по умолчанию, если при вставке поле не указано.

36.

Нотации ERD
Crow's Foot (Воронья лапка) — самая распространённая. Связи обозначаются
символами на концах линий.
Chen — классическая академическая нотация. Сущности — прямоугольники,
атрибуты — эллипсы, связи — ромбы.

37.

Типы таблиц

38.

Историческая таблица
Таблица-справочник (историческая) — хранит историю изменений параметров
во времени.
Используется, когда важно знать не только текущее значение, но и то, каким оно
было в прошлом.
Пример: процентная ставка Центрального Банка менялась несколько раз за год —
историческая таблица позволяет узнать, какая ставка действовала на конкретную
дату.
Каждая запись фиксирует значение параметра за определённый период.
Стандартный формат: date_from / date_to.
id
Ставка
date_from
date_to
1
6.5
2023-01-01
2023-06-09
2
7.0
2023-06-10
2023-10-31
3
7.5
2023-11-01
2024-04-30
4
8.0
2024-05-01
NULL

39.

Словарь/классификатор
Таблица-справочник (словарь/классификатор) — содержит фиксированный
список допустимых значений для других таблиц. Изменяется редко, используется
для нормализации данных.
Вместо того чтобы в каждой строке писать «Российский рубль», таблица хранит
один раз список валют, а другие таблицы ссылаются на него по внешнему ключу
currency_id.
id code name
1
RUB
Российский рубль
2
USD
Доллар США
3
EUR
Евро

40.

Настроечная таблица
Настроечная таблица — хранит параметры, коэффициенты и лимиты, влияющие
на логику системы. Позволяет менять поведение системы без изменения кода.
Вместо того чтобы зашивать значения в код, система читает их из таблицы —
достаточно обновить запись в БД.
id
setting_key
value
description
1
tax_rate_default
0.20
Стандартная ставка
НДС
2
loyalty_bonus_coefficient
1.15
Коэффициент для
расчета бонусов
3
max_login_attempts
5
Кол-во попыток
входа до блокировки

41.

Фактическая таблица
Фактическая таблица — хранит сущности, собранные из нескольких справочных
таблиц. Содержит ссылки на справочники (FK) и уникальные комбинации их
значений.
Сама по себе не дублирует данные — только ссылается на них.
Таблица авторов
Таблица жанров
id name
id name
1
Джордж Оруэлл
1
Фантастика
2
Агата Кристи
2
Детектив
Таблица книг
id
title
author_id
genre_id
year
1
«1984»
1
1
1949
2
«Убийство в «Восточном экспрессе»
2
2
1934

42.

Временные таблицы
Временная таблица — таблица, которая существует только в рамках текущей
сессии или транзакции и автоматически удаляется после её завершения.
Используется для:
• Промежуточных вычислений в сложных запросах
• Хранения временных результатов для дальнейшей обработки
• Разбиения сложной логики на шаги

43.

Представления
Представления (VIEW) — виртуальная таблица, основанная на SELECT-запросе.
Данные не хранятся физически — при обращении к VIEW запрос выполняется
заново.
Зачем нужны:
• Скрыть сложность запроса — дать простое имя сложной выборке
• Ограничить доступ — показать пользователю только нужные столбцы
• Переиспользовать логику — не дублировать одинаковые запросы

44.

Нормализация БД

45.

Нормализация БД
Нормализация БД — процесс организации данных по правилам, которые
обеспечивают чистоту и логичность структуры.
Цели нормализации:
• Устранить избыточность — одни и те же данные не хранятся в нескольких
местах
• Устранить несогласованные зависимости — данные хранятся там, где это
логично
• Повысить гибкость — изменение данных в одном месте не ломает остальное
Простая аналогия: если имя клиента хранится в таблице заказов, придётся
обновлять его в каждом заказе при смене фамилии. После нормализации имя
хранится один раз — в таблице клиентов.

46.

Первая нормальная форма (1НФ)
Таблица соответствует 1НФ, если:
• Каждая ячейка содержит одно атомарное значение — нельзя хранить список
или составные данные в одном поле
• В таблице нет дублирующихся строк
id
клиент
телефоны
id
клиент
телефон
1
Иванов
+79001234567, +79007654321
1
Иванов
+79001234567
2
Иванов
+79007654321

47.

Вторая нормальная форма (2НФ)
Таблица соответствует 2НФ, если:
• Выполнены требования 1НФ
• Каждая запись имеет первичный ключ
• Все неключевые атрибуты полностью зависят от первичного ключа, а не от
его части
Нарушение 2НФ — название
order_id product_id название товара количество
товара зависит только от
1
5
Ноутбук
2
product_id, а не от всего ключа:
2
Исправление — выносим товар в
отдельную таблицу:
5
Ноутбук
product_id
название товара
5
Ноутбук
order_id
product_id
количество
1
5
2
1

48.

Третья нормальная форма (3НФ)
Таблица соответствует 3НФ, если:
• Выполнены требования 2НФ
• Неключевые атрибуты зависят только от первичного ключа, а не друг от
друга
Нарушение 3НФ — город зависит от
индекса, а не от id заказа:
order_id
индекс
город
1
101000
Москва
2
190000
Санкт-Петербург
Исправление — выносим зависимость в индекс
отдельную таблицу:
101000
190000
город
order_id
индекс
Москва
1
101000
Санкт-Петербург
2
190000

49.

Денормализация
Денормализация — намеренное отступление от правил нормализации с целью
ускорения операций чтения.
Вместо множества JOIN-ов данные объединяются в одну таблицу — запрос
становится проще и быстрее, но данные могут дублироваться.
Когда применять:
• Высокая нагрузка на чтение данных
• Нормализованная структура требует слишком многих JOIN для получения
результата
• Аналитические БД, где скорость сложных запросов важнее строгости структуры
Компромисс:
Нормализация
Денормализация
Скорость чтения
Медленнее (много JOIN)
Быстрее
Избыточность данных
Минимальная
Есть дубли
Обновление данных
Просто
Сложнее

50.

Аномалии БД
Аномалии — проблемы, которые возникают в ненормализованных таблицах при
изменении данных.
Аномалия вставки — невозможно добавить данные без указания несвязанной
информации.
Пример: нельзя добавить новый курс, пока на него не записан хотя бы один
студент.
Аномалия обновления — одно изменение требует обновления в нескольких
строках.
Пример: если изменилось название отдела, нужно обновить его в каждой строке
каждого сотрудника.
Аномалия удаления — удаление одних данных уничтожает другие нужные
данные.
Пример: если удалить последнего студента курса, информация о курсе тоже
исчезнет.
Решение: нормализация — каждый факт хранится в одном месте.

51.

Индексы

52.

Индексы БД
Индекс — отдельная структура данных, которая хранит значения выбранных
столбцов в отсортированном виде и указатели на физическое расположение строк
в таблице.
Аналогия: индекс в БД работает как оглавление в книге — вместо того чтобы
листать все страницы, вы сразу открываете нужную.
Как работает:
• Без индекса — СУБД перебирает все строки таблицы (Full Table Scan)
• С индексом — СУБД сразу находит нужные строки по отсортированной структуре
Когда использовать:
• Столбцы, по которым часто фильтруют (WHERE)
• Столбцы, по которым сортируют (ORDER BY)
• Внешние ключи (FK)
Компромисс: индекс ускоряет чтение, но замедляет запись — при каждом
изменении данных индекс нужно обновлять.

53.

Плюсы и минусы индексов
Правило: индексы — это инструмент оптимизации, а не решение по умолчанию.
Создавайте их осознанно, только там, где это реально нужно.
Плюсы
Минусы
Ускоряют поиск — быстрее выполняются
SELECT
Замедляют запись — при INSERT, UPDATE,
DELETE индекс пересчитывается
Улучшают сортировку — ускоряют ORDER BY
Увеличивают объём хранения
Оптимизируют JOIN между таблицами
Требуют администрирования — нужно
следить за актуальностью
Ускоряют фильтрацию WHERE
Не всегда используются — при неудачном
выборе СУБД может игнорировать индекс
Ускоряют агрегатные функции COUNT, MAX,
MIN
Неправильный индекс может навредить
производительности

54.

Составные индексы
Составной индекс — индекс, созданный на основе нескольких столбцов.
Ускоряет запросы, которые фильтруют или сортируют данные по комбинации
значений.
Пример: индекс по (customer_id, order_date) ускорит запрос «найти все заказы
клиента за определённый период».
Важное правило — порядок столбцов имеет значение:
• Составной индекс (customer_id, order_date) работает при фильтрации по
customer_id или по customer_id + order_date
• Но не работает при фильтрации только по order_date
Запрос
WHERE customer_id = 5
WHERE customer_id = 5 AND
order_date = '2024-01-01'
WHERE order_date = '2024-01-01'
Индекс используется?

55.

Максимальное количество индексов
СУБД
Индексов на таблицу
Столбцов в составном индексе
MySQL
До 64
До 16
PostgreSQL
Без ограничений
Без ограничений
MS SQL Server
До 1000 (999 неключевых + 1
кластерный)
До 32
Важно: наличие технической возможности создать много индексов не означает,
что это нужно делать. Каждый индекс — дополнительная нагрузка на запись и
хранение.

56.

Синтаксис создания составного индекса
Создание индекса:
-- PostgreSQL / MySQL
CREATE INDEX idx_customer_order ON orders (customer_id, order_date);
-- MS SQL Server
CREATE INDEX idx_customer_order ON orders (customer_id, order_date);
Удаление индекса:
-- PostgreSQL / MySQL
DROP INDEX idx_customer_order;
-- MS SQL Server
DROP INDEX orders.idx_customer_order;
Правило именования:
idx_ + название таблицы + столбцы.
Пример: idx_orders_customer_date — сразу понятно, к какой таблице и каким
столбцам относится индекс.

57.

Плюсы и минусы составных индексов
Плюсы
Минусы
Ускоряют запросы по нескольким столбцам в
WHERE, ORDER BY, GROUP BY
Зависят от порядка столбцов — работают
только слева направо
Эффективны при сортировке, если поля
идут в порядке индекса
Игнорируются, если запрос не использует
первый столбец индекса
Могут заменить несколько одиночных
индексов
Занимают больше памяти, чем одиночные
индексы
Хорошо работают с диапазонами: a = ? AND
b>?
Сложнее выбрать оптимальный состав и
порядок полей
Больше накладных расходов при
INSERT/UPDATE
Главное правило: первым в составном индексе ставьте столбец с наибольшей селективностью —
тот, который сильнее всего сужает выборку.

58.

Транзакции

59.

Транзакция
Транзакция — группа операций с БД, которые выполняются как единое целое.
Если хотя бы одна операция завершилась с ошибкой — все изменения
откатываются. Если всё прошло успешно — изменения сохраняются все вместе.
Пример — перевод денег:
1.Снять 1 000 ₽ со счёта отправителя
2.Зачислить 1 000 ₽ на счёт получателя
Если шаг 2 не выполнился — шаг 1 автоматически отменяется. Деньги не исчезнут
и не задвоятся.
Основные команды:
• BEGIN — начало транзакции
• COMMIT — подтвердить и сохранить изменения
• ROLLBACK — отменить все изменения транзакции

60.

Принципы транзакций — ACID
Atomicity (Атомарность) — транзакция выполняется полностью или не
выполняется вовсе. Нельзя сохранить половину операций.
Consistency (Согласованность) — до и после транзакции данные остаются в
корректном состоянии. Никакие правила и ограничения не нарушаются.
Isolation (Изоляция) — параллельные транзакции не влияют друг на друга.
Каждая работает так, будто она единственная в системе.
Durability (Долговечность) — после успешного COMMIT данные сохраняются
навсегда, даже если система упала сразу после.
Пример — перевод денег:
Принцип
Что гарантирует
A
Либо деньги перевелись полностью, либо счета остались без изменений
C
Сумма денег на двух счетах до и после перевода одинакова
I
Другой перевод с того же счёта не повлияет на текущую операцию
D
После подтверждения перевод не исчезнет при перезагрузке сервера

61.

Масштабирование
БД

62.

Масштабирование БД
Вертикальное (Scale Up) — увеличение мощности одного сервера: больше CPU,
RAM, быстрее диски.
Горизонтальное (Scale Out) — добавление новых серверов: шардинг,
репликация, кластеризация.
Вертикальное
Горизонтальное
Суть
Мощнее один сервер
Больше серверов
Плюсы
Просто, не требует изменений в
архитектуре
Практически неограниченный рост
Минусы
Физический предел мощности, дорого
Сложнее в настройке и
администрировании
Когда
Небольшой и средний рост нагрузки
Высокие нагрузки, большие объёмы
данных
Примеры
Upgrade сервера с 32 до 128 ГБ RAM
Шардинг MongoDB, репликация
PostgreSQL

63.

Scale Out: Репликация
Репликация — копирование данных между узлами для обеспечения надёжности
и масштабирования.
Зачем нужна: обеспечивает отказоустойчивость — если один узел упал, система
продолжает работать.
Master-Slave
Master-Master
Запись
Только на Master
На любой узел
Чтение
Master или Slave
Любой узел
Сложность
Проще
Сложнее
Конфликты
Нет
Требует разрешения

64.

Scale Out: Партиционирование и
Шардинг
Партиционирование — разделение данных внутри одной БД на части (партиции)
для улучшения производительности запросов.
Шардинг — разновидность партиционирования, где данные распределяются по
разным физическим серверам (шардам).
Пример для обоих: таблица users делится по диапазону ID или по дате —
запросы обращаются только к нужной части, а не ко всей таблице.
Простая аналогия: партиционирование — разложить книги по полкам в одном
шкафу. Шардинг — распределить книги по нескольким шкафам в разных
комнатах.
Партиционирование
Шардинг
Где данные
На одном сервере
На разных серверах
Сложность
Проще
Сложнее
Масштабирование
Вертикальное
Горизонтальное
Когда
Большие таблицы, медленные запросы
Огромные объёмы, высокая нагрузка

65.

Партиционирования и Шардинга: пример
Партиционирование — таблица orders разделена по месяцам на одном сервере:
Партиция
Данные
orders_2024_01
Заказы за январь 2024
orders_2024_02
Заказы за февраль 2024
orders_2024_03
Заказы за март 2024
Запрос за февраль обращается только к
orders_2024_02, а не ко всей таблице.
Шардинг — та же таблица orders распределена по разным серверам:
Шард
Сервер
Данные
Shard 1
server-01
Заказы user_id 1 — 100 000
Shard 2
server-02
Заказы user_id 100 001 — 200 000
Shard 3
server-03
Заказы user_id 200 001 — 300 000
Запрос по user_id = 50 000
идёт только на server-01.

66.

Фоновые задачи
Фоновые задачи (Background Jobs) — задачи, которые выполняются по
расписанию или триггеру, не блокируя основной процесс.
Примеры:
• Ежедневная очистка логов
• Обработка накопленных данных в фоновом режиме
• Отправка email-рассылок, генерация отчётов
Компонент
Описание
Триггер
Что запускает задачу: время (CRON) или событие
Логика
Скрипты или функции, которые выполняют работу
Воркер
Процесс, который берёт задачу и исполняет её
Результат
Запись в БД, отправка уведомления, файл
Инструменты: Apache Airflow, Celery, CRON.

67.

Кэширование
Кэш — промежуточное хранилище быстрых данных. Вместо обращения к БД
система берёт данные из кэша.
Зачем: снизить нагрузку на БД и ускорить ответ системы.
Инструмент
Тип
Когда использовать
Redis
In-memory, ключ-значение
Сессии, счётчики, очереди, кэш
запросов
Memcached
In-memory, ключ-значение
Простой кэш без сложной логики
Типичные сценарии кэширования:
• Результаты тяжёлых SQL-запросов
• Данные справочников, которые редко меняются
• Сессии пользователей
• Счётчики и рейтинги
Проблема инвалидации: если данные в БД изменились, кэш нужно обновить
или сбросить — иначе пользователь увидит устаревшие данные.

68.

Стили
наименования

69.

Стили наименования
Стиль
Пример
Где используется
camelCase
middleName,
numberOfItems
Переменные и методы в
Java, JavaScript
PascalCase
MiddleName,
NumberOfItems
Классы, компоненты, типы
snake_case
middle_name,
number_of_items
Столбцы и таблицы в БД,
Python
UPPER_SNAKE_CASE
MAX_VALUE,
DEFAULT_TIMEOUT
Константы
kebab-case
middle-name, number-ofitems
URL, CSS-классы, HTMLатрибуты

70.

Правила наименования
Правило
Правильно
Неправильно
Стиль — snake_case
order_items
orderItems, OrderItems
Язык — только
английский
created_at
дата_создания
Таблицы —
множественное число
users, orders
user, order
Без повтора имени
таблицы
users.name
users.user_name
Даты — стандартные
суффиксы
created_at, updated_at,
deleted_at
date_create,
change_date
Первичный ключ
id
user_id, userId
Внешний ключ —
отражает связь
user_id, product_id
fk1, ref_id

71.

Структура SQL-запроса
Синтаксис (порядок написания)
Порядок выполнения (как читает СУБД)
SELECT [столбцы]
FROM [таблица]
JOIN [таблица] ON [условие]
WHERE [условие]
GROUP BY [столбцы]
HAVING [условие]
ORDER BY [столбцы]
LIMIT [количество];
FROM, JOIN
WHERE
GROUP BY
HAVING
SELECT
DISTINCT
ORDER BY
LIMIT/OFFSET
Важно: порядок написания и порядок выполнения — разные вещи. WHERE
выполняется раньше SELECT, поэтому нельзя использовать алиасы из SELECT в
WHERE.

72.

План выполнения запроса
План выполнения запроса (Query Plan) — инструкция, по которой СУБД
выполняет SQL-запрос: как ищет, сортирует, объединяет и фильтрует данные.
Помогает находить узкие места и оптимизировать производительность.
Что показывает:
• Какие индексы используются
• Как выполняются JOIN между таблицами
• Где происходит фильтрация WHERE
• Как работает сортировка и группировка
• Где СУБД делает полный перебор таблицы (Full Table Scan) — сигнал проблемы
СУБД
Команда
PostgreSQL
EXPLAIN ANALYZE SELECT ...
MySQL
EXPLAIN SELECT ...
MS SQL
SET STATISTICS IO ON или кнопка «Execution Plan» в SSMS
Когда использовать: если запрос выполняется медленно — первым делом
смотри план выполнения.

73.

DDL, DML, DCL, TCL
Группа Расшифровка
Команды
Описание
DDL
Data Definition Language
CREATE, ALTER, DROP,
TRUNCATE
Создание и
изменение
структуры БД
DML
Data Manipulation Language
SELECT, INSERT,
UPDATE, DELETE
Работа с
данными
DCL
Data Control Language
GRANT, REVOKE
Управление
правами
доступа
TCL
Transaction Control Language
BEGIN, COMMIT,
ROLLBACK
Управление
транзакциями

74.

Основные команды SQL
-- Выборка данных
SELECT name, email FROM users WHERE status = 'active’;
-- Вставка
INSERT INTO users (name, email) VALUES ('Иванов', 'ivanov@mail.ru’);
-- Обновление
UPDATE users SET status = 'inactive' WHERE id = 5;
-- Удаление
DELETE FROM users WHERE id = 5;
-- Создание таблицы
CREATE TABLE users ( id SERIAL PRIMARY KEY, name VARCHAR(100) NOT NULL, email VARCHAR(100)
UNIQUE );
-- Изменение таблицы
ALTER TABLE users ADD COLUMN phone VARCHAR(20);
-- Удаление таблицы
DROP TABLE users;

75.

JOIN
JOIN — объединение строк из двух таблиц по условию связи.
Тип
Описание
Когда использовать
INNER JOIN
Только совпадающие строки из обеих Нужны только связанные
таблиц
записи
LEFT JOIN
Все строки левой таблицы +
совпадения из правой (NULL если
нет)
Нужны все записи левой,
даже без связи
RIGHT JOIN
Все строки правой таблицы +
совпадения из левой
Нужны все записи правой,
даже без связи
FULL OUTER JOIN
Все строки из обеих таблиц, NULL где Нужны все записи из обеих
нет совпадений
таблиц
CROSS JOIN
Декартово произведение — каждая
строка с каждой
Комбинации всех записей

76.

Агрегатные функции
Агрегатные функции вычисляют одно значение на основе набора строк.
Функция
Описание
Пример
COUNT
Количество строк
COUNT(*) — все строки, COUNT(field) — без NULL
SUM
Сумма значений
SUM(amount) — итоговая сумма заказов
AVG
Среднее значение
AVG(price) — средняя цена
MIN
Минимальное значение
MIN(created_at) — самый ранний заказ
MAX
Максимальное значение
MAX(salary) — максимальная зарплата
Правило: всё, что не в агрегатной функции, должно быть в GROUP BY.

77.

Подзапросы
Подзапрос — SELECT внутри другого SQL-запроса.
Типы подзапросов:
• Скалярный – возвращает одно значение
• Строчный – возвращает одну строку
• Табличный – возвращает набор строк, используется в FROM или IN
• Коррелированный – ссылается на внешний запрос, выполняется для каждой
строки
Когда использовать: когда результат одного запроса нужен как условие для
другого. При высоких нагрузках предпочтительнее JOIN — он обычно быстрее.

78.

Практическое задание
по написанию SQL-запроса
Вывести название товаров и количество отзывов, если у
товара есть как минимум 3 отзыва.

79.

Вопросы, которые спросят
Базы данных и модели данных
• Какие типы БД вы знаете?
• Чем реляционные БД отличаются от нереляционных?
• Когда выберете SQL, а когда NoSQL?
• Какие типы данных в БД знаете?
• Чем CHAR отличается от VARCHAR?
• Когда использовать TEXT?
• Что такое массив и его свойства?
• Что такое сущность?
• Что такое атрибут?
• Что такое ER-диаграмма?
• Для чего нужна ER-диаграмма?
• Какие элементы ER-диаграммы вы знаете?
• Какие бывают связи между сущностями?
• Как строится связь один-ко-многим?
• Как реализуется связь многие-ко-многим?
• Что такое Primary Key?
• Какие характеристики у Primary Key?

80.

Вопросы, которые спросят
Что такое Foreign Key?
Какие ограничения можно накладывать в БД?
Что такое и зачем нужна нормализация?
Что такое денормализация и зачем она нужна?
Что такое индекс?
Какие бывают индексы?
Плюсы и минусы индексов?
Что такое составной индекс?
Что такое транзакция?
Что такое ACID?
Какие способы масштабирования БД знаете?
Что такое репликация?
Какие типы репликации знаете?
Что такое партиционирование?
Что такое шардинг?

81.

Практические кейсы
Как получить список уникальных имён и отсортировать по убыванию?
Нарисуйте ER-диаграмму интернет-магазина книг.
Нарисуйте ER-диаграмму табло соревнований.
Опишите конкретный пример артефактов, которые вы готовите по БД.
Покажите, как согласовываете модель данных с разработчиком или
архитектором.