Использование реляционной базы данных  в качестве информационного ядра
интегрированной САПР электроавтоматики

А.Н.Липатов,
ведущий инженер-программист
г. Снежинск

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

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

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

Предпосылки для использования реляционной
модели данных в схемно-конструкторском проектировании

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

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

-      интегрированную среду разработки приложений с удобными инструментами для создания таблиц, форм, запросов и отчетов;

-      поддержку международного стандарта языка баз данных SQL, позволяющего работать с данными на уровне множеств;

-      возможность разработки программ на объектно-ориентированном языке Visual Basic для приложений (VBA).

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

Инвариантная часть ИМ предметной области

Рассмотрим обобщенный процесс автоматизированного конструкторского проектирования, происходящий в рамках ЕСКД. Опишем ту часть информационной модели предметной области, которая не зависит от типа проектируемого изделия и номенклатуры выпускаемой конструкторской документации. Для этого нам понадобятся всего три базовые сущности: СоставнаяЧасть, Документ и Приложение. Диаграмма IDEF1X, характеризующая эти сущности и показывающая отношения между ними, представлена на Рис. 1. Условимся называть проектом изделия (или просто проектом) информацию о разрабатываемом изделии, представленную формализованными данными о составе и структуре изделия в таблицах БД проекта и связанными с ними файлами электронной конструкторской документации (ЭКД).

Сущность СоставнаяЧасть идентифицирует изделие в проекте и хранит атрибуты, необходимые для формирования иерархии состава и получения спецификации по ЕСКД. Это может быть головное изделие проекта, либо одна из его проектируемых составных частей, либо стандартное изделие, которое используется при проектировании. Каждый экземпляр сущности СоставнаяЧасть имеет уникальное обозначение или уникальное наименование, признак принадлежности определенному разделу спецификации, код-ссылку на родительскую составную часть (основу рекурсивного отношения входит в состав). В базе данных проекта сущность СоставнаяЧасть реализуется как таблица состава и является основным хранилищем информации и сердцевиной взаимосвязей внутри проекта.

Рис. 1: Базовые сущности и отношения предметной области конструкторского проектирования

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

Сущность Приложение идентифицирует программу, выполняющую определенные функции проектирования, как правило, в диалоге с конструктором и, как правило, предназначенную для формирования определенного конструкторского документа. Это может быть подсистема автоматизированного проектирования общего назначения (ProEngineer, AutoCAD, PCAD), либо специального назначения ("Э6", "Э3", "Жгут СА"). Сущность Приложение является элементом интегрированной среды проектирования, в отличие от сущностей СоставнаяЧасть и Документ, экземпляры которых принадлежат конкретному проекту.

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

Вклад схемы Э6 в общую модель данных

Схема электрическая общая изделия (Э6) содержит информацию о трех типах объектов: Прибор, Жгут и Соединитель. При этом соединители принадлежат приборам или жгутам, а те, в свою очередь, входят в состав изделия. Помимо всеобщего отношения входит в состав, схема Э6 содержит характерный именно для нее тип отношения: разъемное соединение. В разъемном соединении участвуют ровно два соединителя: вилка и розетка. За счет вклада, внесенного схемой Э6, первоначальная модель данных может быть расширена до модели, представленной на Рис. 2.

3

Рис. 2: Вклад схемы Э6 в общую модель данных

Представленную диаграмму можно трактовать следующим образом. При автоматизированном создании Э6 (с помощью приложения «СхемныйРедакторЭ6») одновременно с графическим файлом, содержащим изображение документа в его традиционном виде, в БД проекта формируется ряд связанных таблиц с информационной “вытяжкой” из этого файла. Составные части, находящие отражение на схеме Э6, – это суть Прибор, Жгут и Соединитель, которые в БД проекта реализованы как соответствующие таблицы, подчиненные таблице состава. Отношение разъемного соединения моделируется с помощью ассоциативной сущности РазъемноеСоединение, которая в БД проекта реализована в виде таблицы, содержащей парные коды связанных соединителей.

Следует отметить, что сущность СоставнаяЧасть дополнилась двумя новыми атрибутами: ПО и маркировка, которые являются отличительными признаками составных частей в электрических схемах:

Вклад схемы Э3 в общую модель данных

Схема электрическая принципиальная (Э3) определяет полный состав элементов и электрические связи между ними и дает детальное представление о принципах работы изделия. С точки зрения информационного моделирования важным является то, что схема Э3 формирует новый тип отношений между СЧ: объединение контактов СЧ по признаку равного потенциала. Вклад, вносимый схемой Э3 в общую модель данных, представлен в виде диаграммы на Рис. 3.

2

Рис. 3: Вклад схемы Э3 в общую модель данных

Составные части СА, находящие отражение на схеме Э3, – это суть Прибор, ЭРИ и Соединитель, которые в модели данных представлены как подсущности суперсущности СоставнаяЧасть, а в БД проекта реализованы как соответствующие таблицы, подчиненные таблице состава. Отношение равного потенциала моделируется с помощью ассоциативной связи между сущностями Контакт и Цепь. В БД проекта им будут соответствовать таблица контактов и таблица цепей. Каждый контакт из таблицы контактов, с одной стороны, принадлежит некоторой СЧ из таблицы состава, с другой – связан с некоторой электрической цепью.

Вклад схемы Э4 в общую модель данных

Схема электрическая соединений (Э4) содержит все устройства и элементы, входящие в состав изделия, а также соединения между ними в виде проводов и жгутов. Схема Э4 создается на основе схем Э6 и Э3. По сути дела она представляет собой “расширенную” Э6, в которой каждый соединитель дополнен информацией о проводах, приходящих на его выводы и адресах соединения. С точки зрения информационного моделирования важным является возникновение нового типа связей между контактами, а именно связей типа проводное соединение.

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

1

Рис. 4: Вклад схемы Э4 в общую модель данных

Интересно отметить, что важнейшее родительское отношение между сущностями Цепь и ОтрезокПровода: "Цепь реализуется в виде одного или нескольких ОтрезковПроводов" (принадлежащих одному или нескольким жгутам) – не находит отражения на традиционной схеме Э4 и существует только в голове конструктора. Зато это отношение явно обозначено в БД проекта в виде цепочки ассоциаций между экземплярами сущностей Цепь, Контакт, Контакт-ОП и ОтрезокПровода. Именно благодаря нему при автоматизированном проектировании каждый провод в каждом жгуте знает, какую электрическую цепь он обслуживает.

Полная модель данных, отражающая электрическую
конструкцию изделия

Интегрируя вклады каждого объекта проектирования в общую модель данных, приходим к диаграмме (Рис. 5), на которой представлено ядро информационной модели САПР «СА». Это ядро состоит из десятка базовых таблиц, которые в компактном и формализованном виде накапливают, хранят и предоставляют всем связанным этапам проектирования необходимую информацию.

Основой ИМ является таблица состава (СоставнаяЧасть). Построенное на этой таблице рекурсивное отношение  отражает входимость элементов СА в состав друг друга.

Таблица Материал, подчиненная таблице состава, описывает материалы, такие как Трубка, Плетенка, Провод, примененные в составных частях СА. Таблица Документ представляет множество конструкторских документов, выпущенных на составные части СА.

схемаданных

Рис. 5: Полная модель данных, отражающая электрическую конструкцию изделия

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

-      таблица РазъемноеСоединение описывает взаимосвязи соединителей, осуществляемые на основе разъемного соединения "вилка-розетка";

-      таблицы Контакт и Цепь описывают взаимосвязи контактов СЧ (приборов, соединителей, ЭРИ) по признаку равного потенциала;

-      таблицы УзелЖгута, УчастокЖгута и др. описывают топологические и геометрические связи в жгуте;

-      таблицы Контакт-ОП, ОтрезокПровода, Провод представляет реализацию электрических связей в виде проводного монтажа.

Такого рода табличная модель данных, заполненная в процессе проектирования информацией о конкретном изделии, с точки зрения отражения состава, характеристик составных частей и взаимосвязей между ними является полным эквивалентом традиционной КД на СА. Хотя форма представления данных является менее наглядной для человека, зато более формализованной и доступной для процедур автоматизированной обработки.

Практика использования реляционной базы данных
в качестве информационного ядра САПР

Разработанная модель предметной области была реализована в виде связанных таблиц базы данных MS Access 2000. Взаимодействие прикладных систем с информационным ядром осуществляется как через объектно-ориентированный интерфейс, построенный на основе COM-технологий, так и непосредственно на основе SQL-запросов (в тех случаях, когда табличная форма представления данных является основой для построения пользовательского интерфейса: перечни элементов, таблицы соединений, спецификации и т.п.)

Использование сохраненных SQL-запросов существенно облегчило труд программистов. Они смогли, не написав ни строчки кода, создать и отработать в визуальном режиме более сотни (!) полезных представлений проектных данных, с разнообразными условиями сортировки и группировки, чтобы затем встроить их в свои прикладные программы.

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

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

Данный подход подтверждает свою целесообразность и в контексте дальнейшей интеграции, которая, очевидно, будет происходить в рамках PDM-системы. Действительно, ядром PDM-системы, как правило, является реляционная СУБД, а центром взаимосвязей – таблица состава изделия. Наш подход обеспечивает легкое встраивание приложений САПР «СА»в подобную среду, путем «пристыковки» связанных предметно-ориентированных таблиц (Цепей, Контактов и т.д.) и, возможно, корректировки нескольких базовых SQL-запросов.