Компонента структурных объектов проектной среды принятия решений в сапр. Общее понятие о методах реализации структурной компоненты в информационных системах сапр.
Итак, даже краткое изложение особенностей информационной среды проектирования позволяет сделать вывод о том, что, если попытаться организовать работу с такими данными на основе классической реляционной модели данных, то такой путь окажется неэффективным по причине очень большого числа таблиц, малого числа записей в каждой таблице и сложного механизма выделения собственно объекта, составляющие элементы которого разбросаны по множеству таблиц.
Компонента структурных объектов, с одной стороны, предоставляет среду для моделирования информационных объектов САПР, которые не могут быть эффективно реализованы ни посредством дескрипторной ни посредством классификационной компоненты, а с другой позволяет манипулировать знаниями в форме информационно-логических таблиц и различных сетей вывода. Она может быть представлена посредством логической схемы базы данных, изображённой на рис. 28.
Предполагается, что база данных отображает определённую предметную область, состоящую из перечислимого множества объектов, причём объекты могут быть простыми (неделимыми) объектами или объектами – контейнерами, содержащими в себе другие объекты. Выполним построение базы данных посредством следующих шагов.
Присвоим каждому объекту уникальный идентификатор ObjCode, выполняющий роль системного имени, а также содержательное имя ObjDescr, с которым будет оперировать конечный пользователь. Занесём эти данные с таблицу ObjTbl – таблицу объектов и определим в качестве первичного ключа поле ObjCode, а на поле ObjDescr наложим ограничение Unique.
Каждый объект этой предметной области характеризуется определённым набором атрибутов, выделенным исходя из целей и задач, в которых участвует данный объект. Разобьем все объекты на типы по признаку общности состава атрибутов, характеризующих эти объекты. Присвоим каждому типу уникальный идентификатор TypeCode, который будет служить системным именем, и неформальное имя для конечного пользователя TypeDescr, а также необязательное условное обозначение TypeSymbol. Занесём эти данные в таблицу типов TypeTbl и создадим первичный индекс по полю TypeCode, а ограничение Unique или индекс Candidate – по полю TypeDescr.
Каждый атрибут характеризуется именем, содержанием (семантикой или приписываемым ему смыслом), независимым от типов объектов, которые он характеризует, а также типом значений: числовым, символьным и т.п. Область допустимых значений может зависеть от типа объектов или, даже, быть специфической для конкретного объекта. Присвоим каждому атрибуту с определённой (фиксированной для данной предметной области) семантикой уникальный идентификатор в качестве системного имени AttCode, неформальное имя для конечного пользователя AttDescr, необязательное условное обозначение AttSymbol и указание базового типа значений – символьный, числовой и т.п. Занесём эти данные в таблицу атрибутов AtTbl. Добавим в неё ещё одно поле логического типа, значение TRUE которого говорит о наличии специального домена, в противном случае – атрибут принимает свои значения из общего домена базового типа.
Отношение между именем атрибута и его значениями не всегда является равенством для информационных объектов САПР. Во многих случаях ими могут служить такие предикаты, как “находится в интервале”, “следовать за или предшествовать”, “находиться в отношении наложения” (например, для обрабатываемых поверхностей) и т.п. Поэтому введём в наша базу данных таблицу PredList с двумя полями PredCode и PrdDescr. Первое из полей будет содержать системное имя предиката, а второе – его общепринятое обозначение.
Создадим таблицу ValueC, представляющую домен базового символьного типа значений, с полями ValueCode и ValueC. Первое из них будет содержать системное имя, а второе - собственно символьное значение. Символьные значения могут быть переменной длины и представлять сложные лексемы. Построим два индекса: первичный по полю ValueCode и индекс типа Unique или Candidate по полю ValueC.
Создадим аналогичную таблицу для числовых значений ValueN с полями ValueCode и ValueN с теми же ролями, что и в предыдущем случае. Построим также соответствующие индексы по этим полям.
По примеру доменов базовых типов, может быть создано произвольное число доменов для специальных пользовательских типов. Имена таких доменов заносятся в специальную таблицу DomainList, содержащую поле DCode, представляющее системное имя домена; поле DNameTable, содержащее имя таблицы, передставляющей соответствующий домен, а также поле DDescr, содержащее описание домена.
Наконец, создадим последнюю таблицу в схеме нашей базы данных - таблицу фактов Fact следующей структуры:
Field_name Field_type Field_len Field_dec Remarks
ObjCode C 2 Идентификатор объекта
ElCode C 2 Символьный код порядкового номера объекта с составе объекта-контейнера
TypeCode C 2 Идентификатор типа
AttCode C 2 Идентификатор атрибута
ValueCode С 4 Идентификатор значения
PredCode C 1 Идентификатор предиката
RepF C 1 Число последовательных повторений значения в объекте
Поле “Идентификатор объекта” ObjCode является внешним ключом по отношению к одноименному полю файла объектов и однозначно идентифицирует объект.
Поле “Идентификатор элемента” ElCode содержит символьный код номера элемента (экземпляра типа элемента) в составе объекта - контейнера, хотя может применяться и любая другая уникальная в пределах одного объекта идентификация. Значение этого поля может выполнять роль физического номера строки таблицы в реляционной модели. Символьное представление нулевого значения соответствует атрибутам, характеризующих объект как единое целое.
ObjTbl – Таблица объектов ValueC – Домен символьных значений
Fields Fields
ObjCode ValueCode
ObjDescr ValueC
Indexes Indexes
ObjCode ValueCode
ObjDescr ValueC
AtTbl – Таблица атрибутов
Fields Fact – Таблица фактов
AttCode
AttDescr Fields ValueN – Домен числовых значений
AttSymbol ObjCode
AttType ElCode Fields
Domain AttCode ValueCode
Indexes TypeCode ValueN
Attcode DomainCode Indexes
Attdescr ValueCode ValueCode
PredCode ValueC
TypeTbl – Таблица типов Kratn
Indexes
Fields Objcode
TypeCode Typecode
TypeDescr Attcode
TypeSymbol Valuecode
Indexes DataElem
Typecode
Typedescr
DomainList – список доменов PredList - список предикатов
Fields Fields
DCode PredCode
DNameTable PredDescr
DDescr Indexes
Indexes PredDescr
Dcode
Рис. 28. Логическая схема компоненты структурных объектов информационных систем САПР
Выводы
Расмотренная в настоящем разделе модель представления объектов САПР удобно реализуется средствами реляционной модели и в тоже время позволяет оперировать семантикой объектов САПР любой сложности: моделями обрабатываемых деталей, методами обработки, типами и группами деталей, различными классификаторами, информационно-логическими таблицами и т.п. объектами.