Клиент-серверные приложения баз данных. 1. Анализ задачи 2 1 Семантическое описание предметной области 2

Название	1. Анализ задачи 2 1 Семантическое описание предметной области 2
Анкор	Клиент-серверные приложения баз данных
Дата	02.06.2022
Размер	0.88 Mb.
Формат файла
Имя файла	Клиент-серверные приложения баз данных.docx
Тип	Анализ #563769

Содержание

1.Анализ задачи 2

1.1 Семантическое описание предметной области 2

1.2 Выявление потребностей пользователя ИС 3

2. Разработка серверной части информационной системы 4

2.1 Инфологическое проектирование БД 4

2.1.1 Выявление сущностей и связей 4

2.1.2 Построение ER-диаграмм 6

2.2 Даталогическое проектирование БД 11

2.2.1 Переход от ER диаграммы к предварительным отношениям 11

2.2.2 Заполнение предварительных отношений атрибутами 14

2.2.3 Проверка предварительных отношений на соответствие нормальным формам. 15

2.2.4 Построение схемы данных 18

4. Разработка клиентской части информационной системы. 19

4.1. Выбор режима работы с базой данных, согласно технологии ADO.NET. 19

4.2. Выбор среды программирования для разработки клиентского приложения 20

4.3. Разработка форм 23

5.Разработка программной документации 25

Список используемой литературы: 26

Анализ задачи

1.1 Семантическое описание предметной области

Предметная область - IT компания предоставляющая CRM (ERP) систему для автоматизации бизнеса в сфере услуг: Онлайн запись, складской учет, расчет заработной платы, ведение клиентской базы, рассылки, IP Телефония, работа с контрольно-кассовой техникой и тд.

Клиент переходит на сайт yclients.com и оставляет заявку для консультации специалиста по автоматизации (менеджера по продажам).
В зависимости от сферы бизнеса и размера организации, менеджер подбирает наиболее подходящий тариф которые отличаются по цене в зависимости от количества сотрудников и дополнительных опций (Телефония, работа с ККМ, рассылки и тд).
Далее после того как клиент и менеджер определились с тарифом, клиент оплачивает сервис, подписывает договор и его переводят в отдел внедрения, где специалисты загружают всю номенклатуру товаров, список услуг, сотрудников и тд, которые предварительно прислал клиент.
После того как специалисты внедрения загрузили всю информацию согласно ТЗ, происходит обучение клиента в работе с сервисом автоматизации. Спустя 3 месяца, после того как клиент уже полностью умеет обращаться с CRM, ему присваивают личного аккаунт-менеджера, который будет в дальнейшем вести клиента.

1.2 Выявление потребностей пользователя ИС

Проанализировав описание предметной области были выявлены данные, которые должны хранится в БД.

ФИО сотрудника
Название отдела сотрудника (в котором работает)
Должность сотрудника
Заработная плата сотрудника (Оклад)
Отдел в котором работает сотрудник
Отдел выполняет определенный вид деятельности (работа каждого отдела индивидуальна)
Для выполнения работ используется техническое задание (согласно выбранному тарифу)
У компании есть клиентская база, которая должна храниться в БД компании (ФИО, Мобильный телефон, Email, Тариф)
Менеджер должен добавить информацию о клиенте в КБ (номер договора, вид тарифа, статус, клиент, стоимость, файл на ТЗ)
У специалиста внедрения появляется информация о клиенте с ТЗ, только после перевода статуса на “ожидает внедрения”.
У аккаунт менеджера появляется информация о клиенте только после перевода статуса на “завершено внедрение”. (Или со статусом “без внедрения”, в том случае если клиент настраивает все сам).

2. Разработка серверной части информационной системы

2.1 Инфологическое проектирование БД

2.1.1 Выявление сущностей и связей

В предметной области можно выделить следующие сущности:

1. Клиент (заказчик);

2.    Сотрудник;

3.    Должность (менеджер по продажам, специалист внедрения, аккаунт менеджер);

4.    Отдел (продажи, аккаунтинг, внедрение);

5.    Договор (имеет уникальный номер – идентификатор);

6.    Техническое задание;

7.    Заказ;

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

1.    Отдел продаж имеет Заказ от Клиента

2.    Сотрудник занимает Должность

3.    Сотрудник (менеджер по продажам) оформляет Договор

4.    Клиент подписывает Договор (После подписания договора клиент в системе получает номер идентификатора, он же является и номером договора)

5. Клиент оплачивает Заказ (CRM система)

6.   Заказ имеет Техническое задание

8.    Отдел внедрения использует Техническое задание

9.    Сотрудник (специалист внедрения) выполняет Техническое задание

10. Заказ имеет номер Договора

11. Отдел аккаунтинга получает Заказ

12. Сотрудник (аккаунт менеджер) сопровождает (работает) Заказ

2.1.2 Построение ER-диаграмм

1. Связь Отдел имеет Заказ

Для степени связи:

Отдел может иметь несколько Заказов
Заказ может находиться только в одном Отделе

Для класса принадлежности сущности к связи

Отдел может не иметь Заказов
Заказ не может быть без Отдела

2. Связь Сотрудник занимает Должность

Для степени связи:

Сотрудник может занимать только одну Должность
Должность могут занимать несколько Сотрудников

Для класса принадлежности сущности к связи:

Сотрудник обязательно занимает Должность
Должность может быть не занята ни одним Сотрудником

3. Связь Сотрудник оформляет Договор

Для степени связи:

Сотрудник оформляет много Договоров

Договор оформляется одним Сотрудником

Для класса принадлежности сущности к связи:

У Сотрудника в оформлении может быть много Договоров

У Договора всегда есть ответственный Сотрудник

4. Связь Клиент подписывает Договор

Для степени связи:

Клиент может подписать несколько Договоров
Договор принадлежит только одному Клиенту

Для класса принадлежности сущности к связи:

Клиент обязательно подписывает Договор
Договор обязательно закреплен за Клиентом

5. Связь Клиент оплачивает Заказ

Для степени связи:

Клиент может оплатить несколько Заказов
Заказ принадлежит только одному Клиенту

Для класса принадлежности сущности к связи:

Клиент обязательно оплачивает Заказ
Заказ обязательно закреплен за Клиентом

6. Связь Заказ имеет Техническое задание

Для степени связи:

Заказ может иметь только одно Техническое задание
Техническое задание принадлежит только одному Заказу

Для класса принадлежности сущности к связи:

Заказ не обязательно имеет Техническое задание
Техническое задание не обязательно входит в Заказ

7. Связь Сотрудник выполняет Техническое задание

Для степени связи:

Сотрудник выполняет много Технических заданий
Техническое задание выполняется одним Сотрудником

Для класса принадлежности сущности к связи:

У Сотрудника может не быть Технических заданий
У Технического задания обязательно есть ответственный Сотрудник

7. Связь Заказ имеет Договор

Для степени связи:

Заказ может иметь только один Договор
Договор имеет только один Заказ

Для класса принадлежности сущности к связи:

В Заказ обязательно имеет Договор
Договор обязательно принадлежит Заказу

8. Связь Сотрудник сопровождает Заказ

Для степени связи:

Сотрудник может сопровождать много Заказов
Заказ имеет только одного ответственного Сотрудника

Для класса принадлежности сущности к связи:

Сотрудник может не иметь Заказов
Заказ обязательно имеет ответственного Сотрудника

2.2 Даталогическое проектирование БД

2.2.1 Переход от ER диаграммы к предварительным отношениям

Отдел имеет Заказ

По правилу 4 получаем следующее отношение:
Отдел (Код_отдела)
Заказ (Код_заказа, Код_отдела)

Сотрудник занимает Должность

По правилу 4 получаем следующее отношение:

Сотрудник (ФИО_сотрудника, Должность)
Должность (Код_должности)

Сотрудник оформляет Договор
По правилу 4 получаем следующее отношение:

Сотрудник (ФИО_сотрудника, Код_должность)
Договор (Код_договора, Код_клиента, ФИО_сотрудника)

Клиент подписывает Договор

По правилу 4 получаем следующее отношение:

Клиент (Код_клиента, ФИО_клиента)
Договор (Код_договора, Код_клиента)

Клиент оплачивает Заказ

По правилу 4 получаем следующее отношение:
Клиент (Код_клиента, ФИО_клиента)
Заказ (Код_заказа, Код_клиента)

Заказ имеет Техническое задание

По правилу 4 получаем следующее отношение:
Заказ (Код_заказа)
Техническое задание (Код_ТЗ, Код_клиента)

Сотрудник выполняет Техническое задание

По правилу 4 получаем следующее отношение:
Сотрудник (Код_сотрудника, ФИО_сотрудника, Код_должности)
Техническое задание (Код_ТЗ, Код_клиента, ФИО_сотрудника, Код_отдела)

Заказ имеет Договор

По правилу 4 получаем следующее отношение:
Заказ (Код_заказа)
Договор (Код_договора, Код_клиента, Код_сотрудника, ФИО_ сотрудника, ФИО_ клиента)

Сотрудник сопровождает Заказ
По правилу 4 получаем следующее отношение:

Сотрудник (Код_сотрудника, ФИО_сотрудника, Код_должности, Код_отдела)
Заказ (Код_заказа, Код_Клиента, Код_договора, ФИО_клиента, Код_сотрудника, ФИО_сотрудника)

2.2.2 Заполнение предварительных отношений атрибутами

1. Название должности
2. Название отдела
3. ФИО клиента
4. Телефон клиента
5. Email клиента
6. ФИО сотрудника
7. Телефон сотрудника
8. Номер договора
9. Стоимость заказа
10. Описание технического задания
11. Номер технического задания
12. Оклад сотрудника
13. Описание отдела

Должность (Код_должности, Название_Должности)
Отдел (Код_отдела, Название_отдела, Описание_отдела)
Сотрудник (Код_сотрудника, ФИО_Сотрудника, Должность, Телефон, Email, Оклад)
Клиент (Код_клиента, ФИО_клиента, Телефон, Email)
Заказ (Код_заказа, Код_Клиента, Код_договора, ФИО_клиента, Код_сотрудника, ФИО_сотрудника, Стоимость, Название)
Техническое задание (Код_ТЗ, Код_клиента, Код_заказа, Описание)
Договор (Код_договора, Номер, Код_клиента, ФИО_клиента, Код_заказа, Код_сотрудника, ФИО_сотрудника)

2.2.3 Проверка предварительных отношений на соответствие нормальным формам.

Рассмотрим отношение «Должность»

Отношение находится в 1НФ, так как на пересечении каждой строки и столбца находится одно значение
Отношение находится в 2НФ, так как первичный ключ является простым
Отношение находится в 3НФ, так как в нем нет транзитивных зависимостей
Отношение находится в БКНФ, потому что детерминантом является первичный ключ

Рассмотрим отношение «Отдел»

Отношение находится в 1НФ, так как на пересечении каждой строки и столбца находится одно значение
Отношение находится в 2НФ, так как первичный ключ является простым
Отношение находится в 3НФ, так как в нем нет транзитивных зависимостей
Отношение находится в БКНФ, потому что детерминантом является первичный ключ

Рассмотрим отношение «Сотрудник»

Отношение находится в 1НФ, так как на пересечении каждой строки и столбца находится одно значение
Отношение находится в 2НФ, так как первичный ключ является простым
Отношение находится в 3НФ, так как в нем нет транзитивных зависимостей
Отношение находится в БКНФ, потому что детерминантом является первичный ключ

Рассмотрим отношение «Клиент»

Отношение находится в 1НФ, так как на пересечении каждой строки и столбца находится одно значение
Отношение находится в 2НФ, так как первичный ключ является простым
Отношение находится в 3НФ, так как в нем нет транзитивных зависимостей
Отношение находится в БКНФ, потому что детерминантом является первичный ключ

Рассмотрим отношение «Заказ»

Отношение находится в 1НФ, так как на пересечении каждой строки и столбца находится одно значение
Отношение находится в 2НФ, так как первичный ключ является простым
Отношение находится в 3НФ, так как в нем нет транзитивных зависимостей
Отношение находится в БКНФ, потому что детерминантом является первичный ключ

Рассмотрим отношение «Техническое задание»

Отношение находится в 1НФ, так как на пересечении каждой строки и столбца находится одно значение
Отношение находится в 2НФ, так как первичный ключ является простым
Отношение находится в 3НФ, так как в нем нет транзитивных зависимостей
Отношение находится в БКНФ, потому что детерминантом является первичный ключ

Рассмотрим отношение «Договор»

Отношение находится в 1НФ, так как на пересечении каждой строки и столбца находится одно значение
Отношение находится в 2НФ, так как первичный ключ является простым
Отношение находится в 3НФ, так как в нем нет транзитивных зависимостей
Отношение находится в БКНФ, потому что детерминантом является первичный ключ

2.2.4 Построение схемы данных

`

Рисунок 1 – Схема данных

4. Разработка клиентской части информационной системы.

4.1. Выбор режима работы с базой данных, согласно технологии ADO.NET.

ADO.NET предоставляет согласованный доступ к таким источникам данных, как SQL Server и XML, а также к источникам данных, предоставляемым при помощи OLE DB и ODBC.Пользовательские приложения, использующие общие данные, могут использовать ADO.NET для соединения с этими источниками данных и для получения, обработки и обновления имеющихся в них данных.

ADO.NET разделят доступ к данным и обработку данных на дискретные компоненты, которые могут использоваться отдельно или совместно. ADO.NET включает поставщиков данных .NET Framework для соединения с базой данных, выполнения команд и получения результатов. Эти результаты, помещенные в объект ADO.NET DataSet, обрабатываются непосредственно, чтобы они могли быть предоставлены пользователю нерегламентированным образом, объединенные с данными из многих источников или передаваемые между уровнями. Объект DataSet также может независимо использоваться поставщиком данных .NET Framework для управления локальными для приложения данными или данными, источником которых является XML.

4.2. Выбор среды программирования для разработки клиентского приложения

Для разработки клиентского приложения была выбрана среда программирования ASP NET MVC С# и технология Entity Framework.
Платформа ASP.NET MVC представляет собой фреймворк для создания сайтов и веб-приложений с помощью реализации паттерна MVC.
Концепция паттерна (шаблона) MVC (model - view - controller) предполагает разделение приложения на три компонента:
Контроллер (controller) представляет класс, обеспечивающий связь между пользователем и системой, представлением и хранилищем данных. Он получает вводимые пользователем данные и обрабатывает их. И в зависимости от результатов обработки отправляет пользователю определенный вывод, например, в виде представления.
Представление (view) - это собственно визуальная часть или пользовательский интерфейс приложения. Как правило, html-страница, которую пользователь видит, зайдя на сайт.
Модель (model) представляет класс, описывающий логику используемых данных.

Общую схему взаимодействия этих компонентов можно представить следующим образом:
Паттерн MVC в ASP.NET

В этой схеме модель является независимым компонентом - любые изменения контроллера или представления не затрагивают модель. Контроллер и представление являются относительно независимыми компонентами, и нередко их можно изменять независимо друг от друга.
Благодаря этому реализуется концепция разделение ответственности, в связи с чем легче построить работу над отдельными компонентами. Кроме того, вследствие этого приложение обладает лучшей тестируемостью. И если нам, допустим, важна визуальная часть или фронтэнд, то мы можем тестировать представление независимо от контроллера. Либо мы можем сосредоточиться на бэкэнде и тестировать контроллер.
Конкретные реализации и определения данного паттерна могут отличаться, но в силу своей гибкости и простоты он стал очень популярным в последнее время, особенно в сфере веб-разработки.
Свою реализацию паттерна представляет платформа ASP.NET MVC. 2013 год ознаменовался выходом новой версии ASP.NET MVC - MVC 5, а также релизом Visual Studio 2013, которая предоставляет инструментарий для работы с MVC5.
Хотя во многих аспектах MVC 5 не слишком сильно будет отличаться от MVC 4, многое из одной версии вполне применимо к другой, но в то же время есть и существенные отличия:
В MVC 5 изменилась концепция аутентификации и авторизации. Вместо SimpleMembershipProvider была внедрена система ASP.NET Identity, которая использует компоненты OWIN и Katana.
Для создания адаптивного и расширяемого интерфейса в MVC 5 используется css-фреймворк Bootstrap
Добавлены фильтры аутентификации, а также появилась функциональность переопределения фильтров
В MVC 5 также добавлены атрибуты маршрутизации
Это наиболее важные нововведения в MVC 5. Кроме того, есть еще ряд менее значимых, например, использование по умолчанию Entity Framework 6, некоторые изменения при создании проекта (концепция One ASP.NET), дополнительные компоненты и т.д.
В любом случае все полученные при работе с MVC 4 навыки можно успешно применять при использовании MVC 5, учитывая, конечно, нововведения.

4.3. Разработка форм

Рисунок 2 – Страница авторизации пользователя

Рисунок 3 – Форма отслеживания новых заказов

Рисунок 4 – Форма добавления нового заказа

Разработка программной документации

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

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

Рисунок 5 – Страница авторизации пользователя

Список используемой литературы:

1. Сайт docs.microsoft.com. Сраница: Типы данных (Transact-SQL) [Электронный ресурс] / Режим доступа: https://docs.microsoft.com/ru-ru/sql/t-sql/data-types/data-types-transact-sql?view=aps-pdw-2016

Сайт docs.microsoft.com. Страница: Запросы. [Электронный ресурс] / Режим доступа: https://docs.microsoft.com/ru-ru/sql/t-sql/queries/queries?view=aps-pdw-2016
Агуров, Павел C#. Сборник рецептов / Павел Агуров. - М.: "БХВ-Петербург"
Албахари, Джозеф C# 3.0. Справочник / Джозеф Албахари , Бен Албахари. - М.: БХВ-Петербург, 2012
Албахари, Джозеф C# 3.0. Справочник / Джозеф Албахари , Бен Албахари. - М.: БХВ-Петербург, 2013
Альфред, В. Ахо Компиляторы. Принципы, технологии и инструментарий / Альфред В. Ахо и др. - М.: Вильямс, 2015
Бишоп, Дж. C# в кратком изложении / Дж. Бишоп, Н. Хорспул. - М.: Бином. Лаборатория знаний