КАТЕГОРИИ: Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748) |
Список использованных источников. Рис. 28. Логическая схема компоненты структурных объектов информационных систем САПР
Dcode
Рис. 28. Логическая схема компоненты структурных объектов информационных систем САПР
Поле “Идентификатор типа” TypeCode является внешним ключом по отношению к одноименному полю таблицы типов и однозначно определяет тип структуры объекта. Значение этого поля может выполнять роль имени таблицы в реляционной модели. Поле “Идентификатор атрибута” AttCode является внешним ключом по отношению к одноименному полю таблицы атрибутов. Может выполнять роль имени поля таблицы в реляционной модели. Поле “Идентификатор значения” ValueCode содержит ключ записи соответствующего домена, содержащего данное значение, причём первая часть кода идентифицирует сам домен. Поле “Идентификатор предиката” PredCode содержит ключ записи таблицы предикатов, идентифицирующий значение последнего. Поле “Фактор повторения” RepF содержит символьное представление числа последовательных повторений имени или значения атрибута. Для файла фактов FKT создаются следующие индексы (теги) (Табл. 9): Таблица 9
Каждая запись таблицы фактов служит полным описанием некоторого факта в виде набора соответствующих указателей: ”Значение соответствующего домена, определяемое ключом 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), то можно видеть, что этот интерфейс обеспечивает ввод данных таблицы по графам не обращая внимания на их взаимное расположение в строках.
Придание структуры введённым таким образом данным осуществляется путём ввода номеров строк. Рассмотренный интерфейс имеет три достоинства и один недостаток: · достоинства: § предельная простота реализации в любой современной системе программирования; § абсолютная универсальность. Можно ввести информационно-логическую таблицу любой сложности или информационную модель произвольного объекта (физико-технического эффекта, детали, схемы установки детали в приспособлении и т.п.); § предельная экономичность действий. Любое повторяющееся данное вводится лишь один раз. · недостаток – не традиционность. Непривычная форма представления знакомых структур данных может вызывать определённое неприятие конечного пользователя. Выводы Расмотренная в настоящем разделе модель представления объектов САПР удобно реализуется средствами реляционной модели и в тоже время позволяет оперировать семантикой объектов САПР любой сложности: моделями обрабатываемых деталей, методами обработки, типами и группами деталей, различными классификаторами, информационно-логическими таблицами и т.п. объектами. 1. Исследование системных закономерностей и методов синтеза технических принципов действия на основе интеллектуальной базы данных и знаний по физико-техническим эффектам. ГБ НИР 97-96, № г.р. 1997993; 2. Foundations of knowledge base management: Contributionsfrom logic, database and AI applications/Ed. J.W. Schmidt, C. Thanos. Pisa, 1986/482 p. 3. Д.А. Поспелов. В сб. Экспертные системы: состояние и перспективы. Москва, «Наука» 1989 г. 4. А. И. Змитрович. Базы данных. Минск, Университетское. 1991г. 5. Д. Марселлус. Программирование экспертных систем на Турбо Прологе. Москва. «Финансы и статистика». 1994 г. 6. Excalibur Tecnologies предлагает средства извлечения знаний. ComputerWeek-Moscow №45 1996. 7. Н. Кречетов, П. Иванов. Продукты для интеллектуального анализа данных. ComputerWeek-Moscow №14-15 1997. 8. Data mining the search for knowledge in databases./Hoisheimer Marcel. Siebes Arno//Rapp./Cen. Wisk. en inf. – 1994.-NC5-R9406.-p.1—78. 9. Кочуров В.А. Некоторые инвариантные компоненты программной реализации информационных технологий технической подготовки производства. Материалы международной конференции по искусственному интеллекту. Минск. 1995. 10. Кочуров В.А. О способе представления знаний средствами реляционных СУБД. Материалы международной конференции БГПА. Минск. 1996. 11. Разработка структуры и алгоритмов функционирования компьютерной базы данных и знаний по технологической оснастке. ГБ НИР 94-58, № г.р. 19942950; 12. Разработка интеллектуальной системы построения физико-технических принципов действия новых машин и приборов. ГБ НИР 96-45, № г.р. 1996887; 13. Исследование и разработка инвариантных компонентов и архитектуры интеллектуальных систем автоматизированного проектирования. ГБ НИР 98-24, № г.р. 19981594; 14. Исследование и разработка информационной технологии интеллектуального анализа Конструкторско-Технологических Данных (КТД ). Шифр ГБ 00-68, № г.р. 20001470.
Дата добавления: 2015-04-25; Просмотров: 350; Нарушение авторских прав?; Мы поможем в написании вашей работы! Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет |