Опубликован: 02.08.2007 | Доступ: свободный | Студентов: 3126 / 427 | Оценка: 4.55 / 4.39 | Длительность: 27:09:00
ISBN: 978-5-9556-0111-3
Лекция 14:

Проектирование модулей приложений

Системные модули

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

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

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

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

Размещение логики обработки

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

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

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

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

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

Примерами правил для данных являются следующие:

  • Пол человека должен быть либо мужской, либо женский. Это правило может быть введено с помощью ограничения CHECK в определении колонки таблицы базы данных.
  • Каждый заказ должен быть предназначен для одного и только одного покупателя. Это правило для данных можно ввести с помощью ограничений PRIMERY KEY или NOT NULL.

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

Примерами правил для процессов являются следующие:

  • Размер зарплаты не должен превышать 160000 рублей. Это правило следует реализовать в приложении, в нем ничего не говорится о содержимом и определении базы данных. Оно выражает утверждение о том, что может быть, а чего не может быть.
  • Только руководитель может санкционировать выплату премиальных. В момент санкционирования платежа приложение должно проверить наличие у пользователя надлежащих прав, т.е. руководитель ли он.

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

Примерами правил для интерфейса являются следующие:

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

Некоторые сформулированные правила бывают составными, а их составные части относятся к разным группам правил. Например, рассмотрим правило:

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

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

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

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

Остановимся кратко на основных принципах размещения бизнес-логики в модулях приложения базы данных.

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

Александра Каева
Александра Каева
Михаил Забелкин
Михаил Забелкин
Антон Свистельников
Антон Свистельников
Россия, г. Москва