Постановка задачи на ЭИС

Функции по добавлению информации также относятся к разряду  редактирования базы, но добавление информации разрешено большинству пользователей. К примеру, добавление припаркованного авто в базу данных.

Функции, представленные на рисунке 3.1 подразделяются на две  группы:

• служебные;
• основные.

К служебным функциям относятся функции по авторизации  пользователя в системе. При вводе логина и пароля происходит проверка на подлинность введённых данных.

К основным функциям относятся функции по добавлению данных в базу (новый сотрудник, новое авто, новый договор), формирование отчётов и выходных документов, редактирование базы данных.

Так как сценарий диалога  пользователя и системы организован  через контекстно-зависимое меню, то это означает, что в программе  можно выделить несколько уровней. На рисунке 3.2 показан сценарий диалога. Каждому блоку соответствует  своя экранная форма, которая представлена в Приложении А.

В систем можно выделить три уровня:

1. Уровень авторизации пользователя. Это служебный уровень, с него начинается работа системы.
2. Уровень диалога пользователя с системой. Главный уровень, ему соответствует главная форма программы. Отсюда пользователь может вызывать на исполнение другие формы, изменять базу данных.
3. Уровень исполнения. На этом уровне происходит взаимодействие пользователя с отчётными документами, с базой данных.

 

Рисунок 3.2 – Сценарий диалога

3.2.2 Структурная  схема пакета модулей

Структурная схема пакета представляет собой иерархию модулей  системы  от авторизации пользователя до вывода отчётов. Структурная схема представлена на рис. 3.3.

Модуль autorisation авторизирует пользователя и определяет его права в системе. Затем этот модуль вызывает на исполнение модуль main, который является основным для системы. Из этого модуля можно вызвать большинство других модулей [30].

Модули третьего уровня выполняют следующие основные функции:

• добавление информации в базу данных;
• изменение информации;
• удаление информации;
• вывод отчётов;
 

• вывод результатной информации по требуемым параметрам;
• администрирование системы.

Модули четвёртого уровня представляют пользователю всю выходную информацию, которая выводится либо в виде отчёта, либо в виде экранной формы [31]. Экранные формы выходных документов и примеры отчётов представлены в Приложении Б.

На представленной схеме на рисунке 3.3 представлены модули четырёх уровней и уровень авторизации пользователей. Каждый модуль вызывается через контекстное меню. По функционалу модули разделяются на отображение информации, изменение и добавление в базу.

Рисунок 3.3 – Структурная  схема пакета модулей

 

3.3 Описание  реализации БД ЭИС

На рисунке 3.4 представлена ER-модель базы данных, использующейся в автоматизированной системе. Схема состоит из нескольких таблиц. Представленная схема базы данных является реляционной [32]. Практически все СУБД позволяют добавлять новые данные в таблицы. С этой точки зрения СУБД не отличаются от программ электронных таблиц (Excel), которые могут эмулировать некоторые функции баз данных.

К числу достоинств реляционного подхода можно отнести:

• наличие небольшого набора абстракций, которые позволяют сравнительно просто моделировать большую часть распространенных предметных областей и допускают точные формальные определения, оставаясь интуитивно понятными;
• наличие простого и в то же время мощного математического аппарата, опирающегося главным образом на теорию множеств и математическую логику и обеспечивающего теоретический базис реляционного подхода к организации баз данных;
• возможность ненавигационного манипулирования данными без необходимости знания конкретной физической организации баз данных во внешней памяти.

Прежде чем разрабатывать  схему базы данных необходимо чётко  представлять предметную область, для  которой создаётся база данных. При  проектировании этой базы данных использовался  классический подход, при котором весь процесс проектирования производится в терминах реляционной модели данных методом последовательных приближений к удовлетворительному набору схем отношений.

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

причем каждая следующая  нормальная форма обладает свойствами лучшими, чем предыдущая.

В основе процесса проектирования лежит метод нормализации, декомпозиция отношения, находящегося в предыдущей нормальной форме, в два или более отношения, удовлетворяющих требованиям следующей нормальной формы [33].

Таблицы в модели на рисунке 3.4 связаны между собой отношениями по первичному ключу, являющегося идентификатором каждой записи.

Таблица Clients

Эта таблица является одной из основных таблиц в базе данных. Структура таблицы представлена в таблице 3.12. Она содержит информацию о клиентах компании, включая информацию о паспортных данных. Она содержит следующие поля:

• id – Идентификатор записей таблицы. Первичный ключ таблицы, это поле является уникальным в разрезе самой таблицы. Значение поля автоматически увеличивается при добавлении новой записи в таблицу;
• famlia, name, otchestvo – строковые типы данных. Содержат информацию, соответственно, о фамилии, имени и отчестве клиента компании;
• adres – прописка клиента;
• dom_nomer, mob_nomer – контактная информация с клиентом. Эти поля показывают домашний и мобильный номера телефонов клиента;
• seria – серия паспорта клиента. Это поле имеет числовой формат;
• nomer – номер паспорта клиента. Так же имеет числовой тип данных;
• date_vidachi – дата выдачи паспорта. Это поле имеет тип данных Дата;
• kem_vidan – кем выдан паспорт. Строковый тип данных

Экранная форма, соответствующая этой таблице, представлена в Приложении А. Запись имеет заполнение по всем полям при оформлении договора с клиентом. При оформлении «ночников» некоторые поля могут не заполняться [34]. При этом поля фамилия и имя являются обязательными для заполнения.

 

Рисунок 3.4 - ER-модель базы данных

 
Таблица 3.12 - Таблица Clients

Имя поля	Тип данных	Описание
Id	Счётчик	Идентификатор
Familia	Строковый	Фамилия клиента
Name	Строковый	Имя клиента
Otchestvo	Строковый	Отчество клиента
Adres	Строковый	Адрес по прописке
Dom_nomer	Строковый	Домашний номер телефона
Mob_nomer	Строковый	Мобильный номер телефона
Seria	Числовой	Серия паспорта
Nomer	Числовой	Номер паспорта
Date_vidachi	Дата	Дата выдачи паспорта
Kem_vidan	Строковый	Кем выдан

 

Информация об остальных таблицах представлена в таблице 3.13:

 

Таблица 3.13 – Описание таблиц базы данных

Название таблицы	Размер	Описание
Polzovateli	Порядка 20 записей в таблице	Таблица содержит информацию о логинах  и паролях пользователей системы и определяет права доступа пользователя к системе
Sotrudniki	Порядка 20 записей в таблице	Содержится информация о сотрудниках  компании, их контактной информации. Связана  с таблицей пользователи по первичному ключу.
Tarifi	Порядка 20 записей в таблице	Содержится информация об установленных  тарифах в компании на стоянку  автомобилей.
Auto	Порядка 1000 записей в таблице	Содержится информация об автомобилях  клиентов компании, которые паркуются  на стоянках компании. Связана с  таблицей клиенты по первичному ключу. Размер таблицы постоянно увеличивается по мере появления новых автомобилей.
Продолжение таблицы 3.13
Название таблицы	Размер	Описание
Dogovora	Порядка 500-600 записей в таблице	Содержится информация о заключённых  договорах с клиентами, завершёнными или действующими. Связана по первичному ключу с таблицей клиенты.
Financi	Порядка 1000 записей в таблице	Содержится информация по внесению средств по договорам. Связана по первичному ключу с таблицей договора.
Nochniki	Порядка 2000 записей в таблице	Содержится информация по оплате за парковку «ночниками». Связана по первичному ключу с таблицей клиенты.
Zarplata	Порядка 1000 записей в таблице	Содержится информация о выданной зарплате сотрудникам компании. Связана  по первичному ключу с таблицей сотрудники.
Rashodi	Порядка 500 записей в таблице	Содержится информация о прочих расходах компании, не связанных с  основной деятельностью компании. Связана  по первичному ключу с таблицей сотрудники.
Parkovka	Порядка 5000 записей в таблице	Содержится информация о парковавшихся автомобилях. Рабочая таблица, которая связывает между собой сотрудников, клиентов и автомобили. Размер таблицы постоянно увеличивается.

 

3.4 Схема функционирования  ЭИС

Схема функционирования ЭИС представляет собой последовательную схему процесса сбора, обработки и выдачи результатной информации.

В качестве входной информации для автоматизированной системы выступает информация об автомобилях клиентов, данные по самим клиента, информация о свободных местах на стоянке [35]. К входным документам системы можно отнести договора, которые имеются в виде шаблонов в системе.

Информация в базе данных меняется с частотой поступления автомобилей на стоянку. К выходным документам относятся отчёты по зарплате (зарплатная ведомость), баланс компании и экранные формы со служебной информацией [36]. На рисунке 3.5 представлена схема функционирования ЭИС.

 

Рисунок 3.5 – Схема  функционирования ЭИС

 

Продолжение рисунка 3.5

 

Продолжение рисунка 3.5

 

Продолжение рисунка 3.5

 

Схема, представленная на рисунке 3.5 представляет собой схему  работы всей системы от сбора до выдачи информации. Она показывает действия пользователя при выборе того или иного пункта меню [37]. В схеме указано взаимодействие программного комплекса с информационными документами. В качестве информационных документов в системе представлены выходные отчёты. Входных документов системе нет.

3.5 Обеспечение  информационной безопасности при эксплуатации ЭИС

Основой применения системы  безопасности в разработанной системе  служит информация, которая хранится в базе данных:

• Информация о паспортных данных клиентов компании;
• Информации движении денежных средств компании, зарплатах сотрудников.

Информационная безопасность обеспечивается на двух уровнях. Первый уровень составляет СУБД, второй уровень  составляет само приложение.

SQL Server 2005 поддерживает  два режима аутентификации: с  помощью Windows и с помощью SQL Server. Первый режим позволяет реализовать решение, основанное на однократной регистрации пользователя и едином пароле при доступе к различным приложениям (Single SignOn solution, SSO). Подобное решение упрощает работу пользователей, избавляя их от необходимости запоминания множества паролей и тем самым снижая риск их небезопасного хранения (вспомним стикеры с паролями, наклеенные на мониторы) [38]. Кроме того, данный режим позволяет использовать средства безопасности, предоставляемые операционной системой, такие как применение групповых и доменных политик безопасности, правил формирования и смены паролей, блокировка учетных записей, применение защищенных протоколов аутентификации с помощью шифрования паролей (Kerberos или NTLM).