Архитектура информационных систем

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

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

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

Что касается логики приложения, то при применении Web-технологии существует возможность ее реализации на стороне Web-сервера. Для этого могут использоваться два подхода - CGI (Common Gateway Interface) и API (Application Programming Interface). Оба подхода основываются на наличии в языке HTML специальных конструкций, информирующих клиента-браузера, что ему следует послать Web-серверу специальное сообщение, при получении которого сервер должен вызвать соответствующую внешнюю процедуру, получить ее результаты и вернуть их клиенту в стандартном формате HTTP (рисунок 2.7).

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

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

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

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

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

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

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

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

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

2.4. Склады данных (DataWarehousing) и системы оперативной  аналитической обработки  данных

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

Прежде чем  перейти к обсуждению технических  аспектов, коротко обсудим проблемы терминологии. Поскольку термины, связанные  со складами данных не так давно появились и на английском языке, и смысл их постоянно уточняется, трудно найти правильные русскоязычные эквиваленты. На сегодняшний день "datawarehouse" разными авторами переводится на русский язык как "хранилище данных", "информационное хранилище", "склад данных". Поскольку термин "хранилище" явно перегружен (он соответствует и английским терминам "storage" и "repository"), в этом курсе мы будем использовать термин "склад данных". Еще хуже дела обстоят с термином "data mart". В четвертом номере журнала "СУБД" за 1996 г. в напечатанных подряд двух статьях авторы переводят этот термин как "витрина данных" и "секция данных" соответственно. Однако в Оксфордском толковом словаре единственным подходящем по смыслу толкованием смысла слова "mart" является "market place". Чтобы не умножать число требуемых сущностей мы будем использовать термин "рынок данных" (обсуждение этого понятия отложим до пятой части курса). Конечно, постепенно терминология будет согласована, но это произойдет только тогда, когда склады данных будут активно использоваться в России.

В этом разделе  мы не будем рассматривать возможные  технологические приемы реализации складов данных, а обсудим соответствующие  вопросы на концептуальном уровне. Начнем с того, что главным образом различает оперативные и аналитические информационные приложения с точки зрения обеспечения требуемых данных. Замечание: речь идет о так называемых OLAP-системах (от On-Line Analitical Processing), т.е. аналитических системах, помогающих принимать бизнес-решения за счет динамически производимых анализа, моделирования и/или прогнозирования данных.

1. Основным источником информации, поступающей в оперативную базу данных является деятельность корпорации. Для проведения анализа данных требуется привлечение внешних источников информации (например, статистических отчетов). Тем самым, склад данных должен включать как внутренние корпоративные данные, так и внешние данные, характеризующие рынок в целом.
2. Если для оперативной обработки, как правило, требуются свежие данные (обычно в оперативных базах данных информация сохраняется не более нескольких месяцев), то в складе данных нужно поддерживать хранение информации о деятельности корпорации и состоянии рынка на протяжении нескольких лет (для проведения достоверных анализа и прогнозирования). Как следствие, аналитические базы данных имеют объем как минимум на порядок больший, чем оперативные.
3. Во многих достаточно крупных корпорациях одновременно существуют несколько оперативных информационных систем с собственными базами данных (как мы уже отмечали в этом курсе, это не очень хорошо, но часто неизбежно по историческим причинам). Оперативные базы данных могут содержать семантически эквивалентную информацию, представленную в разных форматах, с разным указанием времени ее поступления, иногда даже противоречивую (например, из-за ошибок ввода данных). Склад данных корпорации должен содержать единообразно представленные данные из всех оперативных баз данных. Эта информация должна максимально полно соответствовать текущему содержанию оперативных баз данных и быть согласованной. Отсюда следует необходимость наличия компонента склада данных, извлекающего информацию из оперативных баз данных и "очищающего" эту информацию.
4. Оперативные информационные системы проектируются и разрабатываются в расчете на решение конкретных задач. Обычно набор запросов к оперативной базе данных становится известным уже на этапе проектирования системы. Информация из базы данных выбирается часто и небольшими порциями. Поэтому при проектировании оперативной базы данных можно и нужно учитывать этот заранее известный набор запросов (с известными оговорками в связи с возможными переделками информационной системы). Набор запросов к аналитической базе данных предсказать невозможно. Склады данных для того и существуют, чтобы отвечать на неожиданные (ad hoc) запросы аналитиков. Можно рассчитывать только на то, что запросы будут поступать не слишком часто и затрагивать большие объемы информации. Размеры аналитической базы данных стимулируют использование запросов с агрегатами (сумма, минимальное, максимальное, среднее значение и т.д.).
5. Оперативные базы данных по своей природе являются сильно изменчивыми. Это учитывается в используемых СУБД. В частности, распространенным механизмом индексации являются B-деревья, модификация которых выполняется достаточно быстро, а строки в таблицах хранятся неупорядоченно. Аналитические базы данных меняются только тогда, когда в них загружается оперативная или внешняя информация. В результате оказывается разумным использовать другие, более быстрые при выполнении операций массовой выборки методы индексации, поддерживать упорядоченность информационных массивов, сохранять заранее вычисленные значения агрегатных функций и т.д.
6. Если для оперативных информационных систем обычно хватает защиты информации на уровне таблиц (по правилам SQL-ориентированных баз данных), то информация аналитических баз данных настолько критична для корпорации, что для ее защиты требуются более тонкие приемы (например, при использовании реляционных баз данных установка индивидуальных привилегий доступа для индивидуальных строк и/или столбцов таблицы).

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

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

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

1. Многомерное концептуальное представление данных. Это требование возникает по той причине, что бизнес-пользователь естественно представляет историю и деятельность своей корпорации многомерными (например, одно измерение - время, другое - заказчики, третье - производимая продукция и т.д.). OLAP-модели должны поддерживать это представление и, естественно, оно должно хотя бы в какой-то мере опираться на возможности аналитической базы данных.
2. Прозрачность. Для бизнес-пользователя не должно быть существенно, где конкретно расположены средства динамического анализа данных. При разработке OLAP-систем следует придерживаться подхода открытых систем, что позволит размещать средства анализа в любом узле корпоративной сети.
3. Доступность. Логическая схема, с которой работает OLAP-система, должна отображаться в схемы разнородных физических хранилищ данных. При доступе к данным должно поддерживаться их единое и согласованное представление.
4. Согласованная эффективность производства отчетов. Эта эффективность не должна деградировать при увеличении числа измерений.
5. Архитектура "клиент-сервер". Серверный компонент OLAP-системы должен быть достаточно развитым, чтобы разнообразные клиенты могли подключаться к нему с минимальными усилиями и затратами на дополнительное "интегрирующее" программирование.
6. Родовая многомерность. Структурные и операционные возможности работы с каждым измерением данных должны быть эквивалентны. Для всех измерений должна существовать только одна логическая структура. Любая функция, применимая к одному измерению, должна быть применима к любому другому измерению.
7. Управление динамическими разреженными матрицами. Сервер OLAP-системы должен уметь эффективно хранить и обрабатывать разреженные матрицы. Физические методы доступа должны быть разнообразны, включая прямое вычисление, B-деревья, хэширование или комбинации этих методов.
8. Поддержка многопользовательского режима. OLAP-система должна поддерживать многопользовательский доступ к данным (по выборке и изменению), обеспечивая целостность и безопасность данных.
9. Неограниченные операции между измерениями. При выполнении многомерного анализа данных все измерения создаются и обрабатываются единообразно. OLAP-система должна быть в состоянии выполнять соответствующие вычисления между измерениями.
10. Интуитивное манипулирование данными. Манипуляции, подобные смене пути анализа или уровня детализации, должны выполняться с помощью прямого воздействия на элементы OLAP-модели без потребности использовать меню или другие вспомогательные средства.
11. Гибкая система отчетов. Бизнес-пользователь должен иметь возможность манипулировать данными, анализировать и/или синтезировать, а также просматривать их таким образом, как ему захочется.
12. Неограниченное число измерений и уровней агрегации. OLAP-сервер должен поддерживать не менее 15 измерений для каждой аналитической модели. Для каждого измерения должно допускаться неограниченное число определяемых пользователями агрегатов.

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

2.5. Интегрированные  распределенные приложения

Нет никаких  проблем, если с самого начала информационное приложение проектируется и разрабатывается  в духе подхода открытых систем: все компоненты являются мобильными и интероперабельными, общее функционирование системы не зависит от конкретного местоположения компонентов, система обладает хорошими возможностями сопровождаемости и развития. К сожалению, на практике этот идеал является трудно достижимым. По разным причинам (мы перечислим некоторые из них ниже) возникают потребности в интеграции независимо и по-разному организованных информационно-вычислительных ресурсов. Видимо, ни в одной действительно серьезной распределенной информационной системе не удастся обойтись без применения некоторой технологии интеграции. К счастью, теперь существует путь решения этой проблемы, который сам лежит в русле открытых систем, - подход, предложенный крупнейшим международным консорциумом OMG (Object Management Group).

Остановимся на некоторых факторах, стимулирующих  использование методов интеграции разнородных информационных ресурсов (здесь используются материалы статьи Л.А.Калиниченко и др. из журнала "СУБД" N 4, 1995 г.).

1. Неоднородность, распределенность и автономность информационных ресурсов системы. Неоднородность ресурсов может быть синтаксической (при их представлении используются, например, разные модели данных) и/или семантической (используются разные виды семантических правил, детализируются и/или агрегируются разные аспекты предметной области). Возможна и чисто реализационная неоднородность информационных ресурсов, обусловленная использованием разных компьютерных платформ, операционных систем, систем управления базами данных, систем программирования и т.д.
2. Потребности в интеграционном комплексировании компонентов информационной системы. Очевидно, что наиболее естественным способом организации сложной информационной системы является ее иерархически-вложенное построение. Более сложные функционально-ориентированные компоненты строятся на основе более простых компонентов, которые могли проектироваться и разрабатываться независимо (что порождает неоднородность; ниже мы приведем примеры).
3. Реинжинерия системы. После создания начального варианта информационной системы неизбежно последует процесс ее непрерывных переделок (реинжинерии), обусловленный развитием и изменением соответствующих бизнес-процессов корпорации. Реконструкция системы не должна быть революционной. Все компоненты, не затрагиваемые процессом реинжиниринга, должны сохранять работоспособность.
4. Решение проблемы унаследованных (legacy) систем. Любая компьютерная система (надеюсь, что это не относится к открытым системам в теперешнем понимании; только надеюсь, поскольку неизвестно, как отнесутся к нашим взглядам будущие поколения) со временем становится бременем корпорации. Постоянно (и чем раньше, тем лучше) приходится решать задачу встраивания устаревших информационных компонентов в систему, основанную на новой технологии. Нужно, чтобы эта задача была разрешимой, т.е. чтобы компоненты унаследованных систем сохраняли интероперабельность.
5. Повторно используемые (reusable) ресурсы. Технология разработки информационных систем должна способствовать использованию уже существующих компонентов, что в конечном итоге должно перевести нас от экстенсивного ручного программистского труда к интенсивным методам сборки ориентированной на конкретную область применения информационной системы.
6. Продление жизненного цикла информационной системы. Чем дольше живет и приносит пользу информационная система, тем это выгоднее для корпорации. Естественно, что для этого должна существовать возможность добавления в нее компонентов, спроектированных и разработанных, вообще говоря, в другой технологии.