В лекцията накратко ще разгледаме основните особености на стандарта за езика SQL 1989г.
14.1. Типове данни
В езика SQL/89 се поддържат следните типове данни: CHARACTER, NUMERIC, DECIMAL, INTEGER, SMALLINT, FLOAT, REAL, DOUBLE PRECISION. Тези типове данни се класифицират по типове на символните низове, точните числа и приблизителните числа.
Към първия клас се отнасят CHARACTER. Спецификаторът на типа има вида CHARACTER (lenght), където lenght задава дължината на низовете от дадения тип. Ще отбележим, че в SQL/89 няма тип низ с променлив размер, макар, че в много реализации те се допускат. Символните низове се изобразяват като 'последователност от символи' (например, 'example').
Представители на втория клас типове са NUMERIC, DECIMAL (или DEC), INTEGER (или INT) и SMALLINT. Спецификаторът на типа NUMERIC има вида NUMERIC [(precision [, scale]). Специфицират се точни числа, представлявани с точност precision и мащаб scale. Тук и по-нататък, ако е изпуснат мащаба, то се предполага равен на 0, а ако не е посочена точност, то нейното значение по подразбиране се определя в реализацията.
Спецификаторът на типа DECIMAL (или DEC) има вида NUMERIC [(precision [, scale]). Специфицират се точни числа, представлявани с мащаб scale и точност, равна или по-голяма от значението на precision.
INTEGER специфицира типът данни точни числа с мащаб 0 и определяема в реализацията точност. SMALLINT специфицира типът данни на точните числа с мащаб 0 и определяема в реализацията точност, не по-голяма, отколкото точността на числата от тип INTEGER.
Литералните стойности на точните числа в общия случай се представят във формата
[+|-] <цяло-без-знак> [.<цяло-без-знак>].
Към класа типове данни на приблизителните числа се отнасят типовете FLOAT, REAL и DOUBLE PRECISION. Спецификаторът на типа FLOAT има вида FLOAT [(precision)]. Специфицират се приблизителни числа с двойна точност, равна или по-голяма от стойността на precision.
REAL специфицира тип данни на приблизителните числа с точност, определена в реализацията. DOUBLE PRECISION специфицира тип данни на приблизителните числа с точност, определена в реализацията, по-голяма, отколкото точността на тип REAL.
Значенията на приблизителните числа в общия случай се представят във вида <литерално-значение-на-точно-число>E<цяло-със-знак>.
Макар, че с използването на езика SQL можe да се определи схема на БД, съдържаща данни от всеки от изброените типове, възможността за използване на тези данни в приложните системи зависи от прилагания език за програмиране. Целият набор типове данни може да се използва, само ако се програмира на ПЛ/1. Затова в някои реализации на SQL типовете данни с мащаб и точност въобще не се поддържат.
Макар правилата за вграждане на SQL в програми на език С да не са определени в SQL/89, в повечето реализации, поддържащи такова вграждане, има следното съответствие между типовете данни на SQL и типовете данни на С: CHARACTER съответствува на низовете на С; INTEGER съответствува на long; SMALLINT съответствува на short; REAL съответствува на float; DOUBLE PRECISION съответствува на double (именно такова съответствие е утвердено в стандарта SQL/92).
Ще отбележим още, че в повечето реализации на SQL се поддържат някои допълнителни типове данни, например, DATE, TIME, INTERVAL, MONEY. Някои от тези типове са специфицирани в стандарта SQL/92, но в текущите реализации синтактическите и семантичните свойства на такива типове може да се различават.
14.2. Средства за определяне на схема
Средствата за определяне на схема на БД в стандарта SQL/89 се отнасят към най-слабите и допускащи различна интерпретация части на стандарта. Повече от това, не е известна нито една реализация, в която да се поддържа точно такъв набор средства за определяне на схема.
Затова, за да се постигне мобилност на приложната система в достатъчно широк клас реализации на SQL/89, е необходимо щателно да се локализират компонентите на определението на схема на БД. По-добре е да се съсредоточи цялата работа със схемата на БД в един модул и да се има предвид, че при преход към друга СУБД е много вероятно да потрябва преправяне на този модул.
Ще отбележим, че в SQL/89 въобще отсъстват някакви средства за изменение на схемата на БД: няма възможност да се изтрие схема на таблица, да се добави към схемата на таблица нов стълбец и т.н. Във всички реализации такива средства се поддържат, но те могат да се различават и по синтаксис, и по семантика.
Независимо че няма особени надежди за това, че ще има реализация, поддържаща език за определяне на схеми на SQL/89, кратко ще опишем този език (без синтактични детайли), за да се оценят на съдържателно ниво възможностите на SQL/89 в тази част и да се получат поне някакви средства за сравнение на различните реализации.
14.2.1. Оператор за определяне на схема
В съответствие с правилата на SQL/89 всяка таблица от дадена БД има просто и квалифицирано имена. Ролята на квалификатор на името играе "идентификатор на пълномощията" на таблицата, който обикновено в реализациите съвпада с името на някой потребител, и квалифицираното име на таблица има вида:
<идентификатор пълномощий>.<простое имя>
Подходът за определяне на схема в SQL/89 се състои в това, че всички таблици с един идентификатор на пълномощията се създават (определят се) чрез изпълнение на един оператор за определяне на схема. При това в стандарта не се определя способ за изпълнение на оператора за определяне на схема: трябва ли той да се изпълнява само в интерактивен режим или може да бъде вграден в програма, написана на традиционен език за програмиране.
В оператора за определяне на схема се съдържа идентификатор на пълномощията и списък с елементи на схемата, всеки от които може да бъде определение на таблица, определение на представяне (view) или определение на привилегии. Всяко от тези определения се представя от отделен оператор на SQL/89, но всички те, както беше споменато, трябва да бъдат вградени в оператора за определяне на схема.
За тези оператори ще приведем синтаксис, защото това ще позволи по-точно да опишем особеностите им.
14.2.2. Определение на таблица
Операторът за определяне на таблица има следния синтаксис:
::=
CREATE TABLE (
[{, }...])
::=
|
Освен името на таблицата, в оператора се специфицира списък на елементите на таблицата, всеки от които служи или за определяне на стълб, или за определяне на ограничения за цялостност на определяната таблица. Изисква се наличие на поне едно определение на стълб. Операторът CREATE TABLE определя така наречената базова таблица, т.е. реалното хранилище на данни.
За определяне на стълбовете на таблицата и ограниченията за цялостност се използват специални оператори, които трябва да бъдат вложени в оператора за определяне на таблица.
14.2.3. Определяне на стълб
Операторът за определяне на стълб се описва чрез следните синтактични правила:
::=
[] [...]
::=
DEFAULT { | USER | NULL }
::=
NOT NULL []
|
| CHECK ()
Както се вижда, освен задължителната част, в която се определя името на стълба и неговия тип данни, определението на стълб може да съдържа два незадължителни раздела: раздел за значението на стълба по подразбиране и раздел на ограниченията за цялостност на стълба.
В раздела значение по подразбиране се указва стойността, която трябва да бъде в реда, записан в дадената таблица, ако стойността в дадения стълб не е указана явно. Значението по подразбиране може да бъде указано във вид литерална константа с тип, съответствуващ на типа на стълба; чрез задаване на ключовата дума USER, на която при изпълнението на оператора за записване на реда съответствува символен низ, съдържащ името на текущия потребител (в този случай стълбът трябва да има тип символен низ); или чрез задаване на ключовата дума NULL, означаваща, че стойността по подразбиране е неопределена. Ако значението на стълба по подразбиране не е специфицирано, и в раздела на ограниченията за цялостност на стълба е указано NOT NULL, то опитът да се запише в таблицата низ с неспецифицирана стойност на дадения стълб ще доведе до грешка.
Указанието в раздела за ограниченията за цялостност NOT NULL води до неявно пораждане на проверовъчно ограничение за цялостност за цялата таблица "CHECK (C IS NOT NULL)" (където C е името на дадения стълб). Ако ограничението NOT NULL не е указано, и разделът за подразбиране отсъствува, то неявно се поражда раздел по подразбиране DEFAULT NULL. Ако е указана спецификация за уникалност, то се поражда съответстваща спецификация за уникалност за таблицата.
Ако в раздела на ограниченията за цялостност не е указано ограничение по връзки за дадения стълб (<reference specification>), то се поражда съответствуващо определение на ограничение по връзки за таблицата:
FOREIGN KEY(C) .
Ако е указано проверовъчно ограничение за стълба, то условието за търсене на това ограничение трябва да сочи само към дадения стълб, и неявно да се поражда съответното проверовъчно ограничение за цялата таблица.
14.2.4. Определяне ограниченията за цялостност на таблица
Ограниченията за цялостност на таблица имат следния синтаксис:
::=
|
|
::=
()
::= UNIQUE | PRIMARY KEY
::= [{,}...]
::=
FOREIGN KEY ()
::=
REFERENCES
::=
::=
[()]
::= [{,}...]
::= CHECK ()
За една таблица могат да бъдат зададени няколко ограничения за цялостност, в това число тези, които неявно се пораждат от ограниченията за цялостност на стълбовете. Стандартът SQL/89 устанавява, че ограниченията за таблицата фактически се проверяват при изпълнението на всеки SQL оператор.
Забележка: Наличието на правилно подбран набор ограничения на БД е много важно за надеждното функциониране на приложната информационна система. Заедно с това, в някои СУБД ограниченията за цялостност практически не се поддържат. Затова при проектирането на приложна система е необходимо да се вземе решение за това, кое е по-съществено: да се разчита на поддържането на ограниченията за цялостност, но да се ограничи набора възможни СУБД, или да се откажем от използването им на ниво SQL, запазвайки възможността за използване на не най-съвременни СУБД.
По-нататък T ще обозначава таблицата, за която се определят ограничения за цялостност.
Ограничение за уникалност
Всяко име на стълб в списъка за уникалност трябва да именува стълб на T и не трябва да се включва в този списък повече от един път. При определянето на стълб, включен в списъка за уникалност, трябва да бъде указано ограничение за стълба NO NULL. Сред ограниченията за уникалност на T не трябва да има повече от едно определение на първичен ключ (ограничение за уникалност с ключова дума РRIMARY KEY).
Действието по ограничение за уникалност се състои в това, в таблицата T да не се допуска появата на два или повече реда, значенията на стълбовете за уникалност на които съвпадат.
Ограничение по връзки
Ограничението по връзки от зададен набор стълбове CT на таблицата T върху зададен набор стълбове CT1 от някаква определена към този момент таблица T1 определя условие върху съдържимото на тези две таблици, при което връзките може да се смятат за коректни.
Ако списъкът стълбове CT1 явно е специфициран в определението на ограничението по връзки, то е необходимо този списък явно да влиза в някакво определение за уникалност на таблицата T1. Ако списъкът CT1 не е специфициран явно в определението за ограничение по връзки на таблицата T, то е необходимо в определението на таблицата T1 да присъствува определението на първичния ключ, и списъкът CT1 неявно се полага съвпадащ със списъка от имена на стълбове от определението за първичния ключ на таблица T1. Имената на стълбовете от списъците CT и CT1 трябва да именуват столбове от таблиците T и T1 съответно, и не трябва да се появяват в списъците повече от един път. Списъците на стълбовете CT и CT1 трябва да съдържат еднакъв брой елементи, и стълбът от таблица T, идентифициран като i-ти елемент на списъка CT трябва да има същия тип, както на стълба от таблицата T1, идентифициран като i-ти елемент на списъка CT1.
По определение, таблици T и T1 удовлетворяват зададено ограничение по връзки, ако за всеки ред s на таблицата T такъв, че всички значения на стълбовете на s, идентифицирани от списъка на CT, не са неопределени, съществува ред s1 от таблицата T1 такъв, че стойностите на стълбовете на s1, идентифицирани от списъка CT1, позиционно са равни на значенията на столбовете на s, идентифицирани от списъка CT. Това може да се формулира така: ограничението по връзки се удовлетворява, ако за всяка коректна връзка съществува обект, към който тя сочи. В привичната на програмистите терминология, ограничението по връзки не позволява да се произвеждат "висящи" връзки, неводещи към никакъв обект.
Проверовъчно ограничение
Проверовъчното ограничение специфицира условието, което трябва да удовлетворява поотделно всеки ред на таблицата T. Това условие не трябва да съдържа подзаявките, спецификациите на агрегатни функции, а също и връзки към външни променливи или параметри. В него могат да влизат само имена на стълбове от дадената таблица и литерални константи.
Таблица удовлетворява проверовъчното ограничение за цялостност тогава и само тогава, когато изчислението на условието за всеки ред на таблицата дава true.
В някои реализации се допускат разширени механизми на ограниченията по връзки и проверовъчните ограничения. Трябва да се внимава, ако не желаем да излезем извън границите на възможностите на стандарта.
14.2.5. Определяне на представянията
Механизмът на представянията (view) е мощно средство на езика SQL, позволяващо да се скрие реалната структура на БД от някои потребители за сметка на определянето на представяне БД, което реално е някаква съхранявана в БД заявка с именувани стълбове, а за потребителя с нищо не се различава от базова таблица на БД (с отчитане на техническите ограничения). Всяка реализация трябва да гарантира, че състоянието на представляваната таблица точно съответствува на състоянието на базовите таблици, върху които е определено представянето. Обикновено изчислението на представляваната таблица (материализацията на съответствуващата заявка) се извършва всеки път при използване на представянето.
В стандарта SQL/89 операторът за определяне на представяне има следния синтаксис:
::=
CREATE VIEW [()]
AS [WITH CHECK OPTION]
::= [{,}...]
Определяната представляема таблица V е изменяема (т.е. по отношение на V може да се използват операторите DELETE и UPDATE) тогава и само тогава, ако се изпълняват следните условия за спецификация на заявка:
-
В списъка на извадката не е указана ключовата дума DISTINCT;
-
Всеки аритметичен израз в списъка на извадката представлява една спецификация на стълб, и спецификацията на един стълб не се появява повече от един път;
-
В раздела FROM е указана само една таблица, явяваща се или базова таблица, или изменяема представляема таблица;
-
В условието на избора в раздела WHERE не се използват подзаявки;
-
В табличния израз отсъстват раздели GROUP BY и HAVING.
Тези ограничения са много силни. В реализациите те могат да бъдат отслабени. Но ако се стремим към мобилност, не трябва да се използват разширените възможности.
Ако в списъка за избор в спецификацията на заявката имеется има поне едун аритметичен израз, състоящ се не от една спецификация на стълб, или ако едно име на стълб участвува в списъка за избор повече от един път, определението на представянето трябва да съдържа списък от имената на стълбовете на представяната таблица. По-просто, трябва явно да се именуват стълбовете на представяната таблица, ако тези имена не се наследяват от стълбовете на таблиците от раздела FROM на спецификацията на заявката.
Изискването WITH CHECK OPTION в определението на представянето има смисъл само в случай на определение на изменяема представляема таблица, която се определя от спецификацията на заявката, съдържаща раздел WHERE. При наличие на това изискване не се допускат изменения на представляемата таблица, които водят до появата в базовите таблици на редове, невидими в представляемата таблица (т.е. такива редове, които не удовлетворяват условието за търсене на раздела WHERE от спецификацията на заявката). Ако WITH CHECK OPTION в определението на представянето отсъствува, такъв контрол не се извършва.
14.2.6. Определяне на привилегии
В съответствие с идеологията на езика SQL контролът за правата на достъп на даден потребител до таблиците на БД се извършва на основата на механизма на привилегиите. Фактически, този механизъм се състои в това, че за изпълнението на всяко действие над таблица потребителят трябва да притежава съответната привилегия (реално всички възможни действия се описват с фиксиран стандартен набор привилегии). Потребител, създал таблица, автоматически става собственик на всички възможни привилегии над изпълнението на операции над тази таблица. Сред тези привилегии е и привилегията за предаване на всички или някои привилегии по отношение на дадената таблица на друг потребител, включително привилегията за предаване на привилегии. Понякога се поддържа и обратната операция по изземане на привилегиите от потребителя, получил ги преди това.
В SQL/89 се определя опростена схема на механизма на привилегии. Първо, "раздаването" на привилегии е възможно само при определянето на таблица. Второ, потребителят, получил някакви привилегии от други потребители, може да ги предаде по-нататък само при определянето на схемата.
Определянето на привилегии се извършва по следния синтаксис:
::=
GRANT
ON TO
[{,}...] [WITH GRANT OPTION]
::=
ALL PRIVILEGES
| [{,}...]
::= SELECT | INSERT | DELETE
| UPDATE [()]
| REFERENCES [(]
::= [{,}...]
::= PUBLIC |
Смисълът на механизма за определяне на привилегии в SQL/89 е достатъчно ясен от този синтаксис. Ще отбележим само, че трябва да се притежава привилегията REFERENCES по отношение на указани стълбове на таблица T1, за да има възможност при определението на таблица T да се определи ограничението по връзки между тази таблица и съществуващата към този момент таблица T1.
Забележка: макар в общия смисъл във всички SQL-ориентирани СУБД да се поддържа механизъм на защита на достъпа на основата на привилегии, реализациите могат да се различават в детайлите. Това е мястото, което трябва да се локализира, ако се стремим към създаването на мобилна приложна система.
Сподели с приятели: |
