Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Разработка модели процесса AS-IS).pdf

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

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

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.

---