Размещено на http://www.allbest.ru/

Содержание

Введение

1. Обоснование актуальности разработки

1.1 Анализ предметной области

1.2 Структура информационных потоков предприятия

1.2.1 Процесс приобретения новых автомобилей, автозапчастей и или расходных материалов

1.2.2 Процесс продажи или перемещения автомобилей и автозапчастей

1.3 Анализ программного средства с существующими аналогами

1.4 Выбор методов и средств создания программного средства

1.5 Обоснование выбора инструментальных средств разработки ПС

1.6 Математический аппарат программного средства

1.7 Техническое задание на разработку ПС

Вывод

2. Проектирование АРМ

2.1 Проектирование базы данных

2.1.1 Информационно логическая модель предметной области

2.1.2 Нормализация отношений

2.1.3 Логическое проектирование

2.1.4 Физическое проектирование

2.1.5 Входные и выходные данные

2.2 Архитектура программного средства

2.3 Реализация функционального назначения программного средства

2.4 Разработка алгоритма программного средства

2.5 Реализация математического метода решения задачи

2.6 Тестирование программного средства

Вывод

3. Разработка АРМ

3.1 Руководство пользователя

3.1.1 Запуск и выполнение программы

3.2Руководство системного программиста

3.2.1 Системные требования

Вывод

4. Расчет экономической эффективности программного средства

4.1 Технико-экономическое обоснование проекта

4.2 Определение трудоемкости разработки программного продукта

4.3 Расчет себестоимости программного продукта

4.4 Расчет экономического эффекта от внедрения программного продукта

Вывод

Заключение

Список использованных источников

Приложение А Программный код

Введение

информация компьютер вычислительная сеть

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

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

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

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

В данной дипломной работе рассматривается программное средство для автоматизации рабочего места ООО «Автоконтактсервис».

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

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

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

1. Исследовательский раздел

1.1 Анализ предметной области

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

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

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

У всех рабочих станций установлены источники бесперебойного питания UPS и сетевые фильтры, что позволяет свести к минимуму риск перебоев с электропитанием и соответственно благоприятно сказывается на техническом состоянии рабочих станций.

В отделе автоматизации производства работают четыре сотрудника:

1. Начальник отдела, организует: поиск поставщиков интернет услуг (провайдеров), расходных материалов и заключение с ними договоров; составление документа заявок сотрудников предприятия о приобретении расходных материалов на следующий месяц; контроль покупок новых автомобилей и автозапчастей; контроль перемещения комплектующих рабочих станций.

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

3. Инженер электронщик, организует: обеспечение работоспособности и обслуживание рабочих станций, принтеров, ксерокопировальных машин и изменение конфигурации рабочих станций.

4. Оператор печати, организует: ксерокопирование, печать больших карт.

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

1. Создание и ведение базы данных "Автозапчасти". База данных должна содержать следующие сведения:

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

- автомобили : фирма-производитель автомобиля; модель автомобиля; закупочная цена; состояние автомобиля; фирма-поставщик; дата поступления автомобиля на рабочую станцию;

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

2. Должна быть реализована возможность хранения истории движения заказов оборудования и комплектующих между рабочими станциями и складами с момента поступления оборудования от поставщика до продажи товара покупателям.

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

4. Необходимо организовать уровни доступа к базе данных, т.е. определить уровни доступа администратора БД, различных пользователей с помощью имен и паролей.

5. Реализовать возможность получения следующих выходных документов:

Счет-фактуру с данными о заказе;

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

1.2 Структура информационных потоков предприятия

Структура информационных потоков ООО “Автоконтактсервис” представлена на рисунке 1.1.



1

4

2 6

2

5,

Рисунок 1.1 - Структура информационных потоков ООО “Автоконтактсервис”

1 - заявка на приобретение расходных материалов

2 - распоряжение на продажу или перемещение автозапчастей

3 - средства на покупку

4 - накладные на автомобили и автозапчасти

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

6 - запрос на продажу или перемещение автозапчастей и автомобилей

1.2.1 Процесс приобретения новых автомобилей, автозапчастей или расходных материалов

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

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

1.2.2 Процесс продажи или перемещения автомобилей и автозапчастей

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

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

1.3 Анализ программного средства с существующими аналогами

Одним из аналогов разработанного ПС является ПС «КомпьюЛиб». Это программа для учета компьютеров и комплектующих. Данная программа имеет ряд существенных недостатков:

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

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

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

- отсутствие формирования выходной документации.

Кроме того, ПС «КомпьюЛиб» была реализована с использованием системы управления базами данных FoxPro и функционирует под управлением операционной системы DOS, что не удовлетворяет современным требованиям пользователей.

Также существуют такие ПС как AIDA32 и SiSoftSandra, которые предназначены для тестирования и диагностики компьютеров. Они также имеют недостатки. Такие как:

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

- отсутствие БД для хранения информации;

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

- не полностью русифицированы.

Все перечисленные недостатки не позволяют полноценно и максимально эффективно использовать их на предприятии. Также большое значение имеет стоимость лицензии на ПС.

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

1.4 Выбор методов и средств создания программного средства

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

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

Программы разбиваются на модули для того, чтобы:

упростить их разработку и реализацию;

- облегчить чтение программы;

упростить их настройку и модификацию;

облегчить работу с данными, имеющими сложную структуру;

избежать чрезмерной детализации алгоритмов;

обеспечить более выгодное размещение программ в памяти ЭВМ.

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

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

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

Наиболее распространенная трактовка реляционной модели данных принадлежит К.Дейту. Согласно Дейту, реляционная модель состоит из трех частей:

структурной части;

целостной части;

манипуляционной части.

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

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

Манипуляционная часть описывает два эквивалентных способа манипулирования реляционными данными - реляционную алгебру и реляционное исчисление.

Логическую структуру базы данных на основе реальной модели данных можно получить двумя методами:

методом семантического моделирования;

методом нормализации.

Семантическое моделирование представляет собой моделирование структуры данных, опираясь на смысл этих данных. В качестве инструмента семантического моделирования используются различные варианты диаграмм «сущность-связь» (ER - Entity-Relationship).

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

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

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

1.5 Обоснование выбора инструментальных средств разработки программного средства

Среди большого разнообразия для разработки приложения был выбран язык высокого уровня Borland Delphi-7. Delphi - это комбинация нескольких важнейших технологий:

1) высокопроизводительный компилятор в машинный код;

2) объектно-ориентированная модель компонент;

3) визуальное (а, следовательно, и скоростное) построение приложений из программных прототипов;

4) масштабируемые средства для построения баз данных.

Компилятор, встроенный в Delphi, обеспечивает высокую производительность, необходимую для построения приложений в архитектуре «клиент-сервер». Этот компилятор в настоящее время является самым быстрым в мире, его скорость компиляции составляет свыше 120 тысяч строк в минуту на компьютере 486DX33. Он предлагает легкость разработки и быстрое время проверки готового программного блока, характерного для языков четвертого поколения (4GL) и в то же время обеспечивает качество кода, характерного для компилятора 3GL. Кроме того, Delphi обеспечивает быструю разработку без необходимости писать вставки на языке программирования Си или ручного написания кода (хотя это возможно).

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

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

В стандартную поставку Delphi входят основные объекты, которые образуют удачно подобранную иерархию из 270 базовых классов. На Delphi можно одинаково хорошо писать как приложения к корпоративным базам данных, так и, к примеру, игровые программы. Во многом это объясняется тем, что традиционно в среде Windows было достаточно сложно реализовывать пользовательский интерфейс. Событийная модель в Windows всегда была сложна для понимания и отладки. Но именно разработка интерфейса в Delphi является самой простой задачей для программиста.

Среда Delphi включает в себя полный набор визуальных инструментов для скоростной разработки приложений (RAD - rapid application development), поддерживающей разработку пользовательского интерфейса и подключение к корпоративным базам данных. VCL - библиотека визуальных компонент, включает в себя стандартные объекты построения пользовательского интерфейса, объекты управления данными, графические объекты, объекты мультимедиа, диалоги и объекты управления файлами, управление DDE и OLE. Единственное, что можно поставить в вину Delphi, это то, что готовых компонент, поставляемых Borland, могло бы быть и больше. Однако, разработки других фирм, а также свободно распространяемые программистами freeware-компоненты уже восполнили этот недостаток.

Объекты БД в Delphi основаны на SQL и включают в себя полную мощь Borland Database Engine. В состав Delphi также включен Borland SQL Link, поэтому доступ к СУБД Oracle, Sybase, Informix и InterBase происходит с высокой эффективностью. Кроме того, Delphi включает в себя локальный сервер Interbase для того, чтобы можно было разработать расширяемые на любые внешние SQL-сервера приложения в онлайновом режиме. Разработчик в среде Delphi, проектирующий информационную систему для локальной машины (к примеру, небольшую систему учета медицинских карточек для одного компьютера), может использовать для хранения информации файлы формата .dbf (как в dBase или Clipper) или .db (Paradox). Если же он будет использовать локальный InterBase for Windows 4.0 (это локальный SQL-сервер, входящий в поставку), то его приложение безо всяких изменений будет работать и в составе большой системы с архитектурой клиент-сервер. Т.е. очень хорошая масштабируемость - одно и то же приложение можно использовать как для локального, так и для более серьезного клиент-серверного вариантов.

Выпущены две версии Delphi - одна (Delphi Client-Server) адресована для разработчиков приложений в архитектуре “клиент-сервер”, а другая (Delphi for Windows) предназначена для остальных программистов. Приложения, разработанные при помощи Delphi, можно использовать без выплаты royalty-процентов и без оплаты runtime- лицензий.

Клиент-серверная версия включает в себя следующие особенности:

1) SQL Links: специально написанные драйвера для доступа к Oracle, Sybase, Informix, InterBase;

2) локальный сервер InterBase: SQL-сервер для Windows 3.1. СУБД для разработки в корпоративных приложений на компьютере, не подключенном к локальной сети;

3) reportSmith Client/server Edition: генератор отчетов для SQL-серверов;

4) team Development Support: предоставляет версионный контроль при помощи PVCS компании Intersolve (приобретается отдельно) или при помощи других программных продуктов версионного контроля;

5) visual Query Builder - это средство визуального построения SQL-запросов;

6) лицензия на право распространения приложений в архитектуре клиент-сервер, изготовленных при помощи Delphi;

7) исходные тексты всех визуальных компонент.

Delphi for Windows представляет из себя подмножество Delphi Client-Server и предназначен для разработчиков высокопроизводительных персональных приложений, работающих с локальными СУБД типа dBase и Paradox.Delphi Desktop Edition предлагает такую же среду для быстрой разработки и первоклассный компилятор как и клиент-серверная версия (Client/Server Edition). Эта среда позволяет разработчику быстро изготавливать персональные приложения, работающие с персональными СУБД типа dBase и Paradox. Delphi позволяет также создавать разработчику DLL, которая может быть вызвана из Paradox, dBase, C++ или каких-нибудь других готовых программ:

1) компилятор Object Pascal (этот язык является расширением языка Borland Pascal 7.0);

2) генератор отчетов ReportSmith 2.5 (у которого, правда, отсутствует возможность работы с SQL-серверами);

3) среда визуального построителя приложений;

4) библиотека визуальных компонент;

5) локальный сервер InterBase.

В первую очередь Delphi предназначен для профессионалов-разработчиков корпоративных информационных систем. Здесь следует пояснить, что конкретно имеется в виду. Не секрет, что некоторые удачные продукты, предназначенные для скоростной разработки приложений (RAD - rapid application development) прекрасно работают при изготовлении достаточно простых приложений, однако, разработчик сталкивается с непредвиденными сложностями, когда пытается сделать что-то действительно сложное. Бывает, что в продукте вскрываются присущие ему ограничения только по прошествии некоторого времени.

Delphi такие ограничения не присущи. Хорошее доказательство тому - это тот факт, что сам Delphi разработан на Delphi.

Delphi предлагает разработчикам - как в составе команды, так и индивидуальным - открытую архитектуру, позволяющую добавлять компоненты, где бы они ни были изготовлены, и оперировать этими вновь введенными компонентами в визуальном построителе. Разработчики могут добавлять CASE-инструменты, кодовые генераторы, а также авторские help'ы, доступные через меню Delphi. Руководители предприятий, планирующие выделение средств на приобретение программных продуктов, должны быть уверены в том, что планируемые инвестиции окупятся. Поэтому одним из оцениваемых факторов должен быть вопрос - а легко ли найти специалиста по Delphi и сколько будет стоить его обучение, сколько времени специалист затратит на овладение продуктом. Ответ здесь получить весьма просто - любой программист на паскале способен практически сразу профессионально освоить Delphi. Специалисту, ранее использовавшему другие программные продукты, придется труднее, однако самое первое работающее приложение он сможет написать в течение первого же часа работы на Delphi. И, конечно же, открытая технология Delphi является мощным гарантом того, что инвестиции, сделанные в Delphi, будут сохранены в течение многих лет.

Team Development Support - средство поддержки разработки проекта в группе. Позволяет существенно облегчить управление крупными проектами. Это сделано в виде возможности подключения такого продукта как Intersolve PVCS 5.1 непосредственно к среде Delphi.

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

Благодаря такой архитектуре приложения, изготовленные при помощи Delphi, работают надежно и устойчиво. Delphi поддерживает использование уже существующих объектов, включая DLL, написанные на С и С++, OLE сервера, VBX, объекты, созданные при помощи Delphi. Из готовых компонент работающие приложения собираются очень быстро. Кроме того, поскольку Delphi имеет полностью объектную ориентацию, разработчики

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

В качестве системы управления базой данных было выбрано приложение «Microsoft Access». Выбор обоснован анализом таблицы 1.5.1

Таблица 1.5.1 - Сравнительные характеристики СУБД

Название	Access	Oracle	Inter Base
Производитель	Microsoft Borland	Oracle Corporate	Microsoft Borland
Формат файла	*.mdb	*. qdb	*.qdb
Обучаемость	Проста и удобна	Трудна в усвоении	Проста для знающих SQL
Технология создания БД	Визуальная, SQL	Визуальная, SQL	SQL
Установка, минимальные требования	Проста в установке. ОЗУ 16 Мб, Windows 95, Intel Pentium 133	Требовательна к ПО. ОЗУ 128 Мб, Windows 95, Intel Pentium II	Проста в установке. ОЗУ 32 Мб, Windows 95, Intel Pentium 133
Чаще используется	На малых предприятиях	От малых до крупных предприятий	На небольших предприятиях
Защита данных	Реализована на уровне получения или отказа в доступе ко всей БД	Высокоэффективные механизмы, контролирующие предоставление прав доступа	Реализована с возможность доступа отдельного пользователя к отдельным таблицам с правами: чтение, правка, запись
Поддерживаемая модель данных	Реляционная	Реляционная	Реляционная
Встроенный язык	Visual Basic	SQL*Plus	нет
Поддержка стандарта SQL	да	да	да
Поддержка объектов БД	таблицы, индексы, последователь-ности	домены, хранимые процедуры и триггеры, индексы	домены, хранимые процедуры и триггеры, последователь-ности, индексы
Средства поддержки ограничения целостности	Первичный и внешний ключи, индексы	Первичный и внешний ключи, индексы	Первичный и внешний ключи, индексы

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

Связи между таблицами можно разбить на четыре базовых реляционных типа с отношениями:

один-к-одному;

один-ко-многим;

многие-к-одному;

многие-ко-многим.

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

Также «Microsoft Access» предоставляет большое количество внутренних средств по оптимизации работы проектируемого приложения. К ним относятся:

загрузка модулей по требованию;

оптимизация дерева вызовов;

использование файлов MDE;

автоматическая поддержка компилированного состояния;

использование библиотек Windows API;

индивидуальная настройка системы;

эффективное использование индексов;

встроенный оптимизатор запросов.

1.6 Математический аппарат программного средства

Статистические гипотезы - это выдвигаемые теоретические предположения относительно параметров статистического распределения или закона распределения случайной величины. В соответствии с решаемой задачей различают параметрические и непараметрические гипотезы.

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

В статистике рассматривают простые и сложные параметрические гипотезы. Простая гипотеза содержит только одно предположение относительно оцениваемого параметра, например, предположение о том, что среднее значение j-го признака равно нулю: =0, или . Сложная гипотеза состоит из нескольких простых гипотез. Например, - это означает, что могут быть ; и т.д., т.е. здесь гипотеза состоит из набора простых гипотез.

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

Проверка статистических гипотез всегда допускает определенную вероятность ошибки в выводах:

- вероятность отвергнуть нулевую гипотезу, когда она справедлива;

- вероятность принять нулевую гипотезу, когда она ложна.

В экономических исследованиях обычно используется - вероятность ошибки первого рода. Наиболее распространенными в практике экономического анализа значениями являются: 0,01; 0,05; 0,1.

В многомерном анализе для проверки статистических гипотез используются те же статистические критерии, что и в одномерном, но они изменяются с учетом природы многомерных случайных величин. Чаще всего это критерии для проверки параметрических гипотез: t-Стьюдента, F-Фишера, и проверки непараметрических гипотез - .

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

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

, при альтернативной .

Для проверки многомерной гипотезы данного вида используется критерий, известный как критерий Хотеллинга

, (1.1)

где - ковариационная матрица; - матрица с центрированными значениями переменной: .

Расчетное значение () сравнивается с критическим значением, исчисляемым при заданном уровне вероятности () и числе степеней свобода и

. (1.2)

В формуле (1.2) - табличное значение F-критерия Фишера для числа степеней свободы и . Многомерная гипотеза о

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

1.7 Техническое задание на разработку программного средства

Необходимость автоматизации рабочего места менеджера попродажам автозапчастей и поставкам автомобилей ООО “Автоконтактсервис” привела к реализации процесса создания такой автоматизированной информационной системы, как программное средство автоматизированное рабочее место ООО “Автоконтактсервис”. Разрабатываемое программное средство будет выполнять функции учета поступления автомобилей и автозапчастей на предприятие, продажу автозапчастей.

В рамках разрабатываемого программного средства должны быть программно реализованы следующие функции:

- создания, просмотра базы данных автомобилей и автозапчастей;

редактирования учетных записей автомобилей и автозапчастей в базе данных;

поиска учетных записей по заданным критериям;

оперативного формирования, просмотра и печати выходной документации;

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

разграничения прав доступа конечных пользователей к базе данных;

-защиты от несанкционированного доступа и ошибок пользователей;

дальнейшей модификации и модернизации.

Выводы

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

В связи с вышеизложенным целесообразно перейти к проектированию базы данных ООО Автоконтактсервис.

2. Специальный раздел

2.1 Проектирование базы данных

Система управления базами данных должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о:

физическом размещении в памяти данных и их описаний;

механизмах поиска запрашиваемых данных;

проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);

способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;

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

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

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

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

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

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

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

2.1.1 Построение инфологической модели

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

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

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

При описании предметной области необходимо отразить между объектами разных классов. Различают связи типа «один к одному» (1:1), «один ко многим» (1:М), «многие ко многим» (М:М). Иногда эти типы связей называются степенью связи.

Спроектированная инфологическая модель представлена ER-диаграммой по методологии Ричарда Баркера на рисунке 2.1.1



Рисунок 2.1.1 - Инфологическая модель БД

Созданная инфологическая модель данных является источником информации для фазы логического проектирования базы данных.

2.1.2 Нормализация отношений

Реляционная модель данных является простейшей и наиболее привычной формой представления данных в виде таблицы. В теории множеств таблице соответствует термин отношение (relation), который и дал название модели. Достоинством реляционной модели является сравнительная простота ее инструментальных средств.

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

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

В реляционной базе данных на каждое отношение накладывается нормализация. Состав атрибутов отношений должен удовлетворять следующим требованиям:

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

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

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

Если имеется два атрибута А и В и если в любой момент времени каждому значению атрибута А соответствует не более одного значения атрибута В, то говорят, что В функционально зависит от А (А->Б).

Если отношение находится в 1НФ, то все неключевые атрибуты функционально зависят от ключа. Если неключевой атрибут зависит от части ключа, то говорят о частичной зависимости. Если неключевой атрибут зависит от всего составного ключа и не находится в частичной зависимости от его ключей, то говорят о его полной функциональной зависимости. Если для атрибутов А,Б,В выполняется условие А->Б, Б->В, но обратная зависимость отсутствует, то говорят, что В зависит от А транзитивно. Многозначная зависимость - если каждому значению атрибута А соответствует множество значений атрибутов Б.

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

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

Отношение находится в третьей нормальной форме (3НФ), если отношение находится во 2НФ и в нем отсутствуют транзитивные зависимости неключевых атрибутов от ключа.3НФ освобождает отношения от избыточности.

Отношение находится в четвертой нормальной форме (4НФ),если в нем не присутствуют функциональные многозначные зависимости. Если в отношении имеется много функциональных зависимостей,4НФ не устраняет избыточность, то применяют 5НФ.

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

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

Процесс нормализации отношений последовательно устраняет следующие типы функциональных зависимостей:

частичные зависимости неключевых атрибутов;

транзитивные зависимости неключевых атрибутов от ключа;

зависимости ключей от неключевых атрибутов;

независимые многозначные зависимости.

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

В результате нормализации получили отношения соответствующие 3НФ описанной предметной области:

деталь (код детали, серийный номер, инвентарный номер, цена, код типа детали, код фирмы-производителя, код модели, код поставщика);

тип детали (код типа детали, название типа детали, блочность);

фирма-производитель (код фирмы-производителя, название фирмы-производителя);

модель (код модели, название модели, код типа детали, код фирмы-производителя);

поставщик (код поставщика, название поставщика, телефон поставщика, город, улица, номер дома);

динамика состояний (код динамики состояния, дата, комментарий, код детали, код состояния);

состояние (код состояния, название состояния);

рабочая станция (код рабочей станции, название рабочей станции, код отдела, код ответственного);

отдел (код отдела, название отдела, телефон отдела, код руководителя);

руководитель (код руководителя, фамилия руководителя, имя руководителя, отчество руководителя);

ответственный (код ответственного, фамилия ответственного, имя ответственного, отчество ответственного, телефон ответственного, код должности);

должность (код должности, название должности);

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

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

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

2.1.3 Логическое проектирование

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

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

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

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

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

а) если многие из объектов обладают рассматриваемым свойством, то его можно записать, как и обычное свойство;

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



Размещено на http://www.allbest.ru/

Рисунок 2.1.2 - Логическая схема базы данных

2.1.4 Физическое проектирование

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

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

При разработке физической модели данных возникают вопросы:

хорошо ли спроектированы таблицы;

правильно ли выбраны индексы;

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

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

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

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

Данная реляционная база данных представлена в файле base.mdb имеет тип Access, который содержит в себе 14 таблиц, представленных в таблице 2.3.

Таблица 2.3 - Таблицы базы данных Base.mdb

Название таблицы	Таблица БД
Положение комплектующих	BLOCKDET
Деталь	DETAIL
Фирма-производитель	FIRMPR
Модель	MODEL
Отдел	OTDEL
Ответственный	OTVET
Поставщик	POST
Руководитель отдела	RUKOVOD
Динамика состояний	SOST
Состояние	SOSTNAME
Тип детали	TIPDET
Ведомость замен комплектующих	VEDZAM
Положение автозапчастей и автомобилей	WORKDET
Рабочая станция	WRKSTN

Описания выше указанных таблиц представлено в таблице 2.4

Таблица 2.4 - Описание таблиц БД

Объект	Свойство	Ключи	Логические ограничения	Информационные процессы происходящие с объектами
			Тип	Длина	Запол-нение
1	2	3	4	5	6	7
Рабочая станция	Код рабочей станции	П У	I		*	Генерируется программно
	Название рабочей станции		С	15	*
	Код детали		I		*
	Код отдела		I		*
	Код ответственного		I		*
	Дата поступления детали на рабочую станцию		D		*
Деталь	Код детали	П У	I		*	Генерируется программно
	Тип детали		С	25	*
	Фирма-производитель детали		C	25	*
	Модель детали		C	25	*
	Состояние детали		I	1	*
	Серийный номер детали		C	15	*
	Код фирмы-поставщика детали		I		*
Отдел	Код отдела	П У	I		*	Генерируется программно
	Название отдела		C	25	*
	Телефон отдела		I	10	*
	Фамилия руководителя отдела		C	25	*
	Имя руководителя отдела		C	25	*
	Отчество руководителя отдела		C	25	*
Ответственный	Код ответственного	П У	I		*	Генерируется программно
	Фамилия ответственного		C	25	*
	Имя ответственного		C	25	*
	Отчество ответственного		C	25	*
	Должность		C	20	*
	Телефон ответственного		I	10	*
Фирма- поставщик детали	Код фирмы - поставщика ...

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

• Основные принципы организации баз данных

  Системы автоматизированной обработки информации. Хранение большого объема информации. Понятие базы данных (БД). Обеспечение секретности данных. Уровни представления данных в БД. Логическая структура данных. Ограничения, накладываемые на данные.
  
  реферат [65,2 K], добавлен 26.11.2011
  

• Разработка программного продукта, оптимизирующего создание отчетов по базе данных

  Деятельность отдела информационных технологий. Сопровождение аппаратных средств, баз данных и локальной вычислительной сети. Обслуживание телекоммуникаций и защита информации. Разработка программного средства, работающего с базой данных Oracle.
  
  курсовая работа [405,1 K], добавлен 16.09.2012
  

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

  Общий анализ структуры локальной вычислительной сети военного назначения. Необходимость повышения защиты информации путем использования дополнительных средств защиты. Создание виртуальных защищенных сетей в рамках локальной компьютерной сети объекта.
  
  дипломная работа [1,2 M], добавлен 20.10.2011
  

• Память компьютера

  Организация и основные характеристики основной памяти персонального компьютера. Запоминающие устройства ЭВМ как совокупность устройств, обеспечивающих хранение и передачу данных. Хранение и обработка информации. Основные виды памяти компьютера.
  
  контрольная работа [52,0 K], добавлен 06.09.2009
  

• Создание локальной вычислительной сети страховой компании

  Настройка телекоммуникационного оборудования локальной вычислительной сети. Выбор архитектуры сети. Сервисы конфигурации сервера. Расчет кабеля, подбор оборудования и программного обеспечения. Описание физической и логической схем вычислительной сети.
  
  курсовая работа [1,3 M], добавлен 22.12.2014
  

• Программа складского учета на предприятии ООО "МоторТрансойл"

  Автоматизация процесса мониторинга товара на складе. Автоматическое заполнение товарной документации. Поиск необходимой информации. Уменьшение временных затрат работников по составлению отчетов. Хранение большого объема информации в электронном виде.
  
  курсовая работа [2,3 M], добавлен 20.05.2013
  

• Защита локальной сети ТОГБОУ СПО "Котовский индустриальный техникум"

  Проверка локальной вычислительной сети техникума (ТОГБОУ СПО "КИТ") с помощью сетевого сканера безопасности XSpider. Средства защиты информации. Отключение удаленного помощника. Система защиты информации от несанкционированного доступа SECRET NET.
  
  отчет по практике [1,4 M], добавлен 21.10.2015
  

• Проектирование базы данных абонентов телефонной сети

  Создание базы данных и ее системы управления. Динамическая информационная структура, двунаправленный список. Создание файла, содержащего сведения об абонентах телефонной сети. Вывод информации в файл для печати. Обработка информации в базе данных.
  
  курсовая работа [1,7 M], добавлен 18.03.2013
  

• Создание базы данных для электронного магазина с помощью "Денвер"

  Представление данных в памяти компьютера. Обобщенные структуры и модели данных. Методы доступа к информации. Физическая организация системы управления базами данных, структура сервера. Архитектура "клиент-сервер". Создание базы данных с помощью "Денвер".
  
  курсовая работа [770,3 K], добавлен 17.11.2014
  

• Решения прикладных задач с реализацией автоматизированной обработки экономической информации

  Разработка программы на языке Си++ и осуществление постановки и выбора алгоритмов решения задач обработки экономической информации, создание и редактирование базы данных, сортировка записей по определенному запросу, анализ эффективности обработки данных.
  
  контрольная работа [316,8 K], добавлен 28.08.2012
  

• Проектирование локальной вычислительной сети

  Создание локальной вычислительной сети, ее топология, кабельная система, технология, аппаратное и программное обеспечение, минимальные требования к серверу. Физическое построение локальной сети и организация выхода в интернет, расчет кабельной системы.
  
  курсовая работа [749,1 K], добавлен 05.05.2010
  

• Тенденция развития локальных сетей

  Развитие информационных технологий. Разработка персонального компьютера. История возникновения локальной вычислительной сети. Задачи сервера. Классификация компьютерных сетей. Технология передачи информации. Межсетевое взаимодействие. Появление Интернет.
  
  презентация [669,9 K], добавлен 16.03.2015
  

• Разработка программного средства автоматизации обслуживания заявок пользователей локальной вычислительной сети филиала РГУ нефти и газа имени И.М. Губкина в г. Оренбурге

  Разработка базы данных учета и хранения заявок пользователя. Создание программного средства на основе клиент/серверной технологии. Описание возможностей платформы Tandem Framework. Апробация программы автоматизации процессов подачи и обработки заявок.
  
  дипломная работа [3,6 M], добавлен 08.03.2013
  

• Организация защиты информации в локальной вычислительной сети (на примере ОАО "Марийский машиностроительный завод")

  Организация компьютерной безопасности и защиты информации от несанкционированного доступа на предприятиях. Особенности защиты информации в локальных вычислительных сетях. Разработка мер и выбор средств обеспечения информационной безопасности сети.
  
  дипломная работа [1,6 M], добавлен 26.05.2014
  

• Модернизация локальной вычислительной сети на предприятии

  Общая характеристика локальных вычислительных сетей, их основные функции и назначение. Разработка проекта модернизации локальной компьютерной сети предприятия. Выбор сетевого оборудования, расчет длины кабеля. Методы и средства защиты информации.
  
  дипломная работа [1,5 M], добавлен 01.10.2013
  

• Создание базы данных "Администратор гостиницы"

  Анализ предметной области. Требования, предъявляемые при составлении базы данных гостиницы. Реализация процесса поиска необходимой информации. Формирование таблиц, запросов, отчетов и вывод их на печать. Редактирование, добавление и хранение данных.
  
  курсовая работа [2,0 M], добавлен 07.02.2016
  

• Основные понятия информатики

  Информатика - технология сбора, хранения и защиты информации. Обработка текстовой информации, специализированное и прикладное программное обеспечение. Технические средства; базы данных; автоматизированные информационные системы; антивирусные средства.
  
  реферат [24,6 K], добавлен 09.12.2012
  

• Понятие информации и программного обеспечения

  Методы и единицы измерения количества и объема информации. Общее понятие, виды, классификация программного обеспечения. Классическая архитектура электронной вычислительной машины. Основополагающие принципы логического устройства компьютера Фон Неймана.
  
  реферат [272,3 K], добавлен 16.02.2014
  

• Средства передачи информации в компьютерных сетях

  Изучение понятия локальной вычислительной сети, назначения и классификации компьютерных сетей. Исследование процесса передачи данных, способов передачи цифровой информации. Анализ основных форм взаимодействия абонентских ЭВМ, управления звеньями данных.
  
  контрольная работа [37,0 K], добавлен 23.09.2011
  

• Локальная вычислительная сеть

  История интрасети и приложений. Анализ входной и выходной информации "Автосалон "Алмаз"". Внедрение локальной вычислительной сети. Создание базы данных и пользовательского интерфейса с использованием языков запроса SQL. Разработка политики безопасности.
  
  дипломная работа [2,0 M], добавлен 27.02.2015
  

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам