Моделирование данных: от сущностей к структурам данных. Сущности и объекты

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

Моделирование данных: от сущностей к структурам данных. Сущности и объекты

Введение

даталогический алгоритм схема

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

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

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

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

- определиться с разновидности формальных типов структур, которые могут быть использованы в схеме организации данных;

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

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

1. Базовые объекты и кластеры даталогической модели

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

Сценарий этой предметной области, получивший условное название «Космонавтика», приводится ниже.

Пример сценарного описания процессов предметной области

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

К космическим аппаратам относят спутники, орбитальные станции, грузовые и пилотируемые корабли.

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

Кроме того, существуют носители (ракеты), с помощью которых космические аппараты доставляются в космос.

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

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

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

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

Рисунок 1 - Схема организации данных

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

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

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

Таблица 1 - Сущности, объекты и структуры даталогической модели

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

Рисунок 2 - Конструирование объектов с помощью абстракций обобщения

Рисунок 3 - Соответствия между типами объектов и типами сущностей

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

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

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

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

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

Формирование совокупности группировочных объектов всегда сопряжено с некоторой неопределённостью. Особенно это справедливо в отношении представления в модели данных иерархической системы классификации. Согласно наперед заданной иерархической структуре, исходное (базовое) множество сущностей распределяется между подмножествами, образующими начальный уровень. Далее, на следующих уровнях, происходит уже объединение подмножеств низлежащих уровней в более крупные подмножества. И так вплоть до формирования корневого узла. Упомянутая неопределённость связана с тем, что зачастую неизвестно конечное число классификационных уровней, которые будет присутствовать в предметной области в произвольные моменты времени (менеджеры имеют склонность периодически пересматривать используемые системы классификации сущностей, вводя новые системы, отзываясь от действующих или модифицируя последние). В последнем случае карта объектов (рисунок 4, подсхема 1) оказывается предпочтительнее, так как структура группировочного объекта позволяет поддерживать произвольное количество классификационных уровней за счет введения «петлевой» связи (такую конструкцию можно встретить в работе Мартина Дж. «Организация баз данных в вычислительных системах» (М.: Мир, 1977)).

Вновь обратимся к схеме конструирования объектов (рисунок 2).

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

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

2. Ассоциативные объекты

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

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

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

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

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

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

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

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

Исходя из технологических соображений, монтаж космической станции должен начинаться с установки головного модуля (<1>) (<1> - модуль идентифицирован цифрой 1).

Затем попарно должны собираться модули 2 и 3,а также 4 и 7. Далее к модулю 1 пристыковывается пара 2, 3, а потом пара 4, 7.

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

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

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

Для этого достаточно воспользоваться данными, включёнными в .

Рисунок 8 - Последовательность «сборки» агрегированного объекта

Рисунок 9 - Карта объектов с вариантным блоком порядка

Сказанным не охватываются все аспекты взаимодействия порядка, которые могут происходить между сущностями в предметных областях. Очень часто встречаются ситуации, когда для какого-то типа сущности может задаваться не один, заранее предопределённый порядок её агрегации/ декомпозиции, а несколько альтернативных по отношению к друг другу вариантов. В этом случае не обойтись без включения в модель данных ещё одной разновидности объектов - «вариантных объектов» и выделения в границах кластера специализированных кластерных блоков (один из таких блоков, объединяющий объект-тип и объект-знак, просматривается явно, поскольку «знаковый» объект не может существовать без «типового» объекта). Пример такого кластера, включающего вариантный объект, представлен на рисунке 9. Экземплярами «вариантного» объекта будут номера вариантов и, возможно, какие-то характеристики вариантов. Последнее, что осталось ещё нерассмотренным при моделировании взаимодействия состава, - вопросы представления «промежуточных» сущностей, которые на рисунке 8 были помечены как {<2, 3>}, {<4, 7>}, {<1>, <2, 3>}, {<1>,<2, 3>,<4, 7>}. Подобные сущности - это не что иное, как полуфабрикаты - промежуточные результаты, которые должны быть обязательно созданы в процессе получения готового продукта.

Они являются промежуточными по отношению к агрегированным объектам.

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

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

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

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

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

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

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

Карта объектов, представленная на рисунке 11, соответствует следующему сценарию: «Личность в организации работает одновременно в нескольких отделах и на нескольких должностях».

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

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

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

«Нормативную» и «фактическую» части при классификации информации по такому признаку, как функция управления, относят соответственно к нормативно-справочной и учётной информации.

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

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

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

- в итоговом (суммарном) виде. В этом случае применяется «усечённая» подсхема;

- только в индивидуальном (поштучном) варианте, что соответствует «стандартной» подсхеме;

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

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

Имеет смысл в дальнейшем именовать такой «складской» объект «слабой сущностью местоположения типа», в отличие от «слабой сущности местоположения знака», показанной на рисунке 10.

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

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

Завершённое представление обо всех аспектах моделирования взаимодействий может дать информация таблицы 2.

Таблица 2 - Взаимодействия между сущностями и аспекты их представления в моделях данных

Заключение

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

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

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

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

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

- определение исходного набора типов сущностей предметной области;

- разработка критериев качества даталогических схем, включая создание модели-основания;

- задание вида структур данных и механизма преобразования объектов в структуры.

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