Нормальные формы

Сегодня разберем, что такое НФ-ки в бд и как они помогают улучшить структуру таблиц.

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

Чаще всего в практических приложениях используются до 3NF или BCNF. Это объясняется рядом причин:

1NF:
• Используется всегда, как базовый стандарт.
• Все данные должны быть атомарными.
• На практике 1NF чаще всего соблюдается по умолчанию.

2NF:
• Применяется, когда таблица имеет составные ключи.
• На практике встречается в системах, где есть сложные связи, например:
Расписание (курс, аудитория, преподаватель).
Заказы (номер заказа, товар, количество).

3NF:
• Самая популярная форма в реальных базах данных.
• Устраняет транзитивные зависимости и считается золотым стандартом в реляционном проектировании.
• Используется в большинстве OLTP-систем (оперативных бд), где важны целостность данных и минимизация избыточности.

BCNF (Форма Бойса-Кодда):
Применяется реже, чем 3NF, но встречается в системах с более сложными зависимостями между атрибутами.

4NF и 5NF:
Используются в специфических случаях:
• При работе с многозначными зависимостями.
• Для устранения зависимостей объединения в больших проектах, где требуется высокое разделение данных.
• Обычно применяются в научных базах данных или хранилищах.

6NF:
• Практически не встречается в классических базах данных.
• Используется в временных базах данных (temporal databases), где важно отслеживать изменения данных с течением времени.

Почему 3NF используется чаще всего?
Она достигает баланса между:
• Устранением избыточности.
• Удобством использования данных.
• Простотой исполнения SQL-запросов.

После 3NF нормализация (например, до BCNF или 4NF) может привести к излишнему разбиению таблиц, что усложнит работу и увеличит количество JOIN-запросов.

Задачки с собесов ч.1

Пора выкладывать мои задачи с собеседований, а раз собесов было больше 45 в свое время, то и задач у меня достаточно. Часть успел поскринить, часть нет.

Я тут пока эксперементирую с форматами, немного деталей

• Буду прикладывать сразу несколько задачек из пула [ intern | junior | middle | senior ] чтобы всем было интересно
• Визуальная часть остается - смотрим глазками
• Прикрепляю файлы маркдаун, внутри тоже самое + код для создания таблиц
• Также прикрепляю решение в маркдауне
• Задачки актуальные и по сей день, поэтому смотрим

- Люди не связанные с айти - делаем умный вид (я так часто делаю)
- Супер новички - сохраняем, разбираем, развиваем насмотренность. Задаем вопросы - здесь никто не кусается, комьюнити расчитано на разные уровни
- Джуны - активно штурмуем
- Миддлы и выше - практикуемся, удивляемся, что не смогли решить

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

Топ 5 вопросов по SQL ч.1

Что чаще всего спрашивают на собесах? Да вот самую базу и спрашивают на самом деле

1. Чем отличаются WHERE и HAVING?

2. Различия обычного подзапроса и коррелированного подзапроса?

3. Что такое индексы и зачем они нужны?

4. Различия UNION, UNION ALL?

5. Что есть нормализация и денормализация базы данных?

Сначала пытаемся ответить сами, потом сверяемся с моими ответами

План выполнения запроса ч. 1
(Не путаем с порядком выполнения операторов)

Если коротко - это пошаговое описание того, как база данных выполняет SQL-запрос.

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

Что показывает?

1. Какие таблицы будут задействованы.
2. Какие индексы будут использоваться.
3. Как будут объединяться данные (JOIN).
4. Сортировки и фильтрации.
5. Какие операции наиболее затратны.

СУБД создает этот план на основе своего оптимизатора запросов, чтобы найти наиболее эффективный способ выполнения.

Почему это важно?

1. Оптимизация производительности
План помогает выявить узкие места (например, дорогостоящие и болючие операции вроде Full Table Scan).

2. Устранение проблем
Например, можно обнаружить, что запрос не использует индекс, даже если он создан.

3. Экономия ресурсов
План позволяет понять, как можно снизить нагрузку на процессор и диск.

(продолжение следует...)

План выполнения запроса ч.2

Давайте разберем эту историю на примере базового запроса

SELECT * FROM orders
WHERE order_date = '2024-01-01';

Если выполнить команду EXPLAIN (в PostgreSQL, MySQL, Oracle и других СУБД), мы получим что-то вроде:

Seq Scan on orders  (cost=0.00..35.50 rows=5 width=100)
  Filter: (order_date = '2024-01-01')

Seq Scan (Sequential Scan): База данных просканирует всю таблицу orders. Это неэффективно для больших таблиц.
• Cost: Оценка стоимости операции — чем выше, тем сложнее запрос.
• Rows: Оценка количества строк, которые вернёт запрос.
• Filter: Какой фильтр применён.

Если бы был индекс на order_date, запрос мог бы использовать Index Scan вместо полного сканирования таблицы.

Как интерпретировать план выполнения?

1. Типы сканирования:
• Seq Scan: Последовательное сканирование таблицы. Медленно на больших таблицах.
• Index Scan: Использует индекс, значительно быстрее для фильтров.
• Bitmap Index Scan: Сканирование индекса для поиска подходящих строк, объединяя их в блоки.

2. Объединение данных (JOIN):
• Nested Loop: Перебирает каждую строку одной таблицы и ищет совпадения в другой (подходит для небольших наборов данных).
• Hash Join: Создаёт хэш-таблицу из одной таблицы, затем ищет совпадения. Быстро для больших таблиц.
• Merge Join: Сортирует обе таблицы и объединяет их по порядку. Эффективно для уже отсортированных данных.

3. Операции сортировки:
• Sort: Указывает, что данные сортируются, что может быть дорогостоящей операцией.

4. Оценка стоимости:
• Общая стоимость включает чтение данных с диска, использование памяти и процессора.

Как сделать запросы эффективнее?

1. Используйте индексы.
• Создайте индексы на столбцах, которые часто участвуют в фильтрации, сортировке или JOIN.

CREATE INDEX idx_order_date ON orders(order_date);

2. Пишите запросы проще.
• Разделяйте сложные запросы на несколько шагов.
3. Не выбирайте лишние данные.
• Вместо SELECT * выбирайте конкретные столбцы:

SELECT order_id, order_date FROM orders;

4. Изучайте план выполнения.
• Перед оптимизацией всегда анализируйте, какие операции занимают больше всего ресурсов.

Интересные моменты из реальной практики

1. Проблема с JOIN
В одной из задач JOIN двух больших таблиц занимал часы. После анализа плана выполнения понял, что надо прикрутить индексы. После их добавления запрос стал выполняться пару минут.

2. Over-indexing
Слишком много индексов может замедлить операции INSERT и UPDATE. Анализ плана выполнения помогает понять, какие из них реально используются.

Важный поинт 1
Оптимизатор не всегда прав. Иногда оптимизатор выбирает неэффективный план. В таких случаях можно использовать хинты для принудительного выбора

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

Обычно запросы не супер большие, либо под них есть удобные таблицы. И даже если вы не оптимизированно напишите запрос он будет крутиться ну пусть 10 минут вместо каких-нибудь 3. (Опять же ситуации разные могут быть)