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

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

С помощью этих связанных полей можно начать с записи в одной таблице и затем найти связанную информацию в другой таблице. Далее объясняется принцип действия.

■ Начиная с таблицы Dolls,выберите куклу, которая вас интересует (скажем, Yoda (Йода)). Вы получите дополнительную информацию о производителе куклы Yoda, найдя название компании "MagicPlastic" в таблице Manufacturers.

■ Начиная с таблицы Manufacturers,выберите изготовителя (скажем, компания Rebobblicans). Вы можете найти все изделия этого производителя с помощью поиска названия "Rebobblicans" в таблице Dolls.

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

Связывание с помощью столбца Код (ID)

В предыдущем примере таблицы Dollsи Manufacturersсвязаны друг с другом полем Manufacturer,в котором хранится имя компании-изготовителя. Такой выбор кажется оп­равданным в данном проекте — до тех пор, пока вы не задумаетесь на пару минут о возмож­ных ошибках. Специалисты по проектированию БД известны тем, что тратят недели на об­думывание неотвратимых бедствий.

В данном случае есть две потенциальные проблемы.

■ У двух изготовителей одно и то же название компании. Как узнать, какая из компаний сделала куклу?

■ Изготовитель куплен другой компанией, и у него изменилось название. Внезапно появляется длинный список записей из таблицы Dolls,которые нуждаются в корректировке.

Возможно, вы узнали эти проблемы, поскольку они аналогичны тем, с которыми вы сталкивались, когда речь шла о выборе первичного ключа (см. разд. "Первичный ключ "главы 2). Как вы уже знаете, трудно найти данные, гарантированно уникальные и неизменные. Вме­сто риска возникновения проблем надежнее положиться на поле с типом данных Счетчик,содержащее код (ID number), генерируемый программой Access.

Интересно, что тот же подход применяется при связывании таблиц. Для ссылки на запись в другой таблице не следует использовать любую порцию данных — вместо этого нужно применять уникальный код, указывающий на нужную запись. В табл. 5.5 приведена переконструированная таблица Dolls,ставшая более корректной за счет замены поля Manufacturerполем ManufacturerID.

Таблица 5.5. Данные в таблице Dolls после ее реконструирования

Если вы вернетесь назад и посмотрите на таблицу Manufacturers(см. табл. 5.4), то быст­ро обнаружите, что изготовитель с кодом или идентификационным номером 1 — это компа­ния MagicPlastic.

Этот проект — универсальный стандарт БД. Но у него есть два явных недостатка:

■ пользователь, вставляющий записи в таблицу Dolls,возможно, не знает кодов всех изго­товителей;

§когда смотришь на таблицу Dolls,нельзя сказать, кем изготовлена каждая кукла.

Для решения обеих проблем воспользуйтесь подстановкой. Подстановки отображают соответствующие сведения об изготовителе в таблице Dolls,а также позволяют выбрать изготовителя из списка в тот момент, когда добавляется запись или корректируется поле ManufacturerlD.(Вы узнали, как использовать подстановки со списками констант в разд. "Создание простого списка подстановок, состоящего из констант" главы 4. О том, как при­менять подстановки, сведя вместе связанные таблицы, такие как Dollsи Manufacturers,бу­дет рассказано в разд. "Поиск в связанных таблицах" далее в этой главе.)