Лекции по бази данни

Четени през летния семестър на учебната 2003/2004 година.

Лектор тогава беше доц. Владо Димитров.

Използвал съм мои (и на мои колеги) записки от лекции. Основно, обаче, материалът е от книгата Начален курс в СУБД на Джефри Улман.

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

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

Поради това, в наши дни СУБД е доста сложен софтуер.

Примери за СУБД са Oracle, DB2, Microsoft SQL server. Първите две системи, за разлика от третата се използват в сериозни организации.
По-нататък под база от данни ще разбираме наборът от данни, които се поддържат в даден момент от една СУБД.
От потребителска гледна точка една СУБД трябва да притежава следните свойства:

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

От архитектурна гледна точка една СУБД трябва да предоставя следните функции:

• 
  СУБД позволява на потребителя да създава нови бази от данни;
  

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

Естествената еволюция на файловите системи доведе до поява на следните два модела:

• 
  йерархичен модел – например IMS на IBM; при него данните са във вид на дърво; в действителност някои данни може да присъстват в повече от едно дърво, ако към тях се използват връзки (reference);
  
• 
  мрежови модел – този модел се появи по-късно; при него навигацията в данните е на значително по-високо ниво.
  

При релационните СУБД за първи път се появява език за заявки от високо ниво.

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

Този модел е изключително прост от гледна точка на потребителя – използва се само една структура от данни, наречена таблица (релация). Реализацията на таблицата е скрита за потребителя. Използват се езици за заявки от високо ниво. Примерна таблица:

В таблицата всяка колона си има име, което се нарича атрибут (accountNo, balance, type). Всеки ред в таблицата се нарича кортеж (имаме два кортежа). В рамките на една колона стойностите са еднотипни.

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

Условието може да има следния вид име_на_атрибут=стойност.

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

Ще опишем как се изпълнява конструкцията. В таблицата, зададена във FROM клаузата се извършва търсене по всички кортежи, като се проверява условието, зададено в WHERE клаузата. SELECT клаузата определя кои атрибути на намерените кортежи да бъдат изведени. Примери: (предполагаме, че горната таблица се казва Accounts)

Тук ще се изведе 1000.00$.

Тук ще се изведе 56789.

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

Има тенденция СУБД да са вградени в операционните системи и в бъдеще да изместят файловите системи.
СУБД се развиват в посока на съхранение на данните във връзка с мултимедията, която е много голям по обем (например от порядъка на терабайтове). Концепцията на работа на една СУБД е, че данните се обработват в оперативната памет, а се съхраняват върху дискове. Проблемът при големите бази данни е, че дисковете все още не са достъчно големи. Поради тази причина се промени моделът за съхранение на данните. Той беше на две нива – оперативна памет и вторична памет. Сега вече се появи и третична памет – шкафове с носители, които се управляват от роботи (например Juke Box, лентови силози). Недостатъкът е, че времето за достъп до третичната памет е много голямо – приблизително няколко секунди, за разлика от вторичната памет, при която това време е около 10-20 ms.
За да може да се оптимизира управлението на различните памети се използват индексна структура на данните или паралелизъм в няколко варианта. Паралелизмът може да означава паралелно работещи процесори, паралелно работещи дискове. Възможно е използването на така наречените разпределени системи – при изпълнението на една заявка тя се разбива на няколко части, които се обработват от различни разпределени компютърни системи.
Концепции в развитието на СУБД
Client-server е архитектура, при която един процес (клиент, client) изпраща заявка за изпълнение към друг процес (сървър, server). Когато сървърът изпълни заявката, той връща данните на клиента. Естествено, СУБД е сървърът, а клиентите са потребителите или приложните програми. При такава организация се постига полезно натоварване на мрежата.

Проблем при архитектурата client-server е претоварването на сървърите. Поради тази причина се налагат архитектури client-server с множество нива. При тях СУБД отново е сървърът, но негови клиенти са така наречените приложни сървъри. Те имат за клиенти уеб-сървъри, които вече взаимодействат с потребителите. Приложните сървъри имат за задача да реализират бизнес-логиката на СУБД. Чрез такова разслоение отговорността за изпълнение на заявките се поделя между различни компютърни системи.

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

Потребителят дава заявка към системата. Това става в интерактивен режим. Възможно е това взаимодействие да се осъществява чрез приложение. Самите заявки не променят базата от данни, докато при обновяване тя се променя.

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

Обикновено в интерактивен режим заявките не се оптимизират. Когато обаче една заявка се съхранява, т.е. тя ще се изпълнява много пъти, то тя се оптимизира. Освен самият сорс на заявката се съхранява и нейният оптимизиран план (естествено, оптимизацията се извършва само веднъж при първото изпълнение на заявката).

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

Когато един потребител работи интерактивно със системата, всяка негова заявка се счита за една транзакция. Той, обаче, може да изпълнява няколко заявки в рамките на една транзакция с помощта на специални команди. Има и други команди за управление на транзакциите.

в който се регистрират транзакциите. По време на изпълнението на една транзакция, изпълнителната машина записва в журнала всякакви промени, които извършва върху транзакцията. Грубо казано, журналът се състои от записи. Всеки запис има нова част и стара част. Изпълнителната машина извършва промените върху новата част. Ако по време на изпълнение на транзакцията възникне проблем, т.е. тя не успее да завърши, чрез старата част на записа се възстановява старото състояние на базата от данни.

DDL-компилатора. Самите DDL-команди след компилация се изпълняват от изпълнителната машина.

Когато една транзакция се обработва от модула управление на транзакциите, то е известно кои таблици ще се използват за четене/писане в рамките на транзакцията. Тогава този модул се обръща към управлението на едновременния достъп, при което се блокират съответните таблици (релации). В таблицата на блокировката се съдържа информация кои от релациите са блокирани само за четене или за четене и за обновяване. Ако се прави опит за повторно блокиране за четене, няма проблем, т.е. от една релация едновременно могат да четат много транзакции. От друга страна, само една транзакция може да блокира релация за обновяване, т.е. ако една транзакция пише в релация, то други транзакции нямат достъп до тази релация (нито за четене, нито за обновяване). Най-често блокировката се извършва на отделни релации. Възможно е блокировката да се извършва на ниво кортежи, т.е. върху една и съща релация може да работят едновременно няколко транзакции, но върху различни кортежи. Ако блокировката е на по-едро ниво, то се губи ефективност. Ако блокировката е на по-ситно ниво, то се усложнява значително управлението на едновременния достъп.

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

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

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

буфери – метаданни, данни, индекси.
Често при описание на свойствата на транзакциите се използва съкращението ACID – атомарност (atomicity), цялостност (consistency), изолирано изпълнение (isolation), надеждност и устойчивост (durability).
По-отношение на СУБД се изучават следните компоненти:

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

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

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

Моделът ER дава възможност с определени структури да се опишат същности, а с други структури да се опишат връзките между тези същности.

Друг подход за описание на базата от данни е обектно-ориентираният подход. При този подход се използват така наречените UML-диаграми. Те са ориентирани по-скоро към описание на софтуера, отколкото описание на самите данни както е при ER-диаграмите.

Недостатък на релационния модел при проектиране е, че структурата която се използва е само една – таблицата (релацията). Чрез тази структура трябва да се описват както същностите, така и връзките.

Затова при проектиране се предпочита ER-модела пред релационния модел.

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

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

Между две или повече множества от същности може да има връзки. Най-простите връзки са бинарни, но може да има и по-сложни връзки между повече от две множества същности.

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

по-малко атрибути. Естествено, същностите и атрибутите трябва да са така подбрани, че да отразяват адекватно реалния свят.
Диаграмата ER е описание на схемата на базата от данни. С нея не се описва конкретното съдържание на базата от данни. Конкретните данни се наричат екземпляр на базата от данни и те могат да се менят с времето, докато схемата на базата от данни е устойчива и не се променя.

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

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

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

Нека R е връзка между множествата от същности E₁, E₂, …, E_n.

Тогава екземпляр на R е краен списък от наредени n-торки (e₁, e₂, …, e_n), където e_i е конкретна същност от множеството E_i, i = 1, 2, …, n.

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

Нека Sharon Stone и Arnold Schwarzeneger са конкретни същности

от Stars. Нека Basic Instinct и Total Recall са конкретни същности от Movies. Тогава един екземпляр на връзката stars_in може да е следния:

Movies	Stars
Basic Instinct	Sharon Stone
Total Recall	Arnold Schwarzeneger
Total Recall	Sharon Stone

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

Нека R е връзка между множествата същности E и F.

Ако всеки елемент на E може да бъде свързан с най-много един елемент на F, казваме че R е връзка много към един (many-one) от E към F.

В диаграмата ER за такива връзки се обозначава стрелка от R към F.

Пример от по-горе е връзката owns, което означава че един филм може да бъде притежаван най-много от едно студио.

Ако R е връзка много към един от E към F и R е връзка много към един от F към E, казваме че R е връзка един към един (оne-one)

между E и F. В диаграмата ER за такива връзки се обозначава стрелка от R към F и от R към E. Пример от по-горе е връзката runs, което означава, че едно студио може да има най-много един президент и освен това един президент може да ръководи най-много едно студио.

Ако R не е връзка много към един от E към F и R не е връзка много към един от F към E, казваме че R е връзка много към много

(many-many) между E и F. В диаграмата ER за такива връзки не се обозначават стрелки. Пример от по-горе е връзката stars_in, което означава, че една звезда може да участва в повече от един филм и в един филм могат да участват повече от една звезди.

Нека E₀, E₁, …, E_n са множества от същности и R е връзка. Аналогично на по-горе, казваме че R е връзка много към един от E₁, …, E_n към E₀, ако за всеки елемент e₁ от E₁, e₂ от E₂, …, e_n от E_n съществува най-много един елемент e₀ от E₀, така че (e₀, e₁, …, e_n) е наредена (n+1)-орка от R.

В диаграмата ER за такива връзки се обозначава стрелка от R към E₀.

Ще разгледаме един пример.

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