Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Проектирование информационно-поисковой системы "Регламенты НИУ ВШЭ-Пермь"

Проектирование информационно-поисковой системы "Регламенты НИУ ВШЭ-Пермь"

Анализ работы учебного офиса с регламентирующими документами. Моделирование бизнес-процессов TO-BE. Формулировка требований к информационной системе. Описание сущностей и связей между ними. Проектирование базы данных и пользовательского интерфейса.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 21.09.2018
Размер файла 2,6 M
рефераты на заказ со скидкой

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Страница:

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

Пермский филиал федерального государственного автономного

образовательного учреждения высшего образования

«Национальный исследовательский университет

«Высшая школа экономики»

Факультет экономики, менеджмента и бизнес-информатики

Выпускная квалификационная работа

Проектирование информационно-поисковой системы «Регламенты НИУ ВШЭ - Пермь»

по направлению подготовки 38.03.05 Бизнес-информатика

образовательная программа «Бизнес-информатика»

Юрчак Алексей Романович

Пермь 2018 г.

Оглавление

  • Введение
  • Глава 1. Анализ деятельности учебного офиса в части работы с регламентами
    • 1.1 Анализ работы учебного офиса с регламентирующими документами
    • 1.2 Разработка модели процесса AS-IS
  • Глава 2. Проектирование информационной системы
    • 2.1 Разработка модели процесса TO-BE
  • 2.2 Формулировка требований к информационной системе
  • 2.3 Проектирование базы данных
    • 2.4 Проектирование прототипа пользовательского интерфейса
  • Заключение
  • Библиографический список
  • Приложение

Введение

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

В НИУ ВШЭ, например, таким сводом правил является набор утвержденных регламентирующих документов. Они определяют порядок проведения внутренних мероприятий, выступают в качестве руководства для принятия решений.

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

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

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

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

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

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

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

Несмотря на то, что проблема регламентных несоответствий широко распространена и касается многих предприятий, подобные ситуации возникают и при организации учебного процесса Высшей Школы Экономики, поэтому в процессе работы над проектом будет использована регламентная база и рассмотрены бизнес-процессы НИУ ВШЭ Пермь.

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

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

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

В ходе работы будут выполнены задачи:

1. Анализ предметной области.

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

1.2. Моделирование бизнес-процессов “as is”.

1.3. Выявление недостатков процессов, обоснование необходимости автоматизации.

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

2. Определение требований к ИС.

2.1. Уточнение функций проектируемой ИС.

2.2. Разработка моделей поведения ИС, моделирование бизнес-процессов “to be”.

3. Проектирование ИС

3.1. Проектирование базы данных.

3.2. Проектирование интерфейсов и форм.

Результатом работы будет являться проект ИС.

Содержание глав работы

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

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

Глава 1. Анализ деятельности учебного офиса в части работы с регламентами

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

1.1 Анализ работы учебного офиса с регламентирующими документами

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

В их работе используется репозиторий регламентирующих документов, доступный через корпоративный портал НИУ ВШЭ. Через веб-интерфейс доступна фильтрация по виду (положение, регламент, порядок и др.), сфере деятельности (прием, распорядок, финансы и др.), адресату, дате принятия, статусу и прочим характеристикам. Также пользователям доступен поиск по названию или телу документа, по номеру или ключевому слову. Всего в сборнике представлено более тысячи различных документов.

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

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

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

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

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

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

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

1.2 Разработка модели процесса AS-IS

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

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

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

3. Сотрудник учебного офиса производит поиск релевантных разделов внутри отобранных на предыдущем шаге документов.

4. Сотрудник учебного офиса выполняет предписанные документом действия.

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

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

7. Ответственное лицо принимает решение по возникшему несоответствию или разночтению либо перенаправляет заявку на рассмотрение вышестоящему лицу.

8. Ответственное лицо направляет принятое решение сотруднику учебного офиса.

В настоящий момент используются следующие программные средства.

Регламентирующие документы хранятся в едином архиве, доступном через веб-интерфейс портала НИУ ВШЭ [1].

Для коммуникаций между сотрудниками и отделами университета используется электронная почта.

Диаграмма процесса AS-IS в нотации BPMN 2.0 представлена на рисунке 1.1.

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

Рисунок 1.1. Модель процесса AS-IS

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

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

Предлагается альтернативный способ решения описанных проблем - внедрение информационной системы для автоматизации процесса работы с регламентными несоответствиями.

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

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

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

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

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

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

2.1 Разработка модели процесса TO-BE

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

С использованием информационной системы процесс будет выполняться следующим образом:

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

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

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

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

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

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

7. Модератор обсуждения в определенный момент принимает финальное решение по обсуждаемому вопросу, это решение заносится в систему. Модератор также имеет право сменить решение в дальнейшем.

8. В ссылке на данный пункт регламента появляется отметка о наличии решенного вопроса по данному пункту.

Диаграмма процесса TO-BE в нотации BPMN 2.0 представлена в Приложении А.

2.2 Формулировка требований к информационной системе

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

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

По результатам анализа бизнес-процессов учебного офиса были сформулированы функциональные и нефункциональные требования к системе.

Функциональные требования. Система должна:

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

2. Хранить ссылки на регулирующие документы, их разделы, пункты, приложения, пункты приложений.

3. Хранить информацию о соответствиях ссылок пункта 2 задачам пункта 1.

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

5. Позволять пользователем проходить авторизацию и работать с системой от своего имени.

6. Позволять добавлять новых сотрудников, ссылки на новые документы, новые задачи.

7. Допускать привязку одного пункта регламента к нескольким задачам, допускать привязку к одной задаче нескольких пунктов регламентов.

8. Предоставлять площадку для диалога сотрудникам организации - позволять им создавать новые обсуждения с привязкой к определенным документов.

9. Позволять инициатору обсуждения на этапе его создания выбирать, какие лица будут в него приглашены.

10. Позволять инициатору обсуждения на этапе его создания выбирать модераторов обсуждения.

11. Позволять членам обсуждения добавлять к обсуждению новых лиц.

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

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

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

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

Нефункциональные требования. Система должна:

1. Состоять из базы данных и web-интерфейса.

2. Иметь удобный графический пользовательский интерфейс.

3. Быть расширяемой и возможной к применению не только в НИУ ВШЭ, но и в других организациях, осуществляющих работу с регламентами.

4. Организовывать общение в обсуждениях в формате форума.

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

Рисунок 2.1. Диаграмма прецедентов

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

2.2 Проектирование базы данных

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

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

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

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

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

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

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

Таблица 2.1. Сравнительный анализ моделей данных

Преимущества

Недостатки

Реляционная модель

1. Простота и понятность структуры модели данных для пользователя, т.к. основная конструкция для организации данных - таблица.

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

3. Строгие правила проектирования, основанные на математическом аппарате и теории нормализации.

4. Используется большинством современных СУБД.

1. Относительно низкая скорость доступа к данным.

2. Большой расход памяти для представления данных.

3. Множество таблиц в сложных БД приводит к трудности восприятия модели.

4. Предметная область не всегда может быть представлена в виде таблиц.

Иерархическая модель

1. Минимальный расход памяти.

2. Принцип подчиненности сущностей друг другу является естественным для многих предметных областей.

1. Сложность понимания модели для пользователя.

2. Относительно медленный доступ к данным нижних уровней иерархии.

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

4. Для предметных областей с нетривиальными логическими связями модель становится громоздкой.

5. Не используется современными СУБД.

Сетевая модель

1. Универсальность. Модель позволяет выразить больше типов связей между сущностями предметной области.

2. Гибкость. Модель позволяет описать предметную область, которую невозможно представить в виде иерархии.

3. Быстродействие.

4. Стандартизация. Стандарт CODASYL определяет базовые понятия модели и формальный язык описания.

1. Жесткость. Изменение структуры базы данных ведет к необходимости перестроения всей базы данных.

2. Сложность структуры хранения базы в памяти.

3. Относительно слабая поддержка моделей такого типа современными СУБД.

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

Теперь можно перейти непосредственно к разработке реляционной модели данных. Сначала будет создана логическая модель данных. Она описывает понятия предметной области, их взаимосвязи и ограничения. Поэтому, перед тем, как создавать логическую модель, нужно выделить основные сущности предметной области. Используя информацию, полученную в процессе интервьюирования сотрудников учебного офиса НИУ ВШЭ и анализа существующих бизнес-процессов, был сформирован следующий список сущностей предметной области:

1. Сотрудник - человек, работающий в организации.

2. Должность - позиция сотрудника в организационной структуре.

3. Группа должностей - набор подобных друг другу должностей (например, группа «Менеджеры» включает должности менеджеров всех образовательных программ.

4. Документ - регулирующий работу организации документ любого из существующих типов.

5. Пункт - часть документа или приложения, как правило регулирующая отдельную операцию.

6. Приложение - приложение к документу. Оно может содержать свой набор пунктов.

7. Операция - единица деятельности сотрудника организации, регулируемая документами.

8. Кейс - более общая задача, регулируемая документами, содержащая операции.

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

10. Сообщение - комментарий сотрудника, участвующего в обсуждении.

11. Пара «пункт-операция» - связанные пункт документа и регулируемая им операция, для обсуждения проблемы с которыми создается обсуждения.

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

Таблица 2.2. Описание сущностей и связей между ними

Сущность 1

Смысл связи

Сущность 2

Сотрудник

Занимает

Должность

Сотрудник

Пишет

Сообщение

Сотрудник

Участвует

Обсуждение

Сотрудник

Модерирует

Обсуждение

Группа должностей

Включает

Должность

Документ

Содержит

Пункт

Документ

Включает

Приложение

Приложение

Содержит

Пункт

Пункт

Регулирует

Операция

Пара пункт-операция

Включает

Пункт

Пара пункт-операция

Включает

Операция

Обсуждение

Создается для

Пара пункт-операция

Обсуждение

Содержит

Сообщение

Обсуждение

Содержит

Решение

Сообщение

Является

Решением

Кейс

Содержит

Кейс

Кейс

Содержит

Операция

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

Рисунок 2.2. Предварительная модель ERD

Эта модель является предварительной, так как она не показывает типы связей, предусмотренные ERD. Они различаются в зависимости от кардинальности связываемых сущностей и степеней связей.

Кардинальность - класс принадлежности сущности отношению. Существуют обязательный и необязательный классы принадлежности. Если связь не может существовать без присутствия в ней одной из сущностей, класс принадлежности такой сущности называется обязательным. Эта сущность имеет кардинальность 1. Если же в отношении не каждая из связываемых сущностей имеет отношение к другой, класс принадлежности первой называется необязательным. Она имеет кардинальность 0.

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

Таким образом, каждую связь в модели ERD можно описать через пару связываемых сущностей, а также кардинальность и степень связи для каждой из них. Например, связь один-к-одному с обязательным классом принадлежности первой сущности и необязательным классом принадлежности второй можно обозначить как (0,1:1,1), где первая цифра каждой пары обозначает кардинальность, а вторая - степень связи. Связь один-ко-многим между такими же сущностями будет иметь вид (0,1:1,N).

Модель на рисунке 2.2 можно уточнить типами связей. Для этого следует сначала дополнить ими таблицу 2.2. Результат анализа связей представлен в Приложении C.

Нотация ERD предписывает использовать следующие обозначения для связей (таблица 2.3).

Таблица 2.3. Обозначения связей в нотации ERD

Связь

Обозначение

(…:0,1)

(…:1,1)

(…:0,N)

(…:1,N)

В результате описания кардинальностей и степеней связей теперь можно построить уточненную модель ERD. Она представлена на рисунке 2.3.

Рисунок 2.3. Модель ERD

Далее следует определить набор атрибутов, которые описывают каждую сущность. Атрибуты сущностей представлены в таблице 2.4.

Таблица 2.4. Сущности и их атрибуты

Сущность

Атрибут

Сотрудник

Фамилия

Имя

Отчество

Должность

Адрес электронной почты

Должность

Название должности

Группа должностей

Группа должностей

Название группы должностей

Документ

Название документа

Ссылка на документ в хранилище

Пункт документа

Название/номер пункта документа

Документ

Приложение

Документ

Название приложения

Ссылка на приложение

Пункт приложения

Приложение

Название/номер пункта приложения

Пара пункт-операция

Пункт документа

Пункт приложения

Операция

Обсуждение

Вопрос

Дата

Время

Участники

Модераторы

Сообщение

Автор

Текст

Статус (решение/нет)

Обсуждение

Дата

Время

Внешнее сообщение

Операция

Кейс

Название операции

Номер операции

Описание операции

Сроки выполнения операции

Внешние сущности

Требуемые ресурсы и инструменты

Результат выполнения операции

Кейс

Внешний кейс

Операции

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

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

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

Таблица 2.5. Сравнительный анализ популярных СУБД

MS Access

MySQL

MS SQL Server

Размер БД

До 2 Гб

Теоретически неограничен, зависит от ограничений файловой системы

До 10 Гб

Количество одновременных пользователей

255

4 294 967 295 (практически неограничено)

32767

Стоимость

Доступна

Бесплатна

Дорогие сервера

Платформа

Только Windows

Windows+Linux

Только Windows

Поддержка клиент-серверной архитектуры

Нет

Да

Да

Защита данных

Слабая

Сильная

Сильная

Требования к производительности ПК

Низкие

Низкие

Требует мощных серверов с большим объемом оперативной памяти

Сложность установки, настройки и поддержки

Минимальная

Требуется первоначальная настройка и минимальная поддержка

Желательно наличие специалиста по БД

Перспективы развития, надежность разработчиков

Развивается, изменения незначительны

Бурно развивается, новые релизы

Бурно развивается, новые релизы

На основании проведенного анализа была выбрана СУБД MySQL. Она обладает оптимальным набором значений рассмотренных параметров и является наиболее универсальной среди рассмотренных СУБД.

Перед формированием набора таблиц и их полей следует учесть, что список кейсов предметной области, регламентируемых документами, имеет иерархическую структуру с различным количеством уровней иерархии. Так, к примеру, кейс «Отпуск» содержит ряд подчиненных кейсов по различным видам отпусков, а кейс «Оформление больничного листа» не имеет подчиненных кейсов и включает в себя перечень необходимых операций. Так как реляционные базы данных изначально не созданы для хранения иерархических структур, существует несколько подходов к их хранению в рамках реляционной модели данных, такие как «Adjacency List», «Materialized Path» и «Nested Set».

Adjacency List, или список смежности, является способом установить соответствие «один-к-одному» между двумя записями одной таблицы. К таблице в этом случае добавляется поле, хранящее указатель на другое поле этой же таблицы. Преимуществом подхода является простота удаления элемента из иерархии - достаточно назначить верхний по отношению к удаляемому элементу элемент новым предком элементов ближайшего нижнего уровня.

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

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

Рисунок 2.4. Структура Nested Set

В проектируемой базе данных будет использоваться подход Adjacency List, модифицированный для организации связей один-ко-многим. Иерархия будет реализована с использованием дополнительных таблиц «КейсыИерархия» и «СообщенияИерархия», хранящих указатели на пары сущностей, находящихся в подчинительной связи друг с другом. Это позволит реализовать небинарные иерархические структуры, гибкие для изменения.

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

1. «Документы». Таблица должна содержать информацию о документах, регламентирующих деятельность учебного офиса. Так как документы хранятся в едином репозитории на корпоративном портале НИУ ВШЭ [1], достаточно будет хранить только ссылки на документы. Таблица должна содержать поля:

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

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

2. «ПунктыДокументов». Таблица должна содержать набор пунктов каждого документа. Предполагается хранение не всех пунктов документа, а только тех, которые регулируют хотя бы одну из хранимых в БД операций. При необходимости ознакомиться с полным содержанием документа можно перейти к нему по ссылке на портал НИУ ВШЭ. Таблица должна содержать поля:

- Документ. Это внешний ключ для связи с таблицей «Документы». Тип VARCHAR.

- ПунктДокумента. Это ключевое поле, оно является первичным ключом для связи с таблицей «ДокументыКОперациям». Имеет тип TEXT, т.к. содержит в себе текст пункта документа.

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

- Документ. Это поле является внешним ключом для связи с таблицей «Документы». Тип VARCHAR.

- СсылкаНаПриложение. Ключевое поле, внешний ключ для связи с таблицей «ПунктыПриложений». Особенностью предметной области этой работы является факт, что ссылки на приложение содержат в себе часть названия документа, на который они указывают, следовательно, следует использовать тип, дающий пространство для хранения таких ссылок. Тип TEXT с максимальной длиной 65 536 символов удовлетворяет данному условию.

- НазваниеПриложения. Текстовое поле, тип TEXT.

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

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

- Приложение. Внешний ключ для связи с полем «СсылкаНаПриложение» таблицы «Приложения». Тип TEXT.

- ПунктПриложения. Внешний ключ для связи с таблицей «ДокументыКОперациям», тип TEXT.

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

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

- КейсВнешний.

- КейсВнутренний.

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

7. «ОперацииКейса». Таблица должна содержать информацию об операциях, необходимых для решения кейса. Список полей был определен после изучения технологических карт, в настоящее время используемых сотрудниками учебного офиса НИУ ВШЭ Пермь для формализации бизнес-процессов в рамках кейсов. Таблица должна содержать поля:

- НазваниеОперации. Тип VARCHAR.

- Кейс. Тип VARCHAR. Оно будет являться внешним ключом для поля «НазваниеКейса» таблицы «Кейсы» в рамках связи типа «один-ко-многим».

- НомерОперации. В этом поле будет храниться порядковый номер операции в кейсе. При изменении порядка операций в кейсе будет необходимо обновить в базе данных порядковые номера всех операций в кейсе.

- НазваниеОперации. Тип VARCHAR.

- Описание Операции. Тип TEXT.

- СрокиВыполнения. Поле может хранить информацию о сроках выполнения, включающую сложные условия, поэтому имеет смысл присвоить полю тип TEXT.

- ВнешниеСущности. Описывает внешние по отношению к операции сущности. Тип TEXT.

- ТребуемыеРесурсы. Тип TEXT.

- РезультатВыполнения. Тип TEXT.

8. «ДокументыКОперациям». Таблица служит для связи операций, необходимых для решений кейса, регламентирующих их пунктов документов и приложений, а также обсуждений этих пунктов. Таблица должна реализовывать связь типа многие-ко-многим между таблицами «ОперацияКейса», «ПунктыДокументов», «ПунктыПриложений» и «Обсуждения». Таблица должна содержать поля:

- ПунктДокумента. Это внешний ключ для поля «ПунктДокумента» таблицы «ПунктыДокументов» в рамках связи типа «один-ко-многим». Имеет тип TEXT.

- ПунктПриложения. Это внешний ключ для поля «ПунктПриложения» таблицы «ПунктыПриложений» в рамках связи типа «один-ко-многим». Имеет тип TEXT.

- Операция. Это внешний ключ для ключевого поля «idОперации» таблицы «ОперацииКейса» в рамках связи типа «один-ко-многим». Тип unsigned SMALLINT. Если суммарное количество хранимых в БД операций превысит 65 536, тип следует сменить на unsigned MEDIUMINT.

- Обсуждение. Поле участвует в связи «один-к-одному» с ключевым полем «idОбсуждения» таблицы «Обсуждения» и в связи «один-ко многим» с полем «Обсуждение» таблицы «УчастникиОбсуждений». Такой выбор типов связи объясняется тем, что к каждой паре пункта документа или приложения и операции кейса может быть создано только одно обсуждение, но в этом обсуждении может принимать неограниченное количество участников. Тип поля unsigned SMALLINT.

9. «Обсуждения». Таблица предназначена для хранения информации об обсуждениях на форуме, то есть наборах сообщений по определенному вопросу. Таблица должна содержать поля:

- idОбсуждения. Тип unsigned SMALLINT. Хранит уникальный идентификатор обсуждения, является ключевым полем таблицы и внешним ключом для связи с таблицами «ДокументыКОперациям», «Сообщения» и «УчастникиОбсуждений».

- Вопрос. Хранит текст вопроса, или сообщения, которое было введено на этапе инициации обсуждения его создателем. Тип TEXT.

- Дата. Дата создания обсуждения, тип DATE.

- Время. Время создания обсуждения, тип TIME.

10. «Сообщения». Таблица предназначена для хранения сообщений в обсуждениях на форуме и должна содержать поля:

- idСообщения. Уникальный числовой идентификатор сообщения, ключевое поле таблицы, первичный ключ для связи типа «один-ко-многим» с полями «СообщениеВнешнее» и «СообщениеВнутреннее» таблицы «СообщенияИерархия». Тип поля unsigned MEDIUMINT.

- Обсуждение. Тип unsigned SMALLINT, внешний ключ для связи типа «один-ко-многим» с полем «idОбсуждения» таблицы «Обсуждения».

- Текст. Поле хранит текст сообщения. Тип TEXT.

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

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

- Время. Тип TIME, время публикации сообщения.

- Дата. Типа DATE, дата публикации сообщения.

11. «СообщенияИерархия». Таблица используется для организации иерархии сообщений подобно таблице «КейсыИерархия». Таблица включает два поля:

- «СообщениеВнешнее». Является внешним ключом для реализации связи «один-ко-многим» с таблицей «Сообщения». Имеет тип MEDIUMINT. Входит в составной ключ.

- «СообщениеВнутреннее». Является внешним ключом для реализации связи «один-ко-многим» с таблицей «Сообщения». Имеет тип MEDIUMINT. Входит в составной ключ.

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

13. «УчастникиОбсуждений». Таблица предназначена для хранения информации о том, какие сотрудники участвуют в обсуждениях, а также какие роли в этих обсуждениях имеют сотрудники. Таблица должна содержать поля:

- Сотрудник. Первичный ключ для связи типа «один-ко-многим» с таблицей «Сотрудники» через ее ключевое поле и внешний ключ «ЭлектроннаяПочта». Тип VARCHAR.

- Роль. Роль участвующего в обсуждении сотрудника. Поле является внешним ключом для связи типа «один-ко-многим» с таблицей «Роли». Тип «VARCHAR».

- Обсуждение. Внешний ключ для связи типа «один-ко-многим» с таблицей «Обсуждения». Тип unsigned SMALLINT.

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

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

15. «Сотрудники». Таблица должна содержать информацию о сотрудниках учебного офиса. Таблица должна содержать поля:

- Фамилия. Тип VARCHAR.

- Имя. Тип VARCHAR.

- Отчество. Тип VARCHAR.

- Должность. Тип VARCHAR.

- ЭлектроннаяПочта. Это поле является ключевым, так как у двух сотрудников не может быть одинаковых корпоративных (или личных) адресов электронной почты. Имеет тип VARCHAR, так как адреса обычно короткие.

- Пароль. Пароль будет использоваться для входа в систему. Поле имеет тип VARCHAR.

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

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

- Должность. Поле является внешним ключом для связи с таблицей «Должности» и имеет тип VARCHAR. Является частью составного ключа.

- Сотрудник. Поле является внешним ключом для связи с таблицей «Сотрудники» и имеет тип VARCHAR. Является частью составного ключа.

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

18. «Группы» представляет собой справочник групп должностей организации. Под группой понимается набор похожих должностей в разных отделениях организации. Например, в ВШЭ группой должностей может являться группа «Менеджер образовательной программы». Она будет включать менеджеров всех образовательных программ университета. Это упростит процесс приглашения участников в обсуждения, так как можно будет, выбрав группу, моментально выбрать всех ее участников. Таблица должна иметь связь типа один-ко-многим с таблицей «ГруппыДолжностей» по внешнему ключу «НазваниеГруппы». Таблица должна содержать единственное поле «НазваниеГруппы» типа VARCHAR, содержащее в себе название группы должностей.

19. «ГруппыДолжностей». Эта таблица реализует связь «многие-со-многими» между таблицами «Группы» и «Должности», так как в одной группе может содержаться несколько должностей, и каждая должность может числиться в одной из нескольких групп. Например, должность «Менеджер образовательной программы «Бизнес-Информатика» может входить в группы «Менеджеры образовательных программ» и «Бизнес-Информатика». Таблица должна содержать поля:

...

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены