Design of the database structure for software optimization of operation of the stochastic multiphase systems

Selishchev Ivan Alekseevich Postgraduate student, the department of Automated Computational Systems, Voronezh State Technical University 394068, Russia, Voronezhskaya oblast', g. Voronezh, ul. Moskovskii Prospekt, 14 selishcheviv@gmail.com Other publications by this author

Oleinikova Svetlana Aleksandrovna Doctor of Technical Science Professor, Voronezh State Technical University 394026, Russia, Voronezhskaya oblast', g. Voronezh, ul. Moskovskii Prospekt, 14 s.a.oleynikova@gmail.com Other publications by this author

Введение

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

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

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

1. Постановка задачи

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

Рис. 1 – Схематическое представление обслуживающей системы

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

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

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

2. Требования, предъявляемые к проектируемой базе данных

Специфика рассматриваемой задачи накладывает ряд требований, к проектируемой базе данных, а именно:

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

− быть универсальной с точки зрения минимизации коррекций при внедрении в конкретную практическую сферу деятельности;

− возможность обращаться к данным не только для решения заранее предопределенных задач, но и с нерегламентированными запросами;

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

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

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

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

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

3. Выбор модели данных

Главный вопрос, возникающий при выборе базы данных, заключается в выборе реляционной (SQL) или не реляционной (NoSQL) структуры данных. От данных моделей напрямую зависит то, как программное средство будет взаимодействовать с информацией.

Реляционные базы данных, являются наиболее распространенной, широко используемой и проверенной технологией. Термин реляционный (от англ. Relations – отношение, связь) несет под собой математические корни, а именно теорию множеств и логику первого порядка, на которых и базируется реляционная модель. Отношения позволяют группировать данные как связанные между собой наборы, представленные в виде таблиц с содержащейся в них упорядоченной информацией. В качестве основных преимуществ использования SQL баз данных можно выделить следующее:

− соответствие баз данных требованиям ACID (Atomicity, Consistency, Isolation, Durability – атомарность, непротиворечивость, изолированность, долговечность). Данные требования позволяют свести к минимум неожиданное поведение системы и обеспечить целостность данных, путем жесткого определения того, как именно транзакция взаимодействует с базой данных;

− реляционные базы данных требуют наличия строго определённой структуры хранения данных, что является несомненным плюсом для крупных систем, структура которых известна и не подвержена частым изменениям;

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

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

− предполагается хранение больших объемов неструктурированной информации;

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

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

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

4. Структура базы данных

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

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

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

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

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

Концептуальная модель предполагает наличие связей между объектами разных классов. Связь представляет собой ассоциацию между сущностями, где каждый экземпляр одной сущности, ассоциирован с произвольным количеством экземпляров другой сущности. Выделяют несколько типов связей – «один к одному (1:1)», «один ко многим (1:n)», «многие ко многим (n:n)». Для удобства идентификации связи в ER – модели принято указывать «класс принадлежности», характеризующий обязательность связи.

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

− проект – данный объект предназначен для хранения информации о проекте (проектах), время начала проекта, плановое и актуальное время окончания;

− работа – данный объект содержит информацию о работах проекта, а также их длительность;

− связь – данный объект содержит последовательность работ проекта, вида: текущая работа – предшествующая работа;

− ресурс – данный объект представляет собой справочник, содержащий ресурсы, требуемые для выполнения работ;

− ресурс для выполнения работы – данный объект ставит в соответствие каждой работе проекта ресурс для ее выполнения, а также его количество.

− график работ – данный объект содержит плановое и актуальное время начала и завершения работ;

− коррекция – данный объект предназначен для ведения учета коррекции времени работ, а также указания причины коррекции и ее описания.

− причина – данный объект является справочником, в котором содержатся основные возможные причины коррекции графика работ.

Был определен набор предполагаемых отношений, связывающих данные объекты. Предполагается, что один проект содержит в себе n – ое количество работ, следовательно, отношение «Проект-Работа» характеризуется видом связи «один ко многим». Последовательность работ проекта задается классом объектов «Связь» и содержит в себе перечь работ проекта, а также предшествующие им, поэтому в данном случае отношение «Связь-Работа» будет иметь вид «один ко многим». Список работ и назначенных на их выполнение ресурсов содержится в классе «Ресурс для выполнения работы», предполагается, что работы могут иметь несколько ресурсов, поэтому связь «Работа-Ресурс для выполнения работы» будет иметь вид «один ко многим». Один ресурс может быть назначен нескольким работам, вследствие чего отношение «Ресурс-Ресурс для выполнения работы» будет иметь вид «один ко многим». Изменения в расписании работ могут иметь множественный характер, поэтому отношение «Работа-График работ» будет иметь вид «один ко многим». Проведение изменений в графике работ должно учитываться в классе «Коррекция» с указанием причины изменений, вследствие чего отношение «График работ-Коррекция» - «один ко многим», а отношение «Коррекция-Причина» так же - «один ко многим».

Рис. 2 – Концептуальная модель базы данных

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

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

Рис. 3 – Логическая модель данных

4.3 Физическое проектирование

Физическое проектирование подразумевает создание модели данных с учетом требований, накладываемых выбранной СУБД. Выбранная СУБД может накладывать ряд ограничений, таких как особую стилистику именования объектов базы данных, ограничения поддерживаемых типов данных и т.д. Результатом физического проектирования является SQL скрипт, на основе которого генерируется итоговая база данных.

Рис. 4 – Физическая модель базы данных

Обоснование выбора СУБД

В ходе разработки предполагаемой программной системы в качестве СУБД была выбрана MySQL. MySQL, представляет собой свободно распространяемую СУБД с открытым исходным кодом, что позволяет не только использовать ее базовую версию, но и при необходимости изучать и свободно изменять. MySQL поддерживает язык запросов SQL и может применяться в качестве SQL-сервера. Основное взаимодействие с сервером осуществляется на языке SQL, путем запросов от сервера клиента, что позволяет производить большую часть манипуляций с данными непосредственно в СУБД. К достоинствам MySQL часто относят быстроту, простоту и надежность, за счет чего данная СУБД хорошо себя зарекомендовала в качестве источника данных для Web-приложений. Быстродействие MySQL достигается благодаря внутреннему механизму многопоточности.

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

5. Применение полученных результатов

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

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

Рис. 5 – Перечень работ по строительству дома в БД

В качестве ресурсов имеется возможность использовать как материальные (материалы для строительства, т.е. цемент, кирпич и др.), так и человеческие (рабочие). В данном случае в качестве ресурсов использовались рабочие, что представлено на рис. 6.

Рис. 6. – Перечень работ и назначенных на них рабочих в БД

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

Рис. 7. – Перечень работ по разработке ПО в БД

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

Рис.8. – Перечень работ и назначенных на них рабочих в БД

Выводы

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

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

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