Разработка информационной системы для компании, продающих компьютеры и комплектующие

Идентификация и авторизация в компьютерной безопасности. Анализ существующих разработок для автоматизации задачи программы "СКЛАД". Алгоритм работы менеджера по продажам, технического администратора. Структура базы данных электронного документооборота.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 19.04.2016
Размер файла 1,8 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Реляционные модели данных (РМД) строятся на использовании табличных методов и средств представления данных и манипулирования ими. В РМД информация о предметной области отображается таблицей - отношением. Строка таблицы называется кортежем, столбец - атрибутом. Каждый атрибут может принимать некоторое подмножество значений из определенной области - домена. Домен, таким образом, является областью определения одного или нескольких атрибутов. Отношениям, атрибутам и доменам присваиваются имена. К отношениям РМД предъявляется ряд требований, основными из которых считаются следующие:

значения атрибутов, т.е. данные расположенные на пересечении строки и столбца, являются атомарными (неделимыми, элементарными);

в отношении не может быть двух одинаковых кортежей;

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

порядок следования кортежей безразличен.

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

Итак, под РМД понимается набор схем отношений, удовлетворяющих указанным выше требованиям. Достоинством реляционной модели является сравнительная простота инструментальных средств ее поддержки, недостатком - жесткость структуры данных (невозможность задания строк таблицы произвольной длины и другие) и зависимость скорости ее работы от размера базы данных.

В настоящее время реляционные модели данных остаются наиболее используемыми. Реляционные БД в конце 70-х годов практически вытеснили БД других видов. В качестве основной причины этого называют сложность представления данных в иерархических и сетевых моделях и необходимость определения связей между данными на этапе проектирования БД, в то время как в реляционных БД связи между таблицами могут устанавливаться непосредственно в момент выполнения запросов. Кроме того, разработчикам и пользователям значительно проще отображать сущности предметной области в табличных структурах данных, а со структурной точки зрения, реляционные модели являются более простыми и однородными, чем сетевые и иерархические модели.

Учитывая проведенный анализ моделей логической структуры БД, наиболее выгодным решением будет использование реляционной модели. В качестве причин такого выбора стоит отметить, что реляционная модель базируется на развитой математической теории, обладает простотой и легкостью использования, наглядностью представления структур данных.

2.2 Алгоритм функционирования СУБД

Описание предметной области

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

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

-учет товара в розничной торговле ? сама система, как единый процесс;

-пользователь, который непосредственно ведет учет товара;

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

-выходными данными для подсистемы служат отчеты (о реализации товара за период, о приходе товара на склад, о выбытии товара), сформированные на основе различных накладных и накладные, как отдельные документы;

-система разрабатывается на основании договора с клиентом, должна учитывать его требования и положение о складском учете.Для этого выделим следующие процессы:

-приход товара. Входными данными служат приходные накладные. Выходными являются данные для формирования отчета о приходе товара на склад (в торговую точку) за период (месяц), для возврата товара, для переоценки товара, для передачи товара в другой отдел. Процесс действует на основании договора с клиентом и положения о складском учете;

-возврат товара. Входными являются данные прихода товара на склад (приходная накладная). Выходными служат данные для формирования отчета о выбытии товара со склада за период и расходные накладные. Процесс действует на основании договора с клиентом и положения о складском учете;

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

-ввод остатков. Входные данные ? информация об остатках за период. Выходные данные ? инвентаризационная ведомость остатков за период (остатки на начало периода), которая служит для формирования отчета о реализации товара за период (месяц). Процесс действует на основании договора с клиентом и положения о складском учете;

-переоценка товара. Входные данные ? информация о приходе товара в торговую точку (приходная накладная). Выходные данные ? накладная переоценки (акт) товара и информация для формирования отчета о реализации товара за период. Процесс действует на основании договора с клиентом и положения о складском учете;

-передача товара в другой отдел. Входными являются данные о приходе товара на склад (приходная накладная). Выходные данные ? накладная внутреннего перемещения товара и информация для формирования отчета о реализации товара за период. Процесс действует на основании договора с клиентом и положения о складском учете.

Все вышеперечисленные процессы контролируются пользователем.

Центральным компонентом является описание объектов предметной области и связей между ними ? ЕR-модель (от англ. "Entity" ? "сущность", и "Relationship" ? "связь").

Для работы с базами данных выделяется ряд объектов, каждый из которых обладает определенными свойствами ? атрибутами. Атрибут ? абстракция одной характеристики объекта. Каждый атрибут имеет имя и получает значение из определенного множества допустимых значений. У каждого объекта выделяется идентификатор ? один или несколько атрибутов, однозначно определяющих каждый экземпляр объекта

В основу разработки системы положен структурный анализ. Одним из наиболее часто используемых средств служат ЕR ? диаграммы. Построение инфологической модели подразумевает выделение в исследуемой предметной области объектов и связей между ними.

При анализе предметной области определены основные функции, и следовательно, определены основные объекты системы. Для работы с накладными необходима следующая информация: наименование товара, к которой относится товар (для более быстрого поиска необходимого товара), количество товара и его цена, наименование поставщика и покупателя (а также их реквизиты), торговый отдел (торговая точка). Занесение информации о приходе, выбытии, передаче, переоценке товара осуществляется с помощью накладной, поэтому можно выделить 2 объекта: Заголовок ? «шапка» накладной (приходной, расходной (возврат товара поставщику), переоценка товара, передача товара в другой отдел, инвентаризационной ведомости) и Табличная часть накладной ? основная часть. Разделение накладной на две части: заголовок и таблица позволяет более гибко организовать хранение и обработку данной информации.

Для учета движения товара нужно использовать объект «Товар на складе». Данный объект предназначен для хранения информации о приходе конкретного товара, его оптовой и розничной цене за конкретный временной интервал.

Выделение объектов

В данной предметной области можно выделить ряд объектов: ЗАГОЛОВОК НАКЛАДНОЙ, ТАБЛИЧНАЯ ЧАСТЬ НАКЛАДНОЙ, СКЛАД,

АССОРТИМЕНТ, ТИП ТОВАРА, КОНТРАГЕНТЫ (поставщики), КЛИЕНТЫ (покупатели), РЕАЛИЗАЦИЯ(несет информацию о самой покупке), СОТРУДНИКИ, ГРУППЫ (данные о возможности доступа к функционалу системы для сотрудников). При создании ЗАГОЛОВКА НАКЛАДНОЙ необходимо указать поставщика и покупателя (КОНТРАГЕНТОВ). В связи с тем, что один и тот же КОНТРАГЕНТ может выступать в роли как поставщика, так и покупателя, необходимо выделять отдельно объекты ПОСТАВЩИК и ПОКУПАТЕЛЬ. Один и тот же ПОСТАВЩИК может привозить товар несколько раз, следовательно, объекты ПОСТАВЩИК и ЗАГОЛОВОК НАКЛАДНОЙ находятся в отношении один-ко-многим. Один и тот же ПОКУПАТЕЛЬ может приобретать товар несколько раз , следовательно, объекты ПОКУПАТЕЛЬ и РЕАЛИЗАЦИЯ находятся в отношении один-ко-многим. В каждой реализации могут быть сотрудники ответственные за данное действие , следовательно, объекты СОТРУДНИК и РЕАЛИЗАЦИЯ находятся в отношении один-ко-многим. Аналогично обстоит дело с сущностью ТИП ПОКУПКИ.

В большинстве случаев накладная содержит более одной позиции товаров, поэтому объекты ЗАГОЛОВОК НАКЛАДНОЙ и ТАБЛИЧНАЯ ЧАСТЬ НАКЛАДНОЙ находятся в отношении один?ко?многим.

В случае создания приходной накладной, название товара и его единица измерения выбирается из справочника товаров (объект АССОРТИМЕНТ). Объекты АССОРТИМЕНТ и ТАБЛИЧНАЯ ЧАСТЬ НАКЛАДНОЙ находятся в отношении один?ко?многим, т.е. один и тот же товар может включаться в различные накладные. Аналогично обстоит дело с сущностью УПАКОВКА.

Для удобства создания различных отчетов о движении товара выделим объект Склад (наличие товара в торговой точке). Каждая запись из ТАБЛИЧНОЙ ЧАСТИ НАКЛАДНОЙ должна соответствовать определенной записи в таблице СКЛАД (отношение один?ко?одному).

В случае создания расходной накладной (возврат товара поставщику) один и тот же товар может возвращаться поставщику по нескольким накладным (или несколькими отдельными записями в одной накладной), в этом случае связь между объектами СКЛАД и ТАБЛИЧНАЯ ЧАСТЬ НАКЛАДНОЙ можно описать отношением один?ко?многим.

Существуют неоднозначности между сущностями РЕАЛИЗАЦИЯ и АССОРТИМЕНТ. Один вит товара( ассортимента) может принимать участи в различных РЕАЛИЗАЦИЯХ. Для решения этой задачи вводится новая сущность РЕАЛИЗНААССОРТ, которая разрешает отношение многие-ко-многим, заменяя его на пару отношений один-ко-многим. Аналогичная ситуация и между сущностями СОТРУДНИКИ и ГРУППЫ.Необходимо отметить, что каждый объект обладает своими свойствами (атрибутами):

Attribute(s) of "Ассортимент": Код, Наименование, Описание, Цена, Фото, Тип товара, Код по ОКЕЙ, Масса нетто грамм, Ставка НДС.

Attribute(s) of "Группы": Код, Наименование, Изменять права доступа, Изменять пароли, Редактировать сотрудников, Редактировать клиентов, Редактировать контрагентов, Редактировать ассорт, Работа с накладными, Оформлять продажи, Доступ к статистике, Описание, Доступ к складскому учету.

Attribute(s) of "Должность": Name, Наименование, Описание, Оклад, Процент от продаж, Инструкция, Код.

Attribute(s) of "Заголовок накладной": Name, Код поставщика, Дата, Код сотрудника принявшего груз, Цена, Вес, Тип накладной, Код.Attribute(s) of "Клиенты": Name, Код, Фамилия, Имя, Отчество, Адрес, Паспорт, Дата регистрации, Предоставить скидку, Тип, РНН.

Attribute(s) of "Поставщик": Name, Наименование, Адрес, Телефон, e-mail, Дата регистрации, Код.

Attribute(s) of "Реализация": Name, Код клиента, Код сотдрудника, Дата, Замечания, Тип покупки, Код.

Attribute(s) of "РеализНаАссорт": Name, Код ассортимента, Код реализации, Количество, Код партии, Код.

Attribute(s) of "Склад": Name, Название, Адрес, Описание, Площадь (м2), Код.

Attribute(s) of "СотрНаГрупп": Name, Код сотрудника, Код группы, Код.

Attribute(s) of "Сотрудники": Name, Код, Фамилия, Имя, Отчество, Дата приема, Адрес, Телефон, Паспорт, Фотография, Замечания, Код должности, Табельный номер, РНН, Пол, Дата рождения, Место рождения, Образование.

Attribute(s) of "Табличная часть накладной": Name, Код, Код ассортимента, Код заголовка накладной, Количество, Код упаковки, По цене, Штук в одной таре, Годен до, Код склада размещения, Остаток, Найдено при инвентаризации.

Attribute(s) of "Тип покупки": Name, Наименование, Описание, Код.

Attribute(s) of "Тип товара": Name, Наименование, Описание, Код.

Attribute(s) of "Упаковка": Name, Наименование, Вес упаковки грамм, Занимаемая площадь, Код.

Алгоритм функционирования СУБД

Для построения использована модель «Сущность-Связь».

Модель Сущность-Связь (ER-модель) (англ. entity-relationship model (ERM) или англ. entity-relationship diagram (ERD)) -- модель данных, позволяющая описывать концептуальные схемы. Предоставляет собой графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных. В этом смысле ER-модель является мета-моделью данных, то есть средством описания моделей данных.

ER-модель удобна при прототипировании (проектировании) информационных систем, баз данных, архитектур компьютерных приложений, и других систем (далее, моделей). С её помощью можно выделить ключевые сущности, присутствующие в модели, и обозначить отношения, которые могут устанавливаться между этими сущностями.

ER-модель является одной из самых простых визуальных моделей данных (графических нотаций). Она позволяет обозначить структуру «крупными мазками», в общих чертах. Это общее описание структуры называется ER-диаграммой или онтологией выбранной предметной области (area of interest).

На этапе перехода к реализации данной ER-диаграммы в виде реальной информационной системы или программы, происходит отображение ER-модели в более детальную модель данных реляционной (объектной, сетевой, логической, или др.) базы данных, которая называется физической моделью данных по отношению к исходной ER-диаграмме.

На рисунке 2.1 показана ER-диаграмма базы данных, состоящая из 14 сущностей. Из неё можно понять, что основной связью между таблицами является связь один ко многим.

Рисунок 2.2.1 ER-диаграмма базы данных.

Основной алгоритм программы

Основной алгоритм программы приводиться в Приложении Б, лист 1, описывает возможность и последовательность работы программы.

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

Дополнительно в процессе аутентификации определяется профиль пользователя с заданными правами доступа.

Каждый профиль имеет свои права доступа:

- Менеджер по продажам имеет права доступа такие как:

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

- Менеджер по закупкам имеет права доступа такие как: редактирование контрагентов, редактировать ассортимент, работа с накладными, оформляет закупки, доступ к статистике, доступ к складскому учету.

- Технический администратор имеет все перечисленные права доступа, так же имеет такие права как: изменение прав доступа и паролей, редактирование списка пользователей., модернизация системы.

- Директор фирмы имеет все выше перечисленные права и контролирует деятельность всех других подразделений.

После завершения сеанса работы с клиентом определяются необходимость продолжения или завершения работы.

Рисунок 2.2.2 Основной алгоритм программы

Алгоритм работы менеджера по продажам

Алгоритм работы с клиентом приводится в Приложении Б, лист 2.

Менеджер по продажам ожидает запрос на продажу, если запрос не поступил, то он переходит в режим ожидания.

Если запрос поступил, то он проверяет наличие товара на складе, если товар отсутствует, то клиенту говорят, то что в данный момент товара нет на складе, он будет через определенное время. Если клиент не согласен ждать, то с ним прекращается работа. А если клиент согласен ждать, то его запрос передается менеджеру по закупкам.

Если товар присутствует на складе, то проверяется наличие всего ассортимента. Если клиент запрашивает n-ое количества товара и какой-то товар отсутствует, то менеджер ищет аналог данного товара. Если аналог товара имеется, то клиенту предлагается аналогичный товар.

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

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

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

Рисунок 2.3 Алгоритм работы менеджера по продажам

информационный безопасность склад электронный

2.2.5 Алгоритм работы менеджера по закупкам

Алгоритм работы с закупками приводится в Приложении Б, лист 3, в алгоритме приведена последовательная работа с закупкой товара. Менеджер по закупкам ожидает запрос на закупку товара, если запрос на закупку отсутствует, то менеджер по закупкам ожидает запрос. Если запрос поступил, то менеджер по закупкам проверяет наличие товара у поставщика, если у одного поставщика нет данного товара, то проверяются все поставщики, с которыми работает фирма.

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

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

После завершения сеанса работы с поставщиками определяется необходимость продолжения или завершения работы.

Рисунок 2.4 Алгоритм менеджера по закупкам

2.2.6 Алгоритм работы технического администратора

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

Рисунок 2.5 Алгоритм работы технического администратора

2.2.7 Алгоритм работы директора

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

Рисунок 2.6 Алгоритм работы директора

Выбор программного обеспечения

MS Access

Приложение Microsoft Access 97/2000 (далее Access)[3] является мощной и высокопроизводительной 32-разрядной системой управления реляционной базой данных (далее СУБД).

База данных[3] - это совокупность структурированных и взаимосвязанных данных и методов, обеспечивающих добавление выборку и отображение данных.

Реляционная база данных. Практически все СУБД позволяют добавлять новые данные в таблицы. С этой точки зрения СУБД не отличаются от программ электронных таблиц (Excel) ,которые могут эмулировать некоторые функции баз данных. Существует три принципиальных отличия между СУБД и программами электронных таблиц:

- СУБД разрабатываются с целью обеспечения эффективной обработки больших объёмов информации, больших, чем те, с которыми справляются электронные таблицы.

-СУБД может легко связывать две таблицы так, что для пользователя они будут представляться одной таблицей. Реализовать такую возможность в электронных таблицах практически невозможно.

-СУБД минимизируют общий объём базы данных. Для этого таблицы, содержащие повторяющиеся данные, разбиваются на несколько связанных таблиц.

Access - мощное приложение Windows. При этом производительность СУБД органично сочетаются со всеми удобствами и преимуществами Windows.

Как реляционная СУБД Access обеспечивает доступ ко всем типам данных и позволяет одновременно использовать несколько таблиц базы данных. Можно использовать таблицы, созданные в среде Paradox или dBase. Работая в среде Microsoft Office , пользователь получает в своё распоряжение полностью совместимые с Access

текстовые документы(Word) , электронные таблицы(Excel) , презентации(PowerPoint).С помощью новых расширений для Internet можно напрямую взаимодействовать с данными из World Wide Web и транслировать представление данных на языке HTML, обеспечивая работу с такими приложениями как Internet Explorer и Netscape Navigator.

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

База данных храниться в одном файле, но профессиональные пользователи предпочитают разделять базу данных на два файла: в одном хранятся объекты данных (таблицы, запросы), в другом объекты приложения (формы, отчёты, макросы, модули). Microsoft Access[3] -- реляционная СУБД корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, сортировку по разным полям, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.База данных. В общем смысле - совокупность сведений о конкретных объектах реального мира в какой-либо предметной области или разделе предметной области. В терминах СУБД MS Access база данных - это набор данных и объектов, связанных общей задачей. Каждая база данных - это совокупность таблиц, запросов, форм, отчётов, макросов и модулей, которая хранится в файле с произвольным именем и расширением .MDB.Microsoft Access объединяет сведения из разных источников в одной реляционной базе данных. Создаваемые формы, запросы и отчеты позволяют быстро и эффективно обновлять данные, получать ответы на вопросы, осуществлять поиск нужных данных, анализировать данные, печатать отчеты.

Технология ADO

Наряду с традиционными инструментами доступа к данным Borland Database Engine и ODBC в приложениях Delphi можно применять технологию Microsoft ActiveX Data Objects (ADO), которая основана на возможностях СОМ, а именно интерфейсов OLE DB.Технология ADO[4] завоевала популярность у разработчиков, благодаря универсальности -- базовый' набор интерфейсов OLE DB имеется в каждой современной операционной системе Microsoft. Поэтому для обеспечения доступа приложения к данным достаточно лишь правильно указать провайдер соединения ADO и затем переносить программу на любой компьютер, где имеется требуемая база данных и, конечно, установленная ADO.Провайдеры ADO обеспечивают соединение приложения, использующего данные через ADO, с источником данных (сервером SQL, локальной СУБД, файловой системой и т. д.). Для каждого типа хранилища данных должен существовать провайдер ADO. Провайдер "знает" о местоположении хранилища данных и его содержании, умеет обращаться к данным с запросами и интерпретировать возвращаемую служебную информацию и результаты запросов с целью их передачи приложению. Список установленных в данной операционной системе провайдеров доступен для выбора при установке соединения через компонент TADOConnection. При инсталляции Microsoft ActiveX Data Objects в операционной системе устанавливаются следующие стандартные провайдеры. - Microsoft Jet OLE DB Provider[4] обеспечивает соединение с данными СУБД Access при посредстве технологии ОАО. - Microsoft OLE DB Provider for Microsoft Indexing Service[4] обеспечивает доступ только для чтения к файлам и Internet-ресурсам Microsoft Indexing Service. - Microsoft OLE DB Provider for Microsoft Active Directory Service[4] обеспечивает доступ к ресурсам службы каталогов (Active Directory Service).

- Microsoft OLE DB Provider for Internet Publishing[4] позволяет использовать ресурсы, предоставляемые Microsoft FrontPage, Microsoft Internet Information Server, HTTP-файлы. - Microsoft Data Shaping Service for OLE DB[4] позволяет использовать иерархические наборы данных. - Microsoft OLE DB Simple Provider[4] предназначен для организации доступа к источникам данных, поддерживающим только базисные возможности OLE DB. - Microsoft OLE DB Provider for ODBC drivers[4] обеспечивает доступ к данным, которые уже "прописаны" при помощи драйверов ODBC. Однако реальное использование столь экзотичных вариантов соединений представляется проблематичным. Драйверы ODBC и так славятся своей медлительностью, поэтому дополнительный слой сервисов здесь ни к чему.

-Microsoft OLE DB Provider for Oracle[4] обеспечивает соединение с сервером Oracle. -Microsoft OLE DB Provider for SQL Server[4] обеспечивает соединение с сервером Microsoft SQL Server.

Delphi и базы данных

Базы данных считаются основным преимуществом Delphi. Этот язык не создавался специально под эту сферу, но реализация работы с данными здесь просто поражает. Даже специализированные языки для работы с базами данных (такие, как MS Visual FoxPro) явно уступают по простоте и мощи программирования этого типа приложений.

Delphi[5] скрывает все сложности и в то же время даёт тебе величайшую мощь. Ещё не было такой задачи, которую не смогли бы реализовать на Delphi за короткий промежуток времени. А главное, что всё это реализовано очень удобно и легко для понимания.

Для работы с базами в Delphi есть несколько наборов компонент. Каждый набор очень хорошо подходит для решения определённого круга задач. Почему такое разнообразие компонентов? Все они используют разные технологии доступа к данным и отличаются по возможностям. В отличие от Microsoft, которая встроила в свои продукты разработки только технологию доступа к данным ADO собственной разработки, фирма Borland дала разнообразие средств работающих через разные технологии и не ограничивает нас только своими разработками. Такое положение вещей даёт громадные преимущества перед другими программистами.

Помимо этого есть группы, которые могут использоваться в любом случае. На закладке Data Access в соответствии с рисунком 2.7 расположены основные компоненты доступа к данным. Эти компоненты общие для всех и могут использоваться совместно с другими группами компонентов.

Рисунок 2.7 Закладка Data Access палитры компонентов

На закладке Data Controls, в соответствии с рисунком 2.8 расположены компоненты для отображения и редактирования данных в таблицах. Эти компоненты так же используются в не зависимости от используемой технологии доступа к данным.

Рисунок 2.8 Закладка Data Controls палитры компонентов

Закладка BDE, в соответствии с рисунком 2.9 содержит компоненты, позволяющие получить доступ к базам данных по технологии, разработанной фирмой Borland под названием Borland Database Engine. Эта технология сильно устарела и поставляется только для совместимости со старыми версиями. Не смотря на это, она хорошо работает со старыми типами баз данных, такими как Paradox и dBase.

Рисунок 2.9 Закладка BDE палитры компонентов

DBExpress, в соответствии с рисунком 2.10 - это новая технология доступа к данным фирмы Borland. Она отличается большей гибкостью и хорошо подходит для программирования клиент серверных приложений, использующих базы данных. Компоненты с одноимённой закладки я советую использовать с базами данных построенных по серверной технологии, например, Oracle, DB2 или MySQL.

Рисунок 2.10 Закладка dbExpress палитры компонентов

ADO (Active Data Objects), в соответствии с рисунком 2.11 - технология доступа к данным, разработанная корпорацией Microsoft. Очень хорошая библиотека, но рекомендуется её использовать только с базами данных Microsoft, а именно MS Access или MS SQL Server. Её так же можно использовать, если есть специфичный сервер баз данных, который может работать только через ODBC.

Рисунок 2.11 Закладка ADO палитры компонентов

Работа с базами данных Access идёт через специальную надстройку DAO, которая может устанавливаться на компьютер вместе с программой Office или идти как отдельная установка. Если твоя программа не будет работать на компьютере клиента, то надо позаботиться о установке DAO на этот компьютер.

2.9 Требования к аппаратному обеспечению

АИС предназначена для работы на IBM ? совместимых персональных компьютерах. Компьютер должен иметь:

процессор Intel pentium и выше;

оперативную память 64 Мбайт и выше;

жесткий диск (при установке используется около 20 Мбайт);

печатающее устройство;

VGA?совместимый дисплей (рекомендуется SVGA?дисплей).

Для оптимальной работы подсистемы рекомендуется использовать компьютер с процессором Intel Pentium 667 и выше и не менее 32 Мб оперативной памяти.

2.10 Реализация аутентификации

Для реализации аутентификации в программе используется логин и пароль. Для предотвращения утраты пароля при потере базы используется криптографический механизм хеширования (hash). В базе хранится не сам пароль а его hash функция. При вводе пароля по асимметричному алгоритму CRC вычисляется hash и сравнивается со значением из базы.

3 ОБЩЕЕ ОПИСАНИЕ ПРОГРАММНОГО КОМПЛЕКСА

3.1 Структура базы данных электронного документооборота

Рисунок 3.1

Таблицы базы данных:

T_USER - таблица сотрудников.

ID - идентификатор пользователя;

SURNAME - фамилия;

NAME - имя;

PATRONYMIC - отчество;

PHONE - номер контактного телефона;

S_PHONE - номер сотового телефона;

PASSWORD - пароль для входа в систему;

T_BRANCH - таблица отделов организации.

ID - идентификатор отдела;

NAME - наименование отдела;

T_DATA_B_U - таблица данных (Отношение сотрудников к отделам).

ID - идентификатор;

ID_USER - идентификатор пользователя;

ID_BRANCH - идентификатор отдела;

T_FILES - таблица файлов.

ID - идентификатор файла;

CODE - код файла;

NAME - наименование;

DATA_CREATE - дата создания;

SYSCODE - системный код файла;

ID_USER - идентификатор пользователя создавшего файл;

ID_TYPE_DOC - идентификатор документария;

T_TYPE_DOC - таблица документария.

ID - идентификатор;

PARENT - родитель (иерархическая структура)

CODE - код документария;

NAME - наименование документария;

T_CONST - таблица констант.

ID - идентификатор;

NAME - наименование константы;

CODE - код константы;

VALUE - значение константы;

Связи базы данных:

FK_T_DATA_B_REFERENCE_T_USER - связь между таблицами T_USER и T_DATA_B_U родительское поле ID таблицы T_USER дочернее поле ID_USER таблицы T_DATA_B_U.

FK_T_DATA_B_REFERENCE_T_BRANCH - связь между таблицами T_BRANCH и T_DATA_B_U родительское поле ID таблицы T_BRANCH дочернее поле ID_BRANCH таблицы T_DATA_B_U.

FK_T_FILES_REFERENCE_T_USER - связь между таблицами T_USER и T_FILES родительское поле ID таблицы T_USER дочернее поле ID_USER таблицы T_FILES.

FK_T_FILES_REFERENCE_T_TYPE_D - - связь между таблицами T_TYPE_DOC и T_FILES родительское поле ID таблицы T_TYPE_DOC дочернее поле ID_TYPE_DOC таблицы T_FILES .

Программный комплекс «Архивариус» состоит из следующих основных модулей:

frmMain - данный модуль является основным модулем программного обеспечения. Модуль предназначен для визуального просмотра содержимого базы данных, управления (вызов) других модулей программного обеспечения и передачи им интерфейса подключения к базе данных.

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

frmAddDoc - данный модуль добавляет в базу данных описание документа и сохраняет файл в хранилище, вызывается с главного модуля программного обеспечения.

frmCopyDoc - копирует выбранный зарегистрированный файл с хранилища документов на компьютер пользователя.

frmTypeDoc - модуль для просмотра данных “Документария” вызов дополнительного модуля для добавления и редактирования “документария”. Вызывается с главного модуля программного обеспечения.

frmReTypeDoc - данный модуль выполняет две функции добавления и редактирования “документария”.

Входными данными комплекса являются данные:

«Вход в систему…»

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

Рисунок 3.1 Авторизация

Пользователь - Фамилия пользователя зарегистрированного в системе.

Пароль - пароль пользователя.

Тип документов (документарий)»

Добавление типа документа документария в справочник.

Номер - данное значение создается автоматически при создании типа документа, оно является уникальным.

Наименование - наименование документария вводится пользователем.

«Добавление документа»

Добавление документа в базу данных и загрузка электронного документа в хранилище.

Вид документа - выбирается из списка (типов документов “Документария”).

Номер - Входной номер документа.

Наименование - наименование документа.

Путь к файлу - путь к электронному документу для загрузки его в хранилище.

Выходными данными комплекса являются данные:

«Главное окно программы»

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

Номер - входной номер документа.

Тип документа - к какому документарию относится документ.

Название - наименование документа.

Дата создания - дата создания документа.

«Типы документов (документарии)»

Полный список документариев, зарегистрированных в системе.

Код - код документария.

Наименование - наименование документария.

«Копировать файл в …»

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

Номер - номер выбранного документа.

Наименование - наименование документа.

Копировать в … - копировать в указанную директорию

3.2 Характеристика используемого комплекса технических средств

При работе с программным комплексом “Электронный документооборот” необходимы следующие технические средства для более эффективной производительности:

Компьютер (Сервер) - который будет обеспечивать хранение файлов, участвующих в документообороте компании.

Основные требования и характеристики:

Процессор (CPU): Intel Core 2 Duo 3.0 G

Оперативная память (ОЗУ): 2048 mb

Носитель информации (HDD): 360 Gb

Сетевой адаптер (LAN): 100/1000 mb

Операционная система: Windows 2003 Server

СУБД: MS SQL Server 2000

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

Основные требования и характеристики:

Процессор (CPU): Intel CeleronM 2.0 G

Оперативная память (ОЗУ): 512 mb

Носитель информации (HDD): 80 Gb

Сетевой адаптер (LAN): 100/1000 mb

Операционная система: Windows XP

В приложении №6 описывается архитектура сети между компьютерами (Клиентами) и компьютером (Сервером).

ЗАКЛЮЧЕНИЕ

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

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

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

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

Разработка и внедрение автоматизированной системы учёта товарооборота позволило повысить качество управленческих решений .

Возможно применение в малом и среднем бизнесе (бухгалтерский учет, ввод заказов, ведение информации о клиентах, ведение информации о деловых контактах, кадрах и т.п.); при разработке программ и хранилищ данных на заказ (разработка внутриотраслевых приложений, разработка межотраслевых приложений, автоматизация некоторых функций предприятий); в крупных корпорациях (приложения для рабочих групп, системы обработки информации, документооборот); в качестве персональной СУБД (справочник по адресам, ведение инвестиционного портфеля, поваренная книга, каталоги книг, пластинок, комплектующих и т. п.); в качестве средства хранения данных, которое используется в других приложениях.

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

Разработанное приложение объемом 1,5 Мб имеет модульную структуру и представляет собой программу с процедурами, формами, отчетами, удовлетворяющую поставленным требованиям. Может эксплуатироваться на любом персональном компьютере типа IBM PC с процессором, начиная от i486 и с тактовой частотой не менее 66 МГц.

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Шумаков П. В. Базы данных в Delphi.- "Диасофт", 1997, 832 с.

2. Т. Конноли. Базы данных: Проектирование, реализация и сопровождение. Теория и практика. / Т. Конноли, К. Бегг, А. Страчан. - 2-е изд. - М.: Вильямс, 2000.

3. Бекаревич Ю., Пушкина Н. Самоучитель Microsoft Access 2000. - СПб.: БХВ - Санкт-Петербург, 1999, 480 стр.

4. Д. Кренке. Теория и практика построения баз данных. - С-Пб.: Питер, 2003.

5. Гультяев А.К. Проектирование и дизайн пользовательского интерфейса. / Гультяев А.К., Машин В.А. - С-Пб.: Корона Принт, 2000.

Размещено на Allbest.ru

...

Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.