Программирование >>  Реализация целостности данных 

1 ... 84 85 86 [ 87 ] 88 89 90 ... 124


ГЛАВА 1 вду сущностями мами системы

Иерархические структуры

Теоретически, любое отношение один ко многим представляет собой иерархическую структуру, обычно термин для характеристики связей, в которых участвуют три и более наборов данных, Каждый из элементов, расположенных на более высоком уровне иерархии, участвует зи один ко многим с элементами более низкого уровня. Иерархические структуры часто применяют в моделях данных, но отображать их в пользовательских формах приходится значительно реже (рис. 14-5).

Customers

) 4

Orders

1 <


Рис. 14-5 гиение между сущностями Customers (Покупатели), Orders (Заказы) и Order Details (Информация о заказе) представляет трехуровневую иерархическую структуру

Если в системе используется такая структура, то в большинстве приложений будет следующая архитектура: в форме Customers (Покупатели) данные о заказе представлены в виде сводной таблицы (если в этой форме вообще есть данные о заказе). Данные, относящиеся к сущностям Orders и Order Details, представлены в отдельной форме Orde (Заказы). Форма Orders ссылается на сущность Customer, однако в этой форме представлена только связь один ко между сущностями Orders и Order Details. И лишь в очень небольшом числе случаев может потребоваться создать форму, где данные из всех трех таблиц: Customers. Orders и Order Details, - отображаются одновременно.

Сложно сказать, почему возникла это стремление - при проектировании пользовательского интерфейса избегать в формах иерархических

структур. потому, что случаи, когда их действительно необ-

ходимо достаточно редки; кроме того, подобные структу-

ры довольно трудно представлять в удобном для восприятия виде. Предположим, что заказчик настаивает на том, чтобы включить в форму, предназначенную для ввода и редактирования данных о покупателях, возможность просматривать информацию о заказах. Эту функциональность в системе легко реализовать, отображая записи из таблицы Orders (средний уровень в иерархии) по одной, а записи из таблицы Order Details ~ все сразу. При этом придется в форме Customers, позволяющей вводить и редактировать данные о покупателях, использовать в качестве подчиненной форму, показанную нарис. 14-2.



ЧАСТЬ 3 Проаийрй8а*ше попьзойлпгяльокогокятерфейса

Вероятнее всего, в форме Customers нельзя отображать все записи,

относящиеся к сущности Orders, одновременно. Ведь подобная можность нужна пользователям, чтобы узнать, сколько заказов поступило покупателя, или на какую сумму в среднем он делает заказ и т. п. Вряд ли, открывая форму Customers, пользователи заинтересуются данными, относящимися к конкретным продуктам. Но им будет весьма сложно ответ на эти вопросы, если все

записи, относящиеся к таблице Orders, отображаются в форме Cus-

одновременно.

Можно отображать в форме Customers только агрегированные данные о заказах, позволив пользователям открывать вспомогательную форму Orders, если им будут нужны более подробные сведения. К со-такой подход имеет ряд серьезных недостатков.

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

главной формы Customers информация о каждом заказе представлена

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

Чтобы избежать всех эти miocic н, до недавнего времени иерархическую структуру всего отображали в виде дерева. Элементы унравления, позволяющие это сделать - очень действенный и удобный инструмент и, пожалуй, его единственный недостаток - объем данных, отображаемых пользователю на каждом уровне иерархии, очень ограничен, поскольку все данные должны умещаться в одной строке. Из-за такого ограничения нам, скорее всего, не удастся использовать дерево для представления иерархической структуры: легко ли разместить в строке всю информацию о покупателе?

К счастью, в версии -t: 2000 и Visual Basic 6 включены новые средства, позволяющие отображать дополнительную информацию для элементов основной формы в виде отдельного набора записей. Подчиненные табтщь: (subdatasheets) Access 2000 поддерживают представление иерархических структур в виде схем, позволяющих рать разные уровни детализации при просмотре (рис.

Хотя но внешнему виду подчиненные таблицы уступают многим другим способам представления данных деревьям), они

практичны и удобны. Подчиненные таблицы позволяют реализовать

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



ГЛАВ Стш межд Т9ми и формами системы

подчиненную таблицу, в которой данные из таблиц Addresses (Адреса) и Orders (Заказы) представлены как элементы одного и того же уровня. Настраиваемый табличный элемент управления Hierarchical Flexgrid в Visual Basic версии 6 позволяет отображать иерархическую в том же виде, что и подчиненные таблицы в Microsoft Access. Различие одно - число вложенных наборов записей на каждом уровне иерархии для этого элемента управления не ограничено.


10692. Рмооск, MejrfieW 10702 Peacock, Мщатчл 10635 OarolJO, Nancy 10952 Dsrrolb, Nancy 1101! LBWrlhB, Janet

\A- p

: M! i:.i Mi.fchBfi

JU7i3- Ltfjuniip, rti**

10 PEDnack, MjdTd

; ISJiHtlSSB. lB.War-]e

3I.OCII937 24-Nov-l997

27Дрг-1ЭЭв 07.Мау13Эе

!3-1 р-1Э9а IS-Or

13 ОЙ.199? UnilBd package 21 Oct-lS97 Speedy E*prei! 21-j2iv199e Fedlral Shippinc; 24.Mar-199B Speed) EHptess 1Э-Ар-1ЭЭ6 Speedy Express

HSflvSSe FwlsrSI.EhlpplnJ

1E1D2

E3 94 I 1E9 53 ]

S121 ]

(000 ..

11 81

Puc, 14-6. Подчиненные таблицы Microsoft Access 2000 позволяют отображать данные иерархических структур

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

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

Связи многие ко многим

И, наконец, последний тип связей - это связ огие ко многим , представленные в базе данных тремя или более таблицами.



1 ... 84 85 86 [ 87 ] 88 89 90 ... 124

© 2006 - 2024 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки.
Яндекс.Метрика