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

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

Трехуровневые архитектуры

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

управление пользовательским интерфейсом;

выполнение правил обработки;

выполнение функций хранения и выборки данных.

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

Таким образом, мы можем хранить записи о покупателях в обычных индексированных файлах, записи о заказах - в базе данных Oracle RdB, а записи о запасах - в базе данных Oracle?. Для выборки этих данных приложение вызывает каждую базу данных с помощью соответствующих вызовов, а отдельные совокупности данных не знают о существовании друг друга. К сожатению, это, в свою очередь, означает, что все вопросы целостности ссылок теперь должны решаться приложением. Поскольку ни один из этих складов данных ничего не знает о других, никто из них не может отвечать за ведение перекрестных ограничений между базами данных.

Хотя Oracle? может работать в трехуровневой архитектуре как уровень управления данными, чаще всего эта СУБД разворачивается в двухуровневой архитектуре, где код пользовательского интерфейса (программа управления экранной формой или генератор отчетов) непосредственно взаимодействует с БД через SQL*Net, а средний уровень создается хранимыми процедурами PL/SQL (обычно в форме пакетов), что повыщает производительность и улучшает управляемость.

Для большинства приложений Oracle? мы рекомендуем следующий порядок размещения логики;

правила для интерфейса - во внешней системе (Oracle Forms, PowerBuilder и т.д.);

у1 АО

правила для процессов - в пакетах PL/SQL;

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

В идеале интерфейсные процессы не смогут непосредственно вставлять, обновлять и удалять данные из таблиц, а будут вынуждены выполнять все DML-операции через хранимый PL/SQL-код. Хотя этот подход плохо сочетается со многими предлагаемыми на рынке средствами ускоренной разработки приложений (которые расхваливают за способность генерировать DML-код), он все же позволяет сконцентрировать правила для процессов в одном месте - в базе данных, чтобы их могли совместно использовать все интерфейсы.

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

Повышенные требования к связываемости

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

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

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

Метрики,

макеты

и спецификации

в этой главе:

Разработка метрик проектирован II я

и генерации миду и и

Илгнание мсга iioeij wii

Следует ли вы но. тнть макет ирован не?

Где люа специфт.пн, }!? Принципы pa.i/)(i6mni;u спецификаций uodi/. leii

Описание жра.чны.г форм и отчетIf.

Опиеапне 1ШК< там процессов

В процессе проектирования любой системы наступает момент, когда руководитель проекта начинает преследовать вас вопросами наподобие следующих: Сколько времени понадобится на генерацию этих модулей? , Какими средствами вы будете пользоваться для их генерации? И это еще в лучщем случае. Если же вам не повезет, то руководство к этому моменту уже ответит на эти вопросы к своему полному удовлетворению и перед вами встанет воистину невыполнимая задача - сделать так, чтобы предсказания руководства сбылись! (В этой главе мы попытаемся помочь вам справиться с этой задачей.)

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

Затем, во время пользовательских приемо-сдаточных испытаний, к вам подойдет пользователь и скажет: Это первая из систем, поставленных нам отделом информационных технологий, которая с первого раза делает именно то, что нам нужно . Вы отвечаете (самодовольно): Именно поэтому мы с вами потратили время на макетирование, прежде чем начинать писать код всерьез .

Эта глава посвящена основам черной магии проектирования кода - оценке трудоемкости, составлению спецификаций и макетированию.