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

Переходя к трехуровневым архитектурам, мы рассчитываем найти логику представления данных на клиенте, прикладную логику - на среднем уровне, а логику обработки данных - на сервере данных. Архитектура NCA (Network Computing Arcliitecture), предложенная корпорацией Oracle, делает трехуровневые, а по сути дела п-уровневые, приложения более доступными для проектировщиков. (Подробнее об NCA вы узнаете в разделе Версия 7.3 .)

Давайте вернемся к примеру с прокатом автомобилей. Наши пользователи будут работать с приложением клиент/сервер на ПК. Для них важна возможность быстрой обработки процедуры возврата автомобилей, так как часто клиент спешит, например опаздывает на самолет. Мы решили спроектировать процедуру расчета с клиентом так, чтобы при вводе номера документа на право проката вся информация, необходимая для завершения транзакции, загружалась с сервера на ПК и хранилась локально. Она не обязательно должна появляться на экране вся сразу (и загромождать экран), а будет храниться в памяти ПК или на его локальном диске. После завершения транзакции на сервер отправляются только новые и измененные данные. Говоря языком Oracle, на сервере будет пакет хранимых процедур, обрабатывающий запросы клиента; клиенту никогда не понадобится непосредственно обращаться к таблицам Oracle на сервере.

Более подробно проектирование для архитектур клиент/сервер рассматривается в главе 11.

Распределенные базы данных

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

Некоторые данные настолько трудно разделить без ущерба для смысла, что единственное решение - оставить их на одном сервере. Другие данные поддаются вполне естественному разделению, при этом каждое подмножество может располагаться на отдельном сервере - например, данные, зависящие от географического расположения (от страны или региона), можно держать на сервере, обслуживающем этот регион. К разделенным таким образом данным можно обращаться с удаленного узла посредством распределенного запроса. Их даже можно обновлять в удаленном режиме, пользуясь распределенной транзакцией, в которой можно одновременно обновлять данные на нескольких узлах. Альтернативная реализация секционированных данных - наличие неизменяемых копий секции на некоторых или всех других серверах. Эти копии, называемые снимками, периодически обновляются, однако 100%-ная их актуальность не гарантируется.

Если данные не живут на каком-то конкретном сервере, то может оказаться приемлемым решение, основанное на схеме с множеством мастеруз-лов. Эта технология позволяет нескольким узлам владеть одной таблицей и обновлять ее так же, как любую локальную таблицу. Изменения в этой таблице будут распространяться во все остальные копии - либо синхронно (в пределах транзакции), либо асинхронно (позже).

Oracle с SQL*Net поддерживает все эти возможности с помощью таких средств, как каналы связи базы данных, двухфазная фиксация, снимки, неизменяемые снимки и репликация.

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

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

Хранилища данных

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

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

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

Хранрглище данных строится по следующему принципу. Необходимые данные извлекаются из действующих систем и преобразуются в формат, приемлемый для сложных нерегламентированных запросов. Эти данные хранятся в отдельной базе данных, которая может быть очень большой и содержать архивную информацию, уже изъятую из живых систем. Мы добавляем к этой базе данных необходимые пользователям средства для нерегламетированных обращений, позволяющие им углубиться в данные, и даем пользователям полную свободу в работе с этими средствами. Проектирование базы данных и средств ввода данных для хранилища данных отличаются от проектирования традиционной системы оперативной обработки транзакций (OLTP - Online Transaction Processing). Для такого проектирования необходимо много новых навыков - например, знание многомерного анализа.

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

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

Параллельная обработка

Параллельная обработка заключается в использовании максимального количества наличных аппаратных ресурсов путем инициирования достаточного для полной загрузки машины объема работы. Самые очевидные ресурсы - это центральные процессоры (ЦП) и запоминающие устройства, как правило, диски. Например, ПО Oracle Server специально предназначено для использования всех преимуществ многопроцессорных машин. Parallel Query Option позволяет разбить определенные запросы на компоненты, а затем послать каждый компонент для выполнения на отдельный ЦП. Параллельную обработку можно успешно применять и при работе с дисками: например, стрипинг позволяет распределять нагрузку между дисками. Необходимо оценить потенциальные узкие места в системе и решить, например, что является более серьезной проблемой - нагрузка на сервер или ограничения, накладываемые сетью.

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

Базовая платформа системы - Unix-сервер с четырьмя ЦП и 128 Мбайт оперативной памяти. Когда работает программа ежемесячного начисления оплаты, никаких других операций сервер не выполняет, поэтому три процессора большей частью простаивают. Мы решаем увеличить пропускную способность системы, разбив выполнение этой программы на четыре