Правило 4. Избегайте дублирования данных

Когда вы начинаете заполнять таблицу полями, иногда возникает желание включить в нее несвязанную информацию. Такое включение создает нескончаемые проблемы и в подобную ловушку попасть на удивление легко. На рис. 2.22 показана эта проблема в действии на примере таблицы, пытающейся делать лишнюю работу.

Дублирование данных, подобное показанному на рис 2.22, неэффективно. Легко вообра­зить таблицу с сотнями похожих записей, бесполезно расходующих дисковое пространство и повторяющих одни и те же значения снова и снова. Но эта неприятность — мелочь, по сравнению с затратами на обновление подобной информации и возможностью возникнове­ния противоречивости данных. Что произойдет, если вы на основании новых научных дан­ных решите изменить сведения о средней продолжительности жизни слона? В соответствии с имеющимся проектом таблицы вам нужно изменить все записи с одними и теми же данными.

Еще хуже то, что очень легко внести изменения в одни записи и оставить нетронуты­ми другие. Окончательный итог — противоречивые данные — несогласованная информация и нескольких местах таблицы — что делает невозможным извлечение корректных данных.

Рис. 2.22. Данная таблица содержит список имеющихся в наличии домашних питомцев у человека, занимающегося разведением редких животных. В ней также приведена некоторая полезная информация о средней продолжительности жизни, характере и пищевых предпочтениях каждого вида животных. Сначала такой проект кажется вполне разумным. Но проблема возникает, как только у вас появляется несколько животных одного вида (в данном случае три слона). Теперь все касающиеся слонов подробности повторяются три раза

Проблема возникает, потому что не вся информация в таблице Pets (домашние живот­ные) связана между собой. Для того чтобы понять — почему, нужно погрузиться поглубже в анализ БД.

Как правило, таблица в БД хранит один объект. В таблице Pets — это домашние питом­цы. Каждое поле в таблице — это порция данных об этом объекте.

Рис. 2.23. Теперь относящаяся к животным информация хранится в одном месте, без дублирования. Потребуется чуть-чуть больше времени для получения всей необходимой вам информации о животном — например, для того чтобы выяснить продолжительность жизни Беатрис, вам придется проверить запись Elephant (слон) в таблице AnimalTypes,но в итоге проект стал более логичным

В таблице Pets все поля, такие как Name (имя), Animal (вид животного) и Weight (вес), имеют смысл. Они описывают конкретную особь. Поля же LifeSpan (продолжительность жизни), Temperament (характер) и Diet (рацион) не совсем уместны. Они не описывают

конкретного домашнего питомца. В них содержатся стандарты для животных этого вида. Другими словами, эти поля основываются не на вашем животном (как должны были бы) — они основываются на биологическом виде животного. Единственный способ решения про­блемы — создание двух таблиц: Pets и AnimalTypes(виды животных) (рис. 2.23).

Нужен опыт для поиска полей, не связанных с другими полями. В некоторых случаях дробление таблицы на все более мелкие части не стоит затраченных усилий. Теоретически вы можете извлечь информацию об адресе (содержащую такие поля, как Street, City, Country, PostalCode) из таблицы Customers и поместить ее в таблицу Addresses (адреса). Но два клиента проживают по одному адресу довольно редко, поэтому эта дополнительная работа вряд ли окупится. Мы рассмотрим способы определения связей между таблицами, такими как Pets и AnimalTypes, в главе 5.

Совет

Многие специалисты по проектированию БД считают лучшим методом планирования БД — применение учетных карточек (index cards). Для этого запишите все различные типы информа­ции, необходимые для вашей БД. Затем отложите учетную карточку для каждой таблицы, ко­торую планируете использовать. Наконец, возьмите поля из черновика и записывайте их по очереди на соответствующую учетную карточку до тех пор, пока они не разделятся на четкие связанные группы.