Главная База знаний "Allbest" Программирование, компьютеры и кибернетика Разработка информационной подсистемы "Склад" ООО "Минтком"

Разработка информационной подсистемы "Склад" ООО "Минтком"

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

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

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

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

Страница:

2. Dreamweaver - лидер на рынке ПО для вэб дизайна от компании Adobe, имеет богатый набор встроенных средств, библиотек, стилей.

3. GEdit\Vi\Notepad - некоторые специалисты ООО «Минтком» предпочитают работать непосредственно в текстовом редакторе, без использования дополнительных средств разработки.

На предприятии существует базовое программное обеспечение, к нему относятся OS Windows с пакетом прикладных программ Microsoft Office.

На большинстве рабочих станций установлено следующее общее программное обеспечение (независимо от отдела):

1. Microsoft Windows XP Номе Edition SP3;

2. Пакет Microsoft Office 2003;

3. На рабочих станциях установлен Kaspersky LAB 6, администрируемый с сервера при помощи Kaspersky Administrator Kit 8;

4. Программа Adobe Acrobat Reader 9.0 для работы с отсканированными документами, и другими данными в формате *.pdf;

5. Программа Nero 8.7.13 Ultra ISO предназначенная для чтения данных в форматах файл-образа;

6. Программные продукты компании 1С: Предприятие;

7. ProcEx - менеджер процессов;

8. Total Commander - файловый менеджер;

9. Python 3.4 - последняя стабильная версия интерпретатора с языка python. Может работать не только с простыми файлами, но и с файлами байт-кода. Он нужен для исполнения и тестирования скриптов на языке python.

Всё программное обеспечение, используемое в компании «Минтком» является лицензионным, и используется с соблюдением всех прав правообладателя и уголовного кодекса Российской Федерации.

2.2.3 Анализ существующего организационного и правового обеспечения

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

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

Трудовой кодекс Российской Федерации - кодифицированный законодательный акт о труде, Федеральный закон № 197-ФЗ от 30 декабря 2001 года. Кодекс определяет трудовые отношения между работниками и работодателями и имеет приоритетное значение перед другими принятыми федеральными законами, связанными с трудовыми отношениями, с Указами Президента РФ, Постановлениями Правительства РФ и др.

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

Система Консультант Плюс - надежный помощник для многих специалистов: юристов, бухгалтеров, руководителей организаций, а также для специалистов государственных органов, ученых и студентов. В ней содержится огромный массив правовой и справочной информации [13]. Консультант Плюс - компьютерная справочно-правовая система по законодательству России. Разрабатывается ЗАО «Консультант Плюс» и содержит более 5 млн документов. Распространяется через сеть региональных информационных центров состоящую из 300 центров, расположенных в крупных городах, и более 400 сервисных подразделений в небольших населенных пунктах. Информация, включённая в систему структурирована по разделам, в настоящее время в Консультант Плюс существуют следующие разделы: законодательство, судебная практика, финансовые и кадровые консультации, консультации для бюджетных организаций, комментарии законодательства, формы документов, законопроекты, международные правовые акты, правовые акты по здравоохранению, технические нормы и правила.

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

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

2.3 Описание выявленных преимуществ и недостатков функционирующей АСОИУ

Обычно автоматизированная система управления имеет полный набор функций по всем операциям технологического процесса. Эта система может иметь достаточно развитый экранный интерфейс для общения с менеджером склада или же определенного технологического участка. Однако большая часть управляющих распоряжений операторам выдается в виде бумажного документа. После получения этого документа оператором и до момента ввода в АСУ подтверждения о выполнении задания АСУ фактически не имеет связи с выполняемой операцией и не может контролировать ход ее исполнения. Оператор производит все запланированные в документе действия, пользуясь только бумажным документом и, завершив эти действия, вводит в АСУ отчет с клавиатуры РС. Такой отчет обычно имеет вид ввода подтверждения об исполнении «Заявки № ....» . Оператор может совершить ошибку ( и обязательно совершает их) и эта ошибка проявится только при выявлении пересортицы в комплектовании заказов, при отсутствии паллета на ожидаемом месте или же при инвентаризации склада. Для “отлова” такого рода ошибок обычно разрабатываются различные контрольные бумажные документы, оборот которых замедляет технологический процесс, но не устраняет ошибки. Количество ошибок ( их часто называют «дефектами») в АСУ такого типа по мере эксплуатации склада катастрофически растет и, наконец, наступает момент, когда работа затрудняется настолько, что склад приходится останавливать на внеплановую инвентаризацию, или же производить инвентаризацию «на ходу». В таких системах приходится либо мириться с браком и потерями в работе, либо терять значительное время на проведение внеплановых инвентаризаций. Эти системы не в состоянии обеспечивать современный динамичный бизнес оперативной информацией; в них очень трудно управлять процессами и отдельными операциями и т.д и т. п. Можно сформулировать массу недостатков таких систем, но лучше коротко сказать, что они безнадежно устарели и при внедрении имеют только одно преимущество - низкие цены.

Склад всегда воспринимался как «черный ящик», в который из офиса предприятия поступал листок с заказом. Затем по складу бегали товароведы и грузчики и, наконец, на рампе отгрузки появлялся подобранный заказ. Если заказ подобран неправильно, то это станет известно после получения претензии от покупателя. Такая претензия становится фактически «обратной связью» для данного заказа, но она поступила слишком поздно, чтобы принять оперативное решение об исправлении ошибок! При совершении ошибки почти невозможно найти виновного. Время и качество выполнения заданий зависти от опыта товароведа. К сожалению, эта категория сотрудников в такой ситуации имеет все рычаги нажима на руководство. И часто этим пользуются для решения различных вопросов с выгодным для них результатом. При использовании современных адресных АСУ функции управления складом сосредотачиваются в руках нескольких менеджеров системы, непрерывно находящихся за экранами компьютеров, формирующих задания для операторов и отслеживающих ход их выполнения во времени.

2.4 Разработка предложений по совершенствованию существующей АСОИУ

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

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

2.5 Выводы по разделу

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

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

Анализ технического обеспечения показал, что большинство рабочих мест сотрудников предприятия оснащены компьютерами с различной архитектурой и различным программным обеспечением. Большинство компьютеров объединены в сеть. Корпоративная сеть предприятия построена на основе DNS адресации. Центральной частью сети компании является сервер, совмещающий в себе функции файлового сервера, сервера терминалов, почтового- , интернет-сервера и сервера баз данных.

Анализ программного обеспечения показал, что на большинстве рабочих станций в качестве программного обеспечения используется операционная система Windows XP Home Edition SP3, которая содержит средства для коллективной работы с данными. Так же на некоторых рабочих станциях установлена операционная система Windows 7 Professional. Полноценную работу с документами обеспечивают средства пакетов Microsoft Office и Open Office, на компьютерах специалистов работающих с 1С установлен весь спектр средств для работы с этой программой, включающий в себя наборы расширений и конфигураций для разработки.

Анализ существующего правового обеспечения показал, что деятельность компании опирается на положения правового кодекса. На рабочих местах юристов установлены программные продукты «Консультант +».

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

3. РАЗРАБОТКА ИНФОРМАЦИОННОЙ ПОДСИСТЕМЫ «СКЛАД» ООО «МИНТКОМ»

3.1 Обоснование разработки подсистемы «Склад» компании «Минтком»

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

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

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

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

2. Приобрести адаптируемое решение и услуги по настройке;

3. Привлечь собственных специалистов, которые создадут решение. Данный подход должен иметь право на жизнь только в случае совершенной уникальности стоящих задач. Аргументами за использование такого подхода может служить только полное соответствие решения поставленным задачам [16].

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

Технологическая платформа «1С:Предприятие» не является программным продуктом для использования конечными пользователями, которые обычно работают с одним из многих прикладных решений (конфигураций), использующих единую технологическую платформу. Платформа и прикладные решения, разработанные на её основе, образуют систему программ «1С:Предприятие», которая предназначена для автоматизации различных видов деятельности, включая решение задач автоматизации учёта и управления на предприятии (КИС).

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

Для автоматизации складом компании был выбран третий подход. Такое решение было принято по следующим причинам:

- высокая стоимость тех программ, которые уже существуют на рынке;

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

Таблица 3.1 - Сравнительная характеристика АС для склада

Название

Кол-во пользователей

Возможности

Цена, руб.

“ФОЛИО Логистик Склад” 8.1

? 10

поддержка бумажной технологии или ограниченного круга терминалов сбора данных; предоставление стандартных отчетов; автономный режим работы или простейший интерфейс обмена данными с головной системой

12 000

Advantics фирмы PSI Logistics

? 40

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

50 000

Radio Beacon WMS Expert фирмы Radio Beacon

10 - 40

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

15 000 50 000

Logistics Vision Suite от Mantis

? 30

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

30 000

CoreWMS от “Аргус Софт”

25 - 40

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

15 000

30 000

То есть автоматизированная система управления складом будет создана именно для этого предприятия и будет уникальным в своем роде. Данная программа будет выполнять такие операции как:

- адресный учет товарно-материальных ценностей на складе;

- разбиение сложных складских процедур на простейшие технологические операции;

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

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

- получение информации об исполнителе каждой технологической операции.

Основными преимуществами предлагаемого нами решения являются:

- простота во внедрении и использовании;

- уникальность и полное соответствие всем требования предприятия;

- невысокая стоимость.

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

3.2 Проектирование функциональной структуры подсистемы «Склад»

3.2.1 Построение дерева целей функционирования подсистемы «Склад»

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

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

Рисунок 3.1 - Дерево целей функционирования подсистемы

3.2.2 Построение функциональной структуры подсистемы «Склад»

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

- регистрация поступления товаров;

- регистрация движения товаров;

- формирование отчетной документации;

- сервисные функции.

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

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

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

- учет оплаты поступивших материалов с банковскими счетами.

- формирование «Приходного ордера».

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

- учёт движения товаров и материалов внутри компании.

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

Подсистема «Формирование отчётной документации» предназначена для выполнения информационной функции поиска и выдачи информации по базам данных АСУ. Подсистема реализует функции:

- формирование «Протокола суточных поступлений».

- формирование «Протокола поступления за интервал времени ".

- формирование «Протокола поступления материала по поставщику".

- формирование остатков товара на складе.

3.3 Проектирование информационной базы данных для подсистемы «Склад»

3.3.1 Инфологическое проектирование информационной базы данных

Концептуальное (инфологическое) проектирование - построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности [15].

Чаще всего концептуальная модель базы данных включает в себя:

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

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

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

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

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

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

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

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

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

3. Сотрудник - сотрудники, работающие в компании;

4. Должность - должности сотрудников;

5. Тип и класс - информация о распределении товаров и материалов по принадлежности;

6. Пользователь - сотрудники, работающие с разрабатываемой программой;

7. Документ - документ, на основании которого происходит поставка или реализация товара;

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

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

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

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

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

Между двумя сущностям, например, А и В возможны четыре вида связей. Первый тип - связь один к одному: в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В.

Второй тип - связь один ко многим: одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

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

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

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

Инфологическая модель применяется после словесного описания предметной области (рисунок 3.3).

Рисунок 3.3 - Инфологическая модель базы данных

Определим связи между сущностями.

- внутри определенного класса товаров можно выделить несколько типов товаров. Например, к классу "Сетевое оборудование" можно отнести такие типы как «коммутаоры», «маршрутизаторы», «сетевые адаптеры» и подобные;

- определенный товар принадлежит только к одному классу и, соответственно, только к одному типу товаров;

- товар поступил на склад в соответствии с определенными документами и от определенного поставщика;

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

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

- сотрудник компании занимает определенную должность внутри компании;

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

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

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

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

Система управления базами данных (СУБД) - совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных [16].

Основные функции СУБД:

- управление данными во внешней памяти (на дисках);

- управление данными в оперативной памяти;

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

- поддержка языков БД.

Обычно современная СУБД содержит следующие компоненты:

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

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

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

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

При выборе СУБД немаловажным критерием является стоимость программного обеспечения. В настоящее время на рынке представлены как коммерческие, так и свободные версии СУБД. Среди версий, которые распространяются свободно, необходимо выделить две распространенные СУБД: PostgreSQL и MySQL.

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

MySQL - свободная система управления базами данных, является собственностью компании Oracle Corporation, получившей её вместе с поглощённой Sun Microsystems, осуществляющей разработку и поддержку приложения. Распространяется под GNU General Public License или под собственной коммерческой лицензией. Помимо этого разработчики создают функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации. MySQL является решением для малых и средних приложений. Входит в состав серверов WAMP, LAMP и в портативные сборки серверов Денвер, XAMPP. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы.

Гибкость СУБД обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.

MySQL имеет двойное лицензирование. Может распространяться в соответствии с условиями лицензии GPL. Однако по условиям GPL, если какая-либо программа включает исходные коды MySQL, то она тоже должна распространяться по лицензии GPL. Это может расходиться с планами разработчиков, не желающих открывать исходные тексты своих программ. Для таких случаев предусмотрена коммерческая лицензия, которая также обеспечивает качественную сервисную поддержку [20].

3.3.3 Даталогическое проектирование информационной базы данных

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

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

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

Нормализация - это метод организации реляционной базы данных с целью сокращения избыточности. В ходе этого процесса неоптимальная таблица разбивается на две или более таблиц, между которыми создаются отношения. Нормализация является частью этапа проектирования и выполняется над существующими таблицами. Нормализация позволяет в полной мере реализовать преимущества реляционной модели. Нормализация заставляет разработчика создавать больше таблиц, равномернее распределяя в них информацию, что приводит к снижению избыточности. Нормализация определяется в виде набора правил, известных как нормальные формы. После своей статьи, посвященной реляционной алгебре, доктор Кодд в 1972 г. опубликовал работу под названием «Дальнейшая нормализация реляционной модели баз данных» («Further Normalization of the Data Base Relational Model»). В этом документе были описаны первые три нормальные формы. В последующих работах доктора Кодда и других авторов были определены три другие нормальные формы. Каждая нормальная форма основана на предыдущей, поэтому, например, третья форма более желанна, чем вторая. Устранение избыточности не обязательно означает повышение производительности. Накладные расходы на выполнение операций объединения весьма значительны, поэтому разработчики иногда сознательно идут на нарушение правил нормализации. Это называется денормализацией.

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

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

С учётом приведенных ранее выкладок, применимо к выбранной СУБД таблицы базы данных будут иметь вид (таблицы 3.2 - 3.10).

Таблица 3.2 - Структура таблицы «Товар»

Наименование поля

Описание

Тип данных

Размер

Код

Счетчик

ID_класс

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

Текстовый

5

ID_Тип

Тип товара внутри класса товара

Текстовый

5

Наименование

Модель оборудования, наименование товара

Текстовый

20

ID_Производитель

Фирма, являющаяся производителем товара

Текстовый

5

Стоимость

Цена покупки товара в соответствии с приходной накладной

Текстовый

20

ID_Сотрудник

Сотрудник, за которым закреплено оборудование или товар, при неиспользуемом оборудовании, оно закрепляется за сотрудником склада

Текстовый

5

ID_Документ

Номер приходной накладной при получении товара

Текстовый

5

Таблица 3.3 - Структура таблицы «Документ»

Наименование поля

Описание

Тип данных

Размер

Код

Счетчик

Номер_документа

Номер документа

Текстовый

20

Дата_составления

Дата документа в длинном формате даты (15 марта 2011г.)

Дата

20

Таблица 3.4 - Структура таблицы «Пользователи»

Наименование поля

Описание

Тип данных

Размер

Код

Счетчик

ID_Сотрудник

Указатель на сотрудника компании

Текстовый

5

Логин

Логин для входа пользователя в подсистему управления складом

Текстовый

20

Пароль

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

Текстовый

20

ID_Права_доступа

Статус пользователя при работе с программой (Пользователь, администратор)

Текстовый

20

Таблица 3.5 - Структура таблицы «Поставщики»

Наименование поля

Описание

Тип данных

Размер

Код

Счетчик

Наименование

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

Текстовый

20

ИНН

Идентификационный номер

Текстовый

20

Город

Город поставщика

Текстовый

20

Адрес

Адрес поставщика

Текстовый

20

Представитель

Представитель фирмы или лица, выполняющего роль поставщика

Текстовый

20

Телефон

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

Текстовый

20

E-Mail

Почтовый адрес компании или представителя

Текстовый

20

Описание

Прочие характеристики компании, род деятельности, заметки

Текстовый

200

Таблица 3.6 - Структура таблицы «Сотрудники»

Наименование поля

Описание

Тип данных

Размер

Код

Счетчик

Фамилия

Текстовый

20

Имя

Текстовый

20

Отчество

Текстовый

20

ID_Должность

Занимаемая должность в соответствии со справочником должностей

Текстовый

5

Дата рождения

Дата рождения сотрудника в длинном формате даты (15 марта 2011г.)

Дата

20

E-Mail

Почтовый адрес

Текстовый

50

Таблица 3.7 - Структура справочника «СП_Должности»

Наименование поля

Тип данных

Размер

Код

Счетчик

Должность

Текстовый

20

Таблица 3.8 - Структура справочника «СП_Классы»

Наименование поля

Тип данных

Размер

Код

Счетчик

Класс

Текстовый

20

Таблица 3.9 - Структура справочника «СП_Типы»

Наименование поля

Тип данных

Размер

Код

Счетчик

ID_Класс

Текстовый

5

Тип

Текстовый

20

Таблица 3.10 - Структура справочника «СП_Производители»

Наименование поля

Тип данных

Размер

Код

Счетчик

Производитель

Текстовый

20

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

Рисунок 3.4 - Даталогическая модель базы данных

3.4 Описание применяемых средств защиты информации в базе данных

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

- средства архивации данных;

- антивирусные программы;

- криптографические средства;

- средства идентификации и аутентификации пользователей;

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

- протоколирование и аудит.

Как примеры комбинаций вышеперечисленных мер можно привести:

- защиту баз данных;

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

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

- ZIP, ARJ, для операционных систем Windows;

- TAR для операционной системы Unix;

- межплатформный формат JAR, RAR.

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

Антивирусные программы - программы разработанные для защиты информации от вирусов. Обязательным (необходимым) свойством компьютерного вируса является возможность создавать свои дубликаты (не обязательно совпадающие с оригиналом) и внедрять их в вычислительные сети и/или файлы, системные области компьютера и прочие выполняемые объекты. При этом дубликаты сохраняют способность к дальнейшему распространению. Следует отметить, что это условие не является достаточным т.е. окончательным. Вот почему точного определения вируса нет до сих пор, и вряд ли оно появится в обозримом будущем. Следовательно, нет точно определенного закона, по которому “хорошие” файлы можно отличить от “вирусов”. Более того, иногда даже для конкретного файла довольно сложно определить, является он вирусом или нет [23].

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

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

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

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

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

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

3.5 Описание средств обеспечения достоверности и целостности информации

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

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

Для полей (атрибутов) используются следующие виды ограничений:

- тип и формат поля;

- задание диапазона значений;

- недопустимость пустого поля;

- задание домена;

- проверка на уникальность значения какого-либо поля.

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

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

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

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

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

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

3.6 Описание программного обеспечения проекта

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

Дипломный проект реализован на компьютере с операционной системой Windosw 7. Windows 7 - операционная система семейства Windows NT, следующая за Windows Vista. В состав Windows 7 вошли как некоторые разработки, исключённые из Windows Vista, так и новшества в интерфейсе и встроенных программах. По состоянию на февраль 2011 года, доля Windows 7 среди используемых в мире операционных систем равна 32.2 %. Год назад, в феврале 2010 года доля была равна 13.0 %, возможно, в 2011 году перегонит самую широко используемую операционную систему в мире Windows XP.

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

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

Microsoft Visual Studio 2010 была выбрана из других средств по следующим причинам.

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

Определение влияния изменений в коде на тестирование. В результате анализа влияния изменений в коде на тестирование создается список тестов, рекомендуемых к выполнению после внесения изменений в код. Разработчики сразу знают, на какие тесты оказало влияние данное изменение в коде, и тестировщики точно знают, какие тесты должны быть выполнены для проверки данной сборки. Профилирование производительности приложения. Имеется возможность оценить производительность приложений, загруженность ЦП, потребление памяти, взаимодействие с базами данных, последовательности вызовов Jscript/Ajax и синхронизацию параллельных задач. Используется средство профилирования производительности в сочетании с нагрузочным тестированием. Это поможет выявить узкие места производительности при нагрузке и в стрессовых ситуациях. Выявление типовых ошибок в коде. Возможность без труда конфигурировать систему анализа кода набором правил, которому должны подчиняться определенные сценарии или области. Применение политики регистрации изменений с анализом кода позволит устранить типовые ошибки в коде приложения или базы данных до того, как он поступит в производственную эксплуатацию. Упрощение разработки через тестирование. Visual Studio формирует весь код заглушек, необходимый для выполнения модульного тестирования, позволяя разработчикам сосредоточиться на логике приложения.

Страница:


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

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

© 2000 — 2023, ООО «Олбест» Все права защищены