Информационная система малого предприятия «Инком»

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

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

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

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

На  рисунке 3.2 представлена логическая модель. На ней представлен общий вид потоков информации. На диаграмме имеются 5 сущностей:

• "Клиент"
• "Договор"
• "Отдел продаж"
• "Хранилище данных"
• "Отчётность"

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

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

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

 

 

Рис 3.2 Логическая модель

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

 

Рис. 3.3 Физическая модель

 

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

4. Спецификация  для создания информационной системы  отдела продаж коммерческого предприятия  «Инком »

1. Состав  и принципы информационного обеспечения

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

Объем инициируемых исходных данных составляет 10 Мб.

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

Принципы  построения информационного обеспечения  ИС:

• Интеграция. Система построена по модульному принципу на единой базе данных, имеет общесистемные справочники и классификаторы.
• Функциональная полнота. Система обеспечивает информационные потребности пользователей, обеспечивает поддержку процессов работы отдела розничных продаж.
• Целостность. Система поддерживает целостность данных за счет транзакционности ведения данных.
• Целенаправленность и разграничение доступа. Система включает автоматизированные рабочие места(АРМ) пользователей, в рамках АРМ обеспечивается разграничение доступа к данным и функциям системы, система поддерживает гибкие средства настройки АРМ и полномочий доступа.
• Открытость. Система поддерживает стандартные протоколы доступа к данным. Регламентация доступа к отдельным информационным ресурсам осуществляется с использованием встроенного механизма проверки полномочий.

ИС имеет  модульную структуру и построена  в двухуровневой архитектуре  клиент-сервер. Информационная система  поддерживает уровни представлений  и хранения данных.

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

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

2. Виды  и методы контроля в маршрутах  обработки данных

В системе ИС реализованы различные виды и методы контроля в маршрутах обработки данных, а именно:

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

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

3. Перечень  источников информации (входная и  выходная информация)

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

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

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

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

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

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

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

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

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

Информационный  обмен между сервером системы  и рабочими станциями осуществляется по локальной сети. На транспортном уровне для взаимодействия компонентов  системы используется стек протоколов TCP/IP.

Корректировка информации выполняется  пользователем через АРМ с  конкретными полномочиями доступа. При корректировке используются те же методы контроля, что и описанные  выше. В системе реализованы механизмы  хранения истории данных.

5. Описание построения информационной базы

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

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

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

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

Централизованная  база данных ИС создается автоматически  из образа базы (back-up) при установке системы с помощью программы-инсталлятора. В созданной базе данных изначально введен пользователь с правами всех сотрудников (логин admin, пароль admin). Дальнейшее заполнение ЦБД производится пользователями системы с соответствующих АРМ.

В СУБД Microsoft SQL Server (2005) Enterprise Edition создается специальный  пользователь, которому предоставляются  все права для работы с ЦБД. В дальнейшем все подключения  к СУБД со стороны производятся только посредством данного пользователя. Для защиты информации от несанкционированного доступа в системе предусмотрены  также:

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

6. Программные и аппаратные требования

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

Требования  к аппаратной части вытекают из требований к СУБД и пакету MSOffice и изложены в таблице 4.1.

Таблица 4.1 Требования к аппаратной части

Параметр	Системные требования
	Минимальные	Рекомендуемые
Операционная система	Windows XP, Windows Vista
Процессор	Intel Pentium III 750 Mhz	Intel Pentium IV 1500 Mhz
Оперативная память	512 Mb	1024 Mb
Видеопамять	32 Mb	64 Mb
Жесткий диск	20Gb	40Gb
ЛВС	100 Mbit

 

Для сетевой  работы информационной системы при  поддержки протокола TCP/IP. Конфигурация сервера зависит от количества пользователей и объема базы. При среднем объеме базы для выбора конфигурации сервера можно воспользоваться таблицей 4.2

Таблица 4.2 Аппаратные требования к серверу баз данных

Среднее количество активных пользователей (соединений)	Рекомендуемые характеристики
	Процессор	Память
10 - 50	1-2 Xeon 2400 - 2600 МГц	1024 Мб - 2048 Мб
50 - 100	2-4 Xeon 2600 - 2800 МГц	2048 Мб - 4096 Мб
100 - 200	4 Xeon 2800 - 3000 МГц	4096 Мб и выше

7. Выбор языка программирования

ИС разрабатывается в  среде php. Для ответа обоснования выбора было произведено сравнение РНР с другими языками программирования Web-приложений. Это его основные конкуренты — Perl, ASP.NET, ColdFusion и Java.

1. РНР и Perl

Язык Perl был создан программистом  Ларри Уоллом (Larry Wall) и расшифровывается как Practical Extraction and Report Language. Перевести  это можно как "язык для практического  извлечения данных и составления  отчетов. Perl является интерпретатором  и появился намного раньше, чем Web. С появлением интернета язык Perl оказался удобным инструментом для создания динамических Web-страниц. Большое распространение Perl получил потому, что был доступен на каждом Web-сервере, поскольку практически  все они работали под управлением UNIX, и альтернативой ему являлся  лишь более сложный язык С.

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