Локальные БД

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

Рис. 1. Локальная архитектура БД

Системы управления базами данных, ориентированные на такую архитектуру, называют локальными или персональными. КР таких СУБД относят хорошо известные dвазе и его диалекты (Сlіррег, Рохрго, Раrаdох...).

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

Файл-серверные БД

Эффективная работа современного офиса невозможная без использования сотрудниками общей базы данных. Общность БД достигается ее установлением в локальной сети предприятия на специально для этого выделенный компьютер (сервер) при одновременном доступе к серверу нескольких компьютеров пользователей (клиентов).

При работе в архитектуре "Файл-сервер" БД и приложения размешены на файловом сервере сети (например Nowell Net Ware). Возможная многопользовательская работа с одной и той же БД, когда каждый пользователь с своего компьютера запускает приложения, размещенное на сетевом сервере. Тогда на компьютере пользователя запускается копия приложения. Данные в БД сохраняются в едином экземпляре, а каждый клиент в каждый момент времени работает с некоторой локальной копией этих данных. По каждому запросу приложения к БД данные из таблиц БД перегоняются на компьютер пользователя, независимо от того, сколько реально надо данных для выполнения запроса. После этого выполняется запрос. Каждый пользователь имеет на своем компьютере локальную копию данных, что время от времени обновляется в реальной БД, размещенной на сетевом сервере. При этом изменения, которое каждый пользователь вносит в БД, могут быть к определенному моменту неизвестные другим пользователям, которые делает актуальной задачу систематического обновления данных в компьютере пользователя с реальной БД.

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

В архитектуре "Файл-сервер" вся тяжесть выполнения запросов к БД и управления целостностью БД возлагается на пользовательские приложения. Именно они должны проявлять заботу о синхронизации локальных копий данных на каждом клиентском месте с содержимым основной (и единой) базы данных. То есть, БД на сервере есть пассивным источником данных. На рис.2 изображенная общая схема архитектуры "Файл-сервер'.

Рис.2. Общая схема архитектуры "Файл-сервер"

В походке эксплуатации таких систем были выявленные такие общие недостатки архитектуры файл-сервер:

• вся трудность вычислительной работы перекладывается на
компьютер клиента;

Например, если в результате запроса клиент должен получить 2 записи из таблицы объемом 100000 записей, все 100000 записей будут скопированы с файл-сервера на компьютер клиента; в результате повышается нагрузка сети (сетевой трафик) и увеличиваются требования к аппаратным мощностям компьютера пользователя.

• поскольку БД представляет собой набор файлов на сетевом сервере и доступ к таблицам регулируется лишь сетевой оперативной системой, это делает такую БД, в сущности, беззащитной от случайного или специального искажения информации, которая сохраняется в ней, ее уничтожения или разворовывания;

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

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

Дата добавления: 2014-01-15