Вокруг нормализации постоянно ведутся споры: кто-то считает ее чуть ли не “священным Граалем”, а кто-то — средством, которое наносит ущерб производительности. Что же такого в нормализации, что заставляет людей так по-разному к ней относиться?
По идее, достаточно разместить все данные где-то в таблице, и при наличии способности написать SQL-код для извлечения требуемой информации, а также хорошей РСУБД, функционирующей на машине с быстрыми процессорами, база данных не должна работать медленно. По правде сказать, плохо спроектированные связи и таблицы в базе данных могут иметь серьезные последствия, причем не только для производительности базы данных, но и для действительности самих данных.
Давайте рассмотрим пример системы обработки заказов в хранилище данных. Предположим, что имеется простая таблица, в которой информация о каждом заказчике размещается внутри одного кортежа или строки. Что произойдет в случае проведения для заказчика A около 1000 транзакций, а для заказчика B — только одной или двух? Либо транзакции заказчика A не будут помещаться все в одной строке, либо строка заказчика B будет почти пустой. То есть либо не будет получаться угодить потребностям заказчика, либо огромное количество места в базе данных будет простаивать зря.
С такой моделью простые запросы будут приводить к напрасной трате ресурсов. Можно попробовать видоизменить предыдущую модель, создав гораздо более компактную таблицу за счет разрешения повторения значений атрибутов. Тогда при каждой транзакции вся информация о каждом заказчике будет повторяться.
Это приведет лишь к замене предыдущих проблем новыми. В частности, при возникновении необходимости изменить информацию заказчика A обновлять придется каждую из строк этого заказчика в таблице. В таких повторяющихся группах при выполнении обновления требуется удостоверяться в обновлении абсолютно всех вхождений данных конкретного заказчика, иначе может появиться несогласованный набор данных.
Надеюсь данная заметка будет полезной для начинающих и действующих разработчиков приложений под базы данных Oracle.
