61
менеджеров
ие
Защита от внешних угроз реализуется следующими параметрами:
Все серверные системы в компании ООО ТК"Витамилк" не имеют
установленных сторонних средств удаленного администрирования, таких как
Team Viewer /Remote administrator/Dame Ware/. Доступ организован через
Remote desktop protocol, на нужный сервер, в том числе и сервер приложений и
СУБД, где размещена разрабатываемая ИС, вход осуществляется только по
доменной авторизации в соответствии с уровнем доступа.
В компании ООО ТК «Витамилк» используются все возможные методы
защиты информации, так как нет уникального одного метода, который смог бы
обеспечить полную информационную безопасность, а сочетание всех методов
позволяет реализовать максимальную информационную безопасность.
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
На рисунке 19 приведена Информационная модель выпускной
квалификационной работы в виде схемы.
Область 1 отображает процесс конфигурирования ИС в части ввода
продукции ИС, которые необходимы в рамках задачи для того, чтобы можно
было зафиксировать оптовой поставке клиента[13]. Форма «Административное
управления» предполагает выполнение двух видов операций:
редактирование справочника продукции;
редактирование справочника заказов.
Область 2 отображает то, что из базы ИС в рамках моделируемой задачи
используются пять справочников и три таблицы.
Область 3 отображает собственно процесс заказа поставки, предполагая,
что ввод будет состоять из следующих этапов:
сначала делается запись (либо производится обновление записи) в
справочнике клиентов. Под клиентом понимается ФИО заказчика и какие-либо
его данные (например, паспортные данные);
62
затем делается запись, отражающая факт добавления продукции в
корзину. В рамках задачи предполагается два варианта его совершения;
затем подтверждается заказ, делается запись в таблице заказы.
Рисунок 19 – Информационная модель
Область 4 отображает то, что моделируемая ИС предоставляет на выходе:
клиент получает результатный документ, содержащий параметры
совершённого заказа и являющийся его подтверждением.
администратор получает от банка оповещение об оплате и дальше ведет
статус заказов.
63
2.2.2 Характеристика нормативно-справочной, входной и
оперативной информации
В данной выпускной работе используются только входящие справочники.
Входящим документом является регистрация пользователя и оформления заказа.
Регистрация пользователя представляет набор паспортных данных о клиенте и
номер его телефона. Оформления заказа предоставляет наличие двух
документов: заказ и состав заказа. Примеры регистрации клиента и оформления
заказа можно увидеть на таблицах 17-19.
Таблица 17
Информация о клиенте
Имя
Сергей
Фамилия
Алексеев
Номер телефона
555-6788
Адрес
г. Пермь, ул. Ленина, 89,9.
Таблица 18
Оформленный заказ
Номер заказа
245589
Имя
Сергей
Фамилия
Алексеев
Номер телефона
555-6788
Сумма заказа
5653руб.
Адрес
г. Пермь, ул. Ленина, 89,9.
Таблица 19
Состав заказа
Номер заказа
45589
Наименование продукта
Большая кружка 2,5% персик-абрикос с крыш. 1/12
Количество
13
64
Цена за шт.
40руб
2.2.3 Характеристика результатной информации
В данной выпускной работе результирующей информацией являются –
отчет о заказах. Пример приведен в таблице 20.
Таблица 20
Результирующая информация
Номер заказа
245589
Имя Фамилия
Алексеев Сергей
Номер телефона
555-6788
Сумма заказа
5653руб.
Адрес
г. Пермь, ул. Ленина, 89,9.
Состав заказа
Наименование
продукта
Большая кружка 2,5%
персик-абрикос с крыш.
1/12
Количество
13
Цена за шт.
40руб
2.3 Программное обеспечение задачи
2.3.1 Общие положения (дерево функций и сценарий диалога)
В данной выпускной работе автоматизируется работа торгового
представителя с клиентами. Сценарий диалога представлен на рисунке 20.
65
Рисунок 20 - Сценарий диалога работы программы
Программа согласно заложенной в неё логике обрабатывает регистрацию
клиента и оформления заказа, проверяя их содержимое и согласовывая доступ и
закупку с требуемым регламентом. В программе есть возможность просмотреть
историю обработанных заказов и при возможности отменить созданные заявки.
Любой функционал программы можно разделить на основной, с помощью
которого достигается основная цель алгоритма программы и дополнительный
(служебный) - это то, что можно настроить изменить, прояснить. Дерево
функций как раз наглядно демонстрирует разделение данных функций. Дерево
функций изображено на рисунке 21.
66
Рисунок 21 - Дерево функций
2.3.2. Характеристика базы данных
Разработка концептуальной модели предметной области.
В результате анализа требований пользователя и структур данных,
описывающих деятельность, Поставка оптовой продукции, определены как
сущности следующие объекты:
Клиент (Id – потенциальный ключ);
Заказ (номер заказа – потенциальный);
Администратор (Id– потенциальный ключ);
Продукция (Уникальный код – потенциальный ключ);
Категория продукции (Номер категории – потенциальный ключ).
При этом минимальная информация ER-модели [8] должна содержать
следующие пять элементов данных:
67
сущности, изображаемые в виде прямоугольников произвольного
размера;
ключи сущностей, изображаемые в виде подчеркнутых надписей рядом
с прямоугольником с любой стороны;
связи, изображаемые в виде ромбов произвольного размера и
соединенных прямыми линиями с соответствующими сущностями, эти линии
могут быть произвольного наклона и, по возможности, без пересечений;
степень участия в связи для каждой сущности, изображаемая в виде
числа или буквы около соответствующего прямоугольника-сущности и линии
связи;
полнота участия в связи для каждой сущности, изображаемая в виде
точки перед символом-степенью участия, при этом наличие точки означает
полное участие в связи данной сущности, т.е. значение обязательный.
Каких-либо строгих правил для изображения диаграммы ER-типов не
существует. В различных коммерческих системах (CASE средствах)
проектирования БД используется и другая нотация для изображения ER-
диаграмм, наиболее известными из них являются нотация «куриных лапок» и
нотация стандарта IDEF1X. Однако, для обсуждения результатов
проектирования с будущими пользователями БД удобнее всего представить
диаграмму ER-типов в нотации, предложенной впервые П. Ченом, т.е. в виде
прямоугольников и ромбов.
В процессе функционирования поставки оптовой молочной продукции
сущности взаимодействуют друг с другом. В концептуальной модели
взаимодействие между сущностями выражается с помощью связей, основными
из которых являются следующие.
Клиент оформляет заказ (Клиент в Заказе). Между сущностью
«Клиент» и сущностью «Заказ» существует связь типа «1:М», которая означает,
что любой заказ, обязательным по отношению к сущности «Клиент».
Связь изображена на рисунке 22.
Клиент
Оформляет
Заказ
1
N
68
Id Номер заказа
Рисунок 22 – Связь «Клиент в Заказе»
Подтверждает (Администратор в Заказе). Существует связь между
сущностью «Администратор» и сущностью «Заказ» типа «1:М», обязательная со
стороны сущности «Администратор» (каждому экземпляру сущности «Заказ»
обязательно соответствует администратор и причем только один). Связь
изображена на рисунке 23.
Id Номер заказа
Рисунок 23 – Связь «Менеджер в Заказе»
Находится – связывает сущности Продукция и Категория. Определяет, какой
категории принадлежит продукция. Бинарная связь – один ко многим. Связь
изображена на рисунке 24.
Номер продукции Номер категории
Рисунок 24 – Связь «Категория в Продукции»
Это означает, что каждая продукция входит только в одну категорию, а в
каждой категорию может включаться много продукции. Класс принадлежности
Продукция
Находится
Категория
М
1
Подтверждает
Менеджер
Заказ
1
N
69
сущности Категория обязательный, т.к. нет продукции, не входящих в какую-
либо категорию.
Содержит – связывает сущности Продукция и Заказ. Определяет, какие
продукты входят в какие заказы. Бинарная связь – многие ко многим. Связь
изображена на рисунке 25.
Номер заказа Номер продукции
Рисунок 25 – Связь «Заказ-Продукция»
Это означает, что продукты могут содержаться во многих заказах, а также
заказы содержат много продукции.
Логическая модель. Разработка логической модели базы данных.
После того, как концептуальная модель одобрена, можно перейти к этапу
логического проектирования БД. При этом исходными данными для
проектирования являются диаграмма ER-типов концептуальной модели
предметной области и логическая модель данных, используемая для реализации
будущей БД и поддерживаемая какой-либо коммерческой СУБД [14].
В качестве логической модели данных выбираем реляционную модель
Кодда, как наиболее распространенную в большинстве современных СУБД.
Теперь следует преобразовать концептуальную модель в соответствии с
требованиями реляционной модели данных.
Таким образом, формально этап логического проектирования БД может в
проекте отсутствовать, но при этом следует иметь в виду, что при выполнении
преобразования диаграммы ER-типов в схему БД с помощью выше изложенных
правил 1-8, мы, фактически и выполняем логическое проектирование БД с
использованием реляционной логической модели данных. И в любом случае
получаем логическую модель, в которой все объекты представлены как
Заказ
Содержит
Продукция
М
N
70
сущности (сильные или слабые) и связи один ко многим и один к одному
(сильные или слабые).
Еще одним ограничением реляционной модели данных является
требование нормализации всех сущностей-отношений. Это требование часто
называют первой нормальной формой (1НФ). Оно заключается в том, чтобы все
атрибуты в БД были атомарными с точки зрения СУБД. Атомарность означает
неделимость каждого значения данных на многие значения, например не
допускается иметь в БД атрибутов, представляющих собой списки значений
(множественные значения), как-то: номера телефонов, оценки, дни работы и т.д.
Не допускается иметь в БД и атрибуты составные, например адрес, включающий
город, улицу, дом, квартиру при условии, что в процессе использования БД
потребуется обращение к какой-либо части этого адреса [14].
Во всех этих случаях требуется на этапе логического проектирования
обязательно провести нормализацию каждого отношения, т.е. привести его к
1НФ.
На следующем шаге проектирования необходимо оценить полученные
отношения с точки зрения нормальных форм более высокого порядка. Причем,
из пяти нормальных форм, известных в настоящее время 2НФ, 3НФ. НФБК, 4НФ
и 5НФ, на практике, как правило, бывает вполне достаточно обеспечить третью
нормальную форму или НФБК (усиленную 3НФ). В крайнем случае, можно
вообще не заниматься вопросами приведения БД к той или иной НФ, но при
этом надо помнить о том, что надежность проекта будет тем ниже, чем сложнее
БД и чем большие требования предъявляются к целостности данных.
Чтобы провести проверку на уровень нормализации БД, необходимо:
разместить все атрибуты во всех полученных сущностях-отношениях
(слабых и сильных);
выявить в каждом отношении потенциальные ключи;
выявить все функциональные зависимости (ФЗ) между атрибутами в
каждом отношении;
сопоставить потенциальные ключи с детерминантами ФЗ (их левыми
частями);