бд полный курс. Информация, данные, информационные системы Информация как социальный ресурс
 Скачать 1.56 Mb.
|
|
Функциональная модель предметной области базы данных Понятие функциональной модели предметной области базы данных Вторым ключевым моментом создания ИС с целью автоматизации информационных процессов организации является анализ функционального взаимодействия объектов автоматизации. Результаты такого анализа многогранны. Аналитики представляют их в виде функциональной модели предметной области базы данных. Функциональная модель предметной области является собирательным понятием. Состав функциональной модели существенно зависит от контекста конкретного ИТ-проекта и может быть представлен посредством довольно широкого спектра документов в виде текстовой и графической информации. К рассмотрению таких документов проектировщик баз данных должен подходить с учетом следующих двух положений: главное назначение ИС является базовым критерием оценки достаточности предоставляемой информации; функциональная модель предназначена для описания процессов обработки данных в рамках выделенной предметной области с различных точек зрения. Описать процессы обработки информации всесторонне с помощью одной описательной модели сложно. В последнее время предпринимаются некоторые успешные попытки разработать унифицированную модель в рамках объектно-ориентированного анализа и проектирования (OOA&D) с помощью UML-конструкций. В настоящих лекциях мы основываемся только на результатах структурного анализа предметной области как наиболее прагматичном подходе для проектирования классических реляционных баз данных. Использование объектно-ориентированного подхода к проектированию баз данных - это предмет отдельного курса лекций. Определим функциональную модель предметной области базы данных как совокупность некоторых моделей, предназначенных для описания процессов обработки информации. Будем называть эти модели конструкциями функциональной модели. Ниже приведен перечень основных конструкций функциональной модели, необходимые для выполнения проектирования реляционных баз данных. Модели процессов: бизнес-модель процессов (иерархия функций системы); модель потока данных. Модели состояний: модель жизненного цикла сущности ; набор спецификаций функций системы (требования); описание функций системы через сущности и атрибуты; бизнес-правила, которые реализуют функции. Внимание! Элементы информационной модели предметной области являются входными данными для задачи создания логической модели данных. Элементы функциональной модели предметной области являются входными данными для задачи проектирования приложений базы данных и, частично, для задачи создания физической модели базы данных. Бизнес-модель процессов (иерархия функций системы) Бизнес-модель процессов предназначена для описания процессов и функций системы в предметной области базы данных. Бизнес-модель чаще всего документируется в соответствии с методологией (нотацией) IDEF0 и представляется в виде совокупности иерархически упорядоченных и взаимосвязанных диаграмм ( IDEF0 -диаграмм). Каждая диаграмма является единицей описания системы и расположена на отдельном листе. IDEF0-диаграммы включают в себя следующие диаграммы: контекстная диаграмма; диаграмма декомпозиции ; диаграмма дерева узлов; диаграмма "только для экспозиции". Контекстная диаграмма является вершиной иерархической структуры диаграмм и представляет самое общее описание системы и ее взаимодействия с внешней средой. Дальнейшее описание системы строится на основе последовательного разбиения функциональности системы на более детальные фрагменты. Диаграммы, которые описывают каждый из функциональных фрагментов системы, называются диаграммами декомпозиции. Диаграмма дерева узлов показывает иерархическую структуру функций, не отображая взаимосвязи между ними. Диаграммы "только для экспозиции" представляют, по сути, копии стандартных диаграмм, но не включаются в анализ синтаксиса модели. Они предназначены для демонстрации иных точек зрения на работы, для отображения деталей, которые не поддерживаются явно синтаксисом модели. Основными элементами IDEF0-диаграмм являются работы, входные и выходные параметры, управление, механизмы и вызов. Работы ( Activity ) обозначают процессы, функции или задачи, которые реализуются в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников и именуются отглагольными существительными. Все диаграммы декомпозиции содержат родственные работы, имеющие общую родительскую работу. Взаимодействие работ между собой и с внешними миром показано стрелками. Стрелки (Arrow) именуются существительными и могут обозначать на диаграмме вход, выход, управление, механизм и вызов. Вход ( Input ) - это материалы или информация, которые используются или преобразуются работой для получения результата (выхода). Стрелка входа рисуется как стрелка, входящая в левую грань работы. Управление ( Control ) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления, которая рисуется как стрелка, входящая в верхнюю грань работы. Управление влияет на работу, но не преобразуется работой. Выход ( Output ) - это материалы или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода, которая рисуется как стрелка, выходящая из правой грани работы. Механизм - это ресурсы, которые выполняют работу (персонал, станки, устройства). Стрелка механизма рисуется как стрелка, входящая в нижнюю грань работы. Механизмы могут не изображаться. Вызов ( Call ) - это специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как стрелка, исходящая из нижней грани работы. Стрелка вызова указывает, что некоторая работа выполняется за пределами моделируемой системы. На рис. 2.9 - 2.11 приведены примеры контекстной диаграммы, диаграммы декомпозиции и диаграммы дерева узлов процесса изготовления изделия.  Рис. 2.9. Контекстная диаграмма процесса изготовления изделия  Рис. 2.10. Диаграмма декомпозиции процесса изготовления изделия  Рис. 2.11. Диаграмма дерева узлов процесса изготовления изделия На диаграмме дерева узлов последний уровень декомпозиции показан в виде списка. Модель потока данных Модель потока данных предназначена для описания процессов перемещения данных в предметной области базы данных. Модель потока данных представляется в виде диаграммы потока данных ( 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 млн записей - цифра, характерная для финансовых подсистем крупного предприятия. И база данных "захлебнулась"! Проектировщики баз данных! Будьте внимательны! Требуйте предоставления полного набора необходимой для принятия проектных решений информации! Контроль качества результатов анализа предметной области Предположим, что проектировщик баз данных получил от аналитиков набор материалов с результатами анализа предметной области базы данных. Задача проектировщика - произвести контроль качества предоставленных результатов анализа в целях обеспечения их полноты и достоверности. Первое, что необходимо сделать, - составить перечень полученных документов и проверить, все ли необходимые документы присутствуют. Проектировщику должны быть представлены: (а) информационная модель предметной области базы данных; (б) совокупность частных моделей, которые относятся к функциональной модели предметной области базы данных; (в) общесистемные требования и решения. В то же время надо помнить, что не все конструкции могут оказаться нужными для решения задач проектирования. Так, например, диаграмма потоков данных непосредственно влияет на принятие решения о числе баз данных, подлежащих реализации в рамках системы. И если уже решено, что база данных будет одна, то принимать во внимание эту диаграмму не нужно. Также часто обходятся без диаграммы жизненных циклов сущностей и диаграммы состояний. Далее проектировщик должен классифицировать представленные модели по типам и для каждой модели проверить выполнение присущих ей правил. Существуют формальные и неформальные процедуры проверки результатов моделирования предметной области. Формальные процедуры основываются на формализации общих знаний о моделях предметной области, в частности на: формальных механизмах, посредством которых представляются данные и процессы системы; формах документирования моделей - диаграммах; методологии графического представления диаграмм (нотациях). В таблице 2.1 приведен перечень моделей, используемых для моделирования данных на различных стадиях жизненного цикла создания ИС, типичные формы документирования моделей - диаграммы - и наиболее популярные методологии (нотации).
| |||||||||||||||||||||||||||||||||||||||||||||||||||||