Автор работы: Пользователь скрыл имя, 12 Января 2013 в 15:16, дипломная работа
Целью данной работы является создание системы, которая обеспечит решение следующих задач:
вести журнал посещения и хранения автомобилей на стоянках;
отслеживать информацию о клиентах компании;
отслеживать свободное пространство на стоянках и рекомендовать постановку машины;
вести договора с клиентами.
Функции по добавлению информации также относятся к разряду редактирования базы, но добавление информации разрешено большинству пользователей. К примеру, добавление припаркованного авто в базу данных.
Функции, представленные на рисунке 3.1 подразделяются на две группы:
К служебным функциям относятся функции по авторизации пользователя в системе. При вводе логина и пароля происходит проверка на подлинность введённых данных.
К основным функциям относятся функции по добавлению данных в базу (новый сотрудник, новое авто, новый договор), формирование отчётов и выходных документов, редактирование базы данных.
Так как сценарий диалога
пользователя и системы организован
через контекстно-зависимое
В систем можно выделить три уровня:
Рисунок 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. Она содержит информацию о клиентах компании, включая информацию о паспортных данных. Она содержит следующие поля:
Экранная форма, соответствующая этой таблице, представлена в Приложении А. Запись имеет заполнение по всем полям при оформлении договора с клиентом. При оформлении «ночников» некоторые поля могут не заполняться [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).