Основи на съвременните бази данни Предговор


Език за релационни бази от данни SQL



страница9/17
Дата17.08.2018
Размер1.71 Mb.
#80209
1   ...   5   6   7   8   9   10   11   12   ...   17

Език за релационни бази от данни SQL

Лекция 13. Езикът SQL. Функции и основни възможности

13.1. SEQUEL/SQL СУБД System R


Езикът за взаимодействие с БД SQL се появява в средата на 70-те години и е бил разработен в рамките на проекта за експериментална релационна СУБД System R. Изходното название на езика SEQUEL (Structered English Query Language) само частично отразява същността на този език. Разбира се, езикът е бил ориентиран основно към удобна и разбираема за потребителите формулировка на заявките към релационната БД, но всъщност вече представлява пълен език за БД, съдържащ освен оператори за формулиране на заявки и за манипулиране на БД, средство за определяне и манипулиране на схема на БД; за определяне на ограниченията за цялостност и тригери; представяния на БД; възможности за определяне на структури на физическо ниво, поддържащи ефективното изпълнение на заявките; авторизация на достъпа до отношенията и техните полета; на точки за съхраняване на транзакция и rollbacks. В езика са отсъствали средства за синхронизация на достъпа до обектите на БД от страна на паралелно изпълняваните транзакции: от самото начало се предполагало, че необходимата синхронизация неявно се изпълнява от СУБД.

Да разгледаме тези свойства на езика по-подробно.


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

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

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

В предикатите с вложени подзаявки в SQL на System R може да се употребяват теретико-множествени оператори за сравнение, което позволява да се формулират квантифицирани заявки (тези възможности обикновено по-трудно се разбират от потребителите и затова по-нататък в SQL се появяват явно квантифицируеми предикати).

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

Още едно различие на SQL е незадължителното премахване на кортежи-дубликати в окончателно или промеждутъчни отношения-резултати. Строго погледнато, резултатът от оператора за извадка в езика SQL представлява не отношение, а мултимножество от кортежи. В тези случаи, когато семантиката на заявката изисква наличие на отношение, унищожаването на дубликатите се извършва неявно.

В най-общ вид заявката на езика SQL представлява теоретико-множествен алгебричен израз, съставен от елементарни заявки. В SQL System R са били допустими всички базови теоретико-множествени операции (UNION, INTERSECT и MINUS).

Работата с неопределени стойности в SQL System R не е била до край обмислена, макар неявно да се е предполагало използването на тризначна логика при изчисляване на логически изрази.

Операторите за манипулиране с данни UPDATE и DELETE са построени на същите принципи, както и операторът за избор на данни SELECT. Наборът кортежи от указано отношение, подлежащи на модификация или изтриване, се определя от входящия в съответния оператор логически израз, който може да включва сложни предикати, в това число и с вложени подзаявки.

В оператора за добавяне на кортеж(и) в посоченото отношение записвания кортеж може да се задава както в литерална форма, така и с помощта на вътрешен подоператор за избор.

13.1.2. Оператори за определяне и манипулиране на схемата на БД

Сред операторите за определяне на схема на БД в SQL System R е имало оператори за създаване и унищожаване на постоянни и временни съхранявани отношения (CREATE TABLE и DROP TABLE) и за създаване и унищожаване на представяни отношения (CREATE VIEW и DROP VIEW). В езика и в реализацията на System R не се е забранявало да се използват оператори за определяне на схема в границите на транзакция, съдържаща оператори за избор и манипулиране с данни. Допускало се, например, използване на оператори за избор и манипулиране с данни, в които се указват отношения, несъществуващи в БД към момента на компилация на оператора. Разбира се, тази възможност съществено усложнявала реализацията и е била необходима по същество много рядко.

Операторът за манипулиране със схема на БД ALTER TABLE позволявал да се добавят посочваните полета към съществуващи отношения. В описанието на езика се определяло, че изпълнението на този оператор не трябва да води до недействителност на по-рано компилирани оператори над отношение, схемата на което се променя, и че стойностите на наново определени полета в съществуващи кортежи на отношението стават неопределени.


13.1.3. Определения за ограничения на цялостта и за тригери

Езикът SQL System R включвал много мощни средства за контрол и поддържане на целостта на БД. Средствата за контрол се базирали на апарата на ограниченията за цялостност (ASSERTIONS). Фактически, ограничението за цялостност е логически израз, изчисляван над текущото състояние на БД, стойността „лъжа” на който съответствува на нецялостно състояние на БД. Логическият израз за ограничение на целостността можел да съдържа всеки предикат, допустим в езика.

По-точно, ограниченията за цялостност се делили на два класа: проверявани след изпълнението на оператора за манипулиране с данни и проверявани при завършване на транзакция или при изпълнение на специалния оператор INFORCE INTEGRITY. Типовете предикати, които може да се използват в операторите за определяне на различните видове ограничения за цялостност, се различават. В операторите от първия клас се проверява, фактически, текущия кортеж, с когото се извършва манипулирането. Във втория случай се проверяват указаните в ограничението за цялостност отношения, т.е. всички техни кортежи. Различава се и определяната в езика реакция на системата на нарушенията на различните класове ограничения за цялостност. В първия случай нарушението на ограничението за цялостност води до откат на транзакция в точката, непосредствено предшестваща операцията за манипулиране на данни, изпълнението на която е предизвикало нарушението на ограничението за цялостност. Във втория случай ограничението води до пълен откат на транзакцията до нейното начало.

Много важен механизъм, определен в езика SQL System R, е механизмът на тригерите. В контекста на System R този механизъм се разглеждал най-вече като средство за автоматично поддържане на целостността на БД. При определянето на тригер се посочвало условието за проверка на неговата приложимост (името на отношението и типа н операцията за манипулиране с данни), условието за приложимост на тригера (логически израз, построен по правила, близки до правилата за ограничения на целостността от първия клас) и действието, което трябва да бъде изпълнено над БД в случай на истинност на условието за приложимост. Такова действие би могло да бъде изразено с помощта на произволен оператор за манипулиране с данни. По време на изпълнението на действието можело да сработять други тригери и т.н.

Механизмите за ограничение на целостността и тригерите в System R са били много мощни и общи, но реализацията им – много трудна и допълнително натоварваща (тригерите така и не били реализирани в System R). Допълнителна сложност в реализацията създавал и фактът, че се допускало (поне не се забранявало от езика) определянето на ограничения за цялостност и тригери в границите на една и съща транзакция, в която се изпълняват операторите за манипулиране с данни. При най-пълна реализация биха били необходими голям брой допълнителни действия по време на изпълнение на транзакцията. Освен това, в редица случаи отсъствието на фиксирана семантика на съответните конструкции на езика водило до нееднозначно разбиране на изпълнението на транзакциите.


13.1.4. Представяния на база от данни

В езика се допускало използването на съхранявани отношения на БД и на представляеми отношения. Най-удачното решение било използването на определението на представянията на общия апарат на операторите за избор. Всеки оператор за избор може да бъде използван за определяне на представяне.

В езика няма никакви ограничения отнасящи се до използването на представянията: в кой да е оператор на SQL, в който се допуска използването на име на съхранявано отношение, допуска се и използването на име на представяне. В SQL System R нищо не се казва за препоръчителния начин за реализация на достъпа до представянията, но при всеки способ ефектът трябва да бъде такъв, както ако се изпълнява пълна материализация на представянето преди изпълнението на оператора.

Редица проблеми, изследвания и предложения поражда потенциалната възможност за изпълнение на операторите за манипулиране с данни над представянията. Ясно е, че тази възможност лесно се реализира за прости представяния, но в по-сложните случаи не само реализацията, но и семантиката на операциите става нетривиална. Като допълнение, в System R операторите за манипулиране с данни се допускали само над прости представяния.

13.1.5. Определяне на управляващи структури

Внасянето в релационния език, какъвто е SQL, на явни оператори за пораждане и унищожаване на структури на физическо ниво, поддържащи ефективното изпълнение на заявките към БД, представлявало в SQL System R чисто прагматично решение, осигуряващо възможността за всички видове работа с БД чрез един език.

В SQL System R се споменават два вида такива структури: индекси и връзки (links). Индексът в абстрактното му езиково представяне – това е инвертиран файл, осигуряващ достъп до кортежите на съответното отношение на основата на зададени стойности от един или няколко стълба, съставляващи ключа на индекса. Операторите на езика позволяват да се създават и унищожават индекси, но по никакъв начин не дават възможност явно да се указва необходимостта от използване на съществуващ индекс при изпълнение на оператор за избор, решението за това се възлага на реализацията.

С помощта на оператора за определяне на индекс можело да се изразят две допълнителни твърдения, касаещи логическата схема на отношение и физическата структура за неговото съхранение. Използването при определянето на индекс на ключовата дума UNIQUE означавало, чe ключът на този индекс е възможен ключ на съответното отношение. Фактически това означава наличие на допълнителен механизъм за определяне на ограничението за цялостност на отношение. Един от индексите за дадено отношение може да се определи с ключовата дума CLUSTERING. Това означава изискване за физическа клъстеризация във външната памет на кортежите на отношение с равни или близки стойности на ключа на индекса.

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


13.1.6. Авторизация на достъпа до отношенията и техните полета

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

След създаването на ново отношение всички привилегии, свързани с това отношение и всички негови стълбове, принадлежат само на потребителя-създател на отношението. Сред привилегиите е и привилегията за предаване на всички или част от привилегиите на друг потребител, включително привилегията да се предават привилегии. Технически предаването на привилегии се осъществява при изпълнение на оператора SQL GRANT. Съществува също и привилегия за изземане на всички или част от привилегиите на потребител, на когото те по-рано са били предадени. Тази привилегия също може да се предава. Технически изземането на привилегии се извършва при изпълнение на оператора SQL REVOKE.

Проверката за пълномощност на достъп до данни се извършва на основата на информацията за пълномощията, съществуващи по време на компилацията на съответния оператор на SQL. Подобно на връзките с ограниченията за цялостност и тригерите, в SQL System R отсъстват някакви ограничения по повод използването на операторите GRANT и REVOKE. Това довело до съществени технически затруднения при реализацията, а понякога и до неоднозначному пониманию поведения.

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


13.1.7. Точки на съхранение и откат на транзакции

В SQL System R съществували два специални оператора за установяване на така наречените точки за съхранение на транзакция и за откат на транзакция към по-рано установена точка на съхранение. В литературата за System R, обсъждането на тези възможности практически не се съдържа, от което неявно следва, че те не са били реализирани.

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

Ще отбележим още две важни свойства на езика SQL System R, които в различни разновидности присъстват във всички развити последващи варианти на езика.

13.1.8. Вграден SQL

В SQL System R има специални оператори, поддържащи вграждането на оператори на SQL в традиционните езици за програмиране (в System R основен такъв език е бил PL/1).

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

За тази цел в езика се въвежда понятието курсор, с който се свързва оператора за избор. Над определен курсор може да се изпълнява оператор OPEN, означаващ материализация на отношението-резултат от заявката, оператор FETCH, позволяващ да се избере поредния кортеж от резултиращото отношение в паметта на програмата, и оператор CLOSE, означаващ край на работата с дадения курсор.

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


13.1.9. Динамичен SQL

За опростяване създаването на интерактивни SQL-ориентирани системи в SQL System R са били включени оператори, позволяващи оо време на изпълнението на транзакция да се компилира и изпълни произволен SQL оператор.

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

Оператор DESCRIBE служи за получаване на информация за указания оператор SQL, предварително подготовен с оператор PREPARE. C помощта на този оператор може да се разбере, първо, дали подготвения оператор е оператор за избор, и второ, ако това е оператор за избор, да се получи пълна информация за броя и типовете столбове на резултиращото отношение.

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

Ще отбележим, че независимо от недостатъчната техническа проработка, в идейно отношение езикът съдържал всички необходими средства, позволяващи да се използва като базов език на СУБД.

13.2. Езикът SQL в комерсиалните реализации


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

Най-близки до System R са били двете системи на фирмата IBM - SQL/DS и DB2. Предполага се, че тези системи пряко са използвали реализацията на System R. От тук и голямата близост на реализираните диалекти на SQL до SQL System R. От SQL System R са били махнати само тези части, които не са били достатъчно разработени (например, точките на съхранение) или реализацията която предизвикала много големи технически трудности (например, ограниченията за цялостност и тригерите). Този път към комерсиална реализация може да се нарече движение на SQL отгоре надолу.

Друг подход се прилагал в такива системи, като Oracle и Informix. Независимо от различието в начина на разработка на тези системи, реализацията на SQL се извършвала "отдолу нагоре". Първо: пуснатите на пазара реализации на SQL в тези системи се използвали минимално и много ограничено подмножество на SQL System R. В частност, в първата известна ни реализация на SQL в СУБД Oracle в операторите за избор не се допускало използване на вложени подзаявки.

Независимо от тези ограничения и от много слабата на първо време ефективност, ориентацията на фирмите към поддържане на различни апаратни платформи и заинтересоваността на потребителите към преход към релационните системи позволили на фирмите да постигнат комерсиален успех и да пристъпят към усъвършенствуване на своите реализации. В текущите версии на Oracle и Informix се поддържат достатъчно мощни диалекти на SQL, макар реализацията понякога да предизвиква съмнения.

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

13.3. Стандартизация на SQL


Дейността по стандартизацията на езика SQL започва практически едновремено с появата на първите му комерсиални реализации. Един от първите документи е с дата октомври 1985 г. и е един от поредния проект на стандарта ANSI/ISO.

В качеството на стандарт не е можело да се използва SQL System R. Първо, този вариант на езика не е бил правилно проработен технически. Второ, твърде сложно е било да се реализира (никой не знае, каква щешпе да бъде по-нататъшната история на SQL, ако бяха реализирани напълно всички идеи на System R). От друга страна, първите комерсиални реализации на езика толкова са се различавали, че нито един от реализираните диалекти нямал шанс да бъде приет в качеството на стандарт.

Анализът на достъпните документи показва, че процесът се развивал много сложно с използване на не само научни доводи. В резултат приетият през 1989 г. Международен стандарт на SQL в голямата си част има извънредно общ характер и допуска много широко тълкуване. В този стандарт напълно отсъствуват такива важни раздели, като манипулиране със схемата на БД и динамичен SQL. Много от важните аспекти на езика в съответствие със стандарта се определят в реализацията.

Възможно, най-важните достижения на SQL стандарта са точната стандартизация на синтаксиса и семантиката на операторите за избор и манипулиране на данните и фиксация на средствата за ограничение на цялостността на БД, включвающи възможността за определяне на първичния и външните ключове на отношенията и така наречените проверовъчни ограничения за цялостност, които представляват подмножество на ограниченията за цялостност на SQL System R от първи клас. Средствата за определяне на външни ключове позволяват лесно да се формулират изискванията на така наречената цялостност на БД по указатели. Това разпространено в БД изискване може да се формулира и на основата на общия механизъм на ограниченията за цялостност на SQL System R, но формулировката, основаваща се на понятието за външен ключ e пo-проста и разбираема.

Осъзнавайки непълнотата на SQL стандарта, на фона на завършването на разработката на този стандарт специалисти от различни фирми започнали работа над стандарта SQL2. Тази работа също продължила няколко години, били излъчени няколко проекта на стандарта, докато, накрая, през март 1992 г. не бил изработен окончателният проект на стандарта. Този стандарт е съществено по-пълен и обхваща практически всички необходими за реализацията аспекти: манипулиране на схемата на БД, управление на транзакциите (отново се появили точките на съхранение) и сесиите (сесия – това е последователност от транзакци, в границите на която се съхраняват временни отношения), включването към БД, динамичния SQL. Освен това са стандартизирани отношенията-каталози на БД, което не е свързано с езика непосредствено, но много силно влияе на реализацията.

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

Накрая, едновременно със завършването на работите по определяне на стандарта SQL2 била започната разработката на стандарта SQL3. SQL3 съдържа механизъм на тригери и възможност за използване на абстрактни типове данни. Приемането на стандарта било планирано за 1995 г.


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


Сподели с приятели:
1   ...   5   6   7   8   9   10   11   12   ...   17




©obuch.info 2024
отнасят до администрацията

    Начална страница