CC BY
28Решетневскце чтения
- набор библиотек стандартных изделий и материалов для CATIA V5. За основу взята бесплатная информация из Интернета. Библиотеки развернуты в системе SmarTeam с использованием методологии Design Express;
- комплекс настроек и программных модулей, обеспечивающих оформление чертежей и конструкторских спецификаций. Реализован с использованием разработок компании «Би Питрон» и бесплатных программных модулей компании EPAM Systems;
- выполнена русификация модели данных PLM Express.
Подсистемы поиска данных, генерации отчетов, управления проектами и электронного согласования не потребовали доработок, что является преимуществом модели данных PLM Express.
Перспективные направления развития проекта:
- разработка подсистемы управления закупками материалов;
- разработка подсистемы управления качеством изделий;
- внедрение модулей CATIA V5, выполняющих задачи инженерного анализа и оптимизации, а также ряда партнерских приложений;
- внедрение модулей управления знаниями системы CATIA V5;
- внедрение модулей электрического проектирования системы CATIA V5;
- внедрение модулей CATIA Composites Design для разработки конструкций из композитных материалов;
- внедрение системы SmarTeam для бизнес-процессов разработки электронных приборов;
- внедрение ряда модулей системы технологической подготовки производства DELMIA V5;
- внедрение методологии управления компонентной структурой изделия.
Общее время выполнения проекта составило 2,5 месяца, включая обучение специалистов НОЦ. В настоящее время в системе реализуется пилотный проект разработки оборудования для производства космической техники.
M. V. Lihachev Bee Pitron Ltd, Russia, Krasnoyarsk
A. Yu. Vlasov
Siberian State Aerospace University named after academician M. F. Reshetnev, Russia, Krasnoyarsk
PRODUCT LIFECYCLE MANAGER SYSTEM BASED ON PLM EXPRESS DATAMODEL OF ENOVIA SMARTEAM V5 SOFTWARE
PLM System based ob ENOVIA SMARTEAM, CAD/CAM/CAE CATIA V5, MS Project software has been developed and implemented. Latest achievements at the domains of data modeling and PLM system localization have been utilized. Enterprise business process reengineering has been conducted.
© Лихачев М. В., Власов А. Ю., 2011
УДК 681.3.07
О. Н. Моргунова
Сибирский государственный аэрокосмический университет имени академика М. Ф. Решетнева, Россия, Красноярск
ОРГАНИЗАЦИЯ ЖУРНАЛА ОПЕРАЦИЙ С БАЗОЙ ДАННЫХ В СИСТЕМЕ POSTGRESQL
Предлагается подход к организации журнала операций с базой данных. Основная идея используемой технологии заключается в создании журнальной таблицы для каждой рабочей таблицы базы данных, а также в создании трех правил (CREATE RULE): для операций вставки, обновления и удаления записей из рабочих таблиц. При выполнении операций с рабочей таблицей копии вставляемой, обновляемой или удаляемой записи вставляются в журнальную таблицу.
При эксплуатации информационных систем возможны не только сбои в работе оборудования, но также и ошибки оператора. В первом случае может потребоваться выполнить восстановление базы данных (БД) с ее резервной копии. Для этого используются стандартные утилиты, входящие в комплект системы управления базами данных (СУБД). Такие
утилиты имеются и в составе СУБД PostgreSQL. В случае же ошибок оператора, особенно если они обнаружены с опозданием, выполнение восстановления базы данных посредством системной утилиты приведет к тому, что будут утрачены и корректные изменения базы данных, выполненные после проведения последнего резервного копирования. Таким
Информационные системы и технологии
образом, даже небольшая ошибка оператора может привести к необходимости повторного выполнения ввода или корректировки значительного объема данных.
Если бы в базе данных сохранялась вся история изменений каждой реляционной таблицы, то администратор имел бы возможность выполнять восстанов -ление не только всей таблицы целиком, но и каждой конкретной строки в таблице.
Предлагается организовать такую систему учета изменений базы данных, которая была бы построена на основе системы правил (rules) СУБД PostgreSQL.
Основные принципы и правила ее построения следующие.
1. В каждую таблицу базы данных вводятся следующие атрибуты, содержащие служебную информацию:
who_chg text DEFAULT USER - кем добавлена (изменена) запись;
when_chg timestamp DEFAULT
CURRENT_TIMESTAMP - когда добавлена (изменена) запись.
2. Для каждой таблицы базы данных, которые назовем рабочими таблицами, должна быть создана таблица, которую будем называть журнальной. Эта таблица содержит все атрибуты рабочей таблицы и дополнительно еще три атрибута:
db_operation text - операция над БД;
who_add text DEFAULT USER - кем добавлена запись;
when_add timestamp DEFAULT
CURRENT_TIMESTAMP - когда добавлена запись.
3. Журнальные таблицы создаются без каких-либо ограничений целостности. Ограничения целостности не нужны, поскольку записи в журнальные таблицы добавляются только из рабочих таблиц, а в рабочих таблицах ограничения целостности присутствуют, поэтому данные в них согласованные.
4. Для каждой рабочей таблицы создается три так называемых правила (CREATE RULE). Это расширение языка SQL, поддерживаемое СУБД PostgreSQL. Правила позволяют с каждой операцией, выполняемой над таблицей базы данных, связать некоторые дополнительные операции, выполняемые, возможно, над другими таблицами. В нашей технологии правила создаются для операций вставки записей в таблицу
(INSERT), обновления записи в таблице (UPDATE) и удаления записей из таблицы (DELETE).
Правило для операции вставки записей выглядит так:
CREATE RULE Langs_rule_1 AS
ON INSERT TO Langs
DO INSERT INTO Langs_2 (lang_code, lang_fname, lang_sname, comment, who_chg, when_chg, db_operation) VALUES (NEW. lang_code, NEW. lang_foame, NEW. lang_sname, NEW. comment, NEW. who_chg, NEW. when_chg, 'INSERT').
В этой команде таблица Langs - это основная таблица, а Langs_2 - журнальная таблица. Атрибут db_operation будет содержать значение 'INSERT', атрибут who_add - значение по умолчанию, т. е. имя пользователя, добавившего запись в рабочую таблицу, атрибут when_add - значение по умолчанию, т. е. временную отметку выполнения операции.
Правило для операции обновления записей выглядит так:
CREATE RULE Langs_rule_2 AS
ON UPDATE TO Langs
DO INSERT INTO Langs_2 ( lang_code, lang_fname, lang_sname, comment, who_chg, when_chg, db_operation) VALUES (NEW. lang_code, NEW. lang_foame, NEW. lang_sname, NEW. comment, NEW. who_chg, NEW. when_chg, 'UPDATE').
Правило для операции удаления записей выглядит так:
CREATE RULE Langs_rule_3 AS
ON DELETE TO Langs
DO INSERT INTO Langs_2 (lang_code, lang_fname, lang_sname, comment, who_chg, when_chg, db_operation) VALUES (OLD. lang_code, OLD. lang_foame, OLD. lang_sname, OLD. comment, OLD. who_chg, OLD. when_chg, 'DELETE').
5. В журнальные таблицы записи только добавляются, но не обновляются и не удаляются из них. Поэтому сохраняется вся история изменения каждой записи из рабочей таблицы.
Предложенный подход позволит повысить безопасность выполнения операций с базой данных. В случае ошибки оператора администратор базы данных сможет отыскать запись в журнальной таблице и восстановить то состояние конкретной записи в рабочей таблице, которое требуется.
O. N. Morgunova
Siberian State Aerospace University named after academician M. F. Reshetnev, Russia, Krasnoyarsk SETTING UP OF DATABASE LOGGING SYSTEM FOR POSTGRESQL DBMS
Setting up of database logging system for PostgreSQL DBMS is proposed. The main idea of the technology is that for each working table there must be created a logging table. Additionally, three rules (CREATE RULE) must be created for database operations, namely - INSERT, UPDATE, DELETE. When inserting, updating or deleting a record a copy of this record is being inserted into a logging table.
© Моргунова О. Н., 2011
