35
Продолжение табл.6
Телефон
Текст, 30
да
первая
буква
заглавная
Вв, Пр,
Об
Почта
Текст, 30
да
первая
буква
заглавная
Вв, Пр,
Об
Примечание
Текст, 60
да
первая
буква
заглавная
Вв, Пр,
Об
Дата создания
Дата
нет
ДД.ММ.ГГГ
Г
Вв, Пр
Дата изменения
Дата
нет
ДД.ММ.ГГГ
Г
Вв, Пр
Заказы
Код заказа
УИ, П
число, 10
да
> 0
Г, Пр
Начало работ
по заказу
Дата
нет
ДД.ММ.ГГГ
Г
Вв, Пр
Окончание
работ по заказу
Дата
нет
ДД.ММ.ГГГ
Г
Вв, Пр
Наценка
число, 6
да
> 0
Вв, Пр,
Об
Дата создания
Дата
нет
ДД.ММ.ГГГ
Г
Вв, Пр
Дата изменения
Дата
нет
ДД.ММ.ГГГ
Г
Вв, Пр
Код статуса
УИ, П
число, 10
> 0
Г, Пр
Статус
логическое
да
Вв, Пр,
Об
Оборудование
Код оборудования
УИ, П
число, 10
> 0
Г, Пр
Название
Текст, 30
да
первая буква
заглавная
Вв, Пр,
Об
Стоимость
число, 10
да
> 0
Вв, Пр,
Об
Примечание
Текст, 60
да
первая буква
заглавная
Вв, Пр,
Об
Смета по
оборудованию
Код сметы
УИ, П
число, 10
да
> 0
Г, Пр
Количество
число, 10
да
> 0
Вв, Пр,
Об
Работы
Код работы
УИ, П
число, 10
да
> 0
Г, Пр
Название
Текст, 30
да
первая буква
заглавная
Вв, Пр,
Об
Стоимость
число, 10
да
> 0
Вв, Пр,
Об
Примечание
Текст, 60
да
первая буква
заглавная
Вв, Пр,
Об
Смета работ
Код сметы
УИ, П
число, 10
> 0
Г, Пр
Количество
число, 10
да
> 0
Вв, Пр
36
В таблице 6 использованы сокращения: УИ – уникальный идентификатор,
П – кандидат в первичный ключ (главный уникальный идентификатор), Г –
генерация значения, Вв – ввод значения, Пр – просмотр значения, Об –
обновление значения.
Связи между выявленными классами объектов представлены в таблице 7.
Таблица 7
Связи между классами объектов (КО)
Связь
Опциональн
ость связи
Тип связи
Название связи
главный КО
подчиненный КО
Глав
н КО
Подч
КО
Глав
КО
Подч
КО
Главн. КО
Подчиненны
й КО
Клиент
Заказ
м.б.
д.б.
1
M
введен
выполняетс
я
Пользовател
ь
Заказ
д.б.
д.б.
1
М
существует
обслуживае
т
Статус
Заказ
д.б.
д.б.
1
М
проверяется
соответству
ет
Заказ
Смета работ
м.б.
д.б.
1
М
выполняется
имеет
Заказ
Смета
оборудования
д.б.
д.б.
1
М
выполняется
имеет
Работы
Смета работ
д.б.
д.б.
1
М
входят
содержит
Оборудовани
е
Смета
оборудования
д.б.
д.б.
1
М
входят
содержит
В таблице 7 использованы сокращения: 1 – тип связи «один», М – тип
связи «много», «д.б.» – связь обязательная, «м.б.» – связь необязательная.
Далее связь проверяется путем чтения в обе стороны:
для одногоКЛИЕНТА может быть выполнено множество ЗАКАЗОВ.
Много ЗАКАЗОВ может заказать один КЛИЕНТ;
для одного ПОЛЬЗОВАТЕЛЯ существует множество ЗАКАЗОВ.
Много ЗАКАЗОВ может обслуживать один ПОЛЬЗОВАТЕЛЬ;
один СТАТУС проверяется во многих ЗАКАЗАХ. Для многих
ЗАКАЗОВ соответствует один СТАТУС;
один ЗАКАЗимеет много работ в СМЕТЕ РАБОТ. Для многих СМЕТ
РАБОТ соответствует один ЗАКАЗ;
один ЗАКАЗимеет много оборудования в СМЕТЕ ОБОРУДОВАНИЯ.
Для многих СМЕТ ОБОРУДОВАНИЯ соответствует один ЗАКАЗ;
37
однаСМЕТА РАБОТ содержит много РАБОТ. Много РАБОТ входит в
СМЕТУ РАБОТ;
однаСМЕТА ОБОРУДОВАНИЯ содержит много ОБОРУДОВАНИЯ.
Много ОБОРУДОВАНИЯ входит в СМЕТУ ОБОРУДОВАНИЯ.
Таким образом, при формализации предметной области были выявленные
классы объектов и их свойства и установлены между ними связи.
Поскольку в АРМ специалиста по обработке заявок клиентов ООО
«ЯМАЛ»будет предусмотрено ведение базы данных, то для программиста и
администратора сайта будет предоставлена возможность обновления
информации, а также дальнейшее совершенствование программы.
После информационного наполнения базы данных будет подключена к
интерфейсу пользователя, в котором будет предусмотрена форма авторизации
данных для входа пользователей по логину и паролю[21, c.45].
Определим группы пользователей для АРМ специалиста по обработке заявок
клиентов ООО «ЯМАЛ»и назначим им соответствующие права доступа к
папкам и модулям системы, определим требования к паролям и частоте их
смены, с помощью таблицы 8.
Таблица 8
Разграничение прав пользователей
Группы
пользователе
й
Модуль
«Пользо
ватели»
Модуль
«Заказы»
Модуль
«Клиенты
»
Модуль
«Оборудовани
е»
Модуль
«Работы»
Администрато
р
Чтение/
создание
/
удалени
е
Чтение/
создание/
удаление
Чтение/
создание/
удаление
Чтение/создан
ие/удаление
Чтение/созда
ние/удаление
Менеджер по
работе с
клиентами
-
Чтение/
создание/
удаление
Чтение/
создание/
удаление
Чтение/создан
ие/удаление
Чтение/созда
ние/удаление
Как видно из таблицы 8 у администратора будет доступ ко всем модулям
и базам данных, а менеджер по работе с клиентами будет иметь доступ ко всем
модулям кроме базы данных, в которой будет выполняться не только учет
заявок, но и учет пользователей.
38
Таким образом, для для каждого из пользователей были назначены права
и привелегии для работы с модулями АРМ специалиста по обработке заявок
клиентов ООО «ЯМАЛ»
На основании описания внешнего уровня базы данных разработаем
инфологическую модель.
Исходными данными для построения инфологической модели
предметной области являются результаты анализа предметной области,
представленные в виде описания классов объектов и связей между ними.
Инфологическая модель в данной дипломной работе представлена в виде
ER-диаграммы, построенной по методологии Ричарда Баркера. Далее
приводится краткое описание этой методологии.
Сущность изображается в виде блока с закругленными концами, внутри
которого заглавными буквами записывается имя сущности, а строчными – ее
атрибуты. Две сущности могут быть связаны между собой. Графическое
представление объектов и связей изображено на рисунке 18.
Рисунок 18. Графическое представление классов объектов и
связей
Связи представляют информационные потребности и правила бизнеса:
Значения некоторых атрибутов могут в какие-то моменты просто
отсутствовать или же быть недоступны. В таких случаях перед именем
атрибута на схеме ставится буква «o», что говорит о том, что атрибут –
необязательный (optional).
- обязательная связь – должна быть;
- необязательная связь – может быть;
- один или более – «воронья лапа»;
- один и только один.
КО 1
КО 2
39
Те атрибуты, значения которых должны быть известны всегда, имеют
перед своим именем значок «*».Полученная инфологическая модель
предметной области представлена на рисунке А.1 в приложении А.
Перекрестная проверка полученной модели предметной области на
соответствие выполняемым функциям АРМ приведена в таблице 9.
Таблица 9
Перекрестная проверка модели предметной области и
иерархии функций
Ф
Классы объектов
О1
О2
О3
О4
О5
О6
О7
О8
О9
О10
О11
О12
О13
О14
О15
О16
О17
О18
О19
О20
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Ф1
I,U
Ф2
R
Ф3
I,U
R
Ф4
R
Ф5
I,U
Ф6
R
Ф7
I,U
R
Ф8
R
Ф9
I,U
Ф10
R
Ф11
I,U
R
Ф12
R
Ф13
I,U
Ф14
R
Ф15
I,U
Ф16
R
Ф17
I,U
Ф18
R
Ф19
I,U
Ф20
R
Ф21
I,U
Ф22
R
Ф23
I,U
R
Ф24
R
Ф25
R
R
R
R
I,U
R
R
R
R
Ф26
R
Ф27
Ф28
Ф29
R
R
R
R
Ф30
Ф31
I,U
Ф32
R
Ф33
I,U
R
Ф34
R
Ф35
R
R
R
R
R
I,U
R
R
Ф36
R
40
Продолжение табл.9
Ф37
R
R
R
R
R
R
R
R
R
R
I,U
R
R
R
R
Ф38
R
Ф39
R
R
R
R
R
I,U
Ф40
R
В таблице 9 использованы сокращения: I – операция добавления; U –
операция обновления, R – операция чтения (выборки, поиска), Ф – конечная
функция «ветки» иерархии функций, а также:
О1 – клиент;
О2 – тип клиента;
О3 – заявка;
О4 – статус заявки;
О5 – вид цены;
О6 – позиция;
О7 – тип позиции;
О8 – контакты;
О9 – тип контактов;
О10 – статья;
О11 – тип статьи;
О12 – наценка;
О13 – должность;
О14 – единица измерения;
О15 – квитанция;
О16 – позиция квитанции;
О17 – договор;
О18 – тип квитанции;
О19 – телефон;
О20 – тип телефона.
Анализируя результат перекрестной проверки необходимо отметить, что
в таблице нет пустых строк и столбцов, а это означает, что полученная
инфологическая модель предметной области достаточна и не избыточна.
41
На основании разработанной инфологической модели данных на
следующем этапе разработаем даталогическую модель данных, которая в
последствие будет перенесена в физическую среду реализации (рисунок 19).
Рисунок 19. Даталогическая модель предметной области
В разработанной даталогической модели для каждого из объектов
установлены первичные и внешние ключи.
На основании разработанной даталогической модели данных выполним
анализ схем реляционных отношений на соответствие 3НФ.
Между сущностями «Клиент» и «Заказ» используется отношение «один-
ко-многим», то есть для одного клиента в ООО «ЯМАЛ»может выполняться
несколько заказов. Между сущностями «Пользователь» и «Заказ» используется
отношение «один-ко-многим», то есть для один пользователь может оформлять
несколько заявок при обслуживании клиентов.
Клиент
Код клиентаПК
ФИО клиента
Адрес
Телефон
Почта
Примечание
Дата создания
Дата изменения
Пользователь
Код пользователя ПК
Полное имя
Логин
Пароль
Статус
Код статуса ПК
Статус
Заказ
Код заказа ПК
Код клиента ВК1
Код пользователя ВК2
Начало работ по заказу
Окончание работ по заказу
Наценка
Код статуса заказа ВК3
Примечание
Дата создания
Дата изменения
Смета
Код сметы ПК
Код оборудования ВК1
Код заказа ВК2
Количество
Оборудование
Код оборудования
ПК
Название
Стоимость
Примечание
Работа
Код работыПК
Название
Стоимость
Примечание
Смета
Код сметы ПК
Код работы ВК1
Код заказа ВК2
Количество
42
Между сущностями «Заказ» и «Смета оборудования» используется связь
«один-ко-многим», то есть для каждого заказа при формировании его
стоимости можно создать несколько смет на оборудование. Аналогично
организована связь между сущностями «Заказ» и «Смета на работы».
Между сущностями «Смета оборудования» и «Оборудование»
используется связь «один-ко-многим», то есть одно и тоже оборудование может
быть использовано для формирования нескольких смет. Аналогично
организована связь между сущностями «Смета на работы» и «Работы».
Анализ схем реляционных отношений показал, что в разработанной
модели данных выполняются требования третьей нормальной формы.
Полученная ER-модель в СУБД MSAccess приведена в приложении А. На
основании данной модели выполним описание состава проектируемых
объектов базы данных: «User» (Пользователь), «Client» (Клиент), «Zakaz»
(Заказы), «Complect» (Оборудование), «Works» (Работы), «SmetaComplect»
(Смета по оборудованию), «SmetaWorks» (Смета работ),«Status» (Статус
заказа).
Таблица 10
Описание таблицы «User» (Пользователь)
Наименование
поля
Идентификатор в
базе
Тип данных
Длина поля, байт
Код пользователя
UserID
Long Integer
4
Полное имя
FullName
Text
1
Логин
login
Text
1
Пароль
password
Text
1
Таблица 11
Описание таблицы «Client» (Клиент)
Наименование поля
Идентификатор в
базе
Тип данных
Длина поля
Код клиента
ClientID
Long Integer
4
ФИО клиента
ClientName
Text
1
Адрес
Adress
Text
1
Телефон
Phone
Text
1
Почта
Email
Text
1
Примечание
Info
Text
1
Дата создания
CreateDate
Date/Time
8
Дата изменения
UpdateDate
Date/Time
8
43
Таблица 12
Описание таблицы «Zakaz» (Заказы)
Наименование поля
Идентификатор в
базе
Тип данных
Длина
поля, байт
Код заказа
ZakazID
Long Integer
4
Код клиента
ClientID
Long Integer
4
Начало работ по заказу
DateFrom
Date/Time
8
Окончание работ по заказу
DateTo
Date/Time
8
Наценка (%)
Nacenka
Double
8
Код заказа
Statusid
Long Integer
4
Примечание
Info
Text
1
Код пользователя
UserID
Long Integer
4
Дата создания
CreateDate
Date/Time
8
Дата изменения
UpdateDate
Date/Time
8
Таблица 13
Описание таблицы «Complect» (Оборудование)
Наименование поля
Идентификатор в
базе
Тип данных
Длина
поля, байт
Код оборудования
ComplectID
Long Integer
4
Название
Caption
Text
1
Стоимость
Cost
Double
8
Примечание
Info
Text
1
Таблица 14
Описание таблицы «Works» (Работы)
Наименование поля
Идентификатор в
базе
Тип данных
Длина поля,
байт
Код работ
WorksID
Long Integer
4
Название
Caption
Text
1
Стоимость
Cost
Double
8
Примечание
Info
Text
1
Таблица 15
Описание таблицы «SmetaComplect» (Смета по
оборудованию)
Наименование поля
Идентификатор в
базе
Тип данных
Длина поля,
байт
Код сметы по оборуд.
SmetaComplectID
Long Integer
4
Код заказа
ZakazID
Long Integer
4
Код оборудования
ComplectID
Long Integer
4
Количество
Count
Double
8
44
Таблица 16
Описание таблицы «SmetaWorks» (Смета работ)
Наименование поля
Идентификатор в
базе
Тип данных
Длина поля,
байт
Код сметы работ
SmetaWorksID
Long Integer
4
Код заказа
ZakazID
Long Integer
4
Код работы
WorksID
Long Integer
4
Количество
Count
Double
8
Таблица 17
Описание таблицы «Status» (Статус заказа)
Наименование поля
Идентификатор в
базе
Тип данных
Длина поля,
байт
Код статуса
StatusID
Long Integer
4
Статус
Caption
Text
1
После разработки базы данных следующим этапом является разработка
интерфейса пользователя, что будет выполнено в следующем подразделе
работы.
На рисунке в приложении Б представлена укрупненная схема алгоритма
автоматизированного рабочего места.
Алгоритм реализации математического аппарата приведен в виде
диаграммы состояний приведенной на рисунке 20.
Рисунок 20. Диаграмма состояний