Бизнес-модель процессов (иерархия функций системы)
Бизнес-модель процессов предназначена для описания процессов и функций системы в предметной области базы данных. Бизнес-модель чаще всего документируется в соответствии с методологией (нотацией) IDEF0 и представляется в виде совокупности иерархически упорядоченных и взаимосвязанных диаграмм (IDEF0-диаграмм). Каждая диаграмма является единицей описания системы и расположена на отдельном листе. IDEF0-диаграммы включают в себя следующие диаграммы:
контекстная диаграмма;диаграмма декомпозиции;диаграмма дерева узлов;диаграмма "только для экспозиции".
Контекстная диаграмма является вершиной иерархической структуры диаграмм и представляет самое общее описание системы и ее взаимодействия с внешней средой.
Дальнейшее описание системы строится на основе последовательного разбиения функциональности системы на более детальные фрагменты. Диаграммы, которые описывают каждый из функциональных фрагментов системы, называются диаграммами декомпозиции.
Диаграмма дерева узлов показывает иерархическую структуру функций, не отображая взаимосвязи между ними.
Диаграммы "только для экспозиции" представляют, по сути, копии стандартных диаграмм, но не включаются в анализ синтаксиса модели. Они предназначены для демонстрации иных точек зрения на работы, для отображения деталей, которые не поддерживаются явно синтаксисом модели.
Основными элементами IDEF0-диаграмм являются работы, входные и выходные параметры, управление, механизмы и вызов.
Работы (Activity) обозначают процессы, функции или задачи, которые реализуются в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников и именуются отглагольными существительными. Все диаграммы декомпозиции содержат родственные работы, имеющие общую родительскую работу.
Взаимодействие работ между собой и с внешними миром показано стрелками. Стрелки (Arrow) именуются существительными и могут обозначать на диаграмме вход, выход, управление, механизм и вызов.
Вход (Input) - это материалы или информация, которые используются или преобразуются работой для получения результата (выхода).
Стрелка входа рисуется как стрелка, входящая в левую грань работы.
Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления, которая рисуется как стрелка, входящая в верхнюю грань работы. Управление влияет на работу, но не преобразуется работой.
Выход (Output) - это материалы или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода, которая рисуется как стрелка, выходящая из правой грани работы.
Механизм - это ресурсы, которые выполняют работу (персонал, станки, устройства). Стрелка механизма рисуется как стрелка, входящая в нижнюю грань работы. Механизмы могут не изображаться.
Вызов (Call) - это специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как стрелка, исходящая из нижней грани работы. Стрелка вызова указывает, что некоторая работа выполняется за пределами моделируемой системы.
На рис. 2.9 - 2.11 приведены примеры контекстной диаграммы, диаграммы декомпозиции и диаграммы дерева узлов процесса изготовления изделия.
Рис. 2.9. Контекстная диаграмма процесса изготовления изделия
Рис. 2.10. Диаграмма декомпозиции процесса изготовления изделия
Рис. 2.11. Диаграмма дерева узлов процесса изготовления изделия
На диаграмме дерева узлов последний уровень декомпозиции показан в виде списка.
Стрелка входа рисуется как стрелка, входящая в левую грань работы.
Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления, которая рисуется как стрелка, входящая в верхнюю грань работы. Управление влияет на работу, но не преобразуется работой.
Выход (Output) - это материалы или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода, которая рисуется как стрелка, выходящая из правой грани работы.
Механизм - это ресурсы, которые выполняют работу (персонал, станки, устройства). Стрелка механизма рисуется как стрелка, входящая в нижнюю грань работы. Механизмы могут не изображаться.
Вызов (Call) - это специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как стрелка, исходящая из нижней грани работы. Стрелка вызова указывает, что некоторая работа выполняется за пределами моделируемой системы.
На рис. 2.9 - 2.11 приведены примеры контекстной диаграммы, диаграммы декомпозиции и диаграммы дерева узлов процесса изготовления изделия.
Рис. 2.9. Контекстная диаграмма процесса изготовления изделия
Рис. 2.10. Диаграмма декомпозиции процесса изготовления изделия
Рис. 2.11. Диаграмма дерева узлов процесса изготовления изделия
На диаграмме дерева узлов последний уровень декомпозиции показан в виде списка.
Диаграммы "сущность-связь"
Типичной формой документирования информационной модели предметной области являются диаграммы "сущность-связь" (ER-диаграммы). ER-диаграмма позволяет графически представить все элементы информационной модели согласно простым, интуитивно понятным, но строго определенным правилам - нотациям. Далее мы будем пользоваться условными обозначениями, принятыми в методологии информационного проектирования.
Построение ER-диаграмм, как правило, ведется с использованием CASE-средств. Выбор CASE-средств и способы работы с ними в настоящем курсе не обсуждаются.
Документирование доменов
Домены назначаются аналитиками и фиксируются в специальном документе - словаре данных (Data Dictionary). На стадиях разработки логической и физической моделей реляционной базы данных домены уточняются в сущностях на ER-диаграмме.
Проектировщик базы данных должен тщательным образом изучить домены каждого атрибута с точки зрения их реализуемости в СУБД, с участием аналитиков внести в них изменения, если условие реализуемости не выполняется. При этом проектировщик руководствуется следующим:
для реализации реляционной базы данных требуется использовать реляционную СУБД, например Oracle;в большинстве реляционных СУБД в качестве языка манипулирования и описания данных используется диалект SQL, поддерживающий определенные стандарты, например ANSI SQL-92.Пример. Изначально домен атрибута Photo (Фотография) сущности Person (Персона) был определен как Image (Рисунок). Проектировщик базы данных должен изменить значение домена на LONG RAW (СУБД Oracle) или BLOB (двоичный большой объект) (SQL-92).
Рис. 2.5. Визуализация определения доменов атрибутов на ER-диаграмме при создании физической модели реляционной базы данных
Документирование отношений (связей)
Отношение (связь) сущностей на ER-диаграмме изображается линией, соединяющей эти сущности.
Степень связи изображается с помощью символа "птичья лапка"1, указывающего на то, что в связи участвует много (N) экземпляров сущности, и одинарной горизонтальной чертой, указывающей на то, что в связи участвует один экземпляр сущности.
Необязательный класс принадлежности сущности к связи изображается с помощью кружочка на линии отношения рядом с сущностью, обязательный класс принадлежности - с помощью вертикальной черты на линии отношения рядом с сущностью.
Отношение читается вдоль линии либо слева направо, либо справа налево. На рис. 2.6 представлено следующее отношение: каждая специальность по образованию должна быть зарегистрирована за определенным физическим лицом (персоной), физическое лицо может иметь одну или более специальностей по образованию.
Рис. 2.6. Представление отношения между двумя сущностями на ER-диаграмме
Как правило, отношения на ER-диаграммах именуются с обеих сторон.
Рис. 2.7. Связанные сущности с названием сторон
Документирование супертипов и подтипов
Супертипы и подтипы, так же как и сущности, обозначаются на ER-диаграмме с помощью прямоугольников. Отношения между ними изображаются с помощью "вилки", имеющей в точке ветвления полукруг.
Рис. 2.8. Изображение супертипа Person с двумя подтипами Head и Employee
Супертип Person (Персона) содержит общие для своих подтипов Head (Руководитель) и Employee (Служащий) атрибуты. Подтипы содержат только атрибуты, характерные для выделенных категорий. Предложенная конструкция реализует отношение подчиненности в иерархии организации согласно ее штатному расписанию.
Изучив и проверив качество информационной модели данных предметной области, представленной в виде набора ER-диаграмм, проектировщик базы данных может приступать к созданию логической модели базы данных.
Документирование сущностей и атрибутов
Сущность на ER-диаграмме представляется прямоугольником с именем в верхней части. Будем использовать английские слова для именования элементов модели.
Рис. 2.3. Представление сущности Person (персонал) на ER-диаграмме
Рис. 2.4. Представление сущности Person с атрибутами и уникальным идентификатором сущности
В прямоугольнике перечисляются атрибуты сущности, при этом атрибуты, составляющие уникальный идентификатор сущности, подчеркиваются.
Информационная модель предметной области базы данных
Одним из ключевых моментов создания ИС с целью автоматизации информационных процессов организации является всестороннее изучение объектов автоматизации, их свойств, взаимоотношений между этими объектами и представление полученной информации в виде информационной модели данных.
Информационная модель данных предназначена для представления семантики предметной области в терминах субъективных средств описания - сущностей, атрибутов, идентификаторов сущностей, супертипов, подтипов и т.д.
Информационная модель предметной области базы данных содержит следующие основные конструкции:
диаграммы "сущность-связь" (Entity - Relationship Diagrams);определения сущностей;уникальные идентификаторы сущностей;определения атрибутов сущностей;отношения между сущностями;супертипы и подтипы.Внимание! Элементы информационной модели данных предметной области являются входными данными для решения задачи проектирования базы данных - создания логической модели данных.
Контроль качества результатов анализа предметной области
Предположим, что проектировщик баз данных получил от аналитиков набор материалов с результатами анализа предметной области базы данных. Задача проектировщика - произвести контроль качества предоставленных результатов анализа в целях обеспечения их полноты и достоверности.
Первое, что необходимо сделать, - составить перечень полученных документов и проверить, все ли необходимые документы присутствуют. Проектировщику должны быть представлены: (а) информационная модель предметной области базы данных; (б) совокупность частных моделей, которые относятся к функциональной модели предметной области базы данных; (в) общесистемные требования и решения. В то же время надо помнить, что не все конструкции могут оказаться нужными для решения задач проектирования. Так, например, диаграмма потоков данных непосредственно влияет на принятие решения о числе баз данных, подлежащих реализации в рамках системы. И если уже решено, что база данных будет одна, то принимать во внимание эту диаграмму не нужно. Также часто обходятся без диаграммы жизненных циклов сущностей и диаграммы состояний.
Далее проектировщик должен классифицировать представленные модели по типам и для каждой модели проверить выполнение присущих ей правил.
Существуют формальные и неформальные процедуры проверки результатов моделирования предметной области.
Формальные процедуры основываются на формализации общих знаний о моделях предметной области, в частности на: формальных механизмах, посредством которых представляются данные и процессы системы; формах документирования моделей - диаграммах; методологии графического представления диаграмм (нотациях). В таблице 2.1 приведен перечень моделей, используемых для моделирования данных на различных стадиях жизненного цикла создания ИС, типичные формы документирования моделей - диаграммы - и наиболее популярные методологии (нотации).
| Информационная модель предметной области | |||
| Анализ предметной области | Модели данных | Диаграммы "сущность-связь" (ERD) | CHEF, Martin, Bachman, IDEFXIX, Shlaer & Mellor, Merise, IEM |
| Диаграммы модели данных (DMD) | Martin, Bachman | ||
| Диаграммы структур данных (DSD) | Jackson | ||
| Диаграммы логических структур данных (LDS) | SSADM | ||
| Диаграммы UML | OOA&D | ||
| Функциональные модели предметной области | |||
| Модели процессов | Диаграммы модели бизнес-процессов (контекстная диаграмма, диаграмма декомпозиции, диаграмма дерева узлов | IDEF0, IDEF3 | |
| Диаграммы потоков данных | Yuordan/DeMarco, Gane & Sarson, SSADM | ||
| Графы преобразований | Ward & Mellor, Gane & Sarson, Hatley | ||
| Диаграммы UML | OOA&D | ||
| Модели состояний | Диаграммы состояний (STD) | Ward & Mellor, Hatley | |
| Диаграммы жизненного цикла (ELH) | SSADM | ||
| Диаграммы UML | OOA&D | ||
| Проектирование | Модели процессов проектирования | Структурные схемы (STC) | Youtdan/Constantine Page-Jones |
| Диаграммы UML | OOA&D | ||
| Реализация | Диаграммы UML | OOA&D | |
Как видно из таблицы, не существует единой модели, в рамках которой можно представить весь жизненный цикл системы. Так, стадия анализа предметной области системы представляется с помощью трех типов моделей:
модели данных, которые описывают внутренние, логические взаимоотношения между данными в системе;модели процессов, которые описывают процессы обработки или преобразования данных в системе;модели состояний, которые описывают поведение или отклики системы на события.
Несмотря на то, что каждая из диаграмм может быть представлена с помощью широкого спектра нотаций, все они в рамках определенной диаграммы имеют общие основные черты. Ниже приведены правила, которыми должен руководствоваться проектировщик в ходе формальной проверки правильности представленных моделей.
На диаграммах "сущность-связь" должны быть представлены сущности, связи, степени связи, классы принадлежности сущности, неопределенные связи, супертипы/подтипы сущности. При этом каждая сущность и отношение должны быть поименованы и занесены в словарь данных; каждая сущность может появиться на диаграмме только один раз; каждая сущность должна вступать в отношение (отсутствие "висящих" сущностей), и каждое отношение должно иметь сущности (отсутствие "висящих" отношений). Поэтому проектировщик базы данных должен проконтролировать, чтобы связь между сущностями осуществлялась через точно указанные атрибуты, которые, вероятнее всего, будут определять уникальный ключ связи.
Проектировщик базы данных должен проконтролировать, чтобы в информационной модели предметной области для каждого атрибута сущностей был определен домен. Следует понимать, что определение домена, даваемое аналитиками, носит самый общий характер (число, текст, дата, графика и т.д.), и будет далее уточнено при проектировании. На этом этапе важно, чтобы домен был определен.
На диаграммах модели бизнес-процессов должны быть представлены работы, вход, выход, управление и механизмы. При этом все элементы должны быть поименованы; все работы должны получаться путем функциональной декомпозиции некоторой более крупной работы; для каждой работы должно быть задано управление.
На диаграммах потока данных должны быть представлены внешние сущности (источники и потребители данных), процессы обработки данных, конкурирующие процессы, хранилища данных, потоки данных, указатели ветвления процессов. При этом все процессы должны быть пронумерованы: исходный (начальный) процесс должен иметь номер 0; процессы более низких уровней - 1.1, 1.2, и т.д.; 1.1.1, 1.1.2, и т.д.
На диаграммах жизненного цикла сущностей и диаграммах состояний должны быть представлены состояния, переходы и внешние переходы. При этом на диаграммах должно присутствовать начальное состояние, из которого получаются все остальные состояния. В конечное состояние можно попасть из любого состояния. Запрещается одновременно переход в два состояния; каждый переход имеет условие и действие, которые указываются рядом с переходом.
Таким образом, формальные процедуры проверки нацелены на проверку таких аспектов анализа, как: наличие у каждой сущности уникального идентификатора; наличие функции, создающей экземпляры сущности; наличие хотя бы одной функции, которая ссылается на сущность, и т.п. В основе формальной проверки лежат такие прагматичные соображения, как: зачем создавать сущность, если она никогда не используется или если к ней никогда не будет произведен доступ; зачем создавать сущность, которую нельзя однозначно идентифицировать и т.п.
Следует иметь в виду, что большинство современных CASE-средств, используемых при анализе предметной области и проектировании баз данных, содержат ряд возможностей по автоматизации описанных формальных процедур.
Формальные процедуры проверки качества моделей позволяют проектировщику базы данных убедиться в их "формальной" достоверности, но не позволяют оценить, насколько они адекватно отражают реальную ситуацию внешнего мира в рамках предметной области. Поэтому часто требуется прибегать к неформальным процедурам проверки результатов моделирования предметной области.
Неформальные процедуры заключаются в проведении личных бесед с аналитиками, постановщиками задач, конечными пользователями и руководителями всех автоматизируемых подразделений, проведении семинаров и совещаний всех участников проекта, а также в изучении материалов анализа предметной области.В ходе неформальных процедур могут быть выявлены существенные ошибки (например, потеря сущности предметной области), которые могут привести к пересмотру некоторых результатов проектирования и реализации баз данных, что в конечном счете может стать причиной срыва запланированных сроков выполнения проекта.1)
По окончании проверки качества моделей предметной области составляется список замечаний.
Все вопросы, возникшие в ходе проведения контроля качества результатов анализа предметной области, разрешаются проектировщиками совместно с аналитиками и руководителем ИТ-проекта. Результаты проверки доводятся до сведения руководителя проекта.
Литература: [1], [8], [9], [17], [22], [24], [25], [26], [27], [28], [30], [32], [33], [35], [44], [45], [46]
Как видно из таблицы, не существует единой модели, в рамках которой можно представить весь жизненный цикл системы. Так, стадия анализа предметной области системы представляется с помощью трех типов моделей:
модели данных, которые описывают внутренние, логические взаимоотношения между данными в системе;модели процессов, которые описывают процессы обработки или преобразования данных в системе;модели состояний, которые описывают поведение или отклики системы на события.
Несмотря на то, что каждая из диаграмм может быть представлена с помощью широкого спектра нотаций, все они в рамках определенной диаграммы имеют общие основные черты. Ниже приведены правила, которыми должен руководствоваться проектировщик в ходе формальной проверки правильности представленных моделей.
На диаграммах "сущность-связь" должны быть представлены сущности, связи, степени связи, классы принадлежности сущности, неопределенные связи, супертипы/подтипы сущности. При этом каждая сущность и отношение должны быть поименованы и занесены в словарь данных; каждая сущность может появиться на диаграмме только один раз; каждая сущность должна вступать в отношение (отсутствие "висящих" сущностей), и каждое отношение должно иметь сущности (отсутствие "висящих" отношений). Поэтому проектировщик базы данных должен проконтролировать, чтобы связь между сущностями осуществлялась через точно указанные атрибуты, которые, вероятнее всего, будут определять уникальный ключ связи.
Проектировщик базы данных должен проконтролировать, чтобы в информационной модели предметной области для каждого атрибута сущностей был определен домен. Следует понимать, что определение домена, даваемое аналитиками, носит самый общий характер (число, текст, дата, графика и т.д.), и будет далее уточнено при проектировании. На этом этапе важно, чтобы домен был определен.
На диаграммах модели бизнес-процессов должны быть представлены работы, вход, выход, управление и механизмы. При этом все элементы должны быть поименованы; все работы должны получаться путем функциональной декомпозиции некоторой более крупной работы; для каждой работы должно быть задано управление.
На диаграммах потока данных должны быть представлены внешние сущности (источники и потребители данных), процессы обработки данных, конкурирующие процессы, хранилища данных, потоки данных, указатели ветвления процессов. При этом все процессы должны быть пронумерованы: исходный (начальный) процесс должен иметь номер 0; процессы более низких уровней - 1.1, 1.2, и т.д.; 1.1.1, 1.1.2, и т.д.
На диаграммах жизненного цикла сущностей и диаграммах состояний должны быть представлены состояния, переходы и внешние переходы. При этом на диаграммах должно присутствовать начальное состояние, из которого получаются все остальные состояния. В конечное состояние можно попасть из любого состояния. Запрещается одновременно переход в два состояния; каждый переход имеет условие и действие, которые указываются рядом с переходом.
Таким образом, формальные процедуры проверки нацелены на проверку таких аспектов анализа, как: наличие у каждой сущности уникального идентификатора; наличие функции, создающей экземпляры сущности; наличие хотя бы одной функции, которая ссылается на сущность, и т.п. В основе формальной проверки лежат такие прагматичные соображения, как: зачем создавать сущность, если она никогда не используется или если к ней никогда не будет произведен доступ; зачем создавать сущность, которую нельзя однозначно идентифицировать и т.п.
Следует иметь в виду, что большинство современных CASE-средств, используемых при анализе предметной области и проектировании баз данных, содержат ряд возможностей по автоматизации описанных формальных процедур.
Формальные процедуры проверки качества моделей позволяют проектировщику базы данных убедиться в их "формальной" достоверности, но не позволяют оценить, насколько они адекватно отражают реальную ситуацию внешнего мира в рамках предметной области. Поэтому часто требуется прибегать к неформальным процедурам проверки результатов моделирования предметной области.
Неформальные процедуры заключаются в проведении личных бесед с аналитиками, постановщиками задач, конечными пользователями и руководителями всех автоматизируемых подразделений, проведении семинаров и совещаний всех участников проекта, а также в изучении материалов анализа предметной области.
В ходе неформальных процедур могут быть выявлены существенные ошибки (например, потеря сущности предметной области), которые могут привести к пересмотру некоторых результатов проектирования и реализации баз данных, что в конечном счете может стать причиной срыва запланированных сроков выполнения проекта.1)
По окончании проверки качества моделей предметной области составляется список замечаний.
Все вопросы, возникшие в ходе проведения контроля качества результатов анализа предметной области, разрешаются проектировщиками совместно с аналитиками и руководителем ИТ-проекта. Результаты проверки доводятся до сведения руководителя проекта.
Литература: [1], [8], [9], [17], [22], [24], [25], [26], [27], [28], [30], [32], [33], [35], [44], [45], [46]
 |
|
|
Согласно данным исследовательской организации Gartner Group, почти половина проектов реализации ИС с базами данными по тем или иным причинам оказывается неуспешной.
| © 2003-2007 INTUIT.ru. Все права защищены. |
Модель потока данных
Модель потока данных предназначена для описания процессов перемещения данных в предметной области базы данных. Модель потока данных представляется в виде диаграммы потока данных (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 млн записей - цифра, характерная для финансовых подсистем крупного предприятия. И база данных "захлебнулась"!
Проектировщики баз данных! Будьте внимательны! Требуйте предоставления полного набора необходимой для принятия проектных решений информации!
Отношения, связи
Сущности не существуют отдельно друг от друга. Между ними имеются реальные отношения (Relationship), и они должны быть отражены в информационной модели предметной области. При выделении отношений акцент делается на фиксацию связей и их характеристик. Отношение (связь) представляет собой соединение (взаимоотношение) между двумя или более сущностями. Каждая связь реализуется через значения атрибутов сущностей. Обычно связь обозначается глаголом. Каждая связь также должна иметь свой уникальный идентификатор связи.
Внимание! В реляционной базе данных отношения реализуются только через ограничение целостности по внешнему ключу. Поэтому проектировщик базы данных должен проконтролировать, чтобы связь между сущностями осуществлялась через точно указанные атрибуты, которые будут определять уникальный ключ связи. Выбор ключей сущностей - одно из важнейших проектных решений, которое предстоит сделать проектировщику при переходе от информационной модели предметной области к логической модели базы данных.
Связи характеризуются степенью связи и классом принадлежности сущности к связи. Степень (мощность) связи - это отношение числа сущностей, участвующих в образовании связи. Например, "один-к-одному", "один-ко-многим", "многие-ко-многим". На уровне информационной модели допускается неопределенная или неразрешенная связь. Класс принадлежности сущности - это характер участия сущности в связи. Различают обязательные и необязательные классы принадлежности сущности к связи. Обязательным является такой класс принадлежности, когда экземпляры сущности участвуют в установлении связи в обязательном порядке. В противном случае сущность принадлежит к необязательному классу принадлежности. Для необязательного класса принадлежности сущности степень связи может быть равна нулю, т.е. экземпляр сущности можно связать с 0, 1 или несколькими экземплярами другой сущности. Для обязательного класса принадлежности степень связи не может равняться нулю.
Отношения, связывающие сущность саму с собой, называются рефлексивными. Типичным примером рефлексивных отношений является определение структуры подчиненности в отношении "Сотрудники". Рефлексивные отношения чаще всего отражают иерархические отношения внутри структуры данных. Они порождают ряд проблем проектирования, о которых речь пойдет позже.
С точки зрения отношений различают слабые (weak) сущности. Слабые сущности - это сущности, которые не могут присутствовать в базе данных, пока не существует связанного с ней экземпляра другой сущности. Примером такой сущности является заказ, который не может существовать без клиента. Слабые сущности имеют обязательный класс принадлежности, и степень связи такой сущности не может равняться нулю. Связь "заказ-клиент" является обязательной.
Выявление слабых сущностей и связанных с ними обязательных отношений необходимо для обеспечения целостности и согласованности данных. Так, например, неизвестному клиенту невозможно приписать заказ.
Подтипы и супертипы
Иногда выделенная сущность несет в себе отношение включения или часть-целое. При этом существует некоторый атрибут, значения которого порождают разбиение множества экземпляров сущности на непересекающиеся подмножества - категории сущности. Категории сущности называются подтипами и выделяют в подчиненную в рамках отношения сущность, которая является категорией исходной сущности.
Иногда из исходной сущности выделяются общие для полученных категорий атрибуты, и таким образом выделяется сущность, которая становится супертипом. За выделенной сущностью-супертипом обычно оставляют наименование исходной сущности, хотя ее семантический смысл меняется.
Супертип с порожденными им подтипами является примером так называемой составной сущности. Составная сущность является логической конструкцией модели для представления набора сущностей и связей между ними как единого целого.
Пример. Сущность Автомобиль можно разбить на следующие подтипы: автомобили с приводом на два колеса, автомобили с приводом на четыре колеса, автомобили с переключаемым приводом.
Для проектировщика базы данных важно знать, что все экземпляры сущности-супертипа относятся только к одному из ее подтипов. Наличие в модели подтипов и супертипов усложняют проектирование и создают определенные трудности в реализации.
Поэтому важно на ранней стадии проектирования установить, является ли наличие супертипов в модели необходимым. Для этого можно предпринять следующие действия:
установить, много ли одинаковых свойств имеют различные подтипы. Следует помнить, что чем меньше подтипы похожи друг на друга, тем больше вероятность введения супертипа, или найти экземпляр сущности, который можно обоснованно включить в более чем один подтип. Поскольку это противоречит определению супертипа, то предлагаемое разбиение недопустимо.
Понятие функциональной модели предметной области базы данных
Вторым ключевым моментом создания ИС с целью автоматизации информационных процессов организации является анализ функционального взаимодействия объектов автоматизации. Результаты такого анализа многогранны. Аналитики представляют их в виде функциональной модели предметной области базы данных. Функциональная модель предметной области является собирательным понятием. Состав функциональной модели существенно зависит от контекста конкретного ИТ-проекта и может быть представлен посредством довольно широкого спектра документов в виде текстовой и графической информации. К рассмотрению таких документов проектировщик баз данных должен подходить с учетом следующих двух положений:
главное назначение ИС является базовым критерием оценки достаточности предоставляемой информации;функциональная модель предназначена для описания процессов обработки данных в рамках выделенной предметной области с различных точек зрения.
Описать процессы обработки информации всесторонне с помощью одной описательной модели сложно. В последнее время предпринимаются некоторые успешные попытки разработать унифицированную модель в рамках объектно-ориентированного анализа и проектирования (OOA&D) с помощью UML-конструкций. В настоящих лекциях мы основываемся только на результатах структурного анализа предметной области как наиболее прагматичном подходе для проектирования классических реляционных баз данных. Использование объектно-ориентированного подхода к проектированию баз данных - это предмет отдельного курса лекций.
Определим функциональную модель предметной области базы данных как совокупность некоторых моделей, предназначенных для описания процессов обработки информации. Будем называть эти модели конструкциями функциональной модели. Ниже приведен перечень основных конструкций функциональной модели, необходимые для выполнения проектирования реляционных баз данных.
Модели процессов: бизнес-модель процессов (иерархия функций системы);модель потока данных.Модели состояний: модель жизненного цикла сущности;набор спецификаций функций системы (требования);описание функций системы через сущности и атрибуты;бизнес-правила, которые реализуют функции.Внимание! Элементы информационной модели предметной области являются входными данными для задачи создания логической модели данных. Элементы функциональной модели предметной области являются входными данными для задачи проектирования приложений базы данных и, частично, для задачи создания физической модели базы данных.
Понятие предметной области
Основным назначением информационных систем является оперативное обеспечение пользователя информацией о внешнем мире путем реализации вопросно-ответного отношения. Вопросно-ответные отношения, получая интерпретацию во внешнем мире (мире вне информационной системы), позволяют выделить для информационной системы определенный его фрагмент - предметную область, - который будет воплощен в автоматизированной информационной системе. Информация о внешнем мире представляется в информационной системе (ИС) в форме данных. Это ограничивает возможности смысловой интерпретации информации и конкретизирует семантику ее представления в ИС. Совокупность этих выделенных для ИС данных, связей между ними и операций над ними образует информационную и функциональную модели предметной области, описывающие ее состояние с определенной точностью.
Важно понимать, что информационная и функциональная модели предметной области создаются на этапе анализа требований к базе данных и не содержат предположений о технологии реализации базы данных. Они строятся независимо от выбираемой модели данных (сетевой, иерархической, реляционной, объектно-ориентированной, многомерной и т.д.), поддерживаемой СУБД, модели вычислений, программно-аппаратной платформы для базы данных. Информационная и функциональная модели предметной области являются входными данными для процесса проектирования базы данных. Поэтому проектировщик должен уметь правильно интерпретировать их в ходе решения своих проектных задач.
Понятие предметной области базы данных является одним из базовых понятий информатики и не имеет точного определения. Его использование в контексте ИС предполагает существование устойчивой во времени соотнесенности между именами, понятиями и определенными реалиями внешнего мира, не зависящей от самой ИС и ее круга пользователей. Таким образом, введение в рассмотрение понятия предметной области базы данных ограничивает и делает обозримым пространство информационного поиска в ИС и позволяет выполнять запросы за конечное время.
Совокупность реалий (объектов) внешнего мира - объектов, о которых можно задавать вопросы, - образует объектное ядро предметной области, которое имеет онтологический статус. Нельзя получить в ИС ответ на вопрос о том, что ей неизвестно. Термин объект является первичным, неопределяемым понятием. Синонимами термина "объект" являются "реалия, сущность, вещь". Однако термин сущность понимается нами несколько уже, как компонент модели предметной области, т.е. как уже выделенный на концептуальном уровне объект для базы данных. Таким образом, выделяемые в предметной области объекты превращаются аналитиками (а не проектировщиками базы данных) в сущности. Сущность предметной области является результатом абстрагирования реального объекта путем выделения и фиксации набора его свойств. Сущность является результатом абстрагирования реального объекта, т.е. в нашем контексте имеет гносеологический статус. Хотя далее в контексте сущность н ередко отождествляется с объектом.
На рис. 2.1 представлен один из подходов к классификации объектов предметной области.
Рис. 2.1. Классификации объектов предметной области
Примерами сущностей (с точки зрения ИС) или объектов (с точки зрения внешнего мира) являются отдельный студент, группа студентов, аудитория, время занятий, слова, числа, символы. Обычно считается, что быть объектом - это значит быть дискретным и различимым. Примеры "не-объектов" - это мир, время, смысл, хотя и такие категории могут сохраняться в базе данных.
С объектами связано две проблемы: идентификация и адекватное описание. Для идентификации используют имя. При этом предполагается, что происходит отказ от его смысла, который присущ естественному языку. Используется только указательная функция имени. Имя - это прямой способ идентификации объекта. К косвенным способам идентификации объекта относят определение объекта через его свойства (характеристики или признаки).
Объекты взаимодействуют между собой через свои свойства, что порождает ситуации.
Ситуации - это взаимосвязи, выражающие взаимоотношения между объектами. Ситуации в предметной области описываются посредством высказываний о предметной области с использованием исчисления высказываний и исчисления предикатов, т.е. формальной, математической логики. Например, высказывание "Программист и менеджер есть служащие компании" описывает отношение включения. Таким образом, вся информация об объектах и сущностях предметной области описывается с помощью утверждений на естественном языке.
Методы математической логики позволяют формализовать эти утверждения и представить их в виде, пригодном для анализа.
Пример. Рассмотрим высказывание: Студент Иванов А.А, родился в 1982 году. Оно выражает следующие свойства объекта "Иванов А.А.":
в явном виде - год рождения;в неявном - принадлежность к студентам.
Первое свойство устанавливает связь между объектами "Иванов А.А." и "Год рождения", а второе - между объектами "Иванов А.А." и "Множество студентов". Формализация этого высказывания представляется как результат присваивания значений переменным, входящим в предикаты:
РОДИЛСЯ (Иванов А.А., 1982)
ЯВЛЯЕТСЯ СТУДЕНТОМ (Иванов А.А.)
Отметим, что в семантике естественных языков ситуация и взаимосвязь считаются почти синонимами. Ситуация содержит высказывание об объектах предметной области, которому можно приписать некоторую оценку истинности и представить в виде предиката после введения переменных. Таким образом, совокупность высказываний о предметной области можно трактовать как определение информационного пространства для базы данных.
На рис. 2.2 представлен один из подходов к классификации ситуаций в рамках предметной области.
Рис. 2.2. Классификация ситуаций предметной области
Различают статические и динамические ситуации. Примерами статических ситуаций являются такие ситуации, как иметь цвет, иметь возраст. Примерами динамических ситуаций являются такие ситуации, как создать утюг, выпечь хлеб.
Обратите внимание на то, что ситуация также может представлять собой объект (см. рис. 2.1) и обладать свойствами. С другой стороны, приведенная классификация рассматривает свойства как специальный случай ситуаций. Подобная коллизия порождает неоднозначность при моделировании предметной области базы данных. Поставим вопрос - что есть цвет автомобиля? Объект, свойство, ситуация? К обсуждению этого вопроса мы вернемся специально в следующей лекции.
Приведенная классификация вводит в предметную область два важных аспекта - пространство и время, причем время и как момент, и как интервал. Предметная область существует в пространстве и во времени, т.е. ей присущи, как и реальному миру, временные и пространственные отношения и связи. Следует отличать реальное время внешнего мира и его отражение в базе данных и в источниках информации. В базе данных взаимосвязи, зависящие от времени, фиксируются только после их регистрации в базе данных. Таким образом, предметная область в каждый конкретный момент времени представляет собой выделенную совокупность определенных объектов и ситуаций, называемую состоянием предметной области (или снимком).
Введем определение предметной области.
Определение. Предметная область - это целенаправленная первичная трансформация картины внешнего мира в некоторую умозрительную картину, определенная часть которой фиксируется в ИС в качестве алгоритмической модели фрагмента действительности.
Понятие предметной области было введено в начале 80-х годов прошлого века, когда учеными в области ИС была осознана необходимость использовать семантические модели для представления информации в компьютерных системах. Так же как требования к компьютерной системе формируются средствами естественного языка, так и информация в компьютерных системах представляется средствами особого языка с определенной семантикой. Такой подход впервые был представлен П. Ченом в 1976 году.
Сущности, атрибуты и идентификаторы (ключи) сущности, домены атрибутов
Предметом информационной модели является абстрагирование объектов или явлений реального мира в рамках предметной области, в результате которого выявляются сущности (entity) предметной области. Как правило, они обозначаются именем существительным естественного языка.
Сущность описывается с помощью данных, именуемых свойствами или атрибутами (attributes) сущности. Как правило, атрибуты являются определениями в высказывании о сущности и обозначаются именами существительными естественного языка. Сущности вступают в связи друг с другом через свои атрибуты. Каждая группа атрибутов, описывающих одно реальное проявление сущности, представляет собой экземпляр (instance) сущности. Иными словами, экземпляры сущности - это реализации сущности, отличающиеся друг от друга и допускающие однозначную идентификацию.
Внимание! При представлении сущности в базе данных хранятся только ее атрибуты.
Одним из основных компьютерных способов распознавания сущностей в базе данных является присвоение сущностям идентификаторов (Entity identifier). Часто идентификатор сущности называют ключом. Задача выбора идентификатора сущности является семантически субъективной задачей. Поскольку сущность определяется набором своих атрибутов, то для каждой сущности целесообразно выделить такое подмножество атрибутов, которое однозначно идентифицирует данную сущность.
Некоторые сущности имеют естественные идентификаторы. Например, естественным идентификатором счета-фактуры является его номер. Идентификаторы сущности могут быть составными - составленными из нескольких атрибутов и атомарными - составленными из одного атрибута сущности.
Идентификация сущностей проводится аналитиками. Однако чаще всего их решение не является окончательным! Задача проектировщика баз данных - обеспечить при сохранении экземпляров сущности в базе данных наличие у каждого ее нового экземпляра уникального идентификатора. Уникальный идентификатор сущности - это атрибут сущности, позволяющий отличать одну сущность от другой. Если сущность имеет несколько уникальных идентификаторов, так называемых возможных ключей, то проектировщик должен выбрать первичный ключ сущности.
Различают однозначные и многозначные атрибуты. Однозначными являются атрибуты, которые в пределах конкретного экземпляра сущности имеют только одно значение. В противном случае они считаются многозначными.
Важным моментом изучения информационной модели проектировщиком является выделение многозначных атрибутов сущности. Это связано с тем, что реляционная модель базы данных не поддерживает многозначных атрибутов, и они должны быть разрешены на последующих стадиях проектирования.
Каждый атрибут сущности имеет домен (domain). Домен - это выражение, определяющее значения, разрешенные для данного атрибута. Иными словами, домен - это область значений атрибута. Проектировщик базы данных должен проконтролировать, чтобы в информационной модели предметной области для каждого атрибута сущностей был определен домен.
На уровне информационного моделирования данных назначение домена атрибуту носит общий характер. Например, атрибут текстовый, числовой, бинарный, дата или "не определен". В последнем случае аналитик должен дать описание домена. На последующих стадиях тип домена конкретизируется, смысл понятия домена в логической и физической моделях базы данных уже, чем его может понимать аналитик. Это связано с тем, что в рамках физической модели базы данных домен реализуется посредством механизма ограничения домена, СУБД не понимает неопределенных доменов.
