Предисловие (стр. 31 )

Как уже отмечалось, важное место в функциональной архитектуре системы базы данных занимают механизмы поддержки различных уровней представления данных, в соответствии с архитектурной моделью ANSI/X3/SPARC. Каждый архитектурный уровень, кроме того, располагает внутренними и, возможно, внешними интерфейсами. Внутренние интерфейсы обеспечивают взаимодействие механизмов данного уровня с другими системными компонентами, а внешние (если они существуют) - с пользователями и/или с системным персоналом. Через эти интерфейсы уровневые механизмы получают и передают команды, сигналы обратной связи и данные.

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

Нужно заметить, что для управляемого архитектурного уровня степень его управляемости может быть различной. В некоторых СУБД внешние интерфейсы предоставляют только возможность определения данных, не обеспечивая доступа к средствам манипулирования данными. Таков уровень схемы в СУБД типа КОДАСИЛ. В других случаях, напротив, имеются возможности манипулирования данными, но не предоставляются средства определения данных. Примером может служить интерфейсы некоторых реляционных СУБД, в которых используются только средства языка SQL только для выборки данных из базы данных. Однако существуют и случаи полной управляемости. Такими возможностями обладают интерфейсы уровня подсхемы СУБД типа CODASYL, а также основанный на языке SQL пользовательский интерфейс в ряде реляционных серверов баз данных.

Неуправляемые архитектурные уровни часто используются при разработке СУБД по "технологическим" соображениям - для функциональной структуризации программного обеспечения системы по принципу "сверху вниз" и реализации принципов модульности ее организации.

Механизмы отображения данных, как и уровневые механизмы СУБД, располагают внутренними интерфейсами и могут располагать внешними интерфейсами. Внутренние интерфейсы служат для связи механизмов смежных архитектурных уровней, а внешние - для спецификации междууровневых отображений данных, если система предоставляет такие возможности.

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

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

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

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

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

Контрольные вопросы

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

Какие свойства системы базы данных характеризует ее информационная архитектура?

Необходимость обеспечения какой функции СУБД оказала определяющее влияние на сформировавшийся подход к информационной архитектуре систем баз данных?

Кратко охарактеризуйте основные принципы информационной архитектуры современной системы базы данных.

Какая связь существует между сложившимся подходом к информационной архитектуре систем базы данных и идеями архитектурной модели ANSI/X3/SPARC?

В чем заключается существо трехуровневой архитектуры ANSI/X3/SPARC?

Какова роль концептуальной, внутренней и внешних схем в походе ANSI/X3/SPARC?

Каким образом архитектурная модель ANSI/X3/SPARC обеспечивает независимость данных в системе базы данных, основанной на этой модели?

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

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

Каковы особенности и цели создания распределенных систем баз данных?

Опишите принципы организации мобильных систем базы данных.

В чем заключаются специфические особенности мобильных систем базы данных?

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

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

Что такое архитектурный уровень системы базы данных?

Какие архитектурные уровни называются управляемыми?

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

Каковы основные принципы архитектуры «клиент-сервер»?

Чем различаются двухзвенная и трехзвенная архитектура «клиент-сервер»?

8.8. Языковые средства СУБД

В других случаях функции языков могут быть доступны неявным образом, когда они реализуются в форме так называемых языков четвертого поколения (4GL) - различного рода меню, диалоговых сценариев или заполняемых пользователем экранных форм, различных диаграмм типов и других средств визуального представления данных. По таким входным данным интерфейсные средства формируют адекватные синтаксические конструкции языка интерфейса и передают их на исполнение или включают в генерируемый программный код приложения. Интерфейсы с неявным использованием языка широко используются в СУБД для персональных компьютеров.

В реляционных СУБД широко распространен также другой подход, при котором для обращения к СУБД нет необходимости выписывать операторы системных языков в виде строк литер. В середине 70-х годов сотрудником компании IBM М. Злуфом был разработан табличный язык запросов Query-By-Example (QBE). Для передачи запроса СУБД, поддерживающей этот язык, нужно заполнить некоторые столбцы и строки таблицы, которую система показывает пользователю на экране дисплея. Обработка такого запроса может быть реализована в системе, например, так, что на основе представления запроса, заданного средствами QBE,  генерируется его представление в языке SQL, и далее этот запрос обрабатывается средствами исполнения SQL-запросов.

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

Нужно отметить, что многие СУБД не имеют самостоятельных языков для спецификации междууровневых отображений данных, о которых шла речь выше (см. разд. 5.7). В таких случаях междууровневые отображения данных также описываются средствами ЯОД одного из смежных архитектурных уровней и включаются в соответствующую схему базы данных. Так, в подсхеме базы данных CODASYL (внешней схеме, по терминологии отчета ANSI/X3/SPARC) специфицируется ее отображение в схему базы данных (концептуальную схему, по терминологии ANSI/X3/SPARC).

Здесь уместно сделать важное замечание. Разработчики некоторых СУБД при проектировании архитектуры системы не уделяют достаточного внимания обеспечению естественного разделения функций уровней информационной архитектуры. В результате в значительной мере утрачивается возможность достижения той степени независимости данных, которую потенциально способна обеспечить "чисто" реализованная многоуровневая архитектура. Наиболее часто встречающиеся дефекты архитектуры заключаются в том, что спецификации некоторых характеристик организации хранимых данных, законное место которых в схеме внутреннего уровня, попадают в схему концептуального уровня.

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

Язык манипулирования данными (ЯМД) позволяет запрашивать предусмотренные в системе операции над данными из базы данных. Аналогично языку определения данных ЯМД не обязательно выступает в форме синтаксически самостоятельного языка СУБД. На практике разделение ЯОД и ЯМД играет скорее методическую роль или используется в технологических целях.