Централизация процессов обработки данных позволила устранить такие недостатки, как несвязность, противоречивость и избыточность данных в информационной системе, обеспечила возможность комплексно решать вопросы стандартизации в представлении данных, обеспечения санкционированного доступа к ним и др. Однако по мере роста БД использование их в территориально разнесенных организациях привело к тому, что централизованная СУБД, находящаяся в узле телекоммуникационной сети, обеспечивающей доступ пользователей из территориально разнесенных пунктов к хранимым данным, стала плохо справляться с ростом числа обрабатываемых транзакций в связи с большим потоком обмена данными между терминалами и центральной ЭВМ. Такая ситуация привела к снижению надежности и общей производительности системы при обработке запросов пользователей. Поэтому была предложена идея децентрализации процессов обработки данных в информационных системах для организаций, подразделения которых разнесены. И хотя децентрализация данных затрудняет решение таких вопросов, как обеспечение целостности и непротиворечивости данных, их безопасности, тем не менее она позволяет повысить производительность обработки, улучшить использование данных на местах и снизить затраты на их обработку.
Основной довод в пользу распределения обработки – данные используются в одном периферийном подразделении и редко или вообще никогда не применяются в других подразделениях организации. Может также оказаться, что частота обновления данных слишком высока, и их выгоднее хранить и обрабатывать на местах возникновения, чем использовать централизованно. Распределение обработки также удобно при большом числе операций поиска и манипулирования со вторичными ключами. Такие данные лучше размещать в периферийной системе, и пользователи сами будут следить за их хранением и использованием.
|
|
Но существует ряд факторов, естественным образом приводящих к необходимости централизации данных. Например, если данные используются централизованными приложениями (например, такими, как снабжение или производственное управление); пользователям во всех подразделениях требуются одни и те же данные, причем эти данные часто обновляются; система должна обрабатывать запросы, для которых данные, возникающие в различных подразделениях, рассматриваются в логическом плане как одно целое; имеется большой объем данных общего назначения; необходима защита данных; пользователи определенных данных часто перемещаются с места на место и др.
В одной и той же системе одни данные могут быть централизованными, а другие – децентрализованными. Поэтому основная задача, которую приходится решать при проектировании распределенной БД, – это распределение данных по сети. Существуют следующие способы ее решения:
в каждом узле сети хранится и используется собственная БД, однако хранимые в ней данные доступны для других узлов сети;
все данные распределенной БД полностью дублируются в каждом узле сети;
хранимые в центральном узле сети данные частично дублируются в тех периферийных узлах, в которых они интенсивно используются.
Децентрализованная обработка данных помимо задачи распределения их по сети выдвигает ряд новых требований по сравнению с централизованной:
|
|
1) распределенные БД могут быть однородными или неоднородными в смысле используемых в системе технических и программных средств (СУБД), поэтому должна быть решена проблема преобразования структур данных и ПП;
2) чтобы обеспечивать пользователю логическую прозрачность данных по всей базе, необходима единая концептуальная схема для всей сети, содержащая информацию о местонахождении данных в сети;
3) должен быть решен вопрос о декомпозиции запроса пользователя на отдельные составные части, которые могут пересылаться для выполнения в разные узлы сети в зависимости от места хранения данных и складывающейся на момент обработки запроса операционной обстановки в сети (при этом должна быть обеспечена координация процессов обработки);
4) необходимо обеспечить синхронизацию процессов обновления и обработки копий данных, защиту данных и их восстановление, управление словарями данных и т.д.
Рассмотрим архитектуру однородных распределенных БД. Для описания информационной структуры всей сети используется интерфейс КМД – глобальная сетевая концептуальная схема, или сетевая метамодель данных. Для обеспечения работы внешних пользователей вводится интерфейс внешней модели, который называется внешней схемой сети и благодаря которому пользователи могут писать запросы, не интересуясь реальным распределением данных в сети.
В каждом узле сети имеется локальная общая схема (одна для каждого узла), содержащая кроме описания локальных данных, хранимых в этом узле, описание данных, хранимых в других узлах, используемых ПП и пользователями в данном узле. Для реализации запроса его схема транслируется в так называемую общую схему (в которой уже присутствует информация о размещении требуемых данных по сети) и начинается его выполнение.
Система управления базой данных любого узла сети хранит локальные данные и выполняет в этом узле требуемые операции над ними. Поступивший запрос декомпозируется на составные операции (подзапросы), строится план перемещения и обработки подзапросов в сети и начинается пересылка подзапросов в соответствующие локальные СУБД для выполнения. СУБД узла, выполнив поступивший подзапрос, полученный результат выдает в сеть. После поступления ответов на все подзапросы формируется окончательный ответ.