Вход

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

Рекомендуемая категория для самостоятельной подготовки:
Дипломная работа*
Код 353539
Дата создания 06 июля 2013
Страниц 50
Мы сможем обработать ваш заказ (!) 25 апреля в 12:00 [мск]
Файлы будут доступны для скачивания только после обработки заказа.
4 610руб.
КУПИТЬ

Содержание

Глава 2 Специальный раздел
2.1 Информационное обеспечение задачи
2.1.1 Входная и выходная информация
2.1.2 Организационное обеспечение задачи, бизнес-процессы
2.2 Информационная модель и её описание
2.3 Характеристика базы данных, er-диаграмма
2.4 Математическое обеспечение. Модель Уилсона
2.5 Технологическое обеспечение
2.5.1 Технология файл-сервер
2.5.2 Файл-серверная СУБД MS Access 2007
2.5.3 Технология клиент-сервер
2.5.4 Серверная СУБД MS SQL Server 2005
Глава 3 Программное обеспечение
3.1 Обоснования выбора
3.1.2 Среда разработки приложения
3.1.3 СУБД
3.1.3 Механизм доступа к данным
3.2 Программная реализация информационной модели
3.2.1 Даталогическая модель БД
3.2.2 Средства интеграции
3.3.4 Схема связи диалоговых форм с таблицами БД
3.3.5 Инструкции по эксплуатации ПО.
Список литературы
Приложение 1

Введение

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

Фрагмент работы для ознакомления

Но представим себе, что компьютер поставили в сеть, и сразу несколько человек захотели поработать с этими данными. Пока все пользователи только смотрят на эти данные, ничего страшного не происходит. Но как только какой-то пользователь (или сразу несколько пользователей) захочет изменить эти данные, начинаются проблемы. Пока все смотрят на некоторые данные, думая что они правильные, кто-то может их поменять. В результате то, что видит большинство пользователей оказывается, не соответствует тому, что есть на самом деле. Простой пример: на счету некой фирмы 10 миллионов рублей. Два служащих отдела закупок видят эту цифру и решают сделать закупку. Один подписывает контракт на 6 миллионов, другой - на 7 миллионов. Каждый думает, что он прав. Но как только в данные вносятся изменения, тут же обнаруживается, что оба контракта вместе невозможны! Но они уже подписаны! В них стоят штрафные санкции за срыв! Кто виноват? Поэтому при переходе к многопользовательскому доступу к данным приходится ставить механизм блокировки, который должен запрещать менять, а иногда и показывать значения, которые были кем-то прочитаны, но еще не обработаны. Такой механизм блокировки разумно делать единым для всех пользователей. Функцией такого механизма должна стать координация доступа. Кроме того, по многим причинам имеет смысл возложить на этот механизм и, собственно, все функции доступа к данным. Перечислим эти причины. Программа из нашего примера с функциональной точки зрения состоит из функций, обеспечивающих интерфейс с пользователем, и функций, работающих с данными на диске. Если несколько пользователей запускают эту программу одновременно, то для каждого пользователя в память загружаются и те, и другие функции. Но ведь функции доступа для всех пользователей одинаковы и перенос этих функций из программы, работающей с пользователем в программу-координатор доступа позволяет экономить ресурсы. Второе. Разработчики должны быть уверены, что программист, вследствие ошибки или злого умысла не обойдет наш механизм координации доступа к данным. То есть, нужно быть уверенным, что отслеживание прав доступа, поддержание целостности и т.д. работают всегда и работают правильно. Следовательно, детали реализации доступа к данным надо спрятать где-то поближе к данным. А что может быть ближе чем программа-координатор? И третье - при разработке новых прикладных программ, например для другой платформы или на другом языке, потребуется заново реализовывать и отлаживать функции доступа. А это чревато ошибками, повышает стоимость разработки и усложняет сопровождение всей системы в целом. Таким образом, вместо одной программы, содержащей в себе и интерфейс с пользователем, и доступ к данным, мы получили две общающиеся между собой программы - программу, работающую с пользователем (программа клиент) и программу, реализующую доступ к данным (программа сервер). То есть получили систему, построенную по архитектуре “клиент-сервер”. Обзор функций сервера базы данных. Программа сервер базы данных, является центральной с точки зрения доступа к данным. Именно поэтому большая часть функций, которая должна быть реализована в информационной системе, ложится на сервер базы данных. Перечислим теперь основные функции, которые должна выполнять программа сервер базы данных:Выполнять клиентские запросы по извлечению и модификации данных;Обеспечивать одновременный доступ к данным нескольких пользователей;Обеспечивать идентификацию пользователей и разграничение прав доступа разных пользователей к разным данным;Обеспечивать целостность и непротиворечивость данных в случае аппаратных и программных сбоев;Защищать данные от несакционированного доступа;Предоставлять дополнительные средства администрирования информационной системы. Рассмотрим эти требования более подробно. Выполнять клиентские запросы по извлечению и модификации данных. Вообще говоря, это основная функция сервера баз данных. Механизм реализации этой функции может быть скрыт от пользователя, то есть пользователь (а, точнее, работающая с ним программа-клиент) просто формулирует ЧТО ему нужно, а сервер базы данных исполняет этот запрос. В зависимости от того, какие функции предоставляет сервер базы данных, какие модели данных можно иметь на сервере, различают различные типы СУБД. Более подробно о том, какие бывают СУБД, будет говориться в отдельной главе.Предоставлять механизм одновременного доступа к данным нескольких пользователей. Как мы уже видели в рассмотренном выше примере, при многопользовательском доступе к данным возникают дополнительные задачи, которые должны быть решены. К таким задачам относится, например, блокировка данных. Блокировка означает, что часть данных в некоторые моменты времени должна быть закрыта для модификации, или даже для чтения другим пользователем. Другой аспект многопользовательского доступа - это распараллеливание доступа. То есть сервер баз данных должен уметь обрабатывать несколько запросов одновременно. Другими словами, если два пользователя почти одновременно обратились к серверу баз данных со своими запросами, то сервер не должен обрабатывать их строго по очереди (“вначале выполнить целиком один запрос, а только затем другой”). В противном случае, какой-то один очень сложный запрос может заставить ждать многих пользователей с простыми запросами. В этом аспекте сервер баз данных аналогичен многозадачной операционной системе. Обеспечивать идентификацию и разграничение прав доступа разных пользователей к разным данным. В реальных информационных системах должно существовать разграничение по правам доступа к данным. Какие-то пользователи могут и читать и модифицировать данные, какие-то пользователи могут только читать, а кто-то вообще может только вводить данные, а читать не имеет право. Таким образом, сервер баз данных должен, во-первых, уметь понимать команды, которые описывают такое разграничение прав, а, во-вторых, в процессе обслуживания запросов пользователя контролировать соблюдение этих разграничений.Обеспечивать целостность и непротиворечивость данных в случае аппаратных и программных сбоев. Несмотря на то, что за последнее время надежность аппаратной части существенно выросла, абсолютно надежной техники не бывает. В случае внезапного выключения и последующего включения компьютера, на котором работает сервер базы данных, информация не должна быть искажена или потеряна. Аналогично, если будет случайно выключен компьютер, на котором работает программа клиент, сервер базы данных должен определить этот факт и снять те блокировки, которые данная программа клиент установила, откатить незавершенные транзакции и, возможно, выполнить другие действия.Что касается программных сбоев, то здесь надо различать умышленные попытки исказить информацию, или случайные ошибки в программах, которые могут привести к таким же последствиям. Например, списывание денег с банковского счета должно приводить или к зачислению этой суммы на другой счет, или к появлению расходного документа. То есть нельзя просто так списать или начислить деньги на счет. Злоумышленник, получивший доступ к банковской системе, не должен иметь возможность просто так увеличить сумму на своем счете. Кроме того, при программировании банковской системы в нее может закрасться ошибка, которая может привести к рассогласованию данных. Поэтому сервер базы данных должен уметь проверять корректность производимых манипуляций с данными. Естественно, некоторые действия могут выглядеть совершенно правильно, но при этом таковыми не являться. Например, операционист может просто ошибиться с вводом номера счета и операция будет неправильной. Отследить такие ошибки очень трудно. Однако если некоторые зависимости можно описать формально, то будет очень полезно, если сервер базы данных будет за ними следить. Защищать данные от несакционированного доступа. В современных информационных системах все данные, или, по крайней мере, их значительная часть, является конфиденциальной. Помимо разграничения доступа для разных категорий пользователей, сервер базы данных должен обеспечивать защиту от попыток получить доступ к данным тем лицам, которые не являются пользователями информационной системы. Например, если данные хранятся в dbf-формате, то для того, что бы скопировать данные, достаточно вынуть жесткий диск из компьютера и потом на любом другом компьютере скопировать эти данные. В реальной информационной системе очень важно обеспечить технологичность, то есть информационная система позволять добавлять или удалять пользователей, настраиваться на новые ресурсы и т.д. Также должен быть предусмотрен механизм восстановления системы после такого форс-мажорного события, как, например, пожар или землетрясение. После таких стихийных бедствий зачастую аппаратура приходит в полную негодность, и чтобы не потерять накопленные данные, должна существовать процедура архивирования и восстановления данных. Также существует вероятность, что в процессе проектирования системы не были предусмотрены какие-то типы запросов, и при их реализации оказалось, что они работают слишком медленно. Следовательно, сервер базой данных должен уметь управлять ресурсами и производительностью.Вся деятельность данного типа относится к администрированию сервера базы данных. Качественный сервер базы данных должен предоставлять достаточный набор возможностей по администрированию, а именно, возможность настройки по производительности, средства анализа потока запросов и определения причин недостаточной скорости работы, средства созданий резервных копий (архивов) и восстановления с них и т.д.Функции программы-клиента базы данных. Как правило, программа клиент в системах управления базами данных отвечает за взаимодействие с пользователем. Взаимодействие может строиться на основе каких-либо экранных форм или диалога (как именно, в нашем рассмотрении не важно). На основе команд, введенных пользователем, программа клиент формирует запрос к серверу базы данных. После того, как запрос будет отработан и нужные данные найдены и переданы программе клиенту, программа клиент выдает их на экран. Могут существовать программы клиенты, которые не ведут никакого диалога с пользователем, а выполняют системные задачи. Например, принимают сообщения по почте, извлекают из них данные и заносят в базу данных. В любом случае, программа-клиент выполняет роль взаимодействия с внешним миром, но не занимается вопросами внутреннего представления и хранения данных. 2.5.4 Серверная СУБД MS SQL Server 2005Высокая производительность, является результатом реализации некоторых оптимизирующих механизмов, индивидуальных для каждой СУБД. Рассмотрим, благодаря чему достигается высокая производительность в MS SQL Server. Кроме возможностей индексации, параллельного и распределенного выполнения запросов, в состав SQL Server входят такие механизмы, как процессор запросов и производительный / интеллектуальный Ввод/Вывод (Big/Smart I/O). Рассмотрим их более подробно.Процессор запросов обеспечивает обработку команд на языке Transact-SQL - диалекта стандартного языка SQL применительно к SQL Server. Перечислим наиболее важные возможности этого механизма.Использование более одного индекса на таблицу. Отсутствие такого ограничения в версиях начиная с 7.0 позволяет оптимизатору пользоваться несколькими индексами, например, если условие поиска в запросе задано одновременно по нескольким полям. Над индексами могут осуществляться теоретико-множественные операции, например, объединение или пересечение индексов, что упрощает обработку предикатов фильтрации с операторами or или and, а также может применяться для динамического создания покрывающего индекса. Наряду с традиционным алгоритмом разрешения соединения таблиц (JOIN) - вложенным циклом (nested loop), оптимизатор может применять зачастую более эффективные стратегии - слияние (merge join) и хеширование (hash join). Слияние применяется, когда обе соединяемые таблицы отсортированы по ключу соединения. Хеширование применяется, в том случае, если индексы задействовать не удается. Наиболее эффективная стратегия для каждого запроса определяется оптимизатором самостоятельно в каждом конкретном случае. Процессор запросов обращается за данными к системе хранения (Storage Engine) через интерфейс OLE DB. Через этот же интерфейс он может обращаться за данными и к любым другим OLE DB-совместимым источникам данных, как локальным (находящимся на этом же компьютере), так и удаленным. Таким образом, стандартные операторы SELECT, INSERT, UPDATE и DELETE могут теперь в одном запросе соединять таблицы из разных источников данных. Этими источниками данных могут быть как Microsoft SQL Server, так и другие СУБД, а также нереляционные источники (например, Exchange Server, Index Server и т.д.). В зависимости от возможностей OLE DB-провайдера возможны три варианта обращения к удаленным данным - только чтение удаленных данных, их изменение и включение изменений в распределенную транзакцию. При этом изменение локальных данных возможно в рамках распределенного запроса в любом случае. Полнотекстовый поиск. SQL Server обеспечивает возможности полнотекстового поиска за счет интеграции с системой полнотекстового индексирования. Взаимодействие с этой системой осуществляется через OLE DB. Управление построением и поддержкой индексов осуществляется из главного средства администрирования SQL Server - SQL Enterprise Manager. Полнотекстовые индексы хранятся за пределами баз данных SQL Server - в специально отведенных файловых каталогах. Обновление индексов осуществляется вручную или по расписанию. Построение индекса возможно по символьным и текстовым полям таблиц. Под Big/Smart I/O понимается совокупность приемов, позволяющих обмениваться нужными данными с дисковой подсистемой как можно скорее.Опережающее чтение - процессор запросов подсказывает подсистеме хранения, как это делать. Сканирование строк в порядке физического размещения - при оценке затрат на выполнение запроса может быть сочтено более эффективным не использовать индексы, а просто читать данные в порядке их физического размещения и хешировать их для реляционного соединения, затем соединять и, наконец, сортировать небольшое число получившихся в результате строк. Неупорядоченное сканирование - когда данные расположены на нескольких дисководах, неупорядоченное сканирование их организуется параллельно и доступ происходит быстрее. Параллельные запросы - используют усовершенствованный механизм организации очереди, позволяющий поднять производительность даже в тех случаях, когда данные хранятся вместе. Управление кэшированием - переработано с целью повышения производительности при чтении большого количества данных. Масштабируемость означает возможность улучшение системных характеристик сервера путем увеличения доступных вычислительных ресурсов (количества или быстродействия процессоров, числа дисков). К улучшениям системных характеристик можно отнести, например:рост числа обслуживаемых пользователей с сохранением среднего времени отклика; ускорение обработки одного запроса; сохранение того же времени обработки запроса при увеличении объема участвующих в нем таблиц. SQL Server обеспечивает достаточно высокие уровни масштабируемости и доступности. Однако в данном случае здесь отсутствует масштабируемость сервера в чистом виде, поскольку рост производительности сервера зависит не только от аппаратного обеспечения, но и операционной среды, под управлением которой работает данная СУБД. В состав Microsoft SQL Server входит достаточно мощный язык работы с данными: Transact SQL, который является расширением стандартного SQL. Однако совместимость со стандартом ANSI/ISO SQL-92 не является полной, хотя он и рассматривается как предпочтительный диалект SQL. Transact-SQL поддерживает такие объекты БД, как хранимые процедуры, триггеры, представления, поддержка целостности и т.д. К сожалению, отсутствуют механизмы каскадного удаления и обновления данных по внешним ключам. Средства безопасности SQL Server может авторизовать пользователей двумя путями:на основе собственного списка пользователей; на основе базы пользователей Windows NT. Если организация использует Windows NT в качестве основной сетевой платформы, то применение авторизации Windows NT, безусловно, более эффективно. Во-первых, пользователи осуществляют однократный вход в сеть и получают доступ ко всем ресурсам, в том числе и к SQL Server. Во-вторых, управление доступом пользователей и групп становится более простым с точки зрения администратора. В-третьих, в этом случае задействуются механизмы секретности Windows NT (устаревание паролей и т.п.). При управлении правами пользователей в базах данных применяются роли. Пользователь может входить в одну или несколько ролей. Роль может включать в себя другие роли. Существует такой механизм, как "роль приложения" (application role), который определяет контекст прав любого пользователя данного приложения, независимо от его прав в базе данных. В каждой базе данных имеется несколько встроенных ролей, которые могут использоваться администратором. Имеются также встроенные роли на уровне сервера. Такие роли сервера и баз данных, как dbcreator, diskadmin и sysadmin, обеспечивают высокий уровень гибкости и безопасности. В комплект средств административного управления данной СУБД входит целый набор специальных мастеров и средств автоматической настройки параметров конфигурации. Как и любой другой продукт от Microsoft, SQL Server выглядит красиво и при первом знакомстве у начинающего администратора не возникает мысли, что с этой СУБД могут возникнуть какие-нибудь проблемы. К сожалению, проблемы возникают (как, впрочем, и при работе с другими серверами баз данных). Также MS SQL Server оснащен замечательными средствами тиражирования, позволяющими синхронизировать данные ПК с информацией БД и наоборот. Входящий в комплект поставки сервер OLAP дает возможность сохранять и анализировать все имеющиеся у пользователя данные. В принципе данная СУБД представляет собой современную полнофункциональную базу данных, которая идеально подходит для малых и средних организаций. Глава 3 Программное обеспечение3.1 Обоснования выбора 3.1.1 Архитектуры ЭИСОсновной режим работы ЭИС - это многопользовательское приложение, со множеством точек ввода входящей и получения исходящей информации. Т.е. необходима архитектура, которая обеспечила бы одновременный доступ большого количества пользователей к одним и тем же таблицам базы данных с максимальным параллелизмом (многопоточностью), но при этом нужно исключить редактирования пользователями одних и тех же данных. Ведь это может вызвать потерю данных пользователями. Например, разные пользователи открыли одновременно один и тот же заказ, при этом заказ будет находиться в базе данных, в том виде, в котором ее записывал последний пользователь. Этот последний пользователь поменял одну строку в заказе, а тот который записал таблицу первым, проделал большую работу и поменял 20 строк, понятно, что его труд при этом будет стерт последним пользователем. Такая проблематика разрешается блокировками. Архитектура также должна гарантировать согласованность данных при любых возможных сбоев, «повисание», неожиданное отключение питания. Было бы очень неприятно обнаружить, что общее количество во всех исполненных заказов какого-нибудь товара за период не соответствует разнице между остатком на начало периода и остатком на конец этого периода. Важным свойством выбранной архитектуры было бы встроенное средство обеспечения целостности данных.Все эти возможности, а также многое другое обеспечивает архитектура клиент-сервер, хотя по затратам она превышает архитектуру файл-сервер, но учитывая важность задачи для предприятия необходимо сделать именно такой выбор. К тому же, нужно учитывать возможность внедрения, разработанной ЭИС на других предприятиях с более сложным производственным процессом и большей номенклатурой выпускаемых изделий.3.1.

Список литературы

Список литературы
1.Гурвиц Г.А. Разработка реального приложения в среде клиент-сервер. Учебное пособие. - Хабаровск: ДВГУПС, 2005. - 204 с.
2.Гурвиц Г.А. Разработка реального приложения с использованием Visual FoxPro9. Учебное пособие. - Хабаровск: ДВГУПС, 2007. - 198 с.
3. Мамаев Е. В. «Microsoft SQL Server 2000», СПБ.: Питер 2001. - 1280 с.
4.Хабрейкен Д. “10 минут на урок Access 2002”, Вильямс, 2002. - 224 c.
5.Бекаревич Ю., Пушкина Н. “Самоучитель Microsoft Access 2002”, БХВ-Петербург, 2003. - 720 c.
Очень похожие работы
Пожалуйста, внимательно изучайте содержание и фрагменты работы. Деньги за приобретённые готовые работы по причине несоответствия данной работы вашим требованиям или её уникальности не возвращаются.
* Категория работы носит оценочный характер в соответствии с качественными и количественными параметрами предоставляемого материала. Данный материал ни целиком, ни любая из его частей не является готовым научным трудом, выпускной квалификационной работой, научным докладом или иной работой, предусмотренной государственной системой научной аттестации или необходимой для прохождения промежуточной или итоговой аттестации. Данный материал представляет собой субъективный результат обработки, структурирования и форматирования собранной его автором информации и предназначен, прежде всего, для использования в качестве источника для самостоятельной подготовки работы указанной тематики.
bmt: 0.00499
© Рефератбанк, 2002 - 2024