Главная » SQL, Базы данных » СИСТЕМА УПРАВЛЕНИЯ ПЕРЕДАЧЕЙ ДАННЫХ

0

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

подобных сообщений (от СУБД или оперативного приложения к станции пользователя). Передача таких сообщений происходит под управлением еще одного программного компонента — диспетчера передачи данных.

Диспетчер передачи данных не является частью СУБД; он представляет собой автономную систему со своими правами. Однако, поскольку очевидно, что от диспетчера передачи данных и СУБД требуется согласованная совместная работа, они иногда рассматриваются как равноправные компоненты программного  продукта более высокого уровня, называемого системой базы данных и передачи данных (DataBase/Data-Communications — DB/DC). В такой системе СУБД отвечает за работу с базой данных, а диспетчер передачи данных обрабатывает все сообщения, поступающие в СУБД и из нее (точнее, поступающие в то приложение, в котором используется СУБД, и из него). Однако в этой книге мы можем рассмотреть лишь относительно небольшой объем информации об  обработке сообщений (поскольку такая обширная тема вполне заслуживает самостоятельного обсуждения). В разделе 2.12 кратко рассматриваются  вопросы  передачи данных между отдельными системами (т.е. между отдельными компьютерами в сети передачи данных, подобной Internet), но это действительно отдельная тема.

2.6.         АРХИТЕКТУРА "КЛИЕНТ/СЕРВЕР"

В предыдущих разделах этой главы подробно обсуждалась так называемая архитектура ANSI/SPARC для систем баз данных. Ее упрощенная схема приведена на рис. 2.3. В настоящем разделе мы будем изучать базы данных с несколько иной точки зрения.

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

описанных ниже двух частей — сервера (внутреннего компонента, или машины базы данных) и клиентов (внешних компонентов, или внешних интерфейсов), как показано на рис. 2.5.

1.  Сервер— это сама СУБД. Он поддерживает все основные функции СУБД, кото рые обсуждались в разделе 2.8, а именно: определение данных, манипулирование данными, защиту данных, поддержание целостности данных и т.д. В частности, он предоставляет полную поддержку  внешнего,  концептуального и  внутреннего уровней, обсуждавшихся в разделе 2.8. Поэтому сервер в этом контексте — это просто другое название для СУБД.

2.  Клиенты — это различные приложения, которые выполняются с помощью СУБД. Таковыми являются как приложения, написанные пользователями, так и встро енные приложения, предоставляемые поставщиками СУБД или некоторыми сто ронними поставщиками программного обеспечения. Конечно, в самом сервере разница между встроенными  приложениями и  приложениями,  написанными пользователем, не обнаруживается, поскольку все эти приложения используют один и тот же интерфейс сервера, а именно интерфейс внешнего уровня, который уже рассматривался в разделе 2.3. (Некоторые специальные "служебные" прило жения могут оказаться исключениями. Как упоминалось выше, в разделе 2.5, они иногда работают непосредственно на внутреннем уровне системы. Подобные ути литы правильнее относить к встроенным компонентам СУБД, а не к приложениям в обычном смысле. В следующем разделе утилиты обсуждаются более подробно.)

Рис. 2.5. Архитектура "клиент/сервер"

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

■      Приложения,    написанные    пользователями.    В    основном,    это    обычные прикладные программы, чаще всего написанные либо на языке  программирования общего    назначения,    таком    как    C++    или    COBOL,    либо    на    одном    из специализированных языков четвертого поколения, хотя в обоих случаях эти языки должны как-то связываться с соответствующим подъязыком данных (см. раздел 2.3).

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

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

а) Процессоры языков запросов.

б) Генераторы отчетов.

в) Графические бизнес-подсистемы.

г) Электронные таблицы.

д) Процессоры команд на естественных языках.

е) Статистические пакеты.

ж) Средства управления копированием или средства извлечения данных, з)

Генераторы приложений (включая процессоры языков четвертого поколения).

и) Другие средства разработки приложений, включая CASE-инструменты (CASE, или Computer-Aided Software Engineering — автоматизированное проектирование и создание программ) и т.д.

к) Инструментальные средства интеллектуального анализа данных и визуализации.

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

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

Распределенная обработка предполагает, что отдельные компьютеры можно  соединить какой-нибудь коммуникационной сетью так, чтобы выполнение одной задачи обработки данных можно было распределить на несколько  компьютеров этой сети. Как показала практика, эта возможность настолько заманчива по различным соображениям (главным  образом,  экономическим),  что  термин  "клиент/сервер"  стал  применяться почти исключительно в тех случаях, когда клиенты и сервер действительно находятся на разных компьютерах. Более подробно распределенная обработка данных рассматривается ниже, в разделе 2.12.

2.7.   

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии