WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 3 | 4 || 6 |

«Press Riordan DESIGNING Relational Database Systems Press Ребекка Райордан реляционных баз данных Москва 2001 Р УДК 004 32.973.26-018.2 Р45 Р. ...»

-- [ Страница 5 ] --

Иногда нужно выбирать несколько значений из каждой записи, причем пользователю будет отображаться множество записей одно Используйте с непрерывным режимом просмот ра, если вы работаете с Access (рис. 14-2), и настраиваемый таблич ный элемент управления или иерархическую таблицу Microsoft Hierar chical FlexGrid, если используете Visual Basic. Таблицы Microsoft Access — чрезвычайно мощное средство, иногда даже слишком ное. Помимо текстовых полей, в них несколько видов дополнитель ных элементов управления. табличные элементы (grids) в Visual Basic порой осложняют создание пользовательских приложе ний, а иерархические таблицы позволяют только отображать данные в виде иерархически организованных структур, но не редактировать эти счастью, в Access и Visual Basic арсенал средств, управление данными, достаточно широк. Например, подчинен ные формы в Access позволяют отображать записи в режиме непре рывного просмотра, и таким образом, пользователь видит на экране сразу несколько записей. В версии 6 Visual Basic появился новый объект предоставляющий практически те же возможно сти, что и подчиненная форма Access, хотя реализованы эти два эле мента управления по-разному. Каждый из них там, где нужно отображать пользователю множество записей и при этом ис пользовать тип элементов управления, не поддерживаемый в подчи ненных таблицах и настраиваемых табличных элементах управления (например, группу связанных параметров). Оба эти элемента управ ления: и подчиненные и объект Data Repeater, — позволяют каждую запись на несколько строк при отображении ее в форме пользовательского интерфейса.

Еще один элемент управления, часто применяемый для отображе ния множества записей в форме — дерево. Как правило, дерево ис пользуют для отображения иерархических структур с различной сте пенью детализации, но с его помощью можно также реализовать про смотр дополнительной информации для каждой из записей, хотя ре дактировать данные записи с помощью дерева не очень удоб но. Приняв концепцию, подобную той, что используется в Microsoft ЧАСТЬ Windows Explorer, можно отображать пользователю дополнительные данные, относящиеся к выбранной записи, в другой части формы.

И наконец, в тех случаях, когда пользователям нужно выбирать не сколько значений из списка, подойдет связанная пара списков. По добная структура часто используется в мастерах. Вот пример из масте ра таблиц Microsoft Access 2000: списки Sample Fields и Fields in my new образуют связанную пару (рис. Как правило, пользователи легко осваиваются с подобными элементами управления, однако та кие списки создают немало проблем для разработчиков.

. Связанные списки в мастере Access Связанные списки применяют для первоначального ввода данных, но они не предоставляют пользователям возможности просматривать и изменять введенные данные. Кроме того, связанные списки зани мают слишком много места. Вот почему такие структуры, как прави ло, используются в мастерах, где каждая отдельная ввода выполняется из нового диалогового окна. же пользователь, выб рав несколько элементов из уже не будет впоследствии про сматривать весь список, то использовать связанные списки не имеет смысла. Лучше остановиться на одном из уже обсуждавшихся нами элементов управления, или на списке, позволяющем выбрать не сколько элементов.

позволяющие выбрать несколько элементов, очень удоб ны, но применять их следует с Просматривая такие списки, пользователи могут по ошибке отменить уже сделанный вы бор элементов. Особенно часты такие ошибки, когда для выбора но вого элемента требуется щелкнуть его мышью, а не поставить фла ГЛАВА или переключатель в положение. Когда данные приходится выбирать из длинного списка, отсортировать добавлен ные в список, удаленные и выбранные записи нелегко. Воз можно, лучше применить обычный список, где выбранные элементы отображаются в сочетании с текстовым полем или комбинированным окном, добавлять записи.

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

Контролировать числовые значения, вводимые в текстовые поля, маска ввода в Microsoft Access и элемент управления в Basic — по крайней мере, вы можете запретить вво дить в поля символы алфавита и специальные символы. В Access так же есть множество средств, позволяющих интерпретировать введен ные данные. Но проверять правильность данных, когда они уже вве дены, — не самый лучший вариант, и если есть возможность ограни чить диапазон допустимых значений, то нужно использовать именно этот метод.

В Visual Basic 6 появились два новых элемента управления для вво — Picker (рис. 15-6). В Access 2000 имеется элемент управления аналогичный Month View в Visual Basic.

• • Ли. ? 1 2 5 11 12 r ". 13 1Э • 11 : 25 : • 13 20, 08/04/ 15-6. Элементы и DateTime Picker Элементы управления, обеспечивающие пользователям возмож ность ввода даты, по своей функциональности напоминают окна со списками и комбинированные списки: DateTime Picker выводит на экран окно календаря, только когда пользователь щелкает стрелку рядом с полем, в котором отображается а элемент уп равления отображает календарь постоянно. Особо что и MonthView, и Picker работают только со значениями дат, а не с датой и временем одновременно. Поэтому если их связать с полями таблиц баз данных, для которых выбран тип данных Date/ Time, то придется предусмотреть дополнительные средства преобра зования формата. Уделите особое внимание средствам работы с дан ными, даты.

И в Visual Basic, и в Microsoft Access присутствует элемент управ ления UpDown, также называемый циклическим счетчиком. Он ис пользуется для ввода числовых значений и данных в формате Date/ Time в операционной системе Windows, и поэтому знаком большин ству (рис. Элементы управления UpDown приме няют там, вводимые значения изменяются циклически: например, введенная дата — один из семи дней недели. Или если вводимые дан ные нужно округлить до числа: например, числовое значе ние — до ближайшего целого десятка.

11 12 13 15 16 18 20 21 22 23 25 27 29 I 7. Для времени в Windows используются элементы управления UpDown И, наконец, еще один вид управления Visual Basic, ко торые используются для ввода числовых величин — это бегунки (slider controls) и полосы прокрутки (scroll bars), показанные на рис. 15-8.

ГЛАВА and 15-8. Бегунки и полосы прокрутки для ввода числовых величин Эти элементы управления чрезвычайно редко применяют в при ложениях, работающих с данных. Они — всего лишь графи ческие средства, позволяющие задавать числовые значения некото рых параметров, и поэтому в их можно использовать для ввода числовых данных.

ПРИМЕЧАНИЕ вы и не предполагали, что полосы прокрутки можно использовать как элементы, работающие с числовыми данны ми — их практически нигде не упоминают в таком качестве. Действуют они так: когда пользователь ставит рычажок полосы прокрутки в оп положение, то она передает приложению числовое значение параметра, регулируемого при помощи этой полосы (разумеется, все про исходит незаметно для пользователя).

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

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

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

В Microsoft Access допустимые значения вводимых данных можно ограничить при маски ввода (свойство Input Mask текстового поля), а в Visual Basic — при помоши элемента управления Оба этих элемента управления позволяют задать шаблон, которому должны удовлетворять вводимые данные. Например, для индивидуального номера системы социального страхования в США маска ввода будет (три за которыми дефис, затем две цифры, снова дефис, четыре цифры).

В отдельных случаях маска ввода очень полезна, но к сожалению, задать ее удается не часто. Кроме того, при этом есть риск чрезмерно ограничить диапазон допустимых Самый простой пример — номера хранящиеся в базе данных. Очевидно, соблазн ис пользовать маску ввода для поля, моделирующего телефонный номер, велик. Однако прежде чем делать это, выясните, будут ли в базе дан ных храниться номера телефонов частных лиц или организаций, на на территории страны, или же нужно будет вводить и иностранные номера. Очевидно, что число цифр и формат телефон ных номеров в разных странах не совпадают. Но даже если база дан ных будет содержать телефонные номера, относящиеся к одной не, все равно трижды подумайте: ведь при междугородних звонках кроме телефонного номера абонента часто требуется набирать раз личные коды городов. А в крупных организациях, насчитывающих множество отделов, иногда применяется добавочный внутренний мер, чтобы соединиться с конкретным сотрудником.

Никогда не забывайте, что ваша главная цель — обеспечить пользо вателям максимум удобств при работе с системой. Если же система запрещает ввод абсолютно правильных данных, просто потому что подобная ситуация не была предусмотрена при проектировании и ГЛАВА формат вводимых данных ограничен слишком жестко, то это серьез ный недостаток.

Помимо стандартных текстовых полей в Access и Visual Basic име ется элемент управления Microsoft Rich вводить текст, отформатированный с помощью различных стилей и гарнитур шрифтов. Однако реализация этого элемента управления, как прави ло, требует много времени и усилий, поскольку кроме поля, позволя ющего вводить текст, нужен дополнительный интерфейс, задавать свойства текста.

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

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

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

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

Поддержка целостности базы данных ГЛАВА Представьте себе такую вы, владелец небольшой компа нии, потратили немало сил в борьбе за перспективного клиента. В результате клиент согласился разместить у вас выгодный заказ, одна ко поставил условие: заказ должен быть выполнен в течение 48 часов.

что это вам вполне по силам, вы начинаете праздновать победу, Но тут «на сцену выходит» главный бухгалтер и сообщает, что не пишет договор, не проверив, располагает ли клиент достаточным кре дитом, а такая проверка займет не меньше недели. Что делать в такой ситуации? Скорее всего, вы объясните главному бухгалтеру, что в ключительных случаях можно пойти на некоторые нарушения жившихся правил. Бухгалтер — обычный человек, а большинство людей, как правило, не спорить с начальством и делают (или, по крайней мере, стараются сделать) то, что им приказано.

Компьютерные системы не обладают столь же покладистым харак тером и с ними гораздо сложнее чем с человеком.

Они часто отказываясь выполнять абсолютно разумные и логичные с точки зрения пользователя действия, и при этом приво дят абстрактный аргумент — «поддержка целостности данных». В пре дыдущих главах мы уделили много внимания вопросам целостности данных, ее отражению в модели данных и реализации на программ ном уровне. И вот теперь, объяснив вам, как это делается, я выскажу мысль, которая разом перечеркнет все мои предшествующие замеча ния: поддержка целостности данных — не самая важная си стемы.

ЧАСТЬ Предвидя возгласы и протесты, спешу уточнить: я от нюдь не призываю отказаться от проверки правильности данных. Я просто пытаюсь объяснить, что целостность базы данных гораздо ме нее важна, чем способность системы служить пользователю и помо гать ему в каждодневной работе. И вы должны соответственно спро ектировать вашу систему. хранящиеся в памяти компьюте ров, должны быть но это отнюдь не означает, что они должны быть абсолютно верными в момент их ввода.

Остановитесь на минуту и подумайте: для чего вообще нужна раз рабатываемая вами система? Чтобы помогать людям выполнять их боту. Поэтому такая проверка правильности данных, которая помо гает пользователям выполнять их работу, полезна, поскольку она со ответствует целям компьютерной системы. А если проверка правиль ности данных мешает пользователям выполнять отдельные действия в том порядке, который для них наиболее удобен или который они считают целесообразным, либо не выполнять те которые пользователи считают разумными и полезными, но которые не были предусмотрены на начальных этапах проектирования систе мы, то такая проверка, безусловно, вредна.

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

Классы ограничений целостности В главе 4 мы определили шесть различных видов ограничений относящихся к различным логическим уровням в реляцион ной модели. В этой главе мы рассмотрим вопросы реализации целос данных под другим углом зрения и воспользуемся иной клас сификацией, Разделим все ограничения целостности на два класса:

внутренние (intrinsic constraints) и ограничения, опреде ляемые особенностями веления бизнеса, называемые также правилами (business rules).

Внутренние ограничения регулируют физическую структуру дан ных и диктуются реляционной моделью. Например, ограничение, ГЛАВА запрещающее запись из Customers (Покупатели), если в Orders (Заказы) имеются связанные с ней записи, — это ограничение, поскольку ссылочная целостность — это часть модели. При удалении из базы данных записи о покупателе, но без удаления всех записей о заказах, сделанных ным покупателем, база данных будет находиться в несогласованном состоянии. Если впоследствии добавить в нее запись о покупателе, значение первичного ключа которой совпадет со значением первич ного ключа удаленной то осиротевшие записи о заказах, сде ланных покупателем, информация о котором удалена из базы, могут быть ошибочно связаны с новой записью. Такая вероятна, если определить значение первичного ключа на поле, которое содер жит фамилию покупателя.

Но и когда возможность повторного использования значения пер вичного ключа полностью осиротевшие записи могут причиной большой путаницы и причинить немало неприятнос тей. Например, запросы, в которых вычисляется общее количество продуктов, проданных компанией за период времени, могут выдавать разные результаты в зависимости от того, ся ли в процессе выполнения запроса соединение таблиц Orders и Чтобы получить полный список проданных со держащий информацию о том, какие продукты и в каком количестве приобрел каждый из покупателей, используется естественное нение таблиц Orders. В этот список войдут только те запи си из таблицы для которых имеются записи в таблице и, следовательно, только эти данные будут ис пользованы при вычислении общих объемов продаж. Осиротевшие записи в таблице Orders отсутствуют в наборе результатов, получив шемся в результате соединения Customers и Orders, и, следова тельно, не будут учтены в вычислениях. Однако если при вычисле нии объемов продаж использовано соединение таблиц Pro осиротевшие записи будут присутствовать в наборе результатов и учитываться в вычислениях. Таким образом, на вопрос «Какое ко личество товаров было продано в июне?» система даст два разных ответа, в зависимости от способа выполнения запроса. Что, разуме ется, недопустимо.

В отличие от внутренних ограничений, бизнес-правила основаны на предметной области. Например, правило, выполнять каскадное удаление из таблицы Orders всех записей, относящихся к покупателю, данные о котором были удалены из базы, до тех пор пока все заказы, сделанные этим покупателем, не будут закрыты или — это бизнес-правило. определяют, что обыч но не делают в конкретной ситуации, а внутренние ограничения что вообще нельзя сделать. На практике, провести четкие раз личия между внутренними ограничениями и бизнес-правилами зача стую невозможно, да и не Важно лишь, что один из классов ограничений определяется предметной областью. Вы реализуете эти потому, что хочет или «так удобнее». Если же на самом деле пользо ватель совсем этого не или ему это неудобно, можете опустить эти правила и не включать их в разрабатываемое приложение.

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

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

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

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

Внутренние ограничения Правила проверки правильности введенных значений, называемые внутренними ограничениями, управляют внутренней структурой базы ГЛАВА данных. В этот класс входят правила, регулирующие тип, формат, длину данных, допустимость значений Null, а также ряд ограничений:

диапазона вводимых значений, на уровне сущностей и шие ссылочную Ограничения, налагаемые на тип данных Если при проектировании пользовательского интерфейса правильно выбран тип элементов управления, используемых для ввода и изме нения данных, пользователи редко нарушают правила, диктуемые системой. Вряд ли пользователь будет вводить дату или время в поле Amount Due (Число единиц отправляемого товара), це лочисленные значения, или пытаться ввести текст, работая с пере ключателем или флажком — такие действия возможны только по ошибке. Но пользователь может попытаться набрать в текстовом поле слово, а не число (например, ввести в поле Due слово «один надцать» вместо числа Поэтому правильности выбора элементов интерфейса следует уделять особое внимание.

Ограничения, налагаемые на формат данных Как правило, такие нарушения не слишком заботят пользователей и разработчиков, поскольку формат данных можно изменить, сразу после того, как они введены (в Microsoft Access есть средства, позво ляющие это сделать). Можно также задать маску ввода, гарантирую щую правильный формат вводимых данных. Однако не следует нала гать ком строгие ограничен на формат вводимых данных там, где этого не требуется. Если введенные данные не соответствуют мату, определенному ограничениями, то возможно, лучше оставить окончательное решение за пользователем. Предложите ему вариант форматирования, близкий к правильному, и предоставьте возмож ность повторно ввести данные в том формате, в котором он сочтет нужным. Конечно, не исключено, что введенные данные будут про сто неверны, но все же это бывает редко. Например, пользователь, который ввел в базу данных телефонный номер 9-9999-99999-99, воз просто пользовался новой системой офисной связи.

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

ЧАСТЬ Максимальная длина записи, которую можно ввести в такое поле, составляет 255 символов, Используя тип данных переменной длины, вы, несомненно, решите большинство проблем, с такими огра ничениями. В SQL можно явно тип данных для поля таблицы базы данных. И SQL Server, и Microsoft Jet. сохраняя данные этих типов, место на диске только для символов, в этих полях. Таким образом, хранение данных пере менной длины не приводит к дополнительному расходу дискового пространства.

Но поля переменной длины можно использовать не везде и не все гда. Во-первых, они не применимы, когда вводимое значение долж но содержать строго определенное число символов. инди видуальные номера системы социального страхо вания в США всегда состоят из девяти символов. Если пользователь введет индивидуальный номер, состоящий из десяти то проблема будет не в ограничении на длину данных, а в том, что вве данные неверны. Допускать ввод таких значений в базу дан ных Кроме того, SQL Server обновляет данные переменной длины го раздо медленнее, что может снизить производительность системы, впрочем, в большинстве случаев незначительно. Но в где время обработки данных играет решающую роль, особенно в тех, где данные интенсивно обновляются, рекомендуется данные, имеющие постоянную длину. (Особо отмечу, что добавление новых данных постоянной и переменной длины сказывается на изводительности одинаково, разница есть только при обновлении данных.) Хотя использование полей, допускающих очень большую длину, весьма удобно с точки зрения пользователей, вводящих данные, в других ситуациях оно может принести вред. Данные будут отобра жаться на экранах форм и в отчетах в неудобном для восприятия фор мате;

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

означающее «Company» или «Inc.», «Incorporated», ГЛАВА 16 данных Определяя правила, старайтесь исключить использование разных вариантов Например, такое правило: если в названии компании встречается слово «Company», оно до а все остальные символы, за этим словом, от брасываются. Тем самым вы исключите вероятность, что название компании «The Really, Really Long Name Company, Incorporated» бу дет введено разными пользователями раз как «Really, Really Long Name а другой — как «Really, Really Long, Ведь подобные ошибки могут привести к тому, что одна и та же компания будет уч тена в базе дважды.

Значения Null Отсутствующие — одна проблема нарушения внутрен них ограничений, с которой часто сталкиваются пользователи. В главах я уже говорила, что применение значений Null оправдано, если значение какой-либо величины может быть не или Разумеется, отсутствие того или иного параметра не должно привести к тому, что данные окажутся совер шенно непригодными. Если же вы отказываетесь использовать зна чения Null в системе, тщательно продумайте, как будет действовать пользователь, если ему нужно добавить новую запись в базу данных, а некоторые данные, которые требуется ввести, ему неизвестны.

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

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

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

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

Итак, не нужно требовать невозможного — чтобы в систему вво дились сразу все данные, к некоторой сущности. Всему свое время, и ввод информации в большинстве случа ев можно отложить.

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

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

Другой способ — предоставить пользователю возможность выбрать один из нескольких вариантов значений, например Unknown (Неиз вестно), Not (He используется) и Yef To Соте (Будет введе но позже). В некоторых случаях система может сгенерировать подхо дящее значение по умолчанию самостоятельно.

Ограничения, налагаемые на диапазон возможных значений Задание диапазона возможных значений — еще один из видов ограни чений на уровне атрибутов. Как и в случае со значениями сталки ваться с нарушениями этих ограничений приходится весьма часто. При этом пользователей и разработчиков подстерегают множество подвод ных камней.

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

ГЛАВА Если же подобные ограничения неприемлемы, и реальные значе ния, используемые в системе, превышают предельные, обусловлен ные типом данных, измените схему базы, выбрав другой тип данных, с более широким диапазоном допустимых значений. Но ни в коем случае не следует выполнять такие изменения, когда пользователи активно работают с системой — необходимо на время приостановить работу.

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

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

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

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

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

ЧАСТЬ if! Data you have to the do?

| • i дм fces^p have I Both be to the окно, сообщающее что новая запись в базе, повторяет Реализуя эту возможность, обратите особое на ясность интерфейса. Он должен содержать все комментарии, разъясняющие пользователю возможные варианты действий. Поза ботьтесь, чтобы данные, введенные пользователем, сохранились до окончательного разрешения вопроса с записью, Нельзя допустить, чтобы введенные пользователем данные пропали или были заменены другими без его согласия. Возможно такое реше ние: вывести уже в базе данных запись в отдельном окне и позволить выбрать: заменить ли введенную им запись уже имеющейся или оставить новую запись без изменений.

Обратите внимание на следующую особенность;

окно на рис. 16- позволяет пользователю продолжать ввод данных, не просматривая запись, которая предположительно является «двойником» вводимой.

Возможно, пользователь знает, что такая запись уже существует в базе, и лишний раз напоминать ему об этом не нужно.

Еще один распространенный случай нарушения ограничений на уровне сущности и ссылочной целостности — пользователь при вво де данных пропускает или оставляет пустым поле первичного ключа.

Чтобы этого избежать, часто используют уникальные значения пер вичного ключа, сгенерированные системой. Поля в Access и в SQL Server позволяют определить естественный внешний ключ таким образом, что пустые или повторяющиеся значения, вве денные пользователями, не приведут к нарушению целостности на уровне сущности или ссылочной целостности. Если по какой-либо причине вы не можете использовать поля AutoNumber или Identity в системе, позаботьтесь, чтобы при вводе данных пользователи обяза тельно заполняли все первичного ключа. Обычные значения по ГЛАВА 16 базы умолчанию здесь нельзя, поскольку они определяются для каждой таблицы отдельно. Конечно, можно применить значения, сгенерированные системой на этапе исполнения. Но если вы собирае использовать произвольные значения для первичного ключа, почему не применить поле Единственный альтернатив ный — всякий раз обращаться к пользователю, чтобы он ввел нужное значение.

При нарушении ссылочной целостности пользователь пытается обратиться к записи, которой на самом деле не существует. Такая ситуация может возникнуть случайно — например, когда пользова тель неправильно вводит имя. Ну, а если пользователь просто не знает, что записи, к которой он обращается, не существует, или же еще не ввел соответствующие данные в систему? Диалоговое окно на рис. 16- люстрирует способ разрешения подобной ситуации. Пользователь может выбрать один из четырех вариантов:

• создать новую запись в базе данных и сразу ввести всю необходи мую информацию;

• создать новую запись и ввести лишь часть данных, а впоследствии обновить запись;

• обратиться к другой записи;

• несуществующую ссылку позднее.

Unknown Рис. 16-2. окно, позволяющее ситуацию, когда пользователь обращается к данным Отмечу особо, что предоставить пользователю возможность на время отменить или игнорировать ограничение нельзя: тогда база данных будет содержать неверную информацию.

ЧАСТЬ Если нельзя предоставить возможность выбрать нужное значение из списка что такой список будет слишком велик, выведите на экран список значений, в большей или меньшей степени похожих на введенные данные. Для создания такого списка применяют разные алгоритмы — от простого LI KE до поиска в базе данных величин с использованием EX.

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

Другой случай, когда нарушаются ограничения ссылочной це лостности — попытка удалить или изменить запись, на которую в базе данных имеется ссылка. Например, пользователь может попытаться удалить запись о покупателе, сделавшем заказ, который еще не вы полнен, или изменить значение уникального номера Product для продукта, на который имеется ссылка в таблице Microsoft Jet поддерживает механизм каскадных обновлений и уда лений данных, что позволяет обновлять и удалять записи, на которые имеются ссылки, без дополнительных запросов системы к пользова телю. В SQL Server можно реализовать те же возможности при помо щи триггеров. Каскадные обновления и удаления данных — очень способ автоматического разрешения проблем при наруше нии ссылочной целостности. Я рекомендую использовать его везде, где это возможно (разумеется, решение принимают системные ана литики и Однако если вы предоставляете лю возможность выбирать, что надлежит делать при нарушении ссы лочной целостности, не забудьте подробно ему, к чему каждое из предложенных действий.

ГЛАВА Диалоговое окно рис. предоставляет возмож ность отменить удаления, удалить текущую запись и все связанные с ней (то есть выполнить каскадное или переопределить ссылки таким образом, чтобы связать все открытые заказы с другим покупателем. Обратите внимание;

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

The to delete ha* do?

, - !••.

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

Ваша цель — дать всю информацию для принятия осоз нанного, обоснованного Бизнес-правила Итак, мы рассмотрели внутренние ограничения, струк туру баз данных и данных. Когда действия пользователя приводят к нарушению внутренних ограничений, число вариантов действий, предпринимаемых для устранения этой ситуации, весьма ограничено. Данные должны, пусть даже не сразу, а при наступлении определенного события, удовлетворять реляционной модели. Но нарушение ограничений, налагаемых бизнес-правилами — совсем другой случай.

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

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

ПРИМЕЧАНИЕ Третий — это когда пользователи намеренно вво дят неправильные с целью дестабилизировать работу системы.

Самые строгие а едва ли помогут защитить систему от умышленной порчи данных. К счастью, подобные случаи очень Случайные ошибки при вводе данных Средства для исправления случайных ошибок, допущенных при вво де данных, должны быть простыми и удобными, поскольку подобные ситуации весьма не редки. нужно объяснить пользовате лю, как исправить ошибки. Альтернативные варианты следует пре дусмотреть везде, где только Рассмотрим диалоговое окно, отображаемое при неверном вводе даты: когда означающие месяц и число, переставлены местами 16-4). Система предлага ет пользователю наиболее вероятный вариант даты в правильном формате, и если он подходит, то для исправления данных достаточно всего лишь щелкнуть мышью.

Когда пользователи случайно вводят неверные данные, это, как правило, либо результат оплошности, либо непонимания, какие имен но данные и в каком формате требуется ввести. Диалоговое окно на рис. 16-4 объясняет, что представляет собой поле Date (Дата доставки). Кроме того, пользователь может получить справочную информацию, щелкнув кнопку Help. О том, какие механизмы помо ГЛАВА щи пользователю реализовать в системе, мы поговорим под робнее в главе 18.

Date The Delivery the customer the to the system is unable to the date you have What you da?

• I about field. Диалоговое окно сообщает пользователю о вводе даты и предлагает возможные варианты действий Модель системы и реальность Чаще всего к вводу некорректных данных приводит несоответствие модели реальным условиям. Например, пользователь пытается ввес ти данные о заказе, который уже выполнен и доставлен клиенту, но по каким-то причинам еше не зарегистрирован в системе. Тогда дата доставки будет предшествовать дате оформления заказа, что, по всей вероятности, нарушит бизнес-правила. Если не предусмотреть стан дартный способ разрешения такой ситуации и не дать четких указа ний, что сделать в этом случае, пользователи могут ввести в поле, где должна быть указана дата доставки, произвольную дату, которая не противоречит бизнес-правилам и, следовательно, будет принята сис темой. В результате в базу данных попадет информация, не соответ ствующая действительности.

Итак, при проектировании системы и особенно при определении бизнес-правил следует проявлять особую стараясь предугадать как можно больше нестандартных ситуаций и по возмож ности пользователям способы выйти из них без нару шения данных. На рис. 16-5 показано диалоговое окно, которое появляется на экране пользовательского компьютера, если дата, введенная в поле Delivery предшествует дате, введенной в поле (Дата оформления В этом примере для ввода данных в поле OrderDate используется элемент не позво ляюшии вводить или изменять дату вручную;

по умолчанию подстав ляется текущая дата.

• Рис. 16-5. Это диалоговое окно позволяет заказ «задним числом» Однако не все бизнес-правила можно (и нужно) обходить, если данные им не Некоторые бизнес-правила отменить или игнорировать, и надо обязательно и учитывать, в каком случае и кем правило может быть нарушено. Рас смотрим пример: пользователь попытался ввести в базу данных ин формацию о шестом сотруднике, подчиняющемся менеджеру, кото рый уже руководит группой из пяти человек. Однако бизнес-прави ло, определенное для этой системы, жестко ограничивает число со подчиняющихся одному менеджеру, человеками (рис. 16-6).

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

ГЛАВА Поддержка базы данных а ' Number default, can report to a you would you do not. г..! т.'....'., •. • • Рис. 16-6, Диалоговое окно что только авторизованное может отменить действующее Возможность обойти бизнес-правила работу с системой намного удобней, но приведет к усложнению модели данных.

В приведенном примере в таблицу (Сотрудники) придется добавить дополнительное поле с информацией об авторизации запи си и включить в ограничение целостности данных ссылку на код ав записи.

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

Часто нужно объяснить, почему данная запись некорректна. Для этого следует добавить еще одно поле с соответствующим кодом: на пример, код МА будет означать, что запись должна быть на менеджером, а код СС — что для данного заказа еще не проверен кредит. Второй подход обеспечивает большую гибкость при ке записей. Но использование полей, содержащих код, усложнит си стему, если для каждой записи использовать разные значения кода.

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

Большинство изменений, которые нужно внести в систему для поддержки авторизации записей, несложны и вполне очевидны.

влияние, которое они могут оказать на систему в зачас тую трудно просчитать заранее. Например, следует ли включать в от четы неавторизованные записи? Если нужно выборочно исключать эти записи из отчетов, коды, причину отсутствия несомненно, поскольку именно они позволяют составлять простые запросы, указывая, какие записи следует исклю чить. Если же неавторизованные или неполные записи нужно вклю чать в отчеты, их при этом следует как-то особо например, сгруппировав и определив отдельный заголовок.

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

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

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

Создание отчетов ГЛАВА и средства, позволяющие их создавать — очень важная, едва ли не важнейшая, часть системы. разнородные сведения, хранимые в базе данных, не представляют ценности для пользователей, им нужны систематизированные данные. Эта глава средствам, позволяющим получать из довольно хаотичной массы данных, храни мых в памяти компьютерной системы, связную информацию.

ПРИМЕЧАНИЕ Под отчетом я отнюдь не подразумеваю всего лишь вывод на печать некоей информации, интерес для Я вкладываю в это понятие гораздо более широкий смысл, а именно:

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

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

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

Сегодня ситуация изменилась с точностью до наоборот. Компью теры ото все дешевеют, а рабочее время ного секретаря ценится весьма дорого. Теперь, если пользователю нужно получить «что-то вроде вот этого стандартного отчета, только с некоторыми он, несомненно, обратится не к сек ретарю, а к компьютерной системе. Соответственно, и у разработчи ков баз данных прибавилось забот. Им теперь приходится удовлетво рять требования пользователей в минимальный срок. Но ведь это го раздо чем корпеть над пишущей машинкой, не правда ли?

В компьютерных системах, основанных на базах данных, как пра вило, сочетают два подхода к созданию отчетов. Первый — разработ чики заранее определяют, какие отчеты понадобятся пользователям, и предоставляют им возможность генерировать по готовым шаблонам так называемые отчеты (standard reports). Второй пользователям средства, при помощи которых они могут составлять и генерировать самостоятельно или произвольные отчеты (ad hoc reports).

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

Сортировка, поиск и использование фильтров Средствами операторов SQL выполнить поиск, сортировку и рацию данных достаточно легко, соответствующие критерии задают с помощью ключевых WHERE или ORDER BY оператора SE LECT. Но чтобы пользователи могли задавать критерии самостоятель но, необходимо предусмотреть промежуточный слой программных компонентов. В самом деле, не вынуждать же их составлять запросы к данным при языка SQL, логика которого сильно отличает ся от конструкций языка, на котором мыслят и общаются обычные люди. Поэтому начинающие пользователи так часто ошибаются при составлении SQL-запросов.

Приведу только один пример. Допустим, для составления отчета менеджеру по продажам нужен список всех дистрибьюторов компа нии в штатах Вайоминг и Флорида. Очевидно, что продумывая этот отчет, менеджер пожелает включить в список всех дистрибьюторов в штате Флорида и всех дистрибьюторов в штате Вайоминг. Но в опе раторе SELECT языка SQL условие WHERE, формирующее список, будет выглядеть примерно так: WHERE State «Wyoming» OR State = «Florida». Как видите, здесь используется логический оператор OR ГЛАВА (или), а не логический оператор AND (и). Подобные лингвистичес кие тонкости могут сбить с толку любого новичка!

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

К счастью, чтобы разработать подобный интерфейс, не нужно на чинать «с нуля». В Microsoft Access уже имеются соответствующие интерактивные средства, позволяющие пользователям создавать зап росы к данным с использование критериев SQL. Конечно, прямой перенос механизмов пользовательского интерфейса из одного при ложения в другое не всегда возможен, однако само наличие подоб ных средств оказывает большую помощь разработчику, позволяя ему использовать уже готовый образец. В Visual Basic аналогич ных средств существует, однако их реализация займет не так уж много времени.

Сортировка данных В Access реализован простой и удобный позволяющий быстро отсортировать данные в нужном порядке. Для указания спо соба сортировки имеются две команды — Sort Ascending (Сортировка в порядке возрастания) и Sort Descending (Сортировка в порядке убы Щелкнув мышью элемент интерфейса, по которому нужно выполнить сортировку, пользователь затем выбирает соответствую щую команду в меню Records (Записи) Можно также соот кнопку на панели управления.

Фильтр по выделенному фрагменту в одном поле Для фильтрации данных в одном поле в Access имеются две команды:

фильтр по фрагменту Filter By Selection по вы деленному) и фильтр исключения выделенного фрагмента Filter Exc luding Selection (Исключить выделенное). Эти команды похожи что используются для сортировки данных — Sort Ascending и Sort Descending. Когда пользователь выделяет все содержимое одного из полей формы или задает фокус ввода на это поле и затем выбирает команду Filter By Selection, Access применяет фильтр по этому полю, отбирая только те записи, которые в точности соответствуют выде ленному значению. На SQL условие WHERE, эквивалентное этому фильтру, можно записать таким образом: WHERE = Если пользователь выделяет только несколько первых символов в поле и применяет фильтр по выделенному фрагменту, Access вы бирает только те записи, которые начинаются с выделенных симво лов в этом поле. Рассмотрим пример — базу данных по ставляемую вместе с Access. Если пользователь выберет три символа в названии продукта Chartreuse и применит фильтр по полю Product Name, то на SQL условие WHERE, эквивалентное это му фильтру, можно сформулировать так: WHERE [Product Name] LIKE Этот фильтр ограничит набор тремя записями с соответствующими названиями продуктов: Chartreuse verte, Chai и Chang.

Если же пользователь выделяет несколько символов не в начале поля, а где-нибудь в середине или в и применяет фильтр, то Access выбирает все записи, которые содержат выделенные в этом поле. Например, если выбрать символы в названии про дукта Chartreuse verte, то эквивалентное выражение WHERE на SQL запишется так: WHERE fProduct Name] LIKE Результат при менения этого фильтра базе данных содержит десять за писей (рис.

39 Chartreuse Esc 72 Giovanni 20 Rodney's au sucre Bob's pried Pears 17-1. Результат применения по выделенному фрагменту в поле Name ПРИМЕЧАНИЕ Говоря об эквивалентах языка SQL, я имею в лишь что соответствующий вернет те же результаты, что и при менение фильтра. Трудно с уверенностью сказать, что происходит на самом деле, когда пользователь выбирает команду By Selection — ли Access SQL-запрос с использованием оператора SELECT ГЛАВА или использует какие-то другие методы обработки данных. К сожале нию, мне неизвестны описания внутренних механизмов выполнения команд, позволяющих фильтровать данные в Access.

Фильтр по заданным значениям в нескольких полях Команда Filter By Selection предоставляет пользователю простой и удобный интерфейс, но у нес есть и недостаток — данные с ее помо щью можно фильтровать только по одному полю. Чтобы еще более ог раничить результирующий набор записей, пользователю придется вы полнить команду Filter By Selection еще раз, задав новый критерий и используя набор результатов, полученный в результате применения первого фильтра. Это неудобно, особенно если команду приходится выполнять несколько раз, каждый раз используя новый критерий. Для пользователей, которые нуждаются в более средствах фильт данных, в Access имеется команда Filter By Form (Изменить фильтр). На рис. 17-2 показан вид формы Customers из базы данных после того как в меню Records была выбрана эта команда.

Рис. 17-2. Команда Filter By Form позволяет фильтровать no нескольким полям открываемое по команде By Form, позволяет задать значения полей, используемых для фильтров. В нем имеется несколь ко вкладок, на каждой из которых можно указывать значения полей.

Все значения, заданные на вкладке Look For (Найти), будут объеди нены логической операцией И (AND), а ко всем параметрам фильт ра, указанным на отдельных вкладках Or (Или), будет применена ло ЧАСТЬ ИЛИ (OR). Данная концепция построения интер фейса, хотя и вполне продуманная, порой все же трудна для воспри ятия пользователями. Дело том, что использование логических раций И и ИЛИ для фильтрации наборов данных и значение, вкла дываемое в союзы «и» и «или» в большинстве европейских языков, различаются.

По умолчанию в окне, открываемом по команде Filter By Form, каждое текстовое поле исходной формы представлено комбинированное окно, содержашее все значения, храни мые в этом поле. Вывод списка, все значения, можно отключить. Для этого следует на вкладке, позволяющей задать свой ства текстового поля, для параметра Filter Lookup авто фильтра) выбрать значение Never (Никогда). Когда при задании кри териев фильтра вывод полей исходной формы в виде комбинированного окна, при фильтрации записей в результирующий набор включаются записи, в которых значения соответствующих по лей точно совпадают со значением, выбранным пользователем в ком бинированном окне. Если же автофильтр не используется (то есть для параметра Filter Lookup выбрано значение Never), пользователь мо жет ввести в это поле значение, используемое для поиска записей, точно совпадающих с ним, или выражения для поиска: например LIKE или IS NOT NULL. Решение, использовать ли авто фильтр или предоставить пользователям право самостоятельно зада вать критерии поиска, от того, сколько записей будет со держать комбинированное окно автофильтра (очевидно, заставлять пользователя просматривать 100 тыс. записей не имеет смысла), а так же от необходимой гибкости интерфейса.

Расширенный фильтр Команда Filter By Form и связанный с ней, в большин стве случаев удовлетворяют потребности и пользователей, и разработ чиков. Но если пользователи знакомы со средствами создания запро сов в Access, или если вы решили предоставить пользователям возмож ность выбирать значения для фильтра из комбинированного списка и вводить выражения, используемые в качестве критериев фильтра, то больше подойдут средства расширенного фильтра. Для этого в меню Records выберите команду Advanced Filter/Sort (Расширенный фильтр) и задайте параметры фильтра в полях открывшего ся диалогового окна (рис.

ГЛАВА 17-3. Диалоговое окно, открывающееся при выборе команды Advanced Filter/Sort при работе с формой Customers базы данных Некоторые элементы окна расширенного фильтра совпадают с элементами окна запроса, открываемого в режиме конструктора. Од нако в отличие от интерфейса построения запроса, интерфейс рас ширенного фильтра позволяет задавать лишь параметры, используе мые в выражениях WHERE и ORDER BY оператора SELECT. Он не разрешает структуру набора запи сей: например, изменить список полей или выполнить соединение с наборами записей.

Интерфейс средств расширенной сортировки Access достаточно сложен, и создать интерфейс с аналогичными возможностями в Visual Basic нелегко. При необходимости предоставить пользователю такой интерфейс лучше выберите в качестве средства разработки Access или готовый продукт третьей фирмы, который можно встроить в систему.

Средство построения запросов Microsoft English Query Если при проектировании базы данных используется не механизм СУБД Access, a SQL Server, в качестве построения запросов.

очевидно, будет применен Microsoft English Query. Кроме пользова тельского интерфейса, позволяющего выполнять сортировку и филь данных, средство English Query предоставляет командный ин терфейс, дающий возможность составлять запросы к данным на есте ственном языке.

Для возможностей English Query в своем приложении свяжите терминологию предметной области, моделируемой в систе ме, со схемой базы данных. Для этого создайте объект, который в English Query называется файлом приложения (application file). Это не ЧАСТЬ трудно, хотя задача не столь тривиальна, как может показаться на первый взгляд. Создание этого файла похоже на предмет ного указателя справочной системы: нужно составить полный спи сок слов, которые будут использоваться для называния схемы базы данных и их атрибутов.

Дальнейшая English Query в приложение базы данных несложна. Приложение просто передает вопрос пользователя, сфор мулированный на английском языке, механизму обработки запросов English и в обработки получает готовый оператор SQL.

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

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

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

Отчеты в виде списков и подробные отчеты Используйте отчеты в виде списков и подробные Отчет ввиде списка представляет собой списки всех экземпляров сущностей (про ще говоря, полный набор всех записей), имеющихся в базе данных.

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

или по регионам;

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

Так, торговому скорее всего, не понадобится список всех зарегистрированных в системе — ему нужны будут лишь те, кого обслуживает он сам.

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

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

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

Выделить же диапазон отмеченный символами тире, или от дельные записи, разделенные запятыми, совсем не сложно.

Отчеты, использующие агрегированные данные В этих отчетах агрегированные данные различным образом комбини руются и сравниваются между собой. Типичные примеры таких отче тов — распределение объемов продаж по регионам с указанием доли от объема продаж, приходящейся на каждого из торговых агентов;

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

использующие агрегированные данные, удобно выдавать пользователю в графическом представлении. Для интер претации данных в отчетах можно применить Microsoft Graph и дру гие графические средства. Но я рекомендую использовать графичес кое представление данных в дополнение к обычному их пред ставлению в виде или текста и ни коем случае не заменять графикой данные в текстовом формате. Данные отчета о числе продаж, представленные в текстовом виде, можно импортировать в другое приложение Microsoft Excel) и использовать для статистического анализа и прочих манипуляций.

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

Реализовать ее очень легко, а пользователям она наверняка пригодится.

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

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

Интерфейс для создания отчетов Разработка средств для создания отчетов в пользовательском интер фейсе не доставляет значительных трудностей. Если для создания от чета используется команда Print Report (Печать отчета), то ет несколько способов включить ее в пользовательский интерфейс:

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

Удобней всего включить команду в состав меню. В этом случае вполне достаточно указать названия отчетов в меню Reports (Отче Если для печати отчетов используется кнопка на панели управ ГЛАВА название отчета можно вывести на всплывающей подсказке этой кнопки. Не следует указывать во подсказке или в названии кнопки только название отчета, который будет распечатан — обязательно укажите и команду, выполняемую при щелчке кнопки.

Так, всплывающая подсказка или надпись на кнопке Print Customer Listing (Печать списка покупателей) гораздо информативнее, чем про сто Customer Listing (Список пользователей). Пункты меню, напро тив, должны быть как можно более краткими. Так, пункт Customer Listing в меню Reports вполне уместен и достаточно информативен.

Данные рекомендации относительно названий пунктов меню и дру гих элементов интерфейса соответствуют общепринятым используемым при разработке интерфейса для Windows.

Теперь остается ответить еще на один, не менее важный вопрос;

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

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

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

Обработка ошибок принтера Система должна предоставлять возможность исправлять ошибки и разрешать различные связанные с принтерами. Иногда ре ализовать эту возможность непросто, например, если пользователь захочет распечатать все отчеты, которые еше не были распечатаны.

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

Я рекомендую ошибки, связанные с принтером, исключения — таковыми по сути, они и В ситуации, когда требуется распечатать только те отчеты, которые еще не были напе чатаны, придется добавлять одно поле в соответствующую базы данных. Если от пользователя требуется подтверждение, что от четы распечатаны правильно, то очевидно, нужно добавить поле Yes/ No или булеву константу. При другом способе подтверждения печати отчета можно хранить в соответствующем поле дату ГЛАВА или номер задания печати, присвоенный принтером. А чтобы проблемы, возникающие при печати, добавьте допол нительную команду, позволяющую пользователю ввести коммента рий, если при печати отчета возникали какие-либо проблемы. Этот комментарий можно связать с отчетом или с соот ветствующим заданием печати.

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

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

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

Итак, процесс печати достаточно сложен и может сопровождаться различными ошибками и затруднениями. Поэтому я по возможности стараюсь разделить процессы создания отчетов и обновления запи сей в таблицах, сделав их абсолютно независимыми друг от друга ЧАСТЬ зумеется, за исключением обновления тех полей таблиц, где хранит ся признак успешной печати отчета). Если же сам рабочий процесс определен таким образом, что обновление записи жестко связано с печатью отчета, то наиболее разумно дальнейшее вы полнение всех задач в рамках этого рабочего процесса, пока пользо ватель, сгенерировавший отчет и отправивший его на печать, не под твердит, что отчет успешно распечатан.

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

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

Отчеты, являющиеся частью рабочих процессов (например, сче та-фактуры) можно выводить на печать и по отдельности, и группа ми. Например, распечатать каждый счет сразу же после того, как пользователь введет всю информацию о заказе. Или же объединить в одну группу счета, которые еще не были распечатаны, и отпра вить их на когда пользователь закончит ввод данных о приня тых заказах. Первый вариант уместен, если используется локальный принтер, а второй — если принтер сетевой. Кроме того, полезно пре доставить пользователю возможность выбрать один из двух способов (и принтеров) — ведь конфигурация сети может изменяться, а локаль ные и сетевые принтеры — добавляться и удаляться.

Некоторые разработчики предпочитают автоматически создавать отчеты, которые должны выводиться на печать через определенные промежутки времени — например, каждую неделю или в конце каж дого месяца. Я не возражаю против такого способа, однако предпо читаю в дополнение к печати предоставить ГЛАВА возможность распечатывать эти отчеты самостоятельно, по отдельной команде.

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

а также отслеживать, был ли отчет распечатан в указанное время, или произошли какие-либо ошибки.

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

Вряд ли, однако, имеет смысл реализовать автоматическую генера отчетов только потому, что пользователи могут забыть распеча тать еженедельный, ежемесячный или квартальный отчет — это почти исключено. Но полезно предусмотреть возможность создать этот отчет после указанной даты, если пользователь все-таки о нем забудет. На пример, вы можете задать определенный период для отдельного вида отчетов и использовать его по умолчанию, разрешив пользователям изменять это значение. В этом случае разрешите пользователям пере носить дату создания отчета не только назад, но и вперед.

Пользовательские отчеты Иногда удается настолько четко определить и разграничить рабочие процессы, поддерживаемые СУБД, что можно заранее спланировать все отчеты, которые будут создаваться в системе. В этом случае, оче видно, можно ограничиться стандартными отчетами. Однако чаще приходится предоставлять пользователям большую свободу — само стоятельно задать определенные параметры отчетов или даже созда вать новые отчеты.

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

Средства создания отчетов Если для создания отчетов вы используете Access или средство, раз работанное сторонними фирмами-производителями, реализовать в системе пользовательские средства для создания отчетов будет не сложно. Однако новое средство для создания отчетов Microsoft Data Reports, поставляемое вместе е Visual Basic версии 6, не годится для создания пользовательских отчетов, поскольку для работы с ним тре буется установить средства разработки на каждый из клиентских ком пьютерОЕ:.

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

Высокая стоимость средств для создания пользовательских отче тов не единственный фактор, ограничивающий их применение. От нюдь не достаточно просто средства для создания про извольных отчетов — нужно еще научить пользователей с ними тать. Чтобы составить произвольный отчет, недостаточно просто знать, как работать ео средствами для создания нужно ра зобраться в структуре базы данных, чтобы включить в отчет именно те данные, которые нужны. Такое обучение требует времени, а пользо ватели — занятые люди. У них есть которую они должны полнять, и создание произвольных отчетов отнюдь не входит в спи сок их непосредственных служебных обязанностей.

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

ГЛАВА отчетов кое решение порой рациональней, чем включение в систему коммер ческого программного обеспечения, предназначенного для создания отчетов. Теоретически возможно создать утилиту, обладающую столь же широкими возможностями, как и средства Access, и поддерживаю схему базы данных разрабатываемой системы. Однако это тре бует много сил и времени. Поэтому разработчики обычно предпочи тают более простые решения и включают в систему готовые шаблоны отчетов. А пользователь может выбрать, какие именно данные вклю чить в отчет.

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

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

Мой собственный подход к созданию отчетов отличается от того, который применяется в мастере Access, Я выделяю два компонента в пользовательских отчетах и условно называю их «формат» и «крите рии». К формату я отношу элементы отчета, определяющие макет и стиль, а также поля таблиц, которые должны быть включены в отчет (и возможно, таблицы и запросы, используемые для создания та). Реализация компонентов формата проста;

как правило, это отчет, созданный в Access, или объект Visual Basic Data Report, модифицируемый в зависимости от заданных пользователем крите риев (как они определяют порядок сортировки и параметры фильтра). Кроме того, я обычно добавляю к отчетам средства, позво ляющие сохранить заданные критерии, чтобы использовать их впос ледствии (подробнее об этом я еще расскажу). Иногда полезно пре доставить пользователям возможность различным образом группиро вать данные при составлении отчетов, однако в большинстве случаев это не нужно.

ЧАСТЬ 3 пользовательского Поскольку при таком подходе пользователи имеют дело только с двумя компонентами, требующих задания определенных параметров, для генерации пользовательских я использую диалоговое окно (рис. Если вы решите последовать моему примеру, то по лагаю, вам придется лишь немного изменить вид этого окна, чтобы адаптировать его к пользовательскому интерфейсу своей системы.

Report Д Рис. 17-4. Диалоговое окно для создания отчетов Диалоговое окно разделено на три области. В левой находится окно просмотра с древовидной структурой, где перечислены все име ющиеся виды форматов. Пользователю предлагается выбрать подхо дящий для отчета. Если список имеющихся форматов доста точно компактен и прост, можно не древовидную струк туру, а дать возможность выбрать элементы форматирования из спис ка или с помощью переключателей. В рассматриваемом примере фор маты представлены в виде дерева и сгруппированы по категориям.

Это если список форматов, определенных в системе, доста точно велик. форматы по категориям, например «Ад министративные отчеты», отчеты», «Статистика про и т. п.

Еще один уровень иерархической структуры в левой области окна — отчеты. В данном контексте отчет есть не что иное, как набор ненных критериев и формат. Например, указав для параметра Region (Регион) в отчете по статистике продаж значение Southwest (Юго-За падный), пользователь может сохранить этот отчет под названием Region Sales (Продажи в Юго-Западном регионе). Порой, если приходится задавать достаточно много параметров, это суще ственно экономит время.

В центральной части диалогового окна на рис. пользователь жет задать критерии для сортировки и фильтрации данных. Иногда уда ется спроектировать пользовательский интерфейс так, чтобы с помо щью одного набора элементов управления задавать параметры всех ГЛАВА форматов, а также делать недоступными для те элементы, которые не применимы к выбранному типу формата. Порой для каждо го формата приходится создавать уникальный набор критериев — и со ответственно, набор элементов управления, задать чис ленные значения для этих критериев. Я предпочитаю по возможности придерживаться варианта, где тип формата набор доступных элементов интерфейса. При этом все форматы подразде ляются на отдельные категории, определяющие, какие элементы управ ления доступны пользователю, а какие нет.

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

Щелкнув кнопку Save Or Restore Criteria или восста новить критерии), пользователь откроет одноименное диалоговое окно (рис. 17-5). В его части находится группа элемен тов управления, позволяющих выбирать критерии для отчета. Она полностью идентична группе элементов в центральной части основ ной формы составления пользовательских отчетов — диалогового окна на рис. В списке, размещенном в левой части (рис. 17-5), представлены сохраненные пользователями критерии отчетов. Когда пользователь выбирает одно из названий в этом списке, в средней части окна отображаются соответствующие параметры. Щелкнув кнопку Save As (Сохранить как), пользователь может ввести новое имя и сохранить критерий, задав для него соответствующие параметры в центральной части диалогового окна. Кнопка Restore позволяет вос становить прежние параметры выбранного критерия и загрузить его в основную форму создания отчетов.

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

1 - Save or Restore Рас, 17-5. сохранять новые и прежние критерии пользовательских отчетов Оба этих подхода отнюдь не являются Вы можете реализовать систему так, чтобы каждый пользователь выбирал, как из так и из своего собственного набора критериев. Чтобы реализовать такую возможность, либо добавьте поле, содержащее фа милию и имя пользователя, в таблицу, где хранятся критерии, либо отобразите результат выполнения операции UNION над общей и локальной Я предпочитаю, чтобы фамилии и име на пользователей хранились в критериев — облегчает под держку системы, когда один и тот пользователь регистрируется и работает за разными а не на одном рабочем месте.

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

Но иногда целесообразно связать критерии с определенным фор матом отчета (рис. Реализация такого подхода также не пред ставляет сложностей. Потребуется создать таблицы для каждого критерия (можно использовать таблицы, созданные для сохранения ГЛАВА критериев) и промежуточную таблицу, которая форматы и определенные критерии (рис. 17-6).

17-6. Структура для и и отчетов В Report Categories (Категории отчета) есть поле Table Name таблицы категории). Это позволяет в си стеме ту таблицу, которая содержит критерии, к ука занной категории формата отчета. Если структура критериев одина кова для всех поле в таблице не нужно. Если же для раз ных форматов используются разные наборы критериев, оно обяза тельно должно быть включено в таблицу Report Formats.

Важно, что данная структура таблиц (рис. 17-6), позволяет кон фигурировать отчеты на этапе исполнения программы. Поля For matName (Название и (Имя объекта) включены в таблицу Report для поддержки этой воз можности. Если форматы отчетов определяются как объекты базы данных (например, отчеты Access) или как отдельные файлы (другие средства создания отчетов), вы можете «обходной чтобы реализовать возможность добавить отчет в систему на этапе исполнения клиентского приложения. Для этого нужно разместить список форматов, отображаемый в форме пользовательского прило жения, в таблице Report а не использовать жестко заданный список.

Чтобы добавить в систему новый отчет, создайте новый объект, формат (в Access это отчет, в других средствах созда ния отчетов — отдельный файл) и затем добавьте запись в системную таблицу Report Новый формат будет автоматически включен в систему и доступен всем пользователям, причем это никак не по влияет на функциональность ядра системы. Поле содер жит название формата, отображаемое пользователю в списке тов, а поле PhysicalName — реальное имя объекта и путь к нему (если объекты хранятся не в самой базе данных).

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

письма Стандартные письма — это особый вид пользовательских отчетов.

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

Я не считаю пользовательские отчеты СУБД лучшим для составления писем: и тех, которые содержат один и тот же текст, и тех, содержимое которых меняется в зависимости от ситуации. Хотя возможности отчетов в СУБД весьма широки и их список продолжает пополняться, все же они не сравнимы с возмож ностями, предоставляемыми текстовыми процессорами. Кроме того, большинству пользователей необходимо редактировать текст письма, однако предоставить им возможность изменять текст, хранимый в базе данных, нецелесообразно, поскольку все изменения, внесенные в стандартный текст, невозможно отменить впоследствии. Вот поче му в большинстве случаев нерационально использовать отчеты для со ставления стандартных писем.

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

Организовать обмен данными между текстовым процессором и ба зой данных очень легко. Вы можете использовать возможность ния данных из различных документов Microsoft Office или команду MailMerge, указав таблицу или запрос Access в качестве источника данных. Затем при помощи Visual Basic for Applications (VBA) вставь те в документ данные из базы и выведите готовый документ на экран ГЛАВА пользовательского компьютера для дальнейшего редактирования или отправьте его на печать.

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

Рис. 17-7. Структура, позволяющая абзацы стандартного текста, которые могут быть в письма Если же нужна возможность редактировать письма перед отправ кой их на печать, то хранить текст писем в базе данных нецелесооб разно, поскольку ни Access, ни Microsoft SQL Server не предоставля ют удобных и быстрых средств работы с большими фрагментами тек ста. В этом случае в базе данных следует хранить только имена физи ческих файлов писем и путь к этим файлам. Разумеется, в системе должны быть предусмотрены механизмы отслеживания и обработки ситуаций, когда зарегистрированный файл был перемешен, переиме нован или удален. Как правило, в этом случае от пользователя требу ется выполнить какие-либо дополнительные действия или ответить на вопросы системы.

Итоги Мы рассмотрели различные аспекты предоставления пользователю на основе данных, хранимых в системе. Как правило, под этим подразумевается создание отчетов, которые впоследствии могут быть распечатаны. Другие виды предоставления информации пользователю — в виде формы или набора данных, помещенных в таблицу.

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

Даже если вы не используете Access в качестве инструмента разработ ки, приведенные примеры окажутся весьма полезны — ведь подоб ЧАСТЬ возможности очень часто необходимы пользователям, и их реа лизуют во многих компьютерных системах.

Мы рассмотрели также различные виды стандартных отчетов, в том числе отчеты в виде списков и подробные отчеты, а также отче ты, использующие агрегированные данные, и отчеты на основе форм пользовательского интерфейса. Я рассказала о различных способах интеграции средств создания отчетов в интерфейс пользователя, а также об устранении возникших при создании отчетов. Мы подробно остановились на некоторых аспектах создания пользова тельских отчетов, и обсудили конкретные способы реализации этих отчетов. И в заключение, были рассмотрены широкие возможности поиска и обработки данных, предоставляемые СУБД, для создания стандартных писем, Как вы могли убедиться, возможности современ ных компьютерных систем позволяют сочетать мощные средства ра боты с с возможностями текстовых процессоров.

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

Поддержка пользователя ГЛАВА Поддержка пользователя — достаточно широкое понятие. Все, о чем мы говорили в третьей части книги, подпадает под это определение. Ваша при проектировании интерфейса — создать для пользователя удоб ное рабочее место. Например, данных, которую мы обсуж дали в 16, позволяет облегчить пользователю безошибочный ввод данных. В этой главе мы рассмотрим более обшие формы поддержки пользователя, применяемые при построении интерфейса системы.

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

Поэтому следует не просто рассматривать технические аспекты поддержки, но и учитывать нюансы требований различных групп пользователей. Помните также, что уровень подготовки пользовате лей меняется по мере их работы с системой. Так что пусть диалоговое окно, выводимое на экран при загрузке программы и приглашающее ознакомиться с основами системы, содержит флажок Don't show me again (He показывать в следующий раз). Вклю чив этот флажок, опытный пользователь отменит вывод диалогового окна на экран при последующих загрузках программы. Сообщения интерактивных подсказок обычно никого не раздражают, но все же следует предусмотреть механизм их отключения.

Старайтесь не отсылать пользователя к документации. Интерфейс должен предоставлять полную информацию о реализованных в нем функциях, Большинство систем выполнить одно и то же действие разными способами. Например, сохранить изменения в записи мож но, выбрав пункт Save (Сохранить) в меню File (Файл), нажав соот кнопку на панели управления или при помощи сочета ния клавиш Каждый из этих способов называется команды, а каждый вектор команды чаще использует определенная группа пользователей. Новички, еще не знакомые со всеми особен ностями системы, охотней задействуют меню, более опытные — гра фические элементы управления, а эксперты — сочетания клавиш. Что бы пользователь смог подобрать для себя наиболее подходящий спо соб, интерфейс должен предоставлять полную информацию о воз можных векторах команд.

рис. показан пункт меню File системы Microsoft Access 2000, выводимый по умолчанию, Заметьте, что пункт Save показывает также и все вектора команд. Легко запоминающаяся комбинация выделена с помощью подчеркивания, буква S — первая в слове Save <буква F в пункте File также подчеркнута). Показана также соответ ствующая кнопка меню комбинация клавиш Предоставляя столь подробную информацию, интерфейс способствует обучению пользователя в процессе работы.

Рис. Пункт меню File приложения Access 2000 предоставляет о всех векторах команды Save ГЛАВА ПРИМЕЧАНИЕ Microsoft Visual Basic не позволяет показывать изображе ния командных кнопок в соответствующих пунктах меню, хотя ствуют компоненты ActiveX сторонних производителей, которые под держивают такую Парадигма создания меню в Access позволяет вставлять в пункты меню изображения, однако реализована эта возможность столь неуклюже, что вам почти придется использовать Button Editor для создания собственных графических эле ментов. И Visual Basic, и Access позволяют легко к коман дам определенные комбинации клавиш.

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

Пассивные механизмы поддержки Пассивные механизмы — это ярлыки, указатели, которые включены в интерфейс. В отличие от реактивных, пассивные меха низмы не требуют от пользователя каких-либо действий.

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

Запоминающиеся сочетания клавиш Сочетания клавиш позволяют выполнять операции наиболее быстро.

Комбинации клавиш выполняют роль пассивного механизма поддер жки и всегда выделяются подчеркиванием в названиях соответствую щих элементов управления. Любой более-менее опытный пользова тель Microsoft Windows знаком с парадигмой «сочетание клавиши Alt и подчеркнутого символа».

При разработке системы назначьте определенное сочетание кла виш каждому элементу меню каждого элемента управления. Опреде лите, какой символ вы будете использовать в этом сочетании. Суше определенные определяющие выбор символа. Таки ми символами могут быть:

• первая буква названия элемента управления или пункта меню;

• вторая согласная в элемента управления;

• звонкий гласный в названии элемента управления.

И в Access, и в Visual Basic определить сочетание клавиш нетруд но: просто вставьте специальный символ (&) в название команды или элемента управления перед тем символом, который будет использо ваться в сочетании клавиш. Обе системы выделяют этот символ под черкиванием. (Чтобы использовать символ непосредственно в сочетании клавиш, вам придется вставить перед ним еще один такой символ: команда меню Nuts & Bolts будет отображаться в интерфейсе пользователя как Nuts а вот комбинация Nuts && Bolts — как Bolts).

Всплывающие подсказки Назначение всплывающей подсказки очевидно — проинформировать пользователя о назначении кнопок на панели и тех элементов, кото рые не сопровождаются надписями (рис. 18-2).

Рис. 18-2. Всплывающая подсказка для кнопки Save (Сохранить) панели инструментов Access Form View ПРИМЕЧАНИЕ Когда всплывающая подсказка используется для элемен тов управления, не являющихся кнопками панели инструментов, ее на зывают ярлыком. И всплывающие ярлыки, и всплываю подсказки работают совершенно одинаково, и я буду говорить о них как о всплывающих подсказках.

Всплывающие подсказки делают работу с системой значительно удобней. Если вам когда-нибудь приходилось выбирать картинку, адекватно назначение элемента управления, вы знаете как это трудно. Одно дело — выбрать графический элемент для ки Save — практически каждому пользователю знакомо изображение дискеты в пакете Microsoft Office. А вот какое изобра жение подойдет для кнопки Open Customer которая открывает ГЛАВА форму ввода информации о заказчике? Вы можете поместить на эту кнопку маленькую человеческую фигуру, но что тогда использовать для форм Employees (Сотрудники) и Vendors (Поставщики)? Изобра жения на кнопках могут ввести пользователя в заблуждение.

К счастью, подсказки решают эту проблему. Они дают возможность пользователю запомнить назначение кнопок.

Например в Microsoft Access кнопка с изображением рыбы открывает форму Customers (Покупатели). (Интересно, что проектировщики хотели этим сказать?) Разумеется, пользователь, впервые увидевший эту панель инструментов, не сможет без под сказки определить назначение кнопки с изображением рыбы. Но по лучив подсказку, он в дальнейшем будет ориентироваться без труда.

Чтобы вставить всплывающую подсказку в Access или Visual Basic, достаточно присвоить значение одному из свойств элементов управления. Текст всплывающей подсказки должен быть коротким — не больше двух-трех слов. Помните, что основное на значение подсказки — напомнить пользователю о назначении эле мента, а не обучить его работе с системой.

Все подсказки уникальны. Если элемент управления дублирует пункт меню, текст их подсказок должен быть одинаковым. Если эле мент управления не дублирует никакого пункта меню, используйте в качестве подсказки наиболее подходящий по смыслу глагол. Если панель управления содержит три кнопки, которые выводят на экран формы ввода данных о заказчиках, поставщиках и сотрудниках, при мените в качестве подсказок соответственно Customers, Suppliers и Employees. Если же одна из кнопок отвечает за вывод информации о заказчике на экран, а другая — за печать этой информации, вам при дется использовать фразы типа Open Customer Form (Открыть форму Заказчик) или Maintain Customers (Поддержка заказчиков) — для пер вой, и Print Customers (Распечатать информацию о заказчиках) — для второй кнопки.

При применении изображений в пользовательском интерфейсе очень важно соблюдать ряд правил и разграничивать изображения, представляющие данные и действия. Я обычно провожу такое раз граничение, а затем использую комбинацию изображений из этих двух групп там, где это нужно. Если изображение перечеркивающего объект крестика связано с операцией удаления, а изображение человека — с таблицей заказчиков, разумно использовать комбинацию этих ражений, чтобы обозначить действие «удалить запись о (рис. 18-3).

Рис. 18-3. Такая интуитивно понятна большинству пользователей Строка состояния Строка состояния — стандартное средство пассивной помощи пользо вателю. в нижней части окон, строки состояний отображают различную важную информацию, например, нажата ли клавиша Num Lock или Caps Lock. Строки состояний отображают также пользовательские сообщения.

Заметьте, что форма Categories развернута на весь экран, так что строку состояния в нижней части экрана можно принять за часть эгой формы. На самом деле строка состояния принадлежит главному окну Access (рис. 18-4).

18-4, Строка состояния отображается в нижней части главного окна Access позволяет отображать информацию об элементах управле ния. Для этого поместите соответствующий текст в свойстве Status BarText этих элементов. Если вы не сделали этого для элемента уп равления, связанного с полем какой-либо таблицы, в строке состоя ния будет отображаться значение свойства поля Description (которое вы можете задать, редактируя свойства таблицы в режиме Design view). Насколько мне известно, Access не позволяет задать свойство StatusBarText во время исполнения программы на уровне кода, по ГЛАВА этому его нельзя использовать для отображения на экране пользова тельских сообщений.

В Visual Basic можно управлять отображаемым в строке состояния текстом, явно задав свойство Text элемента управления StatusBar.

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

Строка состояния никак не влияет на работу пользователя, в от личие, например, от диалогового окна. Она не перехватывает управ ление клавиатурой или мышью, выводя на экран сообщения. Факти чески, в Access (а также и в Visual Basic, если вы позаботились о соот ветствующей пользователь может запретить вы вод на экран с строки состояния.

В Visual Basic строка состояний пользователю о происхо дящих фоновых а также об ошибках времени выполнения.

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

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

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

Большинство реактивных механизмов представляет собой разно видность контекстных подсказок. Существует несколько парадигм их реализации, из которых мы рассмотрим всего две: традиционная кон текстная подсказка и всплывающие ярлыки. В некотором смысле, ЧАСТЬ сообщения об ошибках также можно отнести к реактивным и мы обсудим их в конце раздела.

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

Тщательно спроектированная контекстная помощь позволяет пользоваться всеми ее Создание справочной систе мы — это отдельная сложная задача, и мы не рассматриваем ее здесь.

Я лишь дам несколько касающихся справочных сис тем для баз данных, и порекомендую литературу.

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

Помните, что новички могут не подозревать о справочных систем, и им никогда не придет в голову нажать клавишу F1, если они попали в ситуацию. Вы должны рас сматривать справочную систему как дополнение к встроенной систе ме помощи, а не как ее замену. Многие проектировщики думают, что создав справочную они избавляют себя от необходимости проектировать встроенную систему подсказок. Это ошибка — про грамма без системы подсказок крайне неудобна использовании, Следующий вопрос — выбор способа поддержки пользователя.

Грубо контекстные справочные системы можно на две ка тегории: ориентированные на выполняемые задачи и ориентирован ные на выполняемые функции. Системы, ориентированные на зада чи, подсказывают пользователю, как достичь конкретной цели, на пример, распечатать счет-фактуру или отчет о встрече, Функциональ но-ориентированные системы поясняют детали выполнения конкрет ной операции (например, команды Print) или элемента уп равления (например, поля в форме пользовательского Обычно эти два вида справочных систем в пользователь ской документации соответствуют разделам «Руководство для пользо вателя» и «Справочный раздел», Если ваша система поддерживает очень сложные рабочие сы, лучше реализовать справочную систему, ориентированную на полнение Тем не менее, помните о необходимости встроенной справочной системы. Не следует выводить на экран алфавитный спи ГЛАВА ние даты, щелкнув мышью поле и введя другую дату. Нажмите для получения подробной Звуковые сигналы Звуковые сигналы, выдаваемые компьютером — мощное средство оповещения, но проектировщик может использовать их не только во благо, но и во зло. Простейший пример неадекватного использова ния звуковых сигналов — гудок, пользователя, что он совершил недопустимые действия.

Вместо того чтобы запугивать пользователя резкими звуками, луч ше сообщите ему что-нибудь приятное. Например, если введенные данные соответствуют всем необходимым требованиям, пусть компь ютер негромко произнесет что-нибудь вроде все верно». Но если возникла какая-то лучше всего вывести сообщение об ошибке в строке состояния, а не «звонить во все колокола», раздра жая пользователя и окружающих громкими звуками.

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

Не опасайтесь, что звуковые подтверждения, выдаваемые при пра вводе данных, создадут излишний шум в офисе. Да, фраза «ОК, все верно» должна на фоне офисного шума. Но мне приходилось использовать звуковые сообщения при проектировании систем телефонной связи, когда в одной комнате находилось более одновременно операторов, и никаких проблем не возникало.

Сообщения об ошибках Очень жаль, но пользователей не считает сообщения об ошибках одним из видов помощи, воспринимая их, скорее, как зас луженное наказание. Конечно, это не так, ведь каждая ошибка — это очередной повод помочь пользователю. Хорошо воспитанный чело век, прося о помощи, не пытается сразу же обругать помощника, не доказывает, что в его проблемах виноват кто-то еще. Он ясно, доход чиво и вежливо объясняет возникшую проблему, и то, почему он об ратился за помощью.

«Хорошо воспитанная» компьютерная система ведет себя так же.

Она даже должна быть более вежливой, чем человек. Когда возникает ошибка времени исполнения, система обязана:

• объяснить пользователю на понятном ему что произошло;

• попросить о помощи;

• не просить пользователя сделать то, что система должна сделать самостоятельно;

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

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

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

должно быть написано вежливо. Пользователи оценят дружелюбие системы и, может быть, простят вам ваши ошибки. По мните, никто не совершенен.

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

Принцип активной помощи прост: система отслеживает действия пользователя и в случае необходимости сама предлагает ему помощь или подсказку, Например, Office Assistant (Помощник из приложе ний Microsoft Office) предлагает пользователям контекстные справки в зависимости от их действий.

Очень интересен такой механизм активной помоши, как интел лектуальный агент. Это программа, которой пользователь делегирует выполнение определенных задач. Ее обычно используют в Web-при ложениях для ответа на просьбы типа: «Найди мне этот товар за наи меньшую или «Предложи книгу, которая мне понравится». Но ничто не ограничивает область применения интеллектуальных аген ГЛАВА сок доступных форм, как это сделано в окне базы данных Access, и рас читывать, что пользователь непременно прочтет контекстную справку.

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

Помните, что контекстные справки не заменяют обучающих ма Единственная контекстной справки — подсказать пользователю, как действовать, а не когда или почему.

Если выполняется в несколько приемов, лучше не пы таться дать объяснение на одной странице, а разбить справку на не сколько разделов. Вынесите в заголовок наиболее существенные мо менты, а ознакомиться с подробностями предоставьте ссылки на соответствующие Функционально справочные системы поясняют пользователю, что и почему он должен делать. Большинство таких справочных систем скорее объясняют назначение элементов данных и элементов управления, нежели содержат информацию о функцио нальности. Некоторые СУБД, например Access, позволяют получить справку о встроенных функциях (таких, как Mid$).

Для работы с СУБД действительно нужны справочные разделы с информацией о сущностях, их атрибутах и ограничениях. Могут по надобиться и пояснения, касающиеся функциональности элементов управления: например, как по или как получить даты с помощью встроенного календаря.

При создании справочных разделов, объясняющих структуру дан ных в системе, представлять, в какой ситуации она может по надобиться пользователю. Если пользователь просматривает форму ввода заказов и элемент, называющийся Desired Delivery Date (Желательная дата доставки), вряд ли он станет нажимать клавишу чтобы узнать о назначении элемента — оно и так ясно. Специаль ная справка в данном случае — напрасная потеря времени.

Почему пользователю может потребоваться помощь? Может он не понимает, почему это поле уже заполнено — объясните ему, что такое значение по умолчанию, и как его изменить. Или тель попросил доставить ему товар «в любое время после первого чис ла текущего месяца» — объясните пользователю, что он должен ввес ти самую раннюю дату поставки. Попытайтесь на систему глазами самого пользователя.

Подсказки типа «Что это такое» Эти подсказки очень напоминают контекстные справки, за исключе нием способа вызова. Подсказку вызывают, щелкнув кнопку с симво лом вопроса на панели инструментов и выбрав затем элемент управле ния, справку о котором пользователь хочет получить (рис. 18-5).

open database object or window. To use this you install Active Desktop.

'!

18-5. Подсказка типа Что это такое» Такие подсказки тесно связаны с пользовательским интерфейсом.

Но неопытные пользователи часто теряются при необходимости их вызвать, и тому есть причина — вряд ли от кроет для себя этот вид справки, случайно нажав клавишу F1. Ско рее, он просто увидев внезапно возникшее на экране до полнительное окно с пояснениями.

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

Вообразите, что подсказка — это просто большой ярлык для ва шего элемента управления. Что бы вы в нем написали? Если для элемента управления Desired Delivery Date определить подсказку:

«Дата, когда заказчик хочет получить свой товар» — это мало помо жет пользователю. Чтобы предоставить полную информацию об этом элементе управления, напишите так: «Самая ранняя дата, когда това ры могут быть поставлены. По умолчанию товар должен быть постав лен через три дня после даты заказа, но вы можете изменить значе ГЛАВА ние даты, щелкнув мышью поле и введя другую дату. Нажмите F1 для получения подробной Звуковые сигналы Звуковые сигналы, выдаваемые компьютером — средство но проектировщик может использовать их не только во благо, но и во зло. Простейший пример неадекватного использова ния звуковых сигналов — гудок, оповещающий пользователя, что он совершил недопустимые действия.

Вместо того чтобы запугивать резкими звуками, луч ше сообщите ему что-нибудь приятное. Например, если введенные данные соответствуют всем необходимым требованиям, пусть компь ютер негромко произнесет что-нибудь вроде все верно». Но если возникла проблема, лучше всего вывести сообщение об ошибке в строке состояния, а не «звонить во все колокола», раздра жая пользователя и окружающих громкими звуками.

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

Не опасайтесь, что звуковые подтверждения, выдаваемые при пра вильном вводе данных, создадут излишний шум в офисе. Да, фраза все верно» должна выделяться на фоне офисного шума. Но мне приходилось использовать звуковые при проектировании систем телефонной связи, когда в одной комнате находилось более 100 одновременно работающих операторов, и никаких проблем не возникало.

Сообщения об ошибках Очень жаль, но большинство пользователей не считает сообщения об ошибках одним из видов помощи, воспринимая их, скорее, как зас луженное наказание. Конечно, это не так, ведь каждая ошибка — это очередной повод помочь пользователю. Хорошо воспитанный чело век, прося о не пытается сразу же обругать помощника, не доказывает, что в его проблемах виноват кто-то еще. Он ясно, чиво и вежливо объясняет возникшую проблему, и то, почему он об ратился за помощью.

«Хорошо воспитанная» компьютерная система себя так же.

Она даже должна быть более вежливой, чем человек. Когда возникает ошибка времени исполнения, система обязана;

объяснить пользователю на понятном ему языке, что произошло;

• вежливо попросить о • не просить пользователя сделать то, что система должна сделать • описать все действия, которые мог бы предпринять пользователь.

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

Ясное и написанное понятным языком сообщение поможет выйти из с наименьшими потерями. Если пользователь осознал суть проблемы, он скорее всего избежит ее в — конечно, подобной можно избежать вообще.

Объяснив пользователю дальнейшие действия, вы поможете ему справиться с проблемой самостоятельно. Не предоставляйте ему воз можности выбора, в которых он скорее всего запутается. Помните: то, что очевидно для вас как для вовсе не очевидно для пользователя. Не бойтесь объяснений, но и не увлекайтесь деталями.

Сообщение должно быть написано вежливо. Пользователи оценят дружелюбие системы может быть, простят вам ваши ошибки. По мните, никто не совершенен.

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

Принцип активной помощи прост: система отслеживает действия пользователя и в случае необходимости сама предлагает ему помощь или подсказку. Например, Office Assistant (Помощник из приложе ний Microsoft Office) предлагает пользователям контекстные справки в зависимости от их действий, Очень интересен такой механизм активной помощи, как интел лектуальный агент. Это программа, которой пользователь делегирует выполнение определенных задач. Ее обычно используют в Web-при ложениях для ответа на просьбы типа: мне этот товар за наи меньшую или «Предложи книгу, которая мне понравится». Но ничто не ограничивает область применения интеллектуальных ГЛАВА Web-приложениями. Можно спроектировать программу, студентам планировать свое расписание, например:

нятия по математике — до обеда, а языковые курсы — вечером».

Microsoft предлагает способа организации интеллектуального агента — с помощью Microsoft Office Assistant и Microsoft Agent. Боль шинство пользователей знакомы с скрепкой для бумаг» — Microsoft Office Assistant, но не каждый знает, что Office Assistant по зволяет обращаться к его интерфейсу из других программ. Office Assistant доступен только из приложений Office и не рас пространяется вместе с механизмом баз данных Microsoft Access.

Если вы работаете с Access (или любым другим средством разра ботки, поддерживающим элементы Microsoft ActiveX, включая Visual Basic), можете скачать Microsoft Agent SDK с Web-узла Microsoft. Этот пакет обладает расширенными возможностями, по сравнению с Office Assistant.

Microsoft Agent — очень занятная игрушка. Вы можете создавать свои с помощью SDK. Microsoft Agent также поддер живает голосовые сообщения. Мне очень нравится включенный в поставку Microsoft SQL Server 7.0 интерфейс Agent к.

жению Microsoft English Query — он обеспечивает обработку SQL-зап росов. Вообразите, что база данных представлена в виде заставки Microsoft Agent — каково?

Однако ни Office Assistant, ни Microsoft Agent не обеспечивают поддержку реакции на действия пользователя. Они интерфейс взаимодействия с пользователем, но обязанность связать действия пользователя и реакцию на них — целиком возлагается на разработчика.

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

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

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

ЧАСТЬ Опытные пользователи хотят как выполнять те или иные операции, и обычно им хватает встроенной контекстной Фактически, разница между помощью и обучением достаточно рас плывчата. Тем не менее, сложные системы могут потребовать созда ния специального курса и для опытных пользователей.

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

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

Мы рассмотрели три типа пассивных механизмов:

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

Словарь терминов абстрактная (

Abstract

en- бизнес-правило rule) tity) — сущность, моделирующая ограничение осно связи между другими сущностями. ванное на предметной области, а не вытекающее из реляционной агрегатная функция (aggregate теории, function) — функция SQL, возвра щающая суммарные значения. булево выражение (Boolean exp ression) — выражение, результа активная помощь пользователю том которого может быть либо (proactive user assistance) — меха значение True, либо False.

низм помощи пользователю, при создании которого стараются вектор команды (command vector) предугадать, где и какая именно — один из способов выполнения помощь может потребоваться.

команды в пользовательском ин терфейсе: например, при помо альтернативный ключ (alternate key) щи элемента меню или кнопки - в отношении, который не используется в каче- на панели управления.

стве внешнего ключа таблицы.

внешнее отношение (foreign rela аномалия обновления (update ano- tion) — отношение, получающее maly) — операции мани- внешний ключ от другого участ пулирования данными, возника- ника связи.

ющая в результате недочетов при внешнее соединение (outer join) создании модели данных.

соединение, возвращающее все атрибут (attribute) — столбец от- записи, присутствующие во реннем соединении, а также все ношения.

записи, присутствующие в одном база данных (database) — схема или в обоих других участниках базы данных и хранимые данные.

соединения.

Pages:     | 1 |   ...   | 3 | 4 || 6 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.