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

Компания 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 → Печать (Office button → Print.) становится недос­тупной, когда я просматриваю вкладку Схема данных?

После создания связей между вашими таблицами, возможно, вам захочется быстро на­печатать эту структуру. Напечатать непосредственно вкладку Схема данных нельзя, но ее можно преобразовать в отчет, представляющий собой специализированный объект БД и позволяющий создать распечатку в любое время. (Вы узнаете, как создавать отче­ты, в части III.)

Для создания отчета о связях ваших таблиц сначала расположите все выбранные по на­шему вкусу таблицы на вкладке Схема данных. Затем выберите Работа со связями | Конструктор → Сервис → Отчет по схеме данных (Relationship Tools | Design → Tools → Relationship Report). На экран выводится окно предварительного просмотра, которое похоже в той или иной степени на текущее содержимое вкладки Схема данных. Для то­го чтобы вывести его на печатающее устройство, можно выбрать последовательность Office → Печать.

После закрытия отчета со связями программа Access предложит сохранить его в вашей БД. Обычно вы с этим не связываетесь, потому что можете легко восстановить его в лю­бое время. Но если у вас сложная БД и вы хотите напечатать несколько разных схем (на каждой из которых представлены разные группы связей), у вас может возникнуть жела­ние сохранить ваш отчет о связях для последующего применения. Вы узнаете больше об отчетах в главе 10.