Фиктивные элементы (фантомы). 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Фиктивные элементы (фантомы).



Неповторяемое считывание.

Фиктивные элементы (фантомы).

Собственно несовместимый анализ.

Проблема несовместимого анализ-

Проблема несовместимого анализа возникает в том случае, если одна из транзакций в

силу длительности выполнения застает часть данных в одном состоянии (неизмененными), а

часть в другом (уже измененными).

Неповторяемое считывание
Транзакция A дважды читает одну и ту же строку. Между этими чтениями вклинивается транзакция B, которая изменяет значения в строке.

Фиктивные элементы (фантомы)
Транзакция A дважды выполняет выборку строк с одним и тем же условием. Между выборками вклинивается транзакция B, которая добавляет новую строку, удовлетворяющую условию отбора..

Собственно несовместимый анализ
Длинная транзакция выполняет некоторый анализ по всей таблице, например, подсчитывает общую сумму денег на счетах клиентов банка для главного бухгалтера. Пусть на всех счетах находятся одинаковые суммы, например, по $100. Короткая транзакция в этот момент выполняет перевод $50 с одного счета на другой так, что общая сумма по всем счетам не меняется.

3)Методы организации данных в оперативной памяти при работе

Наиболее известные запоминающие устройства, используемые в персональных компьютерах: модули оперативной памяти (ОЗУ), жёсткиедиски (винчестеры), дискеты (гибкие магнитные диски), CD- или DVD-диски, а также устройства флеш-памяти.
Оперативная память и адресные пространства процессора

Оперативная память – это основная память, на работу с которой ориентирован процессор, точнее программа, выполняемая процессором. Это адресная память.

В большинстве ЭВМ оперативная память – энергозависимая. Это означает, что при выключении питания информация в оперативной памяти не сохраняется. Для сохранения информации при выключении питания содержимое оперативной памяти переписывают в энергонезависимую память, например, на основе записи на магнитную поверхность. Это вторичная (внешняя) память на магнитных дисках (память прямого доступа) или на магнитных лентах (архивная память).

Удаленный вызов процедур

Удалённый вызов процедур (или Вызов удалённых процедур)— класс технологий,позволяющих компьютерным программамвызывать функции или процедуры в другом адресном пространстве (как правило, на удалённых компьютерах). Обычно, реализация RPC технологии включает в себя два компонента: сетевой протокол для обмена в режиме клиент-сервер и язык сериализации объектов (или структур, для необъектных RPC). Различные реализации RPC имеют очень отличающуюся друг от друга архитектуру и разнятся в своих возможностях: одни реализуют архитектуру SOA, другие CORBA или DCOM. На транспортном уровне RPC используют в основном протоколы TCP и UDP, однако, некоторые построены на основе HTTP (что нарушает архитектуру ISO/OSI, так как HTTP изначально не транспортный протокол).

Идея вызова удалённых процедур состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. Средства удалённого вызова процедур предназначены для облегчения организации распределённых вычислений и создания распределенных клиент-серверных информационных систем. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удалёнными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.

Характерными чертами вызова удалённых процедур являются:

Асимметричность, то есть одна из взаимодействующих сторон является инициатором;

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

Реализация удалённых вызовов существенно сложнее реализации вызовов локальных процедур. Можно обозначить следующие проблемы и задачи, которые необходимо решить при реализации RPC:

Так как вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины находятся под управлением различных операционных систем или имеют различную архитектуру (например, используется прямой или обратный порядок байтов). Так как RPC не может рассчитывать на разделяемую память, то это означает, что параметры RPC не должны содержать указателей на ячейки нестековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Для копирования параметров процедуры и результата выполнения через сеть выполняется их сериализация.

В отличие от локального вызова удалённый вызов процедур обязательно использует транспортный уровень сетевой архитектуры (например TCP), однако это остается скрытым от разработчика.

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

Существует ряд проблем, связанных с неоднородностью языков программирования и операционных сред: структуры данных и структуры вызова процедур, поддерживаемые в каком-либо одном языке программирования, не поддерживаются точно так же во всех других языках. Таким образом имеется проблема совместимости, до сих пор не решённая ни с помощью введения одного общепринятого стандарта, ни с помощью реализации нескольких конкурирующих стандартов на всех архитектурах и во всех языках.

10)Как выполняется откат транзакции.

ОТКАТ ТРАНЗАКЦИИ (rollback, transaction rollback). Действия, выполняемые СУБД при обработке транзакций в том случае, когда успешного завершения транзакции не произошло. О. т. заключается в том, что отменяются результаты всех операций транзакции, а данные возвращаются в то исходное состояние, которое они имели до начала выполнения транзакции. О. т. может быть вызван различными причинами: 1) О. т. может быть выполнен по инициативе самой транзакции, например, если в процессе ее выполнения обнаруживается, что завершение транзакции приведет к нарушению целостности данных; 2) О. т. может быть вызван машинным сбоем в процессе выполнения транзакции; 3) О. т. может быть выполнен по инициативе СУБД для выхода из тупиковой ситуации. Ср. завершение транзакции

Понятие «Хранилище данных»

Хранилище данных — предметно-ориентированная информационная база данных, специально разработанная и предназначенная для подготовки отчётов и бизнес-анализа с целью поддержки принятия решений в организации. Строится на базе систем управления базами данных и систем поддержки принятия решений. Данные, поступающие в хранилище данных, как правило, доступны только для чтения. Данные из OLTP-системы копируются в хранилище данных таким образом, чтобы построение отчётов и OLAP-анализ не использовал ресурсы транзакционной системы и не нарушал её стабильность. Как правило, данные загружаются в хранилище с определённой периодичностью, поэтому актуальность данных может несколько отставать от OLTP-системы. Принципы организации хранилища Проблемно-предметная ориентация. Данные объединяются в категории и хранятся в соответствии с областями, которые они описывают, а не с приложениями, которые они используют. 1. Интегрированность. Данные объединены так, чтобы они удовлетворяли всем требованиям предприятия в целом, а не единственной функции бизнеса. 2. Некорректируемость. Данные в хранилище данных не создаются: т.е. поступают из внешних источников, не корректируются и не удаляются. 3. Зависимость от времени. Данные в хранилище точны и корректны только в том случае, когда они привязаны к некоторому промежутку или моменту времени.

16)Преимущества системы клиент – сервер перед системой с использованием файл – сервера.

Отличие архитектуры "клиент-сервер" от архитектуры "файл-сервер"

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

Сетевое многопользовательское приложение строится по принципу файл-серверной архитектуры. Данные в виде одного или нескольких файлов размещаются на файловом сервере. Файловый сервер принимает запросы, поступающие по сети от компьютеров-клиентов, и передает им требуемые данные. Однако обработка этих данных выполняется на компьютерах-клиентах. На каждом из компьютеров запускается полная копия процессора обработки данных Jet Engine. Любая копия Jet независимо управляет файлами MDB, содержащими данные. Единственная связь между этими независимыми действиями — файл блокировок (файл, который имеет имя, совпадающее с именем файла приложения, но с расширением Idb), который обязательно создается для каждого файла базы данных с расширением mdb. При этом каждая копия Jet выполняет изменения индексов, работу с системными таблицами и другие функции, входящие в компетенцию СУБД.

В архитектуре "клиент-сервер" сервер базы данных не только обеспечивает доступ к общим данным, но и берет на себя всю обработку этих данных. Клиент посылает на сервер запросы на чтение или изменение данных, которые формулируются на языке SQL. Сервер сам выполняет все необходимые изменения или выборки, контролируя при этом целостность и согласованность данных, и результаты в виде набора записей или кода возврата посылает на компьютер клиента.

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

Архитектура "клиент-сервер" позволяет устранить все указанные недостатки. Кроме того, она позволяет оптимальным образом распределить вычислительную нагрузку между клиентом и сервером, что также влияет на многие характеристики системы: стоимость, производительность, поддержку.

17)Понятие «Целостность хранимых в базе данных» Це́лостность ба́зы да́нных — соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам. Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных,называется ограничением целостности Примеры правил: вес детали должен быть положительным; количество знаков в телефонном номере не должно превышать 25; возраст родителей не может быть меньше возраста их биологического ребёнка и т.д.Задача аналитика и проектировщика базы данных — возможно более полно выявить все имеющиеся ограничения целостности и задать их в базе данных.Целостность БД не гарантирует достоверности содержащейся в ней информации, но обеспечивает по крайней мере правдоподобность этой информации, отвергая заведомо невероятные, невозможные значения. Таким образом, не следует путать целостность БД с достоверностью БД. Достоверность (или истинность) есть соответствие фактов, хранящихся в базе данных, реальному миру. Очевидно, что для определения достоверности БД требуется обладание полными знаниями как о содержимом БД, так и о реальном мире. Для определения целостности БД требуется лишь обладание знаниями о содержимом БД и о заданных для неё правилах. Поэтому СУБД может (и должна) контролировать целостность БД, но принципиально не в состоянии контролировать достоверность БД. Контроль достоверности БД может быть возложен только на человека, да и то в ограниченных масштабах, поскольку в ряде случаев люди тоже не обладают полнотой знаний о реальном мире.Итак, БД может быть целостной, но не достоверной. Возможно и обратное: БД может быть достоверной, но не целостной. Последнее имеет место, если правила (ограничения целостности) заданы неверно.

18)Сопоставление технологии блокировок с технологией тиражирования. Тиражирование данных - это асинхронный перенос изменений объектов исходной базы данных (source database) в БД, принадлежащим различным узлам распределенной системы. Функции DR выполняет специальный модуль СУБД - сервер тиражирования данных, называемый репликатором (replicator). Его задача - поддержка идентичности данных в принимающих базах данных (target database) данным в исходной БД. Сигналом для запуска репликатора служит срабатывание некоторого правила.

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

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

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

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

1.уровень 0 – запрещение "загрязнения" данных. Этот уровень требует, чтобы изменять данные могла только однатранзакция; если другой транзакции необходимо изменить те же данные, она должна ожидать завершения первойтранзакции;

2.уровень 1 – запрещение "грязного" чтения. Если транзакция начала изменение данных, то никакая другаятранзакция не сможет прочитать их до завершения первой;

3.уровень 2 – запрещение неповторяемого чтения. Если транзакция считывает данные, то никакая другая транзакцияне сможет их изменить. Таким образом, при повторном чтении они будут находиться в первоначальном состоянии; 4.уровень 3 – запрещение фантомов. Если транзакция обращается к данным, то никакая другая транзакция не сможет добавить новые или удалить имеющие строки, которые могут быть считаны при выполнении транзакции. Реализация этого уровня блокирования выполняется путем использования блокировок диапазона ключей. Подобная блокировканакладывается не на конкретные строки таблицы, а на строки, удовлетворяющие определенному логическому условию.

19)Основные правила работы распределенной системы, к выполнению которых следует стремиться при её создании. В результате развития локальных и глобальных сетей сегодня не просто возможно, но и достаточно легко можно собрать компьютерную систему, состоящую из множества компьютеров, соединенных высокоскоростной сетью. Она обычно называется компьютерной сетью, или распределенной системой, в отличие от предшествовавших ей централизованных, или одно процессорных, систем, состоявших из одного компьютера, его периферии и, возможно, нескольких удаленных терминалов. Распределенная система — это набор независимых компьютеров, представляющийся их пользователям единойВ этом определении оговариваются два момента. Первый относится к аппаратуре: все машины автономны. Второй касается программного обеспечения: пользователи думают, что имеют дело с единой объединенной системой.

системой. Важны оба момента. Позже в этой главе мы к ним вернемся, но сначала рассмотрим некоторые базовые вопросы, касающиеся как аппаратного, так и программного обеспечения. Возможно, вместо того чтобы рассматривать определения, разумнее будет сосредоточиться на важных характеристиках распределенных систем. Первая из таких характеристик состоит в том, что от пользователей скрыты различия между компьютерами и способы связи между ними. То же самое относится и к внешней организации распределенных систем. Другой важной характеристикой распределенных систем является способ, при помощи которого пользователи и приложения единообразно работают в распределенных системах, независимо от того, где и когда происходит их взаимодействие. Распределенные системы должны также относительно легко поддаваться расширению, или масштабированию. Эта характеристика является прямым следствием наличия независимых компьютеров, но в то же время не указывает, каким образом эти компьютеры на самом деле объединяются в единую систему. Распределенные системы обычно существуют постоянно, однако некоторые их части могут временно выходить из строя. Пользователи и приложения не должны уведомляться о том, что эти части заменены или починены или что добавлены новые части для поддержки дополнительных пользователей или приложений.Для того чтобы поддержать представление различных компьютеров и сетей в виде единой системы, организация распределенных систем часто включает в себя дополнительный уровень программного обеспечения, находящийся между верхним уровнем, на котором находятся пользователи и приложения, и нижним уровнем, состоящим из операционных систем. Соответственно, такая распределенная система обычно называется системой промежуточного уровня. 20)Особенности обработки распределенных запросов. Особенности оптимизации запросов в распределенных реляционных СУБД В самой общей постановке задачей компонента распределенной СУБД, оптимизирующего выполнение глобального запроса, является генерация множества альтернативных планов выполнения запроса и выбора из этого множества на основе некоторых критериев одного плана, на основе которого и производится выполнение запроса. Как видно, в такой общей постановке задача оптимизации глобальных запросов формулируется точно так же, как и в случае локальной СУБД. Однако, решение этой задачи для распределенных систем с локальной автономностью узлов существенно более сложное, чем для локальных СУБД. Для определенности мы будем рассматривать подход к обработке глобальных запросов, основанный на их предварительной компиляции. Этот подход используется, например, в System R* [93] и состоит в том, что фазы порождения выполняемого плана глобального запроса и его реального выполнения разнесены во времени. Это является естественным развитием подхода System R и позволяет, например, заранее откомпилировать программу с включением глобальных запросов на языке SQL, а затем много раз выполнять ее без необходимости каждый раз вырабатывать планы выполнения запросов. В результате компиляции запроса в System R*, инициированной в некотором узле сети, на самом деле порождается распределенная программа выполнения этого запроса, причем она и хранится в распределенной форме. В каждом узле сети, локальная база данных которого содержит отношения, затрагиваемые запросом, хранится часть распределенной программы, под управлением которой производятся доступ к локальным данным этого узла и взаимодействия с другими узлами, содержащими части той же распределенной программы. Выполнение запроса начинается с запуска "главной" части распределенной программы, хранящейся в том узле, в котором инициировалась компиляция запроса ("главном" узле). Эта программа путем сетевого взаимодействия вызывает другие части распределенной программы, хранящиеся в "дополинительных" узлах и т.д. Результат выполнения запроса формируется в главном узле, хотя промежуточные результаты могут быть распределены между другими локальными базами данных. В System R* распределенная программа - это программа в машинных кодах IBM/370, но в данном случае, в контексте оптимизации запросов, для нас это не важно: программа могла бы порождаться и на некотором промежуточном языке и интерпретироваться при своем выполнении. Такой подход также практически применяется. Примером системы может быть распределенный вариант СУБД INGRES [91]. Задача оптимизации запросов остается той же - необходимо построить оптимальный план выполнения запроса в условиях локальной автономности узлов сети. Распределенная обработка – это обработка с использованием централизованной базы данных, доступ к которой может осуществляться с различных компью­теров сети. Топология системы управления распределенной базой данных
Ключевым моментом в определении распределенной базы данных является утверждение, что система работает с данными, физически распределенными в сети. Если данные хранятся централизованно, то даже в том случае, когда доступ к ним обеспечивается для любого пользователя в сети, данная система просто поддерживает распределенную обработку, но не может рассматриваться как распределенная СУБД 21)Графики запуска транзакций График запуска набора транзакций называется последовательным, если транзакции выполняются строго по очереди, т.е. элементарные операции транзакций не чередуются друг с другом..
Если график запуска набора транзакций содержит чередующиеся элементарные операции транзакций, то такой график называется чередующимся.
При выполнении последовательного графика гарантируется, что транзакции выполняются правильно.
Два графика называются эквивалентными, если при их выполнении будет получен один и тот же результат, независимо от начального состояния базы данных.График запуска транзакции называется верным (сериализуемым), если он эквивалентен какому-либо последовательному графику. График запуска набора транзакций – это последовательность, в которой выполняются элементарные операции заданного набора транзакций. График запуска набора транзакций называется ПОСЛЕДОВАТЕЛЬНЫМ, если транзакции выполняются строго по очереди, т.е. элементарные операции транзакций не чередуются друг с другом.Два графика называются эквивалентными, если при их выполнении и одном и том же начальном состоянии базы будет получен один и тот же результат.Если график набора транзакций содержит чередующиеся элементарные операции, то такой график называется чередующимся.
График запуска транзакций называется верным (сериализуемым), если он эквивалентен
какому-либо последовательному графику. 22)Понятие о «Data Mining» Data Mining (рус. добыча данных, интеллектуальный анализ данных, глубинный анализ данных) — собирательное название, используемое для обозначения совокупности методов обнаружения в данных ранее неизвестных, нетривиальных, практически полезных и доступных интерпретации знаний, необходимых для принятия решений в различных сферах человеческой деятельности. Английское словосочетание «Data Mining» пока не имеет устоявшегося перевода на русский язык. При передаче на русском языке используются следующие словосочетания[4]: просев информации, добыча данных, извлечение данных, а, также, интеллектуальный анализ данных Более полным и точным является словосочетание «обнаружение знаний в базах данных» (knowledge discovering in databases, KDD).Основу методов Data Mining составляют всевозможные методы классификации, моделирования и прогнозирования, основанные на применении деревьев решений,искусственных нейронных сетей, генетических алгоритмов, эволюционного программирования, ассоциативной памяти, нечёткой логики. К методам Data Mining нередко относят статистические методы (дескриптивный анализ, корреляционный и регрессионный анализ, факторный анализ, дисперсионный анализ, компонентный анализ,дискриминантный анализ, анализ временных рядов). Такие методы, однако, предполагают некоторые априорные представления об анализируемых данных, что несколько расходится с целями Data Mining (обнаружение ранее неизвестных нетривиальных и практически полезных знаний).

Одно из важнейших назначений методов Data Mining состоит в наглядном представлении результатов вычислений, что позволяет использовать инструментарий Data Mining людьми, не имеющих специальной математической подготовки. В то же время, применение статистических методов анализа данных требует хорошего владениятеорией вероятностей и математической статистикой. 23)Управление каталогом в распределенных базах данных Основные принципы РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:каждый узел — это полноценная СУБД сама по себе;Узлы взаимодействуют между собой таким образом, что пользователь любого из них может получить доступ к любым данным в сети так, как будто они находятся на его собственном узле. Каждый узел сам по себе является системой базы данных. Любой пользователь может выполнить операции над данными на своём локальном узле точно так же, как если бы этот узел вовсе не входил в распределённую систему. Распределённую систему баз данных можно рассматривать как партнёрство между отдельными локальными СУБД на отдельных локальных узлах. Фундаментальный принцип создания распределённых баз данных («правило 0»): Для пользователя распределённая система должна выглядеть так же, как нераспределённая система.Фундаментальный принцип имеет следствием определённые дополнительные правила или цели. Таких целей всего двенадцать: 1.Локальная независимость. Узлы в распределённой системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом. 2.Отсутствие опоры на центральный узел. Локальная независимость предполагает, что все узлы в распределённой системе должны рассматриваться как равные. Поэтому не должно быть никаких обращений к «центральному» или «главному» узлу с целью получения некоторого централизованного сервиса. 3.Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности. 4.Независимость от расположения. Пользователи не должны знать, где именно данные хранятся физически и должны поступать так, как если бы все данные хранились на их собственном локальном узле. 5.Независимость от фрагментации. Система поддерживает независимость от фрагментации, если данная переменная-отношение может быть разделена на части или фрагменты при организации её физического хранения. В этом случае данные могут храниться в том месте, где они чаще всего используются, что позволяет достичь локализации большинства операций и уменьшения сетевого трафика. 6.Независимость от репликации. Система поддерживает репликацию данных, если данная хранимая переменная-отношение — или в общем случае данный фрагмент данной хранимой переменной-отношения — может быть представлена несколькими отдельными копиями или репликами, которые хранятся на нескольких отдельных узлах. 7.Обработка распределённых запросов. Суть в том, что для запроса может потребоваться обращение к нескольким узлам. В такой системе может быть много возможных способов пересылки данных, позволяющих выполнить рассматриваемый запрос. 8.Управление распределёнными транзакциями. Существует 2 главных аспекта управления транзакциями: управление восстановлением и управление параллельностью обработки. Что касается управления восстановлением, то чтобы обеспечить атомарность транзакции в распределённой среде, система должна гарантировать, что все множество относящихся к данной транзакции агентов (агент — процесс, который выполняется для данной транзакции на отдельном узле) или зафиксировало свои результаты, или выполнило откат. Что касается управления параллельностью, то оно в большинстве распределённых систем базируется на механизме блокирования, точно так, как и в нераспределённых системах. 9.Аппаратная независимость. Желательно иметь возможность запускать одну и ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины участвовали в работе распределённой системы как равноправные партнёры. 10.Независимость от операционной системы. Возможность функционирования СУБД под различными операционными системами. 11.Независимость от сети. Возможность поддерживать много принципиально различных узлов, отличающихся оборудованием и операционными системами, а также ряд типов различных коммуникационных сетей. 12.Независимость от типа СУБД. Необходимо, чтобы экземпляры СУБД на различных узлах все вместе поддерживали один и тот же интерфейс, и совсем необязательно, чтобы это были копии одной и той же версии СУБД. Фактически, распределенная база данных – это совокупность логически взаимосвязанных баз данных, распределенных в компьютерной сети. Системы управления распределенными базами данных называются РСУБД – некая программная система, которая обеспечивает управление распределенной базой данных и обеспечивает прозрачность ее использования для всех клиентов.Главная задача таких баз данных – обработка распределенных данных. При этом в общем случае считается, что данные находятся на компьютерах различных моделей и производителей, функционирующих под управлением различных операционных систем, и доступ к ним осуществляется разнородным программным обеспечением, а территориально сами компьютеры могут быть удалены друг от друга и находиться в различных точках планеты.

 

Распределенные СУБД классифицируют на гомогенные и гетерогенные системы. В гомогенных системах все узлы используют один и тот же тип СУБД, например Oracle, а в гетерогенных системах могут функционировать различные СУБД.

24) Методы поддержки параллельной работы в СУБД Одним из основных требований к современным СУБД является поддержка мульти режима транзакций, который означает возможность одновременной обработки в СУБД нескольких транзакций с доступом к одним и тем же данным в одно и то же время. Как известно, в такой системе для корректной обработки транзакций без возникновения конфликтных ситуаций необходимы методы контроля выполнения параллельных транзакций. Без использования таких методов в СУБД могут возникать такие ситуации, как потеря результатов обновления, грязное чтение, неповторяющееся чтение и фантомы. В реализации метод управления параллельными транзакциями определяет поведение планировщика. Основная задача планировщика заключается в своевременном обнаружении и разрешении конфликтов между выполняющимися транзакциями. После того как конфликт был обнаружен, СУБД должна выбрать метод его разрешения. По методамразрешения конфликтов планировщики можно разделить на те, которые используют в качестве основного метода разрешения конфликтов блокировки, те, которые откатывают одну из конфликтующих транзакций и, наконец, те, которые используют версионные механизмы для разрешения конфликтов. Двухфазный протокол синхронизации Двухфазный протокол синхронизации (Two Phase Locking, 2PL) использует блокировки для разрешения конфликтов между конкурентными транзакциями. Этот протокол достаточно широко применяется в коммерческих СУБД. Протокол, основанный на временных метках Согласно этому протоколу, каждая транзакция п



Поделиться:


Последнее изменение этой страницы: 2017-02-17; просмотров: 218; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 34.227.191.136 (0.045 с.)