Замисляли ли сте се колко често сте се сблъсквали с бази данни, без изобщо да се усетите колко са навлезли в практиката, до каква степен са ни необходими, полезни, и колко малко неща бихме могли да свършим без тях. Тук дори няма да използвам примери от пределектронната ера, защото са набиващи се на очи подобно на стена, в която току що сте се блъснали, тоест до болка. Ако все още не сте се сетили какво имам предвид, ще го кажа една дума - библиотека. Без хранилища за информация модерната цивилизация не би могла да се появи, поне не в този си вид. С годините, дейността по съхранението и каталогизацията на знанието се е развивала, основно с цел бърз и ефективен достъп. Неслучайно библиотечното дело е нещо, което все още се изучава. Но нека спрем дотук с хартията.
Малко история
В електронен вид, базите данни започват да си пробиват път още през шестдесетте години на двадесети век, в областта на въздушния транспорт. Авиокомпаниите са сред първите, които осъзнават предимствата на този начин за съхранение и използване на информацията, и започват да преориентират системите си за резервация към бъдещето. Естествено, останалите сфери на човешката дейност не остават по-назад, и бързо се забелязва раздвижване в банковото дело, корпоративните архиви и т.н.
Бумът в интеграцията на електронни бази данни обаче настъпва през седемдесетте, когато Тед Код разработва релационния модел. За разлика от йерархичния, където информацията е организирана в дървовидна структура с връзки между различните нива, разработката на Код се отличава със значително по-лесна за разбиране и употреба потребителска част. Самите данни са подредени в таблици, където всяка колона има име, подсказващо какво се съдържа в нейните полета. Редовете, които се наричат кортежи, пък са самите данни, които се съхраняват.
Освен значително по-натуралния подход към начина на представяне на данните, заедно с релационния модел се появява и език за заявки, който се отличава с голяма интуитивност. Това като цяло е разбираемо, като се вземе предвид, че до голяма степен заявките са близки до начина по-който бихме ги изразили на всеки човешки, вербален начин за комуникация. Общо взето, на SQL (structured query language), една заявка изглежда по следния начин: "избери тези колони от онази таблица, където е спазено даденото условие".
Както се досещате, подобно предимство, заедно със солидната математическа основа, стояща зад модела, бързо го превръщат в не най-предпочитания, но направо в единствения използван при големи бази данни за доста дълъг период от време. Естествено, остават някои по-дребни такива, където се съхраняват достатъчно малки по обем количества информация, при които не е фатално тя дори да не бъде структурирана. Но всичко това - релационна алгебра, релационен модел, нормализации и др. - са неща, с които се занимават не потребителите, а професионалистите. Така че, нека приемем за миг и гледната точка на залепналия за стола началник, желаещ да прехвърли купищата хартии "в компютъра".
Предимства
Но преди да погледнем през неговите очи трябва да споменем, че всъщност видимата част от една база данни е нейната т.нар. система за управление. Тъй като данните трябва да се поддържат и съхраняват за толкова време, колкото е необходимо, да се предпазват от неправилен достъп, да се запазват непокътнати, в наши дни системата за управление на базите данни (DBMS, database management system) представлява доста сложен софтуер. И макар едното задмониторно устройство, при добро изпълнение от администраторското такова, да има лесен и бърз достъп до данните, то второто споменато трябва да има небезизвестно количество налично сиво вещество, за да гарантира същия. Към момента, най-използвани DBMS-и са Oracle, DB2 и Microsoft SQL Server, последната от които рядко се употребява за по-сериозни и тежки проекти. Тези, които са се сблъсквали с инсталация или дори само са виждали инсталационните файлове, без съмнение са забелязали, че има операционни системи, по-малки от тях. При това съвременни такива.
Но нека вече застанем в потребителския ъгъл. Една система за управление на бази данни, освен че забравихме да споменем, че може да управлява не една или две такива, има и следните характеристики:
Съхранението на данните не зависи от протичащите процеси на потребителско ниво, на ниво операционна система и т.н. Това обаче е само един елемент от изискването за устойчивост на съхранението. Освен него, DBMS трябва да осигурява и достатъчно ефективен достъп, както като време, така и като изчислителен ресурс, до големи обеми от запазена информация. Също така, при възникване на грешки, аварии, бедствия и катастрофи, данните трябва да могат да бъдат възстановени. Което ще рече, че имаме не само устойчивост на паметта, но и на информацията.
Реализацията на програмния интерфейс, на свой ред, също се осигурява от системата за управление. Какво ще рече това - трябва да има достатъчно мощен език, на който да може да бъде написана приложна програма, с помощта на която потребителят да достъпва данните, без да ги оцапа. Както се сещате, обаче, само интерфейс е като кола без двигател - можете да си въртите геврека, но до Пловдив няма да идете. Така че се налага DBMS-ът да поддържа едновременен достъп, при това атомарен, до данните, по такъв начин, че всеки потребител, който работи с тях, да инициира отделен процес, наричан транзакция. Всяка от тях, сама по себе си, бива извършвана или изцяло, или отхвърлена изобщо - което всъщност значи атомарност. И, ако по време на изпълнение на една транзакция - не я бъркайте със заявка, защото са две отделни неща - възникне проблем, то системата трябва да я отмени и да възстанови състоянието на данните от преди инициализацията и.
Тъй като неволно се изтървахме за често срещаната грешка да се приравнява транзакция със заявка, нека поясним, че заявката всъщност е достатъчно малка, но обособена част от изпълняването на транзакцията. Чрез специални структури на езика, една транзакция може да включи множество на брой заявки. И въпреки, че това обяснение не е съвсем точно, и в никакъв случай пълно, дава известна представа каква е разликата между тях.
Иначе казано, нашият герой, който май не зае много екранно време, може да бъде сигурен, че фирмената информация се пази не по-зле в електронна база данни, отколкото на хартия - стига да е разбрал какво му казахме.
Архитектура
Архитектурната гледна точка вече ще засегнем по-бегло, тъй като там нещата са значително по-сложни и определено не интересуват толкова горещо потребителя, освен може би от онези няколко бита любопитство.
Като цяло, в чисто професионалния аспект на системата за управление присъстват неща като методи за създаване на схема на бази данни и логическа структура на информацията. Последният метод е реализиран чрез отделен език, наречен език за дефиниция на данните (data definition language, или DDL), който може да бъде език в термините на програмен такъв, но може да бъде и с графична репрезентация на логическата схема - квадратчета, стрелки и други такива джиджавки.
Също така присъстват методи за модификация на данните (чрез езика за манипулация на данните, data manipulation language или DML), език за заявки, който пък е подезик на споменатия вече DML и се използва при търсене. Освен това, в цялата магия, влизат още зачекнатите в потребителската част дългосрочно съхранение на много големи обеми информация, ефективност на търсенето и измененията, едновременният достъп на сюрия потребители и др.
Какво, обаче, се случва вътре?
Потребителят сяда, с възвишената идея да изобличи размера на сутиена на Памела Андерсън. Естествено, администраторите - като умни хора - не му дават да им ръчка директно по базите, което лесно може да достигне джигера, и са му написали съответното приложение. Изходът от това взаимодействие представлява известно количество заявки, потъващи из дебрите на структурата на DBMS. Те попадат в компилатора на заявки.
Компилаторът на заявки представлява нещо като учителка по литература, проверяваща контролни. Първо преглежда синтаксиса - дали всичко е изписано вярно - след което преминава на семантиката, сиреч дали изписаното иначе вярно нещо носи някакъв смисъл в термините на изработения от дизайнера на базата данни модел. След всичко това, обаче, не поставя финална оценка на контролното, а изработва план на заявката. Който план е съставен от константи, изрази и операции от релационната алгебра, имена на атрибути и таблици, иначе казано неща, които изцяло не ви интересуват и не знам въобще що ви ги споменавам. Но въпреки това, дори ще отбележа, че се реализира в дървовидна структура, с възли-релационни операции и листа-константи и имена. Това е за тези, които евентуално биха се поинтересували.
След което, заявките, бидейки от високо ниво, се налага да бъдат оптимизирани. Което отново е функция на компилатора на заявките. С други думи, самият той е комплексна структура, включваща синтактичен, семантичен анализатор, оптимизатор на заявки и други неща. Последният процес обаче носи със себе си и един проблем. Както споменах по-горе, една заявка на езика SQL има вид "избери тези колони от онази таблица, където е спазено даденото условие". Самият този най-прост вид рядко успява да удовлетвори нуждите за достъп до крупни масиви от данни. Ако заявката е от споменатия тип, т.е. се отнася към една таблица, конкретизирани атрибути и натурално условие, то процесът по оптимизирането и надхвърля времето за изпълнение. Естествено, ако е по-сложна, включва набор от таблици, различни типове свързвания, комбинирани групи от атрибути, множество условности и пр., това не е така.
Като цяло този проблем се решава чрез следния метод - когато една заявка се съхранява за множество изпълнения, освен самата нея се съхранява и оптимизирания и план. По този начин се избягва повторната оптимизация на един и същи процес. В интерактивен режим обаче по презумпция би трябвало да се появяват само по-прости заявки, тъй като той не поддържа подобно съхранение. А всъщност е и логично - кой нормален човек пише нещо безумно сложно всеки нов път.
От компилатора цялата галимация попада в изпълнителната машина. Последната вече изпълнява заявките, обръщайки се към различни файлове, използвайки разнообразни методи за достъп. Тя "познава" физическата организация върху носителя на данните и борави с нея.
Каквато и методика за съхранение да се използва, информацията винаги е в странициран вид - сиреч, разделена на строго определени страници по различни методи, от по 4, 16, 32 и т.н. килобайта. За страницирането и буферизацията можете да погледнете и в статиите за  файлови системи и памети. Управлението на външната памет реално извършва достъпа до физическите данни, докато т.нар. управление на буферизацията отговаря за това дали търсените страници не се намират в запазените в оперативната памет буфери, спестявайки операции по четене от диска. Този елемент от организацията стои под изпълнителната машина, заедно с управлението на индексите, на файловете и на записите. Схематично, изпълнителната машина подава заявки към споменатите индекси файлове и записи, от които се генерират постранични команди, след което идват операции по четене и писане по страници и физическото им изпълнение.
Процесите, протичащи в DBMS-а - споменатите транзакции - сами по себе си са достатъчно сложни, не бива да се влияят една от друга, и трябва да се изпълняват поне на виртуално ниво последователно, въпреки че на физическо те могат да се изпълняват и едновременно в големи количества. Така че се налага реализацията на модул за управление на транзакциите, който използва т.нар. журнал, където те се регистрират. Изпълнителната машина записва в журнала настъпилите промени в отделни записи, като се запазва началното състояние на транзакцията, позволяващо при възникване на форсмажорно обстоятелство записът да бъде възстановен.
Освен това, въпреки потребителската си ориентация, DBSM-ът трябва да притежава, и е реализиран, административен модул. Администраторът е този, който отговаря за структурата и схемата на базата данни, както и за нивата на достъп. Споменахме, че за тази цел се използва DDL, изпълнението на команди на него има собствен компилатор, който ги обработва, а финалната им реализация се поема отново от изпълнителната машина.
Всичко това би било толкова просто, ако не се налагаше множество потребители да имат едновременен достъп. Тъй като може да се случи известно количество от тях да искат да извършват манипулации върху едни и същи данни, без допълнително програмно осигуряване не би било възможно да се гарантира атомарност на транзакциите, което - както споменахме - е от основните преимущества на DBSM. Сигурно се досещате, че в модерните такива подобно чудо съществува. Това е модулът за управление на едновременния достъп, към който се обръща този, управляващ транзакциите, при изпълнението им. При такова, първият блокира съответно за четене, за писане, или и двете, известно количество таблици, върху които се извършва обновяване. С цел по-висока ефективност е възможно също така да бъдат блокирани и отделни кортежи (редове от таблицата).
Транзакциите, бидейки процеси, имат тенденцията да попадат в дедлок. Ще да рече, че влизайки в момент на изчакване, определено количество заявки могат да изчакват изпълнението на други, които също в момента чакат. Голямо чакане пада, и както се досещате, в такъв случай цялата система би увиснала. Затова, операционните системи притежават множество алгоритми, целящи предотвратяването на подобни ситуации, или в случай на поява - за разрешаването им. Подобен механизъм, така да се каже, присъства и при DBSM, но е реализиран по възможно най-простия начин - чрез елиминирането на всички транзакции, попаднали в дедлок. Интересна вметка би била, че това е чудесна илюстрация колко по-важни са данните и тяхната сигурност, отколкото потребителските щения. Което, ако си спомняте, беше едно от основните преимущества, споменати по-горе.
Светлото бъдеще
С навлизането на мултимедията като елемент от приложението на компютърните системи в практиката, базите данни също се променят, в посока догонване на технологичния процес. Мултимедийните данни са големи по обем, като например една колекция от HD видео материали може да бъде от порядъка на терабайти и дори да го надхвърля. Генералната концепция гласи, че данните се обработват в оперативната памет, но се държат на дисков носител. Обаче, в случая на мултимедията, изникват два проблема. Единият свързан с обема, другият - със структурата на информацията от този тип.
Първият проблем се решава лесно чрез използването на третичната памет, която изглежда по следния начин: известно и немалко количество дискови носители се съхраняват в помещение, наречено силоз, и се подават чрез автоматизирана система по заявка от страна на изпълнителната машина. Естествено, както се досещате, механизмът е скъп, обемен и бавен.
Вторият е, че ако търсите момент от филм просто няма как да го намерите. Въпреки, че до известна степен е заобиколен чрез записи като заглавие, година и т.н., дори индекси на отделни сцени, на практика произволен момент е достъпен, но ненамираем. Така че, пълната интеграция на мултимедийната информация е все още елемент от бъдещето развитие на базите данни.
По принцип, боравенето с толкова големи обеми данни и реализацията на методите за достъп не може да се осъществява от една независима машина. Точно затова при средния вариант, на сравнително голяма база данни, се използват или многопроцесорни конфигурации с паралелно работещи дискове, организирани в райд-масиви, или - в случая на наистина големи такива - разпределени системи от множество свързани помежду си единици.
За осъществяването на този своеобразен паралелизъм спомага клиент-сървърната архитектура, на чиято база са реализирани повечето DBSM. Иначе казано, тя е съставена от клиентска програма, която изпраща желанията на потребителя към друга, наречена сървър, която пък на свой ред ги удовлетворява. Тази система облекчава до известна степен нещата, но при множество клиенти също се затормозява, или поне в сървърната си част. Затова DBSM в най-тежките случаи бива локирана на сървър, чиито клиенти са приложни сървъри, които от своя страна комуникират с потребителския интерфейс, реализиран на уеб-сървъри. Това изпълнение, представляващо своеобразно разслояване, спомага за разпределението на тежестта и отговорността за изпълнение на заявките между множество отделни компютърни системи.
Финални слова
На шега някои работещи с бази данни, разбърквайки буквите от английското съкращение на системата за управление, понякога го наричат и BDSM. Вероятно тази статия ви е дала някои податки защо се появява това странно явление, извън случайната анаграма. Освен нея се използва, вече съвсем насериозно, още едно - ACID - което не само е плод на киселините, които досега със садо-мазохизма докарва на заетите в бранша, но и най-добре олицетворява идеята, стояща зад модерните бази данни. А именно: атомарност (atomicity), цялостност (consistency), изолирано изпълнение (isolation), устойчивост и надежност (durability). И може би с това мога да завърша. |
• 
Български • 
English [beta] • 
• 
• 
Екип • 
Партньори • 
Ресурси • 
Статистики • 
За контакт
Добави в любими • Предложи статия • Конкурси • За рекламодатели
Добави коментар 
Търсене
покажи/скрий карето 
