КИС - лекции. Термин корпорация происходит от латинского слова corporatio объединение. Корпорация

• Название: Термин корпорация происходит от латинского слова corporatio объединение. Корпорация
• Анкор: КИС - лекции.docx
• Дата: 27.01.2018
• Размер: 0.85 Mb.
• Имя файла: КИС - лекции.docx
• Тип: Документы; #14931
• страница: 8 из 10

Архитектура КИС

        Архитектуру КИС можно рассматривать с разных позиций.

        Функциональная архитектура КИС определяет состав функциональных подсистем и комплексов задач, обеспечивающих реализацию бизнес-процессов. (Бизнес-процесс – это совокупность взаимосвязанных операций по изготовлению готовой продукции или выполнению услуг на основе потребления ресурсов. В ходе управления бизнес-процессами все материальные, финансовые и информационные потоки рассматриваются во взаимодействии.) В соответствии с функциональной архитектурой формируются организационные компоненты КИС, в первую очередь, сеть коммуникаций, рабочие станции (АРМ) конечных пользователей и серверная подсистема сети, определяется их взаимодействие.

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

        В настоящее время сложились следующие типовые информационно-технологические структуры (архитектуры) КИС и соответствующие структуры корпоративных компьютерных сетей (ККС):

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



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

хранятся файлы БД. Вся обработка данных выполняется на рабочей станции

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



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



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

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

        Первоначально системы такого уровня базировались на классической двухуровневой клиент-серверной архитектуре (Two-tier architecture) (рис. 13).

Рис. 13.  Двухуровневая архитектура клиент-сервер

Данная клиент-серверная архитектура характеризуется наличием двух взаимодействующих самостоятельных модулей:  автоматизированного рабочего места (АРМа) и сервера БД, в качестве которого может выступать Microsoft SQL Server, Oracle, Sybase и др. Сервер БД отвечает за хранение, управление и целостность данных, а также обеспечивает возможность одновременного доступа нескольких пользователей. Клиентская часть представлена так называемым «толстым» клиентом, то есть приложением (АРМ), на котором сконцентрированы основные правила работы системы и расположен пользовательский интерфейс программы. При всей простоте построения такой архитектуры, она обладает множеством недостатков, наиболее существенные из которых – это высокие требования к сетевым ресурсам и пропускной способности сети компании, а также сложность обновления программного обеспечения из-за «размазанной» бизнес-логики между АРМом и сервером БД. Кроме того, при большом количестве АРМов возрастают требования к аппаратному обеспечению сервера БД, а это, как известно, самый дорогостоящий узел в любой информационной системе.

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

Рис. 14.  Трехуровневая архитектура клиент-сервер

Плюсы данной архитектуры (Three-tier architecture) очевидны. Благодаря концентрации бизнес-логики на сервере приложений, стало возможно подключать различные БД. Теперь сервер БД освобожден от задач распараллеливания работы между различными пользователями, что существенно снижает его аппаратные требования. Также снизились требования к клиентским машинам за счет выполнения ресурсоемких операций сервером приложений и решающих теперь только задачи визуализации данных. Именно поэтому такую схему построения информационных систем часто называют архитектурой «тонкого» клиента. 
        Но, тем не менее, узким местом, как и в двухуровневой клиент-серверной архитектуре, остаются повышенные требования к пропускной способности сети, что в свою очередь накладывает жесткие ограничения на использование таких систем в сетях с неустойчивой связью и малой пропускной способностью (Интернет, GPRS, мобильная связь).

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



Рис. 15. Распределенная архитектура ИС

        Еще два-три года назад реализация такой архитектуры системы для среднего и малого бизнеса была бы не возможна из-за отсутствия соответствующих недорогих аппаратных средств. Сегодня хороший ноутбук обладает мощностью, которой несколько лет назад обладал сервер крупной корпорации, и позволял рассчитывать множество важных и судьбоносных отчетов для всех сотрудников этой корпорации. 
        Более 95 % данных, используемых в управлении предприятием, могут быть размещены на одном ПК, обеспечив возможность его независимой работы. Поток исправлений и дополнений, создаваемый на этом компьютере, ничтожен по сравнению с объемом данных, используемых при этом. Поэтому, если хранить непрерывно используемые данные на самих компьютерах и организовать обмен между ними исправлениями и дополнениями к хранящимся данным, то суммарный передаваемый трафик резко снизиться. Это позволяет понизить требования к каналам связи между компьютерами и чаще использовать асинхронную связь, и благодаря этому создавать надежно функционирующие распределенные информационные системы, использующие для связи отдельных элементов неустойчивую связь типа Интернета, мобильную связь, коммерческие спутниковые каналы. А минимизация трафика между элементами сделает вполне доступной стоимость эксплуатации такой связи. Конечно, реализация такой системы не элементарна, и требует решения ряда проблем, одна из которых своевременная синхронизация данных.
        Каждый АРМ независим, содержит только ту информацию, с которой должен работать, а актуальность данных во всей системе обеспечивается благодаря непрерывному обмену сообщениями с другими АРМами. Обмен сообщениями между АРМами может быть реализован различными способами, от отправки данных по электронной почте до передачи данных по сетям.
        Еще одним из преимуществ такой архитектуры системы является обеспечение возможности персональной ответственности за сохран-ность данных. Так как данные, доступные на конкретном рабочем месте, находятся только на этом компьютере, при использовании средств шифрования и личных аппаратных ключей исключается доступ к данным посторонних, в том числе и IT администраторов. Такая архитектура системы также позволяет организовать распределенные вычисления между клиентскими машинами. Например, расчет какой-либо задачи, требующей больших вычислений, можно распределить между соседними АРМами благодаря тому, что они, как правило, обладают одной информацией в своих БД и, таким образом, добиться максимальной производительности системы.

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