Лекция 2. Функции на СУБД. Типова организация на СУБД. Примери

2.1.4. Журнализация

Ясно, е че във всеки случай за възстановяването на БД трябва да е на разположение някаква допълнителна информация. С други думи, поддържането на надежността на съхраняването на данни в БД изисква излишност на съхраняването на данни, при това тази част от данните, която се използва за възстановяване, трябва да се съхранява особено надеждно. Най-разпространеният метод за поддържане на такава излишна информация е воденето на журнал на измененията в БД.

Журналът – това е особена част от БД, недостъпна за потребителите на СУБД и поддържана особено щателно (понякога се поддържат две копия на журнала, разполагани на различни физически дискове), в които постъпват записи за всички изменения в основната част на БД. В различните СУБД измененията на БД се журнализират на различни нива: понякога записът в журнала съответствува на някаква логическа операция по изменение на БД (например, операция за изтриване на ред от таблица на релационна БД), понякога - минимална вътрешна операция за модификация на страница от външната памет; в някои системи едновременно се използват двата подхода.

Във всички случаи се прилага стратегията "изпреварващ" запис в журнала (така наречения протокол Write Ahead Log - WAL). Най-общо, тази стратегия се състои в това, че запис за измененията на кой да е обект на БД трябва да попадне във външната памет на журнала преди измененият обект да попадне във външната памет на основната част на БД. Известно е, че ако в СУБД коректно се съблюдава протоколът WAL, то с помощта на журнала може да се решат всички проблеми по възстановяването на БД след кой да е сбой.

Най-простата ситуация на възстановяване е индивидуалният откат на транзакция. Строго погледнато, за това не е необходим общосистемен журнал на измененията в БД. Достатъчно е за всяка транзакция да се поддържа локалния журнал на операциите за модификация на БД, изпълнени в тази транзакция, и да се проведе откат на транзакцията чрез изпълнение на обратни операции, следвайки от края на локалния журнал. В някои СУБД така се и прави, но в повечето системи не се поддържат локални журнали, а индивидуален откат на транзакция се изпълнява по общосистемния журнал, за което всички записи от една транзакция се свързват чрез обратен списък (от края към началото).

При мек сбой във външната памет на основната част на БД може да има обекти, модифицирани от транзакции, незавършили към момента на сбоя, и може да отсъстват обекти, модифицирани от транзакции, които към момента на сбоя успешно са завършили (поради използване на буфери на оперативната памет, съдържимото на които при мек сбой пропада). При съблюдение на протокола WAL във външната памет на журнала трябва гарантирано да има записи, отнасящи се до операциите модификация на двата вида обекти. Целта на процеса на възстановяване след мек сбой е състоянието на външната памет на основната част на БД, което би възникнало при фиксация във външната памет на измененията на всички завършили транзакции и което не би съдържало никакви следи от незавършени транзакции. За да се постигне това, отначало се извършва откат на незавършените транзакции (undo), а след това повторно се възпроизвеждат (redo) тези операции на завършилите транзакции, резултатите от които не са изобразени във външната памет. Този процес съдържа много тънкости, свързани с общата организация на управление на буферите и журнала.

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

2.1.5. Поддържане на езици за БД

В съвременните СУБД обикновено се поддържа единен интегриран език, съдържащ всички необходими средства за работа с БД, започвайки от нейното създаване, и осигуряващ базовия потребителски интерфейс с базите от данни. Стандартен език за най-разпространените в днешно време релационни СУБД е езикът SQL (Structured Query Language). Ще изброим основните функции на релационната СУБД, поддържани на "езиково" ниво (т.е. функции, поддържани при реализация на интерфейса на SQL).

Езикът SQL съчетава средствата на SDL и DML, т.е. позволява да се определя схемата на релационната БД и да се манипулира с данните. При това именуването на обектите на БД (за релационната БД – именуване на таблици и стълбовете им) се поддържа на езиково ниво в този смисъл, че компилаторът на езика SQL извършва преобразуване на имената на обектите в техни вътрешни идентификатори на основата на специално поддържани служебни таблици - каталози. Вътрешнната част на СУБД (ядрото) въобще не работи с имената на таблици и стълбовете им.

Езикът SQL съдържа специални средства за определяне ограниченията за целостта на БД. Отново, ограниченията за целостта се съхраняват в специални таблици-каталози, и осигуряването на контрола за цялост на БД се извършва на езиково ниво, т.е. при компилацията на операторите за модификация на БД компилаторът на SQL на основата на наличните в БД ограничения за цялост генерира съответния програмен код.

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

Накрая, авторизацията на достъпа до обектите на БД се извършва също на основата на специален набор оператори на SQL. Идеята се състои в това, че за изпълнение на различните видове оператори на SQL потребителят трябва да има различни права. Потребител, създал таблица на БД, притежава пълен набор пълномощия за работа с тази таблица. Сред тези пълномощия е и пълномощието за предаване на всички или някои пълномощия на други потребители, включително и пълномощието за предаване на пълномощия. Пълномощията на потребителите се описват в специални таблици-каталози, контролът на пълномощията се поддържа на езиково ниво.

2.2. Типова организация на съвременна СУБД

Естествено е организацията на типична СУБД и съставът на нейните компоненти да съответствува на набора от функции:

• 
  управление на данните във външната памет;
  
• 
  управление на буферите на оперативната памет;
  
• 
  управление на транзакциите;
  
• 
  журнализация и възстановяване на БД след сбой;
  
• 
  поддържане на езици за БД.
  

Логически в една съвременна релационна СУБД може да отделим най-вътрешна част – ядрото на СУБД (често го наричат Data Base Engine), компилатор на езика за БД (обикновено SQL), подсистема за поддержане времето на изпълнение, набор утилити. В някои системи тези части изпъкват, в други - не, но логически такова разделение може да се извърши във всички СУБД.

Ядрото на СУБД отговаря за управлението на данните във външната памет, управлението на буферите на оперативната памет, управление на транзакции и журнализация. Съответно, може да се отделят такива компоненти на ядрото (поне логически, макар, че в някои системи тези компоненти се отделят явно), като мениджър на данните, мениджър на буферите, мениджър на транзакциите и мениджър на журнала. Както се разбра от първата част на тази лекция, функциите на тези компоненти са взаимосвързани, и за осигуряване на коректната работа на СУБД всички тези компоненти са длъжни да взаимодействуват по щателно обмислени и проверени протоколи. Ядрото на СУБД има собствен интерфейс, недостъпен за потребителите директно и използван в програмите, произвеждан от компилатора на SQL (или в подсистемата за поддържане на изпълнението на такива програми) и утилитите на БД. Ядрото на СУБД е основна резидентна част на СУБД. При използване на архитектурата "клиент-сървър" ядрото е основна съставляваща на сървърната част на системата.

Основната функция на компилатора на езика на БД е компилация на операторите на езика на БД в изпълняваната програма. Основен проблем на релационните СУБД е този, че езиците на тези системи (а това, като правило е SQL) са непроцедурни, т.е. в оператор на такъв език се специфицира някакво действие над БД, но тази спецификация не е процедура, а само описва в някаква форма условието за извършване на желаемо действие (спомнете си примерите от първата лекция). Затова компилаторът трябва да реши, по какъв начин да изпълнява оператора на езика, преди да произведе програмата. Използват се достатъчно сложни методи за оптимизация на операторите, които ние подробно ще разгледаме в следващите лекции. Резултат от компилацията е изпълнявана програма, представяна в някои системи в машинни кодове, но по-често в изпълняем вътрешен машинно-независим код. В последния случай реалното изпълнение на оператора се извършва с привличане на подсистема за поддържане на времето за изпълнение, представляващо, по своята същност, интерпретатор на този вътреншен език.

Накрая, в отделните утилити на БД обикновено изпъкват такива процедури, които твърде тежко се изпълняват с използване на език за БД, например, зареждане и разтоварване на БД, събиране на статистика, глобална проверка на целостта на БД и т.н. Утилитите се програмират с използване на интерфейса на ядрото на СУБД, а понякога даже с проникване вътре в ядрото.

2.3. Пример: System R

Основните цели на разработчиците на System R били следните:

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

Структурната организация на System R напълно се съгласува с поставените при нейната разработка цели. Основните структурни компоненти на System R са системата за управление на релационната памет (Relational Storage System - RSS) и компилаторът на заявки на езика SQL. RSS осигурява интерфейса на много ниско, но достатъчно за реализация на SQL ниво за достъп до съхраняваното в базата от данни. Синхронизацията на транзакциите, журнализацията на измененията и възстановяването на базите от данни след сбой също се отнасят към функциите на RSS. Компилаторът на заявките използува интерфейса на RSS за достъп до разнообразна справочна информация (каталози на отношенията, на индексите, на правата на достъп, на условия за цялостност, условни въздействия и т.н.) и произвежда работни програми, изпълнявани по-нататък също с използване на интерфейса на RSS. По такъв начин, системата естествено се разделя на две нива – ниво на управление на паметта и синхронизацията, фактически, не зависеща от базовия език на заявките на системата, и езиково ниво (ниво на SQL), на което се решават повечето проблеми в System R. Тази независимост е по-скоро условна, отколкото абсолютна: езикът SQL може да се замени с друг език, но той трябва да има такава семантика.

Каталог: tadmin -> upload -> storage
storage -> Литература на факта. Аналитизъм. Интерпретативни стратегии. Въпроси и задачи
storage -> Лекция №2 Същност на цифровите изображения Въпрос. Основни положения от теория на сигналите
storage -> Лекция 5 система за вторична радиолокация
storage -> Толерантност и етничност в медийния дискурс
storage -> Ethnicity and tolerance in media discourse revisited Desislava St. Cheshmedzhieva-Stoycheva abstract
storage -> Тест №1 Отбележете невярното твърдение за подчертаните думи
storage -> Лекции по Въведение в статистиката
storage -> Търсене на живот във вселената увод
storage -> Еп. Константинови четения – 2010 г някои аспекти на концептуализация на богатството в руски и турски език

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

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