Пример реализации конструкторского банка данных

Рассмотрим теперь вопросы практической реализации конструкторского банка данных (Рис. 5.2).

Рис. 6.2 - Схема работы с банком конструкторских документов.

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

ГОСТ 2.101-68 устанавливает классификацию изделий по видам (Рис. 5.3). Такой же классификации следует придерживаться и в конструкторском банке данных. ГОСТ 2.201-80 устанавливает единую классификационную систему обозначения изделий основного и вспомогательного производства и их конструкторских документов для всех отраслей промышленности при разработке, изготовлении, эксплуатации и ремонте изделий. В соответствии с этим стандартом каждому изделию должно быть присвоено обозначение, которое является одновременно обозначением и его основного конструкторского документа (чертежа детали, спецификации).

Рис. 6.3 - Виды изделий

Конструкторская документация - это графическая и текстовая информация. Она хранится в файлах различных форматов, поддерживаемых графическими и текстовыми редакторами. Доступ к этим файлам осуществляется через банк данных, содержащий иерархически упорядоченный (в соответствии с ГОСТ 2.101-68) перечень документации на изделие.

Наиболее эффективно рассмотреть банк данных в терминах объектно-ориентированного подхода. Информация о составе изделия хранится в спецификациях по ГОСТ 2.108-68, следовательно, основным объектом конструкторской базы данных будет СПЕЦИФИКАЦИЯ (Рис. 5.4). Атрибуты А1.2 "Код группы-родителя" и А1.3 "Код группы-потомков" обеспечивают построение иерархической структуры каталога. Пунктам спецификации сопоставлен документ. Связь с объектом ДОКУМЕНТ осуществляется через атрибут А1.14 "Номер документа". Наименования разделов хранятся в отдельно - объект РАЗДЕЛЫ А2. Для организации журнала работы и разграничения доступа, введен объект ПОЛЬЗОВАТЕЛИ А3, содержащий информацию о пользователях системы. Справочник материалов представлен в виде отдельного объекта МАТЕРИАЛ А5.

Рис. 6.4 - Информационная модель банка конструкторских документов

Для разработки каталога используется активная реляционная БД. Операции работы с ней могут быть формализованы при помощи аппарата реляционной алгебры (см. приложение). Реляционная модель базы данных R может быть представлена в виде следующих отношений:

,

(1)

Для обеспечения информационной целостности данных на них наложены следующие ограничения:

1. Атрибут A_1.4 "Код раздела спецификации" отношения R₁ может принимать только значения, содержащиеся в проекции атрибута A_2.1 "Ключевое поле" отношения R₂ или, множество значений атрибута A_1.4 "Код раздела спецификации" отношения R₁ содержится или совпадает с проекцией атрибута A_2.1 "Ключевое поле" отношения R₂ .

.

(2)

A_1.14 "Номер документа" может принимать только значения атрибутов A_4.1 "Номер документа" отношения R₄ ДОКУМЕНТ:

.

(3)

Атрибут A_1.13 "Имя пользователя" может принимать только значения атрибутов A_3.1 "Ключевое поле" отношения R₃ ПОЛЬЗОВАТЕЛИ:

.

(4)

Атрибут A_4.10 "Материал" отношения R₄ может принимать только значения, содержащиеся в проекции атрибута A_5.1 "Ключевое поле" отношения R₅ МАТЕРИАЛ:

.

(5)

Данные ограничения поддерживаются активной БД. Любое действие, направленное на их нарушение, будет отменено.

Для получения информации об изделиях первой группы необходимо произвести выборку

,

(6)

где А_1.2 - "Код группы-родителя".

Для определения следующего уровня по отношению к текущему или вхождения в сборку необходимо над отношением r1 провести выборку по условию:

,

(7)

где N - значение атрибута A_1.3 "Код группы-потомков" текущего уровня.

Упорядочивание производится по атрибутам: "Код группы-родителя" А_1.2, "Код раздела спецификации" А_1.4 и "Позиция" А_1.7, что соответствует стандартным требованиям.

У одной группы может быть несколько родителей (Рис. 5.5). Это позволяет при заимствовании сборочного чертежа не набирать заново всю сборку, а лишь указать обозначение сборочного чертежа.

Рассмотрим операции над БД, производимые при выполнении конструктором ряда повседневных задач. При заполнении спецификации конструктор заносит в банк документов формат документа, наименование, позицию и количество деталей в сборке. Далее, банк данных выполняет ряд операций, ранее проводимые конструктором:

1. Проверяет отсутствие в данном разделе детали с таким же обозначением:

2. Выясняет, свободна ли данная позиция. Если условие не выполняется, то необходимо раздвинуть позиции:

3. Проверяет, есть ли в БД данная деталь или сборка с таким обозначением. Если деталь или сборка найдена (|T|>0), то нужно запомнить значения соответствующих атрибутов.

4. Собственно добавляет позицию в спецификацию.

Рис. 6.5 - Дерево каталога конструкторских документов.

Аналогичные проверки проводятся и при редактировании пункта спецификации.

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

Рис. 6.6 - Затраты труда на ведение архива:

а) при ручном ведении архива; б) при внедрении электронного архива

Внедрение такого архива приводит к повышению производительности труда конструкторов на 35..40%.