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

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

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

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

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

• сложность разработки систем на основе многоуровневой архитектуры, т.к  очень сложно «состыковать» различные модули, особенно если они написаны разными группами. А изменение в одном модуле, как правило, вызывает лавинообразные изменения в остальных, и с этой точки зрения даже простую систему, основанную на многоуровневой архитектуре, будет сложнее выполнить в 2 раза;
• высокие требования к производительности серверов приложений и сервера базы данных, а, значит, и высокая стоимость серверного оборудования;
• высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений;
• высокая сложность администрирования.

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

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

Рисунок 12 - Архитектура "клиент-сервер"

2.2 Структура информационной системы,  состав функциональных и обеспечивающих  подсистем

 

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

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

• информационная;
• техническая;
• программная;
• математическая;
• лингвистическая.

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

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

• функциональную структуру;
• информационное обеспечение;
• математическое (алгоритмическое и программное) обеспечение;
• техническое обеспечение;
• организационное обеспечение,

а на стадии разработки ИС дополнительные обеспечения:

• правовое;
• лингвистическое;
• технологическое;
• методологическое;
• интерфейсы с внешними ИС.

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

Математическое обеспечение  состоит из алгоритмического и программного.

Организационное обеспечение  – это совокупность средств и  методов организации производства и управления ими в условиях внедрения  ИС.

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

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

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

Рисунок 13 - Состав функциональных и обеспечивающих подсистем

 

2.3 Техническое обеспечение ИС

 

В комплекс технических средств  должны входить следующие элементы:

• рабочие станции;
• источники бесперебойного питания;
• средства для построения ЛВС;
• сервер БД;
• принтер.

Требования к серверу:

• память 8 Гб;
• процессор 2.2 ГГц Intel Xeon 5500 минимум;
• скорость диска SATA 8 Гбит/с;
• сетевой адаптер 10 Гбит/с;
• операционная система Windows Server 2008.

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

• процессор 2 Ггц;
• память 2 Гб;
• жесткий диск не менее 500;
• операционная система Windows 7;
• сетевой адаптер 100 Мбит/с.

Технические средства ИС описаны  с учетом требований к функционированию прикладного пpогpаммного комплекса. Технические средства должны обеспечить:

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

На рисунке 2.3 представлена топология локальной  вычислительной сети (ЛВС) для ОАО  «Заказчик».

На рассматриваемом  рисунке видно, что через коммутатор к серверу БД и файловому серверу  подключены 5 рабочих станций. Топология сети – звезда.

Рисунок 14 - Логическая схема сети ОАО "Заказчик"

3. Информационное обеспечение ИС

3.1 Описание концептуальной модели  информационной базы

Для хранения данных в информационной системе  используется реляционная база данных под управлением СУБД Oracle 11g. Концептуальная схема структуры информационной базы приведена на рисунке 15.

У сущности «Заказ»  есть следующие атрибуты: Номер заказа, Дата поступления, Наименование заказа, Количество комплектов, Срок выполнения, Id заказчика, Id плана.

Сущность  «Детали» имеет следующие атрибуты: Id детали, Длина, Ширина, Наименование, Id заказа, Id материала, Количество.

Сущность  «Материал» имеет атрибуты: Наименование, Id материала, Цена за лист, Длина, Ширина.

Сущность  «Счет» имеет атрибуты: Id счета, Сумма к оплате, Id заказа.

Сущность  «Заказчик» имеет атрибуты: Id заказчика, ФИО, Адрес, Телефон.

Сущность  «Фурнитура» имеет атрибуты: Id фурнитуры, Наименование, Количество, Стоимость, Id заказа.

Сущность  «План раскроя» имеет атрибуты: Id плана, Файл-изображение (переменная строкового типа, в которой будет храниться ссылка на изображение с планом раскроя), Наименование.

Сущность  «Акт о выполненных работах» имеет  атрибуты: Id плана, Дата окончания работ, ФИО исполнителя, Id заказа.

Между объектами  Заказ и Детали максимальная мощность связи 1:N, т.е. одному заказу может принадлежать множество деталей.

Между объектами Детали и Материал максимальная мощность связи 1:N, т.е. на листе материала может быть множество деталей.

Между объектами  Акт о выполненных работах  и Заказ максимальная мощность связи 1:1, т.е. одному заказу может соответствовать 1 акт о выполнении работ.

Между объектами  Заказ и Счет максимальная мощность связи 1:1, т.е. заказу может соответствовать  только 1 счет.

Между объектами  Заказ и План раскроя максимальная мощность связи 1:N, т.е. в заказе может быть создано несколько планов раскроя.

Между объектами  Заказ и Заказчик максимальная мощность связи 1:N, т.е. у одного заказчика может быть множество заказов.

Между объектами  Детали и Материал максимальная мощность связи 1:N, т.е. на листе материала может быть множество деталей.

Между объектами  Фурнитура и Заказ максимальная мощность 1:N, т.е. одному заказу может соответствовать множество единиц фурнитуры.

 

Рисунок 15 - Концептуальная схема базы данных

 

3.2 Описание логической структуры  информационной базы

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

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

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

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

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