ЧАСТЬ 2 лщтннып систем баз данных

но. Поэтому мы все же рассмотрим некоторые аспекты программной архитектуры.

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

Теперь вместо бесчисленных строчек запутанного программного кода программисты-аналитики имели дело с фрагментами кода гораздо меньшего объема. Эти фрагменты как-то взаимодействовали друг с другом, однако как именно, было весьма

тельно.

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

собов организации многоуровневой архитектуры. Мы подробно рассмотрим два наиболее распространенных: трехуровневую и четырехуровневую архитектуру.

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

В трехуровневой архитектуре выделяют три уровня программных компонентов: пользовательский (User Services), промежуточный или бизнес-уровень (Business Services) и уровень данных (Data Services). Microsoft Visual Modeler - интерактивный инструмент для моделирования данных, интегрированный с Microsoft Visual Studio 6.0, ноддер-живает эту модель (рис.

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

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

ГЛАБА 1D С-лемя базы цониых

X ИГ. А 5ut ЫЛ

inji Ifl-I д,

Рас, 10-1 Щ$иа1 Modeler поддерживаем Овневую архитектуру

Трехуровневая модель проста мтна, и Visual Modeler - практичное, широко распространенное средство моделирования данных. Однако я почти не пользуюсь им для разработки реальных систем. Дело в что каждая система, как правило, включает в себя функ-ггни не принадлежащие ни к одному из уровней. Рассмотрим пример: некий данных требуется отформатировать, прежде чем выводить пользователю. Скажем, индивидуальный номер, присваиваемый при выдаче свидетельства социального страхования, может храниться в базе данных как девятиразрядное десятичное число, но отображаться на экране компьютера он должен в виде К какому уровню должно относиться форматирование данные - к пользовательскому или к уровню данных? Можно привести аргументы в пользу и того, и другого. Еще вопрос: к какому уровню отнести управление транзакциями - к бизнес-уровню или уровню данных? При моделировании сложных систем с использованием иерархических представлений и преобразования данных на эти вопросы ответить не так-то легко.

Если действовать последовательно, вопрос, к какому из уровней отнести подобные функции, не принципиален; однако именно в этом месте модель дает сбой, При создании модели невозможно обойтись без искусственно введенных ограничений и соглашений: например,

ЧАСТЬ 2 Проеюровэиие реляционны систем баз данных

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

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

Выделение четырех уровней в архитектуре программного кода позволяет избежать многих проблем, свойственных трехуровневой архитектуре. В четырехуровневой архитектуре (рис. IO-2J, часто называемой также парадигмой уровней, выделяют, соответственно: уровень интерфейса пользователя (I svi Interface layer), уровень интерфейса данных (Data Interface layer), уровень интерфейса транзакций (Transaction Interface layer) и уровень интерфейса внешнего доступа (External Access Jiuerlace layer).

Компонент пользовательского интерфейса /

i\ Компонент пользовав Компонент польэоаа-\ Компонент польэова- / \ тельского /\ тепьского У \ те льо кого \ ии rep- / интер- / ч интер.

X фейса

/компонентЧ

{ лнтейФай )

Механизм Саз данных

Механизм баз данных

Рис. 19-2. Четырехуровневая модель

Уровень интерфейса пользователя соответствует пользовательскому уровню трехуровневой модели. Программные компоненты уровня интерфейса пользователя осуществляют взаимодействие с пользователем ом числе: представляют данные посредством объектов диалоговых окон, отвечают на изменения пользователем состояния обьек-