ЧАСТЬ 3 Прчекгыртащт пояьзвэательского интерфейса

В большинстве случаев представление связей многие ко многим в пользовательских формах почти ничем не отличается от представления связей один ко многим и при отображении данных в нользо-вательской форме связь ко многим удается заменить свя-

зью один ко многим (рис. 14-7).

Products

Рис. 14- 7. Между сущностями omers odttcts существует связь многие ко многим , таблицы Orders и Order Details используются как промежуточные

Весьма практично отображать пользователю информацию обо всех продуктах, заказанных (таблицу Customers можно

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

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

ко, как уже упоминалось в главе 3, сама связь иногда имеет атрибуты, которые обычно включают в промежуточную таблицу при моделировании данных (рис. 14-7). Если эти атрибуты необходимо включить в разрабатываемую форму, лучше поместить их на стороне

Если в форме должны отображаться данные о продуктах, заказанных каждым из покупателей (при этом таблица Customers находится на стороне один связи один ко то дата заказа, храняща-

яся в одном из полей таблицы очевидно, относится к данным

о продукте, а не о покупателе. Данные, отображаемые в этой форме,

интерпретируются так: Покупатель X приобрел продукт Y 15 числа этого месяца, а продукт Z - 18 числа этог ца*. Если же интерпретировать эту связь с другого ТО таблица Products будет находиться на стороне один связи один ко В этом случае в форме представлены сведения о покупателях, заказавших конкретные продукты, например: Продукт X был приобретен покупателем У 15 числа этого месяца, а покупателем Z - 18 числа этого месяца . Данные таблицы Customers представлены в форме так, как если бы эта таблица являлась участником связи ко со стороны многие .

Весьма вероятно, что в той части формы, где размещена информация из таблицы, участвующей в связи на стороне многие , будут

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

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

В большинстве случаев для представления в пользовательских формах связей многие ко удается применять методы, кото-

рые используются для представления связей один ко Но в

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

ЧАСТЬ пояьзовйтельског; интерфейса

нать, какие еще товары заказали эти покупатели, чтобы составить

комплексный заказ или стандартный набор продуктов.

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

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

имена и фамилии покупателей, которые приобрели эти продукты, а

может быть, поставщиков, продавших эти продукты компании?

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

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

Оба описанных способа отображения данных для связи многие ко многим не являются взаимоисключающими. Например, можно

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

......II.....