Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Корпоративные информационные системы

..pdf
Скачиваний:
9
Добавлен:
15.11.2022
Размер:
14.75 Mб
Скачать

условий. В качестве примера системы, соблюдающей выполнение этих условий, но основанной на файл-серверной архитектуре, можно привести популярный в прошлом «сервер баз данных» Informix SE.

В целом в файл-серверной архитектуре мы имеем «толстого» клиента и очень «тонкий» сервер в том смысле, что почти вся работа выполняется на стороне клиента, а от сервера требуется только достаточная емкость дисковой памяти (рис. 7.4).

Рис. 7.4. «Толстый» клиент и «тонкий» сервер

вфайл-серверной архитектуре

7.2.3.Клиент-серверные приложения

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

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

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

331

Рис. 7.5. Общее представление информационной системы в архитектуре «клиент-сервер»

Как видно, в клиент-серверной организации клиенты могут являться достаточно «тонкими», а сервер должен быть «толстым» настолько, чтобы быть в состоянии удовлетворить потребности всех клиентов (рис. 7.6).

Рис. 7.6. «Тонкий» клиент и «толстый» сервер

вклиент-серверной архитектуре

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

332

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

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

Рис. 7.7. «Потолстевший» клиент и «толстый» сервер в клиент-серверной архитектуре с поддержкой локального кэша на стороне клиента

Предварительные выводы. Архитектура «клиент-сервер» на первый взгляд кажется гораздо более дорогой, чем архитектура «файл-сервер». Требуется более мощная аппаратура (по крайней мере, для сервера) и существенно более развитые средства

333

управления базами данных. Однако это верно лишь отчасти. Громадным преимуществом клиент-серверной архитектуры является ее масштабируемость и вообще способность к развитию.

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

7.2.4. Intranet-приложения

Возникновение и внедрение в широкую практику высокоуровневых служб Всемирной сети сетей Internet (e-mail, ftp, telnet, WWW и т.д.) естественным образом повлияли на технологию создания корпоративных информационных систем, породив направление, известное теперь под названием Intranet. По сути дела, информационная intranet-система – это корпоративная система, в которой используются методы и средства Internet. Такая система может быть локальной, изолированной от остального мира Internet, или опираться на виртуальную корпоративную подсеть Internet. В последнем случае особенно важны средства защиты информации от несанкционированного доступа.

Хотя в общем случае в intranet-системе могут использоваться все возможные службы Internet, наибольшее внимание привлекает гипермедийная служба WWW (World Wide Web – Всемирная паутина). Видимо, для этого имеются две основные причины. Во-первых, с использованием языка гипермедийной разметки документов HTML можно сравнительно просто разработать удобную для использования информационную структуру, которая в дальнейшем будет обслуживаться одним из готовых Web-серверов. Во-вторых, наличие нескольких готовых к использованию клиентских частей– браузеров избавляет от необходимости создавать собственные интерфейсы с пользователями, предоставляя им удобные и развитые механизмы доступа к информации. В ряде случаев такая организация корпоративной информационной системы (рис. 7.8) оказывается достаточной для удовлетворенияпотребностейкомпании.

334

Рис. 7.8. Простая организация intranet-системы с использованием средств WWW

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

На самом деле все перечисленные трудности могут быть разрешены с использованием более развитых механизмов web-техно- логии. Эти механизмы непрерывно совершенствуются, что одновременно и хорошо и плохо. Хорошо, потому что появляются новые возможности. Плохо, потомучтоотсутствует стандартизация.

Что касается логики приложения, то при применении webтехнологии существует возможность ее реализации на стороне web-сервера. Для этого могут использоваться два подхода – CGI

(Common Gateway Interface) и API (Application Programming Interface). Оба подхода основываются на наличии в языке HTML специальных конструкций, информирующих клиента-браузера, что ему следует послать на web-сервер специальное сообщение,

335

Рис. 7.10. Доступ к базе данных в intranet-системе

при получении которого сервер должен вызвать соответствующую внешнюю процедуру, получить ее результаты и вернуть их клиенту в стандартном формате HTTP (рис. 7.9).

Рис. 7.9. Вызов внешней процедуры web-сервера

Подход CGI является более надежным (внешняя программа выполняется в отдельном адресном пространстве), но менее эффективным, чем подход API (в этом случае внешние процедуры компонуются совместно со стандартной частью Web-сервера).

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

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

336

На принципах использования внешних процедур основывается также возможность модификации документов, поддерживаемых Web-сервером, а также создание временных «виртуальных» HTML-страниц.

Даже начальное введение в Intranet было бы неполным, если не упомянуть про возможности язык Java. Java – это интерпретируемый объектно ориентированный язык программирования, созданный на основе языка Си++ с удалением из него таких «опасных» средств, как адресная арифметика. Мобильные коды (апплеты), полученные в результате компиляции Java-программы, могут быть привязаны к HTML-документу. В этом случае они поступают на сторону клиента вместе с документом и выполняются либо автоматически, либо по явному указанию. Апплет может быть, в частности, специализирован как шлюз к серверу баз данных (или к какому-либо другому серверу). При применении подобной техники доступа к базам данных схема организации Intranet-системы становится такой, как на рис. 7.11.

Рис. 7.11. Доступ к базе данных на стороне клиента intranet-системы

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

337

7.2.5. Хранилища данных, системы оперативной аналитической обработки данных и интеллектуальный анализ данных

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

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

В последние годы в мире оформился ряд новых концепций хранения и анализа корпоративных данных:

1) хранилища данных (ХД), или склады данных (Data

Warehouse);

2) оперативная аналитическая обработка (On-Line Analytical

Processing, OLAP);

3) интеллектуальный анализ данных – ИАД (Data Mining). Технологии OLAP тесно связаны с технологиями построения Data Warehouse и методами интеллектуальной обработки –

Data Mining. Поэтому наилучшим вариантом является комплексный подход к их внедрению.

7.2.5.1. Концепция хранилищ данных

Основная концепция – это предоставление конечным пользователям, особенно лицам, принимающим решения, лучшего доступа к корпоративным данным.

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

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

338

использовано при построении систем оперативного анализа и поддержки принятия решений. Основные преимущества данного подхода выражаются в следующем.

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

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

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

Несмотря на различия в подходах и реализациях, всем хранилищам данных свойственны следующие черты.

Предметная ориентированность. Информация в хра-

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

339

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

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

Неизменяемость. Попав в определенный «исторический слой» хранилища, данные уже никогда не будут изменены. Это отличает хранилище от оперативной БД, в которой данные все время меняются, и один и тот же запрос, выполненный дважды с интервалом в 10 минут, может дать разные результаты. Стабильность данных также облегчает их анализ.

Врезультате развития теории хранилищ данных появилась новая технология их построения, которая основана на понятии витрин (киосков) данных.

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

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

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

340