Интеграция графической компоненты

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

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

• анализа;

• проектирования;

• синтеза управляющих программ;

• выпуска чертежей;

• управления промышленными роботами.

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

Объекты

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

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

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

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

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

Схемы подмножеств

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

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

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

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

Методы построения

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

1. Выбор объектов.

2. Выбор атрибутов для каждого типа объектов.

3. Выделение из набора атрибутов ключевых атрибутов.

4. Выбор отношений, связывающих объекты.

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

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

Для стандартизации процедур связи между различными САПР необходимо:

1) определить структуру языков;

2) зафиксировать форматы и способы формализации;

3) выработать перечень примитивов (объектов и операций), которые должны придерживаться как разработчики, так и пользователи САПР.

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