Краткое содержание 29 Об этих стрелках 30 о сочетаниях клавиш 32 о щелчках кнопкой мыши 33 Примеры 33
 Скачать 19.64 Mb.
|
|
Рис. 5.11. Секрет хорошей подстановки — выбор двух порций информации, первичного ключа (в данном случае поля ID) и более информативного значения (названия компании-изготовителя). Данные из поля ID вы должны сохранить в записи о кукле, а значение поля Manufacturer вы отобразите в списке подстановки для того, чтобы облегчить правильный выбор компании-изготовителя Подсказка И  ногда может понадобиться несколько полей для описательной информации. Например, можно использовать поля FirstName и LastName из таблицы FamilyRelatives (члены семьи). Но не включайте слишком много информации, иначе список подстановки станет необъемным из-за включений в него всех этих сведений. Это выглядит неестественно. 6. Выберите поле, применяемое для сортировки списка подстановки (рис. 5.12), и щелкните мышью кнопку Далее. В нашем примере список подстановки лучше всего отсортировать в соответствии со значениями поля Manufacturer. Рис. 5.12. Отсортировать список подстановки очень важно для того, чтобы пользователь мог быстро найти нужное значение
Обычно естественней всего сохранить название поля, использующего подстановку (в данном случае ManufacturerID). На последнем этапе вы можете также выбрать режим, называемый Разрешить несколько значений (Allow Multiple Values). Если установить этот флажок, в списке отображается флажок рядом с каждым значением, поэтому можно одновременно выбрать несколько элементов списка. (В этом примере можно создать запись о кукле с несколькими изготовителями.) Вы узнаете больше о варианте Разрешить несколько значений в разд. "Многозначные поля "далее в этой главе. Р  ис. 5.13. Здесь показан список подстановки, содержащий имя изготовителя (поле Manufacturer) и скрывающий его идентификатор (поле ID) 9. Щелкните мышью кнопку Готово (Finish). Теперь программа Access формирует список подстановки для поля и предлагает сохранить таблицу. После этого Access создает связь между двумя таблицами, связанными вашим столбцом подстановки. В данном случае программа устанавливает отношение "родитель—потомок" между таблицами Manufacturers и Dolls, так же как вы делали это самостоятельно (см. разд. "Определение отношения "ранее в этой главе). Примечание Созданная программой Access связь не обеспечивает ссылочной целостности, поскольку программа не знает, соответствуют ли ваши записи этому жесткому стандарту. В таблице может быть кукла, указывающая на несуществующего изготовителя. Если такая возможность кажется угрожающе нестрогой, можно отредактировать связь с помощью вкладки Схема данных (как описано в разд. "Редактирование связей" ранее в этой главе). Начните с добавления на вкладку обеих таблиц Dolls и Manufacturers. Затем щелкните правой кнопкой мыши линию связи между ними и выберите команду Изменить связь. В заключение установите флажок Обеспечение целостности данных и щелкните мышью кнопку ОК. Теперь, если отобразить таблицу Dolls в Режиме таблицы, можно использовать список подстановки во время редактирования и вставки записей (рис.5.14). Часто задаваемый вопрос. Обновление списка Я только что добавил запись, но она не появилась в моем списке подстановки. Почему? Программа Access заполняет ваши списки подстановок, когда таблица открывается впервые. Например, когда открывается таблица Dolls, Access получает готовый к использованию список изготовителей. Но иногда вы должны открыть одновременно как таблицу, использующую список подстановки, так и таблицу, предоставляющую данные для этого списка. В этой ситуации изменения, вносимые вами в таблицу, предоставляющую данные для списка подстановки, не появятся в таблице, использующей этот список. Д  ля того чтобы понять механизм действия, откройте одновременно таблицы Dolls и Manufacturers. (Они открываются на разных вкладках.) В таблицу Manufacturers добавьте новую компанию-изготовителя. Затем вернитесь в таблицу Dolls и попробуйте воспользоваться списком подстановки в поле ManufacturerID. Вы увидите, что новой записи нет в списке подстановки. К счастью, найти решение легко. Вы можете попросить программу Access обновлять список подстановки в любое время, выбрав Главная → Записи → Обновить все (Ноmе →Records → Refresh All). Выполните эту последовательность из таблицы Dolls и увидите в списке подстановки обновленный список изготовителей. Рис. 5.14. Несмотря на то, что за кадром таблица Dolls хранит значение ID в поле ManufacturerlD, нет способа отобразить его на вашем листе данных. Вместо данного поля вы видите связанное с ним название изготовителя (как на экране, так и на любой сделанной вами распечатке). Более того, если нужно добавить новую запись или изменить изготовителя в имеющейся, вы можете выбрать изготовителя из списка по имени Более экзотические связи Как вы узнали из разд. "Отношение типа „родитель—потомок" "ранее в этой главе, отношение или связь "один-ко-многим" (известная также под именем родитель—потомок), связывающая единственную запись одной таблицы с одной или несколькими записями другой таблицы, — наиболее распространенный тип отношения. Один изготовитель может быть связан с одной куклой, несколькими или не связан ни с одной куклой вообще. Наряду со связями "один-ко-многим" существуют еще два несколько иных типа связей: отношение "один-к-одному" и отношение "многие-ко-многим". В следующих разделах вы познакомитесь с обоими типами. Отношение "один-к-одному" Отношение или связь "один-к-одному" связывает одну запись таблицы с одной или не связывает ни с одной записью другой таблицы. Иногда этот тип отношения применяется для разбиения таблицы с большим количеством полей на две или несколько меньших таблиц. Таблица Products (изделия) может содержать подробную информацию, описывающую изделие и его цену, и дополнительные сведения об особенностях его производства. Эти сведения интересны только сотрудникам инженерно-технических подразделений, поэтому их можно перенести в отдельную таблицу (названную, например, ProductsEngineering (технические характеристики изделия). Это та информация, которая не должна интересовать продавцов при оформлении заказов. В другой ситуации можно разбить таблицу на две, просто потому что она слишком велика. (Программа Access не разрешает таблице иметь более 255 полей.) Р  ис. 5.15. Когда связываются два поля, в которых не допускаются дублирующиеся данные (и флажок Обеспечение целостности данных установлен), Access считает, что создается связь "один-к-одному". Программа помещает цифру 1 на концах линии связи для того, чтобы отличать ее от других типов связей. В этом примере столбец ID в таблице Products и столбец ID в таблице ProductsEngineering — первичные ключи соответствующих таблиц, поэтому невозможно связать несколько записей таблицы ProductsEngineering с одной и той же записью таблицы Products Отношение "один-к-одному" создается так же, как отношение "один-ко-многим" — перетаскиванием с помощью мыши полей на вкладке Схема данных (рис. 5.15). Единственная разница состоит в том, что всвязанных полях обеих таблиц нужно задать запрет совпадений. В этом случае запись одной таблицы может (как максимум) быть связана с единственной записью в другой таблице. Примечание В поле запрещены совпадения, если оно является первичным ключом таблицы (см. разд. "Первичный ключ" главы 2) или если у поля есть индекс, препятствующий появлению дублирующейся информации (см. разд. "Предотвращение дублирования значений с помощью индексов" главы 4). Для тех, кто понимает. Применяйте связи "один-к-одному" с осторожностью Отношения "один-к-одному" крайне редко применяются в программе Access. Обычно гораздо удобнее использовать скрытие столбцов (см. разд. "Скрытие столбцов" главы 3) и запросы (см. главу 6), если вы хотите видеть только отдельные поля таблицы. Разделение таблицы на две части усложняет проект вашей БД и обычно это делается, только если есть другие причины для разбиения таблицы. Примерами могут служить следующие варианты,
Если у вас нет таких ситуаций, вы больше выиграете от создания одной большой таблицы. Отношение "многие-ко-многим" Отношение или связь "многие-ко-многим"связывает одну или несколько записей одной таблицы с одной или несколькими записями в другой таблице. Рассмотрим БД, в которой в отдельных таблицах хранятся данные об авторах и книгах. Авторы бестселлеров не останавливаются на одной книге (поэтому вы должны иметь возможность связать одного автора с несколькими книгами). Однако иногда авторы объединяются в команду под одним заглавием (поэтому вы должны иметь возможность связать одну книгу с несколькими авторами). Аналогичная ситуация возникает, если нужно распределить студентов по курсам, сотрудников по комитетам или ингредиенты по рецептам. Можно даже представить подобную ситуацию и в случае БД с куклами-болванчиками, если несколько изготовителей решат объединиться для изготовления одной куклы-болванчика. Связи "многие-ко-многим" довольно распространены, и программа Access предоставляет два способа их обработки. Связующие таблицы Связующие таблицы — традиционный метод обработки связей "многие-ко-многим", и их используют повсеместно в мире БД (включая и программное обеспечение промышленного уровня, такое как Microsoft SQL Server). Основная идея состоит в том, что вы создаете дополнительную таблицу, у которой единственное назначение — связывание двух таблиц. Каждая запись в связующей таблице представляет связь, которая соединяет вместе запись каждой таблицы в отношение. В БД с книгами и авторами единственная запись в связующей таблице сопоставляет одного автора с одной книгой. Если один и тот же автор написал три книги, вы должны добавить три записи в связующую таблицу. Если два автора работают над одной книгой, вам потребуется дополнительная запись для связи с каждым новым автором. Предположим, что в вашей таблице Authors хранятся записи, представленные в табл. 5.6. Таблица 5.6. Данные таблицы Authors
В таблице Books содержатся записи, показанные в табл. 5.7. Таблица 5.7. Данные таблицы Books
В табл. 5.8 приведена таблица Authors_Books, связывающая обе таблицы. Таблица 5.8. Данные таблицы Authors_Books
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 Хотя на первый взгляд связующие таблицы производят странное впечатление, большинство фанатов БД быстро привыкают к ним. Как и в случае связей "один-ко-многим", которыми вы пользовались ранее, можно создавать подстановки (см. разд. "Поиск в связанных таблицах" ранее в этой главе) для полей 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), эта функциональная возможность выбирается на последней странице мастера Создание подстановки. С другой стороны, если у вас уже есть подстановка в поле, необходимо внести небольшое изменение. Откройте таблицу в Конструкторе, выберите поле с подстановкой (например, 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). Часто задаваемый вопрос. Работа со связями "многие-ко-многим" Какой подход лучше: связующие таблицы или поля с множественными значениями? Большинство фанатов БД в ближайшие годы будут приверженцами связующим таблицам. Такие таблицы приняты, укоренились и не скрывают внутреннего функционирования вашей БД. Связующие таблицы особенно удобны, если вы хотите добавить дополнительную информацию о связи между двумя конкретными таблицами. Предположим, что вы создаете таблицу Students_Classes для учета учебных курсов, которые все студенты слушают в популярном учебном заведении. В таблицу Students_Classes можно включить дополнительные поля, такие как EnrollmentDate (дата записи на курс), Соn-firmationLetterSentDate (дата отправки подтверждающего письма) и Prerequi-sitesChecked (необходимые условия приема проверены). С другой стороны, у связующих таблиц есть недостатки — с ними трудно работать на листе данных. Если в вашей БД применяется связующая таблица Authors_Books, для вставки новой книги в вашу систему придется редактировать, по крайней мере, две таблицы. Сначала необходимо вставить запись в таблицу Books. Затем следует открыть таблицу Authors_Books и вставить в нее новую запись, которая свяжет книгу с автором. (Для облегчения этого процесса можно использовать подстановки в таблице Authors_Books, но все равно для этого требуется отдельный шаг.) Если же в таблице Books содержится поле Authors с множественными значениями, можно добавить книгу и присвоить ей авторов за один шаг, что гораздо удобнее. Если вы решили остановиться на связующих таблицах и хотите облегчить свою жизнь, программа Access предлагает отличное решение. Можно создать настраиваемую форму, умеющую работать сразу с несколькими таблицами. Можно сконструировать форму, позволяющую человеку, работающему с БД, вставлять запись одновременно и в таблицу Books, и в таблицу Authors_Books. И главное — ваша форма может выглядеть так, как будто она использует только одну таблицу. Вы узнаете, как применять этот прием в части IV. Практическое применение связей Каждому проектировщику БД необходимо видеть мир как совокупность таблиц и связей. Смышленые разработчики БД могут быстро оценить информацию и увидеть, как она связана. Благодаря этой способности они могут создать корректную БД в любой области. В последующих разделах представлены два сценария, которые могут помочь вам приобрести опыт создания более реалистических отношений. Обе БД, используемые в данных сценариях, включены в примеры к данной главе, мы вернемся к ним снова в следующих главах, когда начнем создавать более сложные объекты БД, такие как запросы, отчеты и формы. Музыкальная школа Cacophone Studios управляет музыкальной школой среднего размера. Школа предлагает определенный набор курсов и имеет штатное расписание преподавателей, способных вести большинство из них. Есть также довольно длинный список бывших и потенциальных клиентов. В прошлом году случилась катастрофа местного масштаба, когда 273 студента были втиснуты на один и тот же курс и им не назначили преподавателя. (Соседний курс из 14 студентов почему-то получил трех преподавателей) Руководители надеются, что программа Access поможет им избежать подобного конфуза в настоящем и будущем. Подсказка Хотите поработать с Cacophone Studios? Попытайтесь выделить возможные таблицы и их связи, прежде чем читать дальше. Определение таблиц У каждого бизнеса есть особенности, и необходим долгий подробный анализ для создания наилучшей структуры таблиц для Cacophone Studios. Но, даже не имея особенно глубоких знаний, можно выделить несколько наиболее очевидных кандидатов:
Примечание Условия, необходимые для приема студента на курс, хранятся в поле PreviousClassRequirements (необходимые предыдущие курсы) с множественными значениями и подстановкой. Это поле содержит идентификационные номера всех прослушанных курсов. (Другими словами, у каждой записи в таблице Classes есть ловко реализованная возможность указать на другие курсы в той же самой таблице.) Конечно, компании Cacophone Studios очень скоро понадобится гораздо больше таблиц. Но для начала перечисленных таблиц достаточно. Определение связей Выделить необходимые связи очень легко. Студенты записываются на курсы. Преподаватели ведут курсы. Эта ситуация предполагает две связи: одна между таблицами Students и Classes, а другая между таблицами Teachers и Classes. Но тут есть одна загвоздка. Компания Cacophone Studios конечно же не хочет мешать одному студенту заниматься на нескольких курсах, поэтому между этими двумя таблицами необходима связь "многие-ко-многим". Несмотря на то, что Cacophone Studios планирует иметь одного преподавателя для ведения каждого курса, но они хотят сохранить возможность кооперации преподавателей для проведения занятий на одном курсе. Следовательно, таблицы Teachers и Classes вовлечены в более сложное отношение "многие-ко-многим". Для поддержки этих двух связей можно создать две связующие таблицы, названные Students_Classes и Teachers_Classes (соответственно). На рис. 5.18 показана описанная организация таблиц.  Рис. 5.18. Две связи "многие-ко-многим" формируют основу схемы данных БД музыкальной школы Cacophone Studios Примечание Каждая запись в таблице Students_Classes представляет сведения о приеме студента на курс. В таблицу можно добавить дополнительные поля, такие как дата записи студента на курс, предложенная вами скидка для принятых студентов, сделавших заказ заранее, и т. д. Дополнительные подробности Компания Cacophone Studios начала движение в нужном направлении, но им еще нужно подумать о многом. Прежде всего, каждый раз, когда предлагается курс, необходимо создать отдельную запись в таблице Classes. Это разумный подход, но у него есть потенциальная проблема. Это связано с тем, что когда курс (например, электроакустический в стиле гамелан (Electro-Acoustic Gamelan)) заканчивается, он снова предлагается как новый курс с новыми студентами. Несмотря на то, что это полностью новый курс, у него есть информация, общая с предыдущим курсом, например, описание, стоимость курса, предъявляемые требования и т. д. Для учета этой особенности нужно создать еще одну таблицу ClassDescriptions (описания курсов). В записи этой таблицы должна содержаться вся описательная информация о курсе. В записи таблицы Classes представлены сведения об одном предусмотренным расписанием конкретном учебном курсе. Таким образом, школа может предлагать без помех один и тот же курс многократно. Для реализации этой части проекта каждая запись таблицы Classes связывается с единственной записью таблицы ClassDescriptions. Между этими таблицами существует связь "один-ко-многим" (рис. 5.19). Компания Cacophone Studios также должна думать о неприятной финансовой стороне вещей. Каждый раз, когда студент записывается на курс, нужно взять с него установленную плату за обучение. А при каждом назначении преподавателя для ведения курса ему нужно своевременно выплачивать зарплату.  Рис. 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, возможно, все еще не закончила ее формирование. (Например, очень вероятно, что ей понадобится таблица о платежах студентов.) Как и в большинстве реальных БД, вы будете продолжать добавлять новые таблицы и связи бесконечно.  Рис. 5.20. Каждый назначенный курс приводит к появлению платежа в таблице TeacherPayments (вверху слева). Каждый прием студента в курс формирует запись об оплате в таблице StudentCharges (вверху справа). Несмотря на то, что на первый взгляд эта картинка слегка устрашающая, вы должны уметь прокладывать путь последовательно через все таблицы и связи. Начинать создание БД легче всего с нескольких таблиц, постепенно добавляя новые Часто задаваемый вопрос. Печать ваших отношений Почему последовательность Office→ Печать (Officebutton→ Print.) становится недоступной, когда я просматриваю вкладку Схема данных? После создания связей между вашими таблицами, возможно, вам захочется быстро напечатать эту структуру. Напечатать непосредственно вкладку Схема данных нельзя, но ее можно преобразовать в отчет, представляющий собой специализированный объект БД и позволяющий создать распечатку в любое время. (Вы узнаете, как создавать отчеты, в части III.) Для создания отчета о связях ваших таблиц сначала расположите все выбранные по нашему вкусу таблицы на вкладке Схема данных. Затем выберите Работа со связями | Конструктор → Сервис → Отчет по схеме данных (Relationship Tools | Design → Tools → Relationship Report). На экран выводится окно предварительного просмотра, которое похоже в той или иной степени на текущее содержимое вкладки Схема данных. Для того чтобы вывести его на печатающее устройство, можно выбрать последовательность Office → Печать. После закрытия отчета со связями программа Access предложит сохранить его в вашей БД. Обычно вы с этим не связываетесь, потому что можете легко восстановить его в любое время. Но если у вас сложная БД и вы хотите напечатать несколько разных схем (на каждой из которых представлены разные группы связей), у вас может возникнуть желание сохранить ваш отчет о связях для последующего применения. Вы узнаете больше об отчетах в главе 10. Магазин шоколадных изделий БД о продажах, вкоторой хранятся товары, клиенты и заказы компании, торгующей чем-либо, — наиболее распространенная разновидность БД. На самом деле этот шаблон появляется так часто, что стоит рассмотреть его в кратком примере. Как будет видно, существует несколько основных правил, применяемых к любому зависящему от продаж (торговому) предприятию, будь то продажа коллекционируемых книг или уцененных фармацевтических изделий. В данном примере вы встретитесь с принимающей заказы по почте компанией Boutique Fudge, которая удовлетворяет декадентские изыски большой аудитории помешанных на шоколаде клиентов. Ее бесстрашные руководители склонны к постоянным инновациям и хотят как можно лучше управлять постоянно растущим каталогом своих высококачественных изделий. Они также нуждаются в способе учета клиентов и сделанных ими заказов. Каталог изделий и список клиентов Даже зная не слишком много о компании Boutique Fudge, вы можете придумать несколько основных нужных им таблиц. Для того чтобы выставить что-то на продажу, вам потребуются следующие таблицы. ■ Таблица Products, в которой перечислены соблазнительные шоколадные деликатесы, предлагаемые для продажи. В таблице записаны: название, описание и цена каждого предлагаемого изделия. Имеет смысл включить в нее несколько необязательных подробностей — например, почему бы не учесть текущий запас с помощью двух числовых полей (UnitsInStock (количество единиц на складе) и UnitsOnOrder (количество заказанных единиц)), а также логическое поле (названное Discontinued (больше не продающиеся)) для обозначения изделий, которые больше не поступают в продажу. Примечание Во многих БД нельзя удалять старые данные. Компания вроде Boutique Fudge не может просто исключить старые изделия из своих каталогов, поскольку они могут быть связаны со старыми заказами. Кроме того, есть смысл хранить исторические сведения для возможного анализа данных. (Boutique Fudge могла бы применить запрос для поиска самых хорошо продаваемых товаров в 1999 г. и выяснить, есть ли связь между снижением содержания какао и сокращением продаж.) Именно поэтому вам нужно поле Discontinued. Когда перечисляются изделия для продажи, все больше не поступающие в продажу изделия можно исключить с помощью средств фильтрации, с которыми вы познакомились в разд. "Фильтрация" главы 3.
Примечание Многие компании разрешают своим клиентам предоставлять несколько адресов доставки и кредитных карт. Если вы согласитесь на такое разнообразие, вам понадобится (не удивляйтесь) б  ольше таблиц. Можно создать таблицу CustomerCreditCards. Затем каждую запись из таблицы Customers можно связать с одной или несколькими записями в таблице CustomerCreditCards. BoutiqueFudge выбрала легкий путь и хранит номер кредитной карты клиента и его адрес непосредственно в таблице Customers. Пока существует одна действующая связь — связь типа "один-ко-многим" между таблицами ProductCategories и Products. Этот проект показан на рис. 5.21. Рис. 5.21. Товар (например, Chocolate Jasmine Tea (шоколадный жасминовый чай)) можно поместить в одну категорию (скажем, напитки), но в отдельную категорию входит много товаров Заказ товаров Как бы искусно не была спроектирована ваша БД о продажах, если клиенты не смогут заказывать интересующие их товары, компания Boutique Fudge быстро разорится. Новички в разработке БД часто допускают ошибку, считая, что сведения о заказах можно хранить в одной таблице. На самом деле вам нужны две.
Поскольку в среднем заказ содержит несколько видов изделий, отдельная запись в таблице Orders обычно связана с несколькими записями таблицы OrderDetails (как показано на рис. 5.22). Это утверждение может показаться нелепым (т. к. оно означает, что вам требуется создать группу новых записей для всего лишь одного заказа), но процесс не потребует от вас больших усилий. У программы Access есть два средства, которые выручат: подтаблицы (рис. 5.23) и формы (см. главу 12). Обратите внимание на то, что запись OrderDetails хранит цену каждого заказанного вида товара. Может показаться, что такая система порождает избыточность данных по отношению к  таблице Products. Но цены товаров меняются и компании предлагают скидки. По этим причинам очень важно отслеживать цену товара, когда его заказывают. В противном случае вам придется гадать о том, сколько должен вам каждый клиент. Рис. 5.22. У каждого заказа может быть неограниченное количество заказанных видов товаров. Такая возможность неизменно радует компанию Boutique Fudge Р  ис. 5.23. Благодаря наличию подтаблицы можно добавлять в одном месте запись о заказе и связанные с ним виды товаров Примечание Профессиональные разработчики БД называют информацию такого сорта сиюминутными или текущими данными (point-in-time data), поскольку они меняются со временем. Следует отметить, что запись таблицы Order не хранит общую стоимость заказа, т. к. общая стоимость — это просто сумма стоимостей всех заказанных товаров. Если хранить общую стоимость, то возникает возможность появления противоречивых данных — иными словами, у вас появится проблема, если сохраняемая общая стоимость не совпадет со стоимостью всех товаров, включенных в заказ. Вам придется еще как следует поработать, прежде чем Boutique Fudge превратится в компанию, которая управляется БД. Например, возможно, придется создать таблицу Shipments (доставки), в которой учтены заказы, отправленные по почте, и таблицу Payments (платежи), чтобы быть уверенными в том, что клиенты расплатились полностью. Концептуально в этом нет ничего нового, но чем больше таблиц добавляется, тем сложнее становятся БД. Теперь, зная основы отношений и правила создания таблиц хорошей структуры, вы сумеете сохранять хладнокровие в стрессовой ситуации. Часть II Обработка данных с помощью запросов |