Научноизследователски развоен проект: "Нов подход за изграждане на софтуерни

системи за бизнес управление и контрол, предназначени за масово ползване:

концепция, методология, програмни средства, експерименти и анализ"

Обзор 1

Информатика,

езици за програмиране,

среди за разработка,

бази от данни,

методи за достъп

Изготвили:

доц. д-р Красимира Иванова,

докторант Анани Ризов

2015

Работата е извършена по заявка на ФОИ КОНСУЛТ ООД в рамките на изпълнение на:

Договор номер: № 7ИФ-02-5/25.07.2014

Наименование: Нов подход за изграждане на софтуерни системи за бизнес управление и

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

програмни средства, експерименти и анализ

Начало на договора: 01.08.2014

Срок на договора: 18 месеца

Бенефициент: "ФОИ Консулт" ООД

Финансираща институция

:

Национален иновационен фонд

Програма за насърчаване на малките и средните предприятия

Седма конкурсна сесия - 2014

Съдържание

Въведение5

Глава 1. Информатика и информационни технологии...........................................7

1.1 Информатика................................................................................................7

1.2 Информационни технологии.....................................................................10

Глава 2. Езици за програмиране. Парадигми на програмиране..........................13

2.1 Еволюция на програмните езици..............................................................15

2.2 Видове програмиране според начина на изпълнение на програмата...18

2.3 Видове програмиране според начина за организация на програмите..19

Глава 3. Среди за разработка на програмни приложения...................................30

3.1 Основни типове инструменти, изграждащи система за програмиране.30

3.2 Интегрирани среди за разработка............................................................35

3.3 Облакови интегрирани среди за разработка (Cloud IDE)........................37

3.4 RAD технология...........................................................................................41

Глава 4. Бази от данни.............................................................................................45

4.1 Определение..............................................................................................45

4.2 Състав на СУБД...........................................................................................47

4.3 Организация на данните в базата от данни.............................................50

4.4 Архитектура на базата от данни................................................................51

4.5 Класификации.............................................................................................53

4.6 Йерархичен модел на база от данни........................................................55

4.7 Мрежов модел на база от данни..............................................................56

4.8 Релационен модел на бази от данни........................................................57

4.9 ACID тест......................................................................................................63

4.10 NewSQL бази от данни...............................................................................65

4.11 Транзакционни и аналитични системи (OLTP и OLAP).............................66

4.12 Складове от данни (Data Warehouses)......................................................69

4.13 Пространствени бази от данни (Spatial Data Bases).................................71

3

4.14 Пространствено-времеви бази от данни (Spatio-Temporal DB)...............73

4.15 NoSQL бази от данни – предпоставки за развитие..................................74

4.16 Определение на NoSQL базите от данни..................................................80

4.17 ACID vs BASE................................................................................................81

4.18 Класификация на NoSQL базите от данни................................................82

4.19 Сравнителни характеристики и представяне...........................................89

Глава 5. Методи за достъп......................................................................................99

5.1 Едномерни методи за достъп.................................................................102

5.2 Пространствени методи за достъп..........................................................109

5.3 Метрични методи за достъп....................................................................112

5.4 Високо-размерни методи за достъп.......................................................112

5.5 Пространствено-времеви методи за достъп..........................................113

Глава 6. Hadoop; MapReduce.................................................................................115

6.1 Hadoop – разпределено съхранение и обработка на данни върху

клъстери....................................................................................................115

6.2 MapReduce................................................................................................120

Библиография.............................................................................................................126

Приложение 1: Списък на бази от данни.................................................................130

4

Въведение

Тук ще направим кратко описание на съдържанието на обзора.

Първа глава прави общо въведение в целите, обекта и предмета на науката

Информатика и връзката й с други науки, както и на определянето на ролята и задачите

на Информационите технологии в съвременното развитие.

Втора глава се спира на езиците за програмиране като средство за описание на

структури от данни и алгоритми, прилагани върху тях. Разглежда се еволюцията на

езиците за програмиране с подчертаване на принципно новите неща, които всяко

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

класификации на видовете програмиране – спрямо начина за изпълнение на

програмата (императивно, декларативно, събитийно-управляемо) и спрямо начина на

организация на програмите (процедурно, процедурно, структурно, обектно-

ориентирано, компонентно-ориентирано, агентно-ориентирано, аспектно-

ориентирано, функционално и логическо).

Трета глава се спира на основните характеристики на средите за разработка на

програмни приложения. Първоначално са възникнали като необходим минимум от

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

редактори, дебъгери, среди за изпълнение и библиотеки. По-късно се обединяват в

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

значително по-лесна, удобна и производителна. Освен класическия мининум от

елементи съвременните интегрирани среди за разработване често включват:

инструменти за контрол на версиите, средства за управление на проекти, библиотеки с

шаблони за различни типове проекти, браузъри на класове, диаграми на йерархията

им, средства за интегриране на нови компоненти в средата за генериране на

документация, инсталатори и други инструменти, необходими при разработката на

съвременните софтуерни приложения. Облаковите среди за разработка внасят нова

свобода в развитието на разработката на приложения чрез предлагането на удобна

5

функционалност за програмиране в облака, на облачни приложения и/или на

приложения за смартфони, таблети и други мобилни устройства.

В трета глава се прави кратко представяне и на RAD-технологията като един от

първите съвременни методи за разработка на програмни приложения (agile

development), стъпвайки на принципа на прототипирането и тясната връзка с клиентите

във всички фази на разработване до достигането на приемлив продукт.

Четвърта глава е фокусирана върху различни аспекти на базите от данни и

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

данни, различните класификации като специално внимание са обръща на различията

спрямо модела на данните. По-специално внимание се обръща на релационните бази

от данни, доколкото те заемаха господстващо присъствие в предишните години –

принципи на изграждане, условия, на които трябва да отговарят (ACID тест), сфери на

успешни приложения. Вниманието се спира и на примери на приложения, където

релационните бази от данни не се справят добре с възникващите предизвикателства –

като OLAP, Data Warehouses, Spatial Data Bases, Spatio-Temporal DB и др. Бурното

развитие на Интернет и експоненциалното нарастване на данните и потребителите

довежда до развитието на нови типове бази от данни, които да преодолеят

недостатъците на релационните СУБД за решаване на новите задачи. В последните

години силно развитие имат т.нар. NoSQL бази от данни, чието наименование не е

съвсем удачно, доколкото те не отричат езика SQL, а релационния модел на данни, но

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

NoSQL бази от данни според използвания модел на данни, който е свързан и със

сферата на приложение на съответната база от данни. Показват се и някои изводи от

правени сравнения между различните СУБД.

В пета глава се разглеждат различни методи за достъп до данните, използвани в

зависимост от практическите задачи, които решават съответните бази от данни.

Шеста глава разглежда програмната платформа за построяване на разпределени

приложения за масова паралелна обработка на данните Hadoop и на принципа на

работа на MapReduce, използван за извършване на разпределена обработка на големи

обеми данни на изчислителни клъстери.

6

Глава 1.

Информатика и информационни технологии

1.1 Информатика

Информатиката е наука, която изучава

информацията от гледна точка на нейната

структурираност, форми и начини за представяне,

количествените й характеристики; информационните

процеси като композиция на основните

информационни дейности, както и методите и

средствата за автоматизирането им [Бърнев и

Керпеджиев, 1988].фиг. 1. Схема на

информационните дейности

Основен обект на изследванията в информатиката са не само изкуствено

породените информационни процеси, но и такива, които се срещат в природата –

например, процесите на възприятие; когнитивните процеси у човека; клетъчните

процеси, които се управляват от генетичната информация. Разбирането на тези

процеси е от съществено значение и обогатява запаса от основни концепции и схеми, с

които разполага информатиката.

Предметът на информатиката може да се раздели най-общо на две части.

Първата покрива задачите за обработка на информацията, процедури за боравенето с

тях и разнообразни представяния, свързани с тях. Втората се отнася главно до

разнообразните структури, механизми и схеми на обработка на информацията.

Компютърните приложения най-общо се делят на две големи групи – числови и

нечислови. Първите се отнасят до проблеми в областите на числения анализ,

7

оптимизацията и симулацията. Вторите се отнасят до процеси, обхващащи нечислови

данни, като представяния на проблеми, програми, символни изрази, език, структури,

графични обекти. Клонове на информатиката с основна дейност в нечисловите

приложения са изкуственият интелект, съхраняване и извличане на информацията,

комбинаторни процеси, обработка на език, символни манипулации и т.н.

Теоретичната работа по информатика разчита на няколко клона на математиката

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

Практическата работа по информатика е свързана с развитието на компютърната и

комуникационната техника, поради което пък други я считат за инженерна наука.

Всъщност тя просто има пресечни области със съответните науки.

Информатиката се оформя като отделен клон в научното познание от средата на

миналия век. Самото й дефиниране в различните държави и групи държави

исторически е доста объркано, но постепенно, независимо от използваните термини за

обзоначаването й, се оформя виждането като самостоятелна наука, отговаряща на

дефиницията, дадена в началото.

Терминът "информатика" се появява по различни пътища. От една страна Philippe

Dreyfus през 1962 формира термина като сборна дума от френските думи за

"информация" и "автоматика" за обозначаване на науката за електронно-

изчислителните машини и тяхното приложение (Informatique = INFORmation +

autoMATIQUE) [Dreyfus, 1962]. От друга страна руските учени А.И. Михайлов, А.И.

Черный и Р.С. Гиляревский въвели понятието "информатика" като неологизъм на

латинска основа за означаване на научната дисциплина, свързана преди всичко с

научно-техническата информация, а по-късно и с другите системи за натрупване на

ивнформация от печатни източници и документи [Михайлов и др., 1966].

Англоезичните страни обикновено използват термина Computer Science

(компютърни науки), но и при тях има още един близък клон – т.нар. Information

Science (информационни науки).

Encyclopedia of Computer Science [Ralston et al, 2003] препраща понятието

информатика към "Computer Science" (CS) и "Information Science" (IS). В по-старото

издание на енциклопедията [1976-1st ed] Computer Science е определена като

"занимаваща се с информационните процеси, информационните структури и

8

процедури, които влизат в представянията на такива процеси, с техните реализации в

системи за обработка на информация, както и с отношенията между информационните

процеси и класовете задачи, които ги пораждат".

В 1978 г международният конгрес на IFIP официално определя термина

"Computer Science" като наука, свързана с проектирането, разработването,

използването и поддръжката на системите за обработка на информация, включително

компютри и софтуер, както и институционалните, търговските, административните и

социално-политическите аспекти на компютризация (масовото въвеждане на

компютърните технологии във всички области на живота). Тя съдържа три основни

части – техническите средства (hardware), програмните средства (software) и

алгоритмичните средства. За да не се забравя тази трета част, акад. А.А. Дородницин

предлага, по аналогия с първите два термина, да се въведе терминът "brainware" за

обозначаване на тази част от информатиката, която е свързана с разработката на

алгоритмите и изучаването на методите и средствата за тяхното построяване. Терминът

не влиза в употреба в това си значение, но тази трета част от науката продължава да

изгражда гръбнака на изследванията.

Терминът "информационна наука" се създава през 60те години във връзка с

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

информация и е съсредоточена главно върху боравенето с библиографски архиви и

текстова информация в науката и инженерното дело [Ralston et al, 2003]. Значително

внимание е отделено на два основни фокуса на усилията: (1) изучаване на процесите

на комуникация в научната и промишлената общност и (2) разработване на техники и

системи за по-ефективни организация, съхраняване и разпространение на записаната

научна информация. Оттук съвременната информационна наука и нейните професии

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

системи за обработка на информацията, които да разширяват ума на човека и

целенасочените му дейности. И доколкото и компютърната наука (чиито интерес е в

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

споделя тези логически аспекти, те се смятат от мнозина за синоними.

Според Handbook of Information Science "Информационната наука е

интердисциплинарна област, преди всичко свързана с анализа, събирането,

9

класифицирането, обработката, съхранението, възстановяването, движението,

разпространението и защитата на информацията". Тя е интердисциплинарна наука,

свързана с такива области като математика, логика, лингвистика, психология,

компютърни технологии, изследване на операциите, графични изкуства, комуникации,

библиотечни науки, управление, и други подобни области [Stok & Stok, 2013].

Математиката също се занимава с информацията и структурата и това обърква

тези, които не са добре запознати и с математиката, и с информатиката. Математикът

има интерес към откриването на синтактичните отношения между елементи,

основавайки се на набор от аксиоми, които може да нямат съответствие във

физическата действителност. Информатикът има интерес към откриването на

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

се моделира и анализира преобразуването на информацията в действителния свят.

Прагматичните аспекти на този интерес водят до изследване на действени начини за

представяне на информацията, действени алгоритми за преобразуване на

информацията, действени езици за изразяване на алгоритми, действени средства за

наблюдаване на процеса и изобразяване на преобразената информация, и действени

начини да бъдат постигнати изброените на разумна цена [C3S, 1965].

1.2 Информационни технологии

Информационните технологии (ИТ) са група технологии, предназначени за

събиране, обработка, съхранение и разпространение на звукова, графична, текстова и

числена информация, и използващи за тази цел базирано на микроелектрониката

съчетание от компютърна и телекомуникационна техника [Longley et al, 1985].

Информационните технологии обхващат практическото приложение на

информатиката. Тъй като обработваната информация най-често е в дискретизиран вид,

информационните технологии понякога са наричани и цифрови. Поради важната роля

на комуникациите в съвременните средства за обработка на информация, често се

използва и по-широкото понятие информационни и комуникационни технологии.

На практика още шумерите в древна Месопотамия (3000 г. пр.н.е.) са започнали

да съхраняват, извличат, преобразуват и обменят информация. Въз основа на

10

използваните технологии за съхранение и обработка обикновено се разграничават

четири различни фази на развитие на ИТ в общия смисъл: пред-механични (3000 BC -

1450 AD), механични (1450-1840), електромеханични (1840-1940) и електронни (1940-

до момента). На сайта http://www.tcf.ua.edu/AZ/ITHistoryOutline.htm се намира богат

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

Терминът "информационни технологии" в съвременния смисъл на думата за

първи път се среща през 1958 в статия на Harold J. Leavitt и Thomas L. Whisler,

публикувана в Harvard Business Review, където те казват, че за новата технология, която

все още няма утвърдено име, ще използват термина "информационни технологии".

Тяхната дефиниция се състои от следните три категории: техники за обработка;

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

симулация на мислене от по-висш порядък чрез компютърни програми [Leavitt and

Whisler, 1958].

Изследвания в световен мащаб от последните десетилетия показват [Hilbert,

2014], че развитието на информационните и комуникационни технологии в общи

линии следва експоненциалната линия. По-конкретно, използването на компютърни

приложения със специално предназначение се удвоява на всеки 14 месеца,

компютрите с общо предназначение – на всеки 18 месеца, комуникационният

капацитет – на всеки 34 месеца, обемът на съхраняваната информация – на всеки 40

месеца (бел.авт. – самото изследване е до 2011г и вероятно с навлизането на новите

технологии периодът за последните две области силно се е скъсил).

В образователен контекст, Асоциацията за изчислителна техника (ACM) определя

информационните технологии (ИТ) като "специалности, които подготвят обучаемите да

могат да отговарят на нуждите от компютърни и комуникационни технологии на

бизнеса, правителството, здравеопазването, образователните институции и други

видове организации...". Дейността на коя да е организация днес е силно зависима от

информационните технологии. ИТ-специалистите се грижат за двете страни на процеса:

технологичната и човешката. От една страна, организацията трябва да разполага с

подходящо подбрани системи, които да работят правилно, да са сигурни,

модернизирани и добре поддържани. От друга страна, служителите в цялата

организация имат нужда от подкрепа от ИТ-персонала, който разбира от компютърните

11

системи и техния софтуер и се ангажира с решаване на специфичните задачи,

възникващи в процеса на ползване на компютърната инфраструктура. ИТ-

специалистите поемат отговорността за избора хардуерни и софтуерни продукти,

подходящи за дадена организация, за интегриране на тези продукти с организационни

нужди и инфраструктура, както и инсталиране, персонализиране, и поддържане на

тези приложения за компютърните потребители в организацията [ACM and IEEE, 2006].

Отговорностите на ИТ-специалистите включва администрация на мрежи, разработка на

софтуер, инсталация на софтуер, планиране и мениджмънт на организационния

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

(ъпгрейди) и заменяне.

В бизнес контекст, според Американската асоциация за информационни

технологии (Information Technology Association of America), информационните

технологии включват: "изучаването, проектирането, изграждането, приложението,

поддръжката и мениджмънта на компютърно-базирани информационни системи"

[Proctor and Scott, 2011]. Бизнес стойността на ИТ е в автоматизацията на бизнес

процесите, предоставянето на информация за вземане на решения, свързването на

бизнесите с техните клиенти и предоставянето на средства за продуктивност за

увеличаване на ефикасността.

Развитието на информационните технологии поражда и различни етични и

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

информационните технологии, между различни участници в бизнес процеса: между

самите производители на софтуер; между потребители и производители и търговци на

софтуерни продукти, които се използват; между работодателите и

работниците/служителите в различни аспекти (защита на лични данни; следене на

работата на служителя с компютъра; ограничения на хардуера, софтуера и интернет

приложенията, които той може да ползва и др.); с външни лица/организации, които

извършват зловредни действия върху софтуера или данните на организацията

(хакерски нападки на онлайн бази от данни; вируси и троянски коне; интернет

шпиониране и др.) [Reynolds, 2015]

12

Глава 2.

Езици за програмиране. Парадигми на програмиране

Език за програмиране е изкуствен език, предназначен за изразяване на

информационни дейности, които могат да се извършат от машина, по-специално от

компютър.

Най-ранните програмни езици предхождат изобретяването на компютъра, и са

били използвани за управление на поведението на машини като жакардов стан и

механично пиано. В днешно време съществуват и продължават да се създават хиляди

различни езици за програмиране, предимно в областта на компютрите.

Различните езици за програмиране поддържат различни стилове на

програмиране. Избирането на език за програмиране е свързано с много съображения

като например фирмена политика, съвместимост, наличност на библиотеки или лични

предпочитания.

Отличителните белези, които често се смятат за важни за това какво представлява

един език за програмиране, включват:

Функция и цел: Компютърен програмен език е език, използван за писане на

компютърни програми, които са свързани с това компютър да извършва някакъв вид

изчисление или алгоритъм и евентуално да управлява външни устройства като

принтери, дискови устройства, роботи, и т.н. По-общо казано, един език за

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

Общоприето е, че една пълна спецификация за един език за програмиране, включва

описание на машина или обработчик за този език.

Абстракции: Езиците за програмиране обикновено съдържат абстракции за

дефинирането и работата със структури от данни или за управление на потока на

изпълнение.

Изразителна сила: Теорията на алгоритмите, класифицира езиците на базата на

изчисленията, които са способни да изразят. Популярни съвременни езици за

13

програмиране с общо предназначение са C++, C#, Object Pascal, Java, PHP, Perl.

Специализирани езици за програмиране са например SQL (за заявки към системи за

управление на бази от данни), JavaScript (за реализиране на динамично поведение в

уеб сайтове от страна на клиента) и т. н. Маркиращи езици като XML или HTML

дефинират само структуриране на данните и не се считат за езици за програмиране.

Следва да отбележим, че термините "компютърен език" и "език за

програмиране" понякога се въприемат като взаимозаменяеми. Някои автори, обаче,

влагат различен нюанс в двата термина, включително обхвата на всеки един от тях. При

едната употреба, езиците за програмиране се описват като подмножество на

компютърните езици1. Така например, езиците за маркиране, понякога биват наричани

компютърни езици, с цел да се подчертае, че не се използват за програмиране. При

другата употреба на термина, езиците за програмиране се разглеждат като теоретични

конструкции за програмиране на абстрактни машини, а компютърните езици като

тяхно подмножество, които работят на физически компютри, които имат ограничени

хардуерни ресурси2. Джон Рейнолдс подчертава, че формалните езици, са точно

толкова, колкото езици за програмиране, колкото и езиците, предназначени за

изпълнение. Той също така твърди, че текстови и графични входни формати, които

влияят на поведението на компютъра са програмни езици, независимо от факта, че те

често не са Тюрингови, и отбелязва, че това непознаване на концепциите на

програмните езици е причина за много недостатъци във входните формати3.

Езиците за програмиране са средство за описание на структури от данни и

алгоритми, прилагани върху тях. Чрез тях се описват конкретните действия, които

компютърът трябва да извърши за да реализира даден алгоритмичен процес. Всеки

език за програмиране има своя азбука, синтаксис и сематика. Описанието на даден

1 Pascal Lando, Anne Lapujade, Gilles Kassel, and Frédéric Fürst, Towards a General Ontology of

Computer Programs, ICSOFT 2007, pp. 163-1702 R. Narasimahan, Programming Languages and Computers: A Unified Metatheory, pp. 189--247 in Franz

Alt, Morris Rubinoff (eds.) Advances in computers, Volume 8, Academic Press, 1994, ISBN 012012108,

p.2153 John C. Reynolds, Some thoughts on teaching programming and programming languages, SIGPLAN

Notices, Volume 43, Issue 11, November 2008, p.109

14

алгоритъм чрез средствата на дадения език за програмиране се нарича програма.

Азбуката на езика съдържа определен набор от знаци. Синтактичните правила

определят кои последователности от елементи на азбуката на съответния език за

програмиране са допустими езикови конструкции. Семантичните правила определят

смисъла на синтактично правилните конструкции, т.е. как те трябва да се разбират от

човек и как ще бъдат интерпретирани при изпълнение от компютър.

2.1 Еволюция на програмните езици

Спрямо своите възможности и време на създаване езиците за програмиране се

делят на няколко поколения, качествено различаващи се едно от друго по своята

функционалност.

Първо поколение (машинен език) – 40-те години на ХХ век

Машинните езици съдържат основния набор инструкции на конкретния

процесор. Самата програма е последователност от инструкции на компютъра и

представлява двоичен низ с определена дължина и структура. При написване на

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

Програмистът трябва да запомни синтаксиса и семантиката на редица

машинни инструкции в двоичен код и също така се грижи сам за разполагане

на данните в паметта.

Има голяма вероятност от допускане на грешки при въвеждането, а

намирането и коригирането им е трудно.

Преносимостта на програмите не е възможна.

Усвояването на един машинен език не позволява лесен преход към

изучаването на друг машинен език.

Второ поколение (асемблерен език) - 50-те години на ХХ век

Асемблерните езици са машинно-ориентирани езици от ниско ниво, в който

всеки оператор отговаря на инструкция, която процесорът може да изпълни. Основната

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

мнемонични кодове и въвеждането на относителната адресация, чрез използването на

символни адреси за означение на паметта. Кодът може, да се чете и пише сравнително

15

лесно от човек, но за да се изпълни на компютърната система той трябва да бъде

конвертиран (транслиран) до форма четима от машината. Процесът на конвертиране е

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

на програмистки труд по-късно започват да се използват макроасемблерите, в които се

дефинират и именуват групи от често използвани операции, наречени макроси.

Езикът е специфичен за отделна процесорна фамилия и среда.

Асемблерите се използват активно и днес за създаване на програми, максимално

използващи възможностите на хардуера - драйвери, модули за включване на

нестандартно оборудване или за библиотеки за ефективна реализация на стандартни

алгоритми за обработка на данни. Код на асемблерен език е и резултатът от

дизасемблиране на програма, използван при откриването на компютърни вируси.

Трето поколение (езици от високо ниво) – 60-те години на ХХ век

Тези езици за програмиране са проектирани да бъдат по-лесни за разбиране от

човека, включително имена на променливи, абстрактни типове данни, и синтаксис на

алгебрични изрази. Друга голяма разлика в сравнение с второто поколение езици за

програмиране е абстракцията от процесора, върху който се извършва обработката. До

такава идея пръв е достигнал Конрад Цузе, още през 1945 г., започвайки

разработването на езика Plancalcul.

Първите езици от високо ниво са Fortran (1957), Cobol (1960), Algol, а по-късно

Basic (1965) Pascal (1971). Първоначално се е смятало, че отдалечаването на езиците за

програмиране от архитетурата на компютъра ще доведе до намаляване на

ефективността на програмите, но създаденият от Бекъс транслатор за превод от Fortran

на машинен език извършва истинска революция в програмирането. Машинните

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

машинните програми, написани от човек. Със създаването на езика Алгол се очертава и

другата роля на езиците за програмиране – да служат като средство за описание на

алгоритми. Затова тези езици се наричат още алгоритмични езици.

Езиците от високо ниво използват специални думи, наречени оператори и

правила за използване на тези оператори. Един оператор обобщава действието на

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

16

(английски) и чрез възприетата в математиката символика. Езиците от високо ниво

въвеждат процедурния стил в програмирането. Известни процедурни езици са Fortran,

Cobol, Modula-2, Pascal, Basic, C.

Четвърто поколение - 90-те години на ХХ век

Езиците от четвърто поколение се развиват основно в две направления:

Сложен език, осигуряващ набор от средства и подпрограми за повишаване

производителността на програмистите;

Достъпен за крайните потребители език, чрез който те могат да създават

собствени приложения.

Езиците от това поколение се характеризират с наличие на визуална среда за

разработка, използване на обектно-ориентиран подход на програмиране, притежават

мощни средства за програмиране на клиент-сървър приложения, както и със средства

за управление на бази от данни и генератори на отчети.

Пето поколение

Това поколение езици за програмиране се базира на решаването на проблеми

посредством ограничения, дадени на програмата, а не с помощта на императивен

алгоритъм. По този начин, грижата на програмиста е да опише правилно проблемите,

които трябва да бъдат решени и какви условия трябва да бъдат изпълнени, без да се

налага да създава рутинния алгоритъм за решаването им. Петото поколение езици се

използват главно в областта на изкуствения интелект (Lisp, Prolog, SmallTalk). Петото

поколение езици много силно нашумява през 80те години на миналия век, считани за

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

системати, с изключение на езиците от ниско ниво. През това десетилетие Япония

налива много инвестиции в изследванията и резвитието на тези езици и създаването

на масивна компютърна мрежа на машините, които използват тези инструменти.

Отрезвяването идва от факта, че самото дефиниране на набора от ограничения, които

определят даден проблем, и произтичащия ефективен алгоритъм за решаването му е

сама по себе си много трудна задача. В крайна сметка в момента терминът се измества

от разпространението на силно развити езици от четвърто поколение с по-висока

степен на автоматизация и база от знания.

17

2.2 Видове програмиране според начина на изпълнение на

програмата

Спрямо начина на изпълнение на програмата различаваме три основни вида

програмиране: императивно, декларативно и събитийно-управляемо.

Императивно програмиране

Императивното програмиране е най-старият начин на програмиране.

Програмистът описва различните стъпки, които компютърът трябва да следва, за да

изпълни задачата.

Декларативно програмиране

При декларативното програмиране се дефинират множество от факти и

взаимоотношения, описващи проблема, а не последователност от действия за

решаването му. Получавайки база от данни и набор от правила, компютърът се опитва

да намери решение чрез съвпадение с всички желани свойства. Примери на

декларативни езици са езикът за програмиране на заявки SQL, както и семейството на

функционалните езици и езиците за логическо програмиране.

Събитийно-управляемо програмиране

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

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

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

не се води от подредбата на кода в програмата. Инициатор на събитие може да бъде

определено действие от страна на потребителя (натискане на бутон, клавиш,

придвижване на мишката и т.н.), от страна на операционната система (напр.

завършване на текущата сесия на работа) или като резултат от активиране на събитие

от предишно действие на програмата. Следва да отбележим, че докато се обработва

едно събитие, паралелно може да възникне друго събитие и тогава програмните

участъци, отговорни за реакцията им, се изпълняват паралено (процесът се разделя на

нишки).

18

2.3 Видове програмиране според начина за организация на

програмите

Начинът на организиране на програмите частично зависи от начина на

изпълнение на програмите, например функционалното и логическото програмиране са

варианти на декларативното програмиране, но не напълно, например обектно-

ориентирано програмиране може да се осъществи и в декларативна и в събитийно-

управляема програма. По-долу ще разгледаме някои от основните тенденции в

развитието на начините на организиране на програмния код.

Процедурно програмиране (Procedural Programming)

Красноречиво пояснение на процедурното програмиране представлява

заглавието на книгата на Никлаус Вирт:

алгоритми + структури от данни = програми

Програмистът съставя програма и указва на компютъра как на базата на избран

алгоритъм и възприети структури от данни да се намери решение на поставената

задача.

Процедурното програмиране е вид императивно програмиране. Новото е

въвеждането на възможността за оформяне на относително затворени повтарящи се

части от програмния код в подпрограми/процедури/функции/макроси (различни

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

от програмата, с изпълнението на които се получават определени резултати. Чрез

използването им програмата може да се раздели на отделни модули. Основен

принцип на процедурното програмиране е модулния. Програмата се разделя на

"подходящи", взаимосвързани части, всяка от които се реализира чрез определени

средства. Целта е, следващите промени в представянето на данните да не променят

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

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

модули е нарастването на големината на програмата. Основните предимства на този

подход са следните:

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

19

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

Те се дефинират еднократно като функции, след което могат да бъдат

изпълнявани произволен брой пъти;

постига се икономия на памет, тъй като кодът на функцията се съхранява

само на едно място в паметта, независимо от броя на нейните изпълнения.

Структурно програмиране (Structural Programming)

С развитието на езиците и нарастването на сложността на програмите се появява

структурното програмиране като естествена необходимост за изграждане на стил,

позволяващ по-голяма гъвкавост, добър програмен дизайн, по-лесна четимост на

програмите и по-лесна подръжка. Структурното програмиране се базира на

процедурното програмиране и представлява набор от стандарти, които правят

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

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

логическата последователност на извършваните действия. За езици като C, Pascal,

dBase е присъщо структурирането.

Структурното програмиране се базира на метода на последователна

детайлизация на алгоритми. Програмирането се извършва на принципа "отгоре-

надолу" (top-down). В първата фаза се формулира основният алгоритъм, състоящ се от

блокове, част от които са записани само като имена на алгоритми, изпълняващи по-

малки задачи. Във втората фаза Всички допълнителни алгоритми се разписват с

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

Теоретичната база на структурното програмиране е в т. нар. "теорема на

структурното програмиране", наречена още "теорема на Böhm-Jacopini", постулираща,

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

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

последователни оператори (sequence); условни преходи (selection); цикли (iteration).

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

централния процесор, както и работата на Тюринг машината. Затова процесорът

всъщност винаги изпълнява "структурирана програма". Самата теорема пряко не

адресира начините на написване на програмите, но дава основа за развитие на

20

методологията през 60те и 70те години от хора като Edsger W. Dijkstra, Robert W. Floyd,

Tony Hoare, Ole-Johan Dahl, и David Gries.

Началото на тези идеи е от работи на Дийкстра (нач. 1965 г.), обсъждащи

вредното влияние на използването на оператора за безусловен преход "goto".

Паралелно в работите си той развива идеите на низходящото

проектиране/програмиране (top-down). Пълното отричане на оператора, разбира се,

остава неподплатено. Самият Кнут през 1974 в своята статия "Structured Programming

with GOTO Statements" изтъква, че наличието или отсъствието на оператор goto само по

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

налага общото виждане за структурното програмиране като "ориентирано към

общуване на програми с хора, а не към общуване между програми и компютри". За

изпълнение на тоя критерии се оформят следните изисквания [Dahl, Dijkstra & Hoare,

1972]:

1. Програмният текст се съставя от три основни елемента – последователност,

разклонение и повторение (произтичащо от теоремата на Böhm-Jacopini);

2. Всеки програмен модул се организира така, че да има един вход и един изход;

3. Употребата на оператор goto трябва да се избягва навсякъде, където е

възможно;

4. Програмният текст се записва в добър и приемлив стил;

5. Програмният текст да се структурира с изместване и вмъкване на празни

позиции в редовете с цел леко да изпъкват операторите от тялото на оператор за

цикъл, както и ясно да се открояват групата оператори от клаузите then и else в

условните оператори;

6. Програмният текст физически да се разбива на части така, че изпълнимите

оператори от един модул да заемат обем една печатна страница;

7. Програмата да е просто и ясно решение на конкретната задача.

Независимо от развитието на различните парадигми в програмните езици, част от

тези принципи остават основополагащи за изграждането на "красив" стил на

програмиране.

21

Обектно-ориентирано програмиране (Object-oriented programming)

При обектно-ориентираното програмиране (ООП) една програмна система се

моделира като набор от обекти, които взаимодействат помежду си. Всеки обект има

свои собствени данни и програмен код и вътрешно разчита на себе си. Всеки обект е

способен да получава съобщения, обработва данни и праща съобщения на други

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

йерархия от слоеве. ООП дава повече гъвкавост на програмите, по-лесен е за

разработване и поддържане и намира все по-широка популярност в софтуерното

инженерство на мащабни проекти.

Основни понятия в ООП са:

Обекти: Обектите от реалния свят се отличават със своите състояния

(характеристики) и поведение (възможните действия, които могат да извършват).

Софтуерните обекти наподобяват обектите от реалния свят, обединявайки данни и

функционалност заедно в обособени единици. Един обект съхранява състоянието си в

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

методи (функции в някои езици за програмиране). Формалното описание на типовете

обекти става чрез т.нар. класове. Класът съдържа обекти (от по-нисш порядък) и

методи (задаващи спецификата на този клас). Обектът е инстанция на класа, който я е

създал, и притежава неговите характеристики (данни и методи), отразявайки

йерархията и "родствените" връзки на съответния клас.

Абстракция: Това на практика е способността на една програма да игнорира

някои аспекти на информацията, с която работи и да се съсредоточи върху

същественото. Всеки обект в системата служи като модел на един абстрактен агент,

който може да общува с други обекти в системата и външния свят без да разкрива как

са реализирани свойствата му. Процесите, функциите или методите също подлежат на

абстракция като се използват разнообразни техники за разширяване на една

абстракция.

Капсулиране: Механизмът, известен като капсулиране, е основен принцип на

обектно-ориентираното програмиране. При него потребителите на даден обект не

могат да променят неговото вътрешно състояние по неочакван начин; само

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

22

интерфейс, който определя как другите класове могат да взаимодействат с него.

Класовете действат на принципа на черната кутия за другите класове и останалата част

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

да бъде променяна в аспекти, които не са достъпни чрез интерфейса, без това да

изисква промени в потребителските програми. Самите обектно-ориентирани езици

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

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

Полиморфизъм: Полиморфизмът позволява третирането на обекти от наследен

клас като обекти от негов базов клас. Полиморфизмът напомня на абстракцията, но в

програмирането се свързва най-вече с пренаписването (override) на методи в

наследените класове с цел промяна на оригиналното им поведение, наследено от

базовия клас. Абстракцията се свързва със създаването на интерфейс на компонент или

функционалност (дефиниране на роля).

Наследяване: Наследяването организира и подпомага полиморфизма и

капсулирането, като позволява да бъдат дефинирани и създавани обекти, които са

специализирани варианти на вече съществуващи обекти. Новите обекти могат да

използват (и разширяват) вече дефинираното поведение, без да е необходимо да

реализират това поведение отново. Това обикновено се прави чрез групиране на

обектите в класове и дефиниране на нови класове, които разширяват съществуващи

класове и подреждане по този начин на класовете в дървета или решетки, отразяващи

сходствата в тяхното поведение.

Много от най-широко използваните езици за програмиране поддържат обектно-

ориентирано програмиране, обикновено в комбинация с процедурно програмиране.

Най-често използваните обектно-ориентирани езици в момента включват Python, C#,

C++, Delphi, Java, Perl, Ruby и PHP.

Парадигмата на ООП по своята същност не е парадигма на програмирането, а на

проектирането. Една система се изгражда чрез дефиниране на обектите, които ще

съществуват в нея, а кодът се капсулира вътре в обектите. Предизвикателството в ООП

е проектирането на добре обмислена система от обекти.

23

Компонентно-ориентирано програмиране (Component-Oriented

Programming)

Разбивката на проекта на логически компоненти е същността на обектно-

ориентираното проектиране. Това е и основата на компонентния софтуер, който е

съставен от парчета софтуер за многократна употреба в двоичен вид (за разлика от

изходния код), които със сравнително малко усилия могат да бъдат включени в

компоненти от други доставчици.

Компонентно-ориентираното програмиране възниква като надграждаща

парадигма над ООП, въвеждайки редица ограничения върху ООП с цел повишаване на

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

нестабилните базови типове (fragile base classes) и възниква когато промяната на

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

функциониране на типовете-потомци. За тази цел в компонентно-ориентираното

програмиране се забранява наследяването на типове, реализирани в други модули;

наследяването става само чрез чисто абстрактни интерфейсни типове.

Важен принцип на обектно-ориентираното програмиране, който компонентно-

ориентираното програмиране използва с пълна сила, е капсулирането. Капсулирането

крие изпълнението на обекта от потребителите на обекта. Те имат достъп само до

интерфейса на обекта. Разработчиците, които използват предварително създадени

обекти в техните проекти, се интересуват само от "обещаното"поведение на обекта,

дефинирано в неговия интерфейс. Всеки обект декларира какво е способен чрез

прилагане на определени интерфейси. Такъв договор е основата за оперативна

съвместимост, чието насърчаване е една от основните цели на компонентно-

ориентираното програмиране.

За комуникацията между отделните компоненти се използва "интерфейс", който

представлява семантично свързан набор от методи, групирани заедно под едно име

(напр., API Win32 е интерфейс към функционалността на операционната система

Windows). Интерфейсът е строго определена договореност между софтуерната

компонента и нейните клиенти; това е изразяването на очакваното поведение от нея,

без на програмиста да се налага да се интересува от начина на реализиране на

24

съответната компонента. В случай, че два обекта прилагат едни и същи интерфейси, те

са полиморфни.

В света на софтуера няма по-добър пример за въздействието на компоненти от

тази на ActiveX контролите. Това е софтуерна рамка, създадена от Microsoft, която

адаптира техните предишни COM (Component Object Model) и OLE (Object Linking and

Embedding) технологии с разширение в контекста на WWW. Води се, че е независима от

Microsoft Windows, но повечето компоненти изискват изпълнение върху хардуер от

типа Intel x86, доколкото съдържат вече компилиран код за този вид хардуер.

Множество приложения за Microsoft Windows (вкл. такива като Internet Explorer,

Microsoft Office, Microsoft Visual Studio, Windows Media Player) използват ActiveX

контроли за да реализират набор функционални възможности, които капсулират в

собствени ActiveX контроли за използване в последващи приложения.

Aгентно-ориентирано програмиране (Agent-Oriented Programming)

Агентно-ориентираното програмиране е програмна парадигма, при която

основополагаща концепция се явява понятието "агент" и неговото "мисловно

поведение" в зависимост от "средата, в която се намира". Концепцията е предложена

от Yoav Shoham през 1990 г като самият той дава следното определение на

парадигмата: "Тази нова парадигма за програмиране съвсем основателно може да се

нарече рационално планиране. Точно както парадигмата на обектно-ориентираното

програмиране измества писането на процедури към създаване на обекти, така

рационалното програмиране измества създаването на информационни обекти към

създаването на мотивирани агенти" [Shohamр 1990]. Агент се явява всичко, което може

да се разглежда като възприемащо своята среда с помощта на рецептори и

въздействащо на тази среда чрез изпълнителни механизми.

В обектно-ориентирания подход изчислителният процес се възприема като

система, съставена от обекти, които си взаимодействат чрез съобщения. Агентно-

ориентираният подход специализира тези понятия като установява състояния

(наречени "психически състояния") на обектите (наречени "агенти"), състоящи се от

такива компоненти като вярвания (убеждения – за света, за другите, за себе си),

способности и решения, всяко от които има определен синтаксис.

25

Наличието в агента на механизъм за целеполагане предоставя ново ниво на

автономност. Агентът не винаги изпълнява разпорежданията на друг агент или на

потребителя; той просто зависи от условията на околната среда, включително от целите

и намеренията на други агенти. За разлика от обекта, агентът може да поеме

определени задължения или, обратно, да откаже да извърши определена работа,

поради липса на компетентност, заетост с друга задача и др. В същото време, агентът

може да извършва такива действия като създаване, подтискане, замяна на други

агенти, активиране на функции (както собствени, така и на други агенти), активиране на

сценарий, запомняне на текущото състояние на други агенти, и т.н.

Причините за възникване на агентно-ориентирания подход са:

(1) необходимостта ат преодоляване на границите на операционните среди и

(2) отстраняване на разнородността на обектните модели от различията, породени от

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

Като цяло, една система за агентно-ориентирано програмиране трябва да

включва следните базови компоненти:

ограничен формален език със съответните синтаксис и семантика за описание

на вътрешното състояние на агента, което се определя от няколко

параметъра от типа на убеждения, желания, намерения и задължения;

език за програмиране на спецификациите на агентите, включващ примитивни

команди от типа на Request и Inform;

агентификатор, преобразуващ неутралните компоненти в програмируеми

агенти.

Основните свойства, които следва да притежават агентите са: автономност

(способност да изпълняват действия самостоятелно); хомогенност/хетерогенност

(способност да обединяват еднородни или разнородни функции); наличие на

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

ефективността); активно поведение (постоянен обмен на информация вътре в агента и

между агентите); комуникативност (обмен на данни с външната среда); възможност за

възприятие на средата (наличие на специални средства за възприятие на средата, в

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

програмни и физически среди или компоненти).

26

Примери за агентни езици и съответни обектни среди са, JADE, Jason, SARL.

Aспектно-ориентирано програмиране (Aspect-Oriented Programming)

Основното предимство на обектно-ориентираното програмиране е възможността

да моделира и декомпозира ефективно предметни области от реалния живот,

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

този процес. Капсулирането на обектите в класове е наистина ефективна техника в

голяма част от случаите, тъй като с обектния модел лесно се осъществява описание

върху съответните предметни области. Проблемът е, че съществуват много и различни

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

фази на един проект. Капсулирането на обектите води до разпръскването на

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

различни отношения в общ елемент на системата (оплетен код) [Kiczales, 1997]. Или,

както се казва, от отношенията започнат да имат допирни/пресечни точки – появяват се

т.нар. crosscutting функционалности. Типичен пример за crosscutting функционалност е

кодът за трасиране – той обикновено е преплетен с кода, изпълняващ основната логика

на програмата. Аспектно-ориентираното програмиране допълва обектно-

ориентираното програмиране чрез добавяне на нов тип модулност, приличаща на

класа, но с още по-висока степен на абстракция, наречена "аспект". Аспектите могат да

се отнасят до много класове. Те използват т.нар. "точки за вмъкване" (insertion points)

за да реализират регулярни действия, свързани например със сигурността на данните, с

обработка на грешки и т.н. Използвайки аспекти, програмирането на crosscutting

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

използване на вече написаните веднъж аспекти.

Аспектно-ориентираното програмиране се въвежда като понятие от групата на

Gregor Kiczales от Xerox PARC през 1995 (терминът е предложен от члена на групата

Chris Maeda) и предлагат първото практическо разширение AspectJ за Java. Пакетът

успешно се интегрира със среди за разработка като Eclipse, Sun ONE Studio и Borland

JBuilder. Изследователският екип на IBM последва подхода, предлагайки Hyper/J през

2001, но тя не добива особена популярност.

27

Понастоящем, множество програмни езици имат възможност за прилагане на

аспектно-ориентирано програмиране в рамките на езика или като външна библиотека,

като: API за .NET (C# / VB.NET); C / C++; Delphi; AspectJ за Java; JavaScript; Matlab; Perl;

PHP; Prolog; Python; Ruby и др.

Функционално програмиране (Functional programming)

Функционалното програмиране е подмножество на декларативното

програмиране, което разглежда процеса на изчисление като оценка на функции.

Функционалните езици не толерират промени в стойностите на променливите чрез

присвояване. В основата на изпълнението на програмите е заложена рекурсия.

Системите за функционално програмиране предоставят на програмиста богато

множество от базови функции, както и средства за дефиниране на нови потребителски

функции от базовите, с което се постига решаване на поставения проблем. Типични

представители на езиците за функционално програмиране са Lisp, Scheme, Erlang,

Haskell и др.

Логическо програмиране (Logic Programming)

Логическото програмиране е друго подмножество на декларативното

програмиране. Това е парадигма в програмирането, основана на автоматическото

доказателство на теореми, използваща теорията и апарата на математическата логика,

а също така и раздел от дискретната математика, изучаващ принципите на логически

извод на основата на зададени факти и правила за извод. Логическото програмиране

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

Водещият принцип тук е:

правила + факти = програми

Изпълнението на една програма от логическото програмиране се свежда до

последователно обхождане на предварително изградена база данни, съдържаща

множество правила и факти от определена предметна област докато се получи

удовлетворителен отговор или се окаже, че системата от зададени правила и факти не

съдържа такъв. Най-известният език за логическо програмиране е Prolog.

* * *

28

Някои програмни езици са проектирани да поддържат определена парадигма на

програмиране, напр. Java поддържа събитийно-управляемо програмиране, докато Lisp

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

езици за програмиране поддържат повече от една парадигма – например C++ и Object

Pascal поддържат и обектно-ориентирано програмиране, и процедурно програмиране.

Често парадигмите на програмиране са познати повече с това какво забраняват,

отколкото какво препоръчват. Например функционалното програмиране забранява

използването на странични ефекти, структурното програмиране забранява употребата

на "goto". Затова, програмистите, свикнали вече с някакъв стил на програмиране

трудно възприемат различната парадигма. Но в действителност избягването на

определени техники улеснява разбирането на поведението на програмата без да

намалява изразителната сила на програмния език. Напротив, чрез прилагането на

определения стил се използват най-силните качества и на дадения език.

29

Глава 3.

Среди за разработка на програмни приложения

Създаването на дадено приложение най-общо преминава през няколко стъпки,

като за всяка от тях са необходими съответни инструментални средства. Към тези

средства като минимум се включват: редактори на програмен код, езикови процесори

(транслатори), свързващи редактори, инструменти за проверка за грешки (дебъгери),

среда за изпълнение на програмите с цел тяхното тестване (run-time environment),

библиотеки с програмен код.

3.1 Основни типове инструменти, изграждащи система за

програмиране

Тук ще се спрем накратко на класическите инструменти и техните специфики.

Редактори на програмен код

Тези редактори се използват за създаване и изменение на текстови файлове,

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

и обикновените текстови редактори, но специализираните текстови редактори

поддържат функции, улесняващи програмирането на съответния език: цветово

различаване на служебни думи, функции, класове, автоматична табулация,

интелигентни предложения за завършване на програмния код (intelligent code

completion) и др.

Транслатори

Едновременно с развитието на езиците за програмиране се развиват и

транслаторите. Транслаторът е програма, която превежда изходната програма в

машинен код. Според начина, по който се осъществява това превеждане,

транслаторите биват: компилатори и интерпретатори.

30

Компилаторът превежда текста на една програма, написана на език от високо

ниво в семантично отговарящ код на език от (обикновено) по-ниско ниво. Целевият

език може да бъде машинен език или асемблерен език за конкретен процесор или

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

частност и друг език от високо ниво. Когато се компилира до машинен език, крайният

продукт е изпълнима програма или обектен код.

Интерпретаторът изпълнява програмата оператор по оператор, като в момента на

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

инструкции.

Таблица 1. Сравнение на характеристики на компилаторите и интерпретаторите

Компилатор Интерпретатор

Компилаторът преобразува изходния код

в двоични инструкции за определена

процесорна архитектура, като по този

начин се намалява мобилността.

Интерпретируемите програми се

превеждат на конкретната потребителска

машина, което прави програмното

разпространение независимо от

компютърната архитектура.

Превръщането се прави веднъж, в

средата на разработчика, и след това

получените файлове с машинни

инструкции могат да бъдат изпълнявани

на потребителски компютри с

необходимата процесорна архитектура

без допълнителна транслация.

Превръщането се прави при всяко

изпълнение на програмата и зависи от

наличието на съответната машина на

подходящ интерпретатор, което

усложнява и цялостния процес на

инсталация.

Изпълнението на компилираните

програми е бързо:

- при стартиране на компилиран код

само се изпълняват операциите в

логическа последователност зададена

при компилирането;

- адресацията на променливите е

направена още по време на

Изпълнението на програмите чрез

интерпретатор винаги е по-бавно:

- интерпретаторът трябва да анализира

всеки израз в програмата всеки път

когато се изпълнява и чак след това да

извърши необходимата операция;

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

поради непрекъснатото адресиране на

31

компилирането и свързването и при

изпълнението не се губи време за

това.

идентификаторите по време на

изпълнение.

При създаване и тестване на кода на

програмата – цикълът "редактиране-

компилиране-стартиране-дебъгване" е

по-дълъг.

При създаване и тестване на кода на

програмата – цикълът "редактиране-

интерпретиране-дебъгване" е по-кратък.

Създаването на компилатор на езика е

по-трудна задача.

Създаването на интерпретатор е много

по-лесно от създаването на компилатор.

Свързващи редактори

По-големите програми обикновено се състоят от отделни обособени части. След

компилиране на отделните части, те трябва да се свържат в едно цяло. В една обща

изпълнима програма се обединяват няколко обектни модула и библиотеки. Тази

дейност се извършва от специализирана програма на системата за програмиране,

наречена свързващ редактор. Свързващият редактор (на английски: Linker, линкер) е

основна компютърна програма, чиято цел е да свърже компилирани в машинен език

един или повече обектни файлове в една програма, която може да се управлява от

дадена операционна система. Свързващият редактор има грижата и за организирането

на обектите в програмното адресно пространство. Това може да включва преместване

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

необходимостта от пренасочване на абсолютни скокове, входни и изходни точки.

Дебъгери

Бъг (англ. bug - буболечка) в компютърния жаргон се разбира грешка по време на

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

на програмата в определена ситуация. Процесът на отстраняване на грешките се

нарича дебъгване.

Дебъгер (от английското debugger) е компютърна програма за проследяване на

процеса на изпълнение на компютърни програми с цел намиране на грешки (наречени

"бъгове"). Този тип програми се използва от програмисти за тестване на новосъздадени

32

продукти, за да се предотвратят възможни неизправности в процеса на работа на

дадения продукт. Дебъгерите предоставят средства за трасиране (стъпково изпълнение

на програмата и подробен запис на последователността от действия по време на

изпълнение), за наблюдение как се променят стойности на променливи и дават

възможност за установяване точки на прекъсване в настройваната програма.

фиг. 2. Първият компютърен "бъг" 4

Среда за изпълнение на програми (RTE)

По време на изпълнението си дадена програма може да изпраща инструкции към

процесора, да изисква оперативна памет или други системни ресурси. При създаването

на програмите програмистите се нуждаят от среда, в която да тестват изпълнението им

и да наблюдават процеса и евентуалните възникнали грешки. Тази задача се

подпомага от специализирани средства, създаващи "среда за изпълнение на

програми" (RTE – Run-Time Environment). Ако програмата се срине, RTE софтуерът

продължава изпълнението и изпраща важна информация за евентуалните причини,

поради които се е сринала програмата. Освен в средите за разработка, RTE програми се

използват и от обикновените потребители, напр. Adobe Flash Player и Microsoft

PowerPoint Viewer осигуряват среда за изпълнението на съответни файлови формати.

Най-често срещаният тип RTE, обаче, е на Java RTE (или JRE), която позволява на Java

аплети и приложения да се изпълняват на всеки компютър с инсталиран JRE.

4 Оригиналът е запазен в компютърния дневник на групата, работила с компютъра Mark II в

Харвардския университет през 1947 г. Ръководителят на групата Грейс Хопър нарекла операцията

по отстраняване на този молец в едно от релетата на компютъра, който пречел на правилната му

работа, "debugging".

33

Библиотеки

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

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

програми. Това позволява споделяне и промяна на данни и код на модулен принцип.

Библиотеките за езиците с интерпретатор са файлове, които съдържат или код на

езика, или псевдокод за виртуалната машина, за която са предназначени.

Библиотеките, използвани при компилируемите езици, се делят на статични и

динамични.

Статичната библиотека представлява файл с изходен код, който се преобразува от

компилатора в обектен файл или пряко се разпространява като обектен файл, който се

включва в програмата на етапа на свързване. Предимството на този тип включване е,

че всички необходими функции са в един изпълним файл. Недостатъците са, че

изпълнимият файл заема повече дисково и оперативно пространство, както и при

необходимост от промяна в кода на библиотечен модул е необходимо

прекомпилиране на програмата.

Динамичните библиотеки са файлове, които съдържат машинен код.

Зареждането им в паметта става или при създаването на процеса, или при заявка от

вече работещия процес. Спрямо своето предназначение се различават: (1) библиотеки,

които се използват от една програма и съдържат критически за работата й функции

(т.е. ако библиотеката липсва програмата не може да работи); (2) библиотеки,

използвани от една програма, но съдържащи допълнителни функции: например,

библиотека на модули, разширяващи функционалността на системата – т.нар. plug-ins;

и (3) библиотеки за общо ползване (shared libraries), които съдържат функции,

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

операционната система за икономия на памет (едно копие на библиотеката се

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

За целите на проекта интерес представляват следните типове библиотеки:

DLL (Dynamic-Link Library) – програмна библиотека употребявана от Microsoft Windows,

която включва и ActiveX контролите и драйверите; VCL (Visual Component Library) –

библиотека от визуални компоненти за Delphi; LCL е еквивалента на VCL за Lazarus.

34

3.2 Интегрирани среди за разработка

В класическия вариант всяка от функциите по създаване на едно приложение

работи като отделна програма, всяка със собствен интерфейс. В последните години

отделните програми, включени в групата инструментални средства, се обединяват в

т.нар. интегрирани среди за разработване (IDE- Integrated Development Environment).

Интегрираните среди се използват широко в практиката, тъй като те осигуряват лесна и

удобна и по-производителна работа на програмистите в единна среда. Освен

класическия мининум от елементи съвременните интегрирани среди за разработване

често включват доста повече неща като: инструменти за контрол на версиите, средства

за управление на проекти, библиотеки с шаблони за различни типове проекти, както и

браузъри на класове, диаграми на йерархията им, средства за интегриране на нови

компоненти в средата, за генериране на документация, инсталатори и други

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

[Иванова, 2010].

Интегрираните среди за разработка са създадени за да максимизират

производителността на програмистите, благодарение на тясното свързване на

необходимите компоненти чрез използване на единен потребителски интерфейс. Така

разработчикът се освобождава от необходимостта постоянно да превключва между

различните режими, като по този начин позволява на програмиста да се фокусира

върху решения за алгоритмични проблеми без да губи време в чисто технически

действия. От друга страна, тъй като интегрираната среда за разработка е сложен

програмен комплекс, за пълното използване на възможностите е необходимо

специално обучение. За преодоляването бариерата при прехода от един към друг

интерфейс производителите обикновено предлагат многоезичност в рамките на обща

платформа. Също така, интегрирането на задачите за развитие може допълнително да

подобри производителността чрез възможността за въвеждане на допълнителни

функции на междинни етапи (напр. с автоматичното "завършване на кода" по време на

писането или незабавните съобщения за допуснати синтактични грешки).

Допълнителна възможност вследствие на интеграцията е работата с много езици.

Повечето среди поддържат множество езици, напр. Eclips е написан основно на Java,

но чрез множество плъгини наборът от езици, които могат да се използват става Ada,

35

ABAP, C, C++, COBOL, Fortran, Haskell, JavaScript, Lasso, Lua, Natural, Perl, PHP, Prolog,

Python, R, Ruby (вкл. Ruby on Rails framework), Scala, Clojure, Groovy, Scheme и Erlang, а

също може да се използва за писане на пакети в Mathematica. Превключването на

езика става на базата на автоматично разпознаване на разширението на файла или

чрез настройки на средата или на проекта.

По-конкретна информация за основните IDE, разделени по езиците и

платформите, които поддържат, и наличието или липсата на някои основни

характеристики на средите, може да се види на

https://en.wikipedia.org/wiki/Comparison_of_integrated_development_environments

Първите интегрирани среди за разработка стават популярни още преди появата

на операционните системи с графичен интерфейс – функционалността на текстовия

интерфейс при тях се допълва от множество "горещи" клавиши за извикване на

различни функции (например особено популярния за времето си Turbo Pascal на

Borland).

Много от съвременните интегрирани среди са ориентирани към създаване на

приложения за операционни системи с графичен потребителски интерфейс (GUI –

Graphical User Interface) и самите те са основани на такъв (GUI builder или GUI designer).

GUI дизайнерите са средства, които позволяват на проектантите да аранжират

графичните контролни елементи (т.нар. widgets – командни бутони, текстови кутии,

радиобутони, кутии за отметки и др.) чрез т.нар. drag-and-drop редактори, поставяйки

ги на желани от тях места върху програмната форма или фрейм. Писането на редовете

програмен код за описание на разположението на интерфейсните елементи се поема

от GUI дизайнера. Тези програми обикновено използват събитийно-ориентирано

програмиране, така че GUI редакторите се грижат за опростяването и за създаването на

кода по обслужване на събитията. Типични представители на интегрирани среди за

разработка с графичен потребителски интерфейс са Eclipse и Delphi.

36

3.3 Облакови интегрирани среди за разработка (Cloud IDE)

Онлайн интегрираните среди за разработка позволяват изграждане, тестване и

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

на HTML5, нарастващите тенденции към мобилност, развитието на облаковите услуги и

на софтуера с отворен код. Ползите от облака включват достъпност от всяка точка на

света, от всяко съвместимо устройство; минимално до несъществуващо изтегляне и

инсталиране; лекота на сътрудничеството между географски разпръснати

разработчици. Тези плюсове, разбира се, се плащат със зависимостта от наличие на

(надежден) интернет.

По мнения на разработчици тези интегрирани среди все още дразнят със своята

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

технологията на разпределение на ресурсите.

Често пъти облаковите среди не само са базирани в облака, но и са

предназначени за създаването на облачни приложения, други са оптимизирани за

създаване на приложения за смартфони, таблети и други мобилни устройства.

Следва да отбележим наличието на българска следа в това направление –

компанията Telerik развива единствена по рода си на пазара платформа за разработка

на приложения от край до край за всеки екран, операционна система, устройство или

технология - Telerik Platform.

По-долу ще представим мнения на потребители на такива среди за това какво

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

базирано на данни от платформата за споделяне на мнения спрямо продукти и

разработки Slant [slant, 2015]. В челото на използваните среди са Codenvy (SaaS или on-

premises, базирана на Eclipse Foundation's Che project) и Codeanywhere (колаборативна

платформа). Извън коментарите са останали платформи като Collide (Google open

source project) и Orion (open source project under the Eclipse top-level project).

37

Таблица 2. Мнения на потребители за по-известните онлайн интегрирани среди за разработка (по данни от www.slant.co, май 2015)

Online IDE

(мнения +/-)

pros cons

Codenvy

(60/4)

Easy setup

On-demand, instant-access, real-time collaborative IDEs

Powerful editor

Git support

Can provide a custom runtime environment

Fantastic Java support

Complete build lifecycle

Open source

Has a fully functional free tier

Beginner-friendly

Integrates with a wide variety of tools

Has Eclipse plugin

Provides a terminal with root access

Self-hostable

Lots of built-in templates

Can be used for Android development

Nice interface

Custom build system support

Quick support from staff

Includes Subversion support

No IE support

Lacks drag and drop support

No custom keyboard shortcuts

No SSH, FTP mode

No PHP syntax highlighting

Lacks two-factor authentication

No debug for PHP

Codeanywhere 

(55/1)

Has mobile apps for all major mobile OSs

Dropbox and Google Drive support

Unlimited revisions

Full terminal access

GitHub Integration

BitBucket Integration

SFTP access

Allows inviting collaborators with a link

Multiple devboxes

Good editor

Web editor on iPad is severely

lacking

No Java

38

Cloud9 

(40/4)

Full terminal access

Provides with own runtime environment

Git & Mercurial support

Capable editor

Can be hosted on own server

Enables real-time online collaboration

Debugging with breakpoints for NodeJS server side JavaScript

Provides with a simple way to deploy apps

Offline editing

SSH Workspace

Browser testing support

Package manager

Support for most databases

Ability to clone multiple repos in one project

Great documentation

Runs any language

Lacks a built-in Java builder and

runner

Lacks subdomain options

SourceLair 

(32/0)

Simple and efficient interface

Django stack, out of the box

GitHub Integration

Git & Mercurial support

Has a free tier

PHP real-time Preview

Koding

(30/0)

Free VM with root

Everything's supported

Ability to signup with Github

Real-time collaboration

Built-in terminal

Various file upload options

Communities

Built-in package manager

Unlimited domains and subdomains

Great community

Optional Paid VMs

Social Stream

Capable editor

Poor uptime

Bad performance and latency

issues

39

Nitrous

(16/0)

GitHub Integration

Desktop application

Upgradeability

Live online support

Erlang support

Heroku, Azure, Nodejitsu integration

Customizable Development Environment

World Accessible URLs - Preview Your Application

JSFiddle

(12/0)

CoffeeScript and scss support

Supports a wide variety of frameworks and extensions

Allows collaborating on code

Codio

(9/1)

Server-side environment

Fully functional terminal

Node.js included by default.

Monokai

Emmet

BitBucket integration

Private projects aren't free

ShiftEdit

(7/0)

Supports multiple file access points

Syntax checking

Supports autocomplete

Low cost, high quality

StackHive

(3/0)

Supports Bootstrap

FP Complete

(3/0)

Focuses on Haskell (The world’s first commercial Haskell IDE and

deployment platform)

Haskell packages can be easily managed

Compilr

(3/0)

Supports a wide range of languages, including Node.js

Neutron Drive

(3/0)

Realtime Collaboration

Syntax highlighting (40+ Language Modes)

Detailed Change Tracking

latex syntax highlighting

Does not Support Git

Monaco

(Visual Studio

Online)

(1/0)

Continuously Improving

Free Learning Resources

Easy deploy and remote debug options

CodeTasty

(1/0)

Best code completion for php, javascript and css.

40

3.4 RAD технология

Бързата разработка на приложения (Rapid application development – RAD) е

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

внимание върху процеса на развитие и осигуряване на качество на разработвания

софтуер. Той възниква през 80те години с появата на графичните като алтернатива на

конвенционалните модели тип "водопад" за разработка на софтуер, които наблягат на

строгата спецификация и планиране на проекта.

RAD подчертават необходимостта от адаптиране на изискванията, в отговор на

знанията, придобити с напредването на проекта. RAD подхода предполага гъвкав

процес на прототипиране, който може да се адаптира спрямо развитието на проекта.

Графичните среди за разработка (GUI builders) го правят особено подходяща

технология за разработване на софтуер, в който потребителският интерфейс е от

водещо значение.

фиг. 3. Схема на RAD процеса

Прототипирането има редица предимства пред традиционното определяне на

спецификации като:

намаляване на риска. Прототипите дават възможност да се тестват някои

потенциално трудни части на системата още в началото на жизнения цикъл и

навреме да бъде търсено и намерено друго решение;

по-добро взаимодействие с потребителите. При изпитването на прототипите

потребителите по-лесно могат да дадат допълнителна информация в

движение, вместо абстрактно да определят в началото какво трябва да

съдържа системата;

41

самите прототипи могат да бъдат използваеми докато еволюират до

завършен продукт. Един от подходите, използван в RAD технологията е за

изграждане на системата като серия от прототипи, които се развиват от

разгръщаща се функционалност до умерено полезна за крайния потребител

завършена система.

Първата RAD алтернатива е създадена от Barry Boehm и е позната като спирален

модел [Boehm, 1988]. По-късно James Martin развива RAD метода, който публикува в

книга със заглавие "Rapid Application Development" [Matrin, 1991]. Оттогава започва

конфузно объркване на термините RAD като обща алтернатива на модела на водопада

и специфичната методология RAD, описана от Джейм Мартин. Идеите по-късно се

доразвиват от James Kerr and Richard Hunter в книгата им "RAD – как да създадем

напълно функционална система за 90 дни" [Kerr & Hunter, 1993], в която проследяват

развитието на реален проект, изпълняван чрез използване на RAD методологията.

Благодарение на тях и подобни практици RAD технологиите печелят особена

популярност като алтернатива на традиционните последователни методи на жизнения

цикъл.

Подходът на Джеймс Мартин разделя процеса на четири отделни фази:

1. Планиране на изискванията - Потребителите, мениджърите и ИТ членовете

обсъждат и договарят бизнес нуждите, обхвата на проекта, ограничения и

изисквания към системата. Фазата завършва, когато групата постигне съгласие

по ключовите въпроси и получи разрешение от ръководството да продължи.

2. Дизайн на потребителския интерфейс - Потребителите взаимодействат със

системните анализатори и развиват модели и прототипи, които представят

всички процеси, входове и изходи. RAD-групите обикновено използват

комбинация от техники на Joint Application Development (JAD) и CASE за превод

на нуждите на потребителите в работни модели. Това е непрекъснат

интерактивен процес, който позволява на потребителите да разберат,

променят, и накрая да одобрят работен модел на системата, който отговаря

на техните нужди.

3. Изграждане – Фокусът е върху разработката на програмата и нейните

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

42

интеграция на системата и тестване. Потребителите следят изпълнението и

могат да предлагат промени или подобрения.

4. Завършване – Крайните задачи по завършване на системата, включващо

елементи като преобразуване на данни, тестване, преминаване към новата

система, обучение на потребителите като те се извършват взаимосвързано и

по този начин много бързо новата система е изградена, доставена и пусната в

експлоатация.

Плюсове и минуси на RAD

Плюсовете на RAD технологията включват:

по-добро качество – включването на потребителите в процеса на изграждане

на прототипите води до много по-добра функционалност. Така софтуерът има

по-голям шанс да се фокусира върху бизнес проблемите, които са от

решаващо значение за крайните потребители, а не технически проблеми от

интерес за разработчиците;

контрол на риска – Подходът на RAD позволява съсредоточаване в началото

върху основните рискови фактори и регулирането им по време на процеса на

базата на събрани емпирични факти;

повече проекти, завършени в срок и в рамките на бюджета – Чрез фокусиране

върху развитието на отделните звена шансовете за катастрофални сривове е

силно намален спрямо метода на водопада, при който грешка, водеща до

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

края на целия процес.

Минусите от прилагането на RAD може да се изразят в:

риск от прилагането на нов подход – като всеки нов подход RAD изисква

професионалистите да преосмислят начина, по който работят;

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

водопада, потребителите определят изискванията си в началото и след това

отделят време чак на финалния етап на приемане на готовата система. При

RAD технологиите потребителите взаимодействат с разработчиците почти

през целия жизнен цикъл на разработване. Плюсът от по-тесния контакт с

43

потребителите с цел създаване на по-адекватен на нуждите продукт има и

своята обратна страна, че бизнесът трябва да е готов да отдели от времето на

експертите си в сферите на приложение на продукта;

по-слаб контрол за сметка на осигуряването на гъвкавостта. Налице е

неизбежен компромис между гъвкавост и контрол – повече от едното

означава по-малко от другото. Затова прилагането на RAD при проекти,

реализиращи системи, нуждаещи се от строг контрол (напр. живото-

критични), е неуместно;

опасност да се изпусне цялостната архитектура на системата за сметка на

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

неподходящ за проектиране и реализиране на широкомащабни системи.

44

Глава 4.

Бази от данни

Комплексността на света предполага използването на описанията на дадени

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

С развитието на информационното обслужване са забеляни недостатъците от това тези

описания да се извършват за всяко специфично приложение поотделно. При такъв

начин на работа съхраняваните данни са с различни формати, дублирането на едни и

същи данни води до преразход на ресурси за съхранение и обработка, при всяка

промяна в данните или начина за съхранението им се налага модифициране на

използваните или създаване на нови програми.

Появата на понятието "бази от данни" става възможно с развитието на дисковите

устройства и възможността за директен достъп до данните. За рождена дата на "база

от данни" се приема м.юни 1963 г., когато фирмата SDC (System Development

Corporation) организира симпозиум на тема: "Разработка и използване на машинно

управляеми бази от данни". За оформянето на понятието фундаментално значение

оказват идеите на Чарлз Бахман (1964 – "A general programming system for random

access memories"), където той поставя първите проблеми на системите за управление

на бази от данни (СУБД). Работата на групата CODASYL (Conference/Committee on Data

Systems Languages), създадена през 1959 г също дава голямо отражение върху

развитието на концепцията за изграждане на СУБД и създаване на стандарти и

спецификации за езици за мрежови модели данни (CODASYL Data Model).

4.1 Определение

По същество базата от данни не е нищо повече от колекция от богически

свързани данни, структурирани по определен начин, която съществува дълъг период от

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

управление на базата от данни – СУБД. СУБД се състои от набор от компютърни

45

програми, контролиращи изграждането, поддръжката и използването на базата от

данни.

От СУБД се очаква да:

позволява на потребителя да създава нова база от данни и да специфицира

нейната схема (логическата структура на данните) с помощта на

специализиран език (т.нар. "Data-Definition Language");

дава възможност на потребителите да извличат данните чрез "заявки" и да

променят данните, с помощта на подходящ език (т.нар. "Query Language" или

"Data-Manipulation Language");

осигурява съхраняване на големи обеми от данни (в днешно време до

терабайти) за дълъг период от време с ефективен достъп до данните за

извличане и модификации;

осигурява издръжливост и възможност за възстановяване на базата от данни

при възникване на различни грешки, сривове или зловредни атаки;

контролира достъпа до данните от много потребители едновременно, без да

се допуска неочаквано взаимодействие между потребители (наречено

isolation) и без незавършени действия върху данните (наричано atomicity).

Първите важни успешни приложения на СУБД са били тези, при които се налага

оперирането с множество къси транзакции: приложения за резервации на билети,

банкови системи, бизнес системи за обработка и съхраняване на заплати, активи,

продажби и т.н.

Ранните СУБД изискват от програмиста да визуализира данните по начина на

съхраняване. Тези системи за бази от данни използват основно йерархичен и мрежов

модел за описание на структурата на информацията. В тези ранни СУБД все още няма

езици за заявки от високо равнище.

Важен тласък в развитието на СУБД предизвикват разработките на Едгар Код през

60те и 70те години по развитието на теорията на базите от данни и по-специално

развитието на релационните БД. Въведените идеи предполагат организиране на

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

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

46

от много високо ниво. С течение на времето SQL ("Structured Query Language") става

основният език за заявки въз основа на релационния модел. До 90те години на

миналия век релационните бази от данни господстват като норма в развитието на БД.

Постепенно, обаче, развитието на областта показва и нови подходи към

управлението на данните. Типични примери, които пораждат тази необходимост са:

специализираните индексни структури на Google, оптимизирани за заявките на

търсачките; системите за съхранение на сателитни снимки; хранилища като Flickr и

Amazon, съхраняващи милиони снимки и осигуряващо търсене в тях; системи за

съхранение и достъп до видеоинформация като YouTube и др.

4.2 Състав на СУБД

На фиг. 4 са представени компонентите на една цялостна СУБД. Единичните кутии

представят системните компоненти, докато двойните кутии представят структурите в

паметта (in-memory data structures). Плътните линии представят потоците на

управление и данни, докато пунктираните линии отразяват потоци, по които текат само

данни.

Като начало, нека уточним, че има два коренно различни източника на команди

към СУБД: (1) администраторът на базата от данни и (2) потребителите на базата от

данни.

Администраторът на базата от данни отговаря за описание на структурата или

схемата на базата от данни и за тази цел използва езикът за описание на данните (DDL:

Data-Definition Language). Командите на този език се анализират от DDL-процесора и се

предават на изпълняващия модул (execution engine), който след това ги предава на

мениджъра на индекси/файлове/записи (index/file/record manager) за промяна на

метаданните, които задават схемата на базата данни.

Обикновените потребители и приложни програми извличат или модифицират

данни, за чиято цел използват езика за описание на заявки (DML: Data-Manipulation

Language).

47

фиг. 4. Компоненти на СУБД [Molina et al, 2009]

Операторите на DML се делят на две подгрупи, както следва:

отговори на заявки: процесът преминава през превод и оптимизиране на

заявката от компилатора за заявки, в резултат на което се получава план на

заявката, който се подава на двигателя за изпълнение. Двигателят за

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

(записи или кортежи на връзки) към ресурсния мениджър. Ресурсният

48

мениджър работи с файловете с данни и индексните файлове, които се

използват за ускоряване на търсенето. По-нататък исканията за данни се

предават на буферния мениджър, чиято задача е да се съберат необходимите

части от данните от мястото им на постоянно съхранение (диск) в буферите на

оперативната памет. За тази цел той комуникира с мениджъра за съхранение.

Мениджърът за съхранение може да включва команди на операционната

система, но често СУБД-командите се отправят директно към контролера на

диска.

процесиране на транзакциите: както заявките, така и другите действия върху

данните се групират в транзакции, които се изпълняват атомарно и в

изолация една от друга. В допълнение изпълнението на транзакциите трябва

да бъде устойчиво, т.е. завършването на транзакцията трябва да бъде

осигурено дори при сривове на системата.

Данните в базата от данни, обикновено се съхраняват на външната памет, но за

изпълнението на операции върху данните те трябва да бъдат в основната памет. За

този трансфер се грижат мениджърът за съхранение и буферният мениджър. В

простите операционни системи ролята на мениджъра за съхранение се изпълнява от

операционната система. В определени случаи, обаче, СУБД поема директно контрола.

Буферният мениджър е отговорен за разбиването на наличната основна памет на

буфери, в които блоковете, четени от диска се разполагат. По този начин, всички СУБД

компоненти, които се нуждаят от информация от диска си взаимодействат с буферите и

буферния мениджър, пряко или чрез двигателя на изпълнение. Видът на

информацията, от която може да се нуждаят различни компоненти включва:

данни, които са съдържание на самата база от данни;

метаданни: схемата на базата от данни, която описва структурата и

ограниченията й;

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

статистики: събирана информация относно използването на базата от данни;

индекси: структурите от данни, които осигуряват ефективния достъп до

данните.

49

4.3 Организация на данните в базата от данни

Данните, с които работи приложната програма се наричат логически, а същите

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

Тези понятия се въвеждат, за да бъдат разграничени различните аспекти на

използването на данните: логически за програмиста и физически за ЕИМ.

Съществуват две нива на назависимост на данните: логическа и физическа

независимост на данните.

Логическата независимост на данните означава, че общата им логическа

структура може да бъде изменена, без да се променят използваните програми

(изменението, разбира се, не трябва да се състои в отстраняване от базата от данни на

такива елементи, които се използват от програмите).

Физическата независимост на данните означава, че физическото разположение

и организация на данните могат да се изменят, без това да налага изменение на

общата логическа структура на данните или програмите.

Добавянето на нови данни в един запис, без изменение на програмите, е

възможно, когато те работят на ниво поле, а не на ниво запис. Логическото описание на

данните за един програмист може да съдържа елементи, различни от тези на друг

програмист. Физическият запис обаче съдържа и двете групи елементи. Така от едни и

същи данни могат да бъдат формирани различни логически файлове за различни

приложения.

Физическата структура на данните представлява разположението на данните и

съществуващите между тях връзки на техническите носители на информация, както и

използваните методи за достъп до данните. Основните изисквания към физическата

организация на данните са необходимостта от икономия на външна памет и

осигуряване на възможност за бързо намиране и прочитане на записите. Тези две

изисквания определят съществуващото разнообразие на физически структури, които се

използват от програмистите за представянето на схемите и подсхемите на базата от

данни.

50

4.4 Архитектура на базата от данни

Изхождайки от основната идея на базите от данни за осигуряване на

независимост на данните (логическа и физическа), специализираната група по СУБД

към Американския национален институт по стандарти (ANSI/SPARC Study Group on Data

Base Management Systems) предлага следния референтен модел на архитектура на БД

(фиг. 5).

фиг. 5. Архитектура на бази от данни [ANSI/X3/SPARC, 1975]

Архитектурата е разделена на три основни нива:

външно – отразява отделните представи на потребителите към данните;

концептуално – акумулира обобщена представа на потребителите за

данните;

вътрешно – отговорно за физическото представяне.

Външният модел се явява информационното съдържание на базата от данни във

вида, в който си го представя конкретният потребител. Отделният потребител като

правило се интересува само от една конкретна, малка част от цялата база от данни.

Освен това, представите на потребителя за тази част на базата от данни са абстрактни

по отношение на това, как физически се съхраняват данните. Всеки външен модел се

определя посредством външна схема, която обикновено се състои от описание на

всички типови външни записи за този външен модел.

Концептуалният модел е представяне на пълно информационно съдържание на

базата от данни в абстрактна форма. Това представяне на данните по-скоро е близко

51

до данните такива каквито са, отколкото разбирането, което имат потребителите за тях,

под влияние например на конкретния език или техническите средства, които

потребителите използват. Концептуалният модел се състои от множество различни

типове концептуални записи. Моделът се определя посредством концептуална схема,

която включва определения за всеки тип концептуални записи. За да се постигне

необходимата независимост на данните, тези записи не трябва да бъдат обвързани със

структурата на съхранение на данните или стратегията за достъп, а трябва да определят

само информационно съдържание.

Концептуалният модел представя общото съдържание на базата от данни, а

концептуалната схема определя това представяне. Освен това в концептуалната схема

се включват много други допълнителни характеристики например за контрол на

достъпа до данните и други.

Вътрешният модел представлява най-ниското ниво на цялата база от данни и се

състои от различни екземпляри на типовете вътрешни записи. Описанието на

вътрешното ниво на представяне на базата от данни е свързано с определяне на

стратегия за физическото съхраняване на данните. В частност, това описание задава:

разпределяне на базата от данни на файлове, организацията на данните, дължината на

страниците и параметрите на тяхното блокиране, представяне на стойностите на

данните в информационната част на записите, евентуално - параметрите на

сегментирането на записите, средствата за реализация на групови отношения в

мрежовите и йерархичните системи и др.

В предложените от CODASYL езици за описание на база от данни се използват

различни езици за концептуално и вътрешно ниво на представяне. Обаче, в повечето

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

задават съвместно. Такова описание се нарича схема на базата данни, а използваният

език за описанието ѝ е Data Definition Language (DDL).

Схемата представлява пълно описание на всички съдържащи се в базата от

данни елементи, съществуващите между тях връзки, наименованията на логическите

масиви, сегменти и полета.

52

Подсхема се нарича описанието на данните на външно ниво на тяхното

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

Средствата за задаване на подсхемата се определят от механизма за поддържане

на външните представи в конкретната СУБД. В усъвършенстваните системи подсхемата

се задава от администратора на базата от данни, транслира се и във вид на работна

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

подсхема и е подчинена на всички ограничения, зададени от тази подсхема. За

задаване на подсхемата се използва: език за описание на подсхемата. Самата

подсхема определя структурата на данните, която е производна от структурата на

концептуално ниво. В такава производна структура един външен запис може да се

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

данни (които не се съхраняват в базата от данни). Накрая, външните структурни

асоциации могат да се формират от няколко асоциации на концептуално ниво. На

външно ниво могат да бъдат изменени начините за подреждане на данните,

форматите на данните, форматите на представяне на стойностите и др.

В подсхемата администраторът на базата от данни може да задава не само

разрешението за обработка над множеството на данните, но и допустимите режими на

обработка. Така никой потребител не може да извърши действие, ако то не е

предвидено в подсхемата.

В някои системи всички потребители възприемат базата от данни така, както тя е

зададена от администратора на концептуално ниво. Потребителят (програмист или

краен потребител) посочва в приложенията какви данни са му необходими и в какъв

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

вътрешното представяне във външното. В такива СУБД не се използва език за описание

на подсхемата. Списъкът на обработваните данни и външното им представяне се

извършва от потребителите с използване на езиците за разработка на приложенията.

4.5 Класификации

Съществуват различни класификации на базите от данни в зависимост от

избраните критерии като: метод на достъп, възможност за разпределеност, модел на

данните, и др.

53

Според достъпа

Според достъпа може да бъдат категоризирани като вградени, файл-сървърни,

клиент-сървърни.

Вградени

Те влизат в съставната част на приложението. Предназначени са за локално

съхраняване на данни и не могат да се прилагат за колективно ползване. Обикновено

са реализирани като библиотеки, които потребителят включва в приложението си.

Достъпът до данните от страна на приложението е или чрез използване на SQL, или

чрез специални програмни интерфейси. Примери на СУБД, които могат да се ползват

по този начин са: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server

Compact, ЛИНТЕР.

Файл-сървърни

Данните се разполагат на файловия сървър. СУБД се разполага на всеки клиентски

компютър (работна станция). Синхронизацията на четенето и записът се осъществява

чрез файлови блокировки. При този вид достъп имаме ниско натоварване на

процесора на файловия сървър за сметка на високо натоварване на мрежата,

затруднено/невъзможно централизирано управление и осигуряване на надеждност,

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

ниска интензивност на обработка на данните. Примери на такива СУБД са: Microsoft

Access, Paradox, dBase, FoxPro.

Клиент-сървърни

При тях СУБД се разполага на сървъра и осъществява достъпа до базата и всички

потребителски заявки се обработват централизирано. При тази технология се печели

възможност за централизирано управление, осигуряване на надеждност, достъпност и

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

сървъра. Примери на такива системи са: Oracle, Firebird, Interbase, IBM DB2, Informix,

MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛИНТЕР.

Клиент-сървърните технологии се различават по броя на слоевете, които ги

изграждат, възможностите за разбиване (partitioning) и паралелизация и т.н.

54

Спрямо стратегиите за работа с външната памет

Различават се две основни стратегии:

СУБД с непосредствен запис – при тях всички изменения в блоковете на

данните веднага се записват във външната памет при постъпване на сигнал за

потвърждаване на транзакцията. Тази стратегия се използва само при високо

ефективни външни памети;

СУБД с отложен запис – при тях измененията се акумулират в буферите на

външната памет до настъпване на определени събития като: контролна точка;

запълване на буферите и др.

Според модела на данните

Спрямо модела на данните основно се различават релационни, йерархични,

мрежови, обектно-ориентирани и др. По-нататък ще се спрем по-подробно на

различните видове СУБД спрямо използвания модел на данни.

4.6 Йерархичен модел на база от данни

Йерархичните бази данни са един от типовете бази данни, при който данните се

съхраняват в предварително определена йерархия, т.е. в дървовидна структура от

данни. Отделните свързани обекти се отнасят един към друг като

"родител"-"наследник", като отношенията между тях са от типа "едно към много", и в

частност "едно към едно". Достъпът до данните се осъществява, чрез обхождане на

дървото от корена до откриване на търсените данни.

Йерархичната структура е използвана в ранните мейнфрейм СУБД. Примери на

йерархични бази от данни са IMS (Information Management System) на IBM, системата

Windows Registry в операционната система Windows на Microsoft, новосъздадената

СУБД за мобилни устройства – RDM.

Йеррахичният модел е загубил позиции с налагането на релационния модел на

Код като де факто стандарт за СУБД. Схемите на йерархична организация на данните

отново излизат на хоризонта с появата на XML в края на 90те години.

55

фиг. 6. Пример на йерархичен модел5

В момента те се използват основно във файловите системи, при съхраняването на

географски данни и в приложения, които изискват много висока ефективност и

достъпност, като например банкови операции и телекомуникациите.

4.7 Мрежов модел на база от данни

Мрежовият модел на база данни е гъвкав начин за представяне на обекти и

връзките между тях. Предложен е от Чарлс Бакман, който получава награда на Тюринг

за него през 1973 г., а е разработен като стандартна спецификация през 1969 година от

консорциума CODASYL. Мрежовият модел надгражда йерархичния модел на бази

данни, позволявайки всеки запис да има и множество „родители“, с което

дървовидната структура се променя в ориентиран граф. Всеки възел в графа отговаря

на колекция от записи от данни, а дъгите, свързващи възлите, представят релациите в

мрежовата база данни и са от тип „едно към много“. Дъгите имат посока и първият

възел се нарича „собственик“, а вторият — „член“.

Предимствата на мрежовия модел са в бързината, с която се осъществява

достъпът до данните и във възможността за отправяне на по-сложни заявки към базата

данни, отколкото са заявките към йерархични бази данни. Недостатъците на модела са

свързани с необходимостта от внимателно проектиране и добро познаване на

структурата на базата, за да може да се обхожда ефективно и да не се налага

промяната ѝ в процеса на работа, тъй като това влияе на приложните програми, които

работят с базата.

5 https://en.wikipedia.org/wiki/Hierarchical_database_model

56

фиг. 7. Пример на мрежов модел6

Въпреки че моделът е широко внедряван и използван, той не успява да се наложи

по две основни причини. Първо, за своите продукти IBM избира да се придържа към

йерархичния модел с полумрежови разширения. Второ, с времето моделът бива

изместен от релационния модел, който предлага по-декларативен интерфейс от по-

високо ниво. До началото на 1980-те предимствата по отношение на бързодействието,

които йерархичните и мрежовите бази данни предлагат при ниски навигационни

интерфейси, обуславят приложението им в много програми, но с повишаването на

бързодействието на хардуера и налагането на релационния модел като основна

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

приложения за бази данни.

Някои по-известни програми за работа с мрежови бази данни са: TurboIMAGE,

IDMS, RDM Embedded, RDM Server, IDS, Univac DMS-1100.

4.8 Релационен модел на бази от данни

През 1970 г., когато системите базирани на йерархичния и мрежовия модел са

били в разгара на развитието си, Едгард Франк Код публикува статия, в която предлага

разнородните данни да се съхраняват в таблици, което ще позволи да се установят

връзки между тях. През 1970 г. тази идея е смятана за интелектуален куриоз. Този

скептицизъм не успял да спре проучванията на Е. Ф. Код. Един от първите прототипи на

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

6 https://en.wikipedia.org/wiki/Network_model

57

на IBM. През 1987 г. езикът за заявки към БД, SQL, е стандартизиран. В днешно време

релационният модел е най-масово използвания в системите за управление на бази от

данни.

Релационната база от данни е тип база от данни, която съхранява множество

данни във вид на релации, съставени от записи и атрибути (полета) и възприемани от

потребителите като таблици. Софтуерът, който се използва за организиране и

управление на този вид бази данни се нарича най-общо система за управление на

релационни бази данни (СУРБД). [Ернандес, 2004]

Релацията (relation) се дефинира като множество от записи, които имат едни и

същи атрибути. Записът обикновено представя обект и информация за обекта.

Релацията се описва във вид на таблица, организирана по редове и колони. Всички

данни, които се съдържат в даден атрибут, принадлежат на едно и също множество от

допустими стойности, наречено домейн, и съблюдават едни и същи ограничения.

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

базите данни.

Всяка релация (таблица) в базата данни е с уникално име. Всеки атрибут в

рамките на дадена релация също е с уникално име. В релацията не може да се

съдържат повтарящи се идентични записи. Редът на разположение на записите в

релацията, както и на атрибутите в записа не са от значение.

В релационната база от данни, всички данни се съхраняват и достъпват

посредством релации. Релациите, които съхраняват данните, се наричат базови

релации (base relations) или таблици (tables). Други релации обаче не съхраняват

данни, а се изчисляват чрез прилагането на операции над други релации и се наричат

производни релации (отношения), а в приложенията за бази от данни се наричат

заявка (query) и изглед (view). Предимството на производните релации е, че

функционират като една релация, въпреки че могат да включват информация от

няколко релации.

58

Ключове

Ключ (key) се наричат един или повече атрибута със специално предназначение в

таблицата на релацията. Видът на ключа определя предназначението му. Съществуват

четири различни вида ключове в базите данни: кандидат ключ (възможен ключ),

първичен ключ, външен ключ, и алтернативен ключ.

Първичен ключ (primary key) е атрибут (по-рядко група атрибути), който служи да

идентифицира по уникален начин всеки запис (екземпляр) на релацията. Когато

измежду атрибутите на релацията няма един подходящ за първичен ключ атрибут,

вариантите са: (1) да се прибегне към множество от два и повече атрибути, които

заедно идентифицират записите еднозначно, т.нар. сложен първичен ключ (composite

primary key), или (2) да се добави нов атрибут, по който да се прави идентификацията

на записите.

Всяка таблица трябва да съдържа поне един първичен ключ. Първичните ключове

са специален случай на по-общата конструкция, наречена ключове-кандидати

(candidate keys). Един ключ-кандидат е преди всичко точно един уникален

идентификатор. По дефиниция всяка една релация има най-малко един ключ-кандидат

(на практика повечето релации имат точно един, но има такива с по два и повече

ключа). Избирайки един от тези кандидат-ключове за първичен, всички останали стават

(ако съществуват) алтернативни ключове.

Външният ключ (foreign key) е необходим, когато е налице отношение между две

таблици (релации). Отношението се създава, като копие от първичния ключ на едната

таблица се включи в структурата на втората таблица, за която той се явява външен.

Отношения

Отношение (relationship) се нарича зависимост, съществуваща между две

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

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

или кардинални числа (cardinality), са три вида: „едно към едно“ (1:1), „едно към

много“ (1:N), „много към много“ (M:N). В литературата се среща и кардиналността

„много към едно“ (N:1), която е вариант на „едно към много“.

59

Отношението от вид „едно към едно“ е налице, когато всеки запис от една

таблица е свързан с най-много един запис от втора таблица и всеки запис от втората

таблица е свързан най-много един запис от първата таблица. Този вид отношение е

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

общ първичен ключ. Възможно е обаче и първичните им ключове да са различни и

отношението да се създава с използване на външен ключ, като първичният ключ на

едната таблица, без значение коя, се включи в структурата на другата.

Отношение „едно към много“ между две таблици съществува тогава, когато един

запис от първата таблица, наречена родителска, може да бъде свързан с много записи

от втората таблица, наречена дъщерна, но запис от дъщерната таблица може да бъде

свързан само с един запис от родителската таблица. Отношението между двете

таблици се създава като копие на първичния ключ на родителската таблица се включи

в структурата на дъщерната таблица, за която той представлява външен ключ. Това е

най-често срещаният вид отношение между таблици.

Отношението „много към много“ съществува когато един запис от едната таблица

може да се свърже с много на брой записи от втората таблица, и един запис от втората

може да се свърже с много на брой записи от първата таблица. За да се създаде на

практика това отношение, се използва нова, свързваща или асоциираща таблица, която

съдържа копия на първичните ключове на двете таблици. От една страна свързващата

таблица представлява сложен първичен ключ на отношението, а от другата страна,

всеки от първичните ключове на изходните таблици играе ролята на външен ключ за

свързващата таблица.

Оператори

Релациите се манипулират чрез операторите create (създаване), insert (вмъкване),

delete (изтриване) и update (актуализиране).

Заявките, които се отправят към релационната база данни, и извлечените в

резултат подтаблици се изразяват със средствата на релационната алгебра. Самият Код

въвежда осем релационни оператора.

60

Обединение (union) комбинира записи от две релации и премахва от резултата

всички евентуални повтарящи се записи. Релационният оператор обединение е

еквивалентен на SQL-оператора UNION.

Сечение (intersection) извежда множеството от записи, които са общи за двете

релации. Сечението в SQL е реализирано чрез оператора INTERSECT.

Разлика (difference) се прилага над две релации и в резултат връща множеството

от записите от първата релация, които не съществуват във втората релация. В SQL

разликата е имплементирана посредством оператора EXCEPT или MINUS.

Декартово произведение или само произведение (Cartesian product, cross join,

cross product) на две релации представлява съединение (join), при което всеки запис от

първата релация се конкатенира с всеки запис от втората релация. В SQL операторът е

реализиран под името CROSS JOIN.

Селекция (selection, restriction) връща само онези записи от дадена релация,

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

множествата. Еквивалентът на селекцията в SQL е заявка SELECT с клауза WHERE.

Проекция (projection) е по своя смисъл селекция, при която повтарящите се

записи се отстраняват от резултата. В SQL е реализирана с клаузата GROUP BY или чрез

ключовата дума DISTINCT, внедрена в някои диалекти на SQL.

Съединение (join), дефинирана за релационни бази данни, често се нарича и

естествено съединение (natural join). При този вид съединение две релации са

свързани посредством общите им атрибути. В SQL тази операция е реализирана

приблизително чрез оператора за съединение INNER JOIN. Други видове съединение са

лявото и дясното външни съединения, внедрени в SQL като LEFT JOIN и RIGHT JOIN,

съответно.

Деление (division) е малко по-сложна операция, при която записи от една

релация в ролята на делител се използват, за да се раздели втора релация в ролята на

делимо. По смисъла си, тази операция е обратна на операцията (декартово)

произведение.

В добавка към въведените от Едгар Код осем оператора, впоследствие са

въведени и други, включително оператори за релационно сравнение и разширения,

които реализират йерархични, темпорални, размити данни и т.н.

61

Нормализация на бази данни

Друго понятие, което е първоначално предложено от Код като съществена част от

релационния модел, е нормализацията на базите данни. Нормализацията, т.е.

привеждането в нормална форма включва набор от практики по отстраняването на

повторения сред данните, което води до икономия на памет и предпазва от аномалии

при манипулирането с данните (вмъкване, актуализиране и изтриване) и от загуба на

тяхната цялост. Въпреки тези си плюсове, нормализацията има и негативни последици

като усложняване, загуба на яснота и отдалечаване от реалния обект и намаляване на

ефективността поради използването на много съединения. И ако в OLTP приложенията

нормализацията може и да води до увеличаване на ефективността, в OLAP

приложенията сляпото прилагане на всички нормални форми може да доведе до

катастрофални последици – изключително голям брой таблици, сложни заявки за

сливане и оттам – изключително лоша производителност. Това в крайна сметка може

да направи базата данни неизползваема.

Нормалните форми накратко са: [Симеонов, 2009]

1НФ: Една таблица е в първа нормална форма, тогава и само тогава, когато не

съдържа повтарящи се атрибути или групи от атрибути.

2НФ: Таблицата трябва да е в 1НФ и всички неключови стойности трябва да са

напълно функционално зависими от първичния ключ. Не са позволени частични

зависимости.

3НФ: Премахват се непреките зависимости. Например, поле е фунцкционално

зависимо от друго поле, а то от своя страна е зависимо от първичния ключ.

Boyce-codd Normal Form (BCNF): Всяка детерминанта трябва да бъде кандидат

ключ. Детерминант е произволно поле, от което са напълно функционално зависими

други полета. Ако съществува един единствен кандидат ключ 3НФ и BCNF са едно и

също.

4НФ: Трябва да се премахнат многостойностните зависимости.

5НФ: Трябва да се премахнат цикличните зависимости

Domain Key Normal Form (DKNF): Тази форма е по-скоро определение на това как

трябва да излегжда нормализирана до съвършенство база данни.

62

Не трябва да съществуват аномалии при записване, обновяване или триене

на данни. Иначе казано всеки запис трябва да бъде директно достъпен по

всякакъв начин, така че да не възникват грешки;

Всеки запис във всяка таблица трябва да бъде уникално идентифициран и

свързан с първичния ключ в своята таблица. Това означава че всяко поле

трябва да е пряко определено от първичния ключ;

Всички проверки за типа на данните се извършват в самата база данни.

Заб.: Това е крайно нежелателно в комерсиална работна среда от гледна

точка на производителността. По-добър подход е разделянето на

функционалността между базата от данни и приложението.

Несъмнено прилагането на първите две форми е необходимо. Не само че помага

за избягване на аномалите, те са необходими за да съществува релационният модел.

Прилагането на 3НФ също е доста срещано, но с всяка следваща форма моделът на

базата става все по-раздробен и броят на таблиците нараства. Оттам нарастват и SQL

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

Проектантите на бази от данни не трябва да се страхуват да не използват високо

ниво на нормализация, а по-скоро обратното. От първостепенна важност е проектантът

да може да „види” модела на базата през погледа на софтуерния разработчик и

крайния потребител и точно да определи изискванията. За да се определи нивото на

нормализация е добре да се отговори на следните въпроси: "Какъв тип е базата данни -

дали е OLTP, OLAP или warehouse?", а оттам и "Кои заявки към базата са повече - за

добавяне или за извеждане?". [Симеонов, 2009]

4.9 ACID тест

За да може една транзакционна система да извършва надеждно и предсказуемо

работата си се счита, че тя трябва да изпълнява т.нар. ACID тест. Изискванията са били

формулирани в края на 70те години от Джим Грей [Gray, 1981].

63

The ACID Properties of Transactions

Properly implemented transactions are commonly said to meet the "ACID test,"

where:

"A" stands for "atomicity" – the all-or-nothing execution of transactions.

"C" stands for "consistency" – all databases have consistency constraints, or

expectations about relationships among data elements and transactions are

expected to preserve the consistency of the database.

"I" stands for "isolation," the fact that each transaction must appear to be

executed as if no other transaction is executing at the same time.

"D" stands for "durability," the condition that the effect on the database of a

transaction must never be lost, once the transaction has completed.

фиг. 8. Описание на ACID теста [Molina et al, 2009]

Atomicity (Атомарност)

Атомарността гарантира, че никоя транзакция няма да бъде изпълнена частично.

Ще бъдат изпълнени или всички нейни подоперации, или нито една. Понеже на

практика не е възможно едновременното изпълнение на цялата последователност от

операции в рамките на транзакцията, се въвежда понятието rollback: ако транзакцията

не може да се изпълни изцяло резултатите от проведените вече действия се отменят и

системата се връща в началното си състояние до започване на изпълнението на

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

да се изменят, но ако СУБД е програмирана без грешки, това няма да повлияе на

външното й поведение.

Consistency (Съгласуваност)

Транзакция, която достига края на своето нормално изпълнение следва да

съхранява съгласуваността на базата от данни. Т.е. всяка успешна транзакция по

определение фиксира само допустими резултати. Съгласуваността е по-широко

64

понятие от обикновената проверка за цялостност на базата от данни. То включва

следене и на определени бизнес-правила, на които трябва да отговарят данните, за

осигуряването на които са отговорни програмистите при писането на кода. По време на

самото изпълнение на транзакцията може да възникне несъгласуваност, но

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

важно в какво състояние е базата.

Isolation (Изолираност)

По време на изпълнение на дадена транзакция паралелните транзакции не бива

да оказват влияние на нейния резултат. Това изискване е доста скъпо, затова в

реалните бази от данни съществуват режими с по-отслабени изисквания (ниво на

изолираност Repeatable Read и по-ниско).

Durability (Надежност)

Независимо от възникнали проблеми (например, откази на оборудването)

промените, направени при успешно завършена транзакция трябва да останат

съхранени в базата от данни след отстраняване на проблема и връщане на системата в

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

системата, че операцията е извършена, той може да бъде сигурен, че направените

промени няма да бъдат анулирани заради неизправност.

4.10 NewSQL бази от данни

NewSQL са клас съвременни релационни бази от данни, които запазват

използването на SQL и поддръжката на изпълнението на ACID теста, но с осигуряване

на добра мащабируемост на базата – качеството, което е най-слабата страна на

класическите релационни бази от данни.

Примери за такива бази са: ScaleBase, Clustrix, EnterpriseDB, MemSQL, NuoDB и

VoltDB.

65

4.11 Транзакционни и аналитични системи (OLTP и OLAP)

Изборът на едно или друго решение при проектирането на информационните

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

Според начина на тяхното функциониране и употреба се отличават два основни типа:

Транзакционни системи (OnLine Transactional Processing systems - OLTP);

Aналитични системи (OnLine Analitical Processing systems – OLAP).

Основната цел на преобладаващата част от оперативните системи за управление

на бази от данни е ежедневната обработка на информация и изпълнение на заявки.

Тези системи трябва да поддържат ефективност при изпълнението на структурирани и

повторяеми заявки, които се провеждат в отделни изолирани транзакции, като се

стремят да осигурят оптимална скорост на транзакцията, да поддържат съгласуваността

на данните и възможности за тяхното възстановяване. Това определя и названието на

тези системи – транзакционни системи (OLTP systems). Транзакционните системи

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

С течение на времето организациите натрупват огромни количества данни от

техните транзакционни системи. Обемът на тази информация затруднява процеса на

съхранение и достъпа до нея и ограничава възможностите за ефективното й

използване. Това налага данните да бъдат организирани в друг вид структури –

хранилища на данни или складове от данни (Data Warehouses - DW). Те предоставят

инструменти за систематично организиране, визуализиране и анализиране на данни,

събирани от различни системи в продължителен период от време. По тази причина

системите, които се изграждат върху складовете от данни, се наричат аналитични

системи (OLAP systems). OLAP системите позволяват бърз, интерактивен и съгласуван

достъп до обобщено представяне на информацията с възможности за динамичен,

многоразмерен анализ по различни показатели.

Основната цел на една транзакционна система е да осигури бързодействие при

получаване на справките, както и ефективност и гъвкавост при съхранение и

обновяване на ежедневно променящата се информация.

При складовете от данни ударението е върху съхранението на значителни

количества данни във вид, удобен за различни анализи – статистики, сравнения на

данни от предишни години, обобщения по различни параметри. Тази информация има

66

за цел да отговори на различни въпроси, свързани с текущото и миналото състояние на

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

Традиционните системи поддържат онлайн обработка на транзакции (OLTP),

която включва добавяне, изтриване и обновяване на данни, както и отговор на

различни запитвания, относно съдържанието на данните - заявки. Организацията на

базите от данни в тях трябва да бъде оптимизирана по отношение на този тип

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

се извършват операции, с които се актуализират няколко записа във връзка с един

транзакционен процес. Моделите, които съответстват на този тип операции, са се

развивали в продължение на няколко десетилетия и включват последователно

йерархични, мрежови, релационни, обектно-релационни или изцяло обектно-

ориентирани модели [Molina et al, 2009].

Организирани по начин, целящ оптимално представяне на отделните елементи и

връзките между тях, тези модели на бази от данни не са подходящи за аналитични

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

детайлни данни и използване на различни модели на представяне на информацията в

аналитичните системи. При складовете от данни се изисква тематично-ориентиран

модел, удобен за интерактивен анализ на данните [Inmon, 1992]. Те трябва да бъдат

проектирани така, че да осигуряват ефективно извличане, обработка и визуализация на

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

многомерен модел, който не само съхранява данните, но и позволява тяхното

категоризиране на базата на предварително дефинирани критерии (измерения) –

например, време, географско положение и др. За целта данните се разглеждат като

един куб в n-мерното пространство. Кубът се дефинира чрез измеренията и факти за

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

различни измерения.

В сравнение с транзакционните системи, складовете на данни обикновено

съдържат данни, чиито количества са в пъти по-големи. В допълнение, те са събирани

от множество източници, които могат да включват бази от данни с различни модели и

структури на данните, а понякога и файлове от външни системи и платформи. Това

67

също слага отпечатък върху тяхната структура и поставя редица въпроси, свързани с

обединението на данните от различните източници.

Таблица 3. Различия между релационното моделиране и многомерното моделиране 7

релационно моделиране многомерно моделиране

Релационните модели могат да бъдат много

комплексни, със стотици таблици и дълги

вериги от връзки между тях.

Многомерните модели са много прости.

Всяка от таблиците по дадена размерност има

директна връзка с таблицата с данни (fact

table).

Моделирането на данните е доста гъвкаво. Многомерното моделиране има твърда

структура.

Основен принцип е изграждането на

нормализирани бази от данни (така че всяка

стойност да бъде съхранявана само веднъж).

В основата на изграждането на многомерните

модели е заложено игнориране на

нормализацията. Таблиците по

размерностите съдържат голям набор от

повторения на стойности в полетата си.

Релационните модели са оптимизирани за

OLTP (On Line Transaction Processing).

OLTP се нуждае от ефективно обновяване на

данни (постигано чрез нормализацията на

базите)

Многомерните модели са оптимизирани за

OLAP (On Line Analytical Processing).

OLAP не нуждае от ефективно извличане на

данни (постигано чрез минимизиране на пътя

до данните – в случая директен път таблицата

с данни)

SQL (Structured Query Language) заявките

работят върху релационни данни

MDX (MultiDimensional eXpressions) заявките

работят върху многомерни данни

Елементите на релационното хранилище са

"таблици"

Елементите на многомерното хранилище са

"кубове"

Данните се съхраняват в полетата на записите Данните се съхраняват в координатните

позици на размерностите

Размерът на таблиците се определя в брой

записи

Размерът на кубовете се измерва в броя на

"точките"

7 http://erpjewels.com/difrelmulti.htm

68

4.12 Складове от данни (Data Warehouses)

Концепцията за „хранилище на данни” или „склад от данни” не е нова. Тя датира

от седемдесетте години на миналия век и се свързва с някои разработки на известни

компании, включително и на IBM. Но областта започва бурно развитие едва след

появатa на дефиницията на Инмон за „склад от данни”. В своята книга „Building the

Data Warehouse” [Inmon, 1992] той определя склада от данни като „предметно-

ориентирана, интегрирана, относително неизменна съвкупност от данни, с времеви

характеристики, която е предназначена да поддържа процеса на вземане на

управленски решения.”

Всеки склад от данни съдържа огромни количества обобщени данни за една

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

организацията. Най-често тези данни се използват за анализи, които помагат на

ръководството да взема правилни бизнес решения [Inmon, 2005].

Няколко основни типа методи се използват при работа със складовете от данни:

статистически методи - хипотетични тестове, тестове за съвпадение на

разпределенията, анализи на вариантите и др.;

интерактивна аналитична обработка (OLAP) - анализ на данните и

вземане на стратегически управленски решения;

методи за извличане на закономерности от данни (Data Mining methods -

DM) – позволяват откриване на нови, неизвестни зависимости в складовете от

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

изкуствен интелект, машинно самообучение и др.

Непрекъснатото нарастване на обемите от данни и бързо променящите се

технологии за съхранение на информацията доведоха до появата на ново поколение

складове от данни, наречено DW 2.0 [Inmon & Strauss & Neushloss, 2008]. За разлика от

първото поколение складове от данни, което се състои изцяло от структурирани данни,

DW 2.0 интегрира структурирани и неструктурирани данни. Концепцията за мета-

данните също еволюира в DW 2.0. Например, всеки сектор поддържа собствени

метаданни. Важен аспект на DW 2.0 е, че архитектурата на склада от данни се

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

променящите се бизнес изисквания. [Калоянова, 2013].

69

Най-разпространеният модел, използван в момента в аналитичните системи, е

многомерният модел на данните, който представя данните като един куб в n-мерното

пространство. Кубът се дефинира чрез факти и измерения, свързани с фактите.

Измеренията (dimentions) са множеството от критерии, по които се правят анализите.

Всяко измерение включва йерархия, позволяваща да се правят анализи на различни

нива на обобщение.

За физическото представяне на куба, обаче, се използват различни архитектурни

подходи. От гледна точка на архитектурното решение, за многомерния модел

съществуват два основни типа – многомерен OLAP (MOLAP) и релационен OLAP

(ROLAP). Третият тип - хибридният OLAP (HOLAP) е комбинация на двете технологии

[Kaser & Lemire, 2003]. В последно време се заговаря и за други видове, свързани с

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

ROLAP използва релационни таблици, за да симулира многоразмерен куб. Тази

технология позволява работа с големи обеми от данни и интеграция със

съществуващите релационни системи чрез SQL заявки, но е по-бавна.

При MOLAP данните се съхраняват в многоразмерен куб, който е оптимизиран за

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

обеми памет, необходима за съхранението на всички възможни комбинации по

измеренията и техните обобщения и изисква значително време за първоначалното

зареждане и изчисления.

HOLAP използва MOLAP за справки и агрегации на високо ниво, а при преглед на

детайлите се правят заявки към релационна ROLAP схема. [Калоянова, 2013]

Таблица 4. Поддържаните модели от OLAP сървъри8

OLAP Server MOLAP ROLAP HOLAP Offline

Essbase Yes Yes Yes

icCube Yes No No Offline Cubes

Infor BI OLAP Server Yes No No Local cubes

Jedox OLAP Server Yes Yes Yes No

Microsoft Analysis Services Yes Yes Yes Local cubes,

PowerPivot for Excel

8 https://en.wikipedia.org/wiki/Comparison_of_OLAP_Servers

70

MicroStrategy Intelligence Server Yes Yes Yes MicroStrategy Office,

Dynamic Dashboards

Mondrian OLAP server Yes Yes Yes

Oracle Database OLAP Option Yes Yes Yes

SAS OLAP Server Yes Yes Yes

IBM TM1 Yes No No

IBM Cognos Yes Yes Yes

SAP NetWeaver BW Yes Yes No

Cubes (OLAP server) No Yes No

4.13 Пространствени бази от данни (Spatial Data Bases)

С развитието на технологиите за управление на бази от данни, особено след

изграждане на концепцията за обектно-ориентирани бази от данни, става очевидна

необходимостта от разработване на специални инструменти за представяне на

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

определя разстояния между точки и отношения като принадлежност към определено

множество, топологични връзки между обекти ("между", "зад","пред" и др.). Този вид

представяне на реалните обекти е известен като пространствени бази от данни (spatial

databases) и е в основата на географските информационни системи, но и не само. Други

области на приложения са, например, в генната биология – търсенето на сходство на

топологичната структура на амино-киселини в даден ген, в бизнес планирането –

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

потенциалните клиенти и др.

Пространствената база от данни е база от данни, която оптимизира съхранението

и отговорът на заявки, отнасящи се до обекти, дефинирани в геометрично

пространство. Много от пространствените бази от данни позволяват представянето на

прости геометрични обекти като точки, линии и полигони. Някои оперират и с по-

сложни структури като 3D обекти, топологични покрития, линейни мрежи и

триангулачни мрежи.

71

Преминаването от естествената представа за района, която има потребителя, към

разрешеното в релационните бази данни представяне е доста сложно и изисква

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

Обектно-ориентираните бази данни предлагат по-естествено запис на такъв тип

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

поддържащи обектно-ориентирано представяне. В момента на пазара се използват по-

широко релационно-обектни бази данни, в които само някои елементи на обектно-

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

Докато типичните бази от данни оперират с различни числови и символни типове

от данни, за ефективната обработка на пространствените обекти се налага

въвеждането на допълнителна функционалност – обикновено наричана geometry of

feature. Международната организация по стандартизация Open Geospatial Consortium

(OGC) се грижи за създаването и насърчаване на прилагането на отворени стандарти за

геопространствено съдържание и услуги, обработка на геопространствени данни и

споделянето им. Изработеният от тях и приет ISO 19125 стандарт определя общ модел

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

(права/крива), полигон, множество от точки, множество от линии и т.н.).

Основните елементи на необходимата надстройка са: таксономия на

пространството; пространствени типове данни; пространствен език за заявките;

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

данни.

Таксономия на пространството: Пространствените зависимости могат да бъдат

представени по различен начин – топологично (отношения като "съседство",

"включване", "изключване", "във", "извън"); мрежово (за решаване на задачи от типа

наличие на път, намиране на най-къс път и др.); геометрично (чрез използване на

Евклидова координатна система); географско (с обозначаване на географски дължина и

ширина, особено често използвана в GPS-навигацията). В зависимост от задачата

пространството може да се представи чрез множество различни, но свързани, системи

за представяне на обектите.

Пространствени типове данни: Основни типове данни, използвани за

представяне на обектите в пространствените бази от данни, са: вектор (представяне на

72

обекти чрез множество от еднотипни данни); растер (представлява равномерна

решетка над пространството); поле (за представяне на непрекъснати структури като:

температура, поле на облачност и др. Полето е функция, трансформираща основната

рамка на обекта към дефиниционната област на съответния атрибут на обекта);

триангулачни мрежи (друг метод за представяне на "поле").

Пространствен език на заявките: надграждане на езика за опериране с

пространствените данни. По отношение на SQL в OGC има определено съгласие за

създаване на пространствена версия, в която да се имплементира използването на 2D

гео-простанствени абстрактни типове данни.

Алгоритми за пространствени операции: доколкото езиците за заявки са

декларативни езици от 4-то поколение (задава се какво се иска като резултат, а не как

този резултат да се произведе), то за всяка операция от разширеното множество

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

Методи за индексиране на пространствени данни: следващата глава е

специално посветена на различни индексни структури за описание на пространствени

данни.

4.14 Пространствено-времеви бази от данни (Spatio-Temporal DB)

Този тип бази от данни оперират както с пространствени, така и с времеви данни.

Типични примери за такива бази са: проследяване на движещи обекти; историческо

проследяване на събития, екстраполация на действия в бъдеще и др. Те работят с

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

инвариантна геометрия в реално време. Обикновено пространствено-времевите бази

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

сложна структура на данните. Все още няма и официални или фактически стандарти за

пространствено-времевите модели на данни и техните заявки. В следващата глава

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

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

направено в [Mokbel et al, 2003] и [Nguyen-Dinh et al, 2010].

73

4.15 NoSQL бази от данни – предпоставки за развитие

NoSQL технологията започна да се налага от водещите Интернет компании като

Google, Facebook, Amazon, и LinkedIn с цел преодоляване на ограниченията на

традиционната технология на релационните бази от данни за използване от модерните

уеб приложения. Днес развитието на NoSQL се задвижва от четири взаимосвързани

мегатенденции: Big Users, Big Data, the Internet of Things, и Cloud Computing. [Couchbase,

2015]

Big Users: Не много отдавна 1000 потребителя на ден бяха много за едно

приложение, а 10000 бяха извънреден случай. Днес около 3 милиарда човека са

свързани в Интернет и прекарват много време онлайн (за 2014та година – около

35 милиарда часа на месец), създавайки експлозия в броя конкурентни потребители.

Големият брой потребители, комбиниран с динамиката на схемите на използване

водят до необходимостта от по-лесно мащабируема технология, каквато релационните

бази от данни не могат да осигурят.

Big Data: Експлозивното нарастване на използване на Интернет, в допълнение с

използването на мобилните приложения, социални мрежи и комуникациите между

машините довеждат до революцията "big data". Изследователската компания IDC сочи,

че през 2013 общият обем на цифрови данни в света е бил 4.4 зетабайтове, а до 2020

ще нарастне десет пъти.

фиг. 9. Тенденции на нарастване на създаваните данни – структурирани, полуструктурирани и неструктурирани [Couchbase, 2015]

74

Все повече канали заливат с новопоявяваща се информация – социални мрежи,

данни за местоположение, генерирано от потребителите съдържание, данни от

системни логове, сензорно-генерирани данни и т.н. Наличието на толкова много и

различни данни качествено променят естеството на комуникациите, пазарите,

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

разнородно количество данни са нужни и различен тип бази от данни. Полу-

структурираните и неструктурирани данни не могат да намерят място в твърдите схеми

на остарелите вече релационни данни. С нарастващото значение на обработката на

данни, разработчиците са все по-разочаровани от разминаването между обектно-

ориентирания подход, който те използват за по-естествено описание на процесите и

схема-базираната структура на релационните бази от данни. NoSQL осигуряват много

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

организацията на данните и опростяват взаимодействието между приложението и

базата от данни, и като резултат по-малко код за писане, тестване и поддържане.

The Internet of Things: Обемът на машинно-генерираните данни се увеличава с

разпространението на цифровата телеметрия и т.нар. "Интернет на нещата". Днес

около 20 милиарда устройства са свързани към Интернет – от таблети до домакински

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

среда, местоположение, движение, температура, време от повече от 50 милиарда

сензори. В момента фокусът на иновативните проекти е в създаването на благоприятна

среда за развитие на Internet of things – развиване на нови продукти и услуги,

намаляване на разходите и времето за пускане на пазара, увеличаване на

ефективността, повишаване на удовлетвореността на клиентите. Тази способност за

достъп до глобални, оперативни данни в реално време позволява динамично,

информирано вземане на решение и увеличава гъвкавостта на бизнеса. Отново тези

телеметрични данни са полу-структурирани и непрекъснати и представляват не

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

преодоляването им иновативните предприятия разчитат на NoSQL технологията.

Cloud Computing: В днешно време много от новите приложения работят в

публични, частни или хибридни облаци, обслужват голямо количество потребители и

използват трислойна интернет архитектура. В нея приложенията се достъпват през уеб

75

браузър или мобилно приложение, свързано към интернет. Мащабируемостта на

приложенията е от особено значение. На това предизвикателство релационните бази

от данни не успяват да отговорят, защото те са по-централизирани мащабируемостта

им е насочена по-скоро навътре, а не навън. Това ги прави неподходящи за

приложения, които изискват лесна и динамична мащабируемост, докато в основата на

изграждането на NoSQL базите от данни са залегнали технологиите на разпределеност

и мащабиране.

Основни преимущества наNoSQL базите от данни пред релационните

СУБД

Гъвкав модел на данните на NoSQL

Моделите на данните при релационните и NoSQL базите от данни са много

различни.

Релационният модел разделя данните между множество свързани таблици

(записи-редове и атрибути-колони) като връзките една с друга стават посредство

външните ключове, явяващи се колона от таблицата. При извличане на информация тя

трябва да бъде събирана от множество таблици и допълнително комбинирана преди

да се предостави на приложението. Обратно – при писане трябва да бъде

координирано разпръскването между множество таблици.

NoSQL базите от данни имат коренно различен модел. Например, документно-

ориентираната база агрегира данните, които искаме да се съхранят в общ документ,

използвайки JSON формат. Всеки JSON документ може да бъде разглеждан като един

обект, изполван от приложението. Агрегирането води до преразход на памет, но в

днешно време цената на съхраняващите устройства вече не е определящ фактор.

Друга основна разлика е задължителното наличие на схема при релационните

бази от данни, докато NoSQL моделите са безсхемни. Релационната технология изисква

строга дефиниция на схема преди съхраняване на каквито и да било данни в базата от

данни. Промяната на вече изградена схема е почти разрушително, а това е проблем в

ерата на Big Data, когато разработчиците на приложения се нуждаят от постоянно и

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

76

Мащабируемост и общо представяне

Обслужването на нарастващото количество потребители и обеми данни кара

приложенията да се справят с две основни предизвикателства: мащабируемост във

височина (scale up) или мащабируемост в ширина (scale out). Мащабируемостта във

височина изисква централизиран подход и разчита на все по-големи и по-големи

сървъри. Мащабируемостта в ширина предразполага към разпределен подход и

множество сървъри.

Дълги години релационните бази от данни се справят добре със

мащабируемостта във височина, прилагайки трислойния клиент-сървър модел. Обаче,

за обслужването на повече конкурентни потребители и съхраняването на повече данни

релационните СУБД изискват все по-големи и по-скъпи сървъри, а капацитетът и на

най-големият сървър в един момент не може да надхвърли определена граница. За

NoSQL базите от данни това не е проблем защото те са насочени да работят върху

множество неголеми сървъри.

По отношение на мащабируемостта в ширина, NoSQL базите от данни са

създадени с идеята да работят върху разпределени платформи, с използване на

стандартни физически или виртуални сървъри за съхраняване на данни и поддръжка

на операциите с базите от данни. Разширяването става с просто включване на нови

клъстери в множеството. Отчитайки факта на възможност за откази от страна на

вкючените сървъри, NoSQL базите от данни са създадени да могат да възстановяват

загубите. NoSQL базите от данни предполагат изключително лесен линеен метод на

мащабиране – с появата на нови потребители просто включвате още един обикновен

сървър. Не е необходимо да модифицирате приложението доколкото самото

приложение е създадено като единична (разпределена) база от данни.

По отношение на мащабирането в ширина – то винаги печели спрямо

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

от грешки сървъри, които са скъпи за проектиране, реализиране и поддръжка.

77

фиг. 10. Представяне на релационните бази от данни при увеличаването на натоварването от потребители и данни [Couchbase, 2015]

фиг. 11. Представяне на NoSQL базите от данни при увеличаването на натоварването от потребители и данни [Couchbase, 2015]

78

Лицензионните цени на комерсиалните релационни бази от данни също може да

се окажат непосилни, защото те са предвидени за един сървър. Докато NoSQL базите от

данни в повечето случаи са с отворен код, работят на клъстер от сървъри и са

относително евтини.

NoSQL базите от данни разпространяват данните на отделните сървъри, без

участие на приложенията (авто шардинг). Могат да бъдат добавяни или премахвани

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

висока надеждност и възстановяване след авария повечето NoSQL бази от данни

осигуряват репликация на данни, съхраняване на множество копия на данни в рамките

на клъстера и дори между центровете за данни. На една добре управлявана NoSQL

СУБД никога няма да се наложи да бъде "изключена" поради някаква причина, тя е

създадена да осигурява непрекъсната 24x365 работа на приложенията.

Шардингът в една релационна база от данни може да намали или премахне

възможността за извършване на сложни заявки. NoSQL СУБД запазват своята пълна

изразителна сила на заявките, дори когато данните са разпределени сред стотици

сървъри.

На фиг. 12 е показан резултат от проучване на Couchbase от 2011г. за това кои

проблеми на релационните бази от данни водят до преминаване към NoSQL.

фиг. 12. Ключови проблеми, които водят до преминаване към NoSQL DBMS

79

4.16 Определение на NoSQL базите от данни

Нерелационната база от данни предоставя механизъм за съхранение и

възстановяване на данни, който използва свободен съгласуван модел за разлика от по-

често ползваната релационна база данни. Ползите на този подход включват изчистен

дизайн, хоризонтално мащабиране и фин контрол върху наличнaта информация.

Нерелационната база данни е най-често добре оптимизирано хранилище, съдържащо

информация от тип ключ-стойност. Предназначението й е да улесни процесите по

възстановяване и добавяне на информация, с цел оптимизиране на

производителността в условия на неумишлено забавяне на системата и въвеждане на

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

нарастваща роля в real-time web и big data приложенията. Нерелационните системи са

наричани "Not only SQL" (на английски: Not only Structured Query Language, NoSQL) за да

се подчертае, че те в действителност позволяват употребата на езици за търсене

различни от SQL.

За първи път терминът "NoSQL" бива използван от Карло Строци през 1998 г. за да

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

стандартния SQL интерфейс. Строци счита, че поради отклоняването на общото

развитие на тези бази от данни от релационния модел, то би трябвало да бъде

именувано по-подходящо като "NoREL"9.

Нерелационната база от данни има разпределена и устойчива на повреди

архитектура, като обектите с информация се съхраняват на няколко сървъра. По този

начин системата може да се предпази като добавя повече сървъри и тогава при

повреда на сървър продължава да работи. Този тип база от данни се разширява

хоризонтално и се използва за управлението на голямо количество от данни, когато

производителността в реално време е по-важна от последователността (напр. в

индексирането на голям брой документи, обслужващите страници на натоварените

сайтове и предоставянето на стриймове). Не на последно място администрирането на

този тип системи е изключително опростено.

9 http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home%20Page

80

4.17 ACID vs BASE

Нерелационните бази от данни не могат да дадат пълна гаранция за ACID

(Atomicity, Consistency, Isolation, Durability). Обикновено съгласуваността е гарантирана

или транзакциите са ограничени до един обект с информация. Това означава, че ако се

даде достатъчно дълъг период от време, по време на който не се пращат промени,

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

Важно значение за разбирането на основата на изграждане на нерелационните

бази от данни има т.нар. "теорема CAP" (теорема на Брюър10), която гласи:

"В една разпределена система може да се удовлетворят най-много две от

категориите – Консистентност (Consistency (C)), Наличност (Availability (A)) и Възможност

за разделяне на части (Partition tolerance (P)). Едновременното осигуряване на трите не

е възможно".

Самите категории имат следния смисъл:

Консистентност: Всички клиенти на базата от данни виждат една и съща

информация, даже при конкурентно обновяване.

Наличност: Всички клиенти на базата от данни могат да достъпват някоя

версия на информацията.

Възможност за разделяне: Базата от данни може да се разделя върху

множество сървъри.

Решението на повечето NoSQL бази данни е да изберат наличност и възможност

за разделяне, за сметка на консистентността, като се търси максимално бърза и

надеждна синхронизация между отделните сървъри [Николов, 2010].

Понятието BASE, което залагат като принцип при изграждането на

нерелационните бази от данни, означава "Basically Available, Soft-state, Eventual

consistency". BASE е противоположност на ACID.

"Basically Available" предполага, че в края на операцията ще има консистентност,

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

наличност.

10 http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

81

"Soft State"11 по отношение състоянието на данните означава, че състоянието се

управлява с вероятности; то не е непременно консистентно; отговорността за

управление на състоянието на данните се поема от потребителя; състоянието може да

бъде както от мрежата или сървъра, така и от потребителя; и самото то не е критично

за услугата.

"Eventual consistency" означава, че ако няма обновяване, евентуално всички

инстанции на базата от данни ще връщат актуалната и консистентна стойност на

данните. Консистентността може да се разглежда от две страни: от гледна точка на

сървъра и от гледна точка на клиента. Клиентската консистентност трябва да се справи

с това как отделните процеси, комуникиращи със системата, виждат обновяванията. В

случай, че даден процес направи обновяване, спрямо останалите клиенти може да са

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

Силна консистентност. След приключване на обновяването, всеки един

клиент ще вижда обновената стойност;

Слаба консистентност. Системата не гарантира, че последващите клиенти ще

получат обновената стойност, освен ако не са изпълнени някакви условия.

Периодът до изпълняване на условията е период на неконсистентност;

Евентуална консистентност. Това е форма на слаба консистентност, при която

системата гарантира, че ако няма направени нови обновявания на данната,

евентуално всички точки на достъп ще върнат вярната стойност.

4.18 Класификация на NoSQL базите от данни

Поради разнообразния характер на тези бази от данни е сравнително трудно да

се намерят стройни класификационни схеми.

Класификации може да се правят спрямо различни критерии, например:

според приложението – на пълнофункционални бази от данни и

специализирани, като специализираните биват бази данни за кеширане

(Redis, Memcachedb, Kyoto Cabinet и др.), за графи и други;

според поддръжката на шардинг (вид разбиване на свръхголемите бази от

данни на по-малки, по-бързи, по-лесно управляеми самостоятелни части,

11 http://mercury.lcs.mit.edu/~jnc//tech/hard_soft.html

82

наречени шардове) и/или репликация (поддържане на главен сървър, с който

се осъществяват всички действия по изменение на базата от данни и

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

които се извършват заявките за четене);

според езика, на който са написани (Java, Erlang, C++, C, C#,...);

според наличието на REST API и според поддръжката на собствен shell

(MongoDB, HBase Pig Grunt, Cassandra);

според поддръжката на MapReduce;

според необходимостта от специална мрежова файлова система (HBase,

BigTable срещу останалите);

според това, дали са с отворен код или не (Dynamo, Sherpa, Lotus Notes не са с

отворен код, повечето от останалите са).

Класификация според модела на данните

За момента, най-общоприетата класификация се базира на модела на данните.

Има различни деления по този критерии ([Moniruzzaman & Hossain, 2013], http://nosql-

databases.org, http://en.wikipedia.org/wiki/NoSQL). Тук ще се придържаме към

класифицирането, дадено в http://db-engines.com/, където се разглеждат следните

групи: Content Stores, Document Stores, Event Stores, Graph DBMS, Key-Value Stores,

Multivalue DBMS, Native XML DBMS, Navigational DBMS, Object oriented DBMS, RDF Stores

(Tripel Stores), Search Engines, Wide Column Stores. Следва да отбележим, че тези

класификации са като цяло условни, доколкото всяка от базите от данни може да бъде

поставена в повече от една от групите. Например, документните бази от данни могат

да се причислят към групата на евентуално консистентните двойки ключ-стойност.

Content Stores (Content Repositories)

Хранилищата на съдържание са специализирани в управлението на цифрово

съдържание като текст, изображения, видео и техните метаданни. Освен стандартните

функции по съхраняване и стандартните заявки с използване на SQL или XPath,

стандартни допълнителни функции са пълнотекстово търсене, поддържане на версии,

йерархическо структуриране на съдържанието и контрол на достъпа. JCR е стандартно

API за Java-базирани приложения, организиращи хранилища на съдържание.

83

Примери: Jackrabbit, ModeShape.

Document Stores (Document-Oriented Database Systems)

Документните складове (хранилища) се характеризират с тяхната свободна схема

на организация на данните:

записите нямат единна структура, т.е. различните записи имат различни

колони (полета);

типовете на стойностите в индивидуалните колони могат да са различни за

всеки запис;

самите колони могат да съдържат повече от една стойност, а цял вектор от

стойности (масив);

записите може да имат вложена структура.

Документните складове често използват вътрешна нотация, която може да бъде

обработена директно в приложенията, най-вече JSON. JSON-документите могат да

бъдат съхранени и като чист текст в други видове системи – напр. релационни или от

типа ключ-стойност. Това обаче ще изисква обработка на структурите от страна на

клиента, а специфичните функции, предлагани от документните складове, няма да са

налични.

Централната концепция, която стои зад документното хранилище е нотацията за

„документ“. Докато всяка документно-ориентирана имплементация се различава

според детайлите на тази дефиниция, като цяло, всички те приемат, че документите

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

формати са: XML, YAML, JSON както и бинарни формати като BSON, PDF and Microsoft

Office документи (MS Word, Excel и др.).

Различните имплементации предлагат различен подход към организирането и

групираненето на документите: колекции; тагове; метаданни; йерархия на

директориите.

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

възприемат като таблици, а документите могат да се приемат за записи. Все пак има

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

84

еднаква последователност от полета, докато документите в колекцията могат да имат

полета, които са напълно различни.

Адресът на документите се представя в базата данни чрез уникален ключ, който

идентифицира документа. Една от другите основни характеристики на документно-

ориентираните бази данни е, че освен простото търсенето по ключ-документ или ключ-

стойност, което може да се използва за извличане на документа, базите данни

предоставят и потребителски интерфейс или език за заявки, който позволява

документите да бъдат откривани въз основа на тяхното съдържание. Някои NoSQL

документни хранилища предлагат алтернативен начин за извличане на базата на

съдържание, като използват MapReduce технологии (напр. в CouchDB).

Примери: MongoDB, CouchDB, Couchbase, Amazon DynamoDB, MarkLogic.

Event Stores

Складовете на събития са СУБД, чиято задача е да съхраняват различните

състояния на обектите от момента на възникването им. Обикновено съдържат

последователности от начално състояние и изменения, чрез които при заявка текущото

състояние на даден обект се получава чрез проиграване на всички събития за този

обект от време 0 до текущото време. За по-успешно представяне много от складовете

на събития, след определено натрупване на изменения в обекта, правят междинни

снимки на състоянието на обектите (snapshots).

Основната разлика с другите видове СУБД, в които няма заложено поддържането

на времево следене на събитията е, че те съхраняват само текущото състояние на

даден обект и губят историята, освен ако тя не е експлицитно моделирана.

Поддържаните операции от складовете на събития са добавяне на нови събития и

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

заличавания на вече регистрирано събитие, което опростява поддържането на

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

Примери: Event Store, NEventStore.

Graph DBMS

Граф базите данни са създадени за данни, чиито елементи са добре представени

като взаимосвързани елементи с неопределен брой отношения между тях. Типовете

85

отношения могат да бъдат, например: социални отношения, връзки межу линиите на

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

позволяват лесна обработка на данни от този тип и предоставят специфични функции

като – минималнен брой стъпки за достигане от една точка на графа до друга; най-къс

път; път, съобразен с различни условия и т.н.

Примери: Neo4j, OrientDB, Titan, ArangoDB, Giraph.

Key-value Stores

Хранилищата от тип ключ-стойност са вероятно най-простата форма на СУБД. Те

съхраняват само двойки ключове и стойности. Те позволяват на данните да се

съхраняват във формат, който не е таблица или схема. Данните могат да бъдат

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

и не е нужно да се използва фиксиран модел за данни. Тези прости системи

обикновено не са адекватни за сложни приложения. От друга страна, точно тази

простота ги прави атрактивни при определени обстоятелства, като например

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

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

плавен преход към документалните складове и ширококолонните хранилища.

Примери: Redis, Memcached, Amazon DynamoDB, Riak, Ehcache.

Multivalue DBMS

Многостойностните СУБД са системи за управление на база данни, които подобно

на релационни системи съхраняват данните в таблици. Разликата е, че те могат да

съхранят повече от една стойност в атрибута на записа. Тъй като това е в противоречие

с първата нормална форма, тези системи се наричат понякога системи NF2 (Non First

Normal Form). Някои релационни системи са разширени с функции, които позволяват

моделиране на поливалентни атрибути (например масиви от стойности). Въпреки това,

тези характеристики следва да бъдат използвани в релационните СУБД само в

специални случаи. Работата с такива стойности са прерогатив на многостойностните

СУБД, не на последно място защото тези системи не са оптимизирани за операцията

"join".

Примери: Adabas, UniData,UniVerse, D3

86

Native XML DBMS (NXD)

NXD са СУБД, чиито вътрешен модел на данните кореспондира с XML документи.

Това не са СУБД, които използват, например, релационен модел на данните и са в

състояние само да съхраняват данните като XML документи, а СУБД, които използват

пълната мощ на XML. Те могат да представят йерархични данни, разбират включените

PCDATA декларации в XML елементите, както и поддържат специфични XML езици за

заявки като XPath, XQuery или XSLT. Всъщност, самите данни не е задължително да са

съхранени като XML документи, тези СУБД може да използват други формати за по-

добра ефективност.

Примери: MarkLogic, Virtuoso, Sedna.

Navigational DBMS

Терминът навигационни СУБД обхваща клас от СУБД, които позволяват достъп до

множества от данни само през свързани записи (linked records). Тези системи се

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

управляват големи обеми от данни. В зависимост от гъвкавостта на свързване те са

групирани в йерархични СУБД и мрежови СУБД. Най-популярните са IMS на IBM и IDMS

на Computer Associates, които дори в днешно време понякога се използват.

Object oriented DBMS

Обектно-ориентираните СУБД се развиват през 80те години на миналия век,

мотивирани от общото развитие на обектно-ориентираните езици за програмиране.

Целта е съхраняване на обектите в базата от данни по начин, който съответства на

тяхното представяне в програмния език, а също така и запазване на връзките между

обектите (напр. наследяването) в самата база от данни. Обектно-ориентираните СУБД

следват обектно-ориентирания модел на данни с класове (схема от обекти), свойства и

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

използват техен собствен подобен на SQL език за заявки. В последните години някои

класически релационни СУБД се разширяват с обектно-ориентирани възможности, като

например дефинирани от потребителя типове от данни и структурирани атрибути.

Някои от тези разширения дори са стандартизирани в рамките на SQL.

87

Примери: Caché, Db4o, Versant Object Database, ObjectStore, Objectivity/DB.

RDF Stores (Tripel Stores)

Resource Description Framework (RDF) е методология за описание на информация,

разработена първоначално за описание на метаданни на ИТ ресурси. Днес се използва

много по-общо, често във връзка със семантичната мрежа (semantic web), но и в други

приложения. RDF моделът представя информацията като тройки "субект-предикат-

обект". СУБД, които са в състояние да съхраняват и обработват такива тройки, се

наричат RDF-складове. RDF-складовете могат да се разглеждат като подклас на

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

в горната нотация. RDF-складовете, обаче, предлагат специфични методи, които

надхвърлят тези на общите графови СУБД. Например, SPARQL е SQL-подобен език за

заявка за RDF-данни, който се подкрепя от повечето RDF-складове.

Примери: MarkLogic, Virtuoso, Jena, Sesame, AllegroGraph.

Search Engines

Търсещите машини са NoSQL СУБД, посветени на търсенето на зададени условия.

В допълнение към общата оптимизация за този тип приложение, специализацията се

състои в предлагане на характеристики като:

сложни изрази при търсене;

пълнотекстово търсене;

стеминг (възможност за изрязване на думата до корена);

класиране и групиране на резултатите от търсенето

геопространствено търсене;

разпределено търсене с висока мащабируемост.

Примери: Solr, Elasticsearch, Splunk, MarkLogic, Sphinx.

Wide Column Stores

Широко-колонните хранилища съхраняват данните в записи, които може да имат

много голям брой динамични колони. Тъй като имената на колоните и ключовете на

записите не са фиксирани, както и даден запис може да има милиони колони, широко-

колонните хранилища може да се разглеждат като двумерно хранилище от тип ключ-

88

стойност. Широко-колонните хранилища имат характеристики като безсхемните

документни складове, но реализацията им е на различен принцип. BigTable на Google

се счита за първообраз на тоя клас бази от данни [Chang et al, 2006].

Примери: Cassandra, HBase, Accumulo.

По-пълен списък с над 150 различни вида нерелационни база данни е достъпен

от http://nosql-database.org/, на http://db-engines.com/ има списък от над 270 бази от

данни (вкл. релационни), с по-важните характеристики на всяка от тях и статистика за

популярността им (общо или по групи).

4.19 Сравнителни характеристики и представяне

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

данни осигуряват е трудно да се прави общо сравнение между тях. Разработчиците

следва да се насочват към една или друга система, отчитайки различни фактори както

от страна на възможностите на СУБД, така и колко би струвало реализирането на

приложението – цена на лиценз, поддръжка, обучение, и т.н.

Не на последно място по отношение на системи, свързани с организиране и

поддръжка на държавни и административни дейности, следва да се има предвид

безопасността от гледна точка на национална безопасност. В момента на национално

ниво в Русия се обсъжда проблемът за технологичното осигуряване на страната с ИТ

специалисти и в частност използването на СУБД [Муравьев и др., 2015].

В подкрепа на разсъжденията за обезпокоителното състояние в Русия, изказани в

горния източник, ние направихме извлечение, показващо от кои страни са фирмите

или основните разработчици (при малките бази от данни) на СУБД в момента. Списъкът

на базите от данни е взет от www. db -engine s .com .

Причините за смазващата разлика в присъствието на американски компании са

няколко. Една от тях е по-доброто присъствие на техните проекти в Интернет (някои от

представените системи са на практика докторански и магистърски работи), азиатския

пазар и производство вероятно и поради езиковите разлики не е влязъл в

разглежданията. Но на практика повечето големи производители, както на

комерсиални продукти, така и на системи с отворен код, са регистрирани в Щатите.

89

фиг. 13. Разпределение по страни (където е седалището на организацията / откъдето е основният разработчик)

4.19.1 Сравнителни характеристики по модели данни

Бен Скофилд категоризира нерелационните бази данни въз основа на

нефункционални категории („(il)ities“) и рейтинг на съвкупността от функциите, които

покриват [Scofield, 2010]:

Модел на данните Производителност Мащабируемост Гъвкавост Сложност Функционалност

Хранилище ключ-стойност Висока Висока Висока Няма Променлива (нулева)

Колонно хранилище Висока Висока Средна Ниска Минимална

Документно хранилище Висока Променлива (висока) Висока Ниска Променлива (ниска)

Граф бази данни Променива Променлива Висока Висока Теория на графите

Релационни бази данни Променлива Променлива Ниска Средна Релационна алгебра

Christoforos Hadjigeorgiou [epcc, 2013] прави сравнение между MySQL и MongoDB

като представители на двата големи класа – релационни и NoSQL бази от данни.

Сравнението цели да покаже поведението на базите по отношение на способността им

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

Изследването показва плюсовете и минусите на всяка от парадигмите и реализациите.

4.19.2 Сравнения между СУБД по отношение на производителност и

мащабируемост

Популярно средство за сравнение между базите от данни е създадената

платформа от група изследователи в Yahoo YCSB (Yahoo! Cloud Serving Benchmark) за

"улесняване на сравняването на резултатите от обслужващи системи новото поколение

90

на данни в облака, по-специално оценка на издържливостта на натоварвания, които се

различават от тези, измерени чрез показатели, предназначени за по-традиционните

СУБД".

Sergey Bushik [altoros, 2013] прави независимо (от компании-производителки)

сравнение между Cassandra, HBase, MongoDB и Riak, използвайки апарата на YCSB.

Изследванията потвърждават факта, че няма перфектна NoSQL база от данни. Всяка

има добри и слаби страни, които са повече или по-малко важни в зависимост от типа

на задачата. В допълнение, от голямо значение е и капацитетът на хардуера, който (ще)

се използва.

фиг. 14. Част от резултатите от сравненията в [altoros, 2013]

91

Denis Nelubin и Ben Engber, [thumbtack, 2013] правят сравнение между Aerospike,

Cassandra, MongoDB и Couchbase (1.8 и 2.0), фокусирайки изследванията си върху

поведението на базите от данни при варианти SSD - storages и in-memory data sets, а не

общо срещащото се rotating disks. Идеята е била да се покажат възможностите, в

случаите когато компании биха се насочили да ползват такъв тип системи, за нуждите

на които фиксирани мрежи вършат достатъчно добра работа.

В тяхното изследване Aerospike е постигнал изненадващо блестящи резултати при

дисковите операции с множество възли (достигайки до 200 хиляди операции в

секунда), което се е очаквало, защото тя е оптимизирана за работа върху SSD, но не чак

толкова. В случая, когато целият набор от данни се вписват в RAM и гаранциите за

устойчивост са отслабени, резултатите на Aerospike и Couchbase доста си приличат.

Cassandra и MongoDB доста изостават, но по принцип и двете предлагат значително по-

голям набор от функции, което не се отчита при този тест, а е от значение при избора

на база от данни. Също така експериментите измерват прякото изпълнение ключ-

стойност и е нормално системите с този модел да са в по-изгодна позиция.

фиг. 15. Част от резултатите от сравненията в [thumbtack, 2013]

92

End Point Corporation прави изследване на представянето на Cassandra, HBase, и

MongoDB през 2013г, и през 2015г като тогава включва и Couchbase [endpoint, 2015].

Изследванията използват апарата на YCSB върху Amazon Web Services EC2 instances.

По-долу са изведени резултатите от тези тестове спрямо постигнатите операции в

секунда (колкото по-голямо число, толкова по-добре) и спрямо латентния период на

отговор (тук по-малкото число показва по-добрия резултат) на съответните СУБД.

фиг. 16. Load process

фиг. 17. Read-mostly Workload

фиг. 18. Balanced Read/Write Mix

93

фиг. 19. Read-Modify-Write Workload

фиг. 20. Mixed Operational and Analytical Workload (Couchbase does not support scan operations)

фиг. 21. Insert-mostly Workload (without 16 and 32 nodes - created inconsistent results)

4.19.3 Сравнение спрямо популярността на системите в мрежата

В Knowledge Base of Relational and NoSQL Database Management Systems

(www.db-engines.com) извършват класиране на различните видове СУБД спрямо

тяхната популярност в мрежата. Методът на оценка на популярността на системите се

основава на:

брой споменавания на системата в уебсайтове (чрез Google и Bing);

общ интерес към системата (чрез Google Trends);

94

честота на технически дискусии за системата (брой въпроси и брой

заинтересовани потребители от тематичните Q&A сайтове: Stack Overflow и

DBA Stack Exchange);

брой на обяви за работа, в които се споменава системата (чрез търсачките за

работа Indeed и SimplyHired);

брой на профили в професионални мрежи, в които се споменава системата (в

случая – в LinkedIn);

съответствие в социалните мрежи (броя на туитове в Twitter, в които се

споменава системата).

Не се измерва броя на инсталациите на системите или използването им в рамките

на информационни системи. Може да се очаква, че увеличаването на популярността на

една система, измерено чрез тази популярност предхожда широко използване на

системата с определен фактор време, поради което това класиране може да се счита

като ранен индикатор.

По-долу са изведени данните от юли 2015г:

Спрямо модела на данните

фиг. 22. Проценти спрямо брой системи по категории

95

фиг. 23. Проценти на популярност на всяка категория

фиг. 24. Исторически тренд на популярността по категории

*) За всеки месец се взема среден процент популярност от трите най-добри системи от

категорията.

Спрямо критерия "комерсиални"/"с отворен достъп"

фиг. 25. Брой системи по категории

96

фиг. 26. Проценти на популярност на всяка категория

фиг. 27. Тренд на популярност

фиг. 28. Съотношение спрямо модела на данните

97

The top 5 commercial systems, July 2015

Rank System Score Overall Rank

1. Oracle 1457 1.

2. Microsoft SQL Server 1103 3.

3. DB2 198 6.

4. Microsoft Access 144 7.

5. SAP Adaptive Server 87 11.

The top 5 open source systems, July 2015

Rank System Score Overall Rank

1. MySQL 1283 2.

2. MongoDB 287 4.

3. PostgreSQL 273 5.

4. Cassandra 113 8.

5. SQLite 106 9.

фиг. 29. Исторически тренд на популярността на отделните системи

98

Глава 5.

Методи за достъп12

За методи за достъп се говори практически от времето на появата на първите

компютърни периферни устройства. Първоначално методите за достъп са функции на

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

вход/изход от асемблерните езици [Stably, 1970] или чрез съответни оператори за

вход/изход при езиците от по-високо ниво (напр. FORTRAN, COBOL, PL/I и др.).

Появата на първите бази от данни през 60-те години на миналия век предизвиква

постепенно възприемане на понятията "физическа" и "логическа" организация на

данните [CODASYL, 1971]. През 1975 година вече ясно се разделят понятията "методи

на достъп", "физическа" и "логическа" организация на данните [Martin, 1975].

По това време Кристофър Дейт [Date, 1977] специално отбелязва:

"На системата за управление на базата от данни (СУБД) не е известно нищо

за това:

какви са физическите записи (блокове);

как съхраняваните полета са свързани в записи (въпреки че в много случаи

това е очевидно вследствие на тяхното физическо разположение);

как се осъществява подреждането (например това може да се реализира

въз основа на физическата последователност, по индекс или чрез верига

указатели);

как се реализира прекият достъп (т.е. посредством индекс,

последователно преглеждане или хеш-адресация).

Тази информация е част от структурите за съхраняване на данните, но тя се

ползва от метода за достъп, а не от СУБД".

Методът за достъп предполага точно определена организация на файла, с който

оперира и няма отношение към взаимовръзките между файловете, респективно между 12 Материалът е от [Марков, 2006] и [Markov et al, 2008]

99

записите от един файл и тези от другите файлове. Тези връзки се управляват на ниво

физическа организация на базата от данни.

Така, в системите за управление на бази от данни се формират четири нива:

методи за достъп на ядрото на операционната система;

специализирани методи за достъп, надграждащи тези на ядрото на

операционната система;

физическа организация на базата от данни;

логическа организация на базата от данни.

През 80-те години се появяват "многомерни методи за достъп" и съответни

"пространствени информационни структури", а през последните години и

"пространствено-времеви информационни структури". Тези методи за достъп

надграждат тези на операционните системи, специализирайки ги към определени

модели. От различни гледни точки този период е представен в [Ooi et al, 1993], [Gaede,

Günther, 1998], [Arge, 2002], [Mokbel et al, 2003], [Moënne-Loccoz, 2005].

Обикновено едномерните (линейни) методи се ползват от класически

приложения, базирани на буквено-цифрова информация, докато многомерните

(пространствени) се свързват най-често с графично-образна, мултимедийна

информация и др. На многомерните методи днес се отделя особено внимание. Може

би сред най-популярните анализи на методите за достъп е този в [Gaede, Günther,

1998], в който е предложена схема на генезиса на повечето от популярните днес

основни методи и техните модификации. Тази схема първоначално е предложена в

[Ooi et al, 1993]. През 1998 г. тя е допълнена и публикувана в [Gaede, Günther, 1998].

Едно нейно развитие в посока многомерни пространствено-времеви методи е дадено в

[Mokbel et al, 2003].

На фиг. 30 е представен нов вариант на тази схема, в който са добавени методи,

възникнали след 1998 г. и е отразен генезисът на представената в настоящия труд

разработка. На фигурата с курсив са указани методите, включени от [Gaede, Günther,

1998], а с подчертаване – тези от [Mokbel et al, 2003]. Методите, които се срещат и в

двете публикации са с курсив и подчертаване едновременно.

100

фиг. 30. Генезис на методи за достъп и техни модификацииразширен вариант на [Gaede, Günther, 1998] и [Mokbel et al, 2003]

101

Схемата е допълнена и с методи, касаещи работата с едномерна буквено-

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

системи на фирма IBM [Stably, 1970].

Методите, представени на фигура 1 ще групираме и разгледаме както следва:

- едномерни методи за достъп;

- многомерни пространствени методи за достъп;

- метрични методи за достъп;

- високо-размерни методи за достъп;

- пространствено-времеви методи за достъп.

5.1 Едномерни методи за достъп

В литературата, на която се базира тази част от обзора, се ползва понятието

"запис". Ще припомним [Stably, 1970], че "запис" е логически набор от полета,

съдържащи данни, евентуално свързани с уникален идентификатор ("ключ"),

позволяващ да се отличи даден набор полета от другите. Записите се обединяват в

множества, наричани "набори от данни".

В основата на всички методи за достъп лежат три формáта на записите – с

фиксирана, променлива или неопределена дължина.

Всички записи с фиксирана дължина в рамките на един набор от данни имат

еднаква дължина, която следва да е известна за да може коректно да се работи с тези

записи.

Записите с променлива дължина се предхождат от специален префикс, съдържащ

информация за дължината на записа и евентуално допълнителна системна

информация.

Съществува и възможност приложната програма сама динамично да определя

размера на записвания или извличания запис, т.е. дължината отново е променлива, но

пред записите не се задава споменатия по-горе префикс. В този случай, се казва, че

записите са с неопределена дължина.

Понятията "набор от данни" и "файл" не се припокриват, тъй като в някои

файлове освен данните се записва и значителна служебна информация – индекси и пр.,

която не е част от набора от данни. В някои случаи служебната информация или не

102

съществува, или се съхранява отделно от набора от данни, и тогава един файл може да

съдържа точно един набор от данни.

Ще споменем още едно понятие, което в последно време не е много популярно,

но съществува и следва да се отчита. Това е видът на достъпа: "базов" или "опашков".

При базовите методи за достъп приложната програма сама организира

информационната обмяна, включително ускоряването на работата с външните

устройства, т.е. – буферирането, синхронизирането, блокуването и разблокуването на

записите, откриването на грешки и др. Развитието на операционните системи

постепенно затвори възможностите за ползване на този вид достъп – наличието им е

по-скоро за съвместимост със стари версии на приложните програми.

По тази причина методите за достъп, които днес са в употреба са като правило

"опашкови", при които автоматично се изпълняват практически всички служебни

дейности по осъществяването на информационната обмяна.

Това ще опрости и нашия преглед по-долу, защото без специално доуточняване

ще предполагаме този вид методи.

5.1.1 Контекстно-независими методи за достъп

При контекстно-независимите методи съхраняването на информационните

елементи не е свързано с тяхното съдържание и зависи изцяло от външни за

елементите фактори – поредност, адрес на диска или във файла и др.

Необходимостта от стабилни стандартизирани файлови системи в операционните

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

Контексно-независими методи за достъп са например възприетите в популярните

от 60-те и 70-те години на м.в. операционни системи за сериите 360 и 370 машини на

фирмата IBM [IBM, 1965-68]:

последователен достъп;

пряк достъп с фиксирана дължина на записите;

библиотечен (partitioned) метод за достъп.

С появата на микрокомпютрите тези методи придобиха нов вид, но запазиха

основните си характеристики.

103

Последователен метод за достъп (Sequential Access Method – SAM)

Това е най-старият метод на достъп. Може да има фиксирана, променлива или

неопределена дължина на записите. За нас обаче той не представлява особен интерес,

тъй като организацията на многомерен достъп до големи по обем информационни

пространства чрез последователен (очевидно – линеен) достъп няма оперативен

практически смисъл – този вид достъп все още се прилага например за дългосрочно

съхраняване на големи обеми от данни на магнитни ленти.

Прекият метод за достъп (Direct Access Method – DAM)

Този метод на достъп предполага усложнен начин на секциониране на външната

памет и фиксирана дължина на записите. С появата на UNIX-подобните операционни

системи при мини-компютрите, а по-късно и при персоналните компютри,

динамичното разпределение на дисковото пространство стана обичайна практика.

Файловата система се базира на дървовидна многосписъчна структура, като всеки файл

е списък от клъстери, съдържащи блокове (обикновено по 512 байта), връзката между

които се осигурява от специална таблица за разположение на файловете (напр. File

Allocation Table – FAT при редица ранни файлови системи на Microsoft Inc.). В този

случай, въпреки, че се употребяват термините последователен файл и директен файл,

от гледна точка на файловата система файловете не се различават – всички могат да

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

индикация нито в каталога, нито където и да е другаде, която да определя файла като

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

записа или начина на блокуване на записите. Благодарение обаче на FAT, може да се

изчисли точната позиция (адреса) на всеки байт от файла (номер на сектор и

отместване в сектора) – това именно дава възможност на операционната система да

осъществи пряк достъп до данните на файла и да предостави функции както за

последователен, така и за пряк достъп до всеки файл [Войников, 1988].

Потребителската програма избира вида на достъп според логиката на обработка

и най-вече според логическата структура на данните, като всички обръщения към

файла се трансформират до "преки" обръщения към определена точка от списъка,

104

съдържащ файла, от която нататък се записва или чете съответно (фиксирано,

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

Библиотечен метод за достъп (Partitioned Access Method – PAM)

Този метод представлява по същество едномерно информационно пространство.

Библиотеките, организирани с този метод, се състоят от справочник и раздел за

данните. В справочника, разположен в началото на файла, за всеки набор от записи се

съхранява 8-байтово име, три-байтов указател към началото (адреса) на набора,

служебна информация и до 62 байта указатели към допълнителни входни точки на

набора от записи. Самите набори от записи се съхраняват във файла след справочника.

Те могат да са с различна дължина и могат да бъдат обновявани, добавяни и

изтривани. При изтриване се премахват само имената от справочника, но съответните

им набори от записи остават във файла до неговото престуктуриране. Библиотечните

файлове са с последователен достъп, но благодарение на указателите в справочника

става възможно пряко обръщение към конкретен набор от библиотеката. Този вид

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

модули, компоненти, бази от данни и др. За нашите цели обаче този метод е

неприложим поради твърде разточителния по памет справочник, съдържащ важна от

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

информационни пространства.

5.1.2 Контекстно-зависими методи за достъп

Основната идея при контексно-зависимите методи е, че част от записа се избира

за ключ, въз основа на който се преценява къде да се съхрани записът и след това как

да се търси. Така съдържанието на записа влияе на съхранението и достъпа до него.

Исторически от 60-те години на миналия век вниманието е насочено основно към

този вид методи. Съвременните системи за управление на бази от данни се изграждат

чрез контекстно-зависими модели [Connolly, Begg, 2002]. Може би влиянието на

мечтите от областта на изкуствения интелект са причина да се търси контексна

зависимост до най-ниски нива на организация на информацията – включително до

реализация на машини за бази от данни [Ozkarahan, 1986].

105

Контекстно-зависими методи за достъп според [Connolly, Begg, 2002] са:

Неподредени последователни файлове със записи с ключове;

Сортирани файлове с фиксирана дължина на записите;

Статични хеширани файлове;

Динамични хеширани файлове;

Индексни файлове и файлове с данни;

Клъстеризирани индексирани таблици.

Неподредени последователни файлове

Може би исторически най-ранни, този вид файлове съдържат записи с фиксирана

или променлива дължина с ключове. В тези файлове новите записи се добавят винаги в

края на файла, а търсенето е линейно от началото към края на файла. За ускоряване на

достъпа записите могат да са блокувани в страници.

Сортирани файлове с фиксирана дължина на записите

Записите са сортирани по стойностите на едно или няколко полета (ключ) и това

осигурява възможност за по-ефективно търсене от линейното (например двоично).

Операциите за вмъкване и премахване на записи се усложняват във връзка с

необходимостта файлът да се поддържа винаги подреден. Например вмъкването на

запис в началото на голям файл може да се окаже твърде дълъг процес. В такива

случаи се прибягва до т.нар. файл за препълване (overflow file) или файл на

транзакцията (transaction file), като всички операции по допълване се изпълняват във

файла за препълване, който периодично се слива с основния подреден файл. При

странична организация на файла операциите се усложняват още повече.

Статични хеширани файлове

При тях записите могат да не се добавят последователно. За изчисляването на

адреса, на който да се помести записът, се ползва хеш-функция (hash function),

параметри на която се явяват едно или няколко полета от записа (hash fields). Ако

полето освен това е и ключ, то се нарича хеш-ключ (hash key). Доколкото записите се

поместват на страниците в рамките на цялото достъпно за файла пространство, което

предварително е фиксирано, този вид файлове се наричат файлове с произволен или

106

пряк достъп (random file или direct file). Недостатък на хеш-функциите е, че те не

гарантират получаването на уникален адрес, тъй като количеството възможни

стойности на полето за хеширане могат да са значително повече от адресите, достъпни

за записи. На всеки изчислен от хеш-функцията адрес съответствува определена

страница или сегмент (bucket) с няколко клетки (слотове), предназначени за няколко

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

случай, че един адрес се генерира за повече от един записа се появява конфликт

(collision). Такива записи се наричат синоними. За разрешаването на конфликтите се

ползват различни методи:

открита адресация – поставяне на изпадащите записи на първото свободно

място във файла и последващото им линейно търсене;

несвързана област за препълване, в която се записват изпадащите записи;

свързана област за препълване, в която за всеки сегмент има съответна зона,

а в самия сегмент се поддържа указател към нея;

многократно хеширане чрез прилагане на допълнителна хеш-функция, която

да разреши конфликтите. Обикновено тя се прилага за областта на

препълване.

Динамични хеширани файлове

При този вид достъп е възможно адресното пространство на хеш-функцията,

респективно – файла, да се увеличава по време на работа и в зависимост от нуждите да

се добавят нови сегменти. В началото записите се добавят само в първия сегмент, а

като се запълни, той се разделя на определен брой части. За да може да се осигури

достъпа се поддържат таблица на адресите на сегмента (Bucket Address Table – BAT)

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

Индексни файлове и файлове с данни

Индексът е спомагателен структуриран файл, съдържащ стойности на ключове и

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

индексния файл обикновено са структурирани по стойностите на ключовете. Основните

типове индекси са:

107

първичен индекс – файлът с данни се подрежда последователно по полето на

ключа и на негова основа се създава поле за индексация, което гарантирано

има уникални стойности във всеки запис;

клъстерен индекс – файлът с данни се подрежда последователно по

неключово поле и на основата на това неключово поле се формира поле за

индексация. В този случай е възможно няколко записа да съответствуват на

дадена стойност на полето за индексация. Неключовото поле се нарича

"атрибут на клъстеризация".

вторичен индекс – индекс, определен върху поле от файла с данни, което е

различно от това, по което той е подреден. Възможно е да се създават повече

от един вторични индекси, докато първичният и клъстерният са само по един.

Когато файлът с данни е сортиран и притежава само първичен индекс, той се

нарича "индексиран последователен файл" и обикновено има три компоненти –

първична област за данни, отделен индекс и област за препълване. Подобна

организация се ползва при Индексно-последователния достъп (Indexed Sequential

Access Method) на фирмата IBM, който е тясно свързан с характеристиките на

оборудването.

В началото на 70-те години, фирма IBM предлага виртуалeн метод за достъп

(Virtual Storage Access Method - VSAM), който не зависи от оборудването. VSAM е

стандартен метод за достъп за операционните системи OS/VS и z/OS [IBM, 1975], [IBM,

2003]. Той поддържа три организационни типа:

ESDS (Entry-Sequence Dataset) прилича на стандартен "плосък" файл с

последователен достъп;

RRDS (Relative-Record Dataset) прилича на файл с пряк достъп;

KSDS (Key-Sequenced Dataset) може да се обработва последователно или с

произволен достъп въз основа на ключове в записите от данни. Записите

могат да се достигат и чрез алтернативен индекс.

Недостатък на VSAM е необходимостта програмистите и аналитиците да имат

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

108

Клъстеризирани индексирани таблици

Когато библиотечният метод за достъп се ползва за съхраняване на таблици, е

възможно да се приложи т.нар. клъстеризация – в рамките на библиотеката (клъстера)

се съхраняват само таблици, които имат съвпадащи (ключови) колони и се ползват

съвместно. Ако взаимосвързаните записи се съхраняват физически в непосредствена

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

таблиците се наричат "ключ на клъстера". Те се пазят само в един екземпляр и могат да

бъдат индексирани. Подобна организация е налична в редица СУБД, в частност – в

Oracle [Oracle, 2005].

5.2 Пространствени методи за достъп

Многомерните пространствени методи за достъп се създават да обслужват

пространствени обекти като точки, линейни сегменти, многоъгълници, многостени и

пр. Целта е да се поддържат пространствени справки, такива като запитване за най-

близки съседи (да се намерят всички градове отстоящи на разстояние до 10 мили от

Вашингтон), или интервални справки (да се намерят всички езера на Земята между

30-тия и 40-тия паралели) и т.н. Приложенията са многобройни, включващи

традиционното многоатрибутно индексиране при базите от данни, географските

информационни системи и пространствените бази от данни, индексирането по

съдържание при мултимедийните бази от данни и др.

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

основни класа от методи на достъп [Gaede, Günther, 1998] – точкови и пространствени.

Точковите методи за достъп (Point Access Methods – PAM) се използват за

организиране на многомерни точкови обекти (например градове, при което всеки град

е точка, която се представя чрез три координати – географска ширина, дължина и

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

атрибут от релацията). Точковите методи се делят на три основни групи:

многомерно хеширане (Multidimensional Hashing) – Grid File и негови

разновидности, EXCELL, Twin Grid File, MOLPHE, Quantile Hashing, PLOP-

Hashing, Z-Hashing и др.;

109

йерархични методи за достъп (Hierarchical Access Methods) – KDB-Tree, LSD-

Tree, Buddy Tree, BANG File, G-Tree, hB-Tree, BV-Tree и др.;

пространствено-покриващи криви за точкови данни (Space Filling Curves for

Point Data) – Peano curve, N-trees, Z-Ordering и др.

Пространствените методи за достъп (Spatial Access Methods – SAM) се

използват за работа с обекти с произволна форма. При тях основната идея за

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

реалните обекти вместо тяхната истинска геометрия. Най-често използваната

апроксимация в популярните методи от типа SAM е минималният граничен

правоъгълник (Minimum Bounding Rectangle – MBR) на обекта, т.е. минималният

правоъгълник, чиито страни са успоредни на координатните оси и напълно съдържа

обекта. Съществуват и подходи за апроксимация чрез минимални гранични сфери (SS

Tree) и други политопи (например Cell Tree), както и техни комбинации (например SR-

Tree).

Съществуващите предложения за пространствени методи (SAM) могат да бъдат

групирани въз основа на използваните при тях различни техники на организация на

пространствените обекти:

трансформации (Transformation);

припокриващи се региони (Overlapping Regions);

изрязване (Clipping);

множество слоеве (Multiple layers).

Първата техника използва трансформация (Transformation) на неточковите обекти

до точки в повече или по-малко мерно пространство. Така всеки метод за достъп до

точки или буквено-цифрови данни може да бъде използван за индексиране на

(трансформираното) множество от данни. Много от тези методи се базират на

използването на пространствени покриващи криви за получаване на едномерни

стойности на обектите, например криви на Пеано; z-ordering; криви на Хилберт; Gray

ordering. Основното преимущество на този подход е, че точковите методи за достъп

могат да се прилагат за неточкови обекти, при което проблемът за индексирането на

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

числови стойности. Тук следва да споменем метода UB-Tree [Bayer, 1996], който е

110

вариант на B-Tree, в който ключовете са адреси на региони подредени чрез "≤" и z-

ordering.

Втората техника борави с припокриващи области (Overlapping Regions), като

множеството от данни се разпределя в групи, при което две различни групи от обекти

могат да заемат части от едно и също пространство от данните, но всеки пространствен

обект се асоциира само с една от групите. Методите за достъп в тази категория

оперират с данните директно в тяхното естествено пространство (без някакви

трансформации) в евентуално припокриващи се сегменти. Те използват прости техники

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

припокриване. Методите за достъп, използващи техниката на припокриващи се

области, включват R-Tree, R-link-Tree, Hilbert R-Tree, R*-Tree, Sphere Tree, SS-Tree, SR-

Tree, TV-Tree, X-Tree, P-Tree of Schiwietz, SKD-Tree, GBD-Tree, Buddy Tree with

overlapping, PLOP-Hashing и др.

Третата техника използва изрязване (Clipping) като по този начин един обект

може да се раздели на няколко подобекта, които да се съхранят. Основната мотивация

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

минимизират припокриванията. Това всъщност е главната полза от тези методи. Все

пак в стремежа да се постигне нулево припокриване между сегментите,

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

съхранени в различни сегменти. В резултат на прилагането на метода може да се появи

излишество, което не може да бъде управлявано, водещо до увеличаване на разхода

на ресурси и намаляване на производителността на метода. Методите за достъп от

тази категория включват например R+-Tree, Cell-Tree, Extended KD-Tree, Quad-Tree и др.

Например чрез Quad-Tree се представят двумерни изображения чрез рекурсивно

разделяне на квадранти на полето на изображението и съответен дървовиден запис на

съдържимото им.

Четвъртата техника – техниката на разслояване (Multiple Layers) може да бъде

разглеждана като вариант на подхода на припокриващите се региони, тъй като

регионите с данни от различните слоеве могат да се припокриват. Но съществуват

няколко важни разлики: първо – слоевете се организират в йерахия; второ – всеки слой

дели универсума по различен начин; трето – регионите с данни в един слой не се

111

припокриват; и четвърто – регионите с данни не се адаптират към пространствените

разширения на съответните даннови обекти. Примери за такива методи са Multi-Layer

Grid File, R-File и др.

5.3 Метрични методи за достъп

Метричните методи за достъп (Metric Access Methods) отчитат относителното

разстояние на точките до избрани точки, наречени фокуси или отправни точки (anchor

points, vantage points или pivots) [Moënne-Loccoz, 2005]. Отчитайки разстоянията до

базата от фокуси, триангулачното неравенство се използва да се ограничи броят

разстояния, които трябва да се изчислят по време на търсене. Представители на такива

методи са VP Tree, BST-Tree, Geometric Near-Neighbor Access Tree, както и най-

ефективният от тази група методи – M-Tree.

5.4 Високо-размерни методи за достъп

С увеличаване на размерността силно се влошават качествата на многомерните

методи за достъп. Обикновено тези методи изчерпват възможностите си до

размерности около 15. Само X-Tree успява да достигне границата до 25 размерности,

след което и той започва да дава по-лоши резултати, отколкото последователното

сканиране [Chakrabarti, 2001].

Изходът от тази ситуация се основава на апроксимация на данните и

апроксимация на заявките при последователно сканиране (sequential scan). Те оформят

една нова група методи за достъп – Високо-размерни методи за достъп (High

Dimensional Access Methods).

Апроксимация на данните се използва при методите VA-File, VA+-File, LPC-File, IQ-

Tree, A-Tree, P+-Tree и др.

Апроксимация на запитванията – понеже във високо-размерните пространства

селективността на методите за достъп се влошава, се допуска неточност на отговорите.

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

1) Разглеждане само на част от базата, която е по-вероятно да съдържа

резултатното множество – като правило тези методи са основани на клъстеризация на

базата от данни. Сред тези методи са DBIN, CLINDEX, PCURE.

112

2) Разбиване на базата на няколко по-ниско размерни пространства и търсене във

всяко от тях. Използват се два основни подхода, основани на тази стратегия – Random

Lines Projection (представители на този подход са MedRank, който използва B+-Tree за

индексиране на всяка произволна линейна проекция на базата от данни и PvS Index –

комбинация на итеративни проекции с клъстеризация) и Locality Sensitive Hashing,

базиран на множество от локално-сензитивни хеширащи функции [Moënne-Loccoz,

2005].

5.5 Пространствено-времеви методи за достъп

Пространствено-времевите бази от данни имат допълнително дефинирано

времево измерение, което съответно се явява допълнителна координата [Mokbel et al,

2003]. Те оперират с обекти, които променят своето положение и/или форма с течение

на времето.

фиг. 31. Развитие на пространствено-времевите методи за достъп[Nguyen-Dinh et al, 2010]

113

В зависимост от това, кой времеви интервал индексират, пространствено-

времевите методи за достъп (Spatio-Temporal Access Methods) се делят на 4 групи –

индексиращи миналото, настоящето, бъдещето, и коя да е точка от времето. [Nguyen-

Dinh et al, 2010]

Методи, индексиращи миналото: семплирането подпомага намаляването на

размера на съхранените исторически данни. За формиране на траекторията се

използват линейни и нелинейни интерполации между последователните семпли.

Използвани методи – тримерни структури (Multiple TSB-tree, FNR-tree, MON-tree),

припокриващи много-версионни структури (PA-tree, GS-tree), траекторно-ориентирани

структури (CSE-tree, Polar Tree, Chebyshev Polynomial, RTR-tree).

Методи, индексиращи настоящето: проследяват текущото състояние на

непрекъснато движещи се обекти; обикновено се използват в приложения за следене

на трафика. Примери – LUGrid, RUM-tree, IMORS.

Методи, индексиращи бъдещето: използват методи за предстказване на бъдещи

локации на обектите на базата на текущи координати и скорост. Използват се различни

принципи – оригинално пространствено-времево поле (MOVIES), дуални

трансформации (STRIPES, MB-index), пространствено-покриващи криви (Bx-tree, By-tree,

ST2B-tree, Bdual-tree, BdH-tree), параметризация на времето (STP-tree, ANR-tree).

Методи, индексиращи данни от всяка точка от времето: Rppf-tree (надгражда

TPR-tree), PCFI+-index (върху SETI), BBx-tree (на базата на Bx-tree), UTR-tree (разширява

MON-tree), STCB+-tree (използва множество компресирани B+-tree), PPFI (използва 2D

R*-tree за индексиране на пътната мрежа и 1D R*-tree за времевия интервал от

миналата траектория на движещия обект).

114

Глава 6.

Hadoop; MapReduce

Обемът данни, който в момента светът произвежда, наистина е огромен; по

данни от Facebook всеки ден се добавят 300 милиона нови изображения, NYSE създава

и реплицира ежедневно около 1 TB данни, а големият адронен колайдер генерира

40 TB експериментални данни дневно. Но освен задачата за съхранението на данни,

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

време. Променят се изискванията и към решенията на задачите за имитационно

моделиране, статистически анализ, машинно обучение.

За успешното решаване на тези проблеми в края на 2000те години се явява група

концепции, методи и инструменти за обработка на данните с общото наименование

Big Data. Аналитиците на Gartner описват три основни характеристики на Big Data –

т.нар. "три V" – volume (физическия обем на съхраняваните данни), velocity (скорост на

промяна на данните и като следствие от това последващия анализ на тези изменения)

и variety (многообразие – разнообразие на обработваните типове данни, както

структурирани, така и неструктурирани).

Една от ключовите технологии за реализиране на концепцията Big Data се явява

платформата Hadoop.

6.1 Hadoop – разпределено съхранение и обработка на данни

върху клъстери

Hadoop е проект на Apache Software Foundation, който представлява свободно

разпространявана платформа за разпределено съхранение и обработка на

свръхголеми множества от данни върху компютърни клъстери, изградени от

оборудване от масовия клас (commodity hardware). Всички модули на Hadoop са

115

проектирани така, че софтуерът автоматично да се справя със сбоевете на хардуера

(индивидуални машини или ракове от машини. [White, 2015][Петухов, 2012]

Разработката е започната през 2005 г. от Doug Cutting и Mike Cafarella в рамките на

проекта за създаване на търсачка с отворен код Nutch и впоследствие се отделя като

основен проект, развиван фондацията. Потребители на Hadoop са компании като

Facebook (по техни думи през 2011г клъстер с 2000 възела с размер 21PB), Yahoo (над

4000 възела с размер над 15 PB), Ebay (700 възела с 16PB), Twitter, Amazon и монго

други (пълният им списък може да бъде видян на страницата на Apache -

http://wiki.apache.org/hadoop/PoweredBy).

Към 2014 г. Hadoop се състои от четири основни модула:

Hadoop Common: набор инфраструктурни програмни библиотеки и средства,

използвани от останалите модули и родствени проекти, произлезли от него и

дори впоследствие станали проекти от основното ниво на Apache като Avro,

HBase, Hive, Pig, Zookeeper;

HDFS (Hadoop Distributed File System): разпределена файлова система, която

се грижи за съхраняването на данните върху машините;

Hadoop YARN (Yet Another Resource Negotiator): платформа за управление на

ресурсите, отговорна за управлението на компютърните ресурси в клъстерите

планирането на заявките от потребителите. ;

Hadoop MapReduce: имплементация на програмния модел за

широкомащабна обработка на данните, правата за използването на когото

Google предоставя на Apache Software Foundation през 2010 г., три месеца

след защитата му в патентното бюро на САЩ.

Hadoop Common

В Hadoop Common влизат библиотеки за управление на файловите системи,

поддържани от Hadoop и сценарии за създаване на необходимата инфраструктура и

управление на разпределената обработка, за удобство на изпълнението на които е

създаден специализиран опростен интерпретатор на командните редове (FS shell),

голяма част заимстван от Unix (cat, chmod, chown, chgrp, cp, du, ls, mkdir, mv, rm, tail),

обогатен със специфични за Hadoop (като - count изброява каталозите, файловете и

116

байтовете по даден път; expunge изчиства коша, а setrep модифицира коефициента на

репликация на даден ресурс).

HDFS

Hadoop Distributed File System (HDFS) е файлова система за съхраняване на

файлове с големи размери, разпределени по блокове между възлите на изчислителния

клъстер. Всички блокове в HDFS (без последния блок на файла) имат еднакви размери

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

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

В парадигмата на разпределеното съхранение и обработка на свръхголеми

количества данни е залегнало виждането, че отказът на машина е нормално явление, а

не инцидент. За осигуряване на устойчивост на разпределената система спрямо

отказите на отделни възли се използва методът на репликацията. HDFS има разработен

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

между надеждността и производителността. Осигуряването на автоматизиране на

диагностиката на изправността на отделните възли става чрез изпращане на

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

възела на имената с цел реакция при необходимост.

Файловете се записват само веднъж (не се поддържа модификация на файл), а

запис в дадено време може да осъществява само един процес, което пък осигурява

бързодействие на системата.

Hadoop поддържа традиционна йерархична система на организация на

файловете в пространството на имената – коренен каталог, поддържа влагане на

каталози и в един каталог може да има и каталози, и файлове. В Hadoop 1.0 има един

централен възел на имената (NameNode), съхраняващ метаданните на файловата

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

данните (DataNode), които непосредствено съхраняват файловите блокове. Възелът на

имената отговаря за обработката на операциите на ниво файлове и каталози, а възлите

на данните непосредствено обработват операциите по четене и запис на данни.

117

фиг. 32. Hadoop 1.0 - Архитектура на HDFS [White, 2012]

За преодоляване на тясното гърло, свързано с единствеността на възела на

имената, в Hadoop 2.0 се въвежда "HDFS federation" – множество възли на имена

управляват пространствата на имената, което позволява увеличаване на

хоризонталната мащабируемост.

фиг. 33. Разликата между HDFS във версии 1.0 и 2.0 13

Въпреки че HDFS е част от проекта Hadoop, той може да работи и с други

разпределени файлови системи, например Amazon S3 е реализирана в основния

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

разпределена файлова система, например тя стои в основата на разпределената

13 http://www.slideshare.net/hortonworks/federationhadoop-worldfinal

118

NoSQL-СУБД HBase, в нейна среда работи мащабируемата система за машинно

обучение Apache Mahout.

YARN

YARN (Yet Another Resource Negotiator) е модул, който се появява с новата версия

Hadoop 2.0 (2013), отговарящ за управлението на ресурсите на клъстерите и

планирането на задачите.

фиг. 34. Промяна на архитектурата с появата на YARN в 2.0 14

В предишните реализации тези функции са били интегрирани в модула

MapReduce чрез включването на компонента JobTracker. Отделянето им в

самостоятелен демон (ResourceManager) позволява от една страна MapReduce да

облекчи работата си, фокусирайки се върху съществото на разпределената обработка,

както и други програми за разпределени приложения, които поддържат съответните

програмни интерфейси, също да могат да работят с NDFS. YARN осигурява възможност

за паралелна независима работа на няколко различни задачи в рамките на клъстера.

Разработчиците на разпределени приложения трябва да реализират специален клас за

управление на приложението (ApplicationMaster), който отговаря за координация на

заданието в рамките на ресурсите, които предоставя планировчика на ресурсите.

Планировчикът на ресурсите отговаря за създаване на екземпляр на класа на

управление на приложението и взаимодействието с него посредством мрежов

протокол. В такъв смисъл YARN може да се разглежда като клъстерна операционна

система.

14 http://www.tomsitpro.com/articles/hadoop-2-vs-1,2-718.html

119

6.2 MapReduce

Програмният модел MapReduce е парадигма за изпълнение на разпределени

изчисления за големи обеми от данни. Концепцията е предложена (и патентована) от

Google. Моделът е инспириран от съответни функции map и reduce във

функционалното програмиране.

Основните предпоставки са:

Map извършва трансформация.

Reduce извършва агрегация.

Заслугата на модела не са самите функции, а мащабируемостта и

отказоустойчивостта, която може да осигури за приложенията, които го използват.

фиг. 35. Map and Reduce [White, 2012]

Работата на MapReduce условно се състои от следните етапи:

Input read: входните данни се делят на блокове с определен размер (64MB-

128MB), наречени сплитове. MapReduce Framework закрепва за всяка функция Map

определен сплит. Входният четец чете данните от постоянното хранилище на данни и

генерира двойки "ключ/стойност".

Map: всяка функция Map получава на входа уникален списък от двойки

"ключ/стойност", обработва ги и на изхода подава нула или повече двойки, които са

междинен резултат. Входните и изходните типове може да са различни един от друг (и

обикновено са). Всички операции Map се изпълняват паралелно и независимо.

Partition: Целта на този етап е разпределение на получените междинни резултати

по reduce-заданията. Partition функцията взема ключа и броя reduce-възли и връща

индекса на reduce-възела, определен да продължи действията с този ключ. В най-

простия случай за Partition функция се използва хешираща функция по модул броя

120

reduce-възли. Изборът на тази функция е определящ за осигуряване на баланисиране

на натовареността. Некоректно избрана функция Partition може да доведе до

неравномерно разпределение на данните между reduce-възлите, а оттам до силно

забавяне на решението.

За избягване на значителното повторение на междинни ключове, произведени от

всяка Map-функция, се прави комбиниране на междинните резултати преди

изпращането им към Reduce-функцията. Обикновено функцията Combine е същата като

Reduce. Разликата е в насочването на изходящите резултати – в случая на Combine

изходът се записва в междинните файлове, откъдето се изпраща на Reduce задачата.

Sort/Group: На този етап става прехвърлянето на изходните данни от map-възлите

към входа на reduce-възлите, като се сортират, използвайки функция за сортиране,

подадена от приложението и се сливат общите данни, получени от различните възли.

Reduce: За всеки уникален ключ от сортирания списък се извиква функцията

Reduce, която извършва итерации през стойностите, асоциирани на този ключ и връща

нула или повече резултати. Всички операции Reduce се изпълняват паралелно и

независимо.

Output write: Резултатите, получени на етапа Reduce, се записват в изходен поток

в постоянното хранилище, като всеки Reduce-възел записва в отделен изходен поток.

фиг. 36. Общ изглед на стъпките на MapReduce 15

15 http://blog.matthewrathbone.com/2013/04/17/what-is-hadoop.html

121

Имплементация на MapReduce (Google)

Тук ще разгледаме първото описание на алгоритъма, дадено от Google през

2004 г. [Dean & Ghemawat, 2004]. Реализацията на Hadoop MapReduce общо взето

следва подобна схема. Усъвършенстванията по-късно са в междинната фаза на

процеса.

фиг. 37. Изпълнение на MapReduce [Dean & Ghemawat, 2004]

Когато потребителската програма извика функцията MapReduce се изпълняват

следните стъпки (номерираните етикети на фиг. 37 отговарят на номерата от долния

списък):

1. Библиотеката MapReduce в потребителската програма разделя входните

файлове на М парчета, наречени сплитове (размерът им се контролира от потребителя

чрез опционален параметър). След това започва да стартира множество копия от

програмата на клъстер от машини.

2. Едно от копията на програмата е специално – т.нар. Master. Останалите

(workers) получават задачите си от него. Задачата на Master е да разпределя M

map-задания и R reduce-задания, вземайки свободни възли и назначавайки им

поредното задание (map или reduce).

122

3. Worker, който е получил map-задание, чете съдържанието на съответния

входен сплит. Той прави разбор на двойките "ключ/стойност" от входните данни и

подава всяка двойка на Map-функцията, дефинирана от потребителя. Междинните

двойки "ключ/стойност", произведени от потребителската Map-функция, се буферират

в паметта.

4. Периодично буферните двойки се записват на локалния диск на map-възела,

разпределяйки се в R региона, на базата на функция Partition. Локациите на тези

буферни двойки се подават на Master, който е отговорен да ги препрати към възлите от

тип reduce-workers.

фиг. 38. Map-workers и Reduce-workers

5. Когато reduce-worker получи от Master тези локации, чрез отдалечена

процедура calls чете буферните данни от локалните дискове на map-възлите. След

прочитането на всички междинни данни се извършва сортировка и сливане така че

всички срещания на един и същи ключ да се групират заедно.

6. Reduce-worker преминава през сортираните междинни данни и всяка двойка от

междинен ключ и множество от междинни стойности я подава на дефинираната от

потребителя Reduce-функция. Изходът от тази функция се добавя към финалния

изходен файл на този reduce-възел.

7. Когато всички map и reduce задания приключат, Master връща управлението на

потребителската програма. При успешно завършване изходът е наличен в R изходни

файла (имената им се специфицират от потребителя). Обикновено потребителите не се

123

нуждаят от обединяването им, защото често тези файлове се подават като вход на

следващо повикване на MapReduce или към друго разпрелено приложение.

Приложения на MapReduce

MapReduce е приложим в множество задачи, включващи разпределено търсене

по шаблон, разпределено сортиране, статистика на уеб-логове, клъстеризация на

документи, машинно обучение, статистически машинен превод и др. MapReduce

моделът е адаптиран и за различни компютърни среди като multi-core и many-core

системи, облакови и мобилни среди.

Самият Google използва MapReduce като основен търсещ инструмент в своя

индекс на WWW, заменяйки напълно старите си индексиращи програми. Развитието в

Google се пренасочва към технологии като Percolator, Flume и MillWheel, които

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

позволявайки интегрирането "на живо" на резултатите от търсенето, без необходимост

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

Парадигмата на MapReduce предполага ациклично изпълнение първо на map-

функциите, а после на reduce-функциите. Затова тя не е удобна за прилагане в

итеративни алгоритми, например в някои алгоритми на машинното обучение, в които

често се налага да се обхожда едно и също работна множество няколко пъти.

MapReduce програмите не са гарантирано бързи. Големият плюс от този

програмен модел е, че разработчикът на програмното приложение трябва да се

фокусира само върху написването на потребителската Map и Reduce част от

програмата. От голямо значение, обаче, е доколко имплементацията на MapReduce е

оптимизирала междинната фаза на предаване на данните между Map и Reduce

възлите.

Стабилността на програмата също много зависи от съответната имплементация. В

имплементацията на Google от 2004г. (разгледана по-горе) критична точка за

алгоритъма се явява наличието на единствен Master, отказът на който може да срине

изпълнението на задачата. В Ruby имплементация на MapReduce – Skynet, специален

Master, а всеки Worker потенциално може да замени отказалия възел, който в момента

изпълнява ролята на Master и така системата става изключително устойчива.

124

Списък с имплементации на модела MapReduce

Към момента има различни имплементации на MapReduce на различни езици и

изпълняващи различни задачи:

проект /

компания

приложение интерфейс

на езици

Google MapReduce обслужване на търсещата машина и други проекти

от екосистемата

C++, Python и

Java

за вътрешна употреба

Apache Hadoop разпределена обработка Java отворен код

YAMR (Яндекс) обслужване на търсещата машина С (вероятно) за вътрешна употреба

Skynet (Geni) Ruby имплементация на MapReduce с основната

разлика, че няма специален Master-сървър и по

този начин е по-надеждна

Ruby отворен код

Qizmt (MySpace) разпределена обработка на големи клъстери от

Windows сървъри

C# отворен код

CouchDB (Apache) извличане на разпределени документи от БД JavaScript отворен код

MongoDB разпределена обработка на заявките към БД JavaScript отворен код

Riak разпределена обработка на заявките към БД Erlang платена; отворен код

за определени групи

Greenplum разпределена обработка на заявките към БД Python, Perl,

SQL и др.

платена

Disco (Nokia) разпределена обработка; заявки към DiscoDB Erlang, Python отворен код

Phoenix (Apache) разпределена обработка на заявките към БД (рел.) Си

Infinispam NoSQL хранилище на данни (K/V) и разпределена

платформа за мрежа от данни

Java отворен код

Apache Hive

(Facebook)

достъп до данни в БД SQL-подобен

език

отворен код

GridGain имплементация за in-memory computing Java отворен код

Cell Broadband

Engine

в процесорите Cell (проект на алианса Sony, Toshiba,

IBM) за свръхскоростни изчисления

Си

CUDA (NVIDIA) в графичните процесори NVIDIA

Qt Concurrent разпределение на задачите между ядрата на

компютъра

Qt на C++

DryadLINQ

(Microsoft

Research)

за паралелно изпълнение на заявките на езика LINQ

за Microsoft Dryad. През 2011 Microsoft се отказва от

развитието и преминава към използване на Apache

Hadoop framework.

125

Библиография

[ACM and IEEE, 2006] Shackelford, R. et al: The Joint Task Force for Computing Curricula 2005. Computing

Curricula 2005: The Overview Report. ACM, AIS, and IEEE-CS, 30-09-2005, ISBN: 1-59593-359-X

[altoros, 2013] Bushik, S.: A Vendor-independent Comparison of NoSQL Databases: Cassandra, HBase,

MongoDB, Riak

http://www.altoros.com/download_white_papers/vendor_independent_comparison_of_nosql_databas

es.html

[ANSI/X3/SPARC, 1975] ANSI/X3/SPARC Study Group on Data Base Management Systems: (1975), Interim

Report. FDT, ACM SIGMOD bulletin. Volume 7, No. 2

[Boehm, 1988] Boehm B.: A spiral model of software development and enhancement. Computer, 21(5), 1988,

pp.61-72, doi: 10.1109/2.59

[Bohm and Jacopini, 1966] Bohm, Corrado; and Giuseppe Jacopini (May 1966). Flow Diagrams, Turing Machines

and Languages with Only Two Formation Rules. Communications of the ACM 9 (5): 366–371.

DOI:10.1145/355592.365646.

[C3S, 1965] Curriculum Committee on Computer Science: Curriculum'68: An Undergraduate Program in

Computer Science, Preliminary Reccomendations. Commun. ACM, 8(9), 1965, pp. 543-552.

[Cattell, 2010] Cattell, R.: Relational Databases, Object Databases, Key-Value Stores, Document Stores, and

Extensible Record Stores: A Comparison. ODBMS: Expert Articles, Dec. 2010,

http://www.odbms.org/2010/01/relational-databases-object-databases-key-value-stores-document-

stores-and-extensible-record-stores-a-comparison/

[Chang et al, 2006] Chang F., J. Dean, S. Ghemawat, W. C. Hsieh, D. Wallach, M. Burrows, T. Chandra, A. Fikes,

R. Gruber: Bigtable: A Distributed Storage System for Structured Data. OSDI, 2006

http://static.googleusercontent.com/media/research.google.com/bg//archive/bigtable-osdi06.pdf

[Chen et al, 2014] Chen M., S. Mao, Y. Liu: Big Data: A Survey. Mobile Netw Appl, Springer, 2014, 19:171-209,

DOI 10.1007/s11036-013-0489-0

[Couchbase, 2015] Couchbase: Why NoSQL? White paper, 2015. http://www.couchbase.com/nosql-

resources/what-is-no-sql

[Dahl, Dijkstra & Hoare, 1972] Dahl, O.-J., Dijkstra, E., Hoare, T.: Structured Programming. Academic Press Ltd.

London, UK, 1972, ISBN:0-12-200550-3

126

[Dean & Ghemawat, 2004] Dean, J, Ghemawat, S.: MapReduce: Simplified Data Processing on Large Clusters.

OSDI'04., 2004 http://research.google.com/archive/mapreduce.html

[Dreyfus, 1962] Dreyfus Ph.: L’informatique. Gestion, Vol. 5, 1962, pp. 240-241.

[endpoint, 2015] Benchmarking Top NoSQL Databases: Apache Cassandra, Couchbase, HBase, and MongoDB.

Originally Published: 13.04.2015, Revised: 27.05.2015 http://blog.endpoint.com/2015/04/new-nosql-

benchmark-cassandra-mongodb.html

[epcc, 2013] Hadjigeorgiou Ch.: RDBMS vs NoSQL: Performance and Scaling Comparison, 2013, Univ. of

Edinburgh, https://static.ph.ed.ac.uk/dissertations/hpc-msc/2012-2013/RDBMS%20vs%20NoSQL%20-

%20Performance%20and%20Scaling%20Comparison.pdf

[Gray, 1981] Gray, Jim. The Transaction Concept: Virtues and Limitations. Proceedings of the 7th International

Conference on Very Large Databases: pages 144—154, 1981

[Hilbert, 2014] Hilbert M.: On the world’s information capacity. MIRI conversations, 22-04-2014.

https://intelligence.org/2014/04/22/martin-hilbert/

[Inmon et al, 2008] Inmon W. H., D. Strauss, G. Neushloss (2008) DW 2.0: The Architecture for the Next

Generation of Data Warehousing, Morgan Kaufman, 2008.

[Inmon, 1992] Inmon W. H.: Building the Data Warehouse, QED Technical Publishing Group, 1992.

[Kaser & Lemire, 2003] Kaser O., Lemire D. (2003) Attribute Value Reordering for Efficient Hybrid OLAP,

Proceedings of the 6th ACM international workshop on Data warehousing and OLAP, pp.1-8,ISBN:1-

58113-727-3, 2003

[Kerr & Hunter, 1993] Kerr J. M., R. Hunter: Inside RAD: How to Build a Fully Functional System in 90 Days or

Less. McGraw-Hill, 1993, ISBN 0-07-034223-7

[Kiczalesр 1997] Kiczales G, 1997 Aspect oriented programming. Proceedings of the European Conference on

Object Oriented Programming (ECOOP), 1997.

[Leavitt & Whisler, 1958] Leavitt, H.; Whisler, T.: Management in the 1980s. Harvard Business Review 11, 1958

[Longley et al, 1985] Longley, D., M. Shain. Dictionary of Information Technology. 2. Macmillan Press, 1985.

ISBN 0-333-37260-3. с. 164.

[Markov et al, 2008] Markov K, Ivanova, K., Mitov, I., Karastanev, S.: Advance of the access methods. Int. J.

Information Technologies and Knowledge, 2/2, 2008, pp.123-135.

[Matrin, 1991] Martin J.: Rapid Application Development. Macmillan, 1991, ISBN 0-02-376775-8

[Molina et al, 2009] Garcia-Molina H., J. D. Ullman, J. Widom. Database Systems – The Complete Book. Pearson

Education Inc., 2002, 2009, ISBN: 978-0-13-606701-6

127

[Moniruzzaman & Hossain, 2013] Moniruzzaman A. B. M., S. A. Hossain: NoSQL Database: New Era of

Databases for Big data Analytics - Classification, Characteristics and Comparison. Int. J of Database

Theory and Application, 6(4), 2013, 13p.

[Nguyen-Dinh et al, 2010] Nguyen-Dinh L.-V., W. G. Aref, M. F. Mokbel 2010. Spatio-Temporal Access Methods:

Part 2 (2003 - 2010). IEEE Data Engineering Bulletin, 33(2), 2010, pp.46-55

[planetcassandra, 2012] Apache Cassandra NoSQL Performance Benchmarks.

http://www.planetcassandr a .org/nosql-performance-benchmarks/

[Proctor and Scott, 2011] Proctor, K. Scott (2011), Optimizing and Assessing Information Technology: Improving

Business Project Execution, John Wiley & Sons, ISBN 978-1-118-10263-3

[Reynolds, 2015] Reynolds, G.: Ethics in Information Technology. 5th Edition, Cengage Learning, 2015,

ISBN: 9781285197159.

[Scofield, 2010] Scofield, B.: NoSQL - Death to Relational Databases(?).

http://www.slideshare.net/bscofield/nosql-codemash-2010. Retrieved 2014-06-26.

[Shoham, 1990] Shoham, Y.: Agent Oriented Programming. Technical Report STAN-CS-90-1335. Stanford

University, 1990.

[slant, 2015] What is the best cloud IDE?: http://www.slant.co/topics/713/~what-is-the-best-cloud-ide

[Stok & Stok, 2013] Stock, W.G., Stock, M.: Handbook of Information Science. Berlin, Boston, MA: De Gruyter

Saur. 2013, 901 p.

[thumbtack, 2013] Nelubin, D., Engber, B.: Ultra-High Performance NoSQL Benchmarking - Analyzing Durability

and Performance Tradeoffs. http://www.thumbtack.net/whitepapers/ultra-high-performance-nosql-

benchmark.html

[White, 2012] White, T.: Hadoop: The Definitive Guide, 3rd ed., O'Reilly Media / Yahoo Press, 2012, 688p.

[White, 2015] White, T.: Hadoop: The Definitive Guide, 4th ed., O'Reilly Media / Yahoo Press, 2015, 756p.

[Zezula et al, 2006] Zezula, P., Amato, G., Dohnal, V., Batko, M. Similarity Search: the Metric Space Approach.

Springer, 2006, ISBN: 978-0387-29146-8.

[Бърнев & Керпеджиев, 1988] Бърнев, П., Ст. Керпеджиев. Основни понятия в информатиката. Изд. Петър

Берон, 1988.

[Ернандес, 2004] Ернандес, М. Проектиране на бази от данни, Софтпрес, 2004, ISBN 954-685-301-1

[Иванова, 2010] Иванова, Т.: Електронно обучение по среди за програмиране. Приложни среди за

програмиране в електронното обучение. Списание на Софийския Университет за електронно

обучение, № 3, 2010, с. 1-21.

128

[Калоянова, 2013] Калоянова, К.: Анализ и проектиране на информационни системи. Хабилитационен

труд във връзка с конкурс за професор – ФМИ при СУ, 2013

[Марков, 2006] Марков, К.: Многомерен контекстно-независим метод на достъп. Дисертация за ОНС

доктор, ИМИ-БАН, 2006

[Михайлов и др., 1966] Михайлов, А. И., Черный, А. И., Гиляревский, Р. С.: Информатика – новое название

теории научной информации. НТИ, № 12, 1966, с. 35-39.

[Муравьев и др., 2015] Муравьев, С., С. Дворянкин, И. Насенков: СУБД: проблема выбора. Открытые

системы СУБД. 1/2015, http :// www . osp . ru / os /2015/01/13045322/

[Николов, 2010] NoSQL бази от данни – възможности и приложение. Магистърска теза под ръков. на К.

Калоянова, СУ-ФМИ, 2010.

[Петухов, 2012] Петухов, Д.: Платформа Hadoop. Обзор. http://www.codeinstinct.pro/2012/08/hadoop-

overview.html

[Симеонов, 2009] Симеонов Н. К.: Докъде може да стигнем с номализацията?, ТУ-София, ФКСУ, 2009,

http://www.cphpvb.net/db/1876-%D0%BD%D0%BE%D1%80%D0%BC%D0%B0%D0%BB

%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F-%D0%BD%D0%B0-

%D0%B1%D0%B0%D0%B7%D0%B8-%D0%B4%D0%B0%D0%BD%D0%BD%D0%B8/

[Трайков, 2008] Трайков Б.: Бази от данни. Свищов, Акад. изд. Д. Ценов, 2008. 423 с. ISBN: 978-954-23-

0385-5

129

Приложение 1: Списък на бази от данни16

Име на БД Модел на БД Седалище country Website

1010data Relational DBMS New York USA www.1010data.com

4store RDF store Nottingham UK 4store.org

Accumulo Wide column store Los Angeles USA accumulo.apache.org

Adabas Multivalue DBMS Darmstadt Germanyhttp://www.softwareag.com/corporate/products/

adabas_natural/adabas/overview/default.asp

Aerospike Key-value store California USA www.aerospike.com

Akiban Relational DBMS Boston, MA USA www.akiban.com

Algebraix RDF store Austin, Texs USA www.algebraixdata.com

AllegroGraph RDF store Oakland, California USA http://franz.com/agraph/allegrograph/

Altibase Relational DBMS Fort Lee,New Jersey USA altibase.com

Amazon AuroraRelational DBMS

Search engineUSA http://aws.amazon.com/rds/aurora/

Amazon

DynamoDB

Document store

Key-value storeUSA http://aws.amazon.com/dynamodb/

Amazon Redshift Relational DBMS USA http://aws.amazon.com/redshift/

Amazon

SimpleDBKey-value store USA http://aws.amazon.com/documentation/simpledb/

Amisa Server

Document store

Graph DBMS

Relational DBMS

Halifax, Toronto Canada http://www.amisalabs.com/

Apache Drill Relational DBMS Los Angeles USA drill.apache.org

ArangoDB

Document store

Graph DBMS

Key-value store

Germany Germany https://www.arangodb.com/

Axibase Time Series DBMS California, USAhttps://axibase.com/products/axibase-time-series-

database/

Bangdb Key-value store Bangalore India http://www.iqlect.com/bangdb_embedded.php

BaseX Native XML DBMS Konstanz Germany docs.basex.org

BergDB Key-value store Sweden http://bergdb.com/

Berkeley DB Key-value store Redwood City, CA USAhttp://www.oracle.com/us/products/database/berkeley-

db/overview/index.html

Blazegraph Graph DBMS Washington, DC USA blazegraph.com

Blueflood Time Series DBMS USA blueflood.io

BrightstarDB RDF store Oxford UK www.brightstardb.com

c-treeACE Relational DBMS USA http://www.faircom.com/ace/ace_t.php

16 db-engines.com

130

Caché Object oriented DBMSCambridge, MA

02142, USA

http://www.intersystems.com/our-products/cache/cache-

overview/

Cassandra Wide column store Los Angeles USA cassandra.apache.org

CitusDB Relational DBMS San Francisco USA https://www.citusdata.com/

Cityzen Data Time Series DBMS France www.cityzendata.com

Cloudant Document store New York USA https://cloudant.com/

CloudKit Document store USA http://getcloudkit.com/ (Apple)

Clusterpoint Document store Palo Alto, California USA https://www.clusterpoint.com/

Clustrix Relational DBMS San Francisco USA http://www.clustrix.com/

CodernityDB Key-value store Wroclaw Poland http://labs.codernity.com/codernitydb/

Compass Search engine USA http://www.compass-project.org/ (top prj – Lucene)

CortexDBDocument store

Key-value storeIsernhagen Germany http://www.cortex-ag.com/cortexdoku/cms.php

Couchbase Document store California USA http://www.couchbase.com/

CouchDB Document store Los Angeles USA http://couchdb.apache.org/

Crate.IORelational DBMS

Search engineSan Francisco USA https://crate.io/

CubicWeb RDF store Paris, Toulouse,… France https://www.cubicweb.org/

Cubrid Relational DBMS Korea http://www.cubrid.org/

D3 Multivalue DBMS Waltham, MA USAhttp://www.rocketsoftware.com/product-families/rocket-

d3

DaggerDB Relational DBMS Berlin Germany www.daggerdb.com

Datacom/DB Relational DBMS USA http://www.ca.com/us/opscenter/ca-datacom.aspx

DataEase Relational DBMS UK www.dataease.com

Datameer Document store San Francisco, CA USA http://www.datameer.com/

Dataupia Relational DBMS Cambridge, MA USA http://www.dataupia.com/

Datomic Relational DBMS Durham, NC USA http://www.datomic.com/

DB2 Relational DBMS USA http://www-01.ibm.com/software/data/db2/

Db4o Object oriented DBMS CA USA http://supportservices.actian.com/versant/default.html

dBASE Relational DBMS New York USA http://www.dbase.com/

DBISAM Relational DBMSNorth Tonawanda,

NYUSA http://www.elevatesoft.com/products?category=dbisam

DBSight Search engine USA http://www.dbsight.net/

DensoDB Document store Boston, MA USA http://densodb.codeplex.com/

Derby Relational DBMS Los Angeles USA http://db.apache.org/derby/

Djondb Document store Atlanta, GA USA djondb.com

Drizzle Relational DBMS USA www.drizzle.org

Druid Time Series DBMSSan Francisco, New

YorkUSA http://druid.io/

Dydra RDF store Berlin Germany http://dydra.com/

Ehcache Key-value store San Francisco, CA USA http://ehcache.org/

EJDB Document store Novosibirsk Russia http://ejdb.org/

Elasticsearch Search engine California USA https://www.elastic.co/products/elasticsearch

ElevateDB Relational DBMS New York USA http://www.elevatesoft.com/products?category=edb

131

Elliptics Key-value store Moscow Russia reverbrain.com/elliptics

Eloquera Object oriented DBMS Chicago USA www.eloquera.com

Empress Relational DBMS Maryland USA www.empress.com

Endeca Search engine Redwood City, CA USAwww.oracle.com/us/products/applications/commerce/

endeca/overview/index.html

EnterpriseDB Relational DBMS Bedford, MA USA http://www.enterprisedb.com/

Event Store Event Store Midsomer Norton UK geteventstore.com

EXASolution Relational DBMS Nürnberg Germany http://www.exasol.com/en/in-memory-database/overview/

eXist-db Native XML DBMSGinsheim-

GustavsburgGermany www.exist-db.org

Exorbyte Search engine Konstanz Germany www.exorbyte.com

eXtremeDB Relational DBMS Federal Way, WA USA http://www.mcobject.com/extremedbfamily.shtml

FileMaker Relational DBMS Santa Clara, CA USA www.filemaker.com

Firebird Relational DBMS New South Wales Australia www.firebirdsql.org

FleetDB Document store не е активна USA github.com/mmcgrana/fleetdb

FlockDB Graph DBMS San Francisco, CA USA https://github.com/twitter/flockdb

FoundationDB

Document store

Key-value store

Relational DBMS

Vienna, VA USA foundationdb.com

FrontBase Relational DBMS Foothill Ranch, CA USA www.frontbase.com

GemFire Document store Palo Alto, CA USAwww.vmware.com/products/application-platform/vfabric-

gemfire/overview.html

GemStone/S Object oriented DBMS Beaverton, OR USA gemtalksystems.com

GenieDB Relational DBMS не е активна USA www.geniedb.com

Giraph Graph DBMS New York USA giraph.apache.org

GlobalsDB

Document store

Graph DBMS

Key-value store

Cambridge, MA USA globalsdb.org

Google BigQuery Relational DBMS Mountain View, CA USA developers.google.com/bigquery

Google Cloud

DatastoreDocument store Mountain View, CA USA developers.google.com/datastore

Google Search

ApplianceSearch engine Mountain View, CA USA www.google.com/work/search/products/gsa.html

GraphBase Graph DBMS Australia http://graphbase.net/

GraphDBGraph DBMS

RDF storeSofia Bulgaria www.ontotext.com/products/ontotext-graphdb

Graphite Time Series DBMS Switzerland github.com/graphite-project/graphite-web

Greenplum Relational DBMS Palo Alto, CA USA www.gopivotal.com/big-data/pivotal-greenplum-database

GridGain Key-value store Foster City, CA USA www.gridgain.com

GT.M Key-value store Jacksonville, FL USA www.fisglobal.com/products-technologyplatforms-gtm

H2 Relational DBMS Germany www.h2database.com

Hadapt Relational DBMS Cambridge, MA USA hadapt.com

Hamsterdb Key-value store Germany hamsterdb.com

Hazelcast Key-value store Palo Alto, CA USA www.hazelcast.com

HBase Wide column store USA hbase.apache.org

132

Hibari Key-value store USA https://github.com/hibari/hibari

Hive Relational DBMS USA hive.apache.org

HyperDex Key-value store Ithaca, NY USA hyperdex.org

HyperGraphDB Graph DBMS New York USAwww.hypergraphdb.org (Kobrix

borislav.iordanov@gmail.com)

HyperLevelDB Key-value store USA http://hyperdex.org/performance/leveldb/

HyperSQL Relational DBMS hsqldb.org

Hypertable Wide column store Burlingame, CA USA hypertable.org

IDMS Navigational DBMS USA www.ca.com/us/opscenter/ca-idms.aspx

Impala Relational DBMS USAwww.cloudera.com/content/cloudera/en/products-and-

services/cdh/impala.html

IMS Navigational DBMS USA www.ibm.com/software/data/ims/ims

Indica Search engine Netherlands indica.nl

InfiniDB Relational DBMS Plano, TX USA https://github.com/infinidb/infinidb

Infinispan Key-value store USA www.jboss.org/infinispan

InfiniteGraph Graph DBMS San Jose, CA USA objectivity.com

InfluxDB Time Series DBMS San Francisco, CA USA influxdb.com

Infobright Relational DBMS Toronto, Ontario Canada www.infobright.com

InfoGrid Graph DBMS USA infogrid.org

Informix Relational DBMS USA www.ibm.com/software/data/informix

Ingres Relational DBMS Redwood City, CA USA www.actian.com/products/operational-databases/ingres

Interbase Relational DBMS San Francisco, CA USA www.embarcadero.com/products/interbase

ITTIA Relational DBMSBellevue,

WashingtonUSA www.ittia.com

Jackrabbit Content store USA jackrabbit.apache.org

Jade Object oriented DBMS Christchurch New Zealand www.jade.co.nz/jade

JasDB Document store Amsterdam Netherland www.oberasoftware.com/jasdb

jBASE Multivalue DBMS Irvine, CA USA www.jbase.com

Jena RDF store USA jena.apache.org

JethroData Relational DBMS USA www.jethrodata.com

JustOneDB Relational DBMS San Francisco, CA USA www.justonedb.com

KairosDB Time Series DBMS USA github.com/kairosdb/kairosdb

Kdb+Relational DBMS

Time Series DBMSPalo Alto, CA USA kx.com/products.php

Kognitio Relational DBMS Bracknell UK www.kognitio.com

Kyoto Cabinet /

TycoonKey-value store Japan

fallabs.com/kyototycoon

fallabs.com/kyotocabinet

LedisDB Key-value store China ledisdb.com

LevelDB Key-value store San Jose, CA USA github.com/google/leveldb

Linter Relational DBMS Voronezh Russia www.lintersql.com

LokiJS Document store Cork Ireland lokijs.org

MapDB Key-value store Prague Czech Republic www.mapdb.org

MariaDB Relational DBMS Delaware USA mariadb.org

133

MarkLogic

Document store

Native XML DBMS

RDF store

Search engine

California USA www.marklogic.com

MaxDB Relational DBMS Germany maxdb.sap.com

Memcached Key-value store USA www.memcached.org

MemSQL Relational DBMS San Francisco, CA USA www.memsql.com

Microsoft Access Relational DBMS Redmond,WA USA office.microsoft.com/en-us/access

Microsoft Azure

DocumentDBDocument store Redmond,WA USA azure.microsoft.com/en-us/services/documentdb

Microsoft Azure

SearchSearch engine Redmond,WA USA azure.microsoft.com/en-us/services/search

Microsoft Azure

SQL DatabaseRelational DBMS Redmond,WA USA azure.microsoft.com/en-us/services/sql-database

Microsoft SQL

ServerRelational DBMS Redmond,WA USA www.microsoft.com/sqlserver

Mimer SQL Relational DBMS Uppsala Sweden http://mimer.com/

Mnesia Document store Sweden www.erlang.org/doc/man/mnesia.html

Model 204 Multivalue DBMS Waltham, MA USA www.rocketsoftware.com/m204

ModeShape Content store USA www.jboss.org/modeshape (RedHat)

MonetDB Relational DBMS Netherlands www.monetdb.org

MongoDB Document store New York USA www.mongodb.org

mSQL Relational DBMS Australia www.hughes.com.au/products/msql

Mulgara RDF store USA www.mulgara.org

MySQL Relational DBMS USA www.mysql.com

Nanolat Key-value store Japan nanolat.com/index/0-2

NCache Key-value store San Ramon, CA USA www.alachisoft.com/ncache

Neo4j Graph DBMS San Mateo, CA USA neo4j.com

Netezza Relational DBMS New York USA www.netezza.com

NEventStore Event Store Italy neventstore.org

Newts Time Series DBMS Canada github.com/OpenNMS/newts

NexusDB Relational DBMS Brisbane Australia www.nexusdb.com

NonStop SQL Relational DBMS Palo Alto, CA USAh17007.www1.hp.com/us/en/enterprise/servers/

integrity/nonstop/nonstop-sql.aspx

Northgate Reality Multivalue DBMS California USA www.northgate-reality.com

NuoDB Relational DBMS Cambridge, MA USA www.nuodb.com

ObjectDB Object oriented DBMS Nottingham UK www.objectdb.com

Objectivity/DB Object oriented DBMS San Jose, CA USA www.objectivity.com/products/objectivitydb

ObjectStore Object oriented DBMS Austin, Texas USA www.objectstore.com

OpenBase Relational DBMS St. Petersburg, FL USA www.openbase.com

OpenEdge Relational DBMS USA www.progress.com/products/openedge

OpenInsight Multivalue DBMS Westwood, NJ USA www.revelation.com/index.php/products/openinsight

OpenQM Multivalue DBMS Irvine, CA USA www.openqm.com

OpenTSDB Time Series DBMS USA opentsdb.net

134

Oracle Relational DBMS Redwood Shores, CA USA www.oracle.com/us/products/database

Oracle Coherence Key-value store Redwood Shores, CA USAwww.oracle.com/technetwork/middleware/coherence/

overview/index.html

Oracle NoSQL Key-value store Redwood Shores, CA USA www.oracle.com/technetwork/products/nosqldb

Oracle Rdb Relational DBMS Redwood Shores, CA USAwww.oracle.com/technetwork/database/database-

technologies/rdb/overview/index.html

OrientDB

Document store

Graph DBMS

Key-value store

London UK orientdb.com

OrigoDBDocument store

Object oriented DBMSSweden origodb.com

ParAccel Relational DBMS Redwood City, CA USA www.paraccel.com

Percona Server Relational DBMS Durham, NC USA www.percona.com/software/percona-server

Perst Object oriented DBMS Federal Way, WA USA www.mcobject.com/perst

Pervasive PSQL Relational DBMS Germany www.pervasivedb.com

Postgres-XL Relational DBMS CA USA www.postgres-xl.org

PostgreSQL Relational DBMS CA USA www.postgresql.org

PouchDB Document store USA pouchdb.com

Project

VoldemortKey-value store Mountain View, CA USA www.project-voldemort.com (LinkedIn)

Prometheus Time Series DBMS Berlin Germany prometheus.io

Quasardb Key-value store Paris France www.quasardb.net

R:BASE Relational DBMSMurrysville,

PennsylvaniaUSA www.rbase.com

Rainstor Relational DBMS San Francisco, CA USA rainstor.com/products/rainstor-database

RaptorDB Document store UK raptordb.codeplex.com

Rasdaman Multivalue DBMS Germany www.rasdaman.org

RavenDB Document store Israel ravendb.net

Red Brick Relational DBMS USA www-03.ibm.com/software/products/us/en/redbrick

Red Database Relational DBMS Moscow Russia http://www.red-soft.biz/

Redis Key-value store Mountain View, CA USA redis.io

Redland RDF store Bristol UK librdf.org

RedStore RDF store London UK www.aelius.com/njh/redstore

Resin Cache Key-value store San Diego, CA USA www.caucho.com

RethinkDB Document store Mountain View, CA USA www.rethinkdb.com

Riak Key-value store Bellevue, WA USA basho.com/products/riak-overview

RocksDB Key-value store USA rocksdb.org (project in facebook)

RRDtool Time Series DBMS Olten Swtzerland oss.oetiker.ch/rrdtool

SAP Adaptive

ServerRelational DBMS USA

www.sap.com/pc/tech/database/software/adaptive-server-

enterprise/index.html

SAP Advantage

Database ServerRelational DBMS USA

www.sap.com/pc/tech/database/software/advantage-

database-server

SAP HANA Relational DBMS USA www.saphana.com

SAP IQ Relational DBMS USAwww.sap.com/pc/tech/database/software/sybase-iq-big-

data-management

135

SAP SQL

AnywhereRelational DBMS USA

www.sap.com/pc/tech/database/software/sybase-sql-

anywhere

Scalaris Key-value store Berlin Germany http://scalaris.zib.de/

ScaleBase Relational DBMS Boston, MA USA www.scalebase.com

ScaleDB Relational DBMS Menlo Park, CA USA www.scaledb.com

ScaleOut

StateServerKey-value store Bellevue, WA USA www.scaleoutsoftware.com/products/scaleout-stateserver

SciDB Multivalue DBMS Waltham, MA USA scidb.org

ScimoreDB Relational DBMS Lithuania www.scimore.com

SearchBlox Search engine Glen Allen VA USA www.searchblox.com

Sedna Native XML DBMS Russia www.sedna.org - Institute for System Programming

SenseiDB Document store Japan senseidb.com

Sequoiadb Document store District,Shenzhen, China www.sequoiadb.com

Sesame RDF store Ottawa Canada rdf4j.org (in Eclipse – 05.2015)

Siaqodb Object oriented DBMS Romania siaqodb.com

SisoDb Document store Stockholm Sweden www.sisodb.com

SiteWhere Time Series DBMS Atlanta, GA USA www.sitewhere.org

SmallSQL Relational DBMS Germany www.smallsql.de

solidDB Relational DBMS Mission Hills, CA USA www.soliddb.com

Solr Search engine USA lucene.apache.org/solr

SparkleDB RDF store California USA www.sparkledb.net

Sparksee Graph DBMS Barcelona Spain sparsity-technologies.com/#sparksee

Sphinx Search engine USA sphinxsearch.com

Splice Machine Relational DBMS San Francisco, CA USA www.splicemachine.com

Splunk Search engine San Francisco, CA USA www.splunk.com

SQLBase Relational DBMS Roseville, CA USAwww.guptatechnologies.com/Products/

Data_Management/SQLBase

SQLite Relational DBMS USA sqlite.org

Sqrrl

Document store

Graph DBMS

Key-value store

Wide column store

Cambridge, MA USA sqrrl.com

Srch² Search engine Irvine, CA USA srch2.com

Starcounter Object oriented DBMS Stockholm Sweden www.starcounter.com

Stardog RDF store Washington, DC USA stardog.com

Strabon RDF store Greece www.strabon.di.uoa.gr

STSdb Key-value store Gabrovo Bulgaria http://stssoft.com/

Tajo Relational DBMS USA tajo.apache.org

Tamino Native XML DBMS Darmstadt Germany

Tarantool Key-value store Russia tarantool.org (part of mail.ru)

TempoIQ Time Series DBMS Chicago, IL USA www.tempoiq.com

Teradata Relational DBMS Dayton, OH USA www.teradata.com

Teradata Aster Relational DBMS Dayton, OH USA www.asterdata.com

Terrastore Document store Germany code.google.com/p/terrastore

136

TimeSeries.Guru Time Series DBMS Germany www.timeseries.guru

TimesTen Relational DBMS Redwood Shores, CA USAwww.oracle.com/us/products/database/timesten/

index.html

Titan Graph DBMS USA thinkaurelius.github.com/titan

TokuDB Relational DBMS Durham, NC USA www.tokutek.com/products/tokudb-for-mysql

TokuMX Document store Durham, NC USA www.tokutek.com/products/tokumx-for-mongodb

Tokyo Cabinet /

TyrantKey-value store Japan

fallabs.com/tokyocabinet

fallabs.com/tokyotyrant

TomP2P Key-value store Zurich Switzerland tomp2p.net

Transbase Relational DBMS München Germany www.transaction.de/products/transbase.html?L=1

TransLattice Relational DBMSSanta Clara,

CaliforniaUSA

UniData,UniVerse Multivalue DBMS Waltham, MA USA u2.rocketsoftware.com

Valentina Server Relational DBMS Beaverton, OR USA www.valentina-db.net

Vectorwise Relational DBMS Redwood City, CA USA www.actian.com/products/vectorwise

VelocityDBObject oriented DBMS Carlsbad, CA USA www.velocitydb.com

VelocityGraph Graph DBMS Carlsbad, CA USA www.velocitygraph.com

Versant

FastObjectsObject oriented DBMS Redwood City, CA USA www.actian.com/products/operational-databases/versant

Versant Object

DatabaseObject oriented DBMS Redwood City, CA USA www.actian.com/products/operational-databases/versant

Vertica Relational DBMS Palo Alto, CA USA www.vertica.com (HP)

Virtuoso

Native XML DBMS

Relational DBMS

RDF store

Burlington, MA USA virtuoso.openlinksw.com

VistaDB Relational DBMS Owings Mills, MD USA www.vistadb.net

VoltDB Relational DBMS Bedford, MA USA voltdb.com

WakandaDB Object oriented DBMS France www.wakanda.org

WebScaleSQL Relational DBMS webscalesql.org

WebSphere

eXtreme ScaleKey-value store USA

www.ibm.com/software/products/en/websphere-extreme-

scale

WhiteDB Document store Estonia whitedb.org

WiredTiger Key-value store Lincoln, MA USA wiredtiger.com

XAP Key-value store New York USAwww.gigaspaces.com/xap-in-memory-computing-event-

processing/Meet-XAP

Xapian Search engine Hertford UK xapian.org

XtremeData Relational DBMS Schaumburg, IL USA www.xtremedata.com

ZODB Key-value store Fredericksburg, VA USA www.zodb.org

ArM32 MDIM Sandanski Bulgaria www.foi9.eu

137