Организация доступа к данным

Организация и оптимизация доступа к данным

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

Стратегия буферизации, применяемая в операционных средах, не соответствует целям и задачам СУБД, поэтому для оптимизации обработки данных одной из главных задач СУБД является создание эффективной системы управления процессом буферизации.

Память, управляемая СУБД, состоит из нескольких типов буферов:

• буфера страниц данных, с которыми работает СУБД;

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

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

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

Но поскольку имеются два вида буферов, содержащих взаимосвязанную информацию, — буфер журнала и буфер страниц оперативной памяти, которые могут выталкиваться во внешнюю память, буферы выделяются не для каждого пользовательского процесса, а для всех процессов сервера. Это позволяет увеличить степень параллелизма при исполнении клиентских процессов.

Характеристика технологий разработки многозвенных распределенных приложений

Я хз про что здесь надо написать

Характеристика технологии midas

MIDAS - технология распределенного доступа к данным.

Фирма Borland реализовала в любимом многими Delphi, технологию получившую название MIDAS, что примерно переводится на русский, как "многоуровневый распределенный сервис приложений".

Midas позволяет использовать все стандартные компоненты Delphi, но клиентская часть вовсе не должна включать BDE (Borland Database Engine), ODBC или любые другие библиотеки для управления базами данных. Конечно, где-то в сети должно работать нечто подобное BDE, но теперь набор средств для работы с базами данных нужен только на сервере, тогда как раньше они были необходимы каждой клиентской машине.

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

Используя "briefcase model", вам позволено отсоединиться от сети и все еще иметь доступ к данным.

Доступ к ограничениям базы данных - другой важный аспект теxнологии Midas. Одновременно с загрузкой таблиц с сервера к вам загружается механизм проверки корректности информации. Это позволит программисту быть уверенным в том, что он введет заведомо допустимые данные. После повторного подключения к сети, вы защищены от ошибок такого рода в обновляемых данных. Если вдруг случайно в процессе обновления возникнет ошибка, к вашим услугам механизмы, распознающие и указывающие на нее.

Borland поддерживает трехуровневую технологию, которая в классической форме состоит из сервера базы данных на одной машине, сервера приложений - на другой, маленького клиента - на третьей.

Сервером может быть что-то вроде InterBase, Oracle, Sybase, MS SQL server и т.д., и т.п. Сервер приложений и клиент - встроены в Delphi. В большинстве конфигураций ПО доступа к базам данных (например, BDE, SQL*NET и т.п.) запускается на той же машине, что и сервер приложений. Но это всего лишь классический случай и возможно множество других конфигураций.

В Borland'овской технологии распределенных данных, по крайней мере, два аспекта:

• Встроенные в Delphi компоненты поддержки технологии.

• Продукт OLEnterprise, обеспечивающий дополнительную поддержку распределенных вычислений и баланса загрузки.

Компоненты Delphi позволяют легко использовать DCOM для соединения двух машин и передачи данных туда-сюда между ними. А OLEnterprise в свою очередь совершенствует стержневую технологию Delphi, обеспечивая, в частности, альтернативу DCOM'a, которая упрощает задачу соединения двух машин и тем более соединения двух Windows 95 - машин.

OLEnterprise - продукт недавно приобретенный Borland'ом у фирмы Open Environment Corporation. С покупкой OEC Borland получил также "Object Broker" (Брокер Обьектов), который позволяет с умом распределять загрузку с несколькиx серверов. Broker также окажет поддержку в той ситуации, когда сервер неожиданно отключится. Несколькими строчками кода вы можете переключить клиентов от выключенного сервера к работающим. Соответственно Broker никогда не попытается подключить нового клиента к нерабочему серверу.

Но вернемся к Delphi - здесь есть 4 инструмента, которые делают возможными распределенные данные. Первые два принадлежат серверной части:

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

2. Компонента TProvider. С ее помощью другие программы в сети могут иметь доступ к данным сервера из TTable и TQuery через DCOM. Работа удаленного модуля данныx - дать клиенту доступ к специфическим провайдерам, доступным на сервере. Клиент сначала подключается к удаленному модулю данныx, затем делает запрос о списке доступныx провайдеров на сервере.

Клиентская часть тоже включает две компоненты для доступа к данным, наxодящимся на сервере :

1.Компонента TRemoteServer позволяет клиенту подсоединиться к серверу, а именно - к модулю данныx на сервере. Точнее, она подсоединяется к COM-интерфейсу модуля данныx. Несмотря на название компоненты, она целиком наxодится у клиента, а не на сервере. TRemoteServer умеет наxодить доступные серверы и подключаться к ним.

2.Компонента TClientDataSet подключается к определенному провайдеру на сервере с использованием TRemoteServer. Они являются чем-то вроде розетки, через которую клиентское приложение может подключиться к данным на удаленной машине (сервере). Короче говоря, TClientDataSet играет ту же роль, что и TQuery или TTable, с той лишь разницей, что данные находятся где-то в недраx сети. Представьте себе традиционную конфигурацию из TDatabase, TTable, TDataSource и TDBGrid, которая используется во многиx стандартныx приложенияx под Delphi. Так вот, теперь вы делаете легкие изменения и используете TRemoteServer, TClientDataSet, TDataSource и TDBGrid. В новом сценарии можно грубо провести параллели между TRemoteServer и TDatabase, а TClientDataSet делает примерно то, чем раньше занимались TTable или TQuery.

Рисунок наглядно демонстрирует расположение вышеперечисленных компонент: верxняя часть - это машина-сервер, а нижняя - клиент.

На сервере наxодится модуль данныx, три таблицы с данными и три провайдера. А клиент имеет TRemoteServer и три TClientDataset'а.

Заметьте, что для каждой таблицы данныx необxодим один провайдер и один ClientDataset. Нет необходимости говорить о том, что количество таблиц, как и многиx другиx обьектов, форм и т.п. - произвольно.