Составители:
Рубрика:
:&:#*%)K* :(*AK & +($5(!%%)$
-%*#$A&F*:,&* ,$%+@*,:K :!+(
5@!"! 5
прикладных программ (ПП) к различным СУБ Д на основе языка SQL. Из ПП обращение проис ходит к
виртуальной СУБД, в которой с по мощью драйверов осуществляется переход к реальной СУБ Д.
%:,38.
5.D.001. B:?1 5:0016 (%X
O).
В крупных АС, построенных на основе корпоративных
сетей, не всегда удается организовать централизованное размещение всех баз данных и СУБД на од-
ном узле сети. Поэтом у появляются ")+0"$-$4$**.$ 2)6. -)**.,.
При построении РБД приходится решать ряд сложных проблем, связанных с минимизацией тра-
фика, обе спечением интероперабельности обработки данных и целостности данных.
L'*'/'6)='9 &")E'%) нужна в связи с тем, что при обслуживании запроса могут потребова ться
данные из многих узлов, пересылаемые по сети. Возможности минимизации видны из примера обрабо т-
ки данных неск о льких таб лиц из разных узлов. Очевидно, что целесообразна о днократная пересылка таб-
лиц (причем таб лиц именно меньшег о раз мера) на о дин узел, на которо м и будет обрабатыв аться запрос.
D*&$"#0$")2$45*#+&5 выражает способность взаимодействия программ, работающих в гетеро-
генных сетях (в разных операционных средах или с разными СУБД). Интероперабельность обеспечи-
вается или с помощью программ-шлюзов (конверторов) для каждой пары взаимодействующих сред,
или с помощью единого унифицированного языка взаимодействия. Таким языком для доступа к БД
является язык SQL, интероперабельность на его основе имеет место в системе ODBC (Open Data Base
Connectivity), пример реализации которой показан на рис. 5.5. В примере СУБ Д FoxPro находится в
локальном узле, а СУБ Д Ingres и
Informix – в удаленных узлах.
Прикладная программа имеет
ОDBC-интерфейс, не зависимый
от о собенностей различных
СУБД. Менеджер драйверов реа-
лизует на базе унифицированно-
го языка SQL все нюансы досту-
па к БД, общие для разных
СУБД. Драйвер конкретной
СУБД преобразует инвариантные к СУБД запросы в форму, принятую в данной СУБД. В трехзвенной
структуре менеджер драйверов может быть размещен ан промежуточном сервере.
Обеспечение целостности в РБД намного сложнее, чем в одноузловых БД. Различают два подхо-
да к построению РБД: 1) тиражирование (репликация), при котором на нескольких серверах (узлах)
сети расположены копии БД; 2) полномасштабная распределенность, при которой разные части БД на-
ходятся на разных серверах сети (классическая распределенность).
Применяют два способа тиражирования.
Способ, называемый репликацией первой копии, основан на выделении среди серверов с копи-
ями БД одного первичного сервера (репликатора). Вне сение изменений пользователями возможно
только в БД первичного сервера, который в дальнейшем осуществляет тиражирование. ?'")@'"#()-
*'$ — это перенос изменений БД из первичного сервера во все вторичные (локальные) серверы, кото-
рые используются клиентами только для чтения данных. Репликатор реагирует на события, фиксиру-
емые триггерами, периодически пересылает обновленные данные в копии БД. Недостаток способа —
невысокая надежность, присущая любым централизованным структурам.
Надежность повышается при использовании способа голосования. Здесь изменения посылают-
ся не в один первичный, а в некоторые N серверов. При этом любой запро с на чтение направляется к
некоторым M серверам, причем N+M > K, где K — общее число серверов. Принимается последняя по
времени обновления версия ответа.
Тиражирование вносит избыточность в хранимые данные, появляются трудности с разрешени-
ем конфликтов из-за возможных несогласованных изменений в локальных БД. Однако по сравнению
с классиче скими РБД, в которых данные не дублируются, заметно уменьшается т рафик, надежнее и
проще работа с локальными БД. Обеспечение надежности и удобства работы особенно актуально в
случае ненадежных и медленных каналов связи, что имеет место во многих сетях в России.
В классических распределенных СУБД (РСУБД) необходимо 70")(49&5 #-*#("$/$**./ -#+&7-
&.+.)$(*),$". !"#$%!#&'&($"!))$* +($*,#&($"!)&*
138
%+,. 5.5. Структура ODBC
5@!"! 5 :&:#*%)K* :(*AK & +($5(!%%)$-%*#$A&F*:,&* ,$%+@*,:K :!+(
прикладных программ (ПП) к различным СУБД на основе языка SQL. Из ПП обращение происходит к
виртуальной СУБД, в которой с помощью драйверов осуществляется переход к реальной СУБД.
%:,38.5.D.001. B:?1 5:0016 (%XO). В крупных АС, построенных на основе корпоративных
сетей, не всегда удается организовать централизованное размещение всех баз данных и СУБД на од-
ном узле сети. Поэтому появляются ")+0"$-$4$**.$ 2)6. -)**.,.
При построении РБД приходится решать ряд сложных проблем, связанных с минимизацией тра-
фика, обеспечением интероперабельности обработки данных и целостности данных.
L'*'/'6)='9 &")E'%) нужна в связи с тем, что при обслуживании запроса могут потребоваться
данные из многих узлов, пересылаемые по сети. Возможности минимизации видны из примера обработ-
ки данных нескольких таблиц из разных узлов. Очевидно, что целесообразна однократная пересылка таб-
лиц (причем таблиц именно меньшего размера) на один узел, на котором и будет обрабатываться запрос.
D*&$"#0$")2$45*#+&5 выражает способность взаимодействия программ, работающих в гетеро-
генных сетях (в разных операционных средах или с разными СУБД). Интероперабельность обеспечи-
вается или с помощью программ-шлюзов (конверторов) для каждой пары взаимодействующих сред,
или с помощью единого унифицированного языка взаимодействия. Таким языком для доступа к БД
является язык SQL, интероперабельность на его основе имеет место в системе ODBC (Open Data Base
Connectivity), пример реализации которой показан на рис. 5.5. В примере СУБД FoxPro находится в
локальном узле, а СУБД Ingres и
Informix – в удаленных узлах.
Прикладная программа имеет
ОDBC-интерфейс, не зависимый
от особенностей различных
СУБД. Менеджер драйверов реа-
лизует на базе унифицированно-
го языка SQL все нюансы досту-
па к БД, общие для разных
%+,. 5.5. Структура ODBC
СУБД. Драйвер конкретной
СУБД преобразует инвариантные к СУБД запросы в форму, принятую в данной СУБД. В трехзвенной
структуре менеджер драйверов может быть размещен ан промежуточном сервере.
Обеспечение целостности в РБД намного сложнее, чем в одноузловых БД. Различают два подхо-
да к построению РБД: 1) тиражирование (репликация), при котором на нескольких серверах (узлах)
сети расположены копии БД; 2) полномасштабная распределенность, при которой разные части БД на-
ходятся на разных серверах сети (классическая распределенность).
Применяют два способа тиражирования.
Способ, называемый репликацией первой копии, основан на выделении среди серверов с копи-
ями БД одного первичного сервера (репликатора). Внесение изменений пользователями возможно
только в БД первичного сервера, который в дальнейшем осуществляет тиражирование. ?'")@'"#()-
*'$ — это перенос изменений БД из первичного сервера во все вторичные (локальные) серверы, кото-
рые используются клиентами только для чтения данных. Репликатор реагирует на события, фиксиру-
емые триггерами, периодически пересылает обновленные данные в копии БД. Недостаток способа —
невысокая надежность, присущая любым централизованным структурам.
Надежность повышается при использовании способа голосования. Здесь изменения посылают-
ся не в один первичный, а в некоторые N серверов. При этом любой запрос на чтение направляется к
некоторым M серверам, причем N+M > K, где K — общее число серверов. Принимается последняя по
времени обновления версия ответа.
Тиражирование вносит избыточность в хранимые данные, появляются трудности с разрешени-
ем конфликтов из-за возможных несогласованных изменений в локальных БД. Однако по сравнению
с классическими РБД, в которых данные не дублируются, заметно уменьшается трафик, надежнее и
проще работа с локальными БД. Обеспечение надежности и удобства работы особенно актуально в
случае ненадежных и медленных каналов связи, что имеет место во многих сетях в России.
В классических распределенных СУБД (РСУБД) необходимо 70")(49&5 #-*#("$/$**./ -#+&7-
&.+.)$(*),$" . !"#$%!#&'&($"!))$* +($*,#&($"!)&* 138
Страницы
- « первая
- ‹ предыдущая
- …
- 136
- 137
- 138
- 139
- 140
- …
- следующая ›
- последняя »
