Легко понять, почему эти повторяющиеся поля создадут проблемы. Одна из них касается реального количества полей Committee в таблице. Что если несколько сотрудников будут участниками четырех комитетов? Или более? Тогда потребуется добавить еще несколько полей Committee к таблице.

Другая проблема касается извлечения информации из таблицы. Как извлечь информацию о тех сотрудниках, которые в настоящее время принимают участие в работе комитета по решению проблемы 2000 года (Y2K Conformance)? Это не невозможно, но при извлечении такой информации возникнут затруднения. Потребуется выполнить три отдельных запроса для получения правильного ответа, поскольку нельзя быть точно уверенным, в каком из трех полей Committee сохранено значение Y2K Conformance. Таким образом, будет затрачено больше времени и усилий, чем необходимо в действительности.

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

Если вы тщательно изучите таблицу Employees на рис. 2.9, то поймете, что между сотрудниками и комитетами, участниками которых они являются, существует связь многие-ко-многим. Отдельный сотрудник может быть участником любого количества комитетов, а отдельный комитет может состоять из любого количества сотрудников. Поэтому эти дубликаты полей можно устранить тем же способом, который использовался для разрешения любых других связей многие-ко-многим,- путем создания связывающей таблицы. В случае таблицы Employees создайте связывающую таблицу с помощью копии первичного ключа (EmployeelD) и единственного поля Committee. Присвойте новой таблице соответствующее имя, например Committee Members (Члены комитета), определите оба поля EmployeelD и Committee как составной первичный ключ, удалите поля Committee из таблицы Employees - и все сделано. На рис. 2.10 представлена исправленная таблица Employees и новая таблица Committee Members.

Emptoyees

гЦИ,1..1.1

Рис. 2.10. Исправленная таблица Employees

и новая таблица Сommittee Members

Committee Members

7009

Y2K Confbrnr ance

Хотя мы устранили ;!1убликаты полей, которые были в исходной таблице Employees, еще не все закончено. Принимая во внимание, что сотрудники и комитеты, в которых они работают, связаны между собой как многиеко-многим, вполне можно задать вопрос: А где же таблица Committees? Пока еще ее нет! По счастью, у комитетов имеются некоторые другие характеристики, которые необходимо записать, например название комнаты, где собирается комитет, и день месяца, в который проводятся собрания. Поэтому следует создать реальную таблицу Committees, которая включает такие поля, как CommitteelD, CommitteeName, MeetingRoom и MeetingDay. Закончив создание новой таблицы, замените поле Committee в таблице Committee Members на поле CommitteelD из новой таблицы Committees. Окончательные структуры представлены на рис. 2.11.

Определив такую структуру таблиц, вы сделали большое дело, потому что теперь отдельному сотруднику можно поставить в соответствие любое количество комитетов или отдельному комитету - любое количество сотрудников. Затем можно использовать запрос SQL для одновременного просмотра информации из всех трех таблиц.

Employees

CommitteeMembers

Committees

Рис. 2.11. Окончательные структуры таблиц Employees и Committees

В данный момент процесс тонкой настройки структур таблиц близок к зав )ше-нию. Осталось только убедиться, что каждую запись в пределах таблицы д жгJ идентифицировать уникальным образом и что саму таблицу можно идентифи] вать во всей базе данных.

Идентификация - это ключ

Первичный ключ является одним из наиболее важных ключей в таблице, потому что он уникальным образом идентифицирует каждую запись в таблице и формально определяет эту таблицу во всей базе данных. Он также устанавливает связь между парой таблиц. Невозможно переоценить важность первичного ключа - каждая таблица базы данных должна его содержать!

По определению первичный ключ является полем или группой полей, которые однозначно идентифицируют каждую запись в таблице. Первичный ключ называется простым первичным ключом (или просто первичным ключом), когда он состоит из одного поля, и составным первичным ключом, когда состоит из двух или более полей. По возможности определяйте простой первичный ключ, поскольку он более эффективен и его намного легче применять при создании связи. Используйте составной первичный ключ, только когда это уместно (например, для определения и создания связывающей таблицы).

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

Идентифицирует ли данное поле однозначным образом каоюдую запись в таблице? Каждая запись в таблице представляет собой экземпляр предмета таблицы. Хороший первичный ключ гарантирует, что можно однозначно выделить любую запись в этой таблице или обратиться к ней из других таблиц в базе данных. Он также помогает избегать наличия в таблице дубликатов записей.

Уникальны ли значения ключа? Пока значения первичного ключа не повторяются, записи в таблице не будут дублироваться.

Может ли это поле в принципе содержать неизвестные значения? Это очень важно, потому что первичный ключ не должен содержать неизвестные значения. Если у этого поля есть даже малейшая возможность содержать неизвестные значения, его следует признать непригодным.

Может ли значение этого поля когда-либо быть необязательным? Если да, то использовать это поле в качестве первичного ключа нельзя. Если значение поля может быть необязательным, значит оно в некотором случае может быть неизвестным, а первичный ключ не может содержать неизвестные значения.