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

(DataMart; кстати ведущий специалист Московского отделения компании

Informix Ховард Залкин предпочитает называть их "лавками данных"). Рынок

данных по своему исходному определению - это набор тематически связанных

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

деятельности корпорации. По сути дела, рынок данных - это облегченный

вариант склада данных, содержащий только тематически объединенные данные.

Целевая база данных максимально приближена к конечному пользователю и может

содержать тематически ориентированные агрегатные данные. Рынок данных,

естественно, существенно меньше по объему, чем корпоративный склад данных,

и для его реализации не требуется особо мощная вычислительная техника.

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

реляционных баз данных?

В последнее время все более популярной становится идея совместить концепции

склада и рынка данных в одной реализации и использовать склад данных в

качестве единственного источника интегрированных данных для всех рынков

данных. Тогда естественной становится такая трехуровневая организация OLAP-

системы:

. На первом уровне реализуется корпоративный склад данных на основе

одной из развитых современных реляционных СУБД. Это хранилище

интегрированных в основном детализированных данных. Реляционные СУБД

обеспечивают эффективное хранение и управление данными очень большого

объема, но не слишком хорошо соответствуют потребностям OLAP-систем, в

частности, в связи с требованием многомерного представления данных.

. На втором уровне поддерживаются рынки данных на основе многомерной

системы управления базами данных (примером такой системы является

OracleExpressServer). Мы не будем рассматривать здесь особенности

организации многомерных СУБД (это отдельная большая тема), но заметим,

что такие СУБД почти идеально подходят для целей разработки OLAP-

систем, но пока не позволяют хранить сверхбольшие объемы данных

(предельный размер многомерной базы данных составляет 10-20 гигабайт).

В данном случае это и не требуется, поскольку речь идет о рынках

данных. Заметим, что рынок данных не обязательно должен быть полностью

сформирован. Он может содержать ссылки на склад данных и добирать

оттуда информацию по мере поступления запросов. Конечно, это несколько

увеличивает время отклика, но зато снимает проблему ограниченного

объема многомерной базы данных.

. Наконец, на третьем уровне находятся клиентские рабочие места конечных

пользователей, на которых устанавливаются средства оперативного

анализа данных.

8.2.5. Характеристика интегрированных продуктов ведущих компаний для

организации складов данных

В этом разделе мы коротко охарактеризуем продукты ведущих поставщиков,

имеющие связь с технологией складов данных.

8.2.5.1. Компания IBM

Решение компании IBM называется ADataWarehousePlus. Целью компании является

обеспечение интегрированного набора программных продуктов и сервисов,

основанных на единой архитектуре. Основой складов данных является семейство

СУБД DB2. Преимуществом IBM является то, что данные, которые нужно извлечь

из оперативной базы данных и поместить в склад данных, находятся в системах

IBM. Поэтому естественна тесная интеграция программных продуктов.

Предлагаются три решения для складов данных:

1. Изолированный рынок данных. Предназначен для решения отдельных задач

вне связи с общим хранилищем корпорации.

2. Зависимый рынок данных. Аналогичен изолированному рынку данных, но

источники данных находятся под централизованным контролем.

3. Глобальный склад данных. Корпоративное хранилище данных, которое

полностью централизовано контролируется и управляется. Глобальный

склад данных может храниться централизовано или состоять из нескольких

распределенных в сети рынков данных.

8.2.5.2. Oracle

Решение компании Oracle в области складов данных основывается на двух

факторах: широкий ассортимент продуктов самой компании и деятельность

партнеров в рамках программы WarehouseTechnologyInitiative. Возможности

Oracle в области складов данных базируются на следующих составляющих:

. наличие реляционной СУБД Oracle 7 (а теперь и Oracle 8), которая

постоянно совершенствуется для лучшего удовлетворения потребностей

складов данных;

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

разработки склада данных;

. высокий технологический потенциал компании в области анализа данных;

. доступность ряда продуктов, производимых другими компаниями.

8.2.5.3. HewlettPackard

Работы, связанные со складами данных, выполняются в рамках программы

OpenWarehouse. Выполнение этой программы должно обеспечить возможность

построения складов данных на основе мощных компьютеров HP, аппаратуры

других производителей и программных компонентов. Основой подхода HP

являются Unix-платформы и программный продукт IntelligentWarehouse, который

предназначен для управления складами данных. Основа построения складов

данных, предлагаемая HP, оставляет свободу выбора реляционной СУБД, средств

реинжиниринга и т.д.

8.2.5.4. Sybase

Стратегия компании в области складов данных основывается на разработанной

ей архитектуре WarehouseWORKS. В основе подхода находится реляционная СУБД

SybaseSystem 11, средство для подключения и доступа к базам данных

OmniCONNECT и средство разработки приложений Powerbuilder. Компания

продолжает совершенствовать свою СУБД для лучшего удовлетворения

потребностей складов данных (например, введена побитная индексация).

8.2.5.5. InformixSoftware

Стратегия компании в отношении складов данных направлена на расширение

рынка для ее продукта OnLineDynamicParallelServer. Предлагаемая архитектура

склада данных базируется на четырех технологиях: реляционные базы данных,

программном обеспечении для управления складом данных, средствах доступа к

данным и платформе открытых систем. Три последние компонента

разрабатываются партнерами компании. После выхода Универсального Сервера,

основанного на объектно-реляционном подходе, можно ожидать, что и он будет

использоваться для построения складов данных.

8.2.5.6. AT&TGIS

Решение компании направлено на решение проблем корпораций, у которых

одинаково сильны потребности и в системах поддержки принятия решений, и в

системах оперативной аналитической обработки данных. Предлагаемая

архитектура называется EnterpriseInformationFactory и основывается на опыте

использования системы управления базами данных Teradata и связанных с ней

методах параллельной обработки.

8.2.5.7. SASInstitute

Компания считает себя поставщиком полного решения для организации склада

данных. Подход основан на следующем:

. обеспечение доступа к данным с возможностью их извлечения из самых

разнообразных хранилищ данных и реляционных, и нереляционных;

. преобразование данных и манипулирование ими с использованием 4GL;

. наличие сервера многомерных баз данных;

. большой набор методов и средств для аналитической обработки и

статистического анализа.

8.2.5.8. SoftwareAG

Деятельность компании в области складов данных происходит в рамках

программы OpenDataWarehouseInitiative. Программа базируется на основных

продуктах компании ADABAS и Natural 4GL, собственных и приобретенных

средствах извлечения и анализа данных, средстве управления складом данных

SourcePoint. SourcePoint позволяет автоматизировать процесс извлечения и

пересылки данных, а также их загрузки в склад данных.

Существует еще целый ряд компаний, которые прямо или косвенно связаны с

технологией складов данных, но мы ограничимся перечисленными, поскольку их

продукты и подходы кажутся наиболее продвинутыми.

9. Разновидности и архитектуры информационных приложений

В зависимости от конкретной области применения, информационные системы

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

Однако можно выделить по крайней мере два свойства, которые являются общими

для всех информационных систем.

Во-первых, любая информационная система предназначена для сбора, хранения и

обработки информации. Поэтому в основе информационной системы лежит среда

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

хранения и эффективность доступа, соответствующие области применения

информационной системы.

Во-вторых, информационные системы ориентируются на конечного пользователя,

например, банковского клерка. Такие пользователи могут быть очень далеки от

мира компьютеров. Для них терминал, персональный компьютер или рабочая

станция представляют собой всего лишь орудие их собственной

профессиональной деятельности. Поэтому информационная система обязана

обладать простым, удобным, легко осваиваемым интерфейсом, который должен

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

но в то же время не дать ему возможность выполнять какие-либо лишние

действия. Иногда этот интерфейс может быть графическим с меню, кнопками,

подсказками и т.д. Сейчас очень популярны графические интерфейсы, и многие

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

ориентированы на разработку графических интерфейсов. Наличие развитых

интерфейсных средств является обязательным для любой современной

информационной системы.

Тематика прикладных информационных систем исключительно широка. В этой

части курса мы рассмотрим только некоторые вопросы, связанные с

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

слишком углубляться в технические детали.

9.1. Обзор рынка готовых информационных приложений

Сегодня трудно найти компанию, производящую компьютерную технику или

программное обеспечение, которая не поставляла бы средства разработки

информационных приложений, компоненты информационных систем или законченные

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

правила является компания InformixSoftware, которая (по крайней мере, пока)

производит только базовые программные системы и средства разработки, но не

предлагает собственных готовых приложений, оставляя их создание своим

партнерам.

Вообще, в компьютерном мире понятие стороннего поставщика (third-

partycompany) имеет очень большое значение, поскольку значительная часть

прикладного программного обеспечения производится именно небольшими

независимыми софтверными компаниями.

9.1.1. Информационные приложения, поставляемые крупными компаниями

производителями вычислительной техники и СУБД (Oracle, Hewlett-Packard,

IBM, Microsoft и т.д.)

Исключительно в качестве примера приведем очень краткую характеристику

прикладных программных продуктов, производимых и распространяемых

некоторыми ведущими компаниями.

Начнем с компании Oracle. Представители этой компании любят представлять

набор производимых продуктов в виде перевернутой пирамиды с вершиной внизу

и основанием наверху. Вершине пирамиды соответствует базовый комплект

серверов баз данных, предлагаемых компанией. В середине пирамиды

располагаются средства проектирования и разработки баз данных и

информационных систем (в частности, Designer/Developer 2000). Наконец,

основанию пирамиды соответствуют готовые компоненты информационных

приложений и законченные решения. Такая картина правильно отражает

соотношения объемов и числа продуктов. Конечно, серверы баз данных - это

наиболее сложные и ответственные продукты. Но их число и объем кода не

очень велики. Средства проектирования и разработки опираются на

использование серверов; эти продукты менее сложны, но более объемны.

Наконец, приложения создаются с использованием средств проектирования и

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

Oracle предлагает приложения (естественно, основанные на использовании

серверов баз данных Oracle) для использования в следующих предметных

областях:

. управление финансами (распределенные многовалютные бухгалтерские

системы, системы финансового планирования, системы финансового анализа

и т.д.);

. управление человеческими ресурсами (автоматизация процедуры найма на

работу, планирование обучения персонала, удержания его в компании,

продвижения по службе и т.д.);

. автоматизация производства (автоматизированные гибридные

производственные системы, системы поддержки новых методов инженерии,

системы планирования и моделирования и т.д.);

. системы поддержки ведения проектов (организация и мониторинг процесса

проектирования, отслеживание проектных расходов и т.д.);

. автоматизация деятельности по продажам (анализ рынка, управление

рыночной деятельностью, управление продажами);

. системы сетевого планирования.

Другая картина представлена компанией HewlettPackard. Как один из ведущих

производителей вычислительной техники, компания в основном зарабатывает

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

спроса желательно предлагать заказчикам готовые решения. Это и делает

компания. В кооперации с компаниями-разработчиками программного обеспечения

(в частности, с Oracle) разрабатываются законченные аппаратно-программные

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

В частности, имеются решения HP для применения в следующих сферах:

. проверка качества окружающей среды;

. управление финансами;

. автоматизация государственной деятельности (федерального уровня,

уровня штата, уровня города и т.д.);

. автоматизация деятельности в области здравоохранения;

. системы фармацевтического анализа;

. автоматизация производства;

. управление розничной торговлей и т.д.

Компания IBM, являясь крупнейшей (и одной из старейших) в мире

производителей компьютеров и программного обеспечения, предлагает

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

всех сферах человеческой деятельности. Естественно, как и в случае

HewlettPackard, эти решения опираются на аппаратные средства IBM (и базовое

программное обеспечение этой же компании).

Совершенно необъятное число информационных приложений предлагает компания

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

продуктов, компания Microsoft предлагает компоненты для горизонтального

рынка - набор полуфабрикатов, пригодных для построения бухгалтерских

систем, систем документооборота, систем планирования ресурсов и т.д., а

также готовые продукты для вертикального рынка - финансовые системы,

здравоохранение, автоматизация работы гостиниц, издательские системы и т.д.

9.1.2. Приложения, предлагаемые третьими компаниями (пример: Catalyst

компании SunMicrosystems)

Мы уже отмечали, что большинство прикладных программных продуктов

производится небольшими самостоятельными софтверными компаниями. Такие

компании в силу ограниченности своих ресурсов часто не могут обеспечить

разработку и сопровождение продуктов на разных платформах и

сосредотачиваются на поддержке платформ одного поставщика. Компании этого

рода недаром называют "сторонними поставщиками", поскольку они ведут свою

собственную политику, сами рекламируют и продают свою продукцию и не

связаны со своими "старшими братьями" партнерскими отношениями. Тем не

менее, основные поставщики также заинтересованы в том, чтобы их

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

поскольку это является дополнительным доводом при принятии решения о

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

о доступности продуктов сторонних поставщиков.

Например, компания SunMicrosystems каждый год издает специальный каталог

под названием "Catalyst", содержащий исключительно информацию о продуктах

независимых фирм, работающих на платформах Sun. Catalyst обычно имеет объем

более 1000 страниц. Прикладные продукты разбиты на предметно-

ориентированные категории. По поводу каждого продукта приводятся его

краткая характеристика и адрес и другая контактная информация

производителя.

9.2. Инструментальные средства создания пилотных версий приложений и

разработки их законченных вариантов

Понятное дело, что любую программу можно написать на любом языке

программирования. Однако, когда речь идет об информационных приложениях,

существенно возрастает сложность проектирования и программирования

интерфейсов с конечным пользователем (как мы отмечали, эти интерфейсы

должны быть предельно просты, понятны и удобны), а также требуется большая

скорость получения хотя бы как-нибудь работающей версии программы (чтобы

понять, устраивает ли это приложение хотя бы в первом приближении).

9.2.1. Что такое "быстрая разработка приложений"

(rapidapplicationdevelopment)

Все равно, если Вы хотите получить правильно работающую, настроенную под

Ваши потребности, грамотно написанную программу, обращайтесь к

профессионалам. Но необходимо знать, какие средства разработки Вашими

коллегами применяются. Возможны два подхода: RapidApplicationDevelopment -

быстрая разработка приложения и традиционный способ программирования.

Быстрая разработка - это, как правило, создание работающего прототипа

приложения (прототипа в том смысле, что это все-таки не законченное

приложение, а некоторый его прообраз). Этот прототип может быть полностью

функционален. (Иногда не полностью; это зависит от сложности приложения.)

Что Вам могут честно обещать - это полная отработка интерфейсов. Экранные

формы, разного рода меню, подсказки делаются быстро и качественно. Можно

почувствовать, как внешне будет выглядеть приложение.

Но это не значит, что внутренность прикладной программы будет достаточно

эффективной и качественной. Как правило, за небольшим числом исключений (к

ним, в частности, относится язык компании BorlandDelphi) языки быстрого

прототипирования являются интерпретируемыми. Это не обязательно означает

пошаговую пооператорную обработку программы. Иногда, как в случае языка

Java, вся программа подвергается предварительной обработке, в результате

которой образуется промежуточный машинно-независимый код, который в

дальнейшем исполняется с помощью встроенного машинно-независимого

интерпретатора. Но в любом случае интерпретатор остается интерпретатором;

он не может так же эффективно выполнять программу как компьютер.

Почему же так часто используются языки быстрой разработки приложений?

Основной ответ состоит в том, что они действительно быстро дают возможность

получить работающий вариант программы со всеми ее внешними интерфейсами

(применительно к системам, связанным с базами данных, такие языки часто

называют 4GL, языками четвертого поколения).

9.2.2. Пригодны ли средства быстрой разработки только на стадии пилотного

проекта?

Конечно же, нет. Можно найти массу простых информационных приложений,

основное назначение которых состоит в том, чтобы формировать отчеты на

основе заранее подготовленных запросов пользователей к базам данных. Общая

эффективность подобных приложений главным образом определяется

эффективностью используемой СУБД, и на нее мало влияет интерпретируемость

выполнения клиентской части приложения.

Заметим, что большая часть современных языков и инструментальных средств

быстрой разработки приложений (например, Delphi компании Borland,

PowerBuilder компании Sybase и т.д.) имеют несколько собственных

интерфейсов с распространенными серверами баз данных, либо могут работать с

ними через драйверы ODBC. Поэтому с архитектурной точки зрения быстро

разработанное приложение вполне может соответствовать модели "клиент-

сервер". Если же в дополнение к средствам быстрой разработки применяются

такие серверные средства как хранимые процедуры, ограничения целостности и

триггеры, то часть логики приложения может быть перенесена на сервер баз

данных (фактически, это позволяет сформировать третье звено общей цепочки -

сервер приложений).

9.2.3. Тенденции к сближению языков быстрой разработки и языков

программирования. Что это дает?

При использовании средств быстрой разработки приложений для создания

сложных информационных систем с необходимостью существенных вычислений на

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

создается пилотный проект, выполненный целиком на языке быстрой разработки,

а затем наиболее ответственные части приложения переписываются на некотором

традиционном языке программирования (как правило, на Си/Си++),

компилируются и компонуются с остальной частью системы. В большинстве

средств быстрой разработки такая возможность явно предусматривается и

поддерживается. Ясно, что так работать можно. Но возникают некоторые

сомнения.

По каким причинам для большинства языков быстрой разработки используется

техника интерпретации? Кажется, что можно дать два основных ответа. Во-

первых, в случае применения интерпретации упрощаются компиляторы. В

частности, в компиляторе исчезает существенный по сложности компонент

генерации машинных кодов. В результате средство быстрой разработки может

быть реализовано быстрее. Быстрее можно получить и работоспособный вариант

приложения. Во-вторых, применение техники интерпретации машинно-независимых

промежуточных кодов снимает (или, по крайней мере, облегчает) проблему

переноса на новую платформу как самого средства разработки, так и созданных

на его основе информационных систем. Но на самом деле, оба приведенных

довода являются чисто техническими.

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

программирования (например, того же семейства Си/Си++), которые легко

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

обеспечивают простоту переноса приложений. К тому же, эти компиляторы

обеспечивают высокое качество генерируемого кода и соответственно высокую

эффективность выполнения приложений.

В настоящее время имеется явная тенденция к переходу на новое поколение

средств быстрой разработки, которые не утратят достоинства существующих

систем, но будут выполняться в режиме компиляции. Одним из ярких примеров

таких систем является BorlandDelphi, которая позволяет быстро производить

высокоэффективные информационные приложения (ограни- чиваясь, правда,

платформами Intel). В компьютерной прессе обсуждаются перспективы к пе-

реходу на такую технологию для Powerbuilder и других средств быстрой

разработки.

9.2.4. Особенности инструментальных средств, предназначенных для разработки

Intranet-приложений

Об Intranet-приложениях уже достаточно много говорилось в этом курсе. Тем

не менее, для полноты мы немного обсудим особенности инструментальных

средств Intranet-приложений и в этом пункте.

Не будем обсуждать базовые механизмы организации Web-ориентированных

Intranet-приложений и, в частности, средства их интеграции с другими

серверами (включая, естественно, серверы баз данных). Коснемся только языка

Java, наиболее популярного на сегодня инструмента Internet/Intranet, и

сопоставим особенности реализации и использования Java с языками быстрой

разработки, упоминавшимися в предыдущих пунктах этого раздела.

Краткой характеристикой языка Java может быть следующее: более безопасный

по сравнению с Си++ объектно-ориентированный язык с постоянно

развивающимися библиотеками классов. Компания SunMicrosystems разработала и

ввела в обиход этот язык специально для операционной поддержки клиентов

Всемирной Паутины. Полная машинная независимость языка Java дала

возможность создать ряд интерпретаторов, которые сегодня существуют

практически для всех платформ и в состоянии выполнять программы (Java-

апплеты), передаваемые клиенту с Web-серверов. Хотя много раз начинались

разговоры о реализации компиляторов Java в машинные коды, для "гуляющих" по

Сети Java-апплетов более естественно применение интерпретации промежуточных

кодов.

9.3. Обзор применяемых архитектур современных информационных приложений

В начале этой части курса мы кратко рассмотрели основные требования,

которым должна удовлетворять информационная система, и задачи, которые

должны решаться такой системой. При этом мы подчеркивали, что строгость

соблюдения требований и фиксированность набора решаемых задач во многом

являются условными в зависимости от конкретных целей, для достижения

которых разрабатывается прикладная информационная система. Соответственно,

проектирование и разработка информационной системы может базироваться на

разных архитектурных решениях.

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

информационных систем. Мы начинаем с традиционных архитектурных решений,

основанных на использовании выделенных серверов баз данных и, возможно,

серверов приложений. Затем рассматриваются варианты архитектур

корпоративных информационных систем, базирующихся на технологии Internet

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

системы (еще не вполне установившаяся) относится к приложениям оперативной

аналитической обработки данных. Наконец, последняя выделяемая нами

архитектура предназначена для построения глобальных распределенных

информационных приложений с интеграцией информационно-вычислительных

компонентов на основе объектно-ориентированного подхода.

Замечание по поводу терминологии. С терминологией в области информационных

систем вообще, а русскоязычной терминологией в особенности, дела обстоят

неважно. Область информационных систем очень быстро развивается.

Практически каждый год возникают новые технологии и архитектурные решения,

для которых в маркетинговых целях придумываются оригинальные, привлекающие

внимание названия, далеко не всегда точно отражающие смысл технологии и/или

архитектуры. На самом деле, все подходы к организации информационных

систем, рассматриваемые в этом курсе базируются на общей архитектуре

"клиент-сервер". Различие состоит только в том, что делают клиенты и

серверы. Тем не менее, чтобы избежать путаницы, далее мы вынуждены

применять русскоязычные эквиваленты соответствующих англоязычных терминов.

Следует заметить, что как и любая классификация, наша классификация

архитектур информационных систем не является абсолютно жесткой. В

архитектуре любой конкретной информационной системы часто можно найти

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

архитектурном проектировании системы кажется полезным иметь хотя бы

частично ортогонализированный архитектурный базис.

9.3.1. Информационные системы, использующие серверы приложений

Под клиент-серверным приложением в узком смысле мы будем понимать

информационную систему, основанную на использовании серверов баз данных.

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

показано на рисунке 9.1.

[pic]

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

сервер"

. На стороне клиента выполняется код приложения, в который обязательно

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

производящие отчеты, выполняющие другие специфичные для приложения

функции.

. Клиентская часть приложения взаимодействует с клиентской частью

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

является индивидуальным представителем СУБД для приложения.

(Здесь опять проявляются недостатки в терминологии. Обычно, когда компания

объявляет о выпуске очередного сервера баз данных, то неявно понимается,

что имеется и клиентская составляющая этого продукта. Сочетание "клиентская

часть сервера баз данных" кажется несколько странным, но нам придется

пользоваться именно этим термином.)

Интерфейс между клиентской частью приложения и клиентской частью сервера

баз данных, как правило, основан на использовании языка SQL. Поэтому такие

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

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

в коде приложения.

. Наконец, клиентская часть сервера баз данных, используя средства

сетевого доступа, обращается к серверу баз данных, передавая ему текст

оператора языка SQL.

Здесь необходимо сделать еще два замечания:

1. Обычно компании, производящие развитые серверы баз данных, стремятся к

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

только в стандартных на сегодняшний день TCP/IP-ориентированных сетях,

но и в сетях, основанных на других протоколах (например, SNA или

IPX/SPX). Поэтому при организации сетевых взаимодействий между

клиентской и серверной частями СУБД часто используются не стандартные

средства высокого уровня (например, механизмы программных гнезд или

вызовов удаленных процедур), а собственно функционально подобные

средства, менее зависящие от особенностей сетевых транспортных

протоколов.

2. Когда мы говорим об интерфейсе на основе языка SQL, нужно отдавать

себе отчет в том, что несмотря на титанические усилия по

стандартизации этого языка, нет такой реализации, в которой

стандартные средства языка не были бы расширены. Необдуманное

использование расширений языка приводит к полной зависимости

приложения от конкретного производителя сервера баз данных.

Посмотрим теперь, что же происходит на стороне сервера баз данных. В

продуктах практически всех компаний сервер получает от клиента текст

оператора на языке SQL.

. Сервер производит компиляцию полученного оператора. На основе

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

преобразование непроцедурного представления оператора в некоторую

процедуру его выполнения.

. Далее (если компиляция завершилась успешно) происходит выполнение

оператора. Рассмотрим возможные действия операторов SQL:

. Оператор может относиться к классу операторов определения (или

создания) объектов базы данных (точнее и правильнее было бы говорить

про элементы схемы базы данных или про объекты метабазы данных). В

частности, могут определяться домены, таблицы, ограничения

целостности, триггеры, привилегии пользователей, хранимые процедуры. В

любом случае, при выполнении оператора создания элемента схемы базы

данных соответствующая информация помещается в таблицы-каталоги базы

данных (в таблицы метабазы данных). Ограничения целостности обычно

сохраняются в метабазе данных прямо в текстовом представлении. Для

действий, определенных в триггерах, и хранимых процедур вырабатывается

и сохраняется в таблицах-каталогах процедурный выполняемый код.

Заметим, что ограничения целостности, триггеры и хранимые процедуры

являются, в некотором смысле, представителями приложения в

поддерживаемой сервером базе данных; они составляют основу серверной

части приложения.

. При выполнении операторов выборки данных на основе содержимого

затрагиваемых запросом таблиц и, возможно, с использованием

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

данных. Серверная часть СУБД пересылает результат клиентской части, и

окончательная обработка производится уже в клиентской части

приложения.

. При выполнении операторов модификации содержимого базы данных (INSERT,

UPDATE, DELETE) проверяется, что не будут нарушены определенные к

этому моменту ограничения целостности (те, которые относятся к классу

немедленно проверяемых), после чего выполняется соответствующее

действие (сопровождаемое модификацией всех соответствующих индексов и

журнализацией изменений). Далее сервер проверяет, не затрагивает ли

данное изменение условие срабатывания какого-либо триггера, и если

такой триггер обнаруживается, выполняет процедуру его действия. Эта

процедура может включать дополнительные операторы модификации базы

данных, которые могут вызвать срабатывание других триггеров и т.д.

Можно считать, что те действия, которые выполняются на сервере баз

данных при проверке удовлетворенности ограничений целостности и при

срабатывании триггеров, представляют собой действия серверной части

приложения.

. При выполнении операторов модификации схемы базы данных (добавления

или удаления столбцов существующих таблиц, изменения типа данных

существующего столбца существующей таблицы и т.д.) также могут

срабатывать триггеры, т.е., другими словами, может выполняться

серверная часть приложения.

. Аналогично, триггеры могут срабатывать при уничтожении объектов схемы

базы данных (доменов, таблиц, ограничений целостности и т.д.).

. Особый класс операторов языка SQL составляют операторы вызова ранее

определенных и сохраненных в базе данных хранимых процедур. Если

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

включающего и непроцедурные операторы SQL, и чисто процедурные

конструкции (например, языка PL/SQL компании Oracle), то в такую

процедуру можно поместить серьезную часть приложения, которое при

выполнении оператора вызова процедуры будет выполняться на стороне

сервера, а не на стороне клиента.

. При выполнении оператора завершения транзакции сервер должен проверить

соблюдение всех, так называемых, отложенных ограничений целостности (к

таким ограничениям относятся ограничения, накладываемые на содержимое

таблицы базы целиком или на несколько таблиц одновременно; например,

суммарная зарплата сотрудников отдела 999 не должна превышать 150 млн.

руб.). Снова к проверке отложенных ограничений целостности можно

относиться как к выполнению серверной части приложения.

Как видно, в клиент-серверной организации клиенты могут являться достаточно

"тонкими", а сервер должен быть "толстым" настолько, чтобы был в состоянии

удовлетворить потребности всех клиентов (рисунок 9.2).

[pic]

Рис. 9.2. Тонкий клиент и толстый сервер в клиент-серверной архитектуре

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

основанных на архитектуре "клиент-сервер", часто бывают неудовлетворены

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

потребности обращаться от клиента к серверу с каждым очередным запросом. На

практике распространена ситуация, когда для эффективной работы отдельной

клиентской составляющей информационной системы в действительности требуется

только небольшая часть общей базы данных. Это приводит к идее поддержки

локального кэша общей базы данных на стороне каждого клиента.

Фактически, концепция локального кэширования базы данных является частным

случаем концепции реплицированных (или, как иногда их называют в

русскоязычной литературе, тиражированных) баз данных. Как и в общем случае,

для поддержки локального кэша базы данных программное обеспечение рабочих

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

вариант сервера баз данных, который, например, может не обеспечивать

многопользовательский режим доступа. Отдельной проблемой является

обеспечение согласованности (когерентности) кэшей и общей базы данных.

Здесь возможны различные решения - от автоматической поддержки

согласованности за счет средств базового программного обеспечения

управления базами данных до полного перекладывания этой задачи на

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

том, что сервер тоньше не делается (рисунок 9.3).

[pic]

Рис. 9.3. Потолстевший клиент и толстый сервер в клиент-серверной

архитектуре с поддержкой локального кэша на стороне клиентов

Другой идеей, позволяющей сократить сетевой трафик между компонентам клиент-

серверной организации, является выделение дополнительного сервера (сервера

приложений), на который перекладывается часть прикладной обработки и в

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

Тогда клиенты взаимодействуют напрямую только с сервером (или несколькими

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14