V.Разпределени БД и клиент/сървър системи

V.Разпределени БД и клиент/сървър системи

1.Разпределени БД

1.1.Обща характеристика

• 
  всяка страна е БД с пълни права;
  
• 
  отделните страни могат да работят съвместно, така че потребителите на една страна могат да имат достъп до данните в цялата мрежа.
  

Всяка страна има пълни права:

• 
  собствени локални реални БД;
  
• 
  собствени локални потребители;
  
• 
  собствена локална СУБД;
  
• 
  локална система за управление на транзакциите.
  

Така една РБД може да се разглежда като един вид партньорство между индивидуални локални СУБД, намиращи се в индивидуалните локални страни. Добавят се нови софтуерни компоненти, които реализират необходимите партньорски функции. Тези компоненти, комбинирани с класическата СУБД, образуват т.н. РСУБД.

Обикновено се приема, че отделните страни са разделени физически. Физическото разделение може да бъде локална (LAN) или глобална (WAN) мрежа. Тези разлики в преносната среда нямат голямо значение за РБД.

Допустимо е и логическо разделение, при което две страни (или повече) могат да са разположени физически върху една машина.

За да опростим разглежданията ще допуснем, че системата е хомогенна, т.е. всяка страна работи с копие на една и съща СУБД.

1.2.Предимства

Съвременните бизнес-процеси са разпределени:

• 
  логически - на отдели, направления, работни групи и т.н.;
  
• 
  физически - лаборатории, цехове, фабрики, райони;
  
• 
  данните също са разпределени - всяка организационна единица се нуждае от информация за собственото й функциониране;
  
• 
  РБД отразява структурата на бизнес-процесите - локалните данни се съхраняват локално, при необходимост глобалната информация се достига посредством отдалечен достъп.
  

• 
  ефективност на обработката - данните са запомнени близо до точката, където най-често се използват;
  
• 
  разширен достъп - възможно е да се достигнат от Пловдив сметки в София и обратно, посредством комуникационната мрежа.
  

1.3.Фундаментален принцип на разпределената обработка

За потребителя една разпределена база данни трябва да изглежда като неразпределена система.

Следователно потребителите на РБД трябва да се чувстват като в неразпределена среда, т.е.:

всички проблеми, които са свързани с комуникацията и партньорството трябва да се решават на ниско ниво, а не на външното (потребителското) ниво;

всички операции за обработка на данните трябва да останат логически непроменени;

операциите за дефиниране на данните изискват някои разширения в една разпределена система.

Фундаменталният принцип води до идентифицирането на следното множество от правила (често ги наричат обективности) за организация на РБД:

• 
  локална автономност;
  
• 
  не опора върху централната страна;
  
• 
  непрекъсната операция;
  
• 
  независимост от физическото местоположение;
  
• 
  фрагментационна независимост;
  
• 
  дублираща независимост;
  
• 
  разпределена обработка на заявки;
  
• 
  разпределена обработка на транзакции;
  
• 
  хардуерна независимост;
  
• 
  независимост от операционната система;
  
• 
  мрежова независимост;
  
• 
  независимост от СУБД.
  

Тези обективности:

• 
  не всички са взаимно независими;
  
• 
  не са от еднаква значимост;
  
• 
  те са полезни като основа за разбиране на разпределената технология;
  
• 
  могат да се използват като рамка за характеризиране на функционалността на конкретна разпределена система.
  

1.4.Дванадесетте обективности

1.4.1.Локална автономност

Страните в една разпределена система трябва да бъдат автономни. Локална автономност означава, че всички операции в дадена страна се контролират от нея, т.е. страна X не трябва да зависи от страна Y за успешното си функциониране.

От локалната автономност следва, че локалните данни са:

• 
  локална собственост;
  
• 
  локално управляеми;
  
• 
  локално изчислими.
  

Т.е. всички данни реално принадлежат към една и съща локална БД, дори когато могат да са достъпни от отдалечени страни. Такива проблеми като сигурност, цялостност и физическо представяне на локалните данни остават под контрола и юрисдикцията на локалната страна.

Локалната обективност не е напълно реализируема. Съществуват ситуации, в които дадена страна X трябва да допусне част от контрола на друга страна Y.

1.4.2.Не опора върху централната страна

От локалната автономност следва, че всички страни трябва да бъдат третирани като равнопоставени. Т.е. не трябва да се надяват на опора от някаква централна страна (master) за някакво централно обслужване. Напр., за централизирана обработка на заявки, централна обработка на транзакции, централизирано именуване, понеже цялата система е независима от централна страна.

Втората обективност е следствие от първата.

1.4.3.Непрекъснато опериране

Едно предимство на разпределените системи е, че те биха могли да доставят по-голяма достоверност и по-голяма наличност:

• 
  достоверност - (дефинира се като вероятността системата да е работеща във всеки момент) повишава се, защото разпределените системи могат да продължат да функционират (с редуцирана функционалност) в случай на срив или грешка в някои от индивидуалните компоненти (напр. някоя страна);
  
• 
  наличност - (дефинира се като вероятността, че системата е функционираща непрекъснато през един определен период) подобрява се също така частично по същите причини, частично поради възможността за дублиране на данните.
  

Тези проблеми са особено важни в случаите когато се появят непланирани shutdowns (срив от някакъв вид) в системата в определен момент. Непланираните shutdowns са нежелани, но не могат да се избегнат напълно. Трябва да се търси поне максималното им ограничение. Планираните shutdowns също не би трябвало да са желани, т.е. в идеалния случай системата не трябва да изисква своето прекъсване за извършване на планирани операции, такива като добавяне на нов участник, upgrading на СУБД или рестартиране на някое ниво.

1.4.4.Независимост от физическото местоположение

Основната идея на локационната независимост (позната също като прозрачност) е проста: потребителите не трябва да знаят къде физически са съхранени данните. Трябва само да могат да ги получават, все едно че те се съхраняват в локалната им страна.

Локационната независимост е желана, понеже тя опростява потребителските програми и терминалните активности. Така данните могат да мигрират от страна в страна без това да влияе на тези програми и активности. Така миграция е желателна, защото тя разрешава преместването на данните в мрежата в отговор на изисквания за промяна на производителността на системите.

1.4.5.Фрагментарна независимост

Една система поддържа фрагментиране на данните, при което дадена релация може да бъде декомпозирана на части (наречени сегменти) с цел физическото й съхраняване. Фрагментацията е желателна по следната причина: данните могат да се запомнят на места, които се използват много често, така че много от операциите да станат локални. Така се редуцира значително трафикът в мрежата.

1.4.6.Дубликираща независимост

Една система поддържа дубликиране на данните, ако една дадена релация (или фрагмент) може да се представи посредством множество отделни копия, съхраняване в различни страни в мрежата.

Дубликацията е желана по следните две причини:

• 
  по-добра производителност - отделните страни могат да работят с локалните копия вместо да търсят услугите на отдалечен достъп;
  
• 
  по-добра наличност - наличността се запазва докато съществува поне едно копие.
  

1.4.7.Разпределено управление на транзакциите

Съществуват два основни аспекти на управлението на транзакциите:

• 
  контрол на възстановяването;
  
• 
  контрол на конкурентността
  

всеки от които изисква разширено третиране на разпределената среда. За да обясним какво е разширено третиране ще въведем един ново понятие, това за агент.

В една разпределена система една отделна транзакция може да включва изпълнението на код върху много страни. В такива случаи казваме, че транзакцията се състои от няколко агента, където един агент е процесът, изпълнен от името на дадена транзакция върху една определена страна. Необходимо е системата да знае дали два агента са част на една и съща транзакция. Два агента, които са в една транзакция не трябва да изпадат в deadlock.

За контрола на възстановяването - за да се осигури, че една транзакция е неделима в една разпределена среда, системата трябва да осигури, че множеството на агентите за тази транзакция трябва съвместно да завършат работата си в commit или rollback – режим, т.е. различни режими за множеството не са допустими.

За контрола на конкурентността - този контрол в повечето системи се базира на блокировките (както е и в неразпределените системи).

1.4.8.Хардуерна независимост

Обикновено големите системи са хетерогенни (от хардуерна гледна точка). Те включват различни типове работни станции и персонални компютри. Необходимо е да се създадат възможности за интегриране на информацията, независимо от използваната техника.

1.4.9.Независимост от операционните системи

Тази обективност е следствие от предишната и тя не се нуждае от допълнителни обяснения. Щом се използват различни типове машини, тогава е очевидно, че ще се използват различни операционни системи, напр. за работните станции предимно UNIX, за персоналните компютри - основно Windows.

1.4.10.Мрежова независимост

Причините са аналогични на горепосочените.

1.4.11.Независимост от БД

Необходимо е използваните БД в системата да поддържат еднакви интерфейси. Това е достатъчно и не е необходимо всичките използвани БД да бъдат копия на една и съща БД. Напр., всички релационни БД поддържат стандарта SQL.

2.Клиент/сървър системи

2.1.Определение

Клиент/Сървър: разпределена система (специален случай на РБД), в която:

• 
  някои страни са означени като клиенти, а други - като сървъри;
  
• 
  всички данни са разположени върху сървърите;
  
• 
  всички приложения се изпълняват върху клиентите.
  

Клиентите и сървърите могат да работят върху различни машини (обикновения случай) или върху една машина (логически разделени).

2.2.Стандарти

Съществуват няколко стандарта за организиране на клиент/сървър обработка. Някои възможности са интегрирани в последните версии на SQL/92:

• 
  CONNECT - установява връзка със сървъра. Трябва да се изпълни преди да се даде заявка към БД. След като е установена връзката потребителят (клиентът) задава заявката както обикновено. Възможно един клиент да се свързва с повече от един сървъра;
  
• 
  DISCONNECT - разрушава връзката със сървъра.
  

Друг стандарт е даден в ISO Remote Data Access - дефинира формати и протоколи за клиент/сървър - комуникация. Предполага, че:

• 
  клиентът изразява заявки в стандартна SQL-форма;
  
• 
  сървърът поддържа стандартен каталог, също дефиниран в SQL/92. Там са дефинирани специфичните формати на изпращане на съобщенията (SQL заявки, данни и резултати, диагностична информация) между клиентите и сървъра. RDA работи с OSI, TCP/IP.
  

Третият стандарт е този на IBM - Distributed Relational Database Architecture (DRDA) - подобен на RDA. Различия:

• 
  не предполага, че клиентите използват стандартна версия на SQL, а че те използват някой диалект на SQL. Следствие от това е подобрената производителност (клиентът може да експлоатира някои специфични възможности на сървъра);
  
• 
  не се предполага определен каталог на сървъра;
  
• 
  като основен недостатък - намелена преносимост. Освен това DRDA предполага IBM-архитектура, докато RDA е независим от производителите на техника.
  

2.3.Клиент/Сървър приложно програмиране

Както споменахме, клиент/сървър системите са специален вид разпределени системи. При тях всички заявки произлизат от едната страна (клиент), а цялата обработка се извършва от другата страна (сървър). При тази дефиниция клиентът не е БД с пълните права. Възможно е клиентите да поддържат локални БД, но те не са директна част на клиент/сървър отношението.

Един от най-важните изводи, които могат да се направят за клиент/сървър подхода е, че релационните системи работят на ниво множество (set-level). Приложната част обикновено поддържа записен тип на информацията. Използването на заявки за всеки отделен запис ще намали съществено производителността на системата (размяна на много съобщения).

Как да се редуцира броят на съобщенията?

Създаване на някакъв вид т.нар. stored procedure механизъм. Eдна stored procedure е обикновено една прекомпилирана програма, която може да се съхранява при сървъра.

Бази данни (2004-2005)

Каталог: sites -> default -> files
files -> Образец №3 справка-декларация
files -> Р е п у б л и к а б ъ л г а р и я
files -> Отчет за разкопките на праисторическото селище в района на вуз до Стара Загора. Аор през 1981 г. ХХVІІ нац конф по археология в Михайловград, 1982
files -> Медии и преход възникване и развитие на централните всекидневници в българия след 1989 година
files -> Окръжен съд – смолян помагало на съдебния заседател
files -> Семинар на тема „Техники за управление на делата" 18 19 юни 2010 г. Хисар, Хотел „Аугуста спа" Приложение
files -> Чинция Бруно Елица Ненчева Директор Изпълнителен директор иче софия бкдмп приложения: програма
files -> 1. По пътя към паметник „1300 години България

Изтегляне 1.28 Mb.

Сподели с приятели: