Функционализация модели. 
Базы данных: проектирование

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

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

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

Так, бизнес-процессы и бизнес-функции, как правило, остаются с наименованиями, определенными в рамках моделирования бизнес-процессов, но иногда могут быть скорректированы с учетом терминологии при реализации учетных или аналитических информационных систем. Тогда в наименованиях функций и задач будут присутствовать выражения: «Учет …» или «Аналитическая обработка …» Такая терминология позволяет разработчику базы данных понять, что в первом случае («Учет…») должен существовать простой функциональный объект, который используется в базе данных в оперативном режиме всеми возможными операциями обработки (добавление, изменение, удаление, выборка). Во втором случае («Аналитическая обработка …») ключевым является объект хранилища данных с выделением агрегатного атрибута и атрибутов-измерений. В обоих случаях процесс моделирования выполняется по идентичным принципам и правилам. Тем не менее, если формулировка бизнес-процесс или бизнесфункции достаточно информативна и по пей можно выделить основной объект, который, как правило, представляется существительным-объектом, то формулировка функции может не изменяться.

На уровне вспомогательных функций и задач выделяются действия, направленные на формирование всевозможных классификаторов и справочников. Эти функции носят накопительный характер операций, что описывается формулировкой «Учет …» с выделением в этой формулировке существительного-объекта, который будет определяться в качестве ключевого (рис. 4.20).

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

Рис. 4.20. Дерево функций рассматриваемого примера.

Функционализация модели в виде дерева функций дала возможность в инструментальном средстве IBM InfoSphere Data Architect сформировать комплекс диаграмм, которые необходимы для упрощения представления модели, ограничив количество сущностей, которые в модели должны быть отражены (рис. 4.21). На каждом уровне диаграммы моделей базы данных, помимо отражения дочерних диаграмм, будет отражаться модель базы данных, имеющей отношение именно к рассматриваемой диаграмме.

Рис. 4.21. Пример взаимосвязи диаграмм модели базы данных.

В итоге функционализации моделей базы данных будет сформировано множество диаграмм (рис. 4.22), которые будут отображать модель, ориентированную на логическую модель работы с конкретным объектом предметной области.

Рис. 4.22. Пример сформированного множества взаимосвязанных диаграмм.

Модель функционализации может также представляться единой диаграммой (рис. 4.23). Обычно это делается, когда предметная область не очень сложная и дерево функций содержит не очень разветвленную структуру.

Рис. 4.23. Сводная модель взаимодействия диаграмм.

В таких предметных областях, как правило, количество объектов тоже небольшое и модель базы данных ограничивается парой-тройкой десятков сущностей. Для сложных предметных областей целесообразно модели диа;

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

Выделение ключевых сущностей Дальнейший процесс моделирования базы данных ориентирован па объекты рассматриваемой задачи, их атрибутивный состав и модель базы данных, получаемой в ходе нормализации выделяемых объектов. Как говорилось ранее, выделение ключевого объекта (сущности) основывается на формулировке функции, представляемой соответствующей диаграммой. В ее названии должно присутствовать существительное, ассоциированное с объектом предметной области. Обычно такое формулирование выполняется на уровне моделирования бизнес-процессов и вспомогательных функций и задач с параллельным определением входящих и выходящих информационных потоков. Выходящий информационный поток должен представлять тот самый ключевой информационный объект, моделирование которого выполняется в соответствующей диаграмме. Входящие информационные потоки являются информационными объектами для диаграмм, находящихся уровнем ниже или на том же уровне, но направлением стрелки связи диаграмм иллюстрирующие информационное влияние па рассматриваемую модель.

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

Рассмотрение функции «Учет категорий товаров». Выбор данной функции основан на двух моментах:

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

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

В имени функции содержится указание на ключевой информационный объект — «Категория товаров». На этапе построения бизнес-процессов было определено, что категории товаров имеют подкатегории, поэтому его атрибутивный состав будет включать соответствующий атрибут. Но, прежде чем рассматривать атрибутивный состав, необходимо в диаграмме «Учет категорий товаров» отразить соответствующую сущность (рис. 4.24).

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

Рис. 4.24. Сущность, соответствующая ключевому информационному объекту.

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

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

Таблица 4.8.

Описание атрибутивного состава информационного объекта, представляемого ключевой сущностью диаграммы, заключается в определении всех составляющих атрибута сущности в модели базы данных:

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

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

При рассмотрении атрибутов разработчиком могут быть выявлены три основных вида атрибутов:

• • стандартный атрибут — характеризуется простыми типами данных, обозначающих хранение однозначно понимаемого значения;
• • объектный атрибут — характеризуется связью с другим объектом предметной области, определяя необходимость получения вспомогательных данных, при первичном моделирование будем обозначать типом данных, который максимально идентичен сути атрибута (например, datalink, binary, table и т. д.);
• • структурный атрибут — характеризуется необходимостью разделения на отдельные структурные (атрибутивные) элементы, но не представляется объектом предметной области, аналогично объектному атрибуту первоначально в модели может быть отражен максимально идентичным типом данных.

В результате модель базы данных в диаграмме получает сущность «Категория товаров» (рис. 4.25), но, ввиду факта, что наименование является символьным атрибутом и не должно использоваться в качестве первичного ключа, необходимо (табл. 4.9):

• 1) создать суррогатный первичный ключ с автоматическим заполнением, т. е. обладающим типом «Serial» или аналогичным.
• 2) определить альтернативный ключ по атрибуту «Наименование категории», обеспечив уникальность значений.

Рис. 4.25. Наполнение сущности атрибутами.

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

• — тип ключа, обладающий тремя значениями — первичный, внешний и альтернативный;
• — тип данных, по которому можно понять правила заполнения данными, где если указывается числовой тип с обозначением в скобках правила заполнения (например, «+1»), то предполагается, что значение будет формироваться автоматически по указанному правилу арифметической прогрессии;
• — уникальность, где отражается принцип проверки уникальности значения, обладающего двумя значениями — индекс (построение индексной таблицы для эффективного поиска и контроля уникальности) и ограничение (формирование программной логики проверки уникальности значения);
• — дополнительно, где указываются прочие правила работы с ключом, в том числе свойство, указывающее на признак ключа в качестве суррогатного, т. е. не используемого в предметной области.

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

Таким образом, выполнив все операции по моделированию ключевой сущности, получаем ее представление в диаграмме (рис. 4.26), где указаны все необходимые для описания сущности атрибуты, с отображением типов данных, характеризующих значения, признака возможности хранения пустых значений и указания на первичный и альтернативные ключи. Аббревиатура «ИДФ» в наименовании первичного ключа представлена как один из вариантов обозначения идентификационного атрибута, расшифровываясь как «Идентификатор». Впоследствии, когда будут формироваться вспомогательные сущности, у ключевой сущности могут появиться внешние ключи, описание которых позволит расширить и уточнить соответствующую таблицу описания ключей.

Рис. 4.20. Итоговое представление ключевой сущности.

Рассмотрение функции «Наполнение заказа товарами». Функция, согласно формулировке, обеспечивает наполнение заказа клиента товарами с указанием количества. Изучение функции позволяет сформировать перечень атрибутов, которыми характеризуется заказ (табл. 4.10).

В сущности имеется два объектных атрибута — «Клиент» и «Товары», представленные в предметной области соответствующими объектами. При этом атрибут «Товары» может не иметь значения, поскольку клиент начинает формировать заказ не наполнением его товарами, а фактом начала работы с заказом в момент получения списка товаров для выбора.

Таблица 4.10.

Важно отметить, что в момент начала формирования заказа атрибут «Номер заказа» также может иметь пустое значение, поскольку его заполнение целесообразно только при формировании заказа, наполненного товарами, для передачи оператору.

Как очевидно из таблицы описания атрибутивного состава сущности, некоторые атрибуты обладают свойствами «Умолчание» и «Ограничение». Ввиду того, что логическая модель строится без привязки к СУБД, условия ограничения и умолчания формулируются с использованием естественного языка и стандартных логических выражений.

Также среди атрибутов есть такой, который требует вычисления. Это атрибут «Стоимость». Для его вычисления требуется использовать цену товара и количество заказанного товара. В процессе моделирования формула может быть представлена обычными математическими выражениями без учета местоположения того или иного атрибута. Поэтому в описании формула представлена следующим образом: «Товары. Цена * Количество». Здесь показано, что значение атрибута «Цена» должно быть взято из сущности «Товары», а значение атрибута «Количество» — из текущей сущности. Впоследствии эта формула должна быть представлена более формализованным вариантом или необходимо провести дополнительную логическую нормализацию, о которой речь пойдет позже, в рамках соответствующего раздела.