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