2. Архитектура баз данных. Логическая и физическая независимость данных. Схема прохождения запросов к бд. Классификация моделей данных. Архитектура и модели "клиент-сервер" в технологии бд.
Архитектура БД имеет 3-хуровневую систему:
Внешний уровень — определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, необходимые ему. #: система статистки продаж исп. сведения о реальных объемах продаж, но ее не интересуют инфа о менеджерах, осущ. продажи.
Концептуальный уровень — обобщающее представление БД, центральное управляющее звено. Отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась БД. Этот уровень описывает то, какие данные хранятся в БД, а также связи, существующие между ними:
все сущности, их атрибуты и связи;
накладываемые на данные ограничения;
семантическая инфа о данных (метаданные?);
инфа об обеспеч. безоп. и поддержке целостности.
Внутренний уровень — физическое представление БД в ЭВМ. Описывает, как инфа хранится в БД.
Независимость от данных — изменения на нижних уровнях не влияют на верхние уровни. [Осн. назнач. трехуровневой архитектуры.] 2 типа:
Логическая независимость — защищенность внешних схем от изменений, вносимых в концептуальную схему (возмож. изм. одного приложения без корректировки др. приложений, работающих с этой же БД).
Физическая независимость — защищенность концептуальной схемы от изменений, вносимых во внутреннюю схему (возмож. передачи инфы между носителями при сохранении работоспособности всех приложений, работающих с БД).
Схема прохождения запросов к БД:
Пользователь посылает запрос на получ. данных.
Анализ прав юзера и его внеш. модели данных подтверждает или запрещает доступ к данным.
При запрете доступа к данным СУБД сообщает пользователю об этом и прекращает дальнейший процесс обработки данных; иначе СУБД определяет часть концептуальной модели, затрагиваемую запросом пользователя.
СУБД получ. инфу о необх. части концепт. модели.
СУБД запрашивает инфу о расположении данных на физич. уровне (файлы или физич. адреса).
В СУБД возвращается инфа о местоположении данных в терминах ОС.
СУБД обращается к средствам ОС для предоставления необходимых данных.
ОС пересылает данные в системный буфер.
ОС сообщает СУБД об окончании пересылки.
СУБД выбирает из буфера нужную инфу и пересылает в рабочую область пользователя.
* БМД — база метаданных, в кот. хранится вся инфа об исп-мых структ. данных, их логич. организации, правах доступа юзеров, физич. расположении данных.
Описанный процесс прохождения запроса не всегда выполняется полностью. Современные СУБД обладают средствами оптимизации выполнения запросов.
Данные — набор конкретных значений, параметров, хар-зующих объект, условие, ситуацию или любые другие факторы. Данные ≠ информация. Данные становятся инфой тогда, когда им задают опред. структуру (придают им смысловое содержание).
Модель данных — абстракция, приложенная к конкр. данным, позволяет трактовать их как инфу — сведения, содерж. данные и взаимосвязь между ними.
Тезаурусные модели осн. на принципе организ. словарей, содержат опред. языковые конструкции и принципы их взаимод. в заданной грамматике.
Дескрипторные модели — самые простые из документальных, широко использовались на ранних стадиях их использования. В этих моделях каждому документу соотв. дескриптор — описатель, имеющий жесткую структуру и описывающий документ. Обработка информации в таких БД происх. по дескрипторам, т. е. по параметрам, хар-зующим документ, а не по самому тексту документа.
Теоретико-графовые модели отражают совокуп. объектов реального мира в виде графа взаимосвязанных инф-ных объектов. В зависимости от типа графа выделяют иерархическую или сетевую модели. В настоящий момент используются реже, чем более соврем. реляционная модель данных (РМД), но до сих пор сущ. системы, работающие на их основе.
Модель «клиент-сервер» — архитектура ПО, кот. опис. распределение процесса вып-я по принципу взаимодействия 2-х процессов, один из кот. — «клиент», другой — «сервер». Клиентский процесс запраш. услуги, серверный процесс обеспеч. их вып. Один сервер может обслужить множество клиентов.
Осн. принцип модели заключается в разделении ф-ий станд. интерактив. прилож. на 3 части (архитектура?):
Представление (Presentation Logic).
Обработка (Business Logic).
Хранение (Data manipulation Logic) и данные (Data).
В зависимости от распределения этих функций между клиентом и сервером различают 4 модели «клиент-сервер» в технологии БД.
В модели файлового сервера (File Server, FS) представление и обработка располагаются на клиенте. На сервере располагаются файлы с данными, и поддерживается доступ к файлам. Клиент обращается к серверу с файловыми командами, а механизм управ. всеми инф-ными ресами (БМД) находится на клиенте.
Достоинства — разделение ф-ий клиента и сервера, возмож. доступа к файлам одновр. многим юзерам.
К недостаткам модели можно отнести:
высокий сетевой трафик (пересылаются файлы целиком, даже если полезной явл. только 1 строка);
узкий спектр операций манипулир. с данными, который определяется файловыми командами;
отсутствие средств безопасности доступа к данным (только на уровне файловой системы).
Отличием модели удаленного доступа к данным (Remote Data Access, RDA) от предыдущей явл. расположение ядра СУБД на сервере. Представление и обработка расположены также на стороне клиента.
Достоинства — сокращ. трафика, по сети передается только полезная инфа, опред. юзером с помощью языка структурир. запросов (Structured Query Language), которая выделяется из файлов на сервере СУБД.
Недостатки:
высокий сетевой трафик (запросы SQL могут сильно загрузить сеть);
дублирование кода приложений (запросы на получение одних и тех же данных присутствуют в виде копий в различных приложениях);
пассивный сервер.
Модель сервера БД (Database Server, DBS) поддерж. большинством соврем. СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server. Основу модели составляет механизм хранимых процедур как средство программир. SQL-сервера, механизм триггеров как механизм отслеж. текущего состояния инф-ного хранилища и механизм ограничений на польз. типы данных (механизм поддержки доменной структуры).
Бизнес-логика разделена между клиентом и сервером. На сервере реализ. в виде спец. модулей, кот. хранятся в БД и управляются непоср. СУБД. Клиент обращается к серверу с командой запуска процедуры, сервер вып. ее и регистрир. изм-ния в БД. Клиенту возвращ. данные, релевантные его запросу, требуемые для вывода или вып. части бизнес-логики, кот. расположена на нем. Трафика тратится еще меньше.
Сервер активный; используя механизм триггеров, мб инициатором обработки данных.
Процедуры и триггеры хранятся в словаре БД, могут быть использованы несколькими клиентами, что уменьшает дублирование алгоритмов обработки данных в разных клиентских приложениях.
Недостаток модели — сильная загрузка сервера, т. к. на него перекладывается большая часть бизнес-логики, предназнач. для обработки данных. Это одновременно явл. плюсом — требования к клиентам гораздо меньше. Модель также наз. моделью с «тонким» клиентом. Увелич. надежность и защищенность приложений.
Для разгрузки модели была предложена 3-хуровневая модель сервера приложений (Application Server, AS) — расширение 2-хуровневой. Промежуточный уровень между клиентом и сервером содержит сервера приложений (1 или больше).
Разделение ф-ий выражено сильнее всего, т. к. они располож. на отдельных компьютерах: представление нах. на клиенте, обработка — на серверах приложений (промежуточ. ур.?), данные — на сервере БД.
Модель более гибкая, чем 2-хуровневые. Наиболее заметны ее преимущества в случаях, когда клиенты выполняют сложные аналитические расчеты над БД, которые относятся в области OLAP-приложений (On-line analytical processing). Переносимость системы и масштабируемость повышены за счет изолирования большей части бизнес-логики от возмож. расшир. SQL, реализованного в конкр. СУБД (бизнес-логика мб вып. на стандартных языках программир. — C++, Java, …).
