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

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

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

На основе дерева требований клиента к ОК (функциональной конфигурации) и с помощью разрабатываемой базы данных должен быть осуществим синтез конфигурации изделия путем выбора нужного модуля по каждому объекту конфигурации. Совокупность всех таких модулей и базового изделия и будет являться техническим решением. Рисунок 2.8 представляет синтез конфигурации.

Рисунок 2.7 "Организация базы данных"

Рисунок 2.8 "Синтез конфигурации технических изделий"

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



Рисунок 2.9 "Последовательность действий с БД на стадии «Предпроектные работы»"

Рисунок 2.10 "Последовательность действий с БД на стадии «Проектирование»"

Рисунок 2.11 "Последовательность действий с БД на стадии «Производство»"

В соответствии с описанной моделью функционирования предметной области была построена следующая структура базы данных. Физическая модель данных (Рисунок 2.12):



Рисунок 2.12 Физическая модель данных

2.4.2 Описание таблиц и атрибутов

· Документ_конфигурации - таблица, которая содержит информацию о документах, касающихся изделий;

· Изделие - таблица, в которой хранится информация об изделиях;

· Модуль - таблица, в которой описываются модули изделий;

· Модуль_Сборка - таблица, которая содержит информацию о том, какие модули участвуют в конкретной сборке;

· Отдел - таблица, в которой хранится информация об отделах предприятия;

· Поставщик - таблица, в которой заключена информация о поставщиках модулей;

· Поставщик_Модуль - таблица, которая описывает какие модули какой поставщик поставляет;

· Сборка - таблица, в которой хранится информация о конкретной сборке изделия;

· Сотрудник - таблица, в которой содержится информация о сотрудниках предприятия;

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

· Требование - таблица, в которой описаны требования заказчика к модулям.

Таблица 2.2 "Описание атрибутов таблицы Документ_конфигурации"

Документ конфигурации	Тип данных	Описание
ИН_ДК (PK)	Smallint	Идентификационный номер конфигурации
Дата_создания	Datetime	Дата создания док-та
Вложение	Char(30)	Название вложения
ИН_Ст (FK)	Smallint	Идентификационный номер статуса
ИН_Сотр (FK)	Smallint	Идентификационный номер сотрудника

Таблица 2.3 "Описание атрибутов таблицы Изделие"

Изделие	Тип данных	Описание
ИН_Изд (PK)	Smallint	Идентификационный номер изделия
Название	Char(30)	Название изделия
Цена	Float	Цена изделия
Описание	Char(100)	Описание изделия
ИН_Ст (FK)	Smallint	Идентификационный номер статуса

Таблица 2.4 "Описание атрибутов таблицы Модуль"

Модуль_Сборка	Тип данных	Описание
ИН_Мод (FK)	Smallint	Идентификационный номер модуля
ИН_Сбор (FK)	Smallint	Идентификационный номер сборки
Количество	Smallint	Количество модулей в сборке

Таблица 2.5 "Описание атрибутов таблицы Модуль_Сборка"

Модуль_Сборка	Тип данных	Описание
ИН_Мод (FK)	Smallint	Идентификационный номер модуля
ИН_Сбор (FK)	Smallint	Идентификационный номер сборки
Количество	Smallint	Количество модулей в сборке

Таблица 2.6 "Описание атрибутов таблицы Отдел"

Отдел	Тип данных	Описание
ИН_О (PK)	Smallint	Идентификационный номер отдела
Название	Char(30)	Название отдела



Таблица 2.7 "Описание атрибутов таблицы Поставщик"

Поставщик	Тип данных	Описание
ИН_Пост (PK)	Smallint	Идентификационный номер поставщика
Название	Char(30)	Название поставщика

Таблица 2.8 "Описание атрибутов таблицы Поствщик_Модуль"

Поставщик_Модуль	Тип данных	Описание
ИН_Пост (FK)	Smallint	Идентификационный номер поставщика
ИН_Мод (FK)	Smallint	Идентификационный номер модуля
Количество	Smallint	Кол-во модулей

Таблица 2.9 "Описание атрибутов таблицы Сборка"

Сборка	Тип данных	Описание
ИН_Сбор (PK)	Smallint	Идентификационный номер сборки
ИН_Изд (FK)	Smallint	Идентификационный номер изделия
ИН_Сотр (FK)	Smallint	Идентификационный номер сотрудника
ИН_ДК (FK)	Smallint	Идентификационный номер документа конфигурации

Таблица 2.10 "Описание атрибутов таблицы Сотрудник"

Сотрудник	Тип данных	Описание
ИН_Сотр (PK)	Smallint	Идентификационный номер сотрудника
ИН_О (FK)	Smallint	Идентификационный номер отдела
Фамилия	Char(20)	Фамилия сотрудника
Имя	Char(20)	Имя сотрудника
Отчество	Char(20)	Отчество сотрудника
Должность	Char(30)	Должность сотрудника

Таблица 2.11 "Описание атрибутов таблицы Статус"

Статус	Тип данных	Описание
ИН_Ст (PK)	Smallint	Идентификационный номер статуса
Описание	Char(30)	Описание статуса

Таблица 2.12 "Описание атрибутов таблицы Требование"

Требование	Тип данных	Описание
ИН_Тр (PK)	Smallint	Идентификационный номер требования
ИН_Мод (FK)	Smallint	Идентификационный номер модуля
Описание	Char(50)	Описание требования

· «Поставщик» - «Поставщик_Модуль»

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

· «Модуль» - «Поставщик_Модуль»

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

· «Модуль» - «Требование»

Связь обозначает требования, которые предъявляются к модулю (ОК). Тип связи - «один-ко-многим», т.к. к одному модулю может предъявляться несколько требований. Таблица «Требование» подчиненная, так как в ее состав входит первичный ключ таблицы «Модуль».

· «Модуль» - «Модуль_Сборка»

Связь обозначает принадлежность модуля к сборке. Тип связи - «один-ко-многим», т.к. один модуль может использоваться в нескольких сборках. Таблица «Модуль_Сборка» подчиненная, так как в ее состав входит первичный ключ таблицы «Модуль».

· «Сборка» - «Модуль_Сборка»

Связь обозначает отношение сборки к модулю. Тип связи - «один-ко-многим», т.к. в одной сборке могут использоваться несколько модулей. Таблица «Модуль_Сборка» подчиненная, так как в ее состав входит первичный ключ таблицы «Сборка». Мощность связи - Р.

· «Изделие» - «Сборка»

Связь обозначает принадлежность изделия к сборке. Тип связи - «один-ко-многим», т.к. одно изделие может быть базой для нескольких сборок. Таблица «Сборка» подчиненная, так как в ее состав входит первичный ключ таблицы «Изделие». Мощность связи - P.

· «Статус» - «Изделие»

Связь обозначает принадлежность статуса к изделию. Тип связи - «один-ко-многим», т.к. один статус может быть присвоен нескольким изделиям. Таблица «Изделие» подчиненная, так как в ее состав входит первичный ключ таблицы «Статус». Мощность связи - Z.

· «Статус» - «Документ_Конфигурации»

Связь обозначает принадлежность статуса к документу конфигурации. Тип связи - «один-ко-многим», т.к. один статус может быть присвоен нескольким документам. Таблица «Документ_Конфигурации» подчиненная, так как в ее состав входит первичный ключ таблицы «Статус». Мощность связи - Z.

· «Документ_Конфигурации» - «Сборка»

Связь обозначает принадлежность документа конфигурации к сборке. Тип связи - «один-ко-многим», т.к. один документ может быть присвоен нескольким сборкам. Таблица «Сборка» подчиненная, так как в ее состав входит первичный ключ таблицы «Документ_Конфигурации». Мощность связи - Р.

· «Сотрудник» - «Документ_Конфигурации»

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

· «Сотрудник» - «Сборка»

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

· «Отдел» - «Сотрудник»

Связь обозначает принадлежность сотрудника к отделу. Тип связи - «один-ко-многим», т.к. в одном отделе может быть несколько сотрудников. Таблица «Сотрудник» подчиненная, так как в ее состав входит первичный ключ таблицы «Отдел». Мощность связи - Р.

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

Далее рассмотрим непосредственно алгоритм аудита конфигурации и реализацию разработанной базы данных с помощью выгрузки ее в СУБД MS SQL Server 2014.

2.4.3 Реализация БД в СУБД

Разработанная схема базы данных была преобразована в скрипт, с помощью которого создавалась БД в программе MS SQL Server 2014. Рисунок 2.13 отображает структура хранилища данных в MS SQL Server 2014. Скрипт создания базы данных представлен в разделе «Приложение» (Приложение 2).

Рисунок 2.13 "Структура БД в MS SQL Server 2014"



Все таблицы были заполнены данными для тестового примера с сохранением их целостности. На рисунках ниже представлены данные, занесенные в таблицы. (Рисунок 2.14-Рисунок 2.24)

Рисунок 2.14 "Заполнение данными таблицы Требование"

Рисунок 2.15 "Заполнение данными таблицы Статус"

Рисунок 2.16 "Заполнение данными таблицы Сотрудник"

Рисунок 2.17 "Заполнение данными таблицы Сборка"

Рисунок 2.18 "Заполнение данными таблицы Поставщик_Модуль"



Рисунок 2.19 "Заполнение данными таблицы Поставщик"

Рисунок 2.20 "Заполнение данными таблицы Отдел"

Рисунок 2.21 "Заполнение данными таблицы Модуль_Сборка"

Рисунок 2.22 "Заполнение данными таблицы Модуль"

Рисунок 2.24 "Заполнение данными таблицы Документ_конфигурации"

Реализация запросов к БД

В рамках выбранной предметной области и с учетом разработанной базы данных с помощью запросов можно получить следующую информацию:

· о поставщиках (какие у предприятия поставщики, сколько модулей они поставляют);

· о модулях - объекта конфигурации (кто поставляет, сколько, по какой цене, какие существуют к ОК требования, в каких сборках и в каком количестве используются модули);

· о сборках (какие в них используются модули с указание количества, какое базовое изделие используется в сборке, какой сотрудник осуществляет сборку, какие документы относятся к сборке);

· о базовых изделиях (в каких сборках используются, сколько стоят, какой имеют статус);

· о документах конфигурации (какой статус имеют, кто подписал, какое прикреплено вложение, дата создания);

· о сотрудниках (ФИО, на какой должности, в каком отделе работает, какие документы подписывал, в каких сборках участвует);

· об отделах (какие есть отделы на предприятии, кто в них работает).

Вышеописанные запросы реализованы в приложении, в данном разделе представлены некоторые из них.

Чтобы сравнить стоимости утвержденных конфигураций изделия был разработан SQL-запрос (Рисунок 2.25). Результаты выполнения данного запроса могут помочь проектировщику сложных технических изделий при принятии решения относительно окончательного выбора конфигурации изделия.



Рисунок 2.25 "Запрос для сравнения стоимостей конфигураций"

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

Рисунок 2.26 "Запрос на получение информации о документах конфигурации"

Третий построенный запрос (Рисунок 2.27) позволяет просмотреть требования заказчика к объектам конфигурации с указанием идентификационного номера модуля и поставщика.



Рисунок 2.27 "Запрос на получение информации о требованиях к объектам конфигурации"

Также были составлены запросы (Рисунки 2.28, 2.29, 2.30), результатами которых являлись таблицы, содержащие информацию о количестве заказанных у поставщиков модулей, модулях, использующихся в сборках и сотрудниках, осуществляющих сборку соответственно.

Рисунок 2.28 "Запрос на получение информации о количестве модулей, полученных от поставщиков"

Рисунок 2.29 "Запрос на получение информации о модулях, использующихся в сборках"



Рисунок 2.30 "Запрос на получение информации о сотрудниках, осуществляющих сборку"



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

3.1 Алгоритм аудита конфигурации

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

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

Проведение аудита конфигурации начинается с планирования, которое представляет собой выбор шаблона, даты проведения аудита, ответственного лица, отвечающего за данный процесс. На данном этапе задействованы как заказчик, так и производитель. Далее аудиторами проводится функциональный и физический аудиты с помощью специализированных программных модулей, в которых заполняется протокол проверки. Такие протоколы могут состоять из списка вопросов, ответами на которые могут быть «да» или «нет». Функциональный аудит заключается в проверке соответствия фактических характеристик конфигурации требованиям заказчика, в то время как физический аудит является подтверждением соответствия документации фактической конфигурации изделия. После этого в акте проверки формируются замечания к объектам аудита. Замечания изучаются заказчиком и производителем. Поводом к изменению конфигурации может служить риск возникновения какой-либо ошибки при работе изделия. Полное представление процесса аудита конфигурации, разработанное в ARIS представлено на рисунке 3.1 и в приложении 1. Результатом проведения аудита служит отчет о выполненной проверке.

Рисунок 3.1 "Фрагмент описания бизнес-процесса "Аудит конфигурации"

3.2 Программная реализация технологии управления конфигурацией

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

Рисунок 3.2 содержит пример представления архива готовых решений для самолета Ил-96 в виде иерархии. Данное представление позволяет получить информацию об объектах конфигурации разных уровней. Для некоторых объектов конфигурации могут быть представлены варианты решений (на данном рисунке - различные типы влагоотделителей системы кондиционирования), которые являются взаимозаменяемыми.

Рисунок 3.2 "Пример архива готовых решений"

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

Рисунок 3.3 "Пример архива готовых проектов"

В случае если клиента устраивает такая конфигурация изделия, то производителю остается сделать еще один экземпляр по уже имеющимся чертежам.

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

Рисунок 3.4 "Пример описания требований заказчика"

На рисунке ниже (Рисунок 3.5) показан пример структуры дерева требований для ФБК самолета Як-52. В корне иерархии находится изделие, к которому предъявляются требования, а на ветвях - непосредственно сами требования. Структура обозначения требования следующая: «Номер по порядку: Номер изделия. Номер требования Описание требования: Тип требования».

Рисунок 3.5 "Пример структуры дерева требований"

Также можно просмотреть информацию о том, какие статусы присвоены требованиям и проекту в целом. В виде иерархии представлен пример проработки и утверждения дерева требований заказчика (Рисунок 3.6). Здесь каждому из требований присвоен статус, характеризующий возможность выполнения данного требования. Если требование выполнимо, то указывается и объект конфигурации, использование которого позволяет требование выполнить. В конце иерархии находятся статусы конфигурации, которые относятся к изделию целиком - их могут присваивать менеджеры конфигурации, конструкторы и инженеры высших уровней и согласовывать заказчики.

Рисунок 3.6 "Пример проработки и утверждения дерева требований заказчика"

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

Результаты данных запросов в табличном виде представлены ниже (Рисунок 3.7, Рисунок 3.8, Рисунок 3.9).

Рисунок 3.7 "Результат запроса на сравнение стоимостей изделия"

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

Рисунок 3.8 "Результат запроса на получение информации о документах конфигурации"

Рисунок 3.9 "Результат запроса на получение информации о требованиях к объектам конфигурации"

В каждом документе конфигурации можно просматривать информацию о составе конфигурации, количестве необходимых дополнительных модулей, требованиях к ОК (Рисунок 3.10):

Рисунок 3.10 "Информация о конфигурации"

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

Рисунок 3.11 "Результат запроса о количестве заказанных у поставщиков модулей"

Также были разработаны запросы о модулях, использующихся в различных сборках и о сотрудниках, осуществляющих сборку. Результаты выполнения этих запросов представлены на рисунках 3.12 и 3.13:

Рисунок 3.12 "Результат запроса о модулях, использующихся в сборках"

Рисунок 3.13 "Результат запроса о сотрудниках, осуществляющих сборку"



Заключение

Таким образом, технология управления конфигурацией является эффективным инструментом в вопросах установления и поддержания соответствия между эксплуатационными, функциональными и физическими характеристиками продукта и заданными требованиями на всех стадиях ЖЦ изделия. Использование УК на производстве, на мой взгляд, может являться конкурентным преимуществом на рынке высокотехнологичных изделий с учетом того, что с каждым днем производимые продукты становятся более сложными.

В рамках выполнения дипломной работы:

· рассмотрены управленческие технологии, используемые для поддержки сложных технических изделий на этапах жизненного цикла;

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

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

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

· создано прикладное программное средство.

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

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

В качестве перспектив работы хотелось бы рассмотреть осуществление взаимодействия с системой поддержки принятия решений.

Список использованных источников

1. Ali U., Kidd C. Configuration management process capabilities //Procedia CIRP. - 2013. - Т. 11. - С. 169-172.

2. Lindkvist C., Stasis A., Whyte J. Configuration management in complex engineering projects //Procedia CIRP. - 2013. - Т. 11. - С. 173-176.

3. Mьller P. Configuration Management-A Core Competence for Successful through-life Systems Engineering and Engineering Services //Procedia CIRP. - 2013. - Т. 11. - С. 187-192.

4. PDM Step Suite: техническое описание. Версия 2.1 // http://pss.cals.ru/ URL: http://pss.cals.ru/DOC/PSS_TD_2_1.pdf (дата обращения: 15.02.2016).

5. Whyte J., Stasis A., Lindkvist C. Managing change in the delivery of complex projects: Configuration management, asset information and `big data' //International Journal of Project Management. - 2016. - Т. 34. - №. 2. - С. 339-351.

6. Xu Y., Malisetty M. K., Round M. Configuration management in aerospace industry //Procedia CIRP. - 2013. - Т. 11. - С. 183-186.

7. Бессарабов А. М., Афанасьев А. Н. CALS-технологии при проектировании перспективных химических производств //Химическая технология. - 2002. - Т. 3. - №. 3. - С. 26-30.

8. Долгих, Э. А. Основы применения CALS-технологий в электронном приборостроении. Версия 1.0 [Электронный ресурс] : электрон. учеб. пособие / Э. А. Долгих, А. В. Сарафанов, С. И. Трегубов. - Электрон. дан. (4 Мб). - Красноярск : ИПК СФУ, 2008.

9. Концепция развития ИПИ-технологий для продукции военного назначения, поставляемой на экспорт / А.А. Суханов, О.Н. Рязанцев, С.А. Артизов, А.Н. Бриндиков, Н.И. Незаленов, А.В. Карташев, П.М. Елизаров, Е.В. Судов - М.: НИЦ CALS «Прикладная логистика», 2013.

10. Левин А., Судов Е. CALS-сопровождение жизненного цикла //Открытые системы. СУБД. - 2001. - №. 3. - С. 58-62.

11. Левин А.И., Судов К.В. Концептуальные основы управления конкурентоспособностью наукоемкой продукции. Методический материал: М.: НИЦ CALS-технологий «Прикладная логистика», 2005. - 33 с.

12. Норенков И.П., Кузьмик П.К. Информационная поддержка наукоемких изделий. CALS-технологии // М. : Изд. МГТУ им. Н.Э. Баумана, 2002. - 320 с.

13. Погосян М. А., Савельевских Е. П., Тарасов Ю. М. Технология управления данными об изделии в течение его жизненного цикла. Российская энциклопедия CALS. Авиационно-космическое машиностроение. НИЦ АСК //Москва. - 2008.

14. Погорелов В.И. Система и её жизненный цикл: введение в CALS-технологии: учебное пособие. - СПб.: Балт. гос. техн. ун-т., 2010.

15. Система разработки и постановки продукции на производство. Терминология. Справочник. - М.: Изд. Стандартов, 1985

16. Стародубов В. Управление конфигурацией: задачи, стандарты и реализация. - CAD/CAM/CAE Observer, 2006. - №. 4. - С. 28.

17. Судов Е.В. Модели, методы и средства управления и интегрированной информационной поддержки процессов жизненного цикла наукоемкой продукции: Диссертация на соискание ученой степени доктора технических наук. - М. - 2004.

18. Судов Е. В. и др. Концепция развития CALS-технологий в промышленности России //М.: НИЦ CALS-технологий «Прикладная логистика. - 2002. - Т. 28. - С. 1.

19. Суханов А. А. и др. Концепция развития ИПИ-технологий для продукции военного назначения, поставляемой на экспорт //М.: НИЦ CALS «Прикладная логистика. - 2013.

20. Яцкевич А. И., Дещеревский И. В. Технология представления информации об изделии. Система управления конструкторскими данными о машиностроительном изделии //Информационные технологии в проектировании и производстве: Науч.-техн. журн. М.: ГУП «ВИМИ. - 2000. - №. 2. - С. 13-18.

21. http://cals.ru/ (дата обращения: 12.03.2016)

22. Использование CALS-технологий в менеджменте качества // http://fh.kubstu.ru/juk/ URL: http://fh.kubstu.ru/juk/issues/issue01/st0112.pdf (дата обращения: 15.02.2016).



Приложения

Приложение 1

Алгоритм аудита конфигурации



Приложение 2

Запрос на создание базы данных

CREATE TABLE Документ_конфигурации

( ИН_ДК smallint NOT NULL ,

Дата_создания datetime NULL ,

Вложение char(30) NULL ,

ИН_Ст smallint NOT NULL ,

ИН_Сотр smallint NOT NULL )

go

ALTER TABLE Документ_конфигурации

ADD CONSTRAINT XPKДокумент_конфигурации PRIMARY KEY CLUSTERED (ИН_ДК ASC)

go

CREATE TABLE Изделие

( ИН_Изд smallint NOT NULL ,

Название char(30) NULL ,

Цена float NULL ,

Описание char(100) NULL ,

ИН_Ст smallint NOT NULL )

go

ALTER TABLE Изделие

ADD CONSTRAINT XPKИзделие PRIMARY KEY CLUSTERED (ИН_Изд ASC)

go

CREATE TABLE Модуль

( ИН_Мод smallint NOT NULL ,

Название char(30) NULL ,

Цена float NULL )

go

ALTER TABLE Модуль

ADD CONSTRAINT XPKМодуль PRIMARY KEY CLUSTERED (ИН_Мод ASC)

go

CREATE TABLE Модуль_Сборка

( ИН_Мод smallint NOT NULL ,

ИН_Сбор smallint NOT NULL ,

Количество smallint NULL )

go

ALTER TABLE Модуль_Сборка

ADD CONSTRAINT XPKМодуль_Сборка PRIMARY KEY CLUSTERED (ИН_Мод ASC,ИН_Сбор ASC)

go

CREATE TABLE Отдел

( ИН_О smallint NOT NULL ,

Название char(30) NULL )

go

ALTER TABLE Отдел

ADD CONSTRAINT XPKОтдел PRIMARY KEY CLUSTERED (ИН_О ASC)

go

CREATE TABLE Поставщик

( ИН_Пост smallint NOT NULL ,

Название char(30) NULL )

go

ALTER TABLE Поставщик

ADD CONSTRAINT XPKПоставщик PRIMARY KEY CLUSTERED (ИН_Пост ASC)

go

CREATE TABLE Поставщик_Модуль

( ИН_Пост smallint NOT NULL ,

ИН_Мод smallint NOT NULL ,

Количество smallint NULL )

go

ALTER TABLE Поставщик_Модуль

ADD CONSTRAINT XPKПоставщик_Модуль PRIMARY KEY CLUSTERED (ИН_Пост ASC,ИН_Мод ASC)

go

CREATE TABLE Сборка

( ИН_Сбор smallint NOT NULL ,

ИН_Изд smallint NOT NULL ,

ИН_Сотр smallint NOT NULL ,

ИН_ДК smallint NOT NULL )

go

ALTER TABLE Сборка

ADD CONSTRAINT XPKСборка PRIMARY KEY CLUSTERED (ИН_Сбор ASC)

go

CREATE TABLE Сотрудник

( ИН_Сотр smallint NOT NULL ,

Фамилия char(20) NULL ,

Имя char(20) NULL ,

Отчество char(20) NULL ,

Должность char(30) NULL ,

ИН_О smallint NOT NULL )

go

ALTER TABLE Сотрудник

ADD CONSTRAINT XPKСотрудник PRIMARY KEY CLUSTERED (ИН_Сотр ASC)

go

CREATE TABLE Статус

( ИН_Ст smallint NOT NULL ,

Описание char(30) NULL )

go

ALTER TABLE Статус

ADD CONSTRAINT XPKСтатус PRIMARY KEY CLUSTERED (ИН_Ст ASC)

go

CREATE TABLE Требование

( ИН_Тр smallint NOT NULL ,

ИН_Мод smallint NOT NULL ,

Описание char(50) NULL )

go

ALTER TABLE Требование

ADD CONSTRAINT XPKТребование PRIMARY KEY CLUSTERED (ИН_Тр ASC)

go

ALTER TABLE Документ_конфигурации

ADD CONSTRAINT R_6 FOREIGN KEY (ИН_Ст) REFERENCES Статус(ИН_Ст)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

ALTER TABLE Документ_конфигурации

ADD CONSTRAINT R_18 FOREIGN KEY (ИН_Сотр) REFERENCES Сотрудник(ИН_Сотр)

ON DELETE NO ACTION

ON UPDATE NO ACTION

Go

ALTER TABLE Изделие

ADD CONSTRAINT R_19 FOREIGN KEY (ИН_Ст) REFERENCES Статус(ИН_Ст)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

ALTER TABLE Модуль_Сборка

ADD CONSTRAINT R_4 FOREIGN KEY (ИН_Мод) REFERENCES Модуль(ИН_Мод)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

ALTER TABLE Модуль_Сборка

ADD CONSTRAINT R_13 FOREIGN KEY (ИН_Сбор) REFERENCES Сборка(ИН_Сбор)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

ALTER TABLE Поставщик_Модуль

ADD CONSTRAINT R_1 FOREIGN KEY (ИН_Пост) REFERENCES Поставщик(ИН_Пост)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

ALTER TABLE Поставщик_Модуль

ADD CONSTRAINT R_11 FOREIGN KEY (ИН_Мод) REFERENCES Модуль(ИН_Мод)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

ALTER TABLE Сборка

ADD CONSTRAINT R_3 FOREIGN KEY (ИН_Изд) REFERENCES Изделие(ИН_Изд)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

ALTER TABLE Сборка

ADD CONSTRAINT R_5 FOREIGN KEY (ИН_Сотр) REFERENCES Сотрудник(ИН_Сотр)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

ALTER TABLE Сборка

ADD CONSTRAINT R_7 FOREIGN KEY (ИН_ДК) REFERENCES Документ_конфигурации(ИН_ДК)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

ALTER TABLE Сотрудник

ADD CONSTRAINT R_14 FOREIGN KEY (ИН_О) REFERENCES Отдел(ИН_О)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

ALTER TABLE Требование

ADD CONSTRAINT R_2 FOREIGN KEY (ИН_Мод) REFERENCES Модуль(ИН_Мод)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

Размещено на Allbest.ru

...