Денормализация базы данных

Как уже было сказано, в процессе проектирования БД мы стараемся добиться того, чтобы все отношения находились в максимально возможной нормальной форме. Если мы проектируем при помощи последовательной нормализации, мы достигаем этого в явном виде, если мы используем подход «сущность-связь», мы достигаем этого опосредованно. Выше отмечалось, что при аккуратном использовании этого подхода полученные таблицы будут находиться, как минимум, в 3НФ.

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

Поэтому, очень часто после нормализации структуры БД следует ее денормализация – мы сознательно нарушаем требования нормализации для достижения большей производительности. Да, в этом случае мы можем столкнуться с аномалиями, да, размер БД может вырасти за счет дублирования, но мы сможем формулировать более простые запросы, которые будут быстрее выполняться.

Иногда такие оптимизации нельзя сделать на пустой базе данных, и требуется некоторое время реального использования, чтобы выявить узкие места и наметить возможные оптимизации. Как следствие, давать рекомендации по денормализации «вообще» не представляется возможным, поэтому, мы ограничимся тем, что отметим ее, как возможный этап развития базы данных.

Контрольные вопросы.

1. Опишите основные подходы к проектированию баз данных.

2. Дайте понятие нормализации.

3. Перечислите аномалии, возникающие в ненормализованной БД.

4. Перечислите существующие нормальные формы.

5. Опишите этапы создания базы данных через моделирование.

6. Дайте основные понятия метода «сущность-связь».

7. Поясните необходимость денормализации базы данных.