Единая информационная система поддержки производства кольцевых лазеров

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

ОАО НИИ «Полюс» им. М.Ф. Стельмаха; МИЭМ НИУ ВШЭ

Единая информационная система поддержки производства кольцевых лазеров

НовиковС.С., ПотаповаТ.А.,

СавельевИ.И., ХлебниковП.А.

Аннотация

информационный лазер проектирование связь

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

Ключевые слова: реляционная модель, СУБД, сущность, атрибут, нормализация, ссылочная целостность

Annotation

Integrated Information support system in ring laser productions. Novikov S., Potapova T., Savel'ev I., Khlebnikov P.

Issues on the stages of designing a unified information system support of the laser productions, in turn, a new entity-relationship model is developed, using CALS - and CASE - technologies.

Key words: Entity - Relationship model,DBMS (database management system), object, attribute, db normalization, referential integrity

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

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

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

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

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

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

Проектирование информационной системы

Проектирование информационной системы включает в себя создание проекта базы данных, предназначенной для поддержки функционирования предприятия. Этот этап охватывает концептуальное, логическое и физическое проектирование базы данных. Однако, этап физического проектирования выходит за рамки данного доклада и может рассматриваться в контекстеотдельно выбранной работы.[1]

Концептуальное проектирование

Концептуальное проектирование информационной системы можно разделить на ряд этапов:

1.Определение типов сущностей.

2.Определение типов связей.

3.Определение атрибутов и их доменов.

4.Определение атрибутов, являющихся потенциальными и первичными ключами.

5.Проверка модели на отсутствие избыточности.

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

Этап 1. Определение типов сущностей

Тип сущности (entitytype) является основной концепцией ER-модели. Он представляет собой группу объектов реального мира, обладающих одинаковыми свойствами.

На данном этапе каждой сущности присваивается определенное осмысленное имя, которое помещается в словарь данных. Для большей наглядности в словаре данных выделены участки производства датчика лазерного гироскопа (таблица 1).

Таблица 1. Фрагмент словаря данных, содержащий описаниесущностей

Этап 2. Определение типов связей

На этом этапе определяются типы связей сущностей, а также накладываются ограничения кратности. Способы представления ограничений кратности представлены в таблице 2, фрагмент словаря данных, содержащий описание связей в таблице 3.

Таблица 2. Способы представления ограничений кратности

Таблица 3. Фрагмент словаря данных, содержащий описание связей

Выявленные типы сущностей и связей позволяют создать первую версию ER-диаграммы, изображенную на рисунке 1.

При разработке концептуальной модели данных могут возникнуть проблемы, которые принято называть дефектами соединения (connectiontrap). Существуют два основных типа дефектов соединения: дефект типа «разветвление» и дефект типа «разрыв». При недостаточном понимании сути установленных связей может быть создана модель, не отвечающая истинным представлениям реального мира. Представленная модель была проанализирована на наличие дефектов соединения, единственный найденный дефект был устранен [2].

Рис. 1. ER-модель

Этап 3. Определение атрибутов и их доменов

Основные атрибуты выявленных сущностей, относящихся к корпусу и ножке резонатора, представлены в таблице 4. Для краткости часть атрибутов, являющихся набором параметров элемента, объединены в составной атрибут «parameters». Все части этого атрибута равнозначны между собой относительно представленной модели данных, поэтому такой подход не влияет на наглядность.

Этап 4. Определение атрибутов, являющих потенциальными ипервичными ключами

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

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

Для выбора первичного ключа были сформулированы ряд критериев:

§ ПК должен быть с минимальным набором атрибутов.

§ Вероятность изменения значений ПК должна быть минимальной (что особенно важно в условиях изменяющегося технологического процесса НИИ «Полюс»).

§ ПК должен иметь минимальную длину.

§ ПК должен обеспечивать простоту работы с точки зрения пользователей.

Этап 5. Проверка модели на отсутствие избыточности

На этом этапе концептуальная модель данных анализируется на наличие избыточности данных. Для этого выполняются следующие операции:

1. Повторное исследование связей «один к одному» (1:1).

Рис. 2. ER-модель единой информационной системы

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

2. Удаление избыточных связей.

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

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

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

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

Рассмотрим пример транзакции. Необходимо просмотреть историю прохождения ТО корпусом и ножкой, установленной в конкретном резонаторе. Сведения о прохождении корпусом ТО содержаться в сущности BodyLegend, а ножки в сущности StemLegend. Номер резонатора, а так же номер использованных в нем элементов содержится в сущности Resonator. Таким образом, будут использованы связи Body (0…1) Resonator (1…1) и BodyMap (1…1) Body (0…1) для нахождения истории корпуса, Disk (0…1) Resonator (1…1) и StemLegend (1…1) Disk (0…1) для нахождения истории ножки. Графическое представление этой транзакции можно увидеть на рисунке 1 красным цветом.

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

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

Логическое проектирование

Логическое проектирование информационной системы можно разделить на ряд этапов:

1. Исключение особенностей, несовместимых с реляционной моделью.

2. Определение набора отношений.

3. Проверка отношений с помощью правил нормализации.

4. Проверка соответствия отношений требованиям пользовательских транзакций.

5. Определение требований поддержки целостности данных. [3]

Этап 1. Исключение особенностей, несовместимых с реляционной моделью

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

§ Двухсторонние связи «многие ко многим» (*…*).

§ Рекурсивные связи «многие ко многим» (*…*).

§ Сложные связи.

§ Многозначные атрибуты.

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

Этап 2. Определение набора отношений

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

Этап 3. Проверка отношений с помощью правил нормализации

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

1. Приведение к первой нормальной форме (1НФ), позволяющее удалить из отношений повторяющиеся группы атрибутов.

Анализ отношений, полученных на этапе 2 логического проектирования, показал, что модель данных соответствует 1НФ.

2. Приведение ко второй нормальной форме (2НФ), позволяющее устранить частичную зависимость атрибутов от первичного ключа.

Ввиду того, что все первичные ключи отношений состоят из одного атрибута, можно сразу сделать вывод о соответствии модели данных 2НФ.

3. Приведение к третьей нормальной форме (3НФ), позволяющее устранить транзитивную зависимость атрибутов от первичного ключа.

В ходе анализа была выявлена транзитивная зависимость атрибута BodyMap(date_creation) - BodyMap(ID_body_map) - BodyMap(ID_body). Для устранения этого несоответствия требованиям нормализации атрибут BodyMap(ID_body_map) принимаем первичным ключом, атрибут BodyMap(ID_body) альтернативным первичным ключом, а атрибут BodyMap(manufacturer) перенесем в отношение Body. Таким образом, все отношения соответствуют 3НФ.

4. Приведение к нормальной форме Бойса-Кодда (НФБК), позволяющее удалить из функциональных зависимостей оставшиеся аномалии, связанные с потенциальными ключами.

Нормальная форма Бойса-Кодда (НФБК) - отношение, в котором каждый его детерминант (атрибут или группа атрибутов, от которой полностью функционально зависит другой атрибут) является потенциальным ключом. [4]

Отношения, полученные на предыдущих этапах нормализации, соответствуют этому условию.

Таким образом, логическая модель данных полностью отвечает требованиям НФБК, а, следовательно, верна и правильно преобразована в набор отношений.

Этап 4. Проверка соответствия отношений требованиям пользовательских транзакций

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

Этап 5.Определение требований поддержки целостности данных

На данном этапе определены требования поддержки целостности данных. Существует пять основных типов ограничения целостности данных:

1. Обязательные данные (атрибуты не могут иметь пустых значений)

2. Ограничения для доменов атрибутов.

Каждый атрибут имеет домен, представляющий собой набор его допустимых значений. Данные ограничения устанавливаются при определении доменов.

3. Целостность сущностей.

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

4. Ссылочная целостность.

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

Удаление строки из родительского отношения запрещается, если в дочернем отношении существует хотя бы одна ссылающаяся на нее строка (NO ACTION).

При обновлении первичного ключа в строке родительского отношения обновить строки, ссылающиеся на исходное значение первичного ключа в дочерних отношениях (CASCADE).

5. Ограничения предметной области.

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

Разработанная логическая модель данных полностью прошла все этапы проектирования. С помощью правил нормализации была проверена правильность ее структуры, предложены методы поддержания целостности данных и выполнены необходимые пользовательские транзакции. Это позволяет говорить о том, что полученная модель данных полная, точная и соответствует структуре данных в организации. Окончательный вид ER-модели, построенный при помощи CASE - инструмента MySQLWorkbench, представлен на рисунке 2.

Заключение

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

Список литературы

1. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. Пер. с англ. Имамутдиновой Р.Г., Птицына К.А. / Под ред. Птицына К.А. М.: Издательский дом «Вильямс». 2003. 1440 с.

2. Дейт К. Дж. Введение в системы баз данных, 8-е издание. Пер. с англ. Птицына К.А. / Под ред. Птицына К.А. М.: Издательский дом «Вильямс». 2005. 1328 с.

3. Хлебников П.А. Разработка базы данных комплекта зеркал лазерного резонатора // Дипломная работа. М.: МИЭМ. 2010.

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

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