Избыточность в таблицах базах данных
На практике при работе с базами данных, которые проектировали не профессиональные разработчики, а обычные пользователи, часто можно столкнуться с таблицами вида:
Конечно же, такая структура отношений является неоптимальной по многим причинам:
1) данные в таблице являются избыточными. Например, адрес одной и той же фирмы повторяется несколько раз. Если таблица будет большой, то из-за избыточных данных нам потребуется много места на хранение, а производительность работы с таблицей упадет
2) очень легко ошибиться, указав разный адрес (или адрес по-разному для одной и той же фирмы)
3) при изменении, к примеру, адреса для фирмы нам потребуется этот адрес поменять во всех записях для данной фирмы
Кроме того, проблема с нашей таблицей заключается в том, что разнородные данные в столбце «Конт. лица» слиты в единое целое. Один из принципов работы с базами данных заключается в том, что обычно очень просто свести в результате запроса вместе данные из разных столбцов, и очень сложно - произвести дальнейшую детализацию, то есть выделить, к примеру, из последнего столбца телефон.
Прежде чем говорить о том, как именно решать рассмотренные проблемы, то есть нормализовать данные, необходимо рассказать о нескольких принципах, которые лежат в основе нормализации.
Первый принцип - декомпозиция без потерь. Это значит, что после разбиения ненормализованной таблицы на несколько более мелких ее можно при желании объединить обратно без потери данных. Такое объединение обычно производится, конечно, не на уровне самой базы данных, а на уровне запросов.
Второй принцип - каждый кортеж (запись в таблице) должен быть уникален, то есть у нас должна быть возможность как-то отличать одну запись от другой. То есть каждая запись должна содержать в себе метку, которая уникально отличает ее от остальных записей. Такая метка называется ключом. Можно дать и более формальное определение ключа: ключ - это набор столбцов таблицы, значения которых уникально определяют строку.
Как выяснить, что в нашей таблице может быть ключом? Казалось бы, ответ прост - достаточно просто выполнить запрос к таблице и посмотреть, значения каких столбцов (или наборов столбцов) являются уникальными. Однако на практике все намного сложнее за счет того, что набор записей в таблице постоянно изменяется, и в нем могут появиться нарушающие значения.
Например, мы занимаемся автоматизацией работы очень маленькой фирмы, в которой всего три сотрудника - Иванов, Петров и Сидоров. Можно сделать ключом просто фамилию, но в этой ситуации мы столкнемся с проблемами, если фирма расширится и на работу придет однофамилец имеющегося сотрудника. Расширение ключа на еще два столбца - с именами и отчествами - также решение проблемы не является по причине того, что в итоге вполне может появиться полный тезка и однофамилец. Кроме того, если, к примеру, сотрудница сменит фамилию, то опять-таки могут возникнуть проблемы - она будет выглядеть для базы данных как новый сотрудник.
В теории задачу нужно решать правильным выбором набора столбцов (составной или композитный ключ), но практике обычно в таблице создается специальное поле, которое уникально идентифицирует данную запись (простой или атомарный ключ). Такое решение обладает рядом преимуществ с точки зрения производительности и хранения данных.