Análisis de datos - DA SQL

Нормализация в базах данных Нормализация в базах данных — это организация данных в таблицах для уменьшения избыточности и улучшения целостности данных. 🟠Есть несколько форм нормализации: ▶️Первая форма нормализации: Все атрибуты должны быть атомарными: то есть каждое поле должно содержать только одно значение (не должно быть списков, множеств или составных данных). Например, есть таблица с клиентам. И если у клиента есть несколько номеров телефона, то, согласно 1НФ, будет неправильно хранить их все в одном поле и в одной строке (условно через запятую). Разделить их можно несколькими способами: - создавать столбцы "телефон 1", "телефон 2", "телефон 3" и т.д., но это тоже будет неправильно, т.к. такая таблица будет очень неудобной и всё так же будет нарушать 1НФ - а именно иметь повторяющиеся группы столбцов. - создавать под каждый номер телефона отдельную строку в таблице с клиентами. Это будет соответствовать 1НФ, но глобально всё еще будет далеко от идеала, т.к. при таком подходе будем иметь большое количество повторяющихся строк, которые будут отличаться между собой только лишь номером телефона. - и самый оптимальный вариант - создать отдельную таблицу с номерами телефонов и связать ее с основной с помощью client_id (это решение будет соответствовать 2НФ, но об этом дальше). Что касаемо составных данных в 1НФ, то будет неправильно хранить в одном столбце и в одной строке, например, информацию о товаре: "Такой-то товар такого-то цвета таких-то размеров произведенный кем-то". Для этого нужно будет выделить отдельные столбцы "Наименование", "Цвет", "Размер", "Производитель", чтобы это всё соответствовало 1НФ. Помимо всего прочего, в таблице еще не должно быть и повторяющихся строк - для этого создаются первичные ключи. ▶️Вторая форма нормализации: Таблица должна быть в 1НФ. Все неключевые атрибуты должны зависеть от всего первичного ключа. Делается это для того, обновлять данные было удобнее, быстрее и чтобы избежать ошибок. Возвращаясь к примеру с клиентами. Почему разбивка номеров телефонов на отдельные строки в рамках 1 таблицы соответствует 1НФ, а разбивка номеров телефонов и клиентов на 2 разные таблицы соответствует 2НФ? Потому что в 1 случае уникальность строки зависит не от client_id (помним про дубликаты), а от client_id + номер телефона. Из-за этого могут возникать такие ситуации, когда одни записи в таблице будут зависеть от client_id (например, ФИО), а другие от номера телефона (например, оператор). И как раз для устранения таких проблем с идентификацией используется 2 случай с разбивкой на разные таблицы, чтобы все записи в одной таблице соответствовали одному id. ▶️Третья форма нормализации: Таблица должна быть в 2НФ. Неключевые атрибуты не должны зависеть от других неключевых атрибутов. Например, в таблице с клиентами есть еще атрибуты "Город" и "Регион". Такая таблица не будет соответствовать 3НФ, если значение региона будет зависеть от города, т.к. оба этих атрибута - неключевые. Встает вопрос опять же про обновление данных - в случае, если изменится логика определения региона в зависимости от города, то будет проблематично обновлять данные по всей таблице. Для того, чтобы структура соответствовала 3НФ, нужно "Город" и "Регион" вынести в отдельную таблицу, чтобы "Регион" зависел от ключевого значения "Город". 🟠Обычно на практике останавливаются на 3НФ, остальные формы идут уже для специфических ситуаций. Бывают еще случаи, когда намеренно используется денормализация. Допускают такое, как правило, для повышения производительности запросов, т.к. степень нормализации тесно связана с тем, как много джоинов потом будет написано. Говоря об остальных НФ, чаще всего выделяют еще: ▶️Нормальную форму Бойса-Кодда (BCNF). Применяется, если при PK = (атрибут 1; атрибут 2) некоторые атрибуты зависят только либо от атр.1, либо от атр.2. ▶️Четвертую форму. Применяется, когда от PK зависит атр.1 и атр.2, но при этом, имея зависимость от одного PK, нет зависимости между атр.1 и атр.2. ▶️Пятую форму. Применяется, когда данные корректны только при соединении 3+ таблиц.