Компонента структурных объектов информационных систем САПР

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

Компонента структурных объектов, с одной стороны, предоставляет среду для моделирования информационных объектов САПР, которые не могут быть эффективно реализованы ни посредством дескрипторной ни посредством классификационной компоненты, а с другой позволяет манипулировать знаниями в форме информационно-логических таблиц и различных сетей вывода. Она может быть представлена посредством логической схемы базы данных, изображённой на рис. 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

IndexesIndexes

ObjCode ValueCode

ObjDescrValueC

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. Логическая схема компоненты структурных объектов информационных систем САПР

 

 

Поле “Идентификатор типа” TypeCode является внешним ключом по отношению к одноименному полю таблицы типов и однозначно определяет тип структуры объекта. Значение этого поля может выполнять роль имени таблицы в реляционной модели.

Поле “Идентификатор атрибута” AttCode является внешним ключом по отношению к одноименному полю таблицы атрибутов. Может выполнять роль имени поля таблицы в реляционной модели.

Поле “Идентификатор значения” ValueCode содержит ключ записи соответствующего домена, содержащего данное значение, причём первая часть кода идентифицирует сам домен.

Поле “Идентификатор предиката” PredCode содержит ключ записи таблицы предикатов, идентифицирующий значение последнего.

Поле “Фактор повторения” RepF содержит символьное представление числа последовательных повторений имени или значения атрибута.

Для файла фактов FKT создаются следующие индексы (теги) (Табл. 9):

Таблица 9

Имя индекса (тега)	Индексное Выражение	Тип индекса	Примечание
DataElem	Objcode+ typecode +elcode+attcode	Primary	Главный индекс, обеспечивающий уникальность каждого элемента данных
ObjTyAtt	Objcode+typecode+attcode	Regular	Вторичный индекс, обеспечивающий группирование значений заданного атрибута в рамках одного объекта определённого типа
ValueCode	Valuecode	Regular	Вторичный индекс, обеспечивающий группирование данных с одинаковыми значениями атрибутов и прямой доступ к последним

Каждая запись таблицы фактов служит полным описанием некоторого факта в виде набора соответствующих указателей: ”Значение соответствующего домена, определяемое ключом ValueCode является значением атрибута, определяемого ключом AttCode, в составе объекта или элемента ElCode, имеющего тип, определяемый ключом TypeCode в составе контейнера или объекта, определяемого ключом ObjCode, причём между именем атрибута и его значением существует отношение, определяемое ключом PredCode и значение повторяется последовательно в контексте RepF раз”. С другой стороны, её можно рассматривать как представление данного с полной интерпретацией в текущем контексте. Повторяющееся значение в поле ObjCode определяет всю группу значений признаков, относящихся к одному объекту. Повторяющееся значение в поле TypeCode определяет все наборы данных одного структурного типа. Значение поля AttCode, одной стороны, позволяет проинтерпретировать любое данное, а, с другой стороны, – выделить (сгруппировать) значения, характеризующие определённое свойство, присущее различным типам структурных объектов. Совместное задание ObjCode, TypeCode, AttCode позволяет выделить набор значений одноимённого свойства всех экземпляров определённого элемента в составе заданного объекта, например, все диаметры наружных цилиндрических поверхностей обрабатываемой детали.

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

Известно, что некоторый объект можно идентифицировать в результате классификации по определённому набору признаков (рис. 29). Множество данных, представляющих значения признаков классификации в определённом аспекте и присущие определённому объекту, выделяются путем задания аспекта классификации (TypeCode) и имени объекта (ObjCode). Каждое данное в этой группе интерпретируется посредством AttCode.

 

Имя объекта

Имя аспекта классификации К1

Имя признака К11 Ссылка на значение Значение признака К11

Имя признака К12 Ссылка на значение Значение признака К12

 

.........................................................

 

Имя признака К1N Ссылка на значение Значение признака К1N

 

Имя аспекта классификации К2

Имя признака К21 Ссылка на значение Значение признака К21

Имя признака К22 Ссылка на значение Значение признака К22

 

.........................................................

 

Имя признака К2N Ссылка на значение Значение признака К2N

и т.д.

 

Рис. 29. Классификационная интерпретация структурной компоненты

Поле ElCode (идентификатор элемента) для классификаций не заполняется. Его заполняют для представлений структурных объектов и интерпретируют как номер структурного элемента.

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

 

Имя объекта

Имя типа элемента Е1

Элемент i

Имя признака Е11 Ссылка Значение признака Е11i

Имя признака Е12 Ссылка Значение признака Е12i

 

.........................................................

 

Имя признака Е1N Ссылка Значение признака Е1Ni

 

Элемент j

Имя признака Е11 Ссылка Значение признака Е11j

Имя признака Е12 Ссылка Значение признака Е12j

 

.........................................................

 

Имя признака Е1N Ссылка Значение признака Е1Nj

 

и т.д.

 

Имя типа элемента Е2

Элемент k

Имя признака Е21 Ссылка Значение признака Е21k

Имя признака Е22 Ссылка Значение признака Е22k

 

.........................................................

 

Имя признака Е2N Ссылка Значение признака Е2Nk

 

Элемент m

Имя признака Е11 Ссылка Значение признака Е11m

Имя признака Е12 Ссылка Значение признака Е12m

 

.........................................................

 

Имя признака Е1N Ссылка Значение признака Е1Nm

 

и т.д.

Рис. 30. Объектная интерпретация компоненты структурных объектов

На рис. 31 и 32 приводятся два состояния интерфейса ввода структурированных данных. В качества структуры данных взята таблица выбора подач (табл. 10) Интерфейс содержит четыре объекта типа GRIG (таблица), один комбобокс и командные кнопки.

 

Таблица 10

Характер Обрабатываемый Модуль в Подача в

обработки материал

По сплошному Сталь 45 0.25 - 0.3

металлу Чугун 2 - 3 0.3 - 0.35

По обраб. Сталь 45 0.22 - 0.25

зубу Чугун 4 -8 0.35

 

В верхнюю левую таблицу “Имя типа” вводяттся наименования типов структур данных, в частности, -- здесь виден тип “Подачи при обработке на зубодолбёжных станках”. Эта таблица выводит на экран содержимое поля TypeName файла Ftype.dbf. В левую нижнюю таблицу “Имя объекта” вводятся имена объектов (экземпляров типа). В случае ИЛТ объект может совпадать с типом.

Таблица “Имя атрибута” представляет собой интерфейс файла AttDict.dbf и в данном случае показывает состав атрибутов типа “Подачи …”. Если бы был выбран другой тип структуры в таблице типов, то был бы выведен и другой состав атрибутов. Любое редактирование данных в таблице “Имя атрибута” (изменение существующих, удаление или введение новых атрибутов) будет относится к активному типу.

Правая таблица “Значение атрибута” представляет собой интерфейс файла ValueC и показывает на Рис. 31 состав всех значений атрибута “Характер обработки”, а на Рис. 32 – состав всех значений атрибута “Подача”.

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

Кнопки “Добавить”, “Удалить” действуют на активную таблицу, обеспечивая добавление новых или удаление существующих записей.

 

Рис. 31. Интерфейс компоненты ввода структурированных данных

Таким образом, на экране всегда видна следующая информация:

· тип структуры;

· текущий объект, содержащий выбранный тип;

· текущий элемент выбранного типа;

· полный состав атрибутов типа (элемента или всего объекта);

· полный состав значений активного (выбранного) атрибута;

· текущее атрибутивное отношение.

Поле “Номер элемента” обеспечивает идентификацию элементов в структуре объекта.

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

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

 

 

Рис 33. Интерфейс компоненты ввода структурированных данных.

Придание структуры введённым таким образом данным осуществляется путём ввода номеров строк.

Рассмотренный интерфейс имеет три достоинства и один недостаток:

· достоинства:

§ предельная простота реализации в любой современной системе программирования;

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

§ предельная экономичность действий. Любое повторяющееся данное вводится лишь один раз.

· недостаток – не традиционность. Непривычная форма представления знакомых структур данных может вызывать определённое неприятие конечного пользователя.

Выводы

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