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

Разработка информационной системы "Учет и контроль заказов фирмы "Окна Марио"

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

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

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

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

Страница:

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

Введение

фирма заказ база информационный

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

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

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

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

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

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

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

1. Технико-экономическое обоснование

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

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

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

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

На основании вышеизложенного поставлена цель разработать информационную систему "Учет и контроль заказов фирмы "Окна Марио".

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

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

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

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

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

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

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

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

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

2. Теоретическая часть

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

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

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

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

· база данных должна легко расширяться при реорганизации и расширении предметной области;

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

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

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

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

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

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

База данных предназначена для учета деятельности фирмы, а также для хранения данных о заказчиках и сотрудниках.

Функциональные требования к программным модулям:

· учет заказов фирмы;

· хранение персональных данных о сотрудниках;

· хранение персональных данных о заказчиках;

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

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

· формирование отчетов по заказам.

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

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

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

Данные о сотруднике:

· Фамилия, Имя, Отчество

· Серия паспорта

· Номер паспорта

· Рабочий телефон

· E-mail

· Должность

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

· Адрес проживания

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

Данные о заказчике:

· Наименование (ФИО)

· Адрес проживания

· Телефон 1

· Телефон 2

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

Данные об объекте:

· Адрес объекта

· Примечание

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

· Наименование услуги

· Стоимость за единицу

· Категория

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

· Наименование комплектации

· Стоимость за единицу

· Количество на складе

· Категория

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

Данные о поставщиках:

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

· Наименование товара

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

· Стоимость товара

· ИНН поставщика

· КПП поставщика

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

Данные о заказах фирмы:

· Номер заказа

· Дата заказа

· Срок выполнения

· Дата начала работы

· Общая сумма заказа

· Предоплата

· Вид оплаты

· Проплачен заказ

· Заказчик

· Объект

· Услуга

2.2 Постановка задачи

Задачи которая будет решать информационная система:

· ведение учета прихода товара от поставщика, отправка (выдача) товара и предоставление услуг по установке окон клиенту, управление доходами/расходами;

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

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

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

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

· учет движения средств по статьям доходов и расходов;

· возможность работы в сети, одновременный доступ к одной базе с разных компьютеров;

· группировка заказов в различные категории;

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

В фирме "Окна Марио" клиентам предоставляются следующие документы: счет-фактура и счет на оплату.

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

Рисунок 1. Бланк счёт-фактура.

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

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

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

· идентификацию пользователя;

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

· разграничение доступа пользователей на уровне задач и информационных массивов.

Защищённая часть системы должна использовать "слепые" пароли (при наборе пароля его символы не показываются на экране либо заменяются одним типом символов; количество символов не соответствует длине пароля).

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

Рисунок 2. Бланк счет на оплату.

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

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

2.3.1 Основы построения баз данных

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

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

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

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

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

Рисунок 3. Архитектура СУБД: однозвенная (слева); двухзвенная (в центре); трехзвенная (справа)

В зависимости от местоположения отдельных частей СУБД различают локальные и сетевые СУБД.

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

В файл-серверных СУБД все данные обычно размещаются в одном или нескольких каталогax достаточно мощной машины, специально выделенной для этих целей и постоянно подключенной к сети. Такой компьютер называется файл-сервером -- отсюда название СУБД. Безусловным достоинством СУБД этого типа является относительная простота ее создания и обслуживания -- фактически все сводится лишь к развертыванию локальной сети и установке на подключенных к ней компьютерах сетевых операционных систем. Используемая в дипломном проекте язык программирования C# "умеет" использовать сетевые средства самой популярной в мире ОС -- Windows для создания соответствующих клиентских мест, то есть специального программного обеспечения компьютером пользователей. Нетрудно заметить, что между локальными и файл-серверными вариантами СУБД нет особых различий, так как в них все части собственно СУБД (кроме данных) находятся на компьютере клиента. По архитектуре они обычно являются однозвенными, но в некоторых случаях могут использовать сервер приложений. Недостатком файл-серверных систем является значительная нагрузка на сеть.

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

Клиент-серверные (двухзвенные) системы значительно снижают нагрузку на сеть, так как клиент общается с данными через специализированного посредника -- сервер базы данных, который размещается на машине с данными. Сервер БД принимает запрос от клиента, отыскивает в данных нужную запись и передает ее клиенту. Таким образом, по сети передаются относительно короткий запрос и единственная нужная запись, даже если соответствующий файл с данными содержит сотни тысяч записей. Запрос к серверу формируется на специальном языке структурированных запросов (Structured Query Language, SQL), поэтому часто серверы БД называются SQL-серверами. Серверы БД представляют собой относительно сложные программы, разрабатываемые различными фирмами. К ним относятся, например, Microsoft SQL Server производства корпорации Microsoft, Sybase SQL Server корпорации Sybase, Oracle производства одноименной корпорации, DB2 корпорации IBM и т. д. SQL-сервером является также и сервер InterBase корпорации Borland. Клиент-серверные СУБД масштабируются до сотен и тысяч клиентских мест. Распределенные СУБД могут содержать несколько десятков и сотен серверов БД. Количество клиентских мест в них может достигать десятков и сотен тысяч. Обычно такие СУБД работают на предприятиях государственного масштаба, отдельные подразделения которых разнесены на значительной территории. К таковым, например, относятся подразделения Министерства обороны и Министерства внутренних дел. В распределенных СУБД некоторые серверы могут дублировать друг друга с целью достижения предельно малой вероятности отказов и сбоев, которые могут исказить жизненно важную информацию. Они используют собственные региональные средства связи. Интерес к распределенным СУБД возрос в связи со стремительным развитием Интернета. Опираясь на возможности Интернета, распределенные системы строят не только предприятия государственного масштаба, но и относительно небольшие коммерческие предприятия, обеспечивая своим сотрудникам работу с корпоративными данными на дому и в командировках.

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

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

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

2.3.2 SQL - язык доступа к реляционным базам данных

Аббревиатура SQL расшифровывается как structured query language, что в переводе с английского означает "язык структурированных запросов". SQL не является полноценным языком программирования; он представляет собой всего лишь подъязык данных. В нем имеются операторы только для создания и обработки баз данных. Операторы SQL можно также использовать в хранимых процедурах и триггерах, и их можно вводить в интерактивном режиме в командной оболочке СУБД.

Язык SQL был разработан фирмой IBM в конце 1970-х годов и был принят Американским национальным институтом стандартов (ANSI) в качестве национального стандарта США в 1992 году. На этом стандарте, называемом также SQL-92, базируется версия языка. Более поздняя версия стандарта, SQL3, включает в себя ряд концепций, заимствованных из объектно-ориентированного программирования. Эта последняя версия не привлекла пристального внимания со стороны фирм-разработчиков коммерческих СУБД и на настоящий момент не представляет важности с точки зрения практической работы с базами данных

Стандарт SQL-92 обширен и всеобъемлющ. Ни одна из распространенные коммерческих СУБД, таких как DB2, Oracle или SQL Server, не реализует его полном объеме. Язык SQL ориентирован на текст. Он был разработан задолго до появления графических интерфейсов пользователя, так что для работы с ним требуется лишь текстовый редактор. Разумеется, сегодня в SQL Server, Oracle, DB2 и других СУБД имеются графические средства для выполнения многих из тех задач которые ранее могли быть выполнены только с помощью SQL. Не все из того, что позволяет делать SQL, можно осуществить с помощью графических средств; более того, в ряде случаен, па пример, для динамической генерации операторов SQL в программном коде, SQI. использовать необходимо.

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

2.3.3 Выбор СУБД

Перед администратором БД, руководителем предприятия и обычным пользователем проблема выбора СУБД возникает чаще всего перед ее приобретением и при переходе на новые аппаратно-программные средства.

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

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

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

Процедуру выбора СУБД удобно проводить в три этапа. Сначала на качественном уровне оценить предлагаемые программные продукты на предмет пригодности, сузив область выбора. Затем оценить технические характеристики отобранных систем более детально. И наконец, оценить производительность оставшихся продуктов для принятия окончательного решения.

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

1. Вид программного продукта.

2. Категории пользователей.

3. Удобство и простота использования.

4. Модель представления данных.

5. Качество средин разработки.

6. Качество средств защиты и контроля корректности балы данных.

7. Качество коммуникационных средств.

8. Фирма-разработчик.

9. Стоимость.

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

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

В дипломном проекте используется мощная и надежная СУБД Microsoft SQL Server Management Studio 2008. Microsoft SQL Server Management Studio представляет собой СУБД, обеспечивающую создание информационных систем с архитектурой "клиент-сервер". SQL Server удовлетворяет требованиям, предъявляемым к системам распределенной обработки информации. Эта СУБД поддерживает: тиражирование данных, параллельную обработку, создание и обработку больших баз данных на недорогих аппаратных платформах, отличается простотой управления и использования.

Преимущества СУБД Microsoft SQL Server Management Studio 2008:

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

· высокая производительность;

· надежность работы;

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

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

Средства разработки программ работы с БД могут использоваться для создания разновидностей следующих программ:

* клиентских программ;

* серверов БД и их отдельных компонентов;

* пользовательских приложений.

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

К средствам разработки пользовательских приложений относятся системы программирования, разнообразные библиотеки программ для различных языков программирования, а также пакеты автоматизации разработок (в том числе систем типа клиент-сервер). В числе наиболее распространенных можно назвать следующие инструментальные системы. Delphi и Power Builder (Borland), Visual Basic (Microsoft), Visual C# (Microsoft), SILVERRUN (Computer Advisers Inc.), S-Designer (SDP и Powersoft) и ERwin (LogicWorks).

Для разработки информационной системы "Окна Марио" выберем систему программирования Microsoft Visual Studio 2012, язык программирования C# - инструмент быстрой разработки клиент-серверных приложений.

Разработка клиентских приложений в языке программирования Microsoft Visual C# для БД реализована чрезвычайно гибко и грамотно (содержит развитые средства взаимодействия с БД, с помощью которых можно осуществлять доступ к практически любым реляционным базам данных). Любая прикладная задача ложится на него легко. Время показало правильность многих заложенных в инструмент решений.

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

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

· Создание приложений для Windows 7 - Visual Studio 2012 включает встроенные инструменты разработки для Windows 7, в том числе такие компоненты пользовательского интерфейса, как мультисенсорный ввод и лента, которые составляют основу передовой технологии Windows 7.

· Простое создание приложений на базе RIA и WPF - Новая функция привязки данных перетаскиванием (в Windows Presentation Foundation) и конструкторы Silverlight упрощают и ускоряют построение приложений для специалистов по проектированию и разработке.

· Настройка Visual Studio соответственно собственному стилю Основное улучшение IDE - включение поддержки для множества мониторов и повышение четкости текста - делает привычную среду еще более продуктивной.

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

· Меньше времени на отладку Встроенная иерархия вызовов позволяет быстро прослеживать поток выполнения программы без вызова отладчика. Также для упрощения отладки можно использовать метки для точек останова.

· Интегрированная система контроля версий, отслеживание дефектов и автоматизация сборки Visual Studio 2012 с MSDN включает Team Foundation Server 2010, который является идеальной системой контроля версий, отслеживания дефектов и автоматизации сборки для пользователей Visual Studio. Базовая установка Team Foundation Server превосходно подходит для использования на настольных компьютерах и для начинающих пользователей, до этого работавших с Microsoft Visual SourceSafe.

2.4 Проектирование информационной системы

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

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

2.4.1 Выделение сущностей

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

· Сотрудники

· Заказчики

· Объекты

· Услуги

· Комплектации

· Поставщики

· Заказы

2.4.2 Анализ связей между объектами предметной области

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

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

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

Связь между сущностями "заказ" и "заказчик" характеризуется наличием у заказа заказчика (только одного). Хотя один заказчик может оформить несколько заказов.

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

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

Связь между сущностями "заказ" и "объект" характеризуется объектом (только одним), на который нацелена услуга заказа. Хотя один и тот же объект может быть в нескольких заказах.

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

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

Правило 1: Каждое поле любой таблицы должно быть уникальным.

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

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

Правило 4: Должна иметься возможность изменять значения любого поля (не входящего в первичный ключ), и это не должно повлечь за собой изменение другого поля [8].

Рисунок 4. Информационно-логическая модель

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

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

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

2.4.3 Ограничения, накладываемы на данные

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

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

Ограничения целостности могут относиться к разным объектам БД: атрибутам (полям), записям, отношениям, связям между ними и т. п.

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

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

· Выбор типа поля Date в формате ДД.ММ.ГГ позволит пользователю ввести только шесть чисел. При этом первая пара цифр не сможет превысить в лучшем случае значения 31, а вторая - 12.

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

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

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

· Проверка на уникальность значения какого-то поля позволяет избежать записей-дубликатов. Вряд ли будет удобно в справочнике клиентов иметь несколько записей для одного и того же лица.

3. Экспериментальная часть

Основной целью построения автоматизированной информационной системы фирмы "Окна Марио" является хранение информации о деятельности фирмы (ее заказах), о ее сотрудниках и заказчиках.

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

3.1 Разработка программных модулей

3.1.1 Разработка таблиц

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

· "один-ко-многим",

· "один-к-одному",

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

Когда одна запись в таблице А может быть связана с 0, 1 или множеством записей в таблице B, вы имеете дело со связью один-ко-мноигм. В реляционной модели данных связь один-ко-многим использует две таблицы (Рисунок 5).

Рисунок 5 Связь один-ко-многим

Схематическое представление связи один-ко-многим. Запись в таблице имеет 0, 1 или множество ассоциированных ей записей в таблице B.

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

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

Связь многие-ко-многим создается с помощью трех таблиц. Две таблицы - "источника" и одна соединительная таблица. Первичный ключ соединительной таблицы A_B - составной. Она состоит из двух полей, двух внешних ключей, которые ссылаются на первичные ключи таблиц A и B (Рисунок 6).

Рисунок 6. Связь многи ко многим

Все первичные ключи должны быть уникальными. Это подразумевает и то, что комбинация полей A и B должна быть уникальной в таблице A_B.

В нашем случае связь многие-ко-многим это

· Сотрудник-заказ (несколько сотрудников могут участвовать в одно заказе, так и один сотрудник может обслуживать несколько заказов)

· Заказ-услуга (в заказе может быть несколько услуг, так и одна и та же услуга может быть в нескольких заказах)

· Заказ-комплектация (в заказе может быть несколько Комплектаций, так и одна и та же комплектация может быть в нескольких заказах)

Рассмотрим разработанные таблицы:

Таблица Заказы (Рисунок 7)

Рисунок 7. Таблица заказы

Поля таблицы Заказы:

· Id заказа

· Id объекта установки

· Id Заказчика

· Номер заказа

· Дата заказа

· Срок выполнения

· Вид оплаты

· Предоплата

· Заказ проплачен

· Дата начала работы

Таблица Сотрудники (Рисунок 8)

Рисунок 8. Таблица сотрудники

Поля таблицы Сотрудники:

· Фамилия

· Имя

· Отчество

· Серия паспорта

· Номер паспорта

· Телефон

· Эл почта

· Должность

· День рождение

· Адрес

Таблица Заказы - Сотрудники (Рисунок 9)

Рисунок 9. Таблицы Заказы-Сотрудники

Поля таблицы Заказы-Сотрудники

· Id сотрудник

· Id Заказа

· Человеко-часы

Таблица Объекты (Рисунок 10)

Рисунок 10. Таблица Объекты

Поля таблицы объекты:

· Id объекта

· Адрес

· Примечание (вход с торца)

Таблица Услуги (Рисунок 11)

Рисунок 11. Таблица Услуги

Поля таблицы Услуги:

· Id Услуги

· Вид услуги

· Стоимость единицы

Таблица Заказы-Услуги (Рисунок 12)

Рисунок 12. Таблица Заказы-Услуги

Поля таблицы Заказы-Услуги

· Id Услуги

· Id Заказа

· Количество услуг

Таблица Комплектация (Рисунок 13)

Рисунок 13. Таблица Комплектация

Поля таблицы Комплектация:

· Id

· Id Поставщика

· Вид Комплектации

· Цена с наценкой

· Цена поставщика

Таблица Заказы-Комплектация (Рисунок 14)

Рисунок 14. Таблица Заказы-Комплектация

Поля таблицы Заказы-Комплектация:

· Id Заказа

· Id Комплектации

· Количество

Таблица Поставщики (Рисунок 15)

Рисунок 15. Таблица Поставщики

Поля таблицы Поставщики:

· Id

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

· Адрес

· ИНН

· КПП

Таблица Заказчики (Рисунок 16)

Рисунок 16. Таблица Заказчики

Поля таблицы Заказчики:

· Id

· Фамилия

· Имя

· Отчество

· Адрес проживания

· Телефон1

· Телефон2

Схема данных разработанная на основе созданных таблиц в MS SQL Server Managment Studio изображена на рис. 17.

Рисунок 17 . Схема данных

3.1.2 Разработка форм

Для осуществления загрузки разработанного приложения пользователь запускает программу "Окна "Марио". Для просмотра и редактирования таблиц базы данных созданы формы с одноимёнными названиями.

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

· Добавление новых записей в таблицы (под учетной записью администратора);

· Добавление новых записей в таблицу "Order" (для всех пользователей);

· Редактирование записей в таблицах (под учетной записью администратора);

· Удаление записей в таблицах (под учетной записью администратора).

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

В дипломном проекте используются 15 форм:

1. AuthorizationForm - форма, на которой осуществляется аутентификация пользователя и выбор БД. В случае успешного входа загружается главная форма MainForm;

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

3. AddConfigurationForm - форма используется для добавления данных о комплектации в заказ;

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

5. AddCustomerForm - форма, предназначенная для добавления заказчиков в заказ;

6. AddObjectForm - форма, предназначенная для добавления объектов в заказ;

7. SelectEmployeeForm - форма для выбора сотрудника, исполняющего заказ;

8. InsertEmployeeForm - форма добавления, удаления и изменения сотрудника в БД;

9. InsertServiceForm - форма добавления, удаления и изменения услуги в БД;

10. InsertConfigurationForm - форма добавления, удаления и изменения комплектации в БД;

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

12. FindOrderForm - форма, необходимая для поиска заказа в БД по различным параметрам и условиям поиска;

13. SplashScreenForm - форма-заставка;

14. OrderPropertiesForm - форма, позволяющая выводить параметры заказа, изменять их (только под учетной записью администратора) и формировать документы счет-фактура и счет на оплату в формате документа Excel;

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

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

Рисунок 18. Схема передачи данных от форм к БД и наоборот

3.1.3 Разработка SQL запросов

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

Для добавления, изменения, удаления записей в таблицы БД разработаны SQL запросы, которые объединены в класс SqlOperation. Их можно разбить на группы:

· Запросы для поиска данных, Например запрос поиска заказа по номеру договора:

SELECT o.IdOrder

,o.[OrderNumber]

,o.[OrderDate]

,o.[TermPerfomance]

,o.[PaymentKind]

,o.[AdvancePayment]

,o.[TotalSum]

,o.[OrderPaid]

,o.[BeginWorkDate]

,c.Family

,c.Name

,c.Patronomic

,c.AddressResidence

,c.Phone1

,c.Phone2

,obj.[Address]

,obj.Note

FROM [Orders] o INNER JOIN Customer c ON (o.IdCustomer = c.Id)

INNER JOIN [Objects] obj ON (obj.Id = o.IdObjectInstallation)

WHERE o.OrderNumber = {0}

· Запросы для добавления данных, Например запрос добавления заказчика:

INSERT INTO Customer

VALUES ({0}, N'{1}',N'{2}',N'{3}','{4}','{5}','{6}')

· Запросы для получения данных, Например запрос для получения списка услуг:

SELECT [Id]

,[ServicesKind]

,[Cost]

,[Category]

FROM [MariosWindows].[dbo].[Services]

ORDER BY Category

3.1.4 Разработка отчетов

Для отчетов Счет на оплату и Счет-фактура были разработаны соответствующие шаблоны в формате документа Excel (Рисунки 19,20). Посредством находящемся в свободном доступе в сети Internet методов класса формирования и считывания Excel-документов ExcelReader эти шаблоны заполняются считанными из базы параметрами.

Рисунок 19. Шаблон отчета счет на оплату

Рисунок 20. Шаблон отчета счет-фактура

3.2 Тестирование и отладка разработанной системы

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

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

При тестировании проверялись такие функции:

· ввод новой информации о сотрудниках;

· поиск заказа по номеру договора

· просмотр и/или изменение данных об услугах

· получение отчетной документации и возможность ее дальнейшей обработки и т.д.

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

Рисунок 21. Ошибка подключения к БД.

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

Рисунок 22. Ошибка ввода пароля или логина.

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

Рисунок 23. Ошибочный ввод данных.

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

Рисунок 24. Повторное добавление записи

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

4. Документирование разработанной системы

Для запуска программы необходимо запустить приложение "Окна Марио.exe". После запуска приложение загрузится заставка (Рисунок 25).

Рисунок 25. Заставка приложения.

Страница:


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

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

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