Выпуск № 3 (37), 2020

УДК

DOI

Используйте это описание для цитирования: 

Cite this article as:

Быстренина И.Е., Сычева И.Н. Использование CASE-средства Open ModelSphere для решения задач анализа и проектирования информационных систем // Управление рисками в АПК. 2020. № 3. С. 14-21. URL: http://www.agrorisk.ru/pub/202003

СЕЛЬСКОХОЗЯЙСТВЕННЫЕ НАУКИ
БЫСТРЕНИНА И.Е., СЫЧЕВА И.Н.

ИСПОЛЬЗОВАНИЕ CASE-СРЕДСТВА OPEN MODELSPHERE ДЛЯ РЕШЕНИЯ ЗАДАЧ АНАЛИЗА И ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

Быстренина Ирина Евгеньевна – кандидат педагогических наук, доцент, Институт экономики и управления АПК, ФГБОУ ВО «РГАУ – МСХА имени К.А. Тимирязева», Москва, Россия.
E-mail: iesh@rambler.ru
SPIN-код: 9522-2008

Сычева Ирина Николаевна – кандидат сельскохозяйственных наук, доцент, кафедра частной зоотехнии, Факультет зоотехнии и биологии, ФГБОУ ВО «РГАУ – МСХА имени К.А. Тимирязева», Москва, Россия.
E-mail: in_sychewa@mail.ru
SPIN-код: 7049-6721

Аннотация

В статье рассматриваются возможности современных инструментальных средств анализа и проектирования информационных систем, в частности, CASE-средств проектирования баз данных. Представлено программное средство Open ModelSphere, которое содержит инструменты для построения ER-диаграмм, редакторы для создания концептуального, логического и физического описания модели данных, поддержки ведущих реляционных СУБД. CASE-средства позволяют выполнять как прямое, так и обратное проектирование базы данных, т.е. на основании системного каталога базы или DDL-скрипта построить физическую и, далее, логическую схему данных. CASE-средства обычно поддерживают синхронизацию между схемой и системным каталогом базы данных, т.е. при изменении схемы они могут автоматически внести все необходимые изменения в существующую базу данных и наоборот. Представленные подходы используются для подготовки бакалавров РГАУ-МСХА имени К.А.Тимирязева в рамках дисциплин по проектированию информационных систем для нужд предприятий АПК.

Ключевые слова

Информационная система, анализ и проектирование информационных систем, подсистема хранения, CASE-средства, IDEF1X, СУБД.

Annotation

Keywords

Текст статьи

Как показывает практика, использование информационных систем в АПК позволяет ему значительно лучше организовать учет информации, наиболее правильно подобрать экономически выгодные средства для выполнения каждой работы и в конечном счете снизить затраты труда и материально-денежные затраты на единицу работы [1, 2, 3, 4, 7].
Данная особенность характерна и для проектирования и разработки информационных систем, ориентированных на решение задач АПК. Обычно выделяют такие этапы создания систем, как формирование требований к системе, проектирование, реализация, тестирование, ввод в действие, эксплуатация и сопровождение.

Максимально упростить и формализовать процессы формирования требований и проектирования информационной системы позволяют современные CASE-средства, которые реализуют CASE-технологию создания и сопровождения информационных систем [5]. Основными функциями CASE-средств являются: централизованное хранение в единой базе данных проекта (репозитарии) информации об информационной системе в течение всего жизненного цикла системы; прямое проектирование программного обеспечения и баз данных; обратное проектирование (реинжиниринг) системы; синхронизация моделей системы с ее физической реализацией; автоматическое обеспечение качества и тестирование моделей на наличие ошибок, полноту и непротиворечивость; автоматическое составление документации [6, 8, 9, 10].

Согласно структурному подходу к анализу и проектированию информационных систем выделяют следующие этапы: разработка функциональной модели, разработка информационной модели, разработка поведенческих моделей, разработка моделей компонентов и развертывания. Разработанная функциональная модель системы отвечает на вопросы «Что должна делать система?» и «За счет каких действий может быть достигнут требуемый результат?». Эта модель также позволяет концептуально определить наборы данных, используемых в системе. В то же время она не отвечает на вопрос: «Каким образом организованы данные в системе?». Для ответа на него необходимо построить информационную модель – спроектировать базу данных системы.
Традиционно процедуру проектирования базы данных разбивают на три этапа, каждый из которых завершается созданием соответствующей информационной модели. Это концептуальное проектирование, логическое проектирование, физическое проектирование.



press to zoom

press to zoom
1/1


В настоящее время для проектирования БД активно используются CASE-средства, в основном ориентированные на использование ERD (Entity – Relationship Diagrams, диаграммы «сущность–связь»). С их помощью определяются важные для предметной области объекты (сущности), отношения друг с другом (связи) и их свойства (атрибуты). Следует отметить, что средства проектирования ERD в основном ориентированы на реляционные базы данных, и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы проектирования.

ERD были впервые предложены П. Ченом в 1976 г. Основными элементами ERD являются сущность, экземпляр сущности, связь, атрибут. Большинство современных CASE-средств моделирования данных, как правило, поддерживает несколько графических нотаций построения информационных моделей. В частности система ERwin фирмы Computer Associates поддерживает две нотации: IDEF1X и IE (англ. Information Engineering – информационное проектирование). Данные нотации являются взаимно-однозначными, т.е. переход от одной нотации к другой и обратно выполняется без потери качества модели. Отличие между ними заключается лишь в форме отображения элементов модели.

При использовании любого CASE-средства вначале строится логическая схема базы данных в виде диаграммы с указанием сущностей и связей между ними. Логической схемой называется универсальное описание структуры данных, независимое от конечной реализации базы данных и аппаратной платформы. На основании полученной логической схемы переходят к физической схеме данных. Физическая схема представляет собой диаграмму, содержащую всю необходимую информацию для генерации БД для конкретной СУБД (системы управления базами данных) или даже конкретной версии СУБД. Если в логической схеме не имеет значения, какие идентификаторы носят таблицы и атрибуты, тип данных атрибутов и т. д., то в физической схеме должно быть полное описание базы данных в соответствии с принятым в ней синтаксисом, с указанием типов атрибутов, триггеров, хранимых процедур и т.д. По одной и той же логической схеме можно создать несколько физических. Например, ERwin позволяет на основании логической схемы сформировать физические более, чем для 10 промышленных СУБД (ORACLE, MySQL, DB2, MS SQL Server и др.) и их различный версий. На основании физической схемы можно сгенерировать либо саму базу данных или DDL-скрипт, который, в свою очередь, может быть использован для генерации базы данных.

Перечисленный выше порядок действий называется прямое проектирование базы данных (Forward Engineering DB). CASE-средства позволяют выполнять также обратное проектирование базы данных (Reverse Engineering DB), т.е. на основании системного каталога базы данных или DDL-скрипта построить физическую и, далее, логическую схему данных. Кроме режимов прямого и обратного проектирования, CASE-средства обычно поддерживают синхронизацию между схемой и системным каталогом базы данных, т.е. при изменении схемы они могут автоматически внести все необходимые изменения в существующую базы данных и наоборот.

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

press to zoom

press to zoom
1/1

В данной статье рассмотрены особенности прямого проектирования базы данных на примере инструментального средства автоматизации проектирования с открытым доступом Open ModelSphere, разработанное фирмой Grandite. Оно поддерживает графический интерфейс Windows, включает инструменты для построения ER-диаграмм, редакторы для создания концептуального, логического и физического описания модели данных и поддерживает ведущие реляционные СУБД. Процесс моделирования в Open ModelSphere базируется на методологии проектирования реляционных баз данных IDEF1X, которая определяет стандарты терминологии и графического изображения типовых элементов на ER-диаграммах.

Open ModelSphere имеет три уровня представления модели – концептуальный, логический и физический. Концептуальная модель данных отображает обобщающее представление о данных предметной области, не зависящее от типа выбранной СУБД; она содержит условные обозначения и описания свойств сущностей, их атрибутов и связей. Такая модель должна обеспечивать полное представление требований к данным со стороны конечных пользователей.
Разработка концептуальной модели включает в себя следующие операции:
1) создание раздела «Концептуальная модель» заданного проекта в Open ModelSphere;
2) создание сущностей;
3) определение атрибутов каждой сущности;
4) определение первичных ключей;
5) определение связей между сущностями.
Рассмотрим проектирование подсистемы хранения сервиса «Учет нагрузки учителей в школе». На рисунке 1 представлена концептуальная модель подсистемы хранения. Она включает четыре сущности: Учителя, Классы, Предметы, Нагрузка. Также на рисунке 1 можно увидеть связи и атрибуты сущностей.

1/1


Логическая модель данных – это модель данных логического уровня, не привязанная ни к какой конкретной СУБД. Логическая модель данных разрабатываемого сервиса представлена на рисунке 2. Из модели видно, что в сущности Учителя присутствует множественные атрибуты Телефон, Образование, Ступень обучения, Категории. Так учитель может иметь несколько телефонных номеров, что является нарушением первой нормальной формы, согласно которой все значения атрибутов должны быть атомарными. Это же требование необходимо учесть и к остальным атрибутам. Поэтому необходимо выделить атрибуты Телефон, Образование, Ступень обучения, Категории в отдельную сущность.

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

При проверке целостности модели командой Tools – Data Model – Verify Integrity (Сервис – Модель данных – Проверить целостность) будет выведено сообщение об ошибках целостности и предупреждения и предложены возможные решения возникших проблем в отчете «Проверка целостности». Согласно отчету о проверке целостности, в созданной логической модели отсутствуют правила поддержки ссылочной целостности (правила изменения) для всех ролей модели. Поэтому необходимо для каждой роли определить «Правило изменения». И после выполнения указанных действий будет выполняться условие целостности реляционной модели данных.

1/0

Физическая модель данных строится на основе логической с учетом ограничений, накладываемых возможностями выбранной СУБД, например, MS SQL Server, MS Access. Физические имена сущностей и атрибутов должны соответствовать возможностям СУБД, которая будет использоваться при создании информационной системы, в частности, поддерживает ли СУБД возможности работы с «кириллицей». Кроме того, физические имена должны быть, по возможности, короткими и иметь смысл, соответствующий их содержанию и представляемым в модели объектам (документам, справочным данным и т.п.).

Назначение физических имен можно сделать вручную или с помощью генератора физических имен системы Open ModelSphere. Однако возможности автоматической генерации физических имен довольно ограничены, генерируемые таким образом имена далеки от совершенства. Поэтому можно использовать «ручной способ». Для создания физического имени сущности нужно в окне свойств ввести в строке Physical Name нужное значение. Для каждого атрибута (столбца) следует установить тип домена, соответствующий значениям.

Если для атрибута допустимо отсутствие значения (пустое значение), то надо установить символ (v) в поле Null Possible.
После создания физических имен всех атрибутов логической модели данных, она полностью подготовлена для разработки физической модели.
Процесс создания физической модели данных включает в себя:
1) настройку на используемую СУБД;
2) создание таблиц;
3) определение типов данных в таблицах;
4) генерацию внешних ключей;
5) создание физических имен первичных и внешних ключей;
6) создание индексов для первичных и внешних ключей;
7) проверку ссылочной целостности модели;
8) создание базы данных.

1/1

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

Таким образом, инструментальное средство автоматизации проектирования с открытым доступом Open ModelSphere включает инструменты для построения ER-диаграмм, редакторы для создания концептуального, логического и физического описания модели данных и поддерживает ведущие реляционные СУБД. Все эти возможности позволяют автоматизировать основные этапы создания подсистемы хранения, представлять результаты в виде, удобном для обсуждения всеми лицами, заинтересованными в проекте.

Данный аспект анализа и проектирования информационных систем подробно рассматривается на практических занятиях дисциплины «Проектирование информационных систем» с бакалаврами направления подготовки 09.03.03 «Прикладная информатика» ФГБОУ ВО РГАУ-МСХА имени К.А. Тимирязева.

1/0

Источники:

1. Балдин К.В., Уткин В.Б. Информационные системы в экономике. 5-е изд. М.: Дашков и Ко, 2008. 395 с.
2. Быстренина И.Е. Роль информационных технологий в решении задач системы высшего профессионального образования // Социокультурные проблемы современного высшего образования: сборник научных трудов. М.: РУДН, 2019. С. 147-150.
3. Быстренина И.Е., Землянский А.А. Информационные технологии в науке и производстве: учебное пособие. М.: Изд-во РГАУ-МСХА, 2016. 128 с.
4. Быстренина И.Е., Макунина И.В., Грушко Е.С., Казначеева В.О. Информационная система организации образовательной деятельности в системе дополнительного профессионального образования. Вестник Тверского государственного университета. Серия «Экономика и управление». Тверь: Тверской государственный университет, 2017. № 3. С. 180-186.
5. Грекул В. И. Проектирование информационных систем: учебник и практикум для академического бакалавриата. М.: Издательство Юрайт, 2019. 385 с.
6. Емельянова Н.З., Партыка Т.Ф., Попов И.И. Устройство и функционирование информационных систем: учебное пособие. 2-e изд., перераб. и доп. М.: ФОРУМ, 2012. 448 с.
7. Информационные системы и технологии в управлении: учебник для студентов вузов, обучающихся по направлениям «Менеджмент» и «Экономика», специальностям «Финансы и кредит», «Бухгалтерский учет, анализ и аудит». Под ред. Г.Л.Титаренко. 3-e изд., перераб. и доп. М.: ЮНИТИ-ДАНА, 2011. 591 с.
8. Мельников В.П. Информационные технологии: учебник для студентов высших учебных заведений, обучающихся по специальностям «Автоматизированные системы обработки информации и управления», «Информационные системы и технологии». 2-е изд., стер. М.: Академия, 2009. 424 с.
9. Трофимов В. В. Информационные технологии: учебник для академического бакалавриата. М.: Издательство Юрайт, 2014. 624 с.
10. Череватова Т.Ф. Информационные потребности в системе управления развитием хозяйствующих субъектов АПК // Доклады ТСХА: материалы Международной научной конференции, посвященной 175-летию К.А. Тимирязева, Москва, 6-8 декабря 2018. 2019. С. 287−292.

References:

Все иллюстрации статьи | All visuals of paper

 Рисунок 2 – Логическая модель подсистемы хранения
Рисунок 2 – Логическая модель подсистемы хранения

press to zoom
Рисунок 1 – Концептуальная модель подсистемы хранения
Рисунок 1 – Концептуальная модель подсистемы хранения

press to zoom
 Рисунок 2 – Логическая модель подсистемы хранения
Рисунок 2 – Логическая модель подсистемы хранения

press to zoom
1/2