СУБД (Система за управление на бази данни)
СУБД (Система за управление на бази данни) е важен тип програмна система, използвана днес и в най-големите, и в най-малките компютри. Има две главни характеристики, които различават СУБД от другите типове програмни системи.
- Възможност за управление на постоянни данни;
- Възможност за ефективен достъп до голямо количество данни.
Първата характеристика е свързана с факта, че базата данни съществува постоянно и съдържанието й са данните, до които СУБД има достъп и управлява. Втората характеристика разграничава СУБД от файлова система, която също управлява постоянни данни, но обикновено не осигурява бърз достъп до произволни части от данните. Възможностите на СУБД са необходими, когато количеството на данните е много голямо, тъй като за малко количество данни са приложими прости методи за достъп, като линейно сканиране на данните. Наред с тези основни характеристики на СУБД съществуват и редица други, като:
- Осигуряване на поне един модел от данни, или на математическа абстракция посредством, която потребителят може да види данните;
- Осигуряване на език от високо ниво, който разрешава на потребителя да дефинира структури от данни, да има достъп до данните и да ги обработва;
- Управление на транзакциите, възможност за осигуряване на коректен, паралелен достъп до базата данни на много потребители едновременно;
- Управление на достъпа, възможност за ограничаване на достъпа до данни от неоторизирани потребители и възможност за проверка на валидността на данните;
- Гъвкавост, възможност за възстановяване след неизправности в системата без загуба на данни.
Модели данни
Всяка СУБД осигурява поне един абстрактен модел на данните, който дава възможност на потребителя да види информацията, не като редове от битове, а в по-разбираем вид. Обикновено е възможно да се видят данните в няколко нива на абстракция. На относително ниско ниво, СУБД дава възможност данните да се видят, като съставени от файлове.
Пример 4.1. Всяка съобщителна администрация обикновено пази файл с информация за своите абонати, като записът за всеки абонат може да има пет полета: първото име, последното име, абонатен номер, домашен адрес, тип терминал и евентуално друга информация. Да допуснем, че в записа се пази информация за името и адреса на абоната. Записът има структурата:
record
name : char[30];
address : char[30];
end
Самият файл е последователност от записи за всеки абонат на мрежата. В един от моделите на данни, които ще се разгледаме, файлът от записи е абстракция на това, което се нарича релация и може да бъде описано чрез
SUBSCRIBERS(NAME,ADDR)
Тук SUBSCRIBERS е името на релацията, съответстваща на файла от пример 4.1, NAME и ADDR са имена на полета; полетата често се наричат атрибути, когато се говори за релации.
Релацията е абстракция на файл, където типовете на полетата с данни почти не са от значение, и където редът на записите не е определен. Записите в релацията се наричат тюпли (tuple) [1] или кортежи [2]. По този начин файлът се разглежда, като списък от записи, а релацията, като множество от тюпли.
Ефективен достъп до файл
Възможността за съхранение на информация не е толкова важно свойство на СУБД, всяка файлова система, свързана с операционна система прави това. От значение е достъпът до данните във файла. Например, да предположим, че трябва да се намери адреса на абонат с име Иван Петров. Ako съобщителната администрация има хиляди абонати, търсенето в целия файл е твърде скъпо. СУБД дава възможност за използване на индекс на файлове, които ще дадат достъп до записа в един ред, независимо колко голям е файла. Аналогично, въвеждането на нови записи или изтриването на стари може да се направи за постоянно много кратко време, независимо от дължината на файла.
Друго свойство на СУБД дава възможност придвижване из файловете. Стойности от два или повече файла се комбинират, за да се получи информацията, която се търси. Следващият пример илюстрира навигацията.
Пример 4.2. Да предположим, че в записа за даден абонат е съхранена информация за абонатния номер, а не за домашния адрес. В друг файл, наречен NUMBERS има записи, които свързват абонатните номера и домашните адреси. В този случай съществува релацията:
SUBSCRIBERS(NAME,ADDR)
NUMBERS(ADDR, NUM)
Сега, ако трябва да намерим номерa на абоната с име Иван Петров е необходимо да се придвижим от SUBSCRIBERS към NUMBERS, като се използва ADDR полето в двата файла. По този начин първо намираме запис в SUBSCRIBERS, за който NAME="Иван Петров", и от този запис вземаме стойността ADDR, например "Сливница, N73". Тогава търсим във файла NUMBERS запис с поле ADDR= "Сливница, N73", и намираме, че NUM="345678". Ако поставим правилни индекси, ще получим достъп до данните за много кратко постоянно време, което не зависи от дължината на файловете.
Езици за операции с данни
За да направи достъпа до файловете по-лесен, СУБД осигурява език за запитване, или език за операции с данни, за изразяване на операциите във файла. Езиците за операции с данни се различават по нивото за детайлизация, което изискват от потребителя, като обикновено, езиците базирани на релационни модели данни обикновено изискват по-малко детайли от езиците, базирани на други модели.
Пример 4.3. Запитването, разгледано в пример 4.2 може да бъде написано на езика SQL, който е базиран на релационен модел на данните, както е показано по-долу:
(1) SELECT NUM
(2) FROM SUBSCRIBERS, NUMBERS
(3) WHERE SUBSCRIBERS.NAME="Иван Петров"
(4) AND SUBSCRIBERS.ADDR=NUMBERS.ADDR
Ред (1) казва на СУБД да отпечата абонатния номер, като отговор, ред (2) казва да се търси в релациите SUBSCRIBERS и NUMBERS ред (3) казва, че името на абоната е "Иван Петров", последният ред казва, че номерът е свързан със същия адрес, с който е свързан и абоната.
По-долу е написано същото запитване в проста версия на езика за операции с данни DML на мрежов модел.
(1) SUBSCRIBERS.NAME:="Иван Петров"
(2) FIND SUBSCRIBERS RECORD BY CALC=KEY
(3) FIND OWNER OF CURRENT NAME-ADDR SET
(4) FIND NUMBERS RECORD IN CURRENT ADDR-NUM SET
(5) print NUMBERS.NUM
Редове (1) и (2) казват на СУБД да намери записа за Иван Петров във файла SUBSCRIBERS. Ред (3) използва SET структурата, която свързва името на абоната с неговия адрес. Ред (4) използва допускането, че има друга SET структура, ADDR=NUM, свързваща адресите на абонатите с техните номера. На ред (5) ние намираме и отпечатваме номера на този абонат. Забележете, че операторът print не е част от езика за операции с данни, а част от съпътстващия го програмен език.
Лесно може да се забележи, че навигацията между файловете е направена далеч по-трудно в DML отколкото в SQL, т.е. на програмиста на DML са необходими повече усилия. Разликата не е в повечето редове, а главно в това, как вторият пример дава възможност за придвижване от един запис в следващия, докато първият казва как отговора е свързан с данните. Тази декларативност на SQL и на други езици, базирани на релационен модел е причината системите базирани на този модел да стават все по-популярни.
Управление на транзакциите
Друга важна характеристика на СУБД е възможността за управление едновременно на голям брой транзакции, които са процедури за операции в базата данни. Някои бази данни са толкова големи, че те могат да бъдат полезни само, ако се използват едновременно от много компютри. Често тези компютри са разпределени по целия свят. Типичен пример са СУБД, използвани в телекомуникациите.
Понякога два достъпа до данните не си пречат един на друг. Например, няколко заявки за четене на номера на даден абонат няма да си пречат. Но, ако в същото време се прави изменение на тези данни, резултатът от двете транзакции, ако те не са координирани е непредсказуем. Така, транзакцията, която изменя елемента на данните трябва да ги "заключи" за други транзакции, които се опитват да ги четат или записват в същото време. СУБД трябва да осигурява някаква форма на контрол на паралелността, за да предпази от некоординиран достъп един и същ елемент да данните от повече от една транзакции.
Проблемите могат да се усложнят, ако базата данни е разпределена върху много компютърни системи, каквито са съвременните телекомуника-ционни системи. Тези проблеми са свързани с дублирането на данните, така че да се осигури най-бърз локален достъп и да се защитят данните от разрушаване в случай, че някой от компютрите се повреди.
Секретност на данните
СУБД трябва не само да осигури съхранение на данните при неизправност, но тя трябва да ги предпази от неоторизиран достъп. Например, някои от потребителите могат да имат ограничен достъп до информацията в мрежата - операторите могат да изменят елементи от нея, докато на обикновения потребител това не е разрешено. СУБД трябва да бъде в състояние да свърже различните потребители с техните привилегии, т.е. възможност за достъп до файлове, полета във файловете или други подмножества от данни в базата данни. СУБД трябва да поддържа таблица, съдържаща информация за всеки потребител с привилегиите му на достъп до всеки един елемент на данните. Например, на един потребител може да му бъде разрешено да чете файл, но да не вмъква или изтрива данни, на друг може да не бъде разрешен достъп до файла въобще, докато трети може да чете и изменя целия файл.
За да осигури адекватно богато множество от конструкции, така че потребителят да може да вижда части от файловете без да може да вижда всичко, СУБД често предлага възможност виждане (view). Виждането позволява създаването на имагинерни обекти, дефинирани по прецизен начин от реалните обекти, например, файлове или релации.
Пример 4.4. Нека е даден файла SUBSCRIBERS със следните полета:
SUBSCRIBERS(NAME,ADDR,NUM, ACCOUNT)
и се поставя изискването повечето хора да имат достъп до всички други полета с изключение на ACCOUNT (номер на текуща сметка). В езика SQL може да се дефинираме виждането SAFE-SUBS чрез:
CREATE VIEW SAFE-SUBS BY
SELECT NAME, ADDR, NUM
FROM SUBSCRIBERS;
Виждането SAFE-SUBS се състои от полетата с името, адреса и номера на абоната, но не и от полето номер на текуща сметка. SAFE-SUBS може да се разглежда, като релация описана чрез
SAFE-SUBS(NAME,ADDR,NUM)
Виждането SAFE-SUBS не съществува физически, като файл, но към него може да се направи запитване, все едно че съществува. Например, ние можем да попитаме за номера на Иван Петров. Изразено на SQL запитването ще изглежда по следния начин:
SELECT NUM
FROM SAFE-SUBS
WHERE NAME="Иван Петров"
Нормалният потребител има достъп до виждането SAFE-SUBS, но не и до SUBSCRIBERS. На потребителите с правото да знаят номерата на текущите сметки на абонатите е даден достъп до SUBSCRIBERS релацията, т.е те могат да изменят тези номера.
Коментари: