23.10.3. Функциональная архитектура

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

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

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

  2. (концептуальный, внутренний и внешний уровни в терминах архитектуры ANSI/X3/SPARC) и междууровневых отображений данных, ·   

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

  4. поддержку функций администратора системы;

  5. физическую и логическую целостность базы данных;

  6. разграничение доступа к данным в системе базы данных;

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

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

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

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

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

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

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

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

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