Архитектуры баз данных. Архитектура клиент-сервер. Распределенные бд.
Архитектура базы данных
Наиболее часто используется модель, предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД:
1.Уровень внешних моделей — самый верхний уровень, где каждая модель имеет свое «видение» данных. Этот уровень определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению.
2.Концептуальный уровень — центральное управляющее звено, здесь база данных представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически концептуальный уровень отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов реального мира.
3.Физический уровень — собственно данные, расположенные в файлах или в страничных структурах, расположенных на внешних носителях информации.
Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными. Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных. Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с данной базой данных. Это именно то, чего не хватало при использовании файловых систем.
Выделение концептуального уровня позволило разработать аппарат централизованного управления базой данных.
Интерфейсы доступа к БД
С СУБД можно следующими способами:
путём прямого программного доступа на собственном языке СУБД или на языке разработчиков СУБД с использованием их библиотек;
с помощью готовых приложений СУБД, использующих прямой доступ;
через стандартизованный язык баз данных, интерпретируемый средствами СУБД;
через интерфейс уровня обращения, позволяющий динамически встраивать инструкции языка баз данных в собственные приложения;
с помощью трансляции статически встроенных в код приложения инструкций языка баз данных перед компиляцией приложений;
через библиотеки классов, экземпляры которых, создаваемые в приложениях, автоматически загружаются и сохраняются в БД;
с помощью утилит, которые облегчают использование этих библиотек путём преобразования классов в логические объекты БД и обратно;
посредством программ промежуточного уровня, реализующих интерфейс уровня обращения и предоставляющих для разработчиков приложений свой (объектный) интерфейс.
через Web-интерфейс (в виде страниц языков разметки), предоставляемый либо CGI-приложениями (промежуточного уровня), либо самой СУБД.
Двухуровневые архитектуры клиент-сервер.
Двухуровневая модель фактически является результатом распределения пяти указанных функций между двумя процессами, которые выполняются на двух платформах: на клиенте и на сервере. В чистом виде почти никакая модель не существует, однако рассмотрим наиболее характерные особенности каждой двух уровневой модели.
Модель удаленного управления данными. Модель файлового сервера
Модель удаленного управления данными также называется моделью файлового сервера (File Server, FS). В этой модели презентационная логика и бизнес-логика располагаются на клиенте. На сервере располагаются файлы с данными и поддерживается доступ к файлам. Функции управления информационными ресурсами в той модели находятся на клиенте.
В этой модели файлы базы данных хранятся па сервере, клиент обращается к серверу с файловыми командами, а механизм управления всеми информационными ресурсами, собственно база мета-данных, находится на клиенте.
Достоинства этой модели в том, что мы уже имеем разделение монопольного приложения на два взаимодействующих процесса. При этом сервер {серверный процесс) может обслуживать множество клиентов, которые обращаются к нему с запросами. Собственно СУБД должна находиться в этой модели на клиенте.
Запрос клиента формулируется в командах ЯМД. СУБД переводит этот запрос в последовательность файловых команд. Каждая файловая команда вызывает перекачку блока информации на клиента, далее на клиенте СУБД анализирует полученную информацию, и если в полученном блоке не содержится ответ на запрос, то принимается решение о перекачке следующего блока информации и т.д. Перекачка информации с сервера на клиент производится до тех пор, пока не будет получен ответ на запрос клиента.
Недостатки:
-высокий сетевой трафик, который связан с передачей по сети множества блоков и файлов, необходимых приложению;
-узкий спектр операций манипулирования с данными, который определяется только файловыми командами;
-отсутствие адекватных средств безопасности доступа к данным (защита только на уровне файловой системы).