Теория и практика построения баз данных (1088289), страница 74
Текст из файла (страница 74)
Такие ггылкп особенно полезны для материализации ссылок на другие семантические пбьекты пли сильные сушности. Например, в форме на рпс. 10.7 ссылки на интересы клиента можно заменить гиперссылками. Когда пользователь гцелкает мышью ~ш такой ссылке, открывается форма АЙТ15Т с соответству1ошимп даннымн. То же гпиое можно сделать и со ссылками на произведения. Передвижение курсора и единообразная семантика клавиш При разработке форм также заслуживает внимания вопрос о работе курсора. Курсор должен передвигаться по форме легко и естественно.
Это обычно означаст, что движение курсора отражает логическую последовательность действии ко- ~ ~ечного пользователя по мере того как он читает документы с походными данными. Если предполагается, что данные будут вводиться в форму в процессе разговора по телефону, курсор должен отслеживать направление разговора. В этом случае следует выбирать такой закон движения курсора, который покупатель находит естественным и правильным.
То, как двигается курсор, особенно важно в момент возникновения исключительной ситуации и после нее, Предположим, что прп работе с формой, изображенной на рис. 10.7, была допушена ошибка — например, введен неправильный код штата. Форма должна обрабатываться так, чтобы курсор передвигался в то место, которое напрашивается логически. Например, приложение может 352 Глава 1О. Проектирование приложений баз данных Проектирование отчетов 353 вывести список допустимых значений штатов и поместить курсор в некоторую логичную позицию — например, на первый штат, аббревиатура которого начинается с первой буквы, введенной пользователем. Когда штат выбран, курсор должен переместиться обратно к полю 2!р — следующему по логике обработки полю формы.
Действие специальных клавиш, таких как Е5С и функциональные клавиши, должно быть согласова//ыыл! и единообразным. Если клавиша Е5С применяется для выхода из форм, используйте ее исключительно для этой цели и ни для какой другой (кроме тех действий,которые логически эквивалентны выходу из формы). Действие клавиш должно быть согласованным во всем приложении. Так, если клавиша Е5С используется для выхода из одной формы, она должна использоваться для выхода из всех форм. Если сочетание клавиш <йг! е <О используется для удаления данных в одной форме, то следует использовать его для удаления данных и во всех прочих формах.
В противном случае стереотипы действий, сформированные в одном месте приложения, приходится пересматривать в другом месте приложен!и. Это неэкономно, раздражает и дезориентирует пользователей и, наконец, приводит к ошибкам. Хотя сказанное здесь может казаться само собой разумеющимся, как раз внимание к таким деталям и делает форму простой и удобной в использовании.
Проектирование отчетов Проектирование отчетов (герогсв) весьма широко обсуждается в текстах, посвященных разработке приложений, — даже в большей степени, чем проектирование форм. Мы не станем повторять или даже пьпаться обобщать в данном разделе содержание атих дискуссий, а рассмотрим вместо этого несколько принципов, которые непосредственно касаются понятия отчета как материализации представления базы данных. Структура отчета Принципы проектирования хоро|них отчетов аналогичны принципам проектированыя хороших форм.
Как и в случае форы, структура отмета должна отражать структуру лежащего в его основе предстаолеыия. Это означает, что данные из одной таблицы должны быть, вообще говоря, размещены друг рядом с другом, в одном разделе отчета. Как и для форм, из этого правила имеется исключение: базовое отношение данного представления (например, отношение С05ТОМЕк для представления Сиз1отег) в отчете ыожет быть разбито на части.
Группы атрибутов, такие как Рйопе, должны также помешаться вместе и каким-то образом различаться, На рис. 10.12 показан пример отчета для галереи ь/!еьч Идяе, в котором приведены данные по каждому произведению искусства и по транзакциям, осуществленным с этими произведениями, вычислена общая прибыль по каждой работе и каждому автору, а также итоговая прибыль. ТоФа! твгд|п 1ог Зооги Ток|его Етегащ Зеве, Сору 106/195 $860.00 То1а| твгд|п |ог Оопп!в Рппдв $850.00 Мень ТоЬеу Ранегпв 1И 27/95 Па|еАсящгеи Асягнвн|опрнсе пв1еЗо15 ЗоЫ То Зв1еврг|се бговвМвгд1п 9/11/1971 Соорег, Топ| $10,000.00 $2,500.00 3/18/1986 Засквоп, ЕОгаЬе!П $15,000.00 $3,500.00 10/17/1999 Соорег, Тога $21,000.00 $4,000.00 $7,500.00 $11,500. 00 $17,000.00 7/ЗИ 971 1/4Л 986 9/11/1 999 Тога| тагдпп |ог Рапегпв 10, СОРУ 27/95 $10,000.00 Мага ТоЬеу Ииуйпп Па|еАсяигеИ Асясивньопрг1се 2/76 ПтеЗоМ Зощ То Зв!евРг1се Оговвмагдьп $17,000.00 7/14/2001 НеОег, Мах $27,000.00 $10,000.00 ТоФа! тагд|п гог Иьу|ип|, Сору 2/76 $10,000.00 4/8/2001 То1в| п|вгд!п 1ог Мага ТоЬеу $20,000.00 Огепи То|в1: $20,850.00 Рис.
10.12. Отчет о продажах Структура отчета на рис. 10.12 отражает структуру обьекта 1/УОРК. Раздел, посвященный каждому произведению, начинается с названия произведения, которое включает нмя автора (АП/зФагпе), наименование (Т!г!е) и копию (Сору). Далее идет раздел с повторяющимися строками, которые описывают транзакпии с данным произведением. В каждом разделе указывается имя покупателя, взятое из таблицы С05ТОМЕк. Имейте в виду, что с помощью большинства генераторов отчетов трудно сконструировать отчет, который проходил бы схему базы данных более чем по одному многозначному пути. Отчет на рис.
10.12 является материализацией представления АкТ15Т, которое следует по пути АкТ15Т вЂ” 1/!/ОкК вЂ” ТкА7!5АСТТО!1, На диаграмме связей, изображенной на рис. 10Л, д, показан другой путь — через таблицу С05ТОМЕй АкТ15Т Т!1Т к таблице С05ТОМЕй, то есть к клиентам, которые Проектирование отчетов 355 Рис. 10.13. Объект РНОНЕ-НЕОЮЫ 354 Глава 10. Проектирование приложений баз данных интересуются работами данного художника. В большинстве генераторов отчетов будет трудно построить такой отчет, который показывал бы оба этих пути. В отчетах зачастую фигурируют вычисленные значения атрибутов, которые не входят в соответствующее представление и не хранятся в базе данных.
В отчете на рпс. 10.12 таких атрибутов четыре — 6гон Магя!и (прибыль от транзакции), То1а1 Маго1п Ьу Мог!к (прибыль от произведения), То1а1 Магййп Ьу Айвт (прибыль от художника) и 6гапб Тота1 (суммарная прибыль). Значения всех этих атрибутов вычисляются «на лету», в момент создания отчета. Хотя эти вычисленные значения можно было бы хранить в базе данных, в действительности это редко имеет смысл, поточу что значения, на основе которых они вычислялись, могут измениться. Если, к примеру, пользователь изменит значение атрибута 5а?езРпсе для некоторой транзакции и не вычислит повторно суммарную прибыль и все итоги, зависящие от этого атрибута, то хранимые в базе данных значения окажутся неверными.
Однако осуществление всех вычислений, необходимых при обновлении, может вызвать недопустимо медленную обработку. Следовательно, подобного рода итоги лучше всего, как правило, вычислять «на лету». Формулы для вычисления таких итогов рассматриваются, таким образом, как часть материализации отчета, а не представления, лежащего в его основе. Подразумеваемые объекты Рассмотрим запрос «Вывести всех авторов, отсортированных по итоговой прибыли». На первый взгляд может показаться, что здесь запрашивается отчет об объекте АКТ?5Т. Однако слова <...отсортированных по...» указывают, что необходимо рассматривать более одного такого объекта. Фактически, запрос относится не к объекту АКП51, а к объекту, который можно обозначить как «множество всех объектов А!?Т!5Т».
В отчете на рис. 10.12 приведены данные по множеству авторов, и в действительности этот отчет основан па объекте «множество всех объектов АКТ15Тгн а пс на обьекте Ак??51. Человеческий разум так быстро переходит от объекта А к объекту «множество всех объектов А», что мы, как правило, даже не чувствуем, что произошло какое-то нзменеппе. Однако при разработке приложений баз данных важно отслеживать этот сдвиг, поскольку, когда оп происходит, приложение должно вести себя иначе.
Рассмотрим три способа, которыми сортировка может изменить природу базового объекта: (1) сортировка по объектному идентификатору; (2) сортировка по неидснтифицируюшим, необъектным столбцам; (3) сортировка по атрибутам, входящим в состав объектных атрибутов. Сортировка по объектному идентификатору Если данные в отчете должны быть отсортированы по значению атрибута, являюшегося идентификатором объекта, подлинным запрашиваемым объектом является совокупность таких объектов. Так, отчет об объекте АКТ?5Т, данные в котором отсортированы по значению атрибута Ай?нйаюе, является на самом деле отчетом об об ьекте «множество всех объектов АкТ?5Т».
1?ля большинства генераторов от- четов, входящих в состав СУБ??, составить отчет об объекте «множество всех Х» ие сложнее, чем составить отче~ об объекте Х. Тем не менее, важно знать, по про- изошло изменение типа объекта. Сортировка по неидентифицирующим, необъектным столбцам Когда пользователю нужен отчет, данные в котором отсортированы по атрибуту, который нс является идентификатором объекта, реальныи объект, присутствующий в воображении пользователей, имеет, скорее всего, совершенно другой тип. Пусть, например, пользователю нужен отчет об авторах, отсортированньш по атрибуту Найопа?1(у (национальность). Такой отчет является на самом деле материализацией объекта МАТ?ОНАЕ?ТУ, а не объекта АКТ?5Т.
Аналогичным образом, если пользователь запрашивает отчет о покупателях, отсортированный по атрибузу Агеабоде, на самом деле базовым объектом для отчета является объект под названием РНОНЕ-РЕ6?ОН (региональный телефонный префикс) или нечто подобное. Па рис. 10,13 представлен пример объекта РНОНЕ-ВЕ6?ОН, Такие объекты, как МАТ?ОНЯЕ?ТУ и РНОИЕ-КЕ6?ОЙ, являются подразумеваемыми обьекшами (!шр1!ест оЬ?естз), то есть их существование следует из того факта, что пользователь запрашивае~ подобного рода отчет.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
