Набор спецификаций функций системы (требования), описание функций системы через сущности и атрибуты, бизнес-правила

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

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

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

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

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

Общесистемные требования и решения

Общесистемные требования и решения о реализуемости базы данных, как правило, формируются менеджером ИТ-проекта на основе анализа данных предметной области. Среди них наиболее важными для проектировщиков базы данных являются следующие требования и решения.

• Требования по аппаратно-программной платформе:

  • тип компьютеров (Intel, SUN, HP и т.д.);

  • топология сети и протоколы передачи данных (NetBIOS, TCP/IP и т. д.);

  • тип операционной системы (MS Windows, Unix, OpenVMS и т.д.);

  • архитектура базы данных ("клиент-сервер", параллельная архитектура);

  • СУБД, на которой будет реализована база данных (MS SQLServer, Oracle, DB2 и т.д.);

  • язык программирования или средства разработки приложений (C++, Delphi, MS VB и т.д.);

• Требования по обеспечению безопасности и разграничению доступа к базе данных;

• Требования по надежности работы базы данных;

• Требования по активности работы с данными:

  • требования, позволяющие оценить объем базы данных;

  • требования, позволяющие оценить интенсивность потока транзакций в системе;

  • требования, позволяющие оценить пропускную способность сети;

  • требования по максимально возможному числу активных пользователей базы данных;

  • требования по актуализации данных;

  • требования по производительности системы;

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

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

Рассмотрим некоторые примеры возможного неверного принятия решения по выбору СУБД. Предположим, что принято решение о разработке некоторой базы данных на СУБД Oracle. Закуплено и установлено оборудование. Однако информация об объеме базы данных и его потенциальном росте на этапе анализа требований к базе данных отсутствовала. База данных спроектирована и создана, готовится план тестирования приложений базы данных. При составлении плана тестирования базы данных выясняется, что в базе данных будет размещено 1000 записей длиной 100 байт, а рост числа записей базы данных оценивается как 10 записей в год! Базой данных будут пользоваться 4 раза в год для получения 5 видов отчетов. На производство всех отчетов за период требуется один день. Таким образом, цикл простоя системы будет много больше, чем время ее активной работы. В этом случае ответ на вопрос "А зачем выбрана промышленная СУБД Oracle?" имеет вполне экономический смысл.

Имеет место и обратная ситуация. Выбрали СУБД SQLBase. А через два года эксплуатации вышли на объем базы данных в 10 млн записей - цифра, характерная для финансовых подсистем крупного предприятия. И база данных "захлебнулась"!

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