КАТЕГОРИЯ:

основен
Случайна страница
контакти


Астрономия- (809) Биология- (7483) Биотехнологии- (1457) Военное дело- (14632) Высокие технологии- (1363) География- (913) Геология- (1438) Государство- (451) Демография- (1065) Дом- (47672) Журналистика и СМИ- (912) Изобретательство- (14524) Иностранные языки- (4268) Информатика- (17799) Искусство- (1338) История- (13644) Компьютеры- (11121) Косметика- (55) Кулинария- (373) Культура- (8427) Лингвистика- (374) Литература- (1642) Маркетинг- (23702) Математика- (16968) Машиностроение- (1700) Медицина- (12668) Менеджмент- (24684) Механика- (15423) Науковедение- (506) Образование- (11852) Охрана труда- (3308) Педагогика- (5571) Полиграфия- (1312) Политика- (7869) Право- (5454) Приборостроение- (1369) Программирование- (2801) Производство- (97182) Промышленность- (8706) Психология- (18388) Религия- (3217) Связь- (10668) Сельское хозяйство- (299) Социология- (6455) Спорт- (42831) Строительство- (4793) Торговля- (5050) Транспорт- (2929) Туризм- (1568) Физика- (3942) Философия- (17015) Финансы- (26596) Химия- (22929) Экология- (12095) Экономика- (9961) Электроника- (8441) Электротехника- (4623) Энергетика- (12629) Юриспруденция- (1492) Ядерная техника- (1748) Arhitektura- (3434) Astronomiya- (809) Biologiya- (7483) Biotehnologii- (1457) Военни бизнесмен (14632) Висока technologies- (1363) Geografiya- (913) Geologiya- (1438) на държавата (451) Demografiya- ( 1065) Къща- (47672) журналистика и смирен (912) Izobretatelstvo- (14524) външен >(4268) Informatika- (17799) Iskusstvo- (1338) историята е (13644) Компютри- (11,121) Kosmetika- (55) Kulinariya- (373) културата е (8427) Lingvistika- (374) Literatura- (1642) маркетинг-(23702) математиците на (16968) Механична инженерно (1700) медицина-(12668) Management- (24684) Mehanika- (15423) Naukovedenie- (506) образователна (11852) truda- сигурност (3308) Pedagogika- (5571) Poligrafiya- (1312) Politika- (7869) Лево- (5454) Priborostroenie- (1369) Programmirovanie- (2801) производствено (97 182 ) индустрия- (8706) Psihologiya- (18388) Religiya- (3217) Svyaz (10668) Agriculture- (299) Sotsiologiya- (6455) на (42831) спортист строително (4793) Torgovlya- (5050) транспорт ( 2929) Turizm- (1568) физик (3942) Filosofiya- (17015) Finansy- (26596) химия (22929) Ekologiya- (12095) Ekonomika- (9961) Electronics- (8441) Elektrotehnika- (4623) Мощност инженерно ( 12629) Yurisprudentsiya- (1492) ядрена technics- (1748)

Лекции Теоретичен курс

тестове

заключение

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

(IBM), който се опитва да осигури възможности за работа с комплексни обекти чрез разширяване на SQL, и Енгр (UC Berkeley), където Майкъл Stonebraker предложи механизъм за дефиниране на потребителски типове данни на базата на мненията и съхранени процедури.Въпреки това, да даде нов тласък на разширяването на обектни свойства СУБД на SQL-ориентиран е получена от обективния свят след публикуването на първия манифест.

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

Развитието на обектно-релационния подход е отразен в съответния развитието SQL език.Giant стандартен SQL: 1999 ви позволява да сравнявате най-малко известно изпълнение, въпреки че нито една компания не е напълно не го подкрепят.Както можете да видите, на SQL стандарта, разработчиците са отишли до много по-голямо сближаване с обектно-ориентиран подход за организиране на системи за бази данни от очакваното през второто манифест.Това е особено очевидно в напечатани договореностите маса, референтни типове и референтни стойности: напечатани маси, подобни на размерите на класове, както и референтни стойности - до идентификатори на обекти.Въпреки това, в много отношения тя е външна прилика - за пътя изрази в ODMG стил все още крият операция маса връзка.

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

Един последен въпрос, който ние ще завърши този курс.Въпреки някои критики в адреса на езика SQL, както е посочено в началото на лекцията 11 прекарахме на обсъждането на езика на почти половината от хода и повече едва ли критикуван.Означава ли това, че езикът все още е много добра, или че авторът на курс има за него специална привързаност?Разбира се, че не!Езикът на SQL има много слабости, неточности и дори директни грешки.Ако ние тръгнахме да покаже всички грешки на езика SQL, а след това разбира се ще никога не са приключили, и читателите си и не знаят какво представлява език като цяло.



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

1 (1) Да предположим, че имате следните две дефиниции на отделните видове:

CREATE TYPE EMP_NO_I AS ЦЯЛО FINAL;

CREATE TYPE EMP_NO_C AS CHAR (6);

Стойностите на двата вида са номера на служителите, но в първия случай да представляват числа, използвайки числа (очевидно естествено число), а вторият - низ от знаци, представляващи естествени числа.Да приемем, че на маса T1 е определена колона тип EMP_NO_1 EMP_NO_I и таблица T2 - Колона тип EMP_NO_2 EMP_NO_C.Необходима за изпълнение на Равно-присъединят маси Т1 и Т2 от ценностите и EMP_NO_1 EMP_NO_2 колоните.Кои от твърденията, цитирани по-долу са верни?

(A) -

CAST (EMP_NO_1 в цяло число) = CAST (EMP_NO_2 в цяло число)

(В) +

CAST (EMP_NO_1 в цяло число) =
CAST (CAST (EMP_NO_2 ДА CHAR (6)) AS ЦЯЛО)

(C) -

CAST (EMP_NO_1 AS ЦЯЛО) = CAST (EMP_NO_2 AS ЦЯЛО)

1 (2), за да се определи личността и структурна UDT използва същото изявление CREATE TYPE.Как се гледа на определение на типа, че е възможно да се каже точно коя от двете категории се отнася това определение?

(A) -

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

(В) +

при определяне на структурния тип е или присъства раздел наследство ПОД, ако е определено вид не е максимумът, или да присъства представителство раздел AS списък определение спецификация атрибут, оградена в скоби;при определяне на вида на индивидуалната да присъстват представяне сечение, с името на предварително вграден тип (без скоби)

(В) +/- е вярно за SQL: 1999, но промяната в бъдеще

при определяне на структурния тип трябва да съдържа не по FINAL спецификация, и при определянето на вида на индивидуална - FINAL.

1 (3) Нека структурния тип Т не е пряк supertype на максималната тип Т ".Кое от следните твърдения за определенията на T и T "са правилни?

(A) -

при определяне на вида на Т "не трябва да съдържа част, както

(Б) - / + Това винаги е вярно в SQL: 1999, но не се характеризират положението

при определяне на типа Т не трябва да съдържа FINAL спецификация

(С) +

при определяне на типа T трябва да съдържа раздел ПОД, при определянето на вида на Т "трябва да съдържа по раздел се посочва вида на T.

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

(A) -

в дефиницията на една маса напечатан, има раздел ПО

(В) -

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

(С) +

в дефиницията на една маса напечатан, има раздел НА

2 (2) Да предположим, че R е таблица, напечатан само напечатани маса максимална supertablitsey R ".Кое от следните твърдения по отношение на R и R 'са верни?

(A) -

структурен тип на таблицата е максималната R supertype маса тип структура R '

(В) +

в дефиницията на R не е раздел на таблицата по-долу, в R на определение маса "има раздел, появяващи се при R маса;R тип структура маса е директен supertype маса тип структура R '

(В) - / +, е вярно, но не се характеризират положението

в дефиниция R на маса "липсва решителност и самостоятелно референтна първичен ключ колона

2 (3) Нека A - е самостоятелно съотнасяне колона на печатен маса R.Каква е основната спецификация за генериране на стойности на тази колона?

(A) -

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

(В) -

самостоятелно референтна дефиниция на колона в таблицата максимално supertablitse R

(С) +

тип достъп спецификация да се определи максималната supertype маса тип структура R

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

CREATE TYPE EMP_T AS (
EMP_NAME VARCHAR (20)
EMP_BDATE ДАТА,
EMP_SAL ЗАПЛАТА,
Кат REF (кат))
INSTANTIABLE
НЕ FINAL
REF се генерира СИСТЕМА
МЕТОД СЪД възраст ()
RETURNS DECIMAL (3,1);

CREATE TYPE PROGRAMMER_T ПО EMP_T AS (
PROG_>
INSTANTIABLE
НЕ FINAL;

CREATE TYPE DEPT_T AS (
DEPT_NO ЦЯЛО,
DEPT_NAME VARCHAR (200)
DEPT_MNG REF (EMP))

INSTANTIABLE
REF се генерира СИСТЕМА
НЕ FINAL;

Създаване на таблица EMP НА EMP_T
(REF IS DEPT_ID генерираното от системата,
Кат с опция ПОЛЕ DEPT);

Създаване на таблица програмист PROGRAMMER_T ПО EMP;

Създаване на таблица кат DEPT_T
(REF IS EMP_ID генерираното от системата,
DEPT_MNG с опция ПОЛЕ EMP);

3 (1) Кои от следната формулировка правилно съответстват на заявката ", за да даде имената на началниците на отдели, в които работят най-малко един програмист"?

(А) +

SELECT DISTINCT кат -> DEPT_MNG -> EMP_NAME
ОТ PROGRAMMER

(В) -

SELECT eMP_NAME
ОТ EMP, кат
КЪДЕ кат = DEPT_ID
И DEPT_MNG = EMP_ID
И не съществува (SELECT *
ОТ PROGRAMMER
КЪДЕ кат = DEPT_ID);

(С) +

SELECT eMP_NAME
ОТ EMP, кат
КЪДЕ DEPT_MNG = EMP_ID
И не съществува (SELECT *
ОТ PROGRAMMER
КЪДЕ кат = DEPT_ID);

3 (2) Коя от следната формулировка правилно съответстват на заявката ", за да даде имената на ръководителите на отдели, които работи изключително програмисти"?

(A) -

SELECT DISTINCT кат -> DEPT_MNG -> EMP_NAME
ОТ PROGRAMMER

(В) +

SELECT DEPT_MNG -> EMP_NAME
ОТ DEPT
Когато не СЪЩЕСТВУВА (SELECT *
ОТ САМО (EMP)
КЪДЕ кат = DEPT_ID);

(C) -

SELECT DEPT_MNG -> EMP_NAME
ОТ DEPT
КЪДЕ кат IN (SELECT DEPT
ОТ PROGRAMMER);

3 (3) Кои от следната формулировка правилно съответстват на заявката ", за да даде имената на началниците на отдели, в които работят най-малко един не-програмист"?

(А) +

SELECT DISTINCT кат -> DEPT_MNG -> EMP_NAME
ОТ САМО (EMP);

(В) -

SELECT DISTINCT кат -> DEPT_MNG -> EMP_NAME
ОТ PROGRAMMER
КЪДЕ кат IN (SELECT DEPT
ОТ САМО (EMP));

(С) +

SELECT DEPT_MNG -> EMP_NAME
ОТ DEPT
КЪДЕ кат IN (SELECT DEPT
ОТ САМО (EMP));

4 (1), за да се определи от разновидностите на представителства, използвани същото изявление CREATE VIEW.Как се гледа на определението на мнение, че определено може да се каже, че това е валидно определение на печатен изглед?

(A) -

Настоящото раздел НА

(В) +

Настоящите и форумите на недостатъчно

(C) -

Предвиденият бюджет за настоящата точка

4 (2) Как трябва да съответства на печатен изглед тип конструкция с структурен тип печатен база за маса, тази гледна точка?

(А) +

Тези видове, трябва да съответстват на

(В) -

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

(C) -

тип база за маса, трябва да бъде пряк supertype собствен тип predstaveleniya

4 (3) Нека представителство V "в печатен база за маса, R 'е пряко представителство на тяхната собствена subrepresentation V в R база написали маса.Кое от следните твърдения е вярно?

(A) -

форма на представителство, V "трябва да бъде пряк подтип на представителство V, и на масата на R" трябва да бъде пряк ПОДТАБЛИЦА маса R

(В) +

Вид на V трябва да бъде пряк supertype от типа на представителство V ", и на маса R трябва да бъде supertablitsey маса R '

(C) -


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

** Припомнете си, че S 'е правилно подмножество на множеството S и само в случаите, когато S "е част от S, но не съвпада с S (това се нарича S" И С).

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

* Ако това е привърженик на класическата релационна подход;в SQL език позволи определянето на таблици без първични ключове и възможно.

**.Между другото, ние се отбележи, че в класическия релационния модел, ако дефинирате променлива съотношение ясно показва неговия първичен ключ, след това по подразбиране се счита за първичен ключ, за да бъде пълен набор от заглавна атрибути отношения.Разбира се, в този случай, променливо съотношение може да приеме всяка стойност съотношение, съответстващо на титлата, и първичен ключ не играе ограничена роля.

* Тези ограничения са все по-разхлабени в стандартната последователност SQL език

* За втори път в тази глава твърди, че нормализира н -ary връзката е само родово структурата на данните, използвани в релационни бази данни.Това е време, за да обясни какво имаме предвид под термина родово структура.В езиците за програмиране, с модерни системи тип обикновено имат конструкции, наречени основни видове, параметризирани типове, тип конструктори, видове генератори и т.н., което позволява да се генерира определен тип данни, основаващи се на нейната абстрактна (обикновено включва предварително зададени) спецификация.Особеността на този вид е, че конкретният вид на голяма операция се определя в този абстрактен спецификация.Един от най-известните примери е типът на снимачната площадка, например, на езика Pascal.Ако не е изрично каже релационния модел на данните, които otosheniya е общ вид, но по същество това е.релационни операции алгебра се определят на абстрактно ниво на отношения и се прилага за всички стойности otosheniya-специфична заглавията.

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

вярно фалшив ИЛИ вярно фалшив НЕ вярно фалшив
вярно вярно фалшив вярно вярно вярно фалшив вярно
фалшив фалшив фалшив фалшив вярно фалшив

* В SQL език може да бъде няколко варианта за външен ключ определението на, от които само един е в пълно съответствие с класическия подход.За повече информация, ние ще обсъдим това в следващата лекция.

* Не е трудно да се провери, че A INTERSECT B = минус (минус B) = B МИНУС (B минус).

* Когато Ac и Bc са т.нар квалифициран (неопределени) атрибут имена (често начин да се именува нарича нотацията с точка).Ние ще използваме подобен нотация в тези случаи, когато това се изисква, за да се покаже ясно, схемата на отношенията принадлежи на атрибута.

* Необходимо е да се поясни, че съотношението ZARP_11000 всъщност е буквален константа на подходящия вид отношения.Ние не се въведе тук понятието строг тип взаимоотношения;за разбирането на тази глава само трябва да се осъзнае, че по природа и нагласа ZARP_20000 цифров буквален 20000.00 не се различават.

** Ratio ZARP_BOLSHE_20000 - също е буквално на един и същ вид отношения, както ZARP_20000, но като цяло тази връзка буквален тялото мощност (ако не е наложил ограничения за набор от ценности SLU_ZARP домейн) може да бъде много голям.

* Особеността на този случай се крие във факта, че броят на кортежи в тялото буквално ZARP_NE_22000vsego само една по-малко от кардиналността на стойностите на домейни набор SLU_ZARP.Разбира се, тази власт е ограничен, тъй като ние се занимаваме с типа компютър с данни, но като цяло може да бъде много голям.Ето защо, по принцип възможността за изразяване на операция ограничение релационна операция на връзка не означава, че би било разумно да го прилага по начин, който на практика.

* Разбира се, един и същ резултат ще даде израз SLUZHASCHIE_1 <И> ((((SLUZHASCHIE_1 <Премахване> SLU_RUK) <Премахване> SLU_IMYA) <Премахване> SLU_ZARP) <ПРЕИМЕНУВАНЕ> (SLU_NOMER, RUK_NOM)).

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

* Не е трудно да се види, че по принцип, ако общата мощност на атрибутите на домейна на A и B е равно на N, тялото на постоянна A_BOLSHE_B съотношение мощност ще бъде (N + 1) N / 2.

* Това е "постоянна" нагласа, която тялото не зависи от текущото съдържание на отношения на служителите на тялото.

* И разбира се, в алгебра A, като по алгебра Codd, трябва да има операция променлива присвояване отношения.

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

* Чрез, ако ... след това тук е за един-важните и логически функции - намека.По дефиниция, ако А ПОСЛЕ б º НЕ а ИЛИ б.Въпреки, че последствията от операцията е излишно, то е ясно, въведена в релационна смятане, като често се налага на практика да изрази условия.

* Упражнение за читателя.Защо в първата формула (с такъв), използван състояние SLU1.SLU_ZARP> SLU2.SLU_ZARP и втората формула (с FORALL) - SLU1.SLU_ZARP ³ SLU2.SLU_ZARP?

* За съжаление, класически статията Армстронг - WW Армстронг."Зависимост Структури на база данни Връзки" , Proc.IFIP Congress, Стокхолм, Швеция, 1974 - не е преведена на руски (в действителност, това не е лесно да се намери в оригинал).Така че аз не мога да го препоръчвам за по-нататъшно четене, макар длъжен да се отнася.

* Ние използваме тук марка проверяват включването на набора от операции, което не е съвсем правилно, защото, ако, например, определен B се състои от един елемент, след това посочи, че се използва името на атрибута, и в този случай това е по-правилно да използва марката "I" (чек елементни събития, включени в комплекта).

* FD с минимално детерминанта се нарича минимално лявата.

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

* Non-ключов атрибут се нарича атрибут, който не е част от нито един ключов един кандидат.

** Определението предполага, че има само един съотношение възможно ключ.

* Очевидно е, че РР се нарича непреходен, ако и само ако не е преходен.

** Това определение поема отново, че връзката има само един възможен ключ.

* Теоретично е възможно трето разлагане е съотношението на SLUZH2 на отношенията {SLU_NOM, SLU_ZARP} {SLU_UROV и провал прекъсвач, SLU_ZARP} не е без загуба разлагане.За да видите това, да разгледа случая, когато две различни редиците на служителите получават същото количество на заплата.Също така показват, че условията не са изпълнени теорема на Хийт за такова разлагане.

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

* Единственият възможен ключ връзката е SLUZH_NOM_ZADAN {SLU_NOM, SLU_ZADAN}, и в това отношение не са налице нетривиален FD.

* Упражняване на курс от лекции.Да има съотношение R с качества А, В, С (като цяло, композитен), в които има FD А ® Б.Какво тогава може да се каже за връзката на атрибути A и C?

* FD с минимално детерминанта се нарича минимално лявата.

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

* Като се започне с тази глава, ние се обръщаме към употребата на термини, маса, ред и колона, вместо строго релационни отношение връзка, атрибут, и маса, защото там е "релационна" база данни се отнася най-вече, SQL-ориентирани бази данни, за които тази опростена терминология по-естествено.

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

* Аз ще си позволя една терминологична забележка, която може да изглежда малко наивна за специалисти в областта на софтуерното инженерство (софтуерно инженерство), сред които не принадлежат.Long тъй като има отделен клас на софтуерни системи, предназначени за автоматизиране на проектирането на нови продукти в различни отрасли - автомобилостроенето, космонавтиката, електронна промишленост и т.н.Очевидно е, че процеса на проектиране колата е коренно различна от процеса на проектиране микропроцесор, но, въпреки това, да се позове на всякакви системи за автоматизация на проектирането, използвани събирателен термин CAD (CAD - Computer Aided Design).Това се обяснява с факта, че различни подкласове на CAD имат много повече прилики, отколкото разлики.Така че, по мое мнение, в тяхната цел и структура на системата за автоматизация на проектирането на базата данни е повече класа на CAD система, отколкото случай клас система (Computer Aided Software Engineering).Очевидно, автоматизирани инструменти за подкрепа дизайн започна по времето, наречена съдебната инструменти, тъй като те обикновено са включени не само инструментите за подпомагане на разработването, но инструментите, които поддържат проектирането и разработването на приложения за бази данни.През последните години, тези инструменти са рядко, произведени в един пакет, а терминът съдебна означава почти от употреба.Въпреки това, тъй като не е имало каквито и да било други средства за подпомагане на колективни prroektiroavniya име на база данни, ние ще продължим да използваме този термин.

* Трябва да се разбира, че това "определение" всъщност е тавтология, тъй като, от една страна, ние се опитваме да се дефинира понятието "предприятие" чрез неспецифичен термин "обект", и второ, опит да се дефинира понятието "обект" е като безнадежден.Обикновено авторите се опитват да оправдаят факта, че в този контекст те се отнасят до "всеки ден" и не всеки формализирана концепция на обекта.Разбира се, това не става по-лесно, защото същността на концепцията трябва да се разбира по достатъчно точен смисъл.Но тази тавтология не е измислена от автора на този курс;Тя е традиционна за района на семантична моделиране.В тази област, нетърпеливи да се избегне, доколкото е възможно формалности.

* Макар че би било по-правилно да се използва винаги тип отношение лице и копие от вида на предприятието да се избегне детайлност (и следвайки традицията) в случаите, когато това не води до неяснота, ние ще използваме термина субект по смисъла на вида на образуванието.

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

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

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

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

* Този аспект също се отнася до фазата на физически дизайн, тъй като тя е свързана с особеностите на прилагането на СУБД.

** Докато повечето SQL ориентирани съхранение DBMS с неопределено значение е минимално над главата;Този аспект на физически дизайн отново.

* В тази глава ще се използва терминът същност е като неформална като в предишната глава използва термина обекта.В UML, твърди, да се осигури по-точна и официална концепция на обекта (UML обикновено се нарича на езика на обектно-ориентираното моделиране).В спецификацията на UML е още една дефиниция на обекта с помощта на UML.Въпреки това, в нашето дълбоко убеждение, че въпреки тези усилия концепцията за обект в UML остава неясна, тъй като концепцията за същността на ER-модела.И все пак, ние трябва да разчитат на интуицията и здравия разум най-вече.

** В UML, както и в модел на ER-диаграми за родовото наименование на връзки използват дългосрочни отношения.В много преводи на книги за UML на руски език се използва вместо термина връзката терминът връзка.Както и в предишната глава, ние използваме термина съобщението.

*** Език OCL е част от спецификацията на UML, но, за разлика от други части на езика, все още няма графики и линейна нотация.

* Изглежда, че може да се направи известна аналогия със ситуацията, поради наличието на които в релационната алгебра (вж. Лекции 3 и 4) е въведена ПРЕИМЕНУВАНЕ операция.

* Ако "релационна" база данни, за да се разбере на SQL-ориентирана база данни.

** Спомнете си, че в изпълнението на ER-модел, която представихме в предишния liktsii, разрешено само бинарни отношения.По времето, Oracle оправдава това решение, като казва, че присъствието на двоични асоциации винаги е достатъчно.Тук ние се ограничаваме до обсъждането на двукомпонентни асоциации.

* Тъй като UML - език на високо равнище, моделиране, тя не уточнява какво е реализуема, в смисъл на навигация.Но е очевидно, че самата му поява на навигационни понятия, свързани с обектно-ориентиран UML природата.Терминът навигацията е почти мръсна дума в света на релационни бази данни, но и за света на обектно-ориентирани бази данни, че е съвсем естествено, защото в този свят представата за справка, показалеца, или присъства на ниво модел.

** Може да се разглежда като показател за необходимостта от ограничаване на видимостта на обекти на база данни от гледна точка на релационна база данни с еднопосочен навигация сдружение на.Съответната (но много по-често) възможността са SQL ориентирана база данни осигурява механизъм представителства (Изглед).За повече информация, вж. В следващите лекции.

* Макар език OCL официално счита за част от UML, тя е посочена в отделен документ, който съдържа връзки към други части на спецификацията на UML и внедри свои понятия и определения.

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

*** Моля, имайте предвид, че докато, най-общо казано, да се позволи на п- ари отношения в UML, OCL в говорим само за познатия двоичен опция за нас.

* В контекста на разработването на релационна база данни (ако не се има предвид използването на обектно-релационна система за управление на бази данни), като последният вид тип колекция е безсмислена, тъй като релационна база данни не се поддържа поръчка.Ето защо, ние не ще обсъдят детайлите на операциите на последователности.

** Ако все още не се има предвид използването на обектно-релационна система за управление на бази данни.

* Очевидният аналог на класа е вид субект и аналогова връзка, сдружение - комуникация, в смисъл на ER-модел.Между другото, разликите в терминологията и кашата е наистина депресиращо.Съобщението на ER-модел (отношения) - асоциация (сдружение) между двата вида субекти.Асоциацията на UML (сдружение) - е един от видовете комуникация (отношения).Да, по някаква причина, в UML въведе специален термин за обозначаване на асоциацията на линк инстанция.Отново бих искал да се използва терминът връзката, но той вече беше безнадеждно зает, и че е необходимо да се преведат връзката на връзката като руския еквивалент.Това, разбира се, не противоречи на смисъла, но също така е много лошо, защото в съединение термин релационна база данни, без да го има две различни значения - експлоатация връзки и свързване към сървъра на базата данни.Много съжалявам, че преведените книги, посветени на UML.

* Въпреки, че е малко в противоречие с една от основните цели на оригиналната релационния подход към организацията на базата данни: осигуряване на максимална приложение независимо от структурата на базата данни, както и увеличаване на възможността за повторно използване на съществуващи бази данни в случай на нови приложения.От друга страна, по-здравословен прагматизъм предполага, че, макар и да не забравят за възможните нужди в бъдеще, е необходимо, на първо място, да се стреми към ефективно изпълнение на текущите задачи.

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

** В чужда среда, IBM, които са имали уникален и положителен опит в изпълнението на експериментален релационна база данни, система R, не е първата компания, която предлага на пазара с търговска релационна база данни.напред на IBM за две години, малко преди компанията формира от Oracle, която пусна първия си система през 1979 г. Днес, експерти по различен начин обясняват причините за това "изоставане" IBM, но, както изглежда, основната причина се крие в традиционния консерватизъм на ръководството на компанията.

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

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

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

* За съжаление, ние трябва да използваме термина линия по два начина: линия на маса (маса ред) и символ или битов низ (характер или битов низ).Ние ще се опитаме да се гарантира правилното разбиране на смисъла на думата в контекста на неговото използване.

** Спецификация предварително определен тип битов данни низ е била отстранена в SQL: 2003.Но тъй като тази спецификация Povilas само в SQL: 1999, видяхме добре да бъдете в крак с обсъждането на този тип данни.

* Вж. Булева долу.

** Трябва да се подчертае, че не SQL стандарт определя броя на байтовете, заети при съхраняване в стойностите на паметта на видове целочислени.Не бива да мислим, че SQL за съхраняване на стойността на цяло число тип изисква четири байта, и SMALLINT изисква два байта.

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

** Това е пространство, не са "празни" герои!

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

* Тъй като стойността на Z може да бъде много голяма, тя може да бъде съкратена форма на работа им като NK, нМ и ПГ, където п - положително число и K, M и G представлява килограм, мега и гига, съответно.

* Буквален петно ​​трябва винаги да съдържа четен брой шестнадесетични цифри.

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

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

* съответните дефиниции се съхраняват като част от метаданните на база данни (с други думи, те са част от схемата на базата данни).

** Това е необходимо, че при определяне на структурния тип А само видове работа, които са били идентифицирани по-рано.

* От сега нататък, ние ще дадем повече или по-малко точни SQL език синтактични конструкции (не злоупотребяват ексцесии).Без него, текстът щеше да е по-малко точни и по-обемна.Главни букви се показват "крайни" - ключовата дума на езика SQL.

** Тук сме за първи път се сблъскват с името на обект на базата данни.Ние няма да навлизам в подробности, но като цяло, имената на SQL-ориентирани обект на базата данни имат форма imya_kataloga.imya_skhemy.imya_obekta.Този подход за именуване на обекти на базата данни ви позволява самостоятелно да създавате обекти в различни схеми, без да се интересува, че предметите имат различни прости имена.Когато се използва в изявление SQL, проста система име обект трябва да се актуализира автоматично името, въз основа на идентификатора на потребителя, името на който се изпълнява в изявлението.

*** Тази стойност ще се използва по подразбиране за всяка колона е определено в този домейн, който не определя своя собствена подразбиране (виж. Следващата лекция).

* {Element 1, |елемент 2, | ... |елемент н} означава, че в синтаксиса трябва да присъства един и само един елемент аз.

** Стойност niladic_function "оценена" в момент, когато искате стойността по подразбиране (обикновено, когато се добавя нов ред в таблицата, на стойност, съответстваща на тази на колонката изрично е посочено).Значение CURRENT_DATE, CURRENT_TIME и CURRENT_TIMESTAMP очевидна.USER (или, което е същото, текущия потребител), SESSION_USER SYSTEM_USER и зададете идентификацията на потребителя, името на която сегашната сделка, текущата сесия, и идентификатора на операционната система, в която потребителят работи, съответно.Стандартът не определя представянето на тези идентификатори, но имплементации обикновено са представени под формата на символен низ.

*** За повече информация, ние ще обсъдим вида на допустимите в SQL условни конструкции в следващите лекции.

* В SQL отношение заглавието и тялото на таблицата не се използват.Тук можем временно да използвате тази терминология само за целите на сравнението SQL модел с модела на релационни данни.

* В скоби обозначава списък с дефиниции на елементи от базовата таблица (трябва да присъстват определение на най-малко една колона), разделени със запетаи.

* Имайте предвид, че въпреки че колоната може да получи стойност по подразбиране NULL а като явно или неявно, двете дела не са равностойни.Изрично позоваване NULL като стойност по подразбиране забранява стойности наследството на колони за домейн по подразбиране.

** В този случай, SQL, се основава на семантиката на нулеви стойности, с изключение на тази, използвана в повечето други случаи.Смята се, че (NULL = NULL) = вярно и че (а = NULL) = (NULL = A) = фалшива за всички стойности на А, не-NULL.

* Като се вземат предвид коментарите на специално тълкуване на семантиката на нулеви стойности, направени в предходната бележка под линия.

* От рано обяснение на действието на външния ключ за определяне на наличието на външен MATCH ЧАСТИЧНО ключова точка на това трябва да е ясно, че в този случай един ред от таблицата S може да се позовава на няколко различни линии на T маса.

* Както се вижда от горното обяснение, справочните действия служат за автоматично поддържане на връзките, когато маси актуализациите, които са свързани с линиите.Доста често справки и действия, които са част от дефиницията на външния ключ се нарича на декларативни спусъците.

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

** Поради тази причина, ние въведохме в предишната глава толкова горната граница - стойности на заплатите, на домейни - 20,000,000.00.

*** С други думи, това е естествено ограничение изисква размерът на отдел ТРЗ никога не е било по-малко от общата сума на заплатите, получени от служители на този отдел.

* С изключение на тези таблични ограничения за интегритет, че (а) определянето на установения част на базовата таблица, съдържаща колоната, и (б) не съдържат позоваване на каквито и да било други колони.

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

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

* С изключение на тези ограничения за интегритет, че (а) определянето на установения част на базовата таблица, и (б) не се позовават на всяка друга основна маса.

* Ако не го направи, тогава стойността на оператора SELECT MIN (B_DATE) ... може да е NULL.След изчисляването на логически израз ние ще получи стойност uknown, което не е за забрана на стойността на ограничения за интегритет, и като резултат може да се предотврати с твърде стар служител.

* Това означава, че валидна стойност cand_pro_no външен ключ.

* Не приемайте това и следващите параграфи, както и описание на това как да всъщност тече тези заявки в SQL сървър.Това е най-простият и неефективен начин да се изпълни заявката (въпреки че по принцип може да се прилага на практика).Ние сме избрали този начин на описание, защото това е най-подходящият подход към описанието на SQL семантика прилага в стандартен език.Между другото, основната разлика между по-практични начини за изпълнение на заявките със съединение от желанието да се гарантира, за да се избегне изрично декартово произведение.

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

** Отново, ние трябва да го изпревари на себе си.SQL Инструменти за управление на операциите са разгледани по-подробно в следващите глави.

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

**** За някои целостта ограничения deferrable режим, няма смисъл.Такива ограничения включват, например, ограничения на домейни не нула ограничения и ограниченията на възможно ключ (въпреки че тяхното определение е позволено DEFFERABLE индикация).Ако е възможно ключ, използван в чужд ключ дефиниция, SQL стандарта изисква, че ограничението на възможно ключът не беше DEFFERABLE.

* В стандарта SQL в Merchant общ термин за обозначаване на такъв израз, израз на термина стойност.Въпреки това, в по-малко официални публикации обикновено се използват в по-разбираемо скаларна изразяване, за които, освен това, има достатъчно руски еквивалент на скаларна експресията.В това, разбира се, ние предпочитаме да използваме този термин.

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

* За набор от типа Т1, Т2, ..., Tn ще се нарича тип T-малкия общ за reducibility, ако стойностите на всеки от Т1, вида Т2, ..., TN имплицитно се редуцира до тип T, и няма тип Т ", така че стойностите на тип тип T1, T2, ..., TN имплицитно се редуцира до тип Т ", и на стойност от тип Т" имплицитно се редуцира с типа T.

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

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

*** A, B, ... C не се изисква да бъдат базовите таблици.Вижте. Следваща точка.

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

* Если говорить более точно, то в одной группе все строки, составленные из значений столбцов группировки, являются дубликатами.

* Обратите внимание, что в выражении элемента выборки не обязательно должно содержаться хотя бы одно имя столбца. Допускается наличие чисто контантного выражения, значение которого будет повторяться в данном столбце всех строк таблицы TF . Кроме того, заметим, что в соответствии с определением value_expression элемент списка выборки может быть запросом, возвращающим таблицу из одной строки с одним столбцом.

** Заметим, что любой элемент Z . a i этого неявно заданного списка может быть явно включен в список элементов выборки. Кстати, если в списке выборке присутствует явно или неявно заданный элемент вида Z . a , то в пределах запроса соответствующий столбец таблицы T4 получает то же имя.

* Мы снова проигнорируем спецификацию раздела collate, связанную с использованием национальных наборов символов.

* В связи с введением в стандарте SQL:2003 конструктора типов мультимножеств, в качестве элемента списка ссылок на таблицы раздела FROM теперь можно использовать и выражение со значением-мультимножеством. Однако в этом курсе мы не будем подробно рассматривать эту возможность.

* Мы использовали кавычки, поскольку таблицы, к которым применяются операции, в общем случае могут содержать строки-дубликаты, т.е. являться мультимножествами .

* Другими словами, при отсутствии спецификации CORRESPONDING требуется, чтобы заголовки таблиц-операндов совпадали за исключением, возможно, порядка следования столбцов.

** С учетом возможности неявного приведения типов.

* В следующей лекции мы более подробно обсудим подзапросы. Пока заметим, что row_subquery – это запрос, результирующая таблица которого состоит из одной строки.

* По крайней мере, так это следует понимать в соответствии с семантикой представлений в языке SQL. При реальной обработке запросов над представлениями такая явная “материализация” представления выполняется крайне редко. Вместо этого используется техника подстановки тела представления в тело запроса с гарантией того, что результат модифицированного запроса будет в точности таким же, что и результат исходного запроса над материализованным представлением. Но это уже относится к тематике оптимизации SQL-запросов, выходящей за пределы этого курса.

** Конструкция ALTER VIEW в языке SQL не поддерживается.

* Мы не обсуждаем в этом курсе предикаты, основанные на использовании выражений типа мультимножества, введенные в стандарте SQL:2003.

* Здесь снова идет речь о семантике выполнения оператора SELECT. В стандарте, естественно, не требуется, чтобы в реализации языка запросы с корреляционными подзапросами выполнялись в точности так, как описывается ниже. Суть в том, что какой бы реальный алгоритм выполнения такого запроса не использовался, результат выполнения должен быть точно таким же, как если бы запрос выполнялся по описываемой схеме.

* Кстати, в этом случае можно было бы обойтись введением одного псевдонима, оставив в качестве неявного второго псевдонима имя таблицы – EMP.

* Покажем это в развернутой форме. Пусть s текущая строка таблицы EMP, просматриваемой в цикле внешнего запроса, и пусть s .DEPT_NO содержит неопределенное значение. Тогда для строки s условие первого подзапроса будет иметь вид NULL = EMP1.DEPT_NO, и значением этого условия будет uknown для любой строки таблицы EMP (EMP1), просматриваемой в цикле этого подзапроса. Поскольку uknown не является разрешающим условием, результирующая таблица подзапроса будет пуста, и агрегатная функция AVG выдаст значение NULL. По этому поводу значением условия внешнего запроса будет uknown , и строка s не войдет в его результирующую таблицу.

* В стандарте SQL:1999 разрешается применять предикат LIKE только для битовых строк типа BLOB. Битовые строки типов BIT и BIT VARYING не допускаются.

* Мы не обсуждаем в этом курсе предикаты, основанные на использовании выражений типа мультимножества, введенные в стандарте SQL:2003.

* Здесь снова идет речь о семантике выполнения оператора SELECT. В стандарте, естественно, не требуется, чтобы в реализации языка запросы с корреляционными подзапросами выполнялись в точности так, как описывается ниже. Суть в том, что какой бы реальный алгоритм выполнения такого запроса не использовался, результат выполнения должен быть точно таким же, как если бы запрос выполнялся по описываемой схеме.

* Кстати, в этом случае можно было бы обойтись введением одного псевдонима, оставив в качестве неявного второго псевдонима имя таблицы – EMP.

* Покажем это в развернутой форме. Пусть s текущая строка таблицы EMP, просматриваемой в цикле внешнего запроса, и пусть s .DEPT_NO содержит неопределенное значение. Тогда для строки s условие первого подзапроса будет иметь вид NULL = EMP1.DEPT_NO, и значением этого условия будет uknown для любой строки таблицы EMP (EMP1), просматриваемой в цикле этого подзапроса. Поскольку uknown не является разрешающим условием, результирующая таблица подзапроса будет пуста, и агрегатная функция AVG выдаст значение NULL. По этому поводу значением условия внешнего запроса будет uknown , и строка s не войдет в его результирующую таблицу.

* В стандарте SQL:1999 разрешается применять предикат LIKE только для битовых строк типа BLOB. Битовые строки типов BIT и BIT VARYING не допускаются.

* Здесь мы прибегаем к компромиссу между реляционной терминологией и моделью данных SQL: конечно, в реляционной модели кортеж из неопределенных значений не может соответствовать заголовку отношения, поскольку NULL не является значением ни одного типа данных.

* Оба термина являются приемлемыми. Речь идет об агрегатных функциях , поскольку аргументом функции является агрегатное (составное) значение. Речь идет о функциях над множествами , поскольку аргументом функции является множество (в общем случае, мультимножество) значений. Но более правильно было бы говорить о групповых функциях, поскольку в большинстве случаев такие функции работают на значениях столбцов групп строк.

* Обратите внимание на то, что это еще один вид различения строк в SQL и еще одна скрытая интерпретация неопределенного значения. COUNT (*) работает так, как если бы выполнялось соотношение (NULL = NULL) º false . Тем самым, в SQL применяются все три возможные интерпретации NULL. При вычислении логических выражений полагается (NULL = NULL) º uknown ; при определении строк-дубликатов неявно считается, что (NULL = NULL) º true ; наконец, при вычислении агрегатной функции COUNT (*) неявно полагается, что (NULL = NULL) º false . Конечно, в такой “тройственности” нет ничего хорошего, но в контексте языка SQL приходится мириться с этим и другими негативными последствиями наличия неопределенных значений.

* Интересно, что для этого запроса возможна альтернативная формулировка с использованием операции CROSS JOIN: SELECT * FROM table1 CROSS JOIN table2. Может возникнуть естественный вопрос: зачем вводить специальную конструкцию для декартова произведения? По мнению автора, эта конструкция была введена, главным образом, для повышения уровня общности языка SQL. Кроме того, использование явного ключевого слова CROSS JOIN является подтверждением того, что пользователь действительно желает получить декартово произведение, а не опустил по ошибке раздел WHERE.

* Для удобства читателей напомним, что по определению выражение COALESCE (V1, V2) эквивалентно следующему выражению с переключателем: CASE WHEN V1 IS NOT NULL THEN V1 ELSE V2 END.

** Совпадают в строгом смысле, т.е. значение столбца table1.c совпадает со значением столбца table2.c тогда и только тогда, когда значение операции сравнения table1.c = table2.c является true.

* За очевидностью мы опустим пример CROSS JOIN.

* Конечно, предлагаемый русский вариант термина lateral слишком громоздок. По всей видимости, если этот механизм войдет в практику пользователей SQL, нужно будет использовать качестве термина что-то вроде латеральной порождаемой таблицы . Но здесь для нас главным является не обеспечение хорошей новой терминологии, а обеспечение понимания материала.

** Тем самым, ссылка на LD-таблицу не может быть первой в списке раздела FROM. Кстати, может возникнуть естественный вопрос: почему разрешаются ссылки только на таблицы, находящиеся в списке раздела FROM только слева LD-таблицы? Стандарт отвечает на этот вопрос весьма просто и бесхитростно. Если разрешить использовать ссылки, находящиеся и слева, и справа от спецификации ссылки на LD-таблицу, то это может привести к зацикливанию при выполнении раздела FROM. Поэтому нужно было выбирать одно из направлений, и было выбрано направление слева направо.

* Конечно, мы показали строки результирующей таблицы, расположенными в удобном для нас порядке только для упрощения объяснений. В действительности, строки результирующая таблицы (как обычно) будут расположены в порядке, определяемом системой. Чтобы добиться в точности такого порядка расположения строк, как это показано на рис. 16.1, к формулировке запроса из примера 16.1 нужно добавить раздел
ORDER BY DEPT_NO, EMP_BDATE.

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

* Мы не будем приводить полное определение таблицы, включающее требуемые ограничения целостности.

** Если в правой части элемента модификации присутствует value_expression, в котором содержится запрос, то в случае использования в этом запросе имен столбцов модифицируемой таблицы под значениями этих столбцов понимается значение до модификации.

* Обратите внимание, что формально эта формулировка не отвечает требованиям SQL/92 для спецификаций запросов, допускающих применение операций обновления. Но в действительности здесь вложенный подзапрос вычисляется в единственное значение при отсутствии какой-либо корреляции с внешним вхождением таблицы EMP.

* Множество, элементы которого невозможно различить, может быть либо пустым, либо содержать только один элемент.

** В этом случае таблица соответствует понятию мультимножества.

* Определение выражения COALESCE (V1, V2) см. в разд. 12.2 Лекции 12.

* Напомним из Лекции 13, что в соответствии с семантикой оператора выборки в результат раздела WHERE входят все строки результата раздела FROM, для которых результатом вычисления логического условия раздела WHERE является true .

* Напомним из Лекции 13, что на вход раздела HAVING подается результат раздела GROUP BY, если этот раздел присутствует в спецификации запроса, иначе – результат раздела WHERE, если этот раздел присутствует в спецификации запроса, иначе – результат раздела FROM.

* Будем считать, что тем, кто пользуется представлением MORE_RICH_EMP, неизвестно ограничение EMP_SAL < 20000.00, на котором основывается представление MIDDLE_RICH_EMP.

* Непонятно, откуда происходит это ограничение. Скорее всего, в будущих версиях стандарта оно будет снято.

** В примерах этой лекции мы будем считать, что в столбце DEPT_TOTAL_SAL таблицы DEPT хранится суммарное значение заработной платы служащих соответствующего отдела.

* Для читателей, которые имеют хотя бы минимальный опыт работы с продуктами компании Oracle, заметим, что во многих своих чертах SQL/PSM напоминает PL/SQL. Одной из причин, на основании которых мы отказались от описания SQL/PSM в этой книге, является то, что до сих пор (первый вариант стандарта SQL/PSM был опубликован в 1996 г.) нет ни одной реализации SQL, в которой этот стандарт был бы реализован полностью (точнее, ни одна такая реализация не известна автору).

* Во многом на этих возможностях основываются механизмы SQL:1999, предназначенные для определения на уровне пользователя новых типов данных и их операций. Эта тематика также выходит за пределы данной книги (хотя мы немного затронем соответствующие вопросы в последних лекциях этого курса).

** На самом деле, для написания процедур, функций и методов допускается использование не только языка SQL/PSM, но и традиционных языков программирования, для которых в стандарте определены правила связывания с SQL. В последних лекциях курса мы немного затронем и эту тему.

*** Для упрощения будем считать, что идентификаторы уволенных служащих не используются повторно.

* Помимо прочего, этот факт означает, что определение в базе данных нового триггера может привести к неработоспособности существующих приложений, разработчики которых, вообще говоря, могут даже и не знать о появлении нового триггера.

* Здесь мы опять честно пересказали стандарт SQL:1999. И снова предложенное решение выглядит простым, но не убедительным.

* Мы не будем приводить полное определение таблицы, включающее требуемые ограничения целостности.

** Если в правой части элемента модификации присутствует value_expression, в котором содержится запрос, то в случае использования в этом запросе имен столбцов модифицируемой таблицы под значениями этих столбцов понимается значение до модификации.

* Обратите внимание, что формально эта формулировка не отвечает требованиям SQL/92 для спецификаций запросов, допускающих применение операций обновления. Но в действительности здесь вложенный подзапрос вычисляется в единственное значение при отсутствии какой-либо корреляции с внешним вхождением таблицы EMP.

* Множество, элементы которого невозможно различить, может быть либо пустым, либо содержать только один элемент.

** В этом случае таблица соответствует понятию мультимножества.

* Определение выражения COALESCE (V1, V2) см. в разд. 12.2 Лекции 12.

* Напомним из Лекции 13, что в соответствии с семантикой оператора выборки в результат раздела WHERE входят все строки результата раздела FROM, для которых результатом вычисления логического условия раздела WHERE является true .

* Напомним из Лекции 13, что на вход раздела HAVING подается результат раздела GROUP BY, если этот раздел присутствует в спецификации запроса, иначе – результат раздела WHERE, если этот раздел присутствует в спецификации запроса, иначе – результат раздела FROM.

* Будем считать, что тем, кто пользуется представлением MORE_RICH_EMP, неизвестно ограничение EMP_SAL < 20000.00, на котором основывается представление MIDDLE_RICH_EMP.

* Непонятно, откуда происходит это ограничение. Скорее всего, в будущих версиях стандарта оно будет снято.

** В примерах этой лекции мы будем считать, что в столбце DEPT_TOTAL_SAL таблицы DEPT хранится суммарное значение заработной платы служащих соответствующего отдела.

* Для читателей, которые имеют хотя бы минимальный опыт работы с продуктами компании Oracle, заметим, что во многих своих чертах SQL/PSM напоминает PL/SQL. Одной из причин, на основании которых мы отказались от описания SQL/PSM в этой книге, является то, что до сих пор (первый вариант стандарта SQL/PSM был опубликован в 1996 г.) нет ни одной реализации SQL, в которой этот стандарт был бы реализован полностью (точнее, ни одна такая реализация не известна автору).

* Во многом на этих возможностях основываются механизмы SQL:1999, предназначенные для определения на уровне пользователя новых типов данных и их операций. Эта тематика также выходит за пределы данной книги (хотя мы немного затронем соответствующие вопросы в последних лекциях этого курса).

** На самом деле, для написания процедур, функций и методов допускается использование не только языка SQL/PSM, но и традиционных языков программирования, для которых в стандарте определены правила связывания с SQL. В последних лекциях курса мы немного затронем и эту тему.

*** Для упрощения будем считать, что идентификаторы уволенных служащих не используются повторно.

* Помимо прочего, этот факт означает, что определение в базе данных нового триггера может привести к неработоспособности существующих приложений, разработчики которых, вообще говоря, могут даже и не знать о появлении нового триггера.

* Здесь мы опять честно пересказали стандарт SQL:1999. И снова предложенное решение выглядит простым, но не убедительным.

* Напомним, что в этом курсе мы не касаемся вопросов интернационализации и локализации языка SQL.

* Как будет показано в следующем подразделе, термин роль в языке SQL полностью соответствует своему житейскому смыслу. И в мире баз данных люди большей частью играют чью-то роль, а не представляют себя лично.

* В соответствии со стандартом любые зарегистрированные в системе пользователь или роль автоматически являются владельцами части схемы базы данных, имена объектов которой начинаются с соответствующего идентификатора, за которым следует символ “.”.

* Для каждого объекта базы данных и для каждого пользователя, обладающего какими-либо привилегиями доступа к этому объекту, требуется хранить список его привилегий. Если учесть еще и возможность передачи привилегий от одного пользователя к другому, то образуется произвольно сложный граф, за которым трудно следить администраторам базы данных.

* Чтобы хотя бы немного облегчить чтение данного подраздела, забегая вперед, заметим, что понятия сессии и подключения относятся к сеансу работы клиентского приложения с некоторым сервером SQL-ориентированной базы данных.

* Кстати, это один из тех случаев, когда иметь право не означает автоматически иметь возможность реализации своего права. SQL допускает, например, наличие привилегии INSERT для представления, к которому операция INSERT не применима.

* Кстати, стандарт полностью отдает на волю реализации способ того, каким образом сделать неопределенным значение текущего пользовательского идентификатора SQL-сессии.

* В действительности, как видно из приведенных описаний, варианты операторов GRANT и REVOKE для привилегий и ролей настолько близки, что непонятно их синтаксическое разделение, которое, очевидно, усложняет реализацию. Как кажется, это разделение не обосновано в стандарте SQL:1999.

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

*** Читателей может смутить параллельное использование терминов согласованность и целостность. С точки зрения автора этого курса, в контексте баз данных эти два термина эквивалентны. Единственным критерием согласованности данных является их удовлетворение ограничениям целостности, т.е. база данных находится в согласованном состоянии тогда и только тогда, когда она находится в целостном состоянии.

**** Здесь мы опять сталкиваемся с терминологической трудностью, существующей уже много лет. В англоязычной терминологии имеется замечательный термин concurrent , который соответствует как реально параллельному, так и квазипараллельному выполнению транзакций (или процессов). Русский эквивалент одновременный не совсем точно соответствует смыслу оригинала, но лучшего варианта пока нет.

* Правильнее было бы говорить SQL-транзакции , но в этом курсе мы не обсуждаем другие модели транзакций и поэтому будем использовать термин транзакция в смысле SQL-транзакция.

** В русской терминологии для краткой характеристики этого действия часто используется не очень элегантный, но точно отражающий суть происходящего термин откат транзакции.

* В этом курсе мы не будем более подробно обсуждать способы получения и обработки диагностических сообщений, поскольку это потребовало бы привлечения слишком большого числа технических деталей, не слишком существенных для общего понимания языка.

* В действительности, этот подход был введен еще в проекте System R.

<== Предишна лекция | На следващата лекция ==>
| Лекции Теоретичен курс

; Дата: 03.01.2014;; Прегледи: 197; Нарушаването на авторските права?;


Ние ценим Вашето мнение!Беше ли полезна публикуван материал?Да |не



ТЪРСЕНЕ:


Вижте също:

  1. ЗНАЧЕНИЕ И ОСНОВНИ ЦЕЛИ НА УЧЕБНАТА
  2. В процеса на психологията курсове за обучение
  3. Vivchennya че konspektuvannya Jerel ите obranoї тези,
  4. Въпрос 1. Предмет и обект на дисциплината в дисциплините на икономическата система
  5. Въпрос 2. Методологически основи и основни понятия на курса
  6. Въпроси по физика за 3 курса VGKS
  7. Следваща Иларионов Разбира се прекъсва и някои от лекциите записани за KASkvorchevskim.
  8. движение на обменните курсове се отразява в стойността на собствените си средства и не се променя стойността на кредита.
  9. Цели на курса, неговата структура.
  10. Стойността на курса "Modern научна картина на света" за качеството на бакалавърска
  11. За проучване на темата и да направи кратко резюме на списъка с въпроси, на страница 4.
  12. История на държавата и правото на чужди държави в системата на законодателството и целите на политиката.Характеристики на учебна литература




ailback.ru - Edu Doc (2013 - 2017) на година.Тя не е автор на материали, и дава на студентите с безплатно образование и използва!Най-новото допълнение , Al IP: 11.45.9.24
Page генерирана за: 0.146 сек.