Критерии качества даталогических схем. Полнота моделей данных

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

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

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

Таким образом, мы абсолютно точно должны представлять, какими свойствами должна обладать наша даталогическая модель (или каким требованиям соответствовать, что одно и то же) и каким образом можно количественно измерить (выразить) эти свойства. Очевидно, что из ста альтернативных схем наилучшей окажется та, которая обладает «по сумме» наилучшими значениями всех критериев.

1. Требования к модели данных.

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

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

Рис. 1

даталогический предметный информационный

Рис. 2

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

Каждое из свойств-требований нуждается в отдельном рассмотрении. Но начнём с полноты, так как именно полноте адресована настоящая статья.

Для пользователей информационной системы полнота всегда ассоциируется с функциональными возможностями ИС. Если говорить более точно, то для пользователей важнее всего число задач (функций, процессов), автоматизацию которых «берёт на себя» информационная система, а также значимость отдельных задач, поскольку решаемые задачи не равнозначны по отношению друг к другу. Что из этого вытекает? Прежде всего, то, что критерий, отражающий полноту информации, должен быть относительным критерием, например, таким:

, (1)

где - количество задач предметной области, решаемых в автоматизируемом режиме на момент времени t;

- количество задач, которые должны решаться в автоматизированном режиме.

Здесь, правда, никак не учтена значимость отдельных задач, но это пока и не требуется. На первый взгляд такой критерий абсолютно правильный, кроме того, ещё и простой и поэтому интуитивно понятный. Но по нескольким веским причинам нам придётся отказаться от его использования. Во-первых, этот критерий не отражает логическую взаимосвязь задач (функций), которые к тому же тяготеют к объединению в микросистемы (подсистемы) и, следовательно, порождают тем самым другую проблему - проблему оценки полноты подсистем. (Эта проблема может быть сведена к поиску минимального набора задач, которые в обязательном порядке должны быть включены в состав задач, образующих подсистему.) Во-вторых, он (критерий) не проводит различий между функциями, обеспечивающими обработку первичных данных, и функциями, которые нацелены на аналитическую обработку и вследствие этого по очевидным причинам не должны в полном объёме приниматься в расчёт. (Заметим, что аналитические функции частично могут участвовать в формировании первичных данных). Поскольку статья посвящена рассмотрению критериев качества моделей данных, а модели данных представляют собой структуры, в которых хранятся только первичные данные, то вторая группа функций может просто не приниматься в расчёт. Что же касается отслеживания взаимосвязи функций, то и здесь далеко не всё так очевидно и просто.

Предположим, что информационная система может вести автоматизированный учёт поступающих денежных средств, но в то же время в ней отсутствуют функции, фиксирующие расход денег. В чём заключается необходимость в автоматизации первой функции, если отсутствует возможность контроля всего денежного потока? Например, каким образом можно узнать, сколько денежных средств находится сейчас в кассе или на расчётном счёте? Аналогичные тривиальные примеры можно привести для поступления и расходования, например, материалов и товаров, выпуска и реализации готовой продукции и многого другого, что подлежит обязательному учёту в информационных системах. Таким образом, о полноте информации (степени полноты информации, так как это относительная величина) следует судить не по числу автоматизированных функций отнесённых к общему числу функций, а по реализации всех функций, обеспечивающих жизненные циклы объектов предметной области.

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

2. Модели жизненного цикла объектов моделей данных. Модель «местоположений-перемещений»

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

- требования к подобным моделям со стороны «вышестоящей» (информационной) системы;

- элементный состав подобных моделей и виды взаимодействий, которые могут существовать между элементами моделей;

- разновидности МЖЦ, если для удовлетворения всех требований какого-то одного класса МЖЦ окажется недостаточно.

За отправную точку всех последующих рассуждений возьмём основные виды взаимодействий, в которые могут вступать между собой объекты моделей данных, поскольку всё, что происходит с объектами в предметной области, - это результаты их взаимодействий и не что иное. В работе [1] эти взаимодействия были обозначены как взаимодействия местоположения, состава и порядка, причём каждое из них в отдельности рассматривалось в двух независимых срезах (аспектах) - нормативном и фактическом. Если нормативный аспект даталогически моделировал опорную (плановую) траекторию взаимодействия, то фактический показывал соответственно фактический ход развития событий.

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

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

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

- источники поступления и выбытия объектов соответственно в предметную область и из предметной области;

- места расположения объектов;

- допустимые разновидности перемещений между местоположениями (перемещения помечены направленными связями).

Рис. 3

Рис. 4

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

Несколько сложнее определиться со способами задания местоположения объектов. Перечень, который мы сейчас представим, может оказаться неполным, но при желании он всегда может быть расширен.

Первый способ - зафиксировать координаты объекта и добиться тем самым абсолютной точности его позиционирования (абсолютное позиционирование).

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

Ещё один способ - задать неявное (приблизительное) местоположение объекта. Например, материалы «в пути», самолеты «в воздухе» и т.п. (неявное позиционирование). Какие из перечисленных способов или комбинации способов будут выбраны, зависит только от состава требований, которые будут предъявлены к способам позиционирования объектов в местах их предварительно заданной дислокации.

Завершит построение первого приближения модели жизненного цикла указание возможных путей перемещения объектов между местами их расположения.

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

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

Фактически только для небольшого числа объектов нужно в действительности отслеживать их многочисленные местоположения и соответствующие перемещения. Для всех остальных объектов можно ограничиться фиксацией только двух событий - появлением объекта в предметной области и оставлением объектом предметной области. И это несмотря на то, что в действительности у объекта может быть достаточно сложный жизненный цикл. Подобного рода требование к МЖЦ можно классифицировать как неполное. Следовательно, если оно указано, то отпадает необходимость в построении графа перемещений между возможными местоположениями, так как местоположением для объекта в данном конкретном случае оказывается вся предметная область.

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

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

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

Таблица 1 - Требования к детализации МЖЦ объектов предметной области

Название типа объекта	Способ позиционирования (абсолютный, относительный, неявный)	Список объектов, определяющих местоположение	Модели жизненного цикла
			«Полная»	«Неполная»
Материалы	Относительный	Личности, подразделения
Личности	Относительный	Подразделения, должности
Изделия	Относительный	Подразделения, личности
Оборудование	Абсолютный	-
Должности	Неявный	-
Денежные средства	Неявный	-
Полуфабрикаты	Относительный	Личности, подразделения
Подразделения	Относительный	Личности, подразделения

2. Для объектов с полным жизненным циклом следует построить графические модели жизненного цикла и сделать это нужно примерно так, как было показано на рисунках 3 и 4.

3. Опираясь на построенные модели, следует для каждого объекта указать способ его позиционирования, а для каждого относительного способа ещё и перечислить объекты, посредством которых определяется местоположение.

3. Действия и состояния.

Как нетрудно заметить, изучая рисунки 3 и 4, местоположение объекта («склад», «в пути», «в учебном заведении», «в отпуске», «в командировке») дополнено также действием, которое выполняет объект или которое выполняется над объектом («хранение», «зарезервировано», «учится» и т.д.). Интересно, что каждая разновидность объектов характеризуется в том числе и уникальным набором действий, которые эти объекты могут совершать или которые над ними могут производиться. Вот примерный список действий для такого объекта, как оборудование: работает, простаивает, не установлено (находится на складе), находится на техническом обслуживании, неработоспособно (сломано), ремонтируется, законсервировано. Этот список может быть продолжен.

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

Действия над объектами, как и действия, выполняемые с объектами, могут совершаться и в процессе изменения местоположения объектов. Вот только один из многочисленных примеров такого рода. «В автомобиль-миксер загружаются исходные компоненты, необходимые для получения бетона: песок, цемент, щебень, вода, - и автомобиль, водитель которого запускает устройство, осуществляющее перемешивание этих компонентов, отправляется на строительную площадку. По прибытии к месту назначения в миксерном барабане оказывается бетон, полученный из перечисленных ингредиентов». Всё сказанное позволяет сформулировать одно из обязательных требований, имеющее прямое отношение к полноте модели данных. Каждое «местоположение», занимаемое объектом, должно быть дополнено списками действий, совершаемых соответственно объектом и над объектом в этой точке пространства. Только при условии реализации сформулированного требования МЖЦ действительно начинают более или менее полно отражать траекторию и поведение моделируемых объектов в предметной области.

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

Представляется, что между состояниями и действиями существует определённая взаимосвязь. Чтобы окончательно прояснить сложившуюся ситуацию, построим дерево абстракций обобщения (рисунок 5) для совокупности действий, которые выполняет, к примеру, станок, изготавливающий сетки из арматурной проволоки. Как нетрудно заметить, появились новые обобщенные действия: «работоспособен», «неработоспособен», «отключён». Мы не вправе ставить вопрос о том, нужны ли такие обобщения. Если в предметной области эти обобщённые действия принято использовать, значит, они для чего-то (вероятнее всего, для управления) нужны, следовательно, информационная система должна каким-то образом их фиксировать и отслеживать.

После ввода в оборот такой категории, как «действие», необходимость в использовании состояний на первый взгляд отпадает. Состояния, как можно предположить, внимательно рассматривая рисунок 5, - это, скорее, обобщение либо элементарных действий, либо промежуточных состояний. В том, что состояния столь же актуальны, как и сами действия, убедимся несколько позже.

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

Рис. 5

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

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

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

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

4. Обобщённые действия и обобщённые состояния.

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

Рис. 6

Если объект исправен (работоспособен), то он может либо поддерживать свою функциональность, либо не поддерживать. Например, автомобиль может ехать (функционировать), а может просто стоять на месте (не функционировать). Соответственно неисправный (неработоспособный) объект функционировать в принципе не может, а такие состояния, как «неработоспособность» и «нефункционирование» идентичны.

Перейдём к рассмотрению взаимодействий между действиями классов № 1 и № 3.

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

Таким образом, обобщённое состояние любого объекта - это всегда одна из нижеперечисленных пар обобщённых действий:

- рабоспособность - функционирование;

- рабоспособность - нефункционирование;

- агрегирование - функционирование;

- агрегирование - нефункционирование;

- деагрегирование - функционирование;

- деагрегирование - нефункционирование.

Как следствие, изменение обобщённого состояния - это замена одной из перечисленных пар обобщённых действий на другую пару.

На небольшом примере покажем, каким образом это может происходить.

Пусть автомобиль (объект) «своим ходом» добирается до станции техобслуживания (рабоспособность - функционирование), а по прибытии на станцию ожидает своей очереди на обслуживание (рабоспособность - нефункционирование). Затем автомобиль проходит техническое обслуживание (рабоспособность - нефункционирование), которое выявляет необходимость ремонта двигателя. Двигатель снимается с автомобиля (деагрегация - функционирование) и устанавливается обратно на своё место (деагрегирование - функционирование). После пробного запуска отремонтированного двигателя установлено, что автомобиль работоспособен (рабоспособность - нефункционирование).

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

Предположим, что базисная часть МЖЦ (назовем её моделью «местоположения - перемещения») построена (рисунок 3 или рисунок 4). Далее для каждого объекта формируются два списка действий: те, которые сам объект совершает или которые совершаются над объектом. Но простого перечисления действий недостаточно. Необходимо также задать и иерархию действий. Самой удачной конструкцией для представления этой иерархии будет лес. Узлы деревьев будут соответствовать действиям, а сам лес будет выглядеть примерно так, как это показано на рисунке 7.

Рис. 7

Количество деревьев будет равно числу обобщённых состояний. Разрешённые связи, которые могут устанавливаться между элементами различных деревьев, задаются графом обобщённых состояний, показанном на рисунке 6, и здесь не отсутствуют.

5. Способы фиксации действий - состояний.

Нетрудно догадаться, что и действия, и состояния - это не более чем абстракции, формирующиеся в сознании человека. Очевидно, что списки элементарных действий, в построении которых будут принимать участие разные индивидуумы, также окажутся различными. Единственное, в чём, по всей видимости, не случится между ними разногласий, так это в наборах обобщённых действий, элементы которых были только что перечислены. Таким образом, источником информации о действиях всегда будет эксперт или группа экспертов, и это, вне сомнения, наложит отпечаток субъективизма на выбор конкретных действий, включаемых в тот или иной набор. Несмотря на то, что действие представляет собой абстракцию, оно обладает рядом очевидных характеристик, которые нетрудно отслеживать средствами информационной системы. К таким характеристикам можно отнести время начала и время окончания действия, ссылку на субъекты, которые инициировали и прекратили действия, и другую информацию подобного рода. Такие сведения в явном или неявном виде всегда присутствуют в документах, являющихся единственным и одновременно универсальным источником любых данных об объектах. Из всего сказанного логически вытекают два способа фиксации действий объектов в базах данных. Самый простой способ - обеспечить принудительный ввод действий (состояний) так, как, например, это принято делать при вводе ссылок на справочные данные, которые хранятся в специализированных справочных структурах (рисунок 8).



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

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

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

Обособленно от всех других действий располагаются действия, попадающие под категорию «агрегирование/деагрегирование».

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

Таблица 2 - Требования к способам фиксаций действий и состояний даталогических объектов

Название типа объекта

Фиксация действия - состояния (да, нет)

Способ фиксации состояний для групп

Способ отслеживания траекторий

I-я группа

II-я группа

III-я группа

Агрегирование

Деагрегирование

Работоспосбен

Неработоспособен

Функционирует

Не функционирует

Агрегирование

Деагрегирование

«Состав»

«Порядок»

«График»

«Состав»

«Порядок»

«График»

Материалы

Да

Ручной

Ручной

Личности

Да

Документальный

Документальный

Изделия

Да

Документальный

Оборудование

Да

Ручной

Должности

Нет

Денежные средства

Нет

Полуфабрикаты

Да

Документальный

Ручной

Подразделения

Нет

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

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

2. Отсутствие по каким-либо причинам необходимости в фиксации действий (столбец 2 таблицы) автоматически влечёт за собой «обнуление» данных в столбцах с 3-го по 14-й. Попутно отметим, что в реальных информационных системах для большинства объектов будет указано именно это требование.

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

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

5. Несмотря на то, что экземпляр какого-нибудь объекта может одновременно выполнять несколько действий (как и над этим экземпляром, в свою очередь, могут совершаться тоже несколько действий), число обобщённых состояний конечно и равно двум.

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

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

6. Критерий полноты модели данных.

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

Этот критерий, как ранее выяснилось, во-первых, должен быть относительным. Знаменатель должен отражать требования к полноте со стороны предметной области, а числитель - полноту, которую информационная система в состоянии обеспечить. Подчеркнём, что не модель данных, а именно информационная система - ведь совершенно недостаточно создать структуры данных. Это делается быстро и просто средствами современных СУБД. Главное, чтобы эти структуры «работали», чтобы в них программной частью информационной системы вносились соответствующие данные. Поэтому в отношении этого критерия нельзя определить его однозначную «принадлежность» исключительно модели данных. Но рассчитать его можно, только если оперировать в основном категориями модели данных.

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

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

В-четвёртых, критерий должен также каким-то образом учитывать неравнозначность объектов в моделируемой предметной области. Что мы понимаем под неравнозначностью объектов?

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

Понять, какие из объектов главные, а какие вспомогательные, очень просто. Достаточно заполнить реальными значениями ячейки таблиц 1 и 2. Одна только отметка о неполной МЖЦ будет сигнализировать о невысокой значимости объекта. Об этом же скажет и отсутствие требования к отслеживанию состояний. Список можно при желании продолжить.

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

Таблица 3 - Примерная оценочная трудоёмкость реализации значимых компонентов МЖЦ даталогических объектов

№	Компоненты и элементы моделей жизненного цикла	Условная трудоёмкость
1	Неполная модель жизненного цикла	1
2	Переходы между местоположениями, отслеживаемые посредством:
2.1	- «слабых сущностей»	10
2.2	- 2автономных» (не включенных в деловой процесс) документов	20
2.3	- документов, «увязанных» в деловой процесс	от 40 и выше
3	Изменение состояния внутри местоположения посредством использования
3.1	- справочников;	10
3.2	- документов;	20
3.3	- деловых процессов	от 40 и выше
4	Отслеживание траекторий агрегрования - деагрегирования:
4.1	- состава	от 40 и выше
4.2	- порядка	от 50 и выше
4.3	- графика	от 60и выше

Условная единица трудоёмкости - это безразмерная величина, которой можно поставить в соответствие и 50, и 75, и 100 человеко-часов. Но не это главное. Использование такой единицы измерения даёт возможность показать, в каком количественном соотношении находятся между собой оцениваемые компоненты моделей жизненного цикла даталогических объектов, что, как нам представляется, удалось сделать. Без сомнения, значения условной трудоёмкости, перечисленные в таблице 3, - это весьма приблизительные оценки, и дело экспертов - получить близкие к истине величины. Сейчас запишем формальное выражение, которое и предложим в качестве искомого критерия полноты модели данных.

, (2)

где - критерий полноты модели данных;

- индекс даталогического объекта;

- индекс оцениваемого элемента. Все оцениваемые элементы, соответствующие индексу, перечислены в таблице;

- количество оцениваемых элементов;

- трудоёмкость реализации -го элемента.

Числитель выражения (2) - это уже реализованная информационной системой «трудоёмкость» автоматизированного обеспечения МЖЦ объектов, а знаменатель - то, что требует предметная область.

Поскольку в выражении (2) и в числителе и в знаменателе фигурирует одно и то же множество объектов , значения критерия будут варьироваться в пределах от 0 до 1.

Почему мы обращаем на это внимание? Если, к примеру, задаться целью подсчитать значение этого критерия для тиражируемой типовой информационной платформы, то сначала придётся определиться с элементами множества . Что принять за основу? Множество объектов предметной области или множество объектов, «поддерживаемых» типовой информационной платформой. Маловероятно, что два этих множества окажутся равными. Может оказаться, что возможности информационной системы в этом плане окажутся шире, чем это требуется. Это равнозначно тому, что . Поэтому в выражении (2) все объекты, как и оцениваемые элементы должны, принадлежать множествам, формируемым предметной областью. Несмотря на кажущуюся простоту представленного здесь критерия и весьма грубые оценки полноты, которые могут быть получены, он (критерий) отражает наиболее значимые аспекты и факторы, которые должны приниматься в расчёт в процессе создания информационных систем, чтобы последние соответствовали современному уровню функциональных требований. В завершение рассматриваемого вопроса покажем, что осталось за рамками обсуждения.

7. Синхронизация моделей жизненного цикла объектов. Проблема конвертации.

Здесь речь пойдёт о «финансах», что, на первый взгляд, может показаться несколько странным, если ещё раз перечитать заголовок этого раздела.

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

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

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

Посмотрим, как работает конвертационный алгоритм (рисунок 10).



Рис. 10 - Механизм синхронизации и взаимной конвертации материального (товарно-материальные ценности - ТМЦ) и финансового (касса, расчётный счёт) объектов

Все поступающие на предприятие ТМЦ имеют стоимостную оценку, что автоматически приводит к порождению связи № 1 между МЖЦ ТМЦ и МЖЦ «кредиторской задолженности». В свою очередь реализация ТМЦ увеличивает кредиторскую задолженность (связь № 2). Последствия действия связей № 3 и № 4 столь же очевидны и не требуют специальных пояснений. Аналогичные «конвертационные» схемы могут быть построены для всех других объектов предметной области, попадающих под категорию базовых. Но этим не исчерпывается список возможных взаимодействий моделей жизненных циклов объектов.

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

Критерий полноты модели данных, введённый в предыдущем разделе, никаким образом не отражает ни элементы конвертации, ни элементы, участвующие в синхронизации динамики двух объектов - «материального - ТМЦ» и «нематериального (финансового)». Тем не менее сказанное не отрицает полезности использования этого критерия в процессе решения целого ряда задач, касающихся анализа, прогнозирования, развития и улучшения схем организации данных, в которых использование такого критерия видится вполне уместным.

В настоящей главе мы только упомянули о существовании проблемы даталогического представления конвертации и синхронизации МЖЦ объектов. Её изучение и подробное рассмотрение - предмет отдельной статьи.

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

На интуитивном уровне каждому, кто когда-либо создавал или создаёт сегодня базы данных понятно, что скрывается под полнотой. Это (возьмём на себя смелость сформулировать) способность информационной системы аккумулировать (накапливать, фиксировать) данные, отражающие многочисленные факты хозяйственной деятельности организации или, что точнее, состояния объектов управления и управляющие воздействия. Но, что тоже очевидно, оценить количественно полноту, не разработав предварительно строгую формальную основу, невозможно. Наш выбор в качестве такой формальной основы ограничился моделями жизненного цикла даталогических объектов. Подчеркнём - моделями жизненного цикла именно даталогических объектов, которые (модели), что видно уже из их названия, являются самостоятельным классом моделей. Другой исследователь может сформировать иную формальную основу, что предопределит все последующие результаты и выводы, отличные от полученных нами в настоящем исследовании. В нашем же случае оказалось, что оценивание полноты в основном сводится к выполнению набора стандартных процедур, обеспечивающих построение МЖЦ в двух вариантах: варианте требований к ним со стороны предметной области и в варианте уже реализованных возможностей информационной системы.

Хотелось бы обратить внимание на то, что МЖЦ «заточены» под специфику именно даталогических объектов. Все другие разновидности МЖЦ, используемые в ИС (проектирование, разработка программного кода и т.п.) малоприменимы в нашем случае. В этой связи, естественно, пришлось основательно проработать требования к таким моделям, их элементному и компонентному составам. Немаловажное значение было уделено и внешнему виду, который одновременно максимально облегчает понимание таких моделей и способствует правильной расстановке акцентов, выделяя наиболее значимые компоненты и связи.

Не составляет большего труда построить исчерпывающую МЖЦ какого-нибудь абстрактного объекта, которая бы отражала максимальный, предельный уровень требований как в части местоположения, так и действий (состояний) объекта. Такую модель можно было бы назвать, например, трафаретной, потому что, «накладывая» на неё МЖЦ уже реальных объектов, можно было мгновенно отследить, какие элементы реальных моделей выпали из рассмотрения. Само существование подобной универсальной модели (модели «на все случаи жизни») и является тем самым неожиданным выводом, о котором мы упомянули. Это означает наличие некоторого стандартного поведения у любых даталогических объектов, и в этом случае стандартной становится и сама технология даталогического моделирования, когда заранее известен конечный результат и последовательность шагов, направленных на получение этого результата.

Нужно ли в этом случае оценивать полноту моделей данных? Насколько актуальным представляется критерий полноты модели данных?

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

Литература

1. Родионов, А.Н. Моделирование данных: от сущностей к структурам данных. Сущности и объекты / А.Н. Родионов // Вестник ХГАЭП. 2010. № 1. С. 43 - 61.

Размещено на Allbest.ru

...