Анализ функциональной модели предметной области базы данных
Чтобы спроектировать модули приложений, необходимо знать, как будет работать информационная система с базой данных. Такую информацию можно получить из функциональной модели предметной области базы данных. Для проектирования модулей приложений проектировщику базы данных нужен набор спецификаций функций, которые задают необходимые требования к обработке бизнес-данных, а также набор зависимостей между различными бизнес-функциями.
Фактически это означает, что входом для решения задачи проектирования модулей приложений базы данных является иерархия функций. На выходе проектировщик должен получить описание (спецификацию) модулей приложений, а в процессе проектирования модулей проектировщик строит отображение бизнес-требований в спецификации модулей.
Алгоритм действий проектировщика базы данных состоит в следующем: сначала проектировщик пытается сформулировать бизнес-требования (функции) в самом общем виде, а затем выполняет декомпозицию каждой такой бизнес-функции до тех пор, пока не будет получена некоторая функция, которую можно считать атомарной функцией. Критерием атомарности функции является получение ответа на вопрос, имеет ли смысл выполнить только часть функции.
Пример. Рассмотрим фрагмент иерархии функций для обработки заявлений о выплате страхового возмещения. На упрощенной схеме рис. 14.1 показана функция "2. Обработать заявление". Выполнение этой функции включает выполнение четырех функций следующего уровня: "2.1. Зарегистрировать заявление", "2.2. Принять решение по заявлению", "2.3. Произвести платеж по заявлению", "2.4. Закрыть заявление".
На рис. 14.1 показана дальнейшая декомпозиция функции "2.2. Принять решение по заявлению". Полученная на этом этапе функция "2.2.5. Разрешить ремонт" является атомарной функцией. Ремонт разрешается либо не разрешается.
Рис. 14.1. Иерархия функции для обработки заявлений о выплате страхового возмещения
При рассмотрении иерархии функций проектировщику базы данных следует обратить внимание на следующие моменты:
в функциональной модели базы данных описываются бизнес-функции, и не все они будут непосредственно поддерживаться приложением базы данных;при рассмотрении иерархий нередко возникает ситуация, когда экземпляры одной и той же функции будут иметь разные номера.Если в первом случае дополнительную информацию о том, какие бизнес-функции будут реализованы в системе, можно получить от руководителя проекта, то во втором случае проектировщик базы данных, вероятнее всего, имеет дело с ошибкой аналитика в определении функции.
Общие принципы разработки спецификаций модулей
После разработки схемы "функции-модули" и схемы "модули-данные" проектировщик приступает к решению довольно трудоемкой задачи - написанию спецификаций модулей. Именно это спецификация позволит программистам и компоновщикам построить реальную систему с использованием базы данных.
При написании спецификаций следует исходить из того, что человек, который будет писать код, умеет это делать. Поэтому из спецификаций нужно по возможности исключить все указания по тому, как нужно, с вашей точки зрения, писать код. Это следует из того практического соображения, что никто не может создать правильный код без его тестирования. Поскольку проектировщик базы данных, как правило, сам не собирается писать код, то ему в спецификации не следует диктовать структуру реального кода.
Алгоритмы, даже очень сложные, следует формулировать в общем виде. Нужно стараться избегать формальных языков описания алгоритмов.
Также не следует вставлять в спецификации модулей команды SQL. В процессе тестирования администратор базы данных может изменить разработанную проектировщиком базы данных физическую модель базы данных, и, следовательно, команды могут измениться.
Следует избегать лишних инструкций в спецификациях. Например, не нужно объяснять программистам, что они должны выйти из цикла при исключительных ситуациях.
Спецификация модуля должна обязательно включать следующее:
Условное название модуля.Функции, выполнение которых обеспечивает данный модуль.Список таблиц и колонок, к которым производится доступ.Для каждой колонки - способ использования колонки, а именно, запрашиваются ли, вставляются, удаляются ли, обновляются ли данные указанных колонок.Список колонок, которые используются в предикатах поиска.Конкретное описание того, что модуль должен делать.
Пример. Приведем типовую спецификацию модуля для предоставления пользователю доступа к приложению базы данных.
Наименование модуля: Страница для входа в приложение (LogIn).
Цель: идентификация пользователя и предоставление доступа к приложению базы данных.
Входные данные
Имя пользователя
Пароль
Таблица базы данных: USERACCOUNT
Колонки:
USERNAME - запрашивается, используется в предикате поиска
USERPASS - запрашивается, используется в предикате поиска
Действия:
Если пользователя с таким именем и паролем нет в базе данных - отказать в доступе и попросить правильно ввести свои данные (на случай ошибки), но не более трех раз.
Если пользователь есть в базе данных - предоставить доступ к модулю "Главная страница", которая в зависимости от полномочий пользователя может иметь различный внешний вид.
Комментарий:
В зависимости от типа модуля (экранная форма, отчет и т.д.), спецификации могут включать дополнительную информацию, такую как требования к расположению кнопок или формат отчета. Для таких модулей спецификацию следует дополнить следующими позициями:
данные о навигации (какой модуль вызывает, и какие модули вызываются;значения входных параметров по умолчанию; список событий, обрабатываемый на экранной форме, и как они обрабатываются; список ошибок и действий, связанных с их обработкой; данные о безопасности; макет экранной формы или шаблон отчета.
Пример. В качестве примера приведем спецификацию экранной формы для работы с базой данных через браузер.
Наименование экранной формы: Web-страница Форма 3: Список исполнителей.
Цель: приписать исполнителей к проекту, определить их занятость и статус.
Входные данные
Номер проекта
Навигация:
Вызывается из модуля "Редактирование Формы 1".
Возвращает управление в модуль "Редактирование Формы 1".
Действия:
Выбрать из списка исполнителяОпределить его статус - основной, неосновной, руководительОпределить занятость исполнителяСохранить запись об исполнителеПерейти на ввод данных о следующемВозвратить на редактирование Формы 1.
Таблицы:
| ENPID | Внутренний номер служащего | INSERT |
| PROJID | Внутренний номер проекта | INSERT |
| TN | табельный номер (из представления) | |
| NM | ФИО | INSERT |
| PS | Должность | |
| GR | Разряд | |
| DR | Ученая степень | |
| ZV | Ученое знание | |
| JOB | Занятость в проекте в мес. | INSERT |
| EMPSTATUS | Статус исполнителя | INSERT |
| ENPID | Внутренний номер служащего | |
| TN | табельный номер (из представления) | |
| NM | ФИО | Предикат поиска |
| PS | Должность | |
| GR | Разряд | |
| DR | Ученая степень | |
| ZV | ученое звание |
Входные данные
Имя пользователя
Пароль
Таблица базы данных: USERACCOUNT
Колонки:
USERNAME - запрашивается, используется в предикате поиска
USERPASS - запрашивается, используется в предикате поиска
Действия:
Если пользователя с таким именем и паролем нет в базе данных - отказать в доступе и попросить правильно ввести свои данные (на случай ошибки), но не более трех раз.
Если пользователь есть в базе данных - предоставить доступ к модулю "Главная страница", которая в зависимости от полномочий пользователя может иметь различный внешний вид.
Комментарий:
В зависимости от типа модуля (экранная форма, отчет и т.д.), спецификации могут включать дополнительную информацию, такую как требования к расположению кнопок или формат отчета. Для таких модулей спецификацию следует дополнить следующими позициями:
данные о навигации (какой модуль вызывает, и какие модули вызываются;значения входных параметров по умолчанию; список событий, обрабатываемый на экранной форме, и как они обрабатываются; список ошибок и действий, связанных с их обработкой; данные о безопасности; макет экранной формы или шаблон отчета.
Пример. В качестве примера приведем спецификацию экранной формы для работы с базой данных через браузер.
Наименование экранной формы: Web-страница Форма 3: Список исполнителей.
Цель: приписать исполнителей к проекту, определить их занятость и статус.
Входные данные
Номер проекта
Навигация:
Вызывается из модуля "Редактирование Формы 1".
Возвращает управление в модуль "Редактирование Формы 1".
Действия:
Выбрать из списка исполнителяОпределить его статус - основной, неосновной, руководительОпределить занятость исполнителяСохранить запись об исполнителеПерейти на ввод данных о следующемВозвратить на редактирование Формы 1.
Таблицы:
| ENPID | Внутренний номер служащего | INSERT |
| PROJID | Внутренний номер проекта | INSERT |
| TN | табельный номер (из представления) | |
| NM | ФИО | INSERT |
| PS | Должность | |
| GR | Разряд | |
| DR | Ученая степень | |
| ZV | Ученое знание | |
| JOB | Занятость в проекте в мес. | INSERT |
| EMPSTATUS | Статус исполнителя | INSERT |
| ENPID | Внутренний номер служащего | |
| TN | табельный номер (из представления) | |
| NM | ФИО | Предикат поиска |
| PS | Должность | |
| GR | Разряд | |
| DR | Ученая степень | |
| ZV | ученое звание |
Определение функций
При разработке иерархии функций аналитик должен предоставить текстовое описание к каждой функции, по крайней мере для верхнего и самого нижнего уровней иерархии. Желательно, чтобы в этом описании аналитики выделяли сущности предметной области. Это важно для того, чтобы знать с какими сущностями предметной области работает функция, т.е. какие потенциальные объекты реляционной базы данных будут использоваться в каждой функции. Если это не сделано, то проектировщику базы данных придется делать это самостоятельно.
Пример. Определения функции "2.2.2. Проверить обеспечено ли заявление".
"Получить и зарегистрировать все требуемые страховой компанией сведения о заявлении (СВЕДЕНИЯ О ЗАЯВЛЕНИИ), включая все подробные сведения о третьих сторонах (СТОРОННИЕ ЮРИДИЧЕСКИЕ ЛИЦА) и свидетелях (ФИЗИЧЕСКИЕ ЛИЦА).
Изучить страховой полис (ПОЛИС) на предмет наличия исключительных ситуаций (ИСКЛЮЧЕНИЯ) и определить, действуют ли эти ситуации в случае данного заявления (ЗАЯВЛЕНИЕ).
Если имеется исключение, то закрыть заявление и составить стандартное письмо заявителю об отказе в выплате (ПИСЬМО) заявителю (ЗАЯВИТЕЛЬ).
Если никаких исключений нет, то изменить статус заявления на ожидание оценки, назначить и уведомить оценщика (ОЦЕНЩИК)."
Из примера видно, какие сущности предметной области участвуют в выполнении функции (выделены в скобках), как меняется состояние сущности (выделено курсивом) и каков алгоритм работы этой функции.
Из примера ясно, что на этом этапе проектировщик базы данных в качестве входных данных использует также информационную модель предметной области базы данных (описание сущностей).
При выполнении анализа функций полезно иметь некоторую таблицу (матрицу) "Функция-Сущность". Эта матрица должна дать ответ на следующие вопросы:
имеет ли каждая сущность конструктор (функцию, которая создает все экземпляры сущности);имеет ли она деструктор (функцию, которая удаляет экземпляры сущности);есть ли ссылка на эту сущность (функции, которые используют эту сущность и каким образом).
Процесс анализа взаимодействия функции и сущности принято обозначать аббревиатурой CRUD (Create, Reference, Update, Delete - создание, ссылка, модификация, удаление).
Полезными для понимания проектировщиком базы данных назначения функций и того, как данные функции участвуют в процессе обработки данных в системе, могут быть диаграммы потока данных и диаграммы жизненных циклов сущностей, которые были рассмотрены нами во второй лекции. Последние, в частности, дают ясную картину изменения состояния сущности, что важно в определении атрибутов статуса сущности.
Отображение функций в модули
Одной из основных задач проектирования модулей приложений является построение отображения функций в модули. При решении этой задачи проектировщик базы данных должен акцентировать внимание на структуре базы данных, которая составляет основу приложения.
Как правило, решение задачи отображения функций в модули решается в четыре этапа:
Анализ работы функции.Построение модели сущностей, поддерживающей эти функции.Начать проектирование физической структуры с создания схемы, поддерживающей разработанную модель сущностей.Завершить проектирование разработкой спецификаций модулей, которые реализуют функции на предложенной схеме базы данных.
Из предложенного выше подхода видно, как тесно переплетаются в процессе проектирования процессы разработки физической модели базы данных и спецификаций модулей приложений. Таким образом, если проектировщиком был разработан черновой вариант физической модели базы данных по алгоритмам, рассмотренным нами в предыдущих лекциях, то на этом этапе он должен быть адаптирован к реализации функций и, возможно, значительно переработан.
К сожалению, никаких унифицированных и простых способов отображения функций в модули приложений не существует. Это обусловлено двумя обстоятельствами: комбинаторной сложностью построения отображений множеств (теоретически доказано, что для такого класса комбинаторных задач не существует в общем случае алгоритмов с линейной сходимостью) и сложностью выработки критерия того, что полученное отображение оптимально (т.е. довольно широкий семантический произвол в обосновании вариантов того или иного отображения). Как показывает опыт проектирования, мнение относительно состава и количества модулей приложений в процессе проектирования меняется неоднократно.
В последнее время хорошие результаты в разработке и проектировании систем и, в частности, модулей приложений получены с применением объектно-ориентированного подхода на основе унифицированного языка моделирования UML и CASE-инструментария, который этот язык поддерживает. Однако рассмотрение этой методики разработки систем представляет собой предмет отдельного курса, и здесь излагаться не будет. В списке литературы к лекции указаны монографии и учебники по этой популярной методике.
Однако рассмотрение этой методики разработки систем представляет собой предмет отдельного курса, и здесь излагаться не будет. В списке литературы к лекции указаны монографии и учебники по этой популярной методике.
При отображении функций в модули необходимо получить схему, которая ставит в соответствие каждой функции определенный модуль.
Пример. Рассмотрим нашу учебную базу данных, содержащую информацию о сотрудниках, отделах и проектах организации. Допустим, она будет поддерживать бизнес-функцию "Управление проектами в организации". Функциональная модель предметной области базы данных в терминах иерархии функций приведена на рис. 14.2, а на рис. 14.3 приведен перечень функций управления проектами в организации.
Рис. 14.2. Иерархия бизнес-функции "Управление проектами в организации"
Рис. 14.3. Перечень функции управления проектами в организации
Задача состоит в отображении функций из перечня на рис. 14.3 в список модулей.
Сначала из перечня функций должны быть удалены те функции, которые не будут поддерживаться приложением базы данных. Проектировщик узнает у руководителя проекта, что в приложении базы данных не будут поддерживаться следующие функции:
назначить куратора проекта;известить руководителей подразделений; известить сотрудников; собрать совещание; приступить к выполнению; составить список работ; определить объем работ; определить стоимость работ; определить время работ; определить производственные мощности; распределить производственные мощности; распределить работы по сотрудникам; контролировать ход выполнения проекта.
Таким образом, будет получен список функций, который показан в левой колонке таблицы 14.1. Этому списку функций должен быть поставлен в соответствие список модулей приложения базы данных.
| Назначить руководителяя проекта | Ввод информации о проекте | |
| Определить бюджет проекта | Ввод информации о сотрудниках | |
| Определить список подразделений | Поиск информации о сотрудниках | |
| Определить список сотрудников | Поиск информации о проектах | |
| Выполнять проект | Генерация отчета о выполненных проектах | |
| Сдать проект | Генерация отчета о выполняемых проектах |
Руководитель проекта передал проектировщику базы данных характеристику приложения базы данных по управлению выполнением проектов в организации. Это приложение будет заниматься учетом выполняемых и выполненных проектов в организации. Главными вопросами, на которые должно отвечать приложение, являются:
Какие проекты выполняются в организации? Какие сотрудники в каком проекте участвуют? Какими проектами кто руководит? Какие проекты выполнялись в организации? Какие сотрудники в каком проекте участвовали? Какими проектами кто руководил?
Проектировщик базы данных составил список модулей приложения базы данных (правая колонка таблицы 14.1) и установил отображение функций в модули, как показано на рис. 14.4.
Рис. 14.4. Отображение функции в модули
Приведенный пример показывает общий принцип построения отображения бизнес-функций в модули.
В дополнение будет весьма полезным к разработанной схеме "функции-модули" составить схему "модули-данные", опираясь на изучение определения функций.
При составлении схемы "модули-данные" используется описание функций, логическая модель данных или итерация физической модели данных.
Пример. Рассмотрим модуль "Ввод информации о сотрудниках" из предыдущего примера и составим для него схему "модули-данные". При этом мы используем схему базы данных, приведенную на рис. 14.5.
Рис. 14.5. Физическая модель базы данных
Один из возможных результатов, который может быть получен проектировщиком базы данных, приведен в таблице 14.2.
| Ввод информации о сотрудниках | Employee | Empno | Чтение |
| Ename | Чтение, Поиск | ||
| Lname | Чтение, Поиск | ||
| Job | Чтение | ||
| Sal | Чтение | ||
| Depno | Чтение, Поиск | ||
| Department | Depno | Чтение, Поиск | |
| Manager | Чтение | ||
Проектирование процесса тестирования модулей приложений
Тестирование приложения базы данных есть один из основных элементов подготовки и проведения приемо-сдаточных испытаний. Как показывает практика, планирование тестирования приложений базы данных должно начинаться еще на стадии анализа. Имеется вероятность того, что заказчик может отказаться от ранее принятых критериев испытаний в процессе выполнения проекта. Однако чаще всего планирование тестирования откладывают до этапа проектирования, и, таким образом, составление плана тестирования становится задачей проектировщика базы данных или администратора баз данных.
процессе тестирования должно быть выяснено, что приложение базы данных делает то, что от него требуется, т.е. отвечает сформулированным требованиям приемо-сдаточных испытаний.
Как правило, в процессе проектирования проектировщик базы данных предлагает стратегию (или план) комплексного и системного тестирования. При разработке стратегии тестирования следует помнить о том, что должны использоваться тесты следующих категорий:
Автономные тесты (тесты модулей).Тесты связей модулей.Системный тест для приложения базы данных в целом.Приемо-сдаточные испытания (которые может проводить заказчик).Тесты производительности.
Обычно после проведения приемо-сдаточных испытаний подписывается Акт приемки-сдачи. Считается, что система переходит в состояние опытной эксплуатации, на которой выявляются и исправляются ошибки. После окончания стадии опытной эксплуатации система переходит в состояние промышленной эксплуатации, т.е. становится производственным ресурсом компании.
Как правило, тесты и их проведение планируются для удовлетворения требований приемо-сдаточных испытаний. Поэтому разработку стратегии тестирования следует начинать с детального изучения этих требований.
Планирование тестирования приложений базы данных зависит от используемых внутри организации стандартов и методик разработки информационных систем с базами данных. Такие методики различаются как по своему подходу к разработке систем, так и по составу производимой проектной документации.
Так, например, методики разработки, предлагаемые компаниями Microsoft и IBM, отличаются по составу проектной документации, хотя во многом схожи по методологической основе (объектно-ориентированному подходу).
Рассмотрим подход, который основан на модели проектной группы Модель MSF версии 3.1, предлагаемой компанией Microsoft. В этой методике предусмотрен так называемый ролевой кластер "Тестирование".
Задача ролевого кластера "Тестирование" (test) - одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены. Любое программное обеспечение содержит дефекты. Обнаружение и устранение дефектов может подразумевать различные решения, начиная от устранения и заканчивая документированием способов обхода дефекта. Поставка продукта с известным дефектом, но с описанием способов его обхода является более предпочтительной, чем поставка продукта с невыявленным дефектом, который в дальнейшем станет сюрпризом - как для проектной команды, так и для заказчика.
Чтобы достичь успеха, команда тестировщиков должна фокусироваться на определенных ключевых задачах. Они структурируются в виде трех областей компетенции.
Планирование тестов: разработка методологии и плана тестирования;участие в установлении стандарта качества (quality bar);разработка спецификаций тестов.Разработка тестов: разработка и поддержка автоматизированных тестов (automated test cases), инструментов и скриптов;проведение тестов с целью определения состояния проекта;управление билдами (manage the build process).Отчетность о тестах: доведение до сведения проектной группы информации о качестве продукта;мониторинг найденных ошибок с целью обеспечения их улаживания до выпуска продукта.
Планирование тестов. Данная область компетенции (планирование тестов - test planning) ролевого кластера "Тестирование" формулирует методологию нахождения и урегулирования проблем качества продукта.
Команда тестировщиков разрабатывает планы и методики тестирования и таким образом формирует стратегию, используемую в проекте для тестирования решения.
В заключение раздела рассмотрим некоторые практические рекомендации проектировщикам базы данных при разработки стратегии тестирования.
Стратегия тестирования - это план проведения работ по тестированию системы или ее модуля, учитывающий специфику функциональности и взаимозависимости с другими компонентами системы и платформы. Стратегия определяет типы тестов, которые нужно выполнять для данного функционала системы, включает описание необходимых подходов с точки зрения целей тестирования и может задавать описания или требования к необходимым для проведения тестирования инструментам и инфраструктуре.
Стратегия тестирования должна отвечать на следующие вопросы:
Как, каким образом тестирование даст ответ, что данный функционал работает?Что нужно сделать и чем пользоваться из инструментальных средств, для достижения целей тестирования?Когда определенный функционал будет тестироваться и, соответственно, когда ожидать получения результатов?
В качестве дополнительной задачи, которая решается в процессе понимания стратегии тестирования, можно рассматривать задачу минимизации затрат на тестирование.
Из стратегии тестирования органично выписывается план тестирования. Шаблоны планов тестирования, предлагаемые различными методологиями, зачастую прямо включают одним из разделов описание стратегии тестирования или же включают описание стратегии в пункты плана, отвечающие за тестирование конкретных частей функционала. К примеру, шаблон методологии Rational Unified Process определяет стратегию тестирования как самый большой раздел плана тестирования.
Заказчик зачастую хочет контролировать процесс тестирования и видеть понимание задачи тестирования исполнителями по проекту. Для него стратегия тестирования - это менее детальный документ-видение того, как будет тестироваться система в процессе разработки.
При разработке стратегии тестирования для распределенной системы с базой данных проектировщику базы данных нужно выделить основные области, которые могут тестироваться отдельно друг от друга.
Объединим в рамках рассматриваемого примера тестирование функциональности сервера приложений и базы данных. Пусть сервер приложения реализует 20 команд по обработке данных и пользовательских сессий (без учета работы с системными пулами соединений, функций сжатия передаваемого по сети трафика и т.п.). Сервер баз данных реализует 10 системных операций по архивации данных, построению статистики использования отчетов и еще несколько подобных операций. Общий смысл заключается в том, что мы имеем конечный набор тестируемых операций, и так как конфигурации определены заранее, можем говорить о конечном наборе тестов, которые необходимо выполнить, чтобы проверить работоспособность серверного функционала системы. Итог - 30 тестов на серверной стороне. Заметим, что в данном примере мы не затрагиваем нагрузочную составляющую тестирования: речь идет только о функциональном тестировании.
При разработке стратегии тестирования проектировщик базы данных должен учитывать, что, планируя тестирование, он не начинает разбираться с системой, а занимается непосредственно планированием, выделением ресурсов и сроков на конкретные задачи.
Тестирование информационных систем является бурно развивающейся прикладной наукой. Практика показывает целесообразность применения CASE-средств для организации и проведения тестирования. В списке литературы к лекции указаны источники, которые следует использовать для углубленного изучения разработки планов тестирования приложений базы данных.
В этой лекции мы закончили обсуждение основных задач проектировщика базы данных, которые он должен выполнить обязательно (построение логической, физической модели данных, подготовка скрипта для создания базы данных и документирование модели), и в решении которых его участие очень желательно (планирование модулей приложений, планирование тестирования).
В двух последних лекциях мы рассмотрим задачи управления изменениями в структуре базы данных (или задачи обратного влияния), которые могут потребовать непосредственного участия проектировщика базы данных.
Литература: [9], [17], [18], [19], [22], [30], [33], [45].
Размещение логики обработки
Сложность решения задачи проектирования модулей обусловлена еще и тем, что проектировщик баз данных должен выделить из всего планируемого кода серверный код, создание которого обсуждалось в одной из предыдущих лекций. При этом следует придерживаться следующих простых правил:
Задействовать как можно больше ограничений на колонки реляционных таблиц для реализации правил обработки данных без процедурного кода.Задействовать триггеры базы данных для процедурного ввода правил обработки данных, в частности, для поддержки ссылочной целостности данных.Задействовать хранимые процедуры для инкапсуляции общих бизнес-функций. Использовать требования производительности при принятии окончательного выбора о разделении кода.
В настоящем разделе мы рассмотрим некоторые факторы, которые должны учитывать проектировщики баз данных при разграничении управления пользовательским интерфейсом приложений и выполнением операций обработки данных в модулях.
Как отмечают специалисты в области разработки и проектирования информационных систем, многие недостатки в прикладных системах вызваны тем, что в них не определены различия между правилами для данных, правилами для процессов и правилами для интерфейса. Рассмотрим основные.
Правила для данных. В правилах для данных формулируются условия, которым должны удовлетворять данные. Эти правила действуют для каждого экземпляра данных и выводятся из модели данных.
Примерами правил для данных являются следующие:
Пол человека должен быть либо мужской, либо женский. Это правило может быть введено с помощью ограничения CHECK в определении колонки таблицы базы данных.Каждый заказ должен быть предназначен для одного и только одного покупателя. Это правило для данных можно ввести с помощью ограничений PRIMERY KEY или NOT NULL.
Правила для процессов. В правилах для процессов определяется, что может (и что не может) делать приложение. Эти правила обычно выводятся из модели функций.
Примерами правил для процессов являются следующие:
Размер зарплаты не должен превышать 160000 рублей.
Это правило следует реализовать в приложении, в нем ничего не говорится о содержимом и определении базы данных. Оно выражает утверждение о том, что может быть, а чего не может быть.Только руководитель может санкционировать выплату премиальных. В момент санкционирования платежа приложение должно проверить наличие у пользователя надлежащих прав, т.е. руководитель ли он.
Правила для интерфейса. В правилах для интерфейса устанавливается, каким должен видеть пользователь приложение. Эти правила не касаются обработки, а только влияют на представление пользователя о приложении базы данных. Эти правила выводятся из спецификации пользовательского интерфейса.
Примерами правил для интерфейса являются следующие:
Все коды валют должны разъясняться. Это спецификация требований заказчика к визуализации кодов валют. Номера отделов и подразделений не должны показываться. Это также является требованием заказчика системы относительно визуализации данных в приложении.
Некоторые сформулированные правила бывают составными, а их составные части относятся к разным группам правил. Например, рассмотрим правило:
Все торговые операции, производимые в воскресенье, учитываются в бухгалтерских книгах за следующий понедельник.
Это два правила. Первое утверждает, что проводки по торговым операциям в бухгалтерских книгах нельзя делать за воскресенье. Это правило для данных. Второе разъясняет приложению, как откорректировать дату проводки, чтобы она стала приемлемой. К дате проводки, выпадающей на понедельник, нужно добавить единицу. Это правило для процессов.
Выделение и анализ этих трех групп правил приводит к формированию трех наборов документов: описание структуры интерфейса, структура процессов, которая определяет, как должен быть реализован интерфейс, и структура данных, задающая основные объекты базы данных, с которыми работают процессы.
Эти документы играют важную роль как в определении и логике, и ее размещении в приложении, так и в составлении спецификации модулей приложений базы данных.
Остановимся кратко на основных принципах размещения бизнес-логики в модулях приложения базы данных.
Правила для интерфейса реализуются во внешней (клиентской) части системы, независимо от того, какие языки программирования или генераторы отчетов используются. Правила для процессов реализуются в виде процедур, вызываемых из клиентской части системы. Они могут представлять серверный код, либо быть реализованы в виде модулей или библиотек на сервере приложений. Правила для данных реализуются самой базой данных в виде ограничений или триггеров.
Системные модули
Как указывалось выше, целью проектирования модулей является реализация функциональных возможностей, которые удовлетворяют бизнес-требованиям, выявленным в функциональной модели предметной области базы данных. Однако при этом необходимо рассмотреть достаточное число процессов, которые не вытекают непосредственно из сформулированных бизнес-функций. Например, возможность выдачи результатов работы модуля в файл или на принтер.
Набор модулей приложений базы данных, который непосредственно не следует из бизнес-функций, но необходим для обеспечения работы системы, называется системным.
К таким модулям можно отнести процедуры резервного копирования и автоматического восстановления, модули, предоставляющие пользователям возможность менять свой пароль, модули печати, модули навигации по приложениям базы данных и т.д.
Проектировщик базы данных самостоятельно разрабатывает спецификации таких модулей.
