"Мигрирующие" объекты моделей данных: "слабые сущности" и документы

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

УДК 004.4

«Мигрирующие» объекты моделей данных: «слабые сущности» и документы

Актуальные проблемы информатики

А.Н. Родионов,

д-р техн. наук, завкафедрой информационных систем в экономике

Хабаровской государственной академии экономики и права

Interactions between types of domain essences entailing the formation of «data crossing» can be reflected in a data model in two ways: either by using documentary structures or by using such abstractional objects as «weak essences». The objective mutual replacement of the mentioned above categories provokes the necessity of formulating and solving a great number of new tasks: indication of a specialized class of structures for documents' reflection; division of documents into functional zones; development of formal rules of structuring data of these zones as an integral part of a document, in particular, and a data model, on the whole; development of algorithms of direct and back data transmission between «weak essences» and documentary structures with full saving as data themselves as their semantics; determination of a set of conditions and expediency of simultaneous presence of combinations «weak essences - documentary cluster» in data models.

Keywords: weak essences, documentary structures and documentary cluster, structural document scheme, attributes of primary and foreign keys, implicit connection, rules of structures' generalization.

Введение

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

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

Если, например, схематически представить это отражение, то оно будет выглядеть приблизительно так, как это показано на рисунке 1.

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

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

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

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

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

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

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

В шестом разделе рассматриваются вопросы сохранности данных в процессе перемещения последних между «слабыми сущностями» и документальными структурами.

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

1. О взаимозаменяемости «слабых сущностей» в информационных системах и моделях данных информационных систем

Если задаться вопросом о том, что является источником данных для баз данных информационных систем, то ответ будет однозначным: это структурированные документы. (Интересна информация, которая приводится в [2] о количестве документов, циркулирующих на среднем машиностроительном предприятии. Общее число разновидностей документов составляет 1224 единицы.) Только на основании информации, размещённой в документах, можно составить чёткое представление о том, какие сущности присутствуют в предметной области, каким образом эти сущности взаимодействуют между собой и что является результатом этого взаимодействия. Справедливости ради стоит сказать, что документы являются не единственными источниками информации. Есть ещё и многочисленные положения, инструкции и многие другие нормативные и ненормативные акты, которые, как и документы, «обеспечивают» управление предприятием. В идеале описание предметной области должно включать описание её деловых процессов, но и в данном случае без документов не обойтись, поскольку процессы могут быть формально описаны только посредством документов и действий, выполняемых с этими документами. Таким образом, значимость документа как «источника» информации в управлении абсолютна.

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

Рассмотрим с позиций источника данных документ, обладающий простой структурой, - «экзаменационную ведомость» (рисунок 2).

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

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

«Номер билета» = («Дисциплина», «Дата», «Экзаменатор», «Студент»);

«Оценка» = («Дисциплина», «Дата», «Экзаменатор», «Студент»).

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

«Данные пересечения» можно разместить в базе данных и альтернативным способом, воспользовавшись «документальными структурами» (рисунок 4).

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



Рисунок 4 - Пример «документального способа» представления в моделях «данных пересечения»

Данные пересечения здесь атрибуты «Nomer_bil» и «Id_mrk» структуры «Ved_tabl».

Какое из двух представлений следует предпочесть, если они оба альтернативные? Если подходить с позиции полноты отражения данных, то это, бесспорно, документальное представление, так как оно обеспечивает максимальный, 100 %-ный уровень полноты. «Слабая сущность» (рисунок 3) явно уступает в части полноты документу, но ведь ничего не мешает включить в её состав атрибуты «Номер ведомости (Nomer)», «Декан (Id_prs_dean)» и другие, расширив за их счёт состав составного первичного ключа. Однако при этом придётся смириться с тем, что возрастёт уровень избыточности данных, поскольку значения этих атрибутов будут повторяться ровно столько раз, сколько записей будет содержаться в таблице «Результаты сдачи». Понятно, что критерии полноты и избыточности здесь малоприменимы хотя бы потому, что практика включения и документов и «слабых сущностей» в состав моделей данных достаточно распространена. (Упомянутые в работе критерии рассматриваются не в формальном, а, скорее, в смысловом интуитивном плане. О качестве моделей данных можно судить, только опираясь на значения, которые принимают соответствующие критерии. К сожалению, таковых сегодня просто не существует, что делает крайне актуальными исследования, направленные на их разработку и обоснование.)

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

2. Основы структуризации документов: алгоритмы и структуры

модель слабый сущность даталогический

В работе [4] были введены пять классов структур, посредством которых в моделях данных могут быть представлены все классы базовых даталогических объектов: объекты-типы, объекты-знаки, объекты-группировки и «слабые сущности». Очевидно, что в отношении документов мы имеем дело с другим классом объектов и другими классами структур. Последнее хорошо просматривается при внимательном рассмотрении состава и взаимодействия таблиц «Ved_zagolovok» и «Ved_tabl», показанных на рисунке 4. В связи с этим возникает задача задания соответствующих специализированных структур и разработки правил (алгоритмов) структуризации документов (структуризация документа - процедура задания набора табличных структур и закрепление реквизитов документа за этими структурами).

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

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

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

2. Несколько сложнее определить реквизиты, являющиеся свойствами сущностей и сформировать объекты (если они не были сформированы заранее), представляющие эти сущности в модели данных. Снова обратимся к рисунку 4, из которого хорошо видно, что вместо атрибутов, соответствующих свойствам сущностей, в таблицах «Ved_zagolovok» и «Ved_tabl» задействованы идентификаторы этих сущностей - первичные простые суррогатные ключи. Идентификаторы позволяют не только компактно (экономно) представить свойства сущностей, но и выполняют роль своеобразных ссылок на эти сущности. По этим ссылкам можно легко отыскать все необходимые свойства сущностей, включая, что особенно важно, и названия отдельных экземпляров сущностей. Более того, подобная «ссылочная» организация данных позволяет исключать дублирование данных в базе данных.

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

4. После выполнения всех вышеперечисленных действий можно приступать к формированию состава заголовочной и содержательной структур документа. Заметим, что присутствие в составе документа заголовочной структуры является обязательным. Нетрудно догадаться, что одному документу в экземпляре заголовочной структуры соответствует одна-единственная запись.

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

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

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

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

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

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

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

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

«Преподаватель может вести несколько дисциплин. Одна и та же дисциплина может читаться несколькими преподавателями».

Эта ситуация описывается следующей функциональной зависимостью:

.

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

; , где:

- - множество атрибутов простого первичного ключа (simple key), ;

- - множество содержательных (информационных) атрибутов;

- - множество внешних ключевых атрибутов.

; , где:

- - множество атрибутов составного первичного ключ (compound key).

- - множество атрибутов, соответствующих «данным пересечения».

Запишем также правило наследование простого первичного ключа: .

3. Структурная схема документа

Документальный кластер может включать несколько содержательных частей и далеко не во всех случаях какая-то из содержательных частей оказывается «напрямую» увязанной с заголовочной частью.

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

Для иллюстрации сказанного проведём анализ атрибутного состава ещё одного документа - «Приказ на отчисление студентов» (рисунок 6).

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

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

В настоящей работе мы не ставили перед собой цель рассмотреть этот аспект проектирования информационных систем и поэтому предлагаем читателю принять «на веру» корректность представленных нами ДП и их ФЗ).

.

- множества наследуемых атрибутов.

.

.

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

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

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

Таким образом, правило вывода содержательных структур дополним следующим пунктом.

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

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

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

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



Рисунок 8 - Подсхема модели данных документа «Приказ на отчисление»

Иерархическая организация диктует необходимость выработки определённых правил, в соответствии с которыми формируются ключевые атрибуты табличных структур. По аналогии с формальным описанием структурных классов, сделанным в [4], выполним описание структур, которые будут использоваться для даталогического моделирования документов.

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

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

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

3. Связи 1:М между заголовочной структурой и промежуточными табличными структурами, а также между промежуточными табличными структурами поддерживаются посредством включения в состав подчинённой структуры атрибута внешнего ключа, наследующего первичный суррогатный ключ родительской таблицы.

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

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

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

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

Таким образом, к структурной паре добавляется новый структурный тип .

; .

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

4. «Нормативная часть» документа и её представление в модели данных

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

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

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

Стандартный минимальный вариант подобного наследования демонстрируется на рисунке 11.

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

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

5. Моделирование результатных документов

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

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

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

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

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

Рисунок 12 - Таблица нерегулярной структуры для хранения изменённых (устаревших) записей документов

Имя таблицы	Имя атрибута	Дата-время	Идентификатор персонала	Значения
				integer	character	real	……

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

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

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

6. Процедура миграции (замещения) данных

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

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

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

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

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

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

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

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

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

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

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

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

7. Комбинация «слабая сущность - документальный кластер» в моделировании текущих взаимодействий сущностей

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

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

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

Соответственно и время на поиск необходимых данных также будет стремиться к минимуму, поскольку все «нужные» данные уже «лежат» в таблице «Нормы расхода материалов».

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

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

Заключение

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

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

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

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

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

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

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

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

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

Литература

1. Государственный стандарт РФ ГОСТ Р 51141-98. «Делопроизводство и архивное дело. Термины и опредления».

2. Меньков, А. В. Теоретические основы автоматизированного управления / А. В. Меньков, В. А. Острейковский. - М. : Оникс, 2005.

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

4. Родионов, А. Н. Моделирование данных : от сущностей к структурам данных. Структуры концептуальной модели / А. Н. Родионов // Вестник ХГАЭП. 2010. № 6. С. 49. - 67.

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

...