Access 2007

Отношение "один-к-одному"

Отношение или связь "один-к-одному" связывает одну запись таблицы с одной или не связывает ни с одной записью другой таблицы. Иногда этот тип отношения применяется для разбиения таблицы с большим количеством полей на две или несколько меньших таблиц.

Таблица Products (изделия) может содержать подробную информацию, описывающую изделие и его цену, и дополнительные сведения об особенностях его производства. Эти сведения интересны только сотрудникам инженерно-технических подразделений, поэтому их можно перенести в отдельную таблицу (названную, например, ProductsEngineering (технические характеристики изделия). Это та информация, которая не должна интересовать продавцов при оформлении заказов. В другой ситуации можно разбить таблицу на две, просто потому что она слишком велика. (Программа Access не разрешает таблице иметь более 255 полей.)

Рис. 5.15. Когда связываются два поля, в которых не допускаются дублирующиеся данные (и флажок Обеспечение целостности данных установлен), Access считает, что создается связь "один-к-одному". Программа помещает цифру 1 на концах линии связи для того, чтобы отличать ее от других типов связей. В этом примере столбец ID в таблице Products и столбец ID в таблице ProductsEngineering — первичные ключи соответствующих таблиц, поэтому невозможно связать несколько записей таблицы ProductsEngineering с одной и той же записью таблицы Products

Отношение "один-к-одному" создается так же, как отношение "один-ко-многим" — перетаскиванием с помощью мыши полей на вкладке Схема данных (рис. 5.15). Единственная

191

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

Примечание

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

Для тех, кто понимает.

Применяйте связи "один-к-одному" с осторожностью

Отношения "один-к-одному" крайне редко применяются в программе Access. Обычно гораздо удобнее использовать скрытие столбцов (см. разд. "Скрытие столбцов" главы 3) и запросы (см. главу 6), если вы хотите видеть только отдельные поля таблицы.

Разделение таблицы на две части усложняет проект вашей БД и обычно это делается, только если есть другие причины для разбиения таблицы. Примерами могут служить следующие варианты,

•Две части таблицы необходимо поместить в отдельные БД (см. разд. "Что такое разделенная БД" главы 18) для того, чтобы разные люди могли копировать их на разные компьютеры и редактировать независимо.

•Вы хотите защитить от любопытных глаз уязвимые данные. Один из возможных способов — поместить информацию, которую нужно защитить, в отдельную таблицу и сохранить эту таблицу в другой, более защищенный файл БД.

•У вас есть таблица с огромным объемом данных, таких как поля типа Вложение (см. разд. "Вложение" главы 2) с большими документами. В этом случае можно повысить производительность, если разделить таблицу. Вы даже можете решить, что лучше поместить половину таблицы в отдельную БД (см, разд. "Что такое разделенная БД" главы 18).

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

Если у вас нет таких ситуаций, вы больше выиграете от создания одной большой таблицы.

Отношение "многие-ко-многим"

Отношение или связь "многие-ко-многим"связывает одну или несколько записей одной таблицы с одной или несколькими записями в другой таблице. Рассмотрим БД, в которой в отдельных таблицах хранятся данные об авторах и книгах. Авторы бестселлеров не останавливаются на одной книге (поэтому вы должны иметь возможность связать одного автора с несколькими книгами). Однако иногда авторы объединяются в команду под одним заглавием (поэтому вы должны иметь возможность связать одну книгу с несколькими авторами). Аналогичная ситуация возникает, если нужно распределить студентов по курсам, сотрудников по комитетам или ингредиенты по рецептам. Можно даже представить подобную ситуацию

192

и в случае БД с куклами-болванчиками, если несколько изготовителей решат объединиться для изготовления одной куклы-болванчика.

Связи "многие-ко-многим" довольно распространены, и программа Access предоставляет два способа их обработки.

Связующие таблицы

Связующие таблицы — традиционный метод обработки связей "многие-ко-многим", и их используют повсеместно в мире БД (включая и программное обеспечение промышленного уровня, такое как Microsoft SQL Server). Основная идея состоит в том, что вы создаете дополнительную таблицу, у которой единственное назначение — связывание двух таблиц.

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

Предположим, что в вашей таблице Authors хранятся записи, представленные в табл. 5.6.

Таблица 5.6. Данные таблицы Authors

В таблице Books содержатся записи, показанные в табл. 5.7.

Таблица 5.7. Данные таблицы Books

В табл. 5.8 приведена таблица Authors_Books, связывающая обе таблицы.

Таблица 5.8. Данные таблицы Authors_Books

193

AuthorsBooks — связующая таблица, определяющая четыре связи. Первая запись указывает на то, что автор № 10 (Alf Abet) написал книгу № 402 (Fun with Letters). Если вы просмотрите остальную часть таблицы, то обнаружите, что Cody Pendant принимал участие в написании двух книг, и два автора работали над одной и той же книгой (How to Save Money by Living with Your Parents).

Подсказка

Имя связующей таблицы часто состоит из имен двух таблиц, которые она связывает, например Authors

Books.

Суть связующей таблицы заключается в том, что она формирует два отношения "один-ко- многим", определенные в программе Access. Другими словами, связующая таблица — это таблица-потомок, у которой два родителя. У таблицы Authors отношение "один-ко-многим" с таблицей Authors_Books, в котором таблица Authors выступает как родитель. У таблицы Books также отношение "один-ко-многим" с таблицей Authors_Books, в котором таблица Books — родитель. Вы можете определить эти два отношения на вкладке Схема данных, убедившись в том, что заданы правила целостности данных (рис. 5.16).

Рис. 5.16. На самом деле отношение "многие-ко-многим" между таблицами Authors и Books — это два отношения "один-ко-многим", включающие таблицу Authors_Books. После определения этих отношений вы не сможете связать автора или книгу, которые не существуют, и удалить автора или книгу, у которых есть запись в таблице Authors_Books

194

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

Многозначные поля

До появления программы Access 2007 связующие таблицы были единственным средством создания связей "многие-ко-многим". Но для поддержки средств интеграции (см. главу 21) сервисов SharePoint в Access 2007 включена новая функциональная возможность — многозначные поля.

Как следует из названия, многозначное поле может хранить более одного значения. Эта возможность очень удачно решает проблему связей "многие-ко-многим". Идея состоит в настройке связующего поля в таблице-потомке как многозначного поля. Вернемся к примеру с авторами и книгами. При отсутствии связующей таблицы вам нужно вставить столбец AuthorID в таблицу с записями о книгах для обозначения каждого автора, написавшего данную книгу (табл. 5.9).

Таблица 5.9. Данные таблицы Books, в которую добавлен столбец AuthorID, содержащий дублирующие значения

Но обычное поле хранит единственное значение. Таким образом, в этой таблице можно указать только одного из двух авторов книги № 403.

Если же разрешить хранение нескольких значений в поле AuthorID, можно ввести список авторов, подобный приведенному в табл. 5.10.

Таблица 5.10. Данные таблицы Books, в которую добавлен столбец AuthorlD, хранящий несколько значений

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

Для создания поля с несколькими значениями следует использовать подстановку. Как вы уже знаете (см. рис. 5.14), эта функциональная возможность выбирается на последней странице мастера Создание подстановки. С другой стороны, если у вас уже есть подстановка

195

в поле, необходимо внести небольшое изменение. Откройте таблицу в Конструкторе, выберите поле с подстановкой (например, ManufacturerID) и затем в области Свойства поля щелкните кнопкой мыши вкладку Подстановка (Lookup). Найдите свойство Разрешение нескольких значений (Allow Multiple Values) и измените его значение с Нет на Да.

Примечание

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

На рис. 5.17 показан многозначный список подстановки в действии.

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

Многозначные поля доступны, только если применяется БД нового формата с расширением accdb (см. примечание "Для тех, кто понимает. Использование Access БД, созданных в более ранних версиях программы" в разд. "Создание новой базы данных" главы 1). В файле с расширением mdb (БД, созданной программой Access 2003 и еще не преобразованной) вы не сможете их использовать.

Поля с множественными значениями вызывают проблемы при переносе вашей БД на SQL Server (как описано в главе 20), поскольку SQL Server не поддерживает их. Следовательно, если есть вероятность совместного использования вашей БД многими пользователями (скажем, в большой компании) и вы можете в какой-то момент перенести ваши данные в БД более мощной программы SQL Server, избегайте полей с множественными значениями.

Примечание

Поля с множественными значениями не создают проблем при переносе вашей БД на Share-Point Server (как описано в главе 21).

196

Часто задаваемый вопрос. Работа со связями "многие-ко-многим"

Какой подход лучше: связующие таблицы или поля с множественными значениями?

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

С другой стороны, у связующих таблиц есть недостатки — с ними трудно работать на листе данных. Если в вашей БД применяется связующая таблица Authors_Books, для вставки новой книги в вашу систему придется редактировать, по крайней мере, две таблицы. Сначала необходимо вставить запись в таблицу Books. Затем следует открыть таблицу Authors_Books и вставить в нее новую запись, которая свяжет книгу с автором. (Для облегчения этого процесса можно использовать подстановки в таблице Authors_Books, но все равно для этого требуется отдельный шаг.) Если же в таблице Books содержится поле Authors с множественными значениями, можно добавить книгу и присвоить ей авторов за один шаг, что гораздо удобнее.

Если вы решили остановиться на связующих таблицах и хотите облегчить свою жизнь, программа Access предлагает отличное решение. Можно создать настраиваемую форму, умеющую работать сразу с несколькими таблицами. Можно сконструировать форму, позволяющую человеку, работающему с БД, вставлять запись одновременно и в таблицу Books, и в таблицу Authors_Books. И главное — ваша форма может выглядеть так, как будто она использует только одну таблицу. Вы узнаете, как применять этот прием в части IV.

Практическое применение связей

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

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

Музыкальная школа

Cacophone Studios управляет музыкальной школой среднего размера. Школа предлагает определенный набор курсов и имеет штатное расписание преподавателей, способных вести большинство из них. Есть также довольно длинный список бывших и потенциальных клиентов. В прошлом году случилась катастрофа местного масштаба, когда 273 студента были втиснуты на один и тот же курс и им не назначили преподавателя. (Соседний курс из

197

14 студентов почему-то получил трех преподавателей) Руководители надеются, что программа Access поможет им избежать подобного конфуза в настоящем и будущем.

Подсказка

Хотите поработать с Cacophone Studios? Попытайтесь выделить возможные таблицы и их связи, прежде чем читать дальше.

Определение таблиц

У каждого бизнеса есть особенности, и необходим долгий подробный анализ для создания наилучшей структуры таблиц для Cacophone Studios. Но, даже не имея особенно глубоких знаний, можно выделить несколько наиболее очевидных кандидатов:

■Teachers — таблица для хранения списка всех преподавателей из штатного расписания, дополненная контактной информацией;

■Students — таблица для хранения всех учеников, прошлых, настоящих и будущих. Вам не нужно разделять эти группы людей в таблице Students — вместо этого вы сможете выбрать нынешних студентов из таблицы, найдя связанную информацию (а именно их запись на курс). Таким образом, можно не усложнять таблицу Students и хранить в ней только имя и фамилию и контактную информацию;

■Classes — таблица для хранения курсов, предлагаемых компанией Cacophone Studios. В эту таблицу следует включить название учебного курса, дату начала и окончания занятий, максимальный номер принятого студента и другую важную информацию.

Примечание

Условия, необходимые для приема студента на курс, хранятся в поле PreviousClassRequirements (необходимые предыдущие курсы) с множественными значениями и подстановкой. Это поле содержит идентификационные номера всех прослушанных курсов. (Другими словами, у каждой записи в таблице Classes есть ловко реализованная возможность указать на другие курсы в той же самой таблице.)

Конечно, компании Cacophone Studios очень скоро понадобится гораздо больше таблиц. Но для начала перечисленных таблиц достаточно.

Определение связей

Выделить необходимые связи очень легко. Студенты записываются на курсы. Преподаватели ведут курсы. Эта ситуация предполагает две связи: одна между таблицами Students и Classes, а другая между таблицами Teachers и Classes.

Но тут есть одна загвоздка. Компания Cacophone Studios конечно же не хочет мешать одному студенту заниматься на нескольких курсах, поэтому между этими двумя таблицами необходима связь "многие-ко-многим". Несмотря на то, что Cacophone Studios планирует иметь одного преподавателя для ведения каждого курса, но они хотят сохранить возможность кооперации преподавателей для проведения занятий на одном курсе. Следовательно, таблицы Teachers и Classes вовлечены в более сложное отношение "многие-ко-многим". Для поддержки этих двух связей можно создать две связующие таблицы, названные

Students_Classes и Teachers_Classes (соответственно). На рис. 5.18 показана описанная организация таблиц.

198

Рис. 5.18. Две связи "многие-ко-многим" формируют основу схемы данных БД музыкальной школы Cacophone Studios

Примечание

Каждая запись в таблице Students_Classes представляет сведения о приеме студента на курс. В таблицу можно добавить дополнительные поля, такие как дата записи студента на курс, предложенная вами скидка для принятых студентов, сделавших заказ заранее, и т. д.

Дополнительные подробности

Компания Cacophone Studios начала движение в нужном направлении, но им еще нужно подумать о многом. Прежде всего, каждый раз, когда предлагается курс, необходимо создать отдельную запись в таблице Classes. Это разумный подход, но у него есть потенциальная проблема. Это связано с тем, что когда курс (например, электроакустический в стиле гамелан (Electro-Acoustic Gamelan)) заканчивается, он снова предлагается как новый курс с новыми студентами. Несмотря на то, что это полностью новый курс, у него есть информация, общая с предыдущим курсом, например, описание, стоимость курса, предъявляемые требования и т. д.

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

Для реализации этой части проекта каждая запись таблицы Classes связывается с единственной записью таблицы ClassDescriptions. Между этими таблицами существует связь "один-ко-многим" (рис. 5.19).

Компания Cacophone Studios также должна думать о неприятной финансовой стороне вещей. Каждый раз, когда студент записывается на курс, нужно взять с него установленную плату за обучение. А при каждом назначении преподавателя для ведения курса ему нужно своевременно выплачивать зарплату.

199

Рис. 5.19. Благодаря таблице ClassDescriptions можно использовать одно и то же описание для нескольких курсов, тем самым избегая избыточности данных

Этими подробностями можно заполнить две таблицы: TeacherPayments (плата преподавателям) и StudentCharges (плата за обучение студентов). Очевидно, что для этих таблиц надо установить связи, но, возможно, не такие, как вы ожидали. Вы можете решить, что запись таблицы StudentCharges следует связать напрямую с записями таблицы Students. Такая связь не лишена смысла, поскольку необходимо знать, кто из студентов заплатил деньги, Но так же важно знать, за что заплачены деньги — за какой именно курс платит студент. Другими словами, каждая запись таблицы StudentCharges должна быть связана и с таблицей Students, и с таблицей Classes.

Однако есть более легкий способ. Вы можете сберечь силы, связав таблицу StudentCharges непосредственно с таблицей StudentsClasses. Если помните, в каждой записи таблицы Students_Classes содержатся сведения о студентах и курсе для одного учебного курса. Каждый раз, когда добавляется запись в таблицу Students_Classes, необходимо включить соответствующую сумму в таблицу StudentCharges, Аналогичное отношение существует между таблицами Teachers_Classes и TeacherPayments. На рис. 5.20 показано все сооружение (не включена только таблица ClassDescriptions, представленная на рис. 5.19).

Примечание

Напоминаю, что для создания отношения "один-к-одному" следует использовать первичный ключ или индекс, не допускающий совпадений (см.' разд. "Предотвращение дублирования значений с помощью индексов" главы 4). В данном примере нужно создать не допускающий совпадений индекс для поля Student_ClasseslD в таблице StudentCharges и поля Teacher_ClasseslD в таблице TeacherPayments. Этот индекс гарантирует, что студенты заплатят только один раз за каждый выбранный ими курс, а преподаватели получат зарплату только один раз за каждый курс, который они провели.

Эта БД очень быстро станет достаточно сложной. А компания Cacophone Studios, возможно, все еще не закончила ее формирование. (Например, очень вероятно, что ей понадобится таблица о платежах студентов.) Как и в большинстве реальных БД, вы будете продолжать добавлять новые таблицы и связи бесконечно.

200