close

Вход

Забыли?

вход по аккаунту

Гуров Денис Игоревич. Разработка информационной системы сопровождения ведения дел в юридической фирме ООО «Мерцлин и Партнёры»

код для вставки
АННОТАЦИЯ
ВКР 70 с., 19 рис., 4 табл., 30 источников, 1 прил.
ИНФОРМАЦИОННАЯ
СИСТЕМА,
АВТОМАТИЗИРОВАННЫЕ
СИСТЕМЫ УПРАВЛЕНИЯ, ЮРИДИЧЕСКАЯ УСЛУГА, ЮРИДИЧЕСКИЙ
ДОГОВОР, КЛИЕНТ, СОТРУДНИК, ПАРТНЕР.
Выпускная
квалификационная
работа
посвящена
разработке
информационной системы сопровождения ведения дел в юридической фирме ООО
«Мерцлин и Партнёры».
В первой главе проведен анализ деятельности юридической фирмы ООО
«Мерцлин и Партнёры», дана характеристика предметной области, построена
модель процессов предметной области, рассмотрены требования к функциям
системы.
Во второй главе проведено инфологическое проектирование базы данных,
определена сущность базы данных и атрибутов, определены связи между
сущностями базы данных, проведена нормализация концептуальной схемы базы
данных, разработана физическая модель и ограничения целостности базы данных,
рассмотрены алгоритмы базы данных, разработано управление доступом к
ресурсам информационной системы, и ее архитектура, а также проведено
проектирование диалога и представлены экранные формы разработанной
информационной системы.
4
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
5
1 ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ И АНАЛИЗ
ДЕЯТЕЛЬНОСТИ ОРГАНИЗАЦИИ
7
1.3 Построение модели процессов предметной области
10
1.4 Требования к функциям системы
15
2 ПРОЕКТИРОВАНИЕ И РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ
СОПРОВОЖДЕНИЯ ВЕДЕНИЯ ДЕЛ В ЮРИДИЧЕСКОЙ ФИРМЕ
17
2.1 Инфологическое проектирование базы данных
17
2.1.1 Определение сущностей базы данных и их атрибутов
19
2.1.2 Определение связей между сущностями базы данных
23
2.1.3 Нормализация концептуальной схемы базы данных
26
2.1.4 Разработка физической модели базы данных
28
2.2 Разработка ограничений целостности базы данных
28
2.3 Алгоритмы обработки данных
37
2.4 Управление доступом к ресурсам информационной системы
47
2.5 Архитектура информационной системы
49
2.6 Проектирование диалога: графическое представление диалога
53
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
63
ПРИЛОЖЕНИЕ А
64
УДОСТОВЕРЯЮЩИЙ ЛИСТ
68
ИНФОРМАЦИОННО-ПОИСКОВАЯ ХАРАКТЕРИСТИКА
69
5
ВВЕДЕНИЕ
Современные
методы
ведения
бизнеса
рассчитаны
на
широкое
использование интернет-технологий, что предоставляет возможность общения в
интернете с неограниченным количеством
потенциальными потребителями
различных товаров и услуг.
Специфика отдельных видов работ, как будто создана для ведения через
интернет, к таким работам относятся консультации и обучение, реклама, игры и
многое другое.
Юридические услуги также можно отнести относятся к подобному виду
работ, поскольку предоставление подобных услуг можно организовать с помощью
интернета, тем более что зачастую для своей деятельности юристу требуются
только наличие документов заказчика по делу, а присутствие самого клиента не
обязательно.
Причины обращения населения к юристам разнообразны: вопросы
наследства, вопросы недвижимости, консультации по открытию предприятий и
прочее. Кроме того, существует юридический аутсорсинг, когда за фиксированную
абонентскую плату юрист решает профильные дела других компаний. Данное
направление является самым прибыльное.
Результаты оказания услуг посредством сети Интернет имеют такую же
юридическую силу, как и обычные услуги, предоставляемые адвокатами по
соглашениям об оказании юридической помощи.
При этом в секторе оказания юридических услуг посредством сети Интернет
действует высокая конкуренция, поэтому первостепенной задачей является выбор
такого решения, которое позволит справиться с текущими проблемами
организации, будет давать возможность нормального развития при росте
предприятия и будет доступным по цене. Этим определяется актуальность
настоящей темы исследования.
6
Целью
выпускной
квалификационной
работы
является
разработка
информационной системы сопровождения ведения дел в юридической фирме ООО
«Мерцлин и Партнёры».
Задачи, которые необходимо решить в ходе написания выпускной
квалификационной работы:
1. Анализ деятельности организации ООО «Мерцлин и Партнёры», анализ
процесса учета оказания юридических и прочих услуг.
2. Функциональное моделирование процесса учета с помощью стандарта
IDEF0.
3. Проектирование информационной системы учета:
− проектирование базы данных;
− формирование ограничений целостности базы данных;
− разработка алгоритмов обработки данных и основных запросов;
− проектирование управления доступом к ресурсам информационной
системы;
− разработка архитектуры информационной системы;
− проектирование пользовательского интерфейса;
− реализация
информационной системы сопровождения ведения дел в
юридической фирме ООО «Мерцлин и Партнёры».
В качестве объекта выпускной квалификационной работы выступает ООО
«Мерцлин и Партнёры».
7
1 ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ И АНАЛИЗ
ДЕЯТЕЛЬНОСТИ ОРГАНИЗАЦИИ
1.1 Характеристика организации
Юридическая фирма «Мерцлин и Партнёры» учреждена юристами,
имеющими значительный опыт работы, в том числе обладающими обширными
знаниями в следственной, надзорной работе, в деятельности органов власти и
контроля.
Основной целью юридической фирмы является качественное и честное
оказание юридических услуг гражданам и юридическим лицам, основанное на
предварительном анализе ситуации, с которой столкнулся клиент, изучении
имеющихся документов и выработке тактики юридической работы. Широкий
профиль оказываемых фирмой услуг стал возможен благодаря привлечению ряда
партнеров, специализирующихся в различных областях права.
Большинство юридических вопросов сотрудники фирмы могут рассмотреть
дистанционно путем общения по телефонной связи и обмена документами по
электронной почте на нашем официальном сайте, что значительно сэкономит время
клиента.
В свою очередь при необходимости деловой встречи с изучением и
обсуждением большого объема документов, в том числе конфиденциальных,
составляющих коммерческую тайну и т.п., у фирмы имеется возможность
арендовать на необходимый период времени офисное помещение по адресу,
указанному в разделе «контакты».
Фирма оказывает услуги по следующим юридическим категориям:
1. Уголовное право.
2. Гражданское право.
3. Трудовые споры.
4. Семейное право.
5. Жилищное право.
6. Арбитражное право.
8
7. Корпоративное право.
8. Наследственное право.
9. Административное право.
10. Налоговое право.
11. Авторское право.
12. Земельное право.
13. Правовая
помощь
по
административным
делам
органов
Государственной инспекции безопасности дорожного движения (далее – ГИБДД).
14. Защита прав потребителей.
15. Исполнительное производство.
16. Правовая помощь в страховых спорах.
17. Юридическое обслуживание предприятия.
18. Услуги адвоката (юрисконсульта) по сопровождению клиента.
19. Правовые услуги и профессиональные консультации по правовым
вопросам и ситуациям.
20. Профессиональное
консультирование
«молодых
специалистов»
(дознавателей, следователей, оперативных сотрудников).
21. Юридический аудит предпринимательской деятельности.
22. Комплексная
проверка
финансово-хозяйственной
деятельности
организаций и предприятий и инвентаризация.
23. Пожарная безопасность и защита от чрезвычайных ситуаций (далее –
ЧС).
24. Миграционное законодательство, регистрационный учет и оформление
документов, удостоверяющих личность.
25. Информационно-методологические
услуги
по
бухгалтерского учета.
26. Услуги по недвижимости.
27. Разработка и составление юридических документов.
28. Услуги адвоката по уголовным делам в суде.
29. Правовые услуги в судах общей юрисдикции.
организации
9
1.2 Описание предметной области
ООО «Мерцлин и Партнёры» оказывает юридические и прочие услуги
физическим и юридическим лицам. Процесс оказания
услуг сводится к
следующему.
Посредством телефонной или электронной связи клиент (физическое или
юридическое лицо) связывается с представителем организации (директором или
заместителем директора). Директор или его заместитель проводит первичную
консультацию клиента по предоставляемым услугам, ценам на услуги, условиям
сотрудничества. В случае необходимости стороны договариваются о личной
встрече в офисе организации, где уже детально обсуждают интересующие клиента
вопросы. В ходе личной встречи сотрудники юридической фирмы – юристы и
адвокаты подробно общаются с клиентом, изучают имеющуюся у них
документацию, анализируют возникшую ситуацию с позиции действующего
законодательства.
На основании информации, полученной в ходе проведения переговоров,
директор (заместитель директора) составляет смету на оказание услуг. Смета
составляется на основании имеющегося в организации прайс-листа на оказание
услуг после оценки продолжительности и сложности предполагаемого дела, а,
следовательно, определения объема работы: какие иски, запросы, жалобы нужно
будет составить и отправить, в каких следственных действиях участвовать, какие
судебные заседания посетить и т.д.
В
случае,
если
условия
сотрудничества
удовлетворяют
клиента,
заключается договор. Возможно оказание услуг без заключения договора, только
на основании устного соглашения об оказании услуг между сторонами. Это имеет
место в случае предоставления небольших по объему услуг.
Выполнение
услуг
по
договору
(соглашению)
начинается
после
поступления 50% предоплаты за работу на расчетный счет фирмы. Кроме того
клиент предоставляет копии (скан, фото) документов, относящихся к возникшему
10
юридическому вопросу. В ходе исполнения заказа клиента адвокат (юрисконсульт)
может запрашивать у клиента дополнительную информацию, либо документы.
Специалист выполняет необходимые процедуры и регистрирует их в деле.
На любом шаге специалист имеет дело с документами и заключениями, как самой
организации, так и независимых экспертиз.
По завершению обслуживания клиента все материалы дела передаются
директору или заместителю директора. Они дают заключение на официальном
бланке организации.
Юридическое заключение в обговоренный срок направляется клиенту на
электронную почту или почтовый адрес на бланке фирмы с уникальным кодом,
подписью генерального директора или заместителя генерального директора и
печатью. Получив юридическое заключение, клиент оплачивает оставшиеся 50%
суммы за работу на расчетный счет фирмы в течении 24 часов с момента получения
заключения. При необходимости юридическое заключение клиент может получить
лично.
ООО «Мерцлин и Партнёры» сотрудничает с рядом сторонних организаций,
поэтому выполнение услуг по договорам (соглашениям) может производиться с
привлечением представителей организаций-партнеров.
1.3 Построение модели процессов предметной области
В данной главе рассмотрим модель процессов предметной области (далее –
МППО), построенную с помощью программного продукта BPWin 4.1.
МППО
представляет
собой
набор
взаимосвязанных
описаний,
начинающихся с самого верхнего уровня системы и заканчивающихся подробным
описанием деталей. Каждое такое описание называется диаграммой. Модель
объединяет диаграммы в иерархическую структуру. Вершиной этой иерархии
является контекстная диаграмма, которая состоит из одного блока и множества дуг,
и раскрывает связь системы с внешним миром. Остальные уровни иерархии
получаются путем декомпозиции контекстной диаграммы.
11
При построении МППО была определена граница МППО в ширину – ее
определяет контекстная диаграмма (рисунок 1), граница в глубину – ее определяет
количество уровней в иерархической структуре.
Рисунок 1.1 – Контекстная диаграмма МППО
Декомпозиция контекстной диаграммы представлена на рисунке 2. Процесс
получения услуг можно свести к нескольким процессам: подача заявки на оказание
услуг, заключение договора, оказание услуг, оформление результатов.
Рисунок 2 – Декомпозиция контекстной диаграммы МППО
Декомпозиция активности «Подать заявку на оказание услуги» представлена
на рисунке 3.
Подача заявки включает в себя этап первичной консультации клиента и этап
составления сметы на оказание услуг.
12
Рисунок 3 – Декомпозиция диаграммы «Подать заявку на оказание услуги»
Первичная
консультация
(рисунок
4)
предусматривает
телефонную
консультацию (консультацию посредством электронной почты), которую проводит
директор (заместитель директора). На этом этапе директор вникает в суть вопроса
на основании информации о существе вопроса, переданной ему в устной форме или
электронном виде. Уже на этом этапе директор (заместитель директора) может
принять решение о стоимости выполнения услуг и стороны могут прийти к
соглашению о сотрудничестве. Это имеет место, если представляется возможным
оценить трудоемкость работ, например, если услуга предусматривает выполнение
одного вида работ (подготовка договора, оформление претензии и т.п.).
В более сложных делах стороны договариваются о личной встрече, в ходе
которой участвуют сотрудники организации и/или представители партнера,
являющиеся специалистами в различных отраслях. Они знакомятся с документами
клиента, вникают в суть вопроса и оценивают объем работ, который необходимо
выполнить.
После достижения соглашения об оказании услуг в ходе проведения
первичной консультации составляется смета на услуги (Рисунок 1.4). Для этого
определяется состав работ, продолжительность работ, стоимость их выполнения и
исполнители (рисунок 5).
13
Рисунок 4 – Декомпозиция диаграммы «Провести первичную
консультацию»
Рисунок 5 – Декомпозиция диаграммы «Составить смету на услуги»
После того, как имеется соглашение об оказании услуг, составлена смета,
стороны могут заключить договор. Если работы будут производиться с
привлечением партнеров, представитель партнера также участвует на данном
этапе. Директор (заместитель директора) составляет проект договора, он
согласовывается с заказчиком. В случае имеющихся разногласий проект договора
подвергается корректирующей правке. Если все стороны удовлетворены, договор
подписывается сторонами, директор оформляет дело, в котором будут храниться
все документы по договору (рисунок 6).
14
Рисунок 6 – Декомпозиция диаграммы «Заключить договор»
После внесения клиентом предоплаты в размере 50% от стоимости услуг
директор (заместитель директора) оформляет дело для занесения В дальнейшем
всех документов в него. Исполнитель получает от клиента все необходимые
документы и проводит ряд действий (шагов) для оказания услуги в полном объеме.
На каждом шаге исполнителем может быть получено до нескольких документов,
которые прикрепляются к делу (рисунок 7).
Рисунок 7 – Декомпозиция диаграммы «Оказать услугу»
На основании имеющихся в деле документов исполнитель готовит
юридическое заключение, которое подписывается директором (заместителем
директора) и передается клиенту. Клиент оплачивает оставшиеся 50% от стоимости
15
выполненных услуг. На этом процесс оказания услуг считается завершенным
(рисунок 8).
Рисунок 8 – Декомпозиция диаграммы «Оформить результаты»
1.4 Требования к функциям системы
Создание
информационной
системы
предусматривает
выработку
совокупности требований, которым она должна удовлетворять. В нашем случае
наиболее значимым является формирование требований к структуре системы и ее
функциям. Остановимся на данном вопросе более подробно.
В нашем случае необходимо разработать информационную систему, которая
будет автоматизировать работу организации в части учета оказания юридических
и прочих услуг. Информационная система должна обладать следующими
функциями:
− организация учета обращений клиентов с целью получения информации
об условиях сотрудничества;
− организация учета клиентов: хранение данных о ФИО, номере телефона
и т.п. для физического лица, данных о наименовании, фактическом адресе, ФИО
контактного лица, номере телефона контактного лица и т.п. для юридического
лица. Возможность добавления, удаления, редактирования данных;
− организация учета партнеров: хранение данных о ФИО руководителя,
наименовании, телефоне, адресе организации-партнере;
16
− организация учета договоров и соглашений об оказании услуг: хранение
данных о номере договора/соглашения, дате заключения, относящейся к
договору/соглашению смете и т.п.;
− организация учета оплаты клиентами услуг: хранение данных о
реквизитах оплаты;
− организация учета информации и документов, образующихся при
оказании услуг, в т.ч. юридических заключений;
− организация диалогового режима работы с клиентами, реализуемого
через веб-сайт посредством личного кабинета. Предоставление информации о ходе
выполнения услуги, двусторонний обмен документами;
− автоматизированное
формирование
юридического
заключения
с
присвоением уникального штрих-кода, возможность проверки документа по
штрих-коду;
− возможность аналитической работы с данными: формирование отчетов
об
объеме
оказанных
договоров/соглашений и т.п.
услуг,
формирования
списка
действующих
17
2 ПРОЕКТИРОВАНИЕ И РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ
СИСТЕМЫ СОПРОВОЖДЕНИЯ ВЕДЕНИЯ ДЕЛ В ЮРИДИЧЕСКОЙ
ФИРМЕ
2.1 Инфологическое проектирование базы данных
Произведем
инфологическое
(концептуальное)
проектирование
базы
данных, основной целью которого является построение семантической модели
предметной области, то есть информационной модели наиболее высокого уровня
абстракции. Для построения концептуальной схемы базы данных (далее – БД)
воспользуемся стандартом IDEF1(X).
В
стандарте
IDEF1(X)
существуют
два
уровня
представления
и
моделирования – логический и физический. Логический уровень означает прямое
отображение фактов из реальной жизни. На логическом уровне не рассматривается
использование конкретной система управления базами данных (далее – СУБД), не
определяются типы данных (например, целое или вещественное число) и не
определяются индексы для таблиц.
Целевая СУБД, имена объектов и типы данных, индексы составляют второй
(физический) уровень модели.
Процесс построения концептуальной модели состоит из следующих шагов:
− определение сущностей;
− определение атрибутов сущностей;
− задание первичных и альтернативных ключей, инверсных входов;
− определение зависимостей между сущностями;
− приведение модели к требуемому уровню нормальной формы;
− переход к физическому описанию модели;
− задание триггеров, процедур и ограничений.
Проектирование инфологической модели БД будем производить с помощью
программного средства ERWin, позволяющего проектировать, документировать и
сопровождать базы данных, хранилища данных. Визуальное моделирование
18
повышает качество создаваемой базы данных, продуктивность и скорость её
разработки.
Основные особенности IDEF1X/ERWin:
1. Поддерживается прямое (создание БД на основе модели) и обратное
(генерация модели по имеющейся базе данных) проектирование для 20 типов
СУБД.
2. Увеличивает производительность труда благодаря удобному интерфейсу и
автоматизации рутинных процедур.
3. Поддерживает методологию структурного моделирования SADT и
следующие нотации: IDEF1Х.
4. Поддерживает 20 различных СУБД: настольные, реляционные и
специализированные СУБД, предназначенные для создания хранилищ данных.
5. Позволяет повторно использовать компоненты созданных ранее моделей,
а также использовать наработки других разработчиков.
6. Возможна совместная работа группы проектировщиков с одними и теми
же моделями (с помощью AllFusion Model Manager 4.1).
7. Позволяет переносить структуру БД из одной СУБД в другую.
8. Позволяет документировать структуру БД.
9. Продукт можно использовать на всех стадиях жизненного цикла БД:
проектировании, разработке, тестировании и поддержке.
ERWin – инструмент разработки, способный автоматически создавать
таблицы и генерировать текст хранимых процедур для всех популярных СУБД.
Революционная технология Complete – Compare (Завершить-Сравнить) позволяет
организовать итеративную разработку, поддерживая постоянную согласованность
модели и базы данных. Благодаря интеграции с популярными средами разработки
программ, ERWin позволяет ускорить создание приложений для обработки
данных.
В зависимости от глубины представления информации о данных различают
три уровня логической модели:
− диаграмма сущность-связь (Entity Relationship Diagram, ERD);
19
− модель данных, основанная на ключах (Key Based model, KB);
− полная атрибутивная модель (Fully Attributed model, FA).
В дипломной работе будет рассмотрена полная атрибутивная модель,
содержащая наиболее детальное представление структуры данных: представляет
данные в третьей нормальной форме и включает все сущности, атрибуты и связи.
Основные компоненты диаграммы ERWin – это сущности, атрибуты и связи.
Рассмотрим процесс определения сущностей базы данных, их атрибутов,
первичных и потенциальных ключей, а также инверсных входов.
2.1.1 Определение сущностей базы данных и их атрибутов
Сущность – это реальный или представляемый объект, информация о
котором должна сохраняться и быть доступна. Связь – это графически
изображаемая ассоциация, устанавливаемая между двумя сущностями. Атрибутом
сущности является любая деталь, которая служит для уточнения, идентификации,
классификации, числовой характеристики или выражения состояния сущности.
Рассмотрим сущности и их атрибуты, выявленные при переходе от модели
процессов предметной области. Логический уровень концептуальной схемы базы
данных представлен на рисунке 9.
Вначале рассмотрим вспомогательные сущности. Для хранения информации
о сотрудниках юридической фирмы предназначена сущность «Сотрудник».
Первичный ключ – атрибут «Номер сотрудника». В разрабатываемой БД будет
храниться информация о фамилии, имени и отчестве, телефоне сотрудника.
Для хранения информации о должностях предназначена сущность
«Должность». Первичный ключ – атрибут «Номер должности». Кроме того будет
храниться информация о наименовании должности.
Для хранения информации о должностях, занимаемых конкретным
сотрудником, предназначена сущность «Должность сотрудника» с атрибутами
«Дата назначения» и «Дата снятия».
Рисунок 9 – Логический уровень концептуальной схемы базы данных
20
21
Для хранения информации о клиентах предназначена сущность «Клиент».
Первичный ключ – атрибут «Номер клиент». В разрабатываемой БД будет
храниться информация о фамилии, имени и отчестве, телефоне, адресе сотрудника.
Для хранения информации о партнерах предназначена сущность «Партнер».
Первичный ключ – атрибут «Номер партнера». В разрабатываемой БД будет
храниться информация о фамилии, имени и отчестве, телефоне, адресе партнера.
Для хранения информации о том, является клиент и партнер физическим или
юридическим лицом предназначена сущность «Тип», первичный ключ – «Номер
типа», атрибут – «Тип».
Для хранения информации о перечне услуг, предоставляемых фирмой,
предназначена сущность «Услуга». Первичный ключ – атрибут «Номер услуги».
Кроме того будет храниться описание услуги и стоимость, если возможно ее
определить заранее.
Для хранения
справочника документов предназначена одноименная
сущность. Первичный ключ – атрибут «Номер документа». Кроме того будет
храниться название документа.
Для хранения информации о предоставленных заказчиком и полученных в
результате выполнения услуг документах предназначена сущность «Документы» с
атрибутами «Ссылка на файл» и «Тип». Атрибут «Тип» предназначен для хранения
информации о том, к какому типу документов относится: к предоставленным или
результирующим.
Центральное место в БД занимает сущность «Заявка», первичным ключом
которой является «Номер заявки». Кроме того предусмотрено хранение
информации о номере дела, которое привязано к заявке и ведется в бумажной
форме; номере договора, который заключен по данной заявке; ссылке на файл
договора/соглашения.
Поле
«Описание»
предназначено
для
хранения
дополнительных пометок.
Для хранения информации о проводимых в рамках выполнения заявок
консультаций, предназначена сущность «Консультация», первичный атрибут –
22
«Номер консультации». Кроме того будет храниться информация о дате и времени
консультации, ее описание и отметка о проведении.
Для хранения информации о сотрудниках, участвующих в проведении
консультации, предназначена сущность «Сотрудник в консультации».
Для хранения информации об оплате, совершенной по заявке, предназначена
сущность «Оплата», первичный атрибут – «Номер оплаты». Кроме того будет
храниться информация о дате и сумме оплаты.
Для
хранения
информации
об
услугах,
выполняемых
по
заявке,
предназначена сущность «Услуга в заявке» с единственным атрибутом
«Стоимость».
Для хранения информации о существующих статусах выполнения услуги
предназначена одноименная сущность, первичный атрибут – «Номер статуса».
Кроме того будет храниться информация о наименовании статуса.
Для хранения информации о статусе выполнения конкретной услуги
предназначена сущность «Статус выполнения услуги», атрибутом которой
является дата установки статуса.
Для хранения информации об исполнителе услуги предназначена сущность
«Исполнитель услуги». Поскольку возможна ситуация, при которой исполнителем
одной услуги могут быть несколько сотрудников, в качестве первичного ключа
введен суррогатный ключ «Номер исполнителя».
Для
хранения
информации
о
предусмотренных
в
системе
ролях
пользователей предназначена сущность «Роль в системе».
Для хранения информации о переписке между клиентом и исполнителем
услуги предназначена сущность «Сообщение».
Большинство первичных ключей сущностей являются суррогатными, т.е.
генерируемы искусственно, а не образуются на основе каких-либо других данных
из БД. Это сделано для обеспечения гарантии уникальности, неизменности и
эффективности первичного ключа.
При построении модели «Сущность-Связь» для сущностей были выделены
потенциальные ключи, не ставшие первичными, так называемые альтернативные
23
ключи. Например, для сущности «Должность» альтернативным ключом является
атрибут «Наименование», для сущности «Статус выполнения» – атрибут «Статус».
Кроме того были определены инверсные входы, используемые для повышения
производительности при обеспечении доступа к нескольким экземплярам
сущности, объединенным каким-либо одним признаком.
2.1.2 Определение связей между сущностями базы данных
Связь является логическим соотношением между сущностями. Каждая связь
должна именоваться глаголом или глагольной фразой. Имя связи выражает
некоторое ограничение или бизнес-правило.
На логическом уровне можно установить идентифицирующую связь одинко-многим, связь многие-ко-многим и неидентифицирующую связь один-комногим.
В IDEF1X различают зависимые и независимые сущности. Тип сущности
определяется ее связью с другими сущностями. Идентифицирующая связь
устанавливается между независимой (родительский конец связи) и зависимой
(дочерний конец связи) сущностями.
При установлении неидентифицирующей связи дочерняя сущность остается
независимой, а атрибуты первичного ключа родительской сущности мигрируют в
состав неключевых компонентов родительской сущности. Неидентифицирующая
связь служит для связывания независимых сущностей.
Рассмотрим построенные на этапе концептуального проектирования БД
связи.
Между сущностями «Должность» и «Сотрудник» построена связь «многие ко
многим», так как один сотрудник может занимать одновременно несколько
должностей, а на одну должность могут быть назначено несколько сотрудников.
Для этого введена ассоциативная сущность «Должность сотрудника».
Между сущностями «Роль в системе» и «Сотрудник» («Роль в системе» и
«Клиент») построены связи «один ко многим», так как один сотрудник (клиент)
24
может иметь только одну роль в системе, но одной роли могут быть несколько
сотрудников (клиентов).
Между сущностями «Заявка» и «Сообщение» построена связь «один ко
многим», так как по заявке может быть множество сообщений в чате, но одно
сообщение относится к одной заявке.
Между
сущностями
«Сотрудник»
и
«Сообщение»
(«Клиент»
и
«Сообщение») построены связи «один ко многим», так как сообщение формируется
одним сотрудником (клиентом), а один сотрудник (клиент) может формировать
множество сообщений.
Между сущностями «Тип» и «Партнер» построена связь «один ко многим»,
так как партнер может являться либо физическим либо юридическим лицом, а к
одному типу могут принадлежать множество партнеров. Так как для однозначной
идентификации экземпляра сущности «Партнер» используется первичный ключ
«Номер партнера», нет необходимости ввода в состав первичных ключей внешнего
ключа «Номер типа» сущности «Тип», связь между данными сущностями –
неидентифицирующая.
Между сущностями «Тип» и «Клиент» построена связь «один ко многим»,
так как клиент может являться либо физическим либо юридическим лицом, а к
одному типу могут принадлежать множество клиентов. Так как для однозначной
идентификации экземпляра сущности «Клиент» используется первичный ключ
«Номер клиента», нет необходимости ввода в состав первичных ключей внешнего
ключа «Номер типа» сущности «Тип», связь между данными сущностями –
неидентифицирующая.
Между сущностями «Клиент» и «Заявка» построена связь «один ко многим»,
так как клиент может подать несколько заявок, а одна заявка относится к одному
клиенту. Так как для однозначной идентификации экземпляра сущности «Заявка»
используется первичный ключ «Номер заявки», нет необходимости ввода в состав
первичных ключей внешнего ключа «Номер клиента» сущности «Клиент», связь
между данными сущностями – неидентифицирующая.
25
Между сущностями «Заявка» и «Консультация» построена связь «один ко
многим», так как по одной заявке может проводиться несколько консультаций, но
консультация всегда относится к одной заявке. Так как для однозначной
идентификации экземпляра сущности «Консультация» используется первичный
ключ «Номер консультации», нет необходимости ввода в состав первичных ключей
внешнего ключа «Номер заявки» сущности «Заявка», связь между данными
сущностями – неидентифицирующая.
Между сущностями «Сотрудник» и «Консультация» построена связь
«многие ко многим», так как в одной консультации могут принимать участие
несколько сотрудников, а один сотрудник может участвовать во множестве
консультаций. Для этого введена ассоциативная сущность «Сотрудник в
консультации».
Между сущностями «Справочник документов» и «Заявка» построены две
связи «многие ко многим», так как к заявке могут относиться несколько
предоставленных либо результативных документов, а один документ может
предоставляться либо быть результативным во множестве заявок. Для этого
введены
ассоциативные
сущности
«Предоставленные
документы»
и
«Результативные документы».
Между сущностями «Заявка» и «Оплата» построена связь «один ко многим»,
так как по одной заявке может быть совершено несколько оплат, но одна оплата
касается только одной заявки. Так как для однозначной идентификации экземпляра
сущности «Оплата» используется первичный ключ «Номер оплаты», нет
необходимости ввода в состав первичных ключей внешнего ключа «Номер заявки»
сущности «Заявка», связь между данными сущностями – неидентифицирующая.
Между сущностями «Усуга» и «Заявка» построена связь «многие ко
многим», так как заявка может включать выполнение нескольких услуг, а одна
услуга может быть предметом выполнения множества заявок. Для этого введена
ассоциативная сущность «Услуга в заявке».
Между сущностями «Статус выполнения» и «Услуга в заявке» построена
связь «многие ко многим», так как услуга в заявке может в разные моменты
26
времени иметь различные статусы, а один статус может принадлежать различным
услугам. Для этого введена ассоциативная сущность «Статус выполнения услуги».
Между сущностями «Услуга в заявке» и «Сотрудник» построена связь
«многие ко многим», так как одну услугу может выполнять несколько сотрудников,
а один сотрудник может выполнять несколько услуг. Аналогичные рассуждения
положены в основу связи между сущностями «Услуга в заявке» и «Партнер». Связи
построены с помощью ассоциативной сущности «Исполнитель услуги». Связь
между сущностями «Сотрудник» - «Исполнитель услуги» и «Партнер» «Исполнитель услуги» неидентифицирующая с возможностью null-значения,
поскольку услуга оказывается либо сотрудником, либо представителем партнера.
2.1.3 Нормализация концептуальной схемы базы данных
Нормализация – процесс проверки и реорганизации сущностей и атрибутов с
целью удовлетворения требований к реляционной модели данных. Нормализация
позволяет быть уверенным, что каждый атрибут определен для своей сущности,
значительно сократить объем памяти для хранения информации и устранить
аномалии в организации хранения данных. В результате проведения нормализации
должна быть создана структура данных, при которой информация о каждом факте
хранится
только
в
одном
месте.
Процесс
нормализации
сводится
к
последовательному приведению структуры данных к нормальным формам формализованным требованиям к организации
данных. Известны
нормальных форм [18]:
− первая нормальная форма (1NF);
− вторая нормальная форма (2NF);
− третья нормальная форма (3NF);
− нормальная форма Бойса - Кодда (усиленная 3NF);
− четвертая нормальная форма (4NF);
− пятая нормальная форма (5NF).
шесть
27
Основные критерии первой нормальной формы (1NF):
1. Все строки должны быть различными.
2. Все элементы внутри ячеек должны быть атомарными (не списками).
Элемент является атомарным, если его нельзя разделить на части, которые могут
использовать в таблице независимо друг от друга.
Можно утверждать, что схема БД соответствует первой нормальной форме,
поскольку значения доменов всех атрибутов являются атомарными, то есть в
приложении не будут использоваться по частям. Чтобы выполнялось это условие,
некоторые первоначально выделенные атрибуты были разбиты на несколько
частей. Например, так вместо атрибута «ФИО» сущности «Сотрудник», «Клиент»
и «Партнер» выделены атомарные атрибуты «Фамилия», «Имя» и «Отчество».
Основные критерии второй нормальной формы (2NF):
1. Таблица должна находиться в первой нормальной форме.
2. Любое её поле, не входящее в состав первичного ключа, функционально
полно зависит от первичного ключа.
Анализ отношений схем, имеющих составные ключи, позволяет сделать
вывод о том, что она удовлетворяет и требованиям второй нормальной формы, то
есть каждый не первичный атрибут полностью зависит от ключа, частичных
зависимостей не выявлено.
Основные критерии третьей нормальной формы (3NF):
1. Таблица находится во второй нормальной форме.
2. Любой её не ключевой атрибут функционально зависит только от
первичного ключа.
Так как ни один из не первичных атрибутов не является транзитивно
зависимым от ключа и схема находится во второй нормальной форме, то отсюда
следует вывод, что она находится и в третьей нормальной форме.
Таким образом, поскольку при проектировании концептуальной схемы
особое внимание уделялось предупреждению возникновения предпосылок для
аномалий, была получена нормализованная схема, находящаяся, согласно
приведенным выше рассуждениям, в третьей нормальной форме.
28
Перейдем к разработке физической модели базы данных.
2.1.4 Разработка физической модели базы данных
Целевая СУБД, имена объектов и типы данных, индексы составляют второй
(физический)
уровень модели ERwin.
ERwin
предоставляет возможности
создавать и управлять этими двумя различными уровнями представления одной
диаграммы (модели), равно как и иметь много вариантов отображения на каждом
уровне.
Для построения физической модели данных необходимо каждому атрибуту
задать тип данных. Для этого каждому текстовому атрибуту в зависимости от его
назначения поставим в соответствие тип VARCHAR(200), VARCHAR(1000) и
VARCHAR(10000), каждому целочисленному атрибуту поставим в соответствие
тип INTEGER, каждому атрибуту даты и времени поставим в соответствие тип
DATE, каждому атрибуту метки поставим в соответствие тип BLOB.
Для каждой сущности определены альтернативные ключи и инверсионные
входы.
Физический уровень концептуальной схемы базы данных представлен на
рисунке А.1 Приложения А.
2.2 Разработка ограничений целостности базы данных
Целостность – понимается как правильность данных в любой момент
времени. Но эта цель может быть достигнута лишь в определенных пределах:
СУБД не может контролировать правильность каждого отдельного значения,
вводимого в базу данных (хотя каждое з начение можно проверить на
правдоподобность).
Все ограничения целостности можно разделить на три большие категории:
1. Первая категория – средства обеспечения доменной целостности. Они
отвечают за то, чтобы в соответствующем поле базы данных были допустимые
значения. Например, фамилия, как правило, должна состоять из букв, а почтовый
29
индекс – из цифр. В базах данных такая целостность обычно обеспечивается
условиями на значение, запретом пустых значений, триггерами и хранимыми
процедурами, а также ключами.
2. Вторая категория – сущностная целостность. Главная задача здесь –
сделать так, чтобы данные об одной сущности не попали в базу данных два раза.
Обеспечивается ограничением уникальности и первичным ключом.
3. Третья категория – ссылочная целостность, обеспечивается системой
первичных и внешних ключей. Например, при помощи этих средств можно
гарантировать, что у нас не будет зарегистрировано работ, не относящихся ни к
одной заявке.
Требования
описанных
выше
категории
ограничений
целостности
спроектированной нами БД соблюдаются, рассмотрим еще две большие категории,
на которые можно поделить средства обеспечения целостности – средства
декларативного и процедурного характера.
Средства декларативного характера создаются как составные части объектов
при их определении в базе данных (например, условие на значение при
определении таблицы в БД).
Для
обеспечения
доменной
целостности
необходимо
определить
ограничения целостности доменов некоторых атрибутов.
Атрибут «Стоимость» сущности «Услуга» и «Услуга в заявке» не может
принимать отрицательное значение:
ALTER TABLE Service
ADD CHECK ((Price>0) or (Price=0)
ALTER TABLE «Service_in_request»
ADD CHECK ((Price>0) or (Price=0))
Аналогично атрибут «Сумма» сущности «Оплата» не может принимать
отрицательное значение:
ALTER TABLE Payment
ADD CHECK ((Amount>0) or (Amount=0)
30
Атрибут «Статус» таблицы «Статус выполнения» может принимать одно из
значений («не выполнялась», «в работе», «исполнена»):
CREATE DOMAIN Status_domain AS VARCHAR(14)
check (value in (“не выполнялась”, “в работе”, “ исполнена”))
В данном домене происходит наложение ограничения, при котором атрибут,
которому будет присвоен домен, может принимать указанные значения.
CREATE TABLE Status (Status Status_domain NOT NULL)
В данном случае показано, что атрибут Status сущности Status
может
принимать значения домена STATUS.
Атрибут «Наименование» таблицы «Роль в системе» может принимать одно
из значений («Администратор системы», «Сотрудник», «Клиент»):
CREATE DOMAIN Rule_domain AS VARCHAR(21)
check (value in (“Администратор системы”, “Сотрудник”, “Клиент”))
В данном домене происходит наложение ограничения, при котором атрибут,
которому будет присвоен домен, может принимать указанные значения.
CREATE TABLE Rule (Name_rule Rule_domain NOT NULL)
В данном случае показано, что атрибут Name_rule сущности Rule может
принимать значения домена Rule_domain.
Средства процедурного характера (триггеры и хранимые процедуры)
реализуются как отдельные программные модули. В общем случае декларативные
ограничения менее функциональны, но более экономны с точки зрения ресурсов и
наоборот. Так с помощью триггеров СУБД InterBase поддерживается ссылочная
целостность. По умолчанию ERWin генерирует триггеры, дублирующие
декларативную ссылочную целостность, при котором СУБД только следит за тем,
чтобы в таблицу с внешним ключом нельзя было вставить некорректные значения
или – при попытке сделать это возникает ошибка. В случае необходимости
настройки можно изменить.
Для этого необходимо определить одну из стратегий поддержания ссылочной
целостности, использующуюся при выполнении нарушающих ссылочную
целостность операциях:
31
1) RESTRICT (ОГРАНИЧИТЬ) – не разрешать выполнение операции,
приводящей к нарушению ссылочной целостности;
2) CASCADE (КАСКАДИРОВАТЬ) – разрешить выполнение требуемой
операции, но внести при этом необходимые поправки в других отношениях так,
чтобы не допустить нарушения ссылочной целостности и сохранить все
имеющиеся связи;
3) SET NULL (УСТАНОВИТЬ В NULL) – разрешить выполнение требуемой
операции, но все возникающие некорректные значения внешних ключей изменять
на null-значения.
Определим операции, нарушающие ссылочную целостность, и принятые
нами стратегии ограничения ссылочной целостности (таблица 1).
Таблица 1 – Стратегии ограничения ссылочной целостности
Операция
Стратегия
Обновление кортежа в родительском отношении
CASCADE
Удаление кортежа в родительском отношении
RESTRICT
Вставка кортежа в дочернее отношение
RESTRICT
Обновление кортежа в дочернем отношении
RESTRICT
Пример используемого триггера, реализующего стратегию CASCADE при
обновлении кортежа в таблице «Клиент»:
CREATE TRIGGER tU_Client FOR Client AFTER UPDATE AS
DECLARE VARIABLE numrows INTEGER;
BEGIN
IF
(OLD.Num_client <> NEW.Num_client) THEN
BEGIN
update Request
set
Request.Num_client = NEW.Num_client
32
where
Request.Num_client = OLD.Num_client;
END
Триггер проверяет, изменялся ли первичный ключ записи при модификации,
и, если изменялся, то производит изменение внешнего ключа в соответствующих
кортежах зависимой сущности «Заявки».
Аналогичным образом осуществлены ограничения ссылочной целостности и
для ряда других случаев (реализованы триггеры, поддерживающие стратегию
CASCADE при обновлении кортежей родительской сущности):
−
при обновлении кортежей сущности «Тип» изменяются значения
внешних полей в зависимых кортежах сущностей «Клиент», «Партнеры»;
−
при обновлении кортежей сущности «Должность» изменяются значения
внешних полей в зависимых кортежах сущности «Должность сотрудника»;
−
при обновлении кортежей сущности «Сотрудник» изменяются значения
внешних полей в зависимых кортежах сущностей «Сотрудник в консультации»,
«Должность сотрудника» и «Исполнитель услуги»;
−
при обновлении кортежей сущности «Заявка» изменяются значения
внешних полей в зависимых кортежах сущностей «Документ», «Оплата», «Услуга
в заявке», «Консультация»;
−
при обновлении кортежей сущности «Услуга» изменяются значения
внешних полей в зависимых кортежах сущности «Услуга в заявке»;
−
при обновлении кортежей сущности «Услуга в заявке» изменяются
значения внешних полей в зависимых кортежах сущностей «Статус выполнения
услуги» и «Исполнитель услуги»;
−
при обновлении кортежей сущности «Консультация» изменяются
значения внешних полей в зависимых кортежах сущности «Сотрудник в
консультации»;
−
при обновлении кортежей сущности «Статус выполнения» изменяются
значения внешних полей в зависимых кортежах сущности «Статус выполнения
33
услуги».
Рассмотрим случай применения стратегии RESTRICT при удалении
кортежей родительской сущности. Например, триггер, реализующий стратегию
RESTRICT при удалении кортежа в родительском отношении «Оплата». При этом
проверяется, есть ли связанные с удаляемым кортежем кортежи в дочернем
отношении «Заявка», и в случае их наличия операция удаления отменяется,
пользователю выводится соответствующее исключение:
CREATE TRIGGER tD_Service FOR Service AFTER DELETE AS
DECLARE VARIABLE numrows INTEGER;
BEGIN
select count(*)
from Service_in_request
where
Service_in_request.Num_service = OLD.Num_service into numrows;
IF (numrows > 0) THEN
BEGIN
EXCEPTION ERWIN_PARENT_DELETE_RESTRICT;
END
END
Аналогичным образом осуществлены ограничения ссылочной целостности и
для ряда других случаев (реализованы триггеры, поддерживающие стратегию
RESTRICT при удалении кортежей родительской сущности):
− при удалении кортежей сущности «Должность» происходит проверка на
наличие зависимых кортежей в сущности «Должность сотрудника», если таковые
имеются, выводится соответствующее сообщение об ошибке, и удаление кортежа
отменяется;
− при удалении кортежей сущности «Роль в системе» происходит проверка
на наличие зависимых кортежей в сущности «Сотрудник» и «Клиент», если
таковые имеются, выводится соответствующее сообщение об ошибке, и удаление
кортежа отменяется;
34
− при удалении кортежей сущности «Заявка» происходит проверка на
наличие зависимых кортежей в сущности «Должность сотрудника», если таковые
имеются, выводится соответствующее сообщение об ошибке, и удаление кортежа
отменяется;
− при удалении кортежей сущности «Сотрудник» происходит проверка на
наличие зависимых кортежей в сущностях «Сотрудник в консультации»,
«Должность сотрудника» и «Исполнитель услуги», если таковые имеются,
выводится соответствующее сообщение об ошибке, и удаление кортежа
отменяется;
− при удалении кортежей сущности «Заявка» происходит проверка на
наличие зависимых кортежей в сущностях «Предоставленные документы»,
«Результативные документы», «Оплата», «Услуга в заявке», «Консультация», если
таковые имеются, выводится соответствующее сообщение об ошибке, и удаление
кортежа отменяется;
− при удалении кортежей сущности «Услуга» происходит проверка на
наличие зависимых кортежей сущности «Услуга в заявке», если таковые имеются,
выводится соответствующее сообщение об ошибке, и удаление кортежа
отменяется;
− при удалении кортежей сущности «Услуга в заявке» происходит проверка
на наличие зависимых кортежей в сущностях «Статус выполнения услуги» и
«Исполнитель услуги», если таковые имеются, выводится соответствующее
сообщение об ошибке, и удаление кортежа отменяется;
− при удалении кортежей сущности «Консультация» происходит проверка
на наличие зависимых кортежей в сущности «Сотрудник в консультации», если
таковые имеются, выводится соответствующее сообщение об ошибке, и удаление
кортежа отменяется;
− при удалении кортежей сущности «Статус выполнения» происходит
проверка на наличие зависимых кортежей в сущности «Статус выполнения
услуги», если таковые имеются, выводится соответствующее сообщение об
35
ошибке, и удаление кортежа отменяется.
Рассмотрим случай применения стратегии RESTRICT при вставке кортежей
дочерней сущности. Например, триггер, реализующий стратегию RESTRICT при
вставке кортежа в дочернее отношение «Клиент». При этом проверяется, есть ли
связанные со вставляемым кортежем кортежи в родительском отношении «Тип», и
в случае их отсутствия операция вставки отменяется, пользователю выводится
соответствующее исключение:
CREATE TRIGGER tI_Client FOR Client AFTER INSERT AS
DECLARE VARIABLE numrows INTEGER;
BEGIN
select count(*)
from Type
where
NEW.Num_type = Type.Num_type into numrows;
IF (
numrows = 0
) THEN
BEGIN
EXCEPTION ERWIN_CHILD_INSERT_RESTRICT;
END
Исключение:
CREATE
EXCEPTION
ERWIN_CHILD_INSERT_RESTRICT
"Cannot
INSERT Child table because Parent table does not exist."
Аналогичным образом осуществлены ограничения ссылочной целостности и
для ряда других случаев (реализованы триггеры, поддерживающие стратегию
RESTRICT при вставке кортежей дочерних сущностей):
− при вставке кортежей дочерней сущности «Партнер» проверяется, есть ли
связанные со вставляемым кортежем кортежи в родительском отношении «Тип»;
36
− при вставке кортежей дочерней сущности «Документ» проверяется, есть
ли связанные со вставляемым кортежем кортежи в родительских отношениях
«Клиент» и «Заявка»;
− при вставке кортежей дочерней сущности «Сообщение» проверяется,
есть ли связанные со вставляемым кортежем кортежи в родительских отношениях
«Клиент», «Сотрудник» и «Заявка»;
− при вставке кортежей дочерней сущности «Услуга в заявке» проверяется,
есть ли связанные со вставляемым кортежем кортежи в родительских отношениях
«Услуга» и «Заявка»;
− при вставке кортежей дочерней сущности «Статус выполнения услуги»
проверяется, есть ли связанные со вставляемым кортежем кортежи в родительских
отношениях «Услуга в заявке» и «Статус выполнения»;
− при вставке кортежей дочерней сущности «Исполнитель услуги»
проверяется, есть ли связанные со вставляемым кортежем кортежи в родительских
отношениях «Услуга в заявке», «Сотрудник» и «Партнер»;
− при вставке кортежей дочерней сущности «Должность сотрудника»
проверяется, есть ли связанные со вставляемым кортежем кортежи в родительских
отношениях «Должность» и «Сотрудник»;
− при вставке кортежей дочерней сущности «Оплата» проверяется, есть ли
связанные со вставляемым кортежем кортежи в родительском отношении
«Заявка»;
− при вставке кортежей дочерней сущности «Сотрудник в консультации»
проверяется, есть ли связанные со вставляемым кортежем кортежи в родительских
отношениях «Консультация» и «Сотрудник»;
− при вставке кортежей дочерней сущности «Консультация» проверяется,
есть ли связанные со вставляемым кортежем кортежи в родительском отношении
«Заявка».
Рассмотрим случай применения стратегии RESTRICT при обновлении
кортежей дочерней сущности. Например, триггер, реализующий стратегию
37
RESTRICT при обновлении кортежа в дочернем отношении «Оплата». При этом
проверяется, есть ли вставляемое значение внешнего ключа таблицы «Оплата»
среди первичных ключей родительской сущности «Заявка», и в случае его
отсутствия обновление отменяется:
CREATE TRIGGER tU_Payment FOR Payment AFTER UPDATE AS
DECLARE VARIABLE numrows INTEGER;
BEGIN
select count(*)
from Request
where
NEW.Num_request = Request.Num_request into numrows;
IF (
numrows = 0
) THEN
BEGIN
EXCEPTION ERWIN_CHILD_UPDATE_RESTRICT;
END
END
Исключение:
CREATE EXCEPTION ERWIN_CHILD_ UPDATE_RESTRICT "Cannot
UPDATE Child table because Parent table does not exist."
Аналогичным образом осуществлены ограничения ссылочной целостности и
для
ряда
других
случаев
описанных
выше
(реализованы
триггеры,
поддерживающие стратегию RESTRICT при обновлении кортежей дочерних
сущностей).
2.3 Алгоритмы обработки данных
При разработке информационной системы использовано множество
алгоритмов обработки данных.
38
Приведем описание некоторых из них, для этого воспользуемся построением
блок-схем:
1. Алгоритм формирования перечня предоставленных клиентом документов
по заявке. Используется клиентом и сотрудником для просмотра списка
документов по заявке (рисунок 10).
Работа алгоритма:
1) Выбрать заявку.
2) Выбрать из БД информацию о предоставленных документах по данной
заявке. SQL-запрос в БД имеет вид:
select *
from Documents_catalog D_c, Document D
where (D_c.num_document= D.num_document) and
(D.num_request=’текущее значение’) and (D.type=true)
Рисунок 10 – Схема алгоритма формирования перечня предоставленных клиентом
документов по заявке
39
2. Алгоритм формирования перечня неисполненных на текущий момент
заявок, по которым есть оплата (рисунок 11)
Работа алгоритма:
1) Выбрать из БД информацию обо всех заявках, по которым есть оплата.
SQL-запрос в БД имеет вид:
select *
from Request R, Payment P
where (R.num_request = P.num_request) and (P.amount >0)
2) Проверить, есть ли записи в результате запроса.
3) Если записей нет, вывести сообщение «Оплаченных заявок не
зарегистрировано» и завершить работу алгоритма. Если записи есть, то запустить
цикл по всем записям-заявкам:
− выбрать из БД информацию об услугах, относящихся к заявке. SQLзапрос в БД имеет вид:
select *
from Service S, Service_in_request S_R
where (S_R.num_request=’текущее значение’) and (S_R.num_service=
S.num_service)
− проверить, есть ли записи в результате запроса. Если записей нет, то
перейти к следующей записи о заявке. Если записи есть, то запустить цикл по всем
записям:
- выбрать из БД информацию о статусах услуги. SQL-запрос в БД имеет
вид:
select *
from Status S, Status_service S_s, Service_in_request S_R
40
where (S.num_status= S_s.num_status) and
(S_R.num_request=S_s.num_request) and (S_R.num_service=S_s.num_ service) and
(S_s.num_service=’текущее значение’) and
(S_s.num_request=’текущее значение’)
- проверить, есть ли записи в результате запроса. Если записей нет, то
перейти к следующей записи об услуге. Если записи есть, то проверить, есть ли
среди записей статус «Исполнена». Если есть, то перейти к следующей услуге, если
нет, то вывести информацию о текущей заявке и услуге.
Рисунок 11 – Схема алгоритма формирования перечня неисполненных на
текущий момент заявок, по которым есть оплата
41
3. Алгоритм вывода информации о статусе заявок клиента (Рисунок 12).
Работа алгоритма вывода информации о статусе заявок клиента:
1) Выбрать из БД информацию обо всех заявках клиента:
select Num_treaty, Num_ref, First_information
from Request
where Num_client=’текущее значение’
2) Проверить, есть ли записи в результате запроса.
3) Если записей нет, т.е. у клиента заявок не зарегистрировано, вывести
сообщение «Заявок не зарегистрировано». Если записи есть, то запустить цикл по
всем записям:
a) выбрать из БД информацию об услугах, включенных в заявку.
SQL-запрос в БД имеет вид:
b) select *
c) from Service_in_request S_R, Service S
d) where (S_R. num_request =’текущее значение’) and
(S_R.num_service =S. num_service)
e) если записей нет, то перейти к следующей записи о заявке. Если
записи есть, то запустить цикл по всем записям:
f) выбрать из БД информацию о последнем по дате статусе услуги.
SQL-запрос в БД имеет вид:
select Status
from Status S, Status_service S_s
where (S.num_status= S_s. num_status) and (S_s.num_service =’текущее
значение’) and (S_s. num_request=’текущее значение’) and (S_s.Date=(
select Max(Date)
from S__s
42
where (num_service=’текущее значение’) and (num_request=’текущее
значение’))
Рисунок 12 – Схема алгоритма вывода информации о статусе заявок клиента
43
4. Алгоритм формирования отчета о выполненных в полном объеме, но не
оплаченных заявках (рисунок 13).
Рисунок 13 – Схема алгоритма формирования отчета о выполненных в полном
объеме, но не оплаченных заявках
Работа алгоритма формирования отчета о выполненных в полном объеме, но
не оплаченных заявках:
1. Выбрать из БД информацию обо всех исполненных заявках. Работа
данной подпрограммы аналогична рассмотренному в алгоритме №2 процессу
отбора записей об исполненных заявках.
2. Проверить, есть ли записи в результате запроса.
3. Если записей нет, вывести сообщение «Выполненных заявок нет».
4. Если записи есть, то запустить цикл по всем записям:
1) выбрать из БД информацию о сумме оплаты по заявке. SQL-запрос в БД
имеет вид:
select Sum(Amount)
44
from Payment
where num_request =’текущее значение’
2) выбрать из БД информацию о стоимости заявки. SQL-запрос в БД имеет
вид:
select Sum(Price)
from Service_in_request
where num_request =’текущее значение’
- сравнить стоимость заявки и сумму оплаты. Если оплата меньше
стоимости, то вывести информацию о заявке. Если нет, то перейти к следующей
записи и заявке.
5. Алгоритм №5 формирования отчет о запланированных консультациях, в
которых участвует выбранный сотрудник.
Работа алгоритма формирования отчета о запланированных консультациях,
в которых участвует выбранный сотрудник (Рисунок 2.6):
1) Выбрать сотрудника, для которого будет формироваться отчет.
2) Выбрать из БД информацию о запланированных консультациях для
данного сотрудника на будущий период времени. SQL-запрос в БД имеет вид:
select Date, Time, Text
from Worker W, Worker_consultation W_c, Consultation C
where (W.num_worker =W_c.num_worker) and (W_c.num_consultation =
C.num_consultation)and (W_c. num_worker=’текущее значение’)and
(C.Date>=’текущая дата’) and (C.Time>=’текущее время’) and (C.Mark false)
3) Проверить, есть ли записи в результате запроса.
4) Если
записей
нет,
вывести
сообщение
«Консультаций
запланировано».
5) Если записи есть, то запустить цикл по всем записям:
a) вывести информацию о консультации;
не
45
b) выбрать из БД информацию о заявке, относящейся к консультации.
SQL-запрос в БД имеет вид:
select *
from Request R, Consultation C
where (C.num_request =R.num_request)and (R.num_request=’текущее
значение’)
c) вывести информацию о заявке;
d) выбрать из БД информацию об услугах, относящихся к заявке. SQLзапрос в БД имеет вид:
select *
from Service S, Service_in_request S_R
where (S_R.num_request=’текущее значение’) and (S_R.num_service=
S.num_service)
e) проверить, есть ли записи в результате запроса;
f) если записей нет, переходим к следующей записи о консультации;
g) если записи есть, то запустить цикл по всем записям:
− вывести информацию об услуге;
− выбрать из БД информацию об исполнителях услуги. SQL-запрос в БД
имеет вид:
select *
from Worker W, Executor_service E_s, Partner P
where ((W.num_worker= E_s.num_worker) or (P.num_partner= E_s.num_
partner)) and (E_s.num_ request=’текущее значение’) and (E_s. num_service
=’текущее значение’)
− проверить, есть ли записи в результате запроса;
− если записей нет, переходим к следующей записи об услуге;
− если записи есть, то запустить цикл по всем записям:
вывести информацию об исполнителе.
46
Рисунок 14 – Схема алгоритма формирования отчета о запланированных
консультациях, в которых участвует выбранный сотрудник
47
2.4 Управление доступом к ресурсам информационной системы
Данные в БД являются разделяемым ресурсом. Многопользовательский
доступ к данным подразумевает одновременное выполнение двух и более запросов
к одним и тем же объектам данных (таблицам, блокам и т.п.). Для организации
одновременного доступа не обязательно наличие многопроцессорной системы. На
однопроцессорной ЭВМ запросы выполняются не одновременно, а параллельно.
Для каждого запроса выделяется некоторое количество процессорного времени
(квант времени), по истечении которого выполнение запроса приостанавливается,
он ставится в очередь запросов, а на выполнение запускается следующий по
очереди запрос. Таким образом, процессорное время делится между запросами, и
создаётся иллюзия, что запросы выполняются одновременно.
Все команды работы с данными выполняются в рамках транзакций. Для
каждого сеанса связи с БД в каждый момент времени может существовать
единственная транзакция или не быть ни одной транзакции. Транзакции в
многопользовательской БД должны быть изолированы друг от друга. В реальности
транзакции выполняются одновременно и могут влиять на результаты друг друга,
если они обращаются к одному и тому же набору данных и хотя бы одна из
транзакций изменяет данные.
В общем случае взаимовлияние транзакций может проявляться в виде:
− потери изменений;
− чернового чтения;
− неповторяемого чтения;
− повторяемое чтение;
− фантомов.
Потеря изменений могла бы произойти при одновременном обновлении
двумя и более транзакциями одного и того же набора данных.
Ситуация чернового чтения возникает, когда транзакция считывает
изменения, вносимые другой (незавершенной) транзакцией. Если эта вторая
транзакция не будет зафиксирована, то данные, полученные в результате чернового
48
чтения, будут некорректными. Транзакции, осуществляющие черновое чтение,
могут использоваться только при невысоких требованиях к согласованности
данных: например, если транзакция считает статистические показатели, когда
отклонения отдельных значений данных слабо влияют на общий результат.
При повторяемом чтении один и тот же запрос, повторно выполняемый
одной транзакцией, возвращает один и тот же набор данных (т.е. игнорирует
изменения, вносимые другими завершёнными и незавершёнными транзакциями).
Неповторяемое чтение является противоположностью повторяемого, т.е.
транзакция
«видит»
изменения,
внесённые
другими
(завершёнными)
транзакциями. Следствием этого может быть несогласованность результатов
запроса, когда часть данных запроса соответствует состоянию БД до внесения
изменений, а часть – состоянию БД после внесения и фиксации изменений.
Фантомы – это особый тип неповторяемого чтения. Возникновение фантомов
может происходить в ситуации, когда одна и та же транзакция сначала производит
обновление набора данных, а затем считывание этого же набора. Если считывание
данных начинается раньше, чем закончится их обновление, то в результате чтения
можно получить несогласованный (не обновлённый или частично обновлённый)
набор данных. При последующих запросах это явление пропадает, т.к. на самом
деле запрошенные данные после завершения обновления будут согласованными в
соответствие со свойствами транзакции.
Разделение прав доступа пользователей к информации, хранящейся в базе
данных, должно производиться на основании ролей, определенных в системе. В
системе должны быть реализованы следующие роли пользователей:
1. Администратор системы (директор, заместитель директора).
2. Сотрудник (юрисконсульты, адвокаты и т.д.).
3. Клиент.
Роли и доступные функции пользователей системы описаны в таблице 2.
Для того что бы избежать взаимовлияния транзакций, роли настроены таким
образом, что для каждого сотрудника и клиента были доступны заявки и услуги,
относящиеся к ним.
49
Таблица 2.2 – Роли и доступные функции пользователей системы
Наименование
роли
Доступные функции в системе
настройка системы;
определение основных параметров функционирования системы;
ведение каталогов данных (клиенты, партнеры, заявки, услуги,
сотрудники, должности, оплата, консультации, роли в системе и т.д);
регистрация новых заявок;
Администратор регистрация консультаций;
системы
назначение исполнителей услуг;
изменение статуса услуг;
загрузка документов по заявке;
автоматизированное формирование документов по заявке;
формирование отчетов;
просмотр чатов по всем заявкам, возможность добавления сообщений.
просмотр консультаций, в которых он участвует;
изменение статуса консультаций;
просмотр заявок и услуг, исполнителем по которым он является;
изменение статуса услуг;
Сотрудник
загрузка, просмотр и скачивание документов, относящихся к заявке;
автоматизированное формирование документов по заявке;
формирование отчетов;
просмотр чатов по своим заявкам, возможность добавления сообщений.
просмотр ограниченной информации о заявках (номер и скан-копия
договора, номер и описание заявки);
просмотр ограниченной информации о входящих в состав заявки услугах
(наименование, стоимость, дополнительное описание, текущий статус и
Клиент
дата его установки);
загрузка, просмотр и скачивание документов, относящихся к заявке;
проверка документов по штрих-коду;
просмотр чатов по своим заявкам, возможность добавления сообщений.
2.5 Архитектура информационной системы
Перейдем к рассмотрению архитектуры информационной системы –
концепции, которая определяет компоненты системы и их взаимосвязь. С точки
зрения программно-аппаратной реализации можно выделить ряд типовых
архитектур ИС:
1) файл-серверная архитектура;
2) двухуровневая клиент-серверная архитектура;
3) трехуровневая клиент-серверная архитектура.
50
Для выбора подходящей архитектуры разрабатываемой системы необходимо
определить достоинства и недостатки каждой архитектуры и выбрать оптимальный
для решаемого класса задач вариант.
Файл-серверные приложения — приложения, схожие по своей структуре с
локальными приложениями и использующие сетевой ресурс для хранения
программы и данных.
Функции сервера: хранения данных и кода программы. Функции клиента:
обработка данных происходит исключительно на стороне клиента. Количество
клиентов ограничено десятками.
Плюсами является многопользовательский режим работы с данными,
удобство централизованного управления доступом и низкая стоимость разработки.
Минусами
является
низкая
производительность
и
надежность,
слабые
возможности расширения.
Недостатки архитектуры с файловым сервером очевидны и вытекают
главным образом из того, что данные хранятся в одном месте, а обрабатываются в
другом. Это означает, что их нужно передавать по сети, что приводит к очень
высоким
нагрузкам
производительности
на
сеть
и,
приложения
вследствие
при
этого,
увеличении
резкому
числа
снижению
одновременно
работающих клиентов. Вторым важным недостатком такой архитектуры является
децентрализованное решение проблем целостности и согласованности данных и
одновременного доступа к данным. Такое решение снижает надежность
приложения.
Ключевым отличием архитектуры клиент-сервер от архитектуры файлсервер
является
абстрагирование от
внутреннего
представления
данных
(физической схемы данных). Клиентские программы манипулируют данными на
уровне логической схемы.
Итак, использование архитектуры клиент-сервер позволило создавать
надежные (в смысле целостности данных) многопользовательские ИС с
централизованной базой данных, независимые от аппаратной (а часто и
программной) части сервера БД и поддерживающие графический интерфейс
51
пользователя на клиентских станциях, связанных локальной сетью. Причем
издержки на разработку приложений существенно сокращались.
Основные особенности:
1. Клиентская программа работает с данными через запросы к серверному
ПО.
2. Базовые функции приложения разделены между клиентом и сервером.
Плюсы:
3. Полная поддержка многопользовательской работы.
4. Гарантия целостности данных.
Минусы:
1. Бизнес логика приложений осталась в клиентском ПО. При любом
изменении алгоритмов, надо обновлять пользовательское ПО на каждом клиенте.
2. Высокие требования к пропускной способности коммуникационных
каналов с сервером, что препятствует использование клиентских станций иначе как
в локальной сети.
3. Слабая защита данных от взлома, в особенности от недобросовестных
пользователей системы.
4. Высокая сложность администрирования и настройки рабочих мест
пользователей системы.
5. Необходимость использовать мощные ПК на клиентских местах.
6. Высокая сложность разработки системы из-за необходимости выполнять
бизнес-логику и обеспечивать пользовательский интерфейс в одной программе.
Нетрудно заметить, что большинство недостатков классической или
двухслойной
архитектуры
клиент-сервер
проистекают
от
использования
клиентской станции в качестве исполнителя бизнес-логики ИС. Поэтому
очевидным шагом дальнейшей эволюции архитектур ИС явилась идея «тонкого
клиента», то есть разбиения алгоритмов обработки данных на части связанные с
выполнением бизнес-функций и связанные с отображением информации в удобном
для человека представлении. При этом на клиентской машине оставляют лишь
вторую часть, связанную с первичной проверкой и отображением информации,
52
перенося всю реальную функциональность системы на серверную часть. Среди
существенных недостатков такой архитектуры выступают высокие расходы на
администрирование и обслуживание серверной части системы.
Для нашей системы выбрана трехуровневая клиент-серверная архитектура,
изображенная на рисунке 2.6. На клиентском уровне устанавливается любой из
современных web-браузеров: Internet Explorer, Opera, Firefox, Google Chrome и т.д.
Этот
уровень
содержит
только
простейшую
бизнес-логику:
интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на
допустимость и соответствие формату и пр. Взаимодействие клиентской и
серверной частей производится через сеть Internet.
Серверная часть включает сервер базы данных и сервер приложений.
Сервер приложений содержит большую часть бизнес-логики. Реализация
данного компонента обеспечивается связующим программным обеспечением
(далее - ПО). В качестве web-сервера предлагается использовать NGINX,
работающий на Unix-подобных операционных системах (далее – ОС). ОС Debian,
установленная на сервере, состоит из свободного ПО с открытым исходным кодом.
Сервер БД обеспечивает хранение данных, управляется СУБД MariaDB10.1-last,
являющаяся
ответвлением
от
СУБД
MySQL,
разрабатываемое
сообществом под лицензией GNU GPL. Разработку и поддержку MariaDB
осуществляет компания MariaDB Corporation Ab и фонд MariaDB Foundation.
Взаимодействие клиентской и серверной частей системы (архитектура
системы) изображено на рисунке 15.
Рисунок 15 – Архитектура системы
53
В качестве системы управления содержимым (CMS) и фреймворком для
веб-приложений, предлагается использовать систему MODX CMS, она является
бесплатной профессиональной системой управления содержимым, предназначена
для обеспечения и организации совместного процесса создания, редактирования и
управления контентом сайтов.
Для написания дополнительных скриптов предлагается использовать язык
php, являющийся лидером в качестве языка для создания динамических webстраниц.
2.6 Проектирование диалога: графическое представление диалога
При проектировании процесса взаимодействия пользователей с клиентским
приложением необходимо разработать логику диалога данного приложения с
пользователем. Поскольку в системе выделено 3 роли (Администратор системы,
Сотрудник и Клиент), необходимо для каждой роли разработать логику диалога
приложения с пользователем.
При проектировании диалога обычно определяется состояние системы.
Состояние – это устойчивое положение системы, в котором пользователь может
выполнять
определенные
действия.
Состояние
системы
характеризуется
контекстом. Контекст – это набор визуальных объектов, доступных пользователю
в соответствующем состоянии системы. Изменения контекста отображаются на
экране. Для пользователя приложение имеет вид формы с визуальными объектами.
Пользователь взаимодействует с объектами путем порождения событий. Формы
преобразуют события во входные сигналы модулей, т.е. не любое событие является
входным сигналом. В ответ на команду прикладной интерфейс генерирует
ответный сигнал. Одной из разновидностей этого сигнала является сообщение об
ошибке. Сигнал от прикладного интерфейса и входные сигналы пользователя
переводят модуль логики диалога из одного состояния в другое, изменяя при этом
контекст системы.
Одним из наиболее простых способов отражения логики диалога является
простая транзитивная сеть или сеть состояний и переходов. При таком подходе
54
состояния системы отображаются в виде окружностей и соединяются дугами.
Сверху дуги именуются согласно входным сигналам или обратной связи, снизу – в
зависимости от действия, которое система должна выполнить при переходе из
одного состояния в другое по определенному входному сигналу.
Среди состояний выделяют начальное (или стартовое), в котором система
находится в начале работы. Это состояние обозначается входной дугой, не
имеющей источника. Начальное состояние в системе может быть одно. Кроме того,
в транзитивной сети выделяются финальные состояния, попадая в которые система
завершает свою работу. Таких состояний может быть несколько. Финальные
состояния выделяются двойной обводкой.
Реализовать транзитивную сеть можно с использованием конечного
автомата, который описывается семеркой:
H (Q, , P, ,  , q0 , F ) ,
(1)
где Q – множество состояний;
 – множество входных сигналов;
P – множество команд;
 – функция переходов, которая определяет, в какое состояние должна
перейти система из текущего при определенном входном сигнале;
 – функция
прикладных
действий
(какое
действие
необходимо
осуществить);
q0 – начальное состояние системы ( q0  Q );
F – множество конечных состояний ( F  Q ).
На рисунке 16 представлена транзитивная сеть, иллюстрирующая диалог
администратора системы с приложением.
Пользователь с ролью «Администратор системы» имеет следующие
возможности: добавление, изменение и удаление данных в основных формах
приложения.
55
Рисунок 16 – Транзитивная сеть логики диалога приложения и
пользователя с ролью «Администратор системы»
Состояния интерфейса, обозначенные на транзитивной сети, описаны в
таблице 2.3.
Информация о входных сигналах, инициированных пользователем и
обуславливающих изменения состояний пользовательского интерфейса, и о
действиях системы, происходящих в ответ на эти сигналы, представлена в таблице
3.
Нужно отметить, что из состояний S4, S7, S8, S9, S10 возможет переход в
состояние S11 по сигналу 19, что на рисунке не отмечено.
56
Таблица 3 – Описание состояний транзитивной сети
Состояние
1
S
S1
S2
S3
S4
S5
S6
S7
S8
S9
S10
S11
S12
S13
S14
S15
S18
Описание
2
Стартовое
состояние.
Администратор
системы
имеет
возможность выполнить любое действие.
Форма авторизации. Осуществление входа в систему с помощью
логина и пароля.
Главное меню – окно выбора функциональных модулей.
Окно модуля справочников. Отображается полный перечень
справочников системы. Администратор имеет возможность
производить работу со справочниками в полном объеме.
Окно модуля заявок, вкладка «Основное». Администратор имеет
возможность производить работу с заявками в объеме
предоставляемого функционала: доступны данные о ФИО
клиента, номере дела, номере договора, ссылке на файл договора,
оплате.
Окно добавления и изменения данных справочника.
Администратор имеет возможность вводить и изменять данные
записи.
Окно подтверждения удаления записи.
Окно модуля заявок, вкладка «Услуги в заявке». Администратор
имеет возможность производить работу с заявками в объеме
предоставляемого функционала: доступны данные об услугах и
поле «Описание».
Окно модуля заявок, вкладка «Документы». Администратор имеет
возможность производить работу с заявками в объеме
предоставляемого функционала: доступны данные о документах.
Окно модуля заявок, вкладка «Консультации». Администратор
имеет возможность производить работу с заявками в объеме
предоставляемого функционала.
Окно модуля заявок, вкладка «Чат». Администратор имеет
возможность производить работу с заявками в объеме
предоставляемого функционала: отображается история переписки
по заявке, возможно отправить сообщение.
Окно модуля заявок. Администратор имеет возможность
просмотреть заявки, отобрать их по фильтрам.
Окно проводника ОС. Администратор имеет возможность
выбрать каталог и файл на диске.
Окно добавления/изменения оплаты. Администратор имеет
возможность заполнить данные об оплате.
Окно добавления/изменения услуг. Администратор имеет
возможность заполнить данные об услуге.
Окно добавления/изменения исполнителя. Администратор имеет
возможность выбрать/изменить исполнителя услуги.
Окно добавления/изменения документов. Администратор имеет
возможность заполнить данные о документах.
57
Продолжение таблицы 3
1
S19
S20
F
2
Окно добавления/изменения консультации. Администратор имеет
возможность заполнить данные о консультации.
Окно добавления/изменения сотрудников в консультации.
Администратор имеет возможность заполнить данные о
сотрудниках.
Финальное состояние. Завершение работы с программой
Таблица 4 – Описание сигналов и действий, связанных с дугами транзитивной сети
Номер дуги
1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Сигнал
2
Вход в систему
Действие
3
Показать окно авторизации
Удачная авторизация. Переход к
Нажата кнопка «ОК»
главному меню
Неудачная
авторизация.
Нажата кнопка «ОК»
Отображение окна авторизации
Отобразить
окно
«Настройка
Выбрать модуль справочников
справочников»
Отобразить окно «Заявки» с полным
Выбрать модуль заявок
перечнем заявок
Обновить форму, вывести данные
Нажать на название справочника
выбранного справочника
Выбрать запись в справочнике, Отобразить
окно
нажать кнопку «Изменить»
изменения/добавления записи
Отобразить
окно
Нажать кнопку «Добавить»
изменения/добавления записи
Сохранить запись в БД, обновить
Нажать кнопку «Сохранить»
записи в окне
Вернуться в предыдущее состояние
Нажать кнопку «Отмена»
без сохранения изменений
Выбрать запись, нажать кнопку Отобразить окно подтверждения
«Удалить»
удаления
Удалить запись из БД, обновить
Нажать кнопку «ОК»
записи в окне просмотра справочника
Выбрать вкладу «Услуги в Отобразить вкладку «Услуги в
заявке»
заявке»
Выбрать вкладку «Документы»
Отобразить вкладку «Документы»
Выбрать
вкладку
Отобразить вкладку «Консультации»
«Консультации»
Выбрать вкладку «Чат»
Отобразить вкладку «Чат»
Нажать на фильтр «Выполненные
заявки», «Заявки в работе»,
Отфильтровать данные о заявках,
«Оплаченные
заявки
(к
обновить записи в окне
исполнению)», «Неоплаченные
заявки»
58
Продолжение таблицы 4
1
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
2
Выбрать заявку в списке; нажать
кнопку
«Просмотр»
или
«Добавить
заявку»
или
«Изменить заявку»
Закрыть окно модуля просмотра
заявки
Нажать на выпадающий список,
выбрать/изменить ФИО клиента
Заполнить текстовые поля
Нажать на кнопку «Загрузить»
Выбрать файл, нажать кнопку
«ОК»
Выбрать запись об оплате и
нажать кнопку «Изменить»;
нажать кнопку «Добавить»
Выбрать запись об услуге и
нажать кнопку «Изменить»;
нажать кнопку «Добавить»
Нажать на выпадающий список,
выбрать/изменить наименование
услуги/документа/сотрудника
Выбрать запись об исполнителе и
нажать кнопку «Изменить»;
нажать кнопку «Добавить»
Выбрать запись о документе и
нажать кнопку «Изменить»;
нажать кнопку «Добавить»
Выбрать запись о консультации и
нажать кнопку «Изменить»;
нажать кнопку «Добавить»
Ввести
сообщение,
нажать
кнопку «Отправить»
Нажать
кнопку
«Отмена»,
«Выход»
Закрыть окно модуля
Выбрать запись о сотруднике и
нажать кнопку «Изменить»;
нажать кнопку «Добавить»
3
Отобразить вкладку «Основное». В
случае нажатия кнопки «Просмотр»
поля являются нередактируемыми, в
остальных
случаях
–
редактируемыми
Отобразить окно «Заявки» с полным
перечнем заявок
Отобразить
список
клиентов,
зафиксировать выбранную запись
Зафиксировать данные в окне
Отобразить окно проводника ОС
Сохранить изменения, отобразить
вкладку «Основное»
Отобразить окно добавления оплаты
Отобразить окно добавления услуг
Отобразить список услуг/документа,
зафиксировать выбранную запись
Отобразить окно выбора исполнителя
Отобразить
документов
окно
добавления
Отобразить
консультации
окно
добавления
Сохранить запись в БД, обновить
сообщения в окне
Закрыть систему
Отобразить главное окно системы
Отобразить
окно
добавления/изменения сотрудников в
консультации
Логика диалога пользователей с ролью «Сотрудник» организована
аналогичным образом: при входе в систему пользователь получает возможность
работать в двух модулях: модуле справочников и модуле заявок. Функционал
модуля справочников предполагает просмотр справочников без возможности
добавления и редактирования записей. Логика диалога аналогична рассмотренной
59
выше. Функционал модуля заявок полностью совпадает с ролью «Администратор
системы» с той лишь разницей, что права доступа настроены таким образом, что
сотруднику всегда доступны заявки, в которых исполнителем и/или консультантом
является он. Логика диалога аналогична рассмотренной выше.
Логика диалога пользователей с ролью «Клиент» организована похожим
образом: при входе в систему пользователь получает возможность работать в
модуле заявок. Функционал модуля заявок является усеченным по сравнению с
рассмотренным выше: клиент может просматривать заявки, относящиеся к нему,
без возможности редактирования большинства полей, сохраняется возможность
загрузки и скачивания документов по заявке, скачивание договора, ведение чата.
В системе учета юридических и прочих услуг используется три вида
интерфейса: интерфейс для роли «Администратор системы», интерфейс для роли
«Сотрудник» и интерфейс для роли «Клиент» (рисунки 17-19).
Окно авторизации в системе показано на рисунке 17.
Рисунок 17 – Экранная форма окна авторизации в системе
Пользовательский интерфейс окна создания документа показан на рисунке
18.
60
Рисунок 18 – Экранная форма окна создания документа
Пользовательский интерфейс окна поиска документа по штрих-коду
показан на рисунке 19.
Рисунок 19 – Экранная форма окна поиска документа по штрих-коду
Интерфейсы реализованы в одном приложении, а выбор интерфейса
происходит при авторизации пользователя в системе.
61
ЗАКЛЮЧЕНИЕ
При подготовке выпускной квалификационной работы была разработана
информационная система сопровождения ведения дел в юридической фирме ООО
«Мерцлин и Партнёры». В ходе ее разработки были выполнены следующие этапы.
Во-первых, была проанализирована
деятельности организации ООО
«Мерцлин и Партнёры», произведен функциональный анализ предмета дипломной
работы – процесса учета оказания юридических и прочих услуг.
Во-вторых, с помощью стандарта IDEFХ была построена концептуальная
схема БД, проведена нормализация схемы БД, осуществлен переход к физической
модели БД, продумана архитектура системы.
В-третьих, были спроектированы алгоритмы обработки данных и основные
запросы, пользовательский интерфейс, на основании всего этого, в конечном итоге,
реализована информационная система учета сопровождения ведения дел.
Информационная система учета оказания юридических услуг, построеннаяю
с помощью программного продукта BPWin 4.1., позволяет автоматизировать
работу юридической фирмы «Мерцлин и Партнеры».
Преимущество
использования
информационной
системы
состоит
в
сокращении времени на обработку данных, по сравнению с ручной обработкой,
сокращением места для хранения информации, так как в бумажном виде та же
самая информация занимает большее пространство.
Информационная система учета оказания юридических услуг отличается
быстродействием,
оперативностью
обработки,
наглядным
и
удобным
интерфейсом.
Информационная система учета оказания юридических услуг выполняет
следующий перечень требований:
− организация учета обращений клиентов;
− организация учета клиентов;
− организация учета партнеров;
− организация учета договоров и соглашений об оказании услуг;
62
− организация учета оплаты клиентами услуг;
− организация учета информации и документов, образующихся при
оказании услуг;
− организация диалогового режима работы с клиентами;
− автоматизированное
формирование
юридического
заключения
с
присвоением уникального штрих-кода;
− возможность аналитической работы с данными.
Прогнозируемым результатом внедрения информационной системы учета
оказания юридических услуг является повышение производительности труда
сотрудников и партнеров юридической фирмы «Мерцлин и Партнеры», что будет
способствовать ускорению документооборота фирмы, за счет увеличения скорости
обработки информации.
63
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
1. Абрамов Г.В. Проектирование информационных систем: учебное пособие
/ Г.В. Абрамов, И.Е. Медведкова, Л.А. Коробова. – Электрон. текстовые данные. –
Воронеж: Воронежский государственный университет инженерных технологий,
2012. – 172 c.
2.
Болодурина
И.П.
Проектирование
компонентов
распределенных
информационных систем : учебное пособие / И.П. Болодурина, Т.В. Волкова. –
Электрон. текстовые данные. – Оренбург: Оренбургский государственный
университет, ЭБС АСВ, 2012. – 215 c.
3. Булгакова Е. В. Хранилище видеоархивов данных о динамических
признаках человека, предназначенное для решения криминалистических задач /
Е.В. Булгакова, В.Г. Булгаков // Правовая информатика. – 2013. – № 4. – С.28-31.
4. Виснадул Б.В. Технология разработки программного обеспечения / Б.В.
Виснадул, Л.И. Гагарина, Е.В. Кокорева. – М.: Инфра-М, 2018. − 400 с.
5. Воронова Л.И. Big Data. Методы и средства анализа: учебное пособие /
Л.И. Воронова, В.И. Воронов. —М. : Московский технический университет связи
и информатики, 2016. —33 c.
6.
Гвоздева
Т.В.
Проектирование
информационных
систем
/ Т.В. Гвоздева, Б.А. Баллод. – М.: Феникс, 2012. – 512 с.
7. Грекул В.И. Проектирование информационных систем. Курс лекций :
учебное пособие для студентов вузов, обучающихся по специальностям в области
информационных технологий / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. –
Москва,
Саратов:
Интернет-Университет
Информационных
Технологий
(ИНТУИТ), Вузовское образование, 2017. – 303 c.
8. Джатдоев А. Х. Информационные технологии в юриспруденции / А.Х.
Джатдоев // Молодой ученый. – 2018. – №6. – С. 20-24.
9.
Драпезо Р. Г. Краткий обзор ИТ-технологий, используемых в
юридической деятельности / Р.Г. Драпезо [и др. ]// Вестник КемГУ. – 2013. – № 3
(55). – С.306–312.
64
10. Золотов С.Ю. Проектирование информационных систем: учебное
пособие / С.Ю. Золотов.– Томск: Томский государственный университет систем
управления и радиоэлектроники, Эль Контент, 2013. – 88 c.
11. Интеллектуальные информационные системы и технологии : учебное
пособие / Ю.Ю. Громов [и др.]. — Тамбов: Тамбовский государственный
технический университет, ЭБС АСВ, 2013. — 244 c.
12. Ипатова, Э.Р. Методологии и технологии системного проектирования
информационных систем: учеб. пособие для вузов / Э.Р. Ипатова. - М.: ФЛИНТА,
2016. - 256 с.
13. Коцюба И.Ю. Основы проектирования информационных систем : учебное
пособие / И.Ю. Коцюба, А.В. Чунаев, А.Н. Шиков. – СПб. : Университет ИТМО,
2015. – 205 c.
14. Крахоткина Е.В. Методы и средства проектирования информационных
систем и технологий : учебное пособие / Е.В. Крахоткина. – Электрон. текстовые
данные. – Ставрополь: СевероКавказский федеральный университет, 2015. – 152 c.
15.
Латышев
Д.
С.
Краткий
обзор
информационных
технологий,
используемых в юридической деятельности / ДС. Латышев // Инновационная
наука. – 2017. – № 10. – С.14–17.
16. Маклаков С.В. BPwin и ERwin. CASE – средства разработки
информационных систем / С.В. Маклаков. – М.: Диалог-МИФИ, 2009. – 256 с.
17. Марчук В.И. Проблемы использования информационных технологий в
малом бизнесе / В.И. Марчук // Концепт. - 2015. - №5. [Электронный ресурс]. –
Режим
доступа:
http://cyberleninka.ru/article/n/problemy-ispolzovaniya-
informatsionnyh-tehnologiy-v-malom-biznese (дата обращения: 23.05.2018).
18. Масюк М. А. Анализ и визуализация взаимосвязей нормативно-правовых
документов в справочно-правовых системах / М.А. Масюк // Сибирский журнал
науки и технологий. – 2011. – № 2 (35). – С.40–45.
19. Митина О.А. Методы и средства проектирования информационных
систем и технологий : курс лекций / О.А. Митина. – М. : Московская
государственная академия водного транспорта, 2016. – 75 c.
65
20. Неудачин И.Г. Таблицы Delphi для управления базами данных : учебнометодическое пособие / И.Г. Неудачин.– Екатеринбург: Уральский федеральный
университет, 2016. – 96 c.
21. Олифер В. Г. Компьютерные сети. Принципы, технологии, протоколы /
В.Г. Олифер; Н.А. Олифер. – СПб.: Питер, 2015. – 864 с.
22.
Похилько
А. Ф.
CASE-технология
моделирования
процессов
с
использованием средств BPWin и ERWin / А. Ф. Похилько, И. В. Горбачев. –
Ульяновск: УлГТУ, 2013. – 120 с.
23.
Рак
И.
П.
Информационные
технологии
в
деятельности
правоохранительных органов / И.П. Рак // Инновационная наука. – 2016. – № 2–3
(14). – С.132–135.
24. Самуйлов К.Е. Основы формальных методов описания бизнес-процессов
: учебное пособие / К.Е. Самуйлов, А.В. Чукарин, С.Ю. Быков. –М. : Российский
университет дружбы народов, 2011. – 123 c.
25. Санников Е.В. Курс практического программирования в Delphi.
Объектно-ориентированное программирование
/ Е.В. Санников. – Электрон.
текстовые данные. – М. : СОЛОН-ПРЕСС, 2013. – 188 c.
26. Семененко Г. М. К вопросу эффективности применения информационнотелекоммуникационной технологии приема обращений граждан в органы
внутренних дел / Г.М. Семененко, И.А. Стрижченко // Символ науки. – 2015. – №
8. – С.215–218.
27. Стасышин В.М. Проектирование информационных систем и баз данных:
учебное
пособие/
Стасышин
В.М.—Новосибирск:
Новосибирский
государственный технический университет, 2012.—100 c.
28. Черненко В. В. Экспертные системы / В.В. Черненко, С.Ю. Пискорская //
Актуальные проблемы авиации и космонавтики. – 2012. – № 8. – С.322–323.
29. Чернышов В.Н. Системный анализ и моделирование при разработке
экспертных систем : учебное пособие / В.Н. Чернышов, А.В. Чернышов. –
Электрон. текстовые данные. – Тамбов: Тамбовский государственный технический
университет, ЭБС АСВ, 2012. – 128 c.
66
30. Официальный сайт организации ООО «Мерцлин и Партнёры».
[Электронный ресурс]. – Режим доступа: http://merclin.ru (дата обращения:
23.05.2018).
Физический уровень концептуальной схемы базы данных
Приложение А (обязательное)
67
69
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ
УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «ОРЛОВСКИЙ
ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ИМЕНИ И.С. ТУРГЕНЕВА»
ИНФОРМАЦИОННО-ПОИСКОВАЯ ХАРАКТЕРИСТИКА
ДОКУМЕНТА НА ЭЛЕКТРОННОМ НОСИТЕЛЕ
Наименование
группы атрибутов
атрибута
Обозначение документа
1. Описание
(идентификатор(ы)
документа
файла(ов))
Наименование документа
Класс документа
Вид документа
Аннотация
Использование документа
2. Даты и время
3. Создатели
4. Внешние
ссылки
5. Защита
6.
Характеристики
содержания
Дата и время копирования
документа
Дата создания документа
Дата утверждения
документа
Автор
Изготовитель
Ссылки на другие
документы
Санкционирование
Классификация защиты
Объем информации
документа
Характеристики документа
на электронном носителе
\Презентация.pptx
Демонстрационные плакаты
выпускной
квалификационной работе
ЕСКД
Оригинал документа на
электронном носителе
Демонстрационный
материал, отображающий
основные этапы выполнения
выпускной
квалификационной работы
Операционная система
Windows 10, Microsoft
PowerPoint 365
22.06.2018
22.06.2018
22.06.2018
Гуров Д.И.
Гуров Д.И.
Удостоверяющий лист
№ 130083/п
ОГУ имени И.С. Тургенева
По законодательству РФ
1362680 Б
70
7. Структура
документа(ов)
Наименование плаката
(слайда) №1
Наименование плаката
(слайда) №2
Наименование плаката
(слайда) №3
Наименование плаката
(слайда) №4
Титульный лист
Наименование плаката
(слайда) №5
Логический уровень
концептуальной схемы базы
данных
Наименование плаката
(слайда) №6
Наименование плаката
(слайда) №7
Алгоритмы обработки данных
Наименование плаката
(слайда) №8
Наименование плаката
(слайда) №9
Наименование плаката
(слайда) №10
Цель и задачи работы
Модель процессов предметной
области
Модель процессов предметной
области
Организация доступа к
разделяемым ресурсам
системы
Архитектура информационной
системы
Транзитивная сеть логики
диалога пользователя и
системы
Экранные формы
информационной системы
1/--страниц
Пожаловаться на содержимое документа