Предметная область базы данных и ее модели

Модель потока данных

Модель потока данных предназначена для описания процессов перемещения данных в предметной области базы данных. Модель потока данных представляется в виде диаграммы потока данных ( Data Flow Diagram ). Основными элементами диаграммы являются:

• источники данных (Data Source);
• процессы обработки данных (Data Process) ;
• хранилища данных (Data store) ;
• потоки данных (Data Flow).

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

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

Рис. 2.12. Простая диаграмма потока данных для обработки заказа

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

Диаграмма потока данных позволяет:

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

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

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

Модель жизненного цикла сущности

Модель жизненного цикла (ЖЦ) сущности предназначена для описания изменения состояний сущности и переходов между ними.

Модель ЖЦ сущности представляется в виде диаграммы ЖЦ сущности ( Entity Lifecycle Diagram ), на которой изображаются пути перехода сущности из некоторого начального состояния в конечное состояние и события, инициирующие изменения состояния сущности. Модель ЖЦ сущности может быть также представлена в виде текстового описания.

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

На рис. 2.13 приведен пример диаграммы жизненного цикла сущности Чек.

Рис. 2.13. Диаграмма жизненного цикла Чек

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

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

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

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

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

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

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

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

• Требования по аппаратно-программной платформе:
  • тип компьютеров (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 млн записей - цифра, характерная для финансовых подсистем крупного предприятия. И база данных "захлебнулась"!

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