Дескрипторная компонента информационных систем САПР

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

Здесь уместно сделать уточнение относительно терминов «информационно-поисковая система (ИПС)», «информационно-справочная система (ИСС)» и «база данных».

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

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

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

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

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

Взаимодействие с такой моделью, как с информационно-поисковой системой (ИПС), имеет два процесса:

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

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

Выражая эти же положения в терминах современных реляционных СУБД, мы приходим к суждениям, что поле дескриптора - это домен, отдельный поисковый образ, соответствующий кортежу реквизитов - это запись таблицы или группа последовательно связанных отношением записей нескольких таблиц. Множество поисковых образов - это база данных. Процесс поиска при этом называют запросом (Query), а результат запроса – курсором или результирующим набором. При этом следует обратить внимание на то обстоятельство, что не всякая дескрипторная модель адекватно отображается в реляционную базу данных. Подходящие дескрипторные модели должны удовлетворять следующим ограничениям:

· поисковый образ каждого объекта представляется линейной последовательностью дескрипторов;

· из всего множества дескрипторов может быть выделена группа дескрипторов, присущая всем объектам. Если таких дескрипторов нет, они должны быть введены искусственно;

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

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

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

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

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

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

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

· обозначение (индекс) оснастки;

· наименование оснастки;

· обозначение детали, для обработки которой применяется данная оснастка;

· наименование детали, для обработки которой применяется данная оснастка;

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

· цех;

· участок;

· номер операции по технологическому процессу;

· вид технологического процесса;

· другие атрибуты, характеризующие текущее состояние процесса подготовки оснастки;

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

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

· объекта наблюдения (преобразуемой или изменяемой среды);

· воздействующего объекта (преобразующей, воздействующей или окружающей среды);

· входных воздействий;

· характера воздействия;

· выходного эффекта.

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

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

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

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

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

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

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

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

Выводы

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

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

· невозможность ее применения в случаях структурированных поисковых образов, которым относится большая часть объектов проектирования;

· статичность модели, модификация модели в режиме эксплуатации системы, если и допустима, то весьма неудобна.

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