Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
|
№35 Распределенная база данных (DDB – Distributed DataBase) – это совокупность множества взаимосвязанных БД, распределенных в компьютерной сети. БД распределена физически, но логически едина (имеет общую схему данных). В системах с распределенными БД используются разные технологии распределения данных по узлам сети – фрагментация и тиражирование. При использовании фрагментации единая логическая БД разбивается на составные части (фрагменты), хранящиеся в разных узлах сети. Разбиение может проводиться по территориальному, функциональному и временному критериям. При использовании тиражирования в нескольких узлах сети создаются и поддерживаются в согласованном состоянии (синхронизируются) копии всей БД или ее фрагментов. Копия БД называется репликой. В системах с централизованной БД (много клиентов/один сервер) проблемы управления БД решаются просто, поскольку вся она хранится на сервере. В системах с распределенной БД проектирование, реализация запросов и управление представляют собой сложные задачи. Однако такие системы обеспечивают большую гибкость, надежность и быстродействие. Технологии распределения данных видоизменяют преимущества и недостатки систем. Одно из преимуществ БД – сокращение дублирования – теряется при использовании тиражирования. При этом сохраняются возможности контроля целостности данных для всей системы. Ведущими поставщиками СУБД сформулированы следующие свойства идеальной системы управления распределенными БД: · прозрачность относительно расположения данных – СУБД должна представлять все данные так, как если бы они были локальными; · гетерогенность системы – СУБД должна работать с данными, которые хранятся в системах с различной архитектурой и производительностью; · прозрачность относительно сети – СУБД должна одинаково работать в условиях разнородных сетей; · поддержка распределенных запросов – пользователь должен иметь возможность объединять данные из любых баз, даже размещенных в разных системах; · поддержка распределенных изменений – пользователь должен иметь возможность изменять данные в любых базах, на доступ к которым у него есть права; · поддержка распределенных транзакций – СУБД должна выполнять транзакции, выходящие за рамки одной вычислительной системы, и поддерживать целостность БД при возникновении отказов как в системах, так и в сети; · безопасность – СУБД должна обеспечивать защиту всей распределенной БД от несанкционированного доступа; · универсальность доступа – СУБД должна обеспечивать единую методику доступа ко всем данным. Ни одна из существующих СУБД не достигает этого идеала поскольку: · низкая и несбалансированная производительность сетей снижает общую производительность обработки в распределенных транзакциях; · обеспечение целостности данных в распределенных транзакциях базируется на принципе «все или ничего» и требует специального протокола, что приводит к длительной блокировке изменяемых данных; · необходимо обеспечить совместимость данных, для хранения которых в разных системах используются разные форматы и кодировки; · если каталог хранится в одной системе, то удаленный доступ будет замедлен; если будет размножен – изменения придется синхронизировать; · необходимо обеспечить совместимость СУБД разных типов и поставщиков; · велика потребность в ресурсах для обнаружения и устранения тупиковых ситуаций в распределенных транзакциях. |
№36 В архитектуре «файл-сервер» средства организации и управления БД (в том числе СУБД) располагаются на машине клиента, а БД, представляющая собой набор специализированных файлов, – на машине-сервере. В этом случае серверная компонента представлена даже не средствами СУБД, а сетевыми составляющими ОС, обеспечивающими удаленный разделяемый доступ к файлам. Запрос к БД, сформулированный на языке манипулирования данными, преобразуется СУБД в последовательность команд ввода-вывода, которые обрабатываются операционной системой машины-сервера. Недостатки архитектуры: · высокая загрузка сети и машин-клиентов, так как обмен идет на уровне единиц информации файловой системы (физических записей, блоков, файлов); · низкий уровень защиты данных, так как доступ к файлам БД управляется общими средствами ОС сервера; · бизнес-правила функциональной обработки, сосредоточенные в клиентской части, могут быть противоречивыми. Для схемы характерно наибольшее суммарное время обработки информации. |
№37 В архитектуре «файл-сервер» средства организации и управления БД (в том числе СУБД) располагаются на машине клиента, а БД, представляющая собой набор специализированных файлов, – на машине-сервере. В этом случае серверная компонента представлена даже не средствами СУБД, а сетевыми составляющими ОС, обеспечивающими удаленный разделяемый доступ к файлам. Запрос к БД, сформулированный на языке манипулирования данными, преобразуется СУБД в последовательность команд ввода-вывода, которые обрабатываются операционной системой машины-сервера. Недостатки архитектуры: · высокая загрузка сети и машин-клиентов, так как обмен идет на уровне единиц информации файловой системы (физических записей, блоков, файлов); · низкий уровень защиты данных, так как доступ к файлам БД управляется общими средствами ОС сервера; · бизнес-правила функциональной обработки, сосредоточенные в клиентской части, могут быть противоречивыми. Для схемы характерно наибольшее суммарное время обработки информации. |
№38 В архитектуре «активный сервер баз данных» (рис. 40) непротиворечивость бизнес-логики контролируется на стороне сервера. Функции бизнес-логики разделяются между клиентской и серверной частями. Общие функции оформляются в виде хранимых процедур. Вводится механизм триггеров, отслеживающих события БД. При возникновении события (обычно изменения данных) выполняется оператор SQL или вызывается хранимая процедура, связанная с триггером. Хранимые процедуры и триггеры могут быть использованы любыми клиентскими приложениями, работающими с БД. Это снижает дублирование программных кодов и исключает необходимость компиляции каждого запроса. Недостатком архитектуры становится возрастающая загрузка сервера. Такую архитектуру иногда называют моделью с тонким клиентом, в отличие от предыдущих архитектур, называемых моделью с толстым клиентом, где на стороне клиента выполняется большинство функций. Дальнейшее снижение уровня требований к ресурсам клиента достигается за счет введения сервера приложений, на который переносится значительная часть программных компонентов управления данными и большая часть бизнес-логики. При этом серверы БД обеспечивают исключительно функции СУБД Связь клиентских рабочих станций с прикладными программами на сервере приложений устанавливается через интерфейс API (Application Programming Interface). Работа клиентской части сводится к вызову функций сервера приложений. Прикладные программы обращаются к серверу БД с помощью SQL-запросов. К достоинствам трехзвенной архитектуры относятся: · многократное использование общих функций обработки данных в множестве клиентских приложений; · централизованное ведение бизнес-логики (при внесении изменений их не нужно тиражировать в клиентских приложениях); · на клиентских машинах не следует устанавливать компоненту программного обеспечения управления доступом к данным; · оптимизация доступа к БД (диспетчеризация запросов выполняется сервером приложений); · возможность отложенного обновления БД при изменении данных в автономном режиме (данные будут обновлены в БД при следующем соединении); · повышение скорости и надежности за счет дублирования ПО на нескольких серверах приложений, которые могут заменять друг друга; · перенос проверки полномочий пользователей с сервера БД на сервер приложений. · уменьшение мощности сервера приложений за счет параллельной работы сервера приложений и сервера БД. |