Организация переноса геометро-графической информации
в базу данных для прикладной программы
Н.Л. Макаров,
асс., makarov.nl@outlook.com
С.А. Роменский,
асп., romensky.serge@gmail.com
С.И.
Ротков,
зав.
каф., д.т.н., проф., rotkov@nngasu.ru
М.М.
Смычёк,
асс., mariasmychek@gmail.com,
ННГАСУ,
г. Нижний Новгород,
В.Л. Чепкасов,
асп., vladimir.chepkasov@outlook.com
НГТУ им. Р.Е. Алексеева, г. Нижний Новгород
В статье
рассматриваются проблемы переноса геометро-графической
информации из форматов хранения различных САПР в спроектированную базу данных
для удобства и оперативности дальнейшего использования
данных в прикладной программе.
The article deals with the problems of transferring geometry information
from the variety of CAD-systems storage formats to the designed database for
the convenience and efficiency of further use of the data in the user
application.
Работа
выполнена по грантам РФФИ №15-07-05110 и
№15-07-01962.
Электронная модель любого изделия, используемая в
CALS-технологиях, на 80-90% состоит из геометро-графической
информации, которая создается конструктором или технологом с помощью
соответствующих программных средств, входящих в состав систем
автоматизированного проектирования и технологической подготовки производства.
Каждая из таких систем имеет свой, только ей присущий, экранный интерфейс, свою
внутреннюю структуру данных и свои алгоритмы решения элементарных геометро-графических задач. Это приводит к проблемам
передачи данных между составными частями систем автоматизированного проектирования,
к трудностям при составлении прикладных программ конкретного пользователя, к проблемам
чтения и интерпретации данных из внутренней структуры конкретной системы. Кроме
того, внутренняя структура данных каждой системы является предметом коммерческой
тайны фирмы-разработчика системы и тщательно охраняется, и не публикуется.
Для обеспечения информационной совместимости между
различными системами существуют два основных способа передачи данных [1,2]:
v через
программы – конвертеры данных, создаваемые по принципу «каждый с каждым», что
приводит к необходимости создавать дополнительную программу связи;
v через
промежуточный нейтральный формат типа IGES [3] или STEP [1].
Главная функция нейтрального формата – перенос данных из
одной системы в другую. При этом фирма-разработчик оставляет за собой право
реализовывать то или иное подмножество нейтрального формата, что приводит к
разночтениям при передаче и анализе данных в системе-приемнике. При создании
прикладных программ пользователя, реализующих новые функциональные возможности
системы проектирования, не предусмотренные фирмой-разработчиком, использование
нейтрального формата приводит к необходимости изучения достаточно сложной
внутренней структуры нейтрального файла, а также большим накладным расходам времени
и вычислительных мощностей.
В то же время в состав любой САПР входит система управления
базами данных (СУБД), которую можно использовать для оперативного хранения,
анализа и передачи геометро-графических данных. Данная СУБД закрыта для доступа пользователя,
что приводит к двум принципиальным ограничениям при создании прикладной
программы пользователя, в которой должна быть обработана геометро-графическая
информация, использующая внутренние форматы хранения данных. Для преодоления
противоречия необходимо иметь операторы чтения и записи из внутренней структуры
данных системы, которые предоставляет либо фирма-разработчик САПР, либо данные
операции происходят на уровне текстовых фирменных форматов.
Это может быть осуществлено путем создания промежуточной автономной
и доступной пользователю базы данных, в которую будет распакована информация из
текстового файла или других форм представления данных.
Рассмотрим некоторые существующие форматы хранения и
передачи геометро-графической информации между
системами:
· бинарный
файл, содержащий закодированную информацию;
· классический
последовательный файл с записями фиксированной либо переменной длины;
· текстовый
формат хранения, основанный на XML, содержащий
поясняющие теги.
В случае
бинарного файла чтение геометро-графической
информации затруднено закрытостью формата, чтение-запись данных в этом случае
может быть осуществлено лишь при помощи API
САПР, в которой этот файл создан.
Для
классического последовательного файла с записями фиксированной либо переменной
длины время поиска нужной информации определено в [12] и может занимать
значительное время, если исходный файл достаточно большой по объему, до
нескольких Мбайт.
Используется в российской САПР «Компас», разработан
компанией «Аскон». Предназначен для
хранения и использования внутри данной САПР, содержит информацию о чертеже в
бинарном виде. Может содержать двухмерные и трехмерные данные, которые
представляют собой упорядоченный набор геометрических параметров таких, как:
координаты точек, коэффициенты уравнений линий, в том числе высоких порядков,
информацию о типе линий и другие неграфические атрибуты.
Достоинством внутреннего формата системы КОМПАС являются
компактность хранения, т.е. сравнительно малый объем файла чертежа или модели и
отсутствие дублирования данных.
Недостатками формата является что, что все данные о чертеже
или модели хранятся в бинарном виде, что неудобно для расшифровки без
спецификации, и, следовательно, приводит к трудностям при организации обмена
данными с API программами. Чтение бинарного формата .cdw
осуществляется из прикладного приложения путем взаимодействия с САПР «Компас»
через предлагаемое компанией «Аскон» API и
COM-объекты, обеспечивающие связь между двумя запущенными приложениями.
Таким образом, чтение данных из файла формата .cdw возможно произвести лишь средствами САПР «Компас»,
когда нужный файл открывается внутри САПР и интересующие данные при помощи
связующего COM-объекта передаются родительскому процессу прикладного приложения.
Вместе с САПР «Компас» поставляется SDK с примерами
использования API, где так же описана процедура чтения данных из открытого
документа при помощи обхода всех имеющихся слоев, видов и объектов внутри
чертежа.
Запись формата .cdw так же
осуществляется при помощи API «Компас» и средствами самой САПР [6].
DXF (англ. Drawing eXchange Format) — открытый
формат файлов для обмена графической информацией между приложениями САПР. Был
создан фирмой Autodesk для системы AutoCAD. Поддерживается практически всеми CAD-системами на
платформе PC. [9]
К числу достоинств данного формата можно отнести хранение геометро-графической информации в текстовом виде, открытую
спецификацию, что облегчает чтение данных прикладной программой, распространенность
формата среди различных САПР, последовательность хранения данных внутри файла в
виде записей фиксированного формата и объема (80 байт).
К недостаткам данного формата можно отнести закрытую
спецификацию хранения трехмерных данных, постоянно расширяющуюся спецификацию
хранения двухмерных данных. Из особенностей внутренней структуры хранения
данных, минусом формата является то, что в каждой записи содержится один символ
или число, что дает разреженность данных и, как следствие, большой объем
выходного файла.
Так как формат .dxf является
текстовым, то и чтение, и запись осуществляются так же, как и у обычного
текстового файла с тем отличием, что данный формат
имеет определенную структуру, состоящую в основном из 4 секций.
Секция HEADER хранит в себе различные именованные переменные
чертежа, например, версию создавшей файл программы, максимальные и минимальные
координаты в чертеже и т.д.
Секция TABLES хранит в себе массивы данных, такие как: таблица слоев со всеми их
свойствами, таблица стилей и т.д.
Секция BLOCKS хранит в
себе описание примитивов, объединенных в блоки. Каждый блок имеет уникальный
идентификатор, позволяющий вставить данную часть чертежа при помощи команды
INSERT в любое место в конечном чертеже. Кроме того, после изменения внутри
одного блока, все его включения в основной чертеж так же изменятся.
Секция ENTITIES хранит
в себе описание графических примитивов и, по сути, и является отрисовываемой частью.
Все коды графических
примитивов можно найти в спецификации формата на сайте компании Autodesk.
SVG (от англ. Scalable Vector Graphics — масштабируемая
векторная графика) — язык разметки масштабируемой векторной графики, созданный
Консорциумом Всемирной паутины (W3C) и входящий в подмножество расширяемого языка
разметки XML, предназначен для описания двумерной векторной и смешанной векторно/растровой графики в формате XML. Поддерживает как
неподвижную, так и анимированную интерактивную графику — или, в иных терминах,
декларативную и скриптовую. Не поддерживает описание
трёхмерных объектов (не путать с имитацией трёхмерности
путём светотени). Это открытый стандарт, который является рекомендацией
консорциума W3C — организации, разработавшей такие стандарты, как HTML и XHTML.
В основу SVG легли языки разметки VML и PGML. Разрабатывается с 1999 года. В
2001 году вышла версия 1.0, в 2011 - версия 1.1, которая остается актуальной до
сегодняшнего дня. В настоящее время в активной разработке находится версия 2.
[11]
Достоинствами данного формата являются удобная для программиста
структура хранения объектов при помощи тегов, открытая спецификация,
возможность сжатия конечного файла в формат .svgz.
Данный формат хранения наследует все недостатки своего
«предка» - xml, а так же сложен при чтении больших
объектов (например, в картографии), так как для отображения маленького участка
необходимо прочесть весь файл.
Чтение и запись данного формата происходит либо в текстовом
режиме, либо при помощи специальной библиотеки, разбирающей весь файл по
внутренним тегам.
Краткий анализ имеющихся форматов
показывает необходимость разработки средств конвертирования геометро-графической
информации из формата системы в некоторый промежуточный вид, который являлся
бы, с одной стороны, промежуточной базой данных, не связанной с конкретной системой,
а с другой стороны, предоставлял бы пользователю возможность оперативного
получения геометро-графических данных для своей
прикладной программы, не зависящей от конкретной системы проектирования.
В
ходе изучения данной проблемы было принято решение использовать в качестве
посредника между системой автоматизированного проектирования и прикладной
программой базу данных, имеющую специальную структуру для хранения геометро-графической информации.
Рис.1 ER-диаграмма
представления числовой геометро-графической
информации внутри базы данных
Центральной сущностью [12,c.151]
для представления геометро-графической
информации внутри базы данных будет сущность «Точка».
Сущность представляет собой кортеж <ID, X, Y, Z>, где
ID – уникальный идентификатор точки в рамках базы данных, представляет собой
первичный ключ. Тройка <X, Y, Z> представляет собой координаты точки в
трёхмерном пространстве. Остальные информационные объекты тем или иным образом
связаны с сущностью «Точка».
Следующий информационный объект – это кривая. Данный объект
состоит из трех сущностей «Сегмент_кривой», «Кривая»,
и ассоциативной сущностью «Кривая_vs_сегмент_кривой».
Сущность «Сегмент_кривой» состоит из пяти атрибутов
<ID, ID_ТОЧКА_Н, ID_ТОЧКА_К, ID_ОП_1, ID_ОП_2>. Первый атрибут — это
первичный ключ. Четыре последних атрибута представляют собой внешние ключи на
сущность «Точка». В общем случае сущность «СЕГМЕНТ_КРИВОЙ» описывает кубическую
кривую Безье, точнее кортеж сущности «СЕГМЕНТ_КРИВОЙ» содержит четыре опорные
точки, определяющие форму кривой. В частном случае сущность описывает связь
двух точек, отрезок. Сущность «Кривая» состоит из двух атрибутов <ID,
НАЗВАНИЕ>. Кривая может состоять из множества отрезков или сегментов.
Сущность «Кривая» имеет связь с сущностью «СЕГМЕНТ_КРИВОЙ» по средствам
ассоциативной сущности «Кривая_vs_сегмент_кривой». Кортеж сущности «Кривая_vs_сегмент_кривой»
представляет собой тройку <ID_Кривой,ID_Сегмент_кривой,Order>.
Если первые два атрибута это внешние ключи на сущности «Сегмент_кривой»
и «Кривая», то последний это порядок соединения сегментов между собой. Кривая
может быть как замкнутой, так и разомкнутой, этот признак может быть задан с
помощью параметров.
Частным случаем кривой, может быть дуга [13,c.29].
Окружности и полуокружности удобно представлять не так, как кривые. Поэтому имеет
смысл выделить сущность «Дуга». Кортеж этой сущности состоит из пяти атрибутов
и представляет собой <ID, ID_ТОЧКИ_Н, ID_ТОЧКИ_К, ID_ТОЧКИ_Ц, Направление_обхода>. Первый
атрибут – первичный ключ. Три следующих – внешние ключи на сущность «Точка».
Первая точка задает координаты начала дуги, вторая – координаты окончания дуги.
Последняя точка задает координаты центра дуги. Последний атрибут сущности –
направление обхода: по часовой стрелке или против часовой стрелки.
Следующей подгруппой информационных объектов являются фигуры
[13,с.39]. Фигуры могут быть плоские или объемные. Выделены следующие сущности: «2D_Фигура»,
«2D_Фигура_vs_Кривая_Дуга», «3D_Фигура», «Тип_3D_Фигуры», «3D_Фигура_vs_2D_Фигура».
Сущность «2D_Фигура» задает плоские фигуры, ее кортеж представляет собой «ID,Название». Сущность имеет связь с сущностями «Дуга» и
«Кривая» по средствам ассоциативной сущности «2D_Фигура_vs_Кривая_Дуга». Кортеж
этой сущности — это набор <ID_2D_Фигуры, ID_Кривой,
ID_Дуги, Order>. Первая
тройка атрибутов представляет собой внешние ключи на сущности «2D_Фигура»,
«Кривая», «Дуга». Последний атрибут задает порядок соединения дуг и кривых.
Сущность «3D_Фигура» задает объемные фигуры, ее кортеж –
тройка атрибутов <ID,Название, ID_Типа>.
Последний атрибут представляет собой внешний ключ на сущность «Тип_3D_Фигуры»,
в свою очередь эта сущность задает типы фигур, стандартные или
пользовательские. Стандартные фигуры – это фигуры, которые могут поставляться вместе
с БД. Например, базовые геометрические трёхмерные фигуры. Пользовательские же –
фигуры, которые может добавлять пользователь БД по своему усмотрению. Сущность
«3D_Фигура» связывается с сущностью «2D_Фигура» по средствам ассоциативной
сущности «3D_Фигура_vs_2D_Фигура». В понятиях такой структуры данных[13,c.28]
объемная фигура представляет собой набор плоских фигур расположенных
относительно друг друга определенным образом. Такое представление данных
отвечает принципу – составлять сложные объекты из множества простых.
Для группы численного представления можно выделить еще три
сущности информационных объектов: «Булевые_Операции»,
«Аффинные_Преобразования», «Параметры». Выделение
данных сущностей позволяет сделать хранение данных более простым и гибким [13,c.32].
Сущность «Булевые_Операции» имеет
кортеж <ID,Название>. Эта сущность связана с
сущностью «2D_Фигура» по средствам ассоциативной сущности
«2D_Фигура_vs_Булевая_Операция», кортеж которой представляет собой набор <ID,
Parent_ID, ID_2D_Фигуры, ID_Булевой_Операции>.
Первый атрибут – первичный ключ. Второй атрибут внешний ключ на кортеж из этой
же сущности. Два последних атрибута – внешние ключи на сущности «2D_Фигура» и «Булевые_Операции». Так же сущность «Булевые_Операции»
имеет связь с сущностью «3D_Фигура», по средствам ассоциативной сущности
«3D_Фигура_vs_Булевая_Операция», ее кортеж аналогичен кортежу сущности
«2D_Фигура_vs_Булевая_Операция».
Аффинные преобразования могут производиться для объектов,
которые заданы в сущности «Тип_объекта»,
кортеж представляет собой тройку <ID, Название, Название_таблицы>.
Первый атрибут – первичный ключ, второй атрибут - название объекта. Третий
атрибут – название сущности, над которой будут производится
аффинные преобразования. Сущность «Аффинные_Преобразования»
связываются с другими сущностями по средствам ассоциативной сущности «Объект_vs_Афф_Преобр», кортеж этой сущности представляет
собой набор <ID,ID_Объекта,ID_Афф_Преобр,ID_типа_объекта,ID_Точка>.
<ID> - первичный ключ.
<ID_Объекта> - идентификатор
объекта, который участвует в преобразованиях. <ID_Афф_Преобр>
- внешний ключ на сущность «Аффинные_Преобразования».
Сущность «Объект_vs_Афф_Преобр» имеет связь с
сущностью «Параметры» по средствам ассоциативной сущности «Афф_Преобр_vs_Параметры».
Сущность предназначена для хранения параметров аффинных преобразований. Её
кортеж задается в виде <ID,ID_Афф_Преобр_Объекта,ID_Параметра,Значение,Тип,I,J>. Первый атрибут – первичный
ключ, второй – внешний ключ на сущность «Объект_vs_Афф_Преобр»,
третий – внешний ключ на сущность «Параметры». <I, J> индексы элементов
матрицы преобразований, <Значение> - задает величину элемента матрицы.
Сущность «Параметры» имеет связь с
сущностями «Афф_Преобр_vs_Параметры», «Дуга»,
«Точка», «Сегмент_кривой», «Кривая», «2D_Фигура»,
«3D_Фигура». В каждом случае связь между сущностями многие ко многим,
поэтому для каждого случая появляется ассоциативная сущность. В общем случае
кортеж таких сущностей представляет собой набор <ID, ID_*, ID_Параметра, Значение, Тип>. Первый атрибут – первичный
ключ, второй – внешний ключ на сущность, для которой задается параметр, третий
– внешний ключ на сущность «Параметры». Атрибут <Значение> - задает
величину параметра, а атрибут <Тип> - указывает на тип данных, которые
хранятся в атрибуте <Значение>.
Рис.2 ER-диаграмма представления аналитической геометро-графической информации внутри базы данных
В группе с аналитическим представление объектов выделены следующие
основные сущности: «Переменные», «Члены», «Тип_элемента»,
«Группа», «Математические_операции», «Операции_сравнения», «Многочлен», «Система_Многочленов»,
«2D_Фигура_Аналит», «3D_Фигура_Аналит».
Для сущностей
«Переменные», «Математические_операции», «Система_Многочленов», «2D_Фигура_Аналит»,
«3D_Фигура_Аналит» одинаковое представление кортежей, это пара <ID, NAME>,
где первый атрибут – это первичный ключ, второй – это название. Для сущности
«Переменные» – название переменных участвующих в задании
полинома, для сущности «Математические_операции» –
название математической операции, для сущности «Система_Многочленов»
– название системны многочленов, для сущностей «2D_Фигура_Аналит» и
«3D_Фигура_Аналит» – название фигуры.
Сущность «Члены»
хранит коэффициенты одного из членов, многочлена. Задается кортежем <ID,ID_Переменной,Степень_Члена,Коэф,Степень_Коэф>.
Где атрибут <ID_Переменной> - внешний ключ на
сущность «Переменные», а первый атрибут – первичный ключ. Остальные атрибуты
задают коэффициенты члена.
Сущность «Тип_элемента» определяет элемент, элемент может быть
группой или членом. Сущность «Группа» похоже на сущность «Члены» за тем
исключением, что определяет коэффициенты для объединенных вместе членов или
других групп.
Между сущностями
«Члены», «Группа» и «Тип_элемента» существует связь,
которая определяется ассоциативной сущностью «Члены_vs_Группы».
Кортеж этой сущности выглядит как набор <ID_Группы,ID_Элемента,ID_Тип_Элемента>.
Атрибуты представляют собой внешние ключи на сущности, которые ее образуют.
Сущность «Операции_Сравнения» предназначена для хранения операций
сравнения. Кортеж сущности – пара атрибутов <ID,Сравнение>.
Сущность «Многочлен»
предназначена для хранения многочленов. Задается кортежем <ID,NAME,ID_Операции_Сравнения>. Первый атрибут –
первичный ключ. Второй атрибут – название многочлена. И третий – внешний ключ
на сущность «Операции_Сравнения».
Сущности «Многочлен»,
«Математические_операции» и «Группа» образуют
ассоциативную сущность «Многочлен_vs_Группа». Кортеж
сущности представляет собой набор
<ID_Многочлена,ID_Группы,ID_Мат_операции,Order,Левый_или_Правый>. Первые
три атрибута представляют собой внешние ключи на образующие сущности. Атрибут
<Order> – определяет порядок соединения групп.
Атрибут <Левые_или_правый> определяет
размещение группы в многочлене.
Сущности «Многочлен»
и «Система_Многочленов» связаны по средствам
ассоциативной сущности «Система_vs_Многочлены».
Сущность группирует многочлены в группы (системы).
Плоская фигура
задается множеством систем уравнений. Связь системы уравнений и плоской фигуры
определяет сущность «2D_Фигура_Ан_vs_Сист_Многочл»,
которая связывает сущности «2D_Фигура_Аналит» и «Система_Многочленов».
Объемные фигуры
задаются сущностью «3D_Фигура_Аналит». В общем случае объемные фигуры
определяются множеством плоских фигур, то есть сущности «3D_Фигура_Аналит» и
«2D_Фигура_Аналит» связаны по средствам ассоциативной сущности «3D_Фигура_Ан_vs_2D_Фиг_Аналит».
Этапы переноса геометро-графической информации
из различных форматов хранения в
спроектированную базу данных
1. Условная подразбивка геометро-графической информации из формата хранения данных
по «видам» (определяемая либо самим форматом хранения, либо же исходя из
связности компонент геометро-графической информации).
2. Сопоставление сущностей, описанных в структуре базы
данных с сущностями, содержащими геометро-графическую
информацию внутри читаемого формата хранения данных.
3. Перенос геометро-графической
информации в структуру базы данных.
Заключение
·
Рассмотрены
различные способы передачи геометро-графической информации.
·
Исследованы
некоторые распространенные форматы хранения данных САПР, а также возможности их
чтения и записи.
·
Спроектирована
структура базы данных для хранения геометро-графической
информации.
Данная
прикладная программа является частью программного комплекса, необходимого для
решения важной и актуальной производственной задачи преобразования архивной
информации с бумажного носителя в электронную модель объекта производства для PDM-систем [14].
1. Подколзин В.Г., Судов
Е.В. Применение STEP-технологии при построении корпоративной системы «КБ - завод». // В сб. Проблемы продвижения
продукции и технологий на внешний рынок. Специальный выпуск. М., 1997, С.41 –
44
2. Ротков.С.И. Разработка средств геометрического моделирования и
компьютерной графики пространственных объектов для CALS-технологий. Дисс. Докт. Техн.
Наук, Нижний Новгород, 05.01.01, ННГАСУ, 1999 год, 300 с.
3. J. Russell, R.
Cohn, IGES, 2013 – 101 с.
4. Ганин Н.Б.
Трехмерное проектирование в Компас-3D, Москва, 2012 - 784 с.
5. ЗАО АСКОН.
Система проектирования спецификаций. Руководство пользователя, Москва, 2005 - С.
98-99
6. Роменский С.А.,
«Передача геометро-графической информации из системы
автоматизированного проектирования в прикладную программу на примере САПР
«Компас-График» // Системы проектирования, технологической подготовки
производства и управления этапами жизненного цикла промышленного продукта
(CAD/CAM/PDM-2015) : сб. тр. международ.
конф. , 26-28 октября 2015., Москва, 2015. С. 97
7. Журавлев
А.С., AutoCAD для конструкторов. Стандарты ЕСКД в AutoCAD 2009/2010/2011, Санкт-Петербург, 2011 - С. 24-27
8. Полещук
Н.Н., Autocad 2009: наиболее полное руководство, Санкт-Петербург,
2009 – 1184 с.
9. DXF
[Электронный ресурс]: Wikipedia. URL:
https://ru.wikipedia.org/wiki/DXF (дата обращения: 11.03.2015).
10. J. D. Eisenberg, SVG Essentials, 2002 – 360 с.
11. SVG
[Электронный ресурс]: Wikipedia. URL: https://ru.wikipedia.org/wiki/SVG
(дата обращения: 11.03.2015).
12. Дейт К. Дж.
Введение в системы баз данных. — 8-е изд. — М.: «Вильямс», 2006:
13. Хорафас Д., Легг С. Конструкторские базы данных Пер. с англ. — М.:
Машиностроение, 1990. — 224 с.: ил. — ISBN 5-217-00976-4.
14. Васин Д.Ю.,
Макаров Н.Л., Мошкова Т.В., Попов Е.В., Роменский
С.А., Ротков С.И., Тюрина В.А., Чепкасов В.Л.; «Проблема преобразования бумажных архивов
чертежно-конструкторской документации в электронную модель изделия и связанные
с ней геометро-графические задачи»; // Труды
Международной конференции и Школы «Ситуационные центры и геоинформационные
системы для задач мониторинга и безопасности: 10 лет НеоГеографии
(SC-NeoGeo-VRTerro2015)», посвященной 10-летию НеоГеографии,
24-26 ноября 2015 года, Пущино, ПущГЕНИ, Россия.