Убедитесь, что в каждой таблице имеется первичный ключ. Первичный ключ необходимо назначить каждой таблице по двум причинам Во-первых, он однозначно идентифицирует каждую запись в таблице, а во-вторых, он используется для связывания таблиц. Если не назначить первичный ключ каждой таблице, в конце концов возникнут проблемы целостности данных и проблемы в некоторых типах запросов SQL к нескольким таблицам. Позже мы дадим несколько советов о том, как определить надлежащий первичный ключ. (Современные СУРБД, в частности Access 2000, просто не дадут определить таблицу без первичного ключа.- Прим. пер.)

Убедитесь в том, что таблица не codepoicum каких-либо составных или многозначных полей. Теоретически эти вопросы следует решить во время уточнения структуры полей. Тем не менее будет нелишним проверить поля в последний раз и убедиться, что все и каждое из них полностью удалены.

Убедитесь в том, что в таблице отсутствуют вычисляемые поля. Даже если вы уверены, что текущие структуры таблиц не содержат вычисляемых полей, стоит просмотреть некоторые из них во время процесса уточнения полей. В этот момент следует еще раз просмотреть структуры таблиц и удалить все вычисляемые поля, которые, возможно, были пропущены.

Убедитесь в том, что поля в таблицах не дублируются. Одним из признаков плохо спроектированной таблицы является включение дублирующих полей из других таблиц. Возможно, добавить дублирующие поля в таблицу вас вынудило желание добавить справочную информацию или обрзначить таким образом многократные появления значения определенного типа. Такие дублирующие поля вызывают различные сложности при работе с данными и при попытке извлечь информацию из таблицы. Рассмотрим, как справиться с повторяющимися полями.

Устронение дублирующих полей

Возможно, самой трудной частью усовершенствования структуры является устранение дублирующих полей. Ниже приведено несколько примеров, которые демонстрируют, как следует поступать с таблицами, содержащими дублирующие поля.

На рис. 2.7 представлен пример таблицы, содержащей повторяющиеся поля - якобы для справки .

В данном случае поля StaffLastName и StaffFirstName появляются в таблице Classes для того, чтобы при просмотре таблицы можно было видеть имя преподавателя данного класса. Однако эти поля излишни вследствие связи один-ко-многим, которая существует между таблицами Classes и Staff (один преподаватель может

Staff

Ii i jritittewiJiiiriiitiiiiifiii-iiiii

Leverlirg

722 Moss Bay Blvd.

Callahan

Buchanan

Smith

901 Pine Avenue

13920 $£. 40th Street

30301 166th Ave. N.E.

Kirkland

Portland

Bellevue

>!И. ,1Ш>,М<М,>,уМГ.;1

4 I-

Seattle

1 - iiitiiKaTiiTiiim-[i4i>-ti-iiit-inbitti* .мям й ми ММ

98022

Janet

ieverling

722 Moss Bay Blvd.

Kirkland

98023 ! Aiaina

I Hallmark I Route 2. Box 203 В Woodinville WA

в

a

*!Л ;<l>w.<<.Wr<wwиwfr.№w.:w.;<;-

Classes

Эти поля не нужны

98014

Leverling

98014 i Leverling

98021 (Smith

James James

98019

Callahan

Hallmark

98020 i Buchanan

98022 I Leverling

Laura

Aiaina

Albert

Janet

Рис. 2.7. Таблица с дублирующими полями

вести любое количество предметов, но каждый конкретный предмет может вести только один преподаватель). Связь моеду этими таблицами устанавливает поле StaffID, и само наличие этой связи позволяет одновременно просматривать данные из обеих таблиц в запросе SQL. Учитывая это, можно без опаски удалить поля StaffLastName и StaffFirstName из таблицы Classes, не вызвав каких-либо отрицательных воздействий. На рис. 2.8 представлена исправленная структура таблицы Classes.

Сохранение лишних полей в таблице автоматически вызывает значительные проблемы, связанные с противоречивостью данных. Необходимо гарантировать, что значения полей StaffLastName и StaffFirstName в таблице Classes всегда соответствуют их копиям в таблице Staff. Допустим, женщина-преподаватель выходит замуж и меняет свою фамилию на фамилию мужа. Необходимо быть уверенным не только в том, что соответствующие изменения в ее записи сделаны в таблице Staff, но также гарантировать, что изменены все записи с ее именем в таблице Classes. Конечно, это можно сделать (по крайней мере технически), но придется потрудиться больше, чем необходимо. Помимо этого, одна из главных предпосылок использования реляционной БД состоит в том, что все данные встречаются во всей базе данных только один

Staff

Nam-

Classes

Рис. 2.8. Устранение дублирующих полей

раз (единственным исключением из этого правила является установка связи ме>кду таблицами). Как всегда, лучше всего удалить из таблиц базы данных все дублирующие поля.

Другой пример таблицы, содержащей дубликаты полей, представлен на рис. 2.9. Он показывает, как дубликаты полей ошибочно используются для обозначения того, что значение встречается несколько раз. В этом случае три поля Committee (Комитет) используются якобы для записи названий комитетов, в которых принимает участие сотрудник.

Employees

Рис. 2.9.

Таблица с дубликатами полей, используемых для обозначения того, что значение встречается несколько раз