ПЕРЕВАГИ справжність ЗБЛИЖЕННЯ ТЕХНОЛОГІЙ

В [2641] Стоунбрейкер (Stonebraker) представив матрицю класифікації для СУБД (рис 264) Квадрант 1 цієї матриці представляє додатки, в яких застосовуються тільки відносно прості дані і не предявляються вимоги щодо виконання довільних запитів (хорошим прикладом подібного програми може служити звичайний текстовий процесор) Такі додатки насправді взагалі не можна назвати додатками бази даних у звичайному розумінні цього терміна так сказати,

Рис 264 Матриця класифікації СУБД, запропонована Стоунбрейкер

“СУБД, яка найкраще обслуговує їхні потреби, являє собою просто вбудований диспетчер файлів, що надається в складі базової операційної системи

У квадранті 2 представлені програми, в яких предявляються вимоги щодо виконання довільних запитів, але використовуються все ще відносно прості дані У цей квадрант потрапляє більшість сучасних виробничих додатків, і ці програми цілком успішно підтримуються традиційними реляційними СУБД (або, принаймні, системами SQL)

У квадранті 3 представлені програми, в яких потрібні складні дані і алгоритми обробки, але немає необхідності у використанні довільних запитів Наприклад, до цього квадранту можуть ставитися додатки систем автоматизованого проектування і виробництва Сучасні обєктні СУБД в основному призначені для використання в цьому сегменті ринку (традиційні програмні продукти

SQL, як правило, погано підходять для додатків, які відносяться до квадранту 3)

Нарешті, в квадранті 4 представлені програми, для яких потрібні одночасно і складні дані, і довільні запити до цих даних Стоунбрейкер наводить приклад бази даних, яка містить оцифровані 35-міліметрові слайди, в якої типовий запит виглядає так: Знайти знімки сонячних заходів сонця, отримані в 20 милях від Сакраменто, штат Каліфорнія. Потім він наводить аргументи на підтримку

своєї позиції, згідно з якою, по-перше, для додатків, що відносяться до цього квадранту, потрібно обєктно-реляційна СУБД, і, по-друге, протягом найближчих декількох років більшість нових додатків буде ставитися до цього квадранту, а більшість старих додатків до нього перейде Наприклад, може знадобитися доопрацювати навіть прості програми для відділу кадрів, щоб передбачити використання в них фотографій службовців, звукозаписів (мовних повідомлень) і тому подібних даних

Зрештою Стоунбрейкер стверджує (з чим автор повністю згоден), що обєктно-реляційні системи в майбутньому торкнуться буквально кожного; їх не можна розглядати просто як модне захоплення, яке незабаром зміниться якийсь інший темою, що оволоділа на час увагою публіки Але автор повинен нагадати, що якщо справа стосується фахівців в області баз даних, то справжня обєктно-реляційна система – це не більше і не менше, ніж справжня реляційна система Зокрема, це – така система, в якій немає слідів жодного з двох серйозних помилок Мабуть, Стоунбрейкер неповністю погоджується з викладеною тут позицією автора принаймні, в [2641] не виражена явно її підтримка і фактично з

сказаного в цій роботі слід, що змішування покажчиків і відносин не тільки прийнятно, а й бажано (і, насправді, нібито навіть потрібно)

Як би то не було, автор цієї книги стверджує, що справжня обектнореляціонная система дозволить вирішити всі ті проблеми, які (як було зазначено в попередньому розділі) насправді виникають через недоліків таких систем, які

є лише чисто обєктними системами, а не обєктно-реляційними Для уточнення цієї позиції зазначимо, що така система повинна мати здатність підтримувати всі описані нижче вимоги без особливих складнощів

■ Довільні запити, визначення уявлень і декларативні ограниче ня цілісності

■ Методи, які охоплюють цілі класи (тобто не вимагають помітних цільових фактичних параметрів)

■ Динамічно визначаються класи (для результатів довільних запитів)

■ Дворежимний доступ (див главу 4 ця думка в главі 25 не підкреслює, але обєктні системи зазвичай не підтримують принцип дворежимним – замість цього в них використовуються різні мови для програмованого та інтерактивного доступу до бази даних)

■ Перехідні обмеження

■ Семантична оптимізація

■ Звязки зі ступенем більше двох

■ Правила зовнішніх ключів (ON DELETE CASCADE І ТД)

■ Оптимизируемого

•I

Можна також назвати й інші вимоги Крім того, можна навести викладені нижче міркування на користь позиції автора

■ Ідентифікатори обєктів і ланцюжки покажчиків тепер повністю включені в реалізацію і приховані від користувача

■ Усуваються складні обєктні проблеми (наприклад, не доводиться шукати відповідь на питання про те, що мається на увазі під зєднанням двох обєктів)

Переваги інкапсуляції як такі все ще зберігаються, але поширеною] няются на скалярні значення у відносинах, а не на самі відносини

■ Як було зазначено вище, реляційні системи тепер здатні підтримувати такі складні прикладні області, як системи автоматизованого проек тирования і виробництва

Крім того, пропонований підхід цілком обгрунтований теоретично

263СРЕДСТВА SQL

Найбільш очевидні і істотні відмінності між специфікацією SQL: 1999 і попередньої їй специфікацією SQL: 1992 полягають у тому, що в новій специфікації розглядаються обєктно-реляційні кошти Багато з цих коштів, які коротко перераховані нижче, були вже описані і проаналізовані в попередніх розділах

■ У розділі 5 було показано, що мова SQL підтримує дві різні категорії визна ділячи користувачем типів, типи DISTINCT та структуровані типи Обидві ці різновиди можуть використовуватися (Крім усього іншого) як основи для визначення стовпців у базових таблицях

■ У главі 6 було показано, що в мові SQL спеціально передбачена можливість використовувати структуровані типи в якості основи для визначення струк тур, які в специфікації SQL: 1999 були названі типізований таблиця ми (typed table)

■ У главі 20 було відзначено, що в мові SQL підтримується також певна форма успадкування типів, хоча і тільки для структурованих типів

Але крім цих коштів, у мові SQL підтримуються також, по-перше, генератор типу RE 7, і, по-друге, підтаблиці і супертабліци Відзначимо також, що ці додаткові конструкції в дуже значній мірою повязані з уже зазначеними (особливо зі структурованими типами) Хоча і не зовсім ясно, чому вони повинні були бути настільки звязаними (в принципі, поняття, що лежать в їх основі, повністю ортогональні), але, можливо, все одно це не має великого значення, оскільки, на думку автора, зазначені на початку цього абзацу додаткові конструкції взагалі не дуже-то потрібні, як буде показано нижче

Типи REF

Почнемо з простого прикладу (непотрібні подробиці тут не показані)

CREATE TYPE DEPT_TYPE AS ( DEPT#  CHAR(3),

DNAME  CHAR(25), BUDGET MONEY ) ..

REF IS SYSTEM GENERATED

CREATE TABLE DEPT OF DEPT_TYPE

( REF IS DEPT_ID SYSTEM GENERATED, PRIMARY KEY ( DEPT# ) ) ..

Пояснення (частково тут повторюється матеріал, наведений у главі 6)

1 Спочатку нагадаємо, що (як було сказано в розділі 5) при створенні кожного структурованого типу ST система автоматично формує відповідний контрольний тип (тип REF ), званий REF (ST), тому в даному прикладі автоматично формується контрольний тип REF (DEPT_TYPE) Типи REF можуть використовуватися скрізь, де допустимо застосування типу даних будь-якого роду але вони можуть формуватися тільки неявно в якості побічного ефекту створення структурованого типу

7 Ключове слово REF є скороченням від reference (посилання), але типи REF не мають нічого спільного ні з привілеями REFERENCES (див главу 17), ні з тими посиланнями, під якими маються на увазі зовнішні ключі До речі, слід зазначити, що типи REF є скалярними, тому генератор типу REF являє собою приклад генератора скалярного типу

2 Значення типу REF (ST) являють собою посилання на рядки (іншими словами, покажчики на рядки або адреси рядків) в деякій базовій табліце8, яка була визначена (за допомогою ключового слова OF) як відноситься до типу ST (див п 4) Тому в даному прикладі значення типу REF (DEPT_TYPE) представляють собою покажчики на рядки в базовій таблиці DEPT (Тут передбачається, що DEPT – це єдина таблиця, яка визначена за допомогою ключового слова OF як відноситься до типу DEPT_TYPE, хоча це припущення не завжди буде дей ствительность)

Примітка Структурований тип ST, зрозуміло, може використовуватися і в інших контекстах (наприклад, в якості оголошеного типу для деякого шпальти або деякої локальної змінної), але з цими іншими галузями застосування не асоціюється значення REF (ST)

3 Специфікація REF IS SYSTEM GENERATED в реченні CREATE TYPE ука зивает, що значення відповідного типу REF надаються системою (Є й інші опції, наприклад, REF IS USER GENERATED, але відомості про них виходять за рамки даної книги)

Примітка Насправді, опція REF IS SYSTEM GENERATED застосовується за умовчанням тому в даному прикладі можна було б повністю виключити цю специфікацію з визначення тіпаОЕРТ_ТУРЕ

4 Базова таблиця може бути визначена (у пропозиції CREATE TABLE) як відноситься до деякого структурованого типу за допомогою ключового слова OF; така таблиця називається типізованої таблицею (Typed table) або що вказується в посиланнях таблицею (Referenceable table) Але насправді ключове слово OF в даному випадку не зовсім підходить, оскільки (як описано в розділі 6) дана таблиця фактично не відноситься до розглянутого типу (що зазвичай висловлює прийменник of) до цього типу не відносяться і її рядки Насправді в цій таблиці передбачено по одному стовпцю для кожного атрибута розглянутого структурованого типу, а також один дополнитель ний стовпець (а саме, стовпець застосовного типу REF), хоча синтаксис для оп ределения даного додаткового стовпця чи не нагадує звичайний синтаксис визначення стовпця, а замість цього виглядає приблизно так

REF IS  &ltcolumn name&gt  SYSTEM GENERATED

Цей зайвий посилається на самого себе стовпець з імям &ltcolumn  name&gt, який є першим в упорядкуванні стовпців таблиці зліва направо, використовується для зберігання унікальних ідентифікаторів (Посилань) на рядки розглянутої базової таблиці (з цього випливає також, що він має специфікації UNIQUE і NOT NULL) Ідентифікатор для даної конкретної рядки

8 Або, можливо, в деякому поданні Опис того випадку, коли значення типу REF посилаються на рядки подання, виходить за рамки даної книги

присвоюється під час вставки цього рядка і залишається повязаним зі строкой9 доти, поки вона не буде видалена

5 Структурований тип, при її використанні як основи для визначен ня базової таблиці, не розглядається як інкапсульований (хоча він більшою чи меншою мірою і розглядається як такої в інших контек стах) Тому в даному прикладі базова таблиця DEPT має чотири стовпці, DEPT_ID, DEPT #, DNAME і BUDGET (у зазначеному порядку), а не просто два, як було б у тому випадку, якщо б тип DEPT_TYPE був інкапсульованим

6 Значним, застосовуваним за замовчуванням для стовпця DEPT_ID, є NULL (як фактично і передбачено для всіх стовпців, які визначені як від носяться до деякого типу REF, хоча це задане за замовчуванням значення в основному втрачає сенс, якщо для розглянутого стовпця додатково задана специфікація NOT NULL)

Тепер доповнимо розглянутий приклад, щоб ввести в нього базову таблицю ОМР,

наступним образом10

CREATE TABLE EMP

(ОМР # CHAR (5) NOT NOLL, ENAME CHAR (25) NOT NOLL, SALARY MONEY

NOT NOLL, DEPT_ID REF ( DEPT_TYPE )

SCOPE DEPT REFERENCES ARE CHECKED ON DELETE CASCADE

NOT

NOLL, PRIMARY KEY ( EMP# )

)

За звичайних умов базова таблиця ОМР включала б стовпець зовнішнього ключа DEPT #, який посилався б на відділи за допомогою номерів відділів Але тут мається довідковий стовпець DEPT_ID (причому заслуговує на увагу те, що він не позначений явно саме як стовпець зовнішнього ключа), який замість цього вказує на відділи за допомогою посилань на рядки з даними про ці відділах В опції SCOPE DEPT задана відповідна згадувана в посиланнях таблиця Специфікація REFERENCES ARE CHECKED означає, що повинна підтримуватися посилальна цілісність (При використанні опції REFERENCES ARE NOT CHECKED зявилася б можливість створення завислих посилань,тому незрозуміло, навіщо взагалі могло б знадобитися задавати опцію NOT CHECKED) 11 Конструкція ON DELETE вказує правило видалення,

9 На перший погляд може навіть здатися, що тут виникає якась циклічність: вираз ця рядок може означати тільки рядок, яка має даний конкретний розглянутий ідентифікатор . Зокрема, зверніть увагу на плутанину між значенням і змінної Якщо цей рядок повинна мати адресу, то ця рядок повинна і бути змінної рядка (див розділ 263)

10 Зверніть увагу на специфікації NOT NOLL в стовпцях таблиці ОМР Вказати, що в таблиці DEPT також не дозволено мати стовпці, що містять невизначені значення, не так вже просто Аналіз додаткових відомостей з цього питання залишаємо читачеві як вправа

1 І проте, велика ймовірність того, що в остаточній редакції стандарту SQL: 2003 спе цифікації REFERENCES буде вилучена з цього випливає, що (за замовчуванням) завжди буде задана ОПЦІЯ REFERENCES  ARE  NOT  CHECKED

аналогічне звичайними правилами видалення зовнішнього ключа (підтримуються такі ж опції) Аналогічна специфікація ON UPDATE не передбачена

Використання посилань

Тепер розглянемо декілька прикладів запитів і оновлень стосовно до щойно оголошеної базі даних відділів і службовців Спочатку розглянемо наведену нижче формулювання на мові SQL: Визначити номер відділу служащегоЕ1 .

SELECT DEPT_ID -&gt DEPT# AS DEPT# FROM EMP

WHERE EMP# = El

Зверніть увагу на оператор разадресаціі12 -> в конструкції SELECT (вираз DEPT_ID -> DEPT # витягує значення DEPT # з рядка DEPT, на яку вказує розглядається значення DEPT_ID) Зверніть також увагу на необхідність задавати конструкцію AS якби ця конструкція була опущена, то відповідний стовпець результату по суті залишився б безіменним Нарешті, слід зазначити, що суперечить здоровому глузду характер конструкції FROM – значення DEPT #, підмет вибірці, надходить з таблиці DEPT, а не ОМР, а значення DEPT_ID надходять з таблиці ОМР, а не DEPT

До речі, важко подолати спокусу і не відзначити, що продуктивність цього першого запиту, швидше за все, буде нижче в порівнянні з його аналогом, сформульованим за допомогою звичайних засобів SQL (який звертався б тільки до однієї таблиці, а не до двох) Автор навів це зауваження тому, що зазвичай на користь посилань наводять такий аргумент, нібито вони сприяють підвищенню продуктивності (що слідуючи за вказівником, якнайшвидше отримати дані, ніж виконуючи зєднання) Безумовно, недоліком подібних доводів є і те, що в них переплутані логічні і фізичні проблеми

В якості другого прикладу припустимо, що початковий запит був сформульований наступним чином: Визначити відділ (а не просто номер відділу) службовця Е1.

Тепер операція разадресаціі виглядає зовсім інакше, як показано нижче

SELECT DEREF ( DEPT_ID ) AS DEPT FROM EMP

WHERE EMP# = El

Більше того, в даному випадку виклик оператора DEREF призводить до отримання чи не значення рядка DEPT (як можна було б очікувати), а, натомість, до отримання инкапсулированного (Скалярного) значення Це значення відноситься до типу DEPT_TYPE І тому

12 У більшості мов, в яких підтримується разадресація (dereferencing), підтримується також оператор адресації (див, наприклад, опис оператора PTR_TO а розділі 263), але в мові SQL така підтримка не передбачена Більш того, зазвичай в результаті разадресаціі повертається змінна, але в мові SQL відповідна операція замість цього повертає значення

має тільки три атрибути, DEPT #, DNAME І BUDGET (ВПЗ не включає атрибут

DEPT_ID)13

Примітка Повторюючи зауваження, зроблене в главі 6, відзначимо, що якщо оголошеним типом деякого формального параметра Р деякого оператора Ор є DEPT_TYPE, то не можна передавати рядок з таблиці DEPT в якості відповідного фактичного параметра у виклику цього оператора Ор Але тепер очевидно, що замість цього можна передавати результат вираження DEREF (DEPT_ID), якщо DEPT_ID містить посилання на рядок таблиці DEPT

Нижче наведено ще один приклад запиту: Визначити номери службовців відділу

D1&quot.

SELECT EMP# FROM EMP

WHERE DEPT_ID -&gt DEPT# = Dl

Зверніть увагу на використання в даному прикладі разадресаціі в конструкції WHERE Тепер розглянемо наступний приклад пропозиції INSERT (вставка даних про службовця)

INSERT INTO EMP (ОМР #, DEPT_ID)

VALUES ( E5, ( SELECT DEPT_ID FROM DEPT WHERE DEPT# = D2

) )

Відзначимо, що прихильники аналізованих конструкцій (типів REF і тд) підкреслюють таку думку, ніби не про що турбуватися, оскільки всі ці конструкції фактично є просто скороченнями. Наприклад, вони стверджують, що вираз SQL

SELECT DEPT_ID -&gt DEPT# AS DEPT# FROM EMP

WHERE EMP# = El

(Визначити номер відділу службовця Е1; перший із прикладів, розглянутих в даному підрозділі) є скороченим позначенням для наведеного нижче пропозиції

SELECT ( SELECT DEPT# FROM DEPT

WHERE DEPTDEPT_ID = EMPDEPT_ID ) AS DEPT# FROM EMP WHERE EMP# = El

Але в дійсності твердження про те, що це – скорочення, не витримує ніякої критики, оскільки застосовуваний тут новий синтаксис (зокрема, для разадресаціі) може використовуватися тільки в поєднанні з даними, які були визначені з

13 З семантики оператора DEREF випливає, що в системі необхідно також зберігати інформацію про те, що стовпці DEPT #, DNAME і BUDGET таблиці DEPT походять від структурованого типу DEPT_TYPE (хоча для більшості призначень вони можуть розглядатися просто як звичайні стовпці) Іншими словами, використовую термінологію типів і заголовків з глави 6, можна стверджувати, що таблиця DEPT має заголовок (І тому тип) з чотирма компонентами в одних контекстах, але приймає заголовок (і тому тип) тільки з двома компонентами в інших Можливо, типізовані таблиці краще було б назвати таблицями з роздвоєнням особистості?

допомогою спеціального нового способу, з використанням нібито принципово нового генератора типу (REF) Крім того, в цих визначеннях даних широко застосовується також новий синтаксис До того ж, що розглядаються функціональні можливості надаються найвищою мірою в неортогональні формі (крім усього іншого, вони поширюються тільки на ті таблиці, які визначені за допомогою даного спеціального нового способу, а не на всі таблиці)

Більше того, навіть якщо вважати правильним твердження про те, що це – скорочення,

залишається без відповіді питання, для чого взагалі потрібні такі скорочення Яка проблема намічена для вирішення з їх допомогою Чому відповідна підтримка є такою неортогональні За яких умов ми повинні використовувати старомодний спосіб, а за яких – цей дивний новий спосіб І це – далеко не вичерпний список питань

Примітка У цьому звязку див [2615] і анотацію до [2621]

Підтаблиці і супертабліци

У мові SQL дозволено визначати базову таблицю в як підтаблицю базової таблиці А, тільки якщо в і А обидві є типізований таблицями, а структурований тип STB, за допомогою якого визначена таблиця в, є підтипом структурованого типу STA, за допомогою якого визначена таблиця А Як приклад розглянемо такі визначення структурованих типів

CREATE TYPE EMP_TYPE / * службовці

* / AS (ОМР # .., DEPT # ..) REF IS SYSTEM GENERATED

CREATE TYPE PGMR_TYPE UNDER EMP_TYPE /*

програмісти * / AS (LANG ..)

Зверніть увагу на те, що в пропозиції PGMR_TYPE немає конструкції REF IS .; замість цього даний тип фактично успадковує зазначену конструкцію від свого безпосереднього (Прямого) супертіпа EMP_TYPE Іншими словами, значення типу REF (EMP_TYPE) тепер може посилатися на рядок у таблиці, яка визначена як відноситься до типу PGMR_TYPE, а не До типу ЕМР_ТУРЕ

Тепер розглянемо наведені нижче визначення базової таблиці

CREATE TABLE EMP OF EMP_TYPE

( REF IS EMP_ID SYSTEM GENERATED, PRIMARY KEY ( EMP# ) ) ..

CREATE TABLE PGMR OF PGMR_TYPE UNDER EMP

Тут заслуговує на увагу специфікація UNDER EMP після визначення базової таблиці PGMR (слід зазначити також відсутність специфікацій REF is і PRIMARY KEY для цієї базової таблиці) Базові таблиці PGMR і ОМР називаються, відповідно, підтаблицях і відноситься до неї безпосередній (Прямий) супертабліцей в таблиці PGMR успадковані стовпці (і тд) від ОМР і введений один власний додатковий стовпець LANG На інтуїтивному рівні цей приклад можна зрозуміти таким чином, що для службовців, які не є програмістами, передбачено рядок тільки в таблиці ОМР, а для програмістів є рядки в обох таблицях, тому кожна рядок

в таблиці PGMR має свій аналог в таблиці ОМР, але зворотне твердження не є істинним

Операції маніпулювання даними в цих таблицях здійснюються, як описано нижче

■ Операція SELECT Вибірка даних за допомогою операції SELECT з таблиці ОМР здійснюється звичайним чином Операція SELECT на таблиці PGMR виконува ється так, як якби PGMR фактично містила стовпчики таблиці ОМР, а також стовпець LANG

■ Операція INSERT Операція вставки даних за допомогою оператора INSERT в таб особі ОМР здійснюється звичайним чином Виконання операції INSERT з таб ліцей PGMR фактично призводить до появи нових рядків і в таблиці ОМР, і в таблиці PGMR

■ Операція DELETE Виконання операції DELETE з таблицею ОМР тягне за собою зникнення рядків з таблиці ОМР, а також (якщо виявилося, що рассматривае мие рядки відносяться до програмістам) з таблиці PGMR Видалення даних з по потужністю оператора DELETE з таблиці PGMR викликає зникнення рядків і з таблиці ОМР, і з таблиці PGMR

■ Операція UPDATE Оновлення атрибута LANG, яке повинно здійснюватися обовязково через таблицю PGMR, призводить до оновлення лише таблиці PGMR оновлення інших стовпців (в принципі) призводить до оновлення обох таблиць, незалежно від того, чи здійснюється воно за допомогою або таблиці ОМР, або таблиці PGMR

Зокрема, слід зазначити, що з цього аналізу операцій маніпулювання даними слідують наведені нижче висновки

■ Припустимо, що деякий існуючий службовець Джо став программи стом Якщо ми просто спробуємо вставити рядок з даними про Джо в таблицю PGMR, то система спробує вставити рядок, що стосується Джо, також і в табли цу ОМР, але така спроба, безумовно, закінчиться невдачею Замість цього не обхідно видалити рядок Джо з таблиці ОМР, а потім вставити відповідний рядок у таблицю PGMR

■ Навпаки, припустимо, що деякий існуючий службовець Джо перестав бути програмістом На цей раз необхідно видалити рядок Джо або з ОМР, або з PGMR (яка б таблиця ні була задана, в кінцевому підсумку відбувається уда ня з обох таблиць), а потім вставити відповідний рядок у таблицю ОМР

До речі, слід зазначити, що в мові SQL передбачено засіб ONLY, яке дійсно дозволяє проводити маніпуляції тільки з такими рядками даної конкретної таблиці, які не мають аналогів в якій-небудь підтаблицях цієї таблиці Наприклад, вираз SELECT * FROM ONLY (ОМР) дозволяє здійснити вибірку тільки тих рядків таблиці ОМР, які не мають аналогів в таблиці PGMR аналогічним чином, за допомогою виразу DELETE FROM ONLY (ОМР) можна видалити тільки ті рядки ОМР, які не мають аналогів в PGMR, і подібна конструкція може застосовуватися в поєднанні з оператором UPDATE (версія оператора INSERT з ключовим

словом ONLY не передбачена) Але заслуговує уваги те, що цей засіб ONLY не може допомогти у вирішенні проблем, описаних вище, коли доводиться оновлювати базу даних з урахуванням того, що деякий існуючий службовець Джо став програмістом або перестав ним бути

Отже, що спільного мають тільки що описані підтаблиці і супертабліци з істинним спадкуванням типів Наскільки ми можемо судити, відповіддю є – НІЧОГО Таблиці – це не типи Безумовно, тут і мови не може бути про якусь заменяемости, а в главі 20 було показано, що якщо заменяемость не передбачена, то немає і справжнього успадкування типів Тому, якщо навіть припустити, що підтаблиці і супертабліци здатні надати будь корисні засоби, все одно не зовсім зрозуміло, чому мова SQL повинен вимагати, щоб для отримання доступу до цих засобів розглядаються підтаблиці і їхні безпосередні (Прямі) супертабліци були оголошені в термінах типів, які є, відповідно, підтипом і його безпосереднім (Прямим) супертіп

Більш фундаментальне питання полягає в тому, які ж тут можливі позитивні кошти Чим можуть нас підкупити підтаблиці і супертабліци Мабуть, відповідь полягає в тому, що користі від них дуже мало , принаймні, на рівні моделі14 Вірно те, що може бути досягнута деяка економія в реалізації, якщо підтаблиця та її супертабліца фізично зберігаються на диску у вигляді однієї таблиці, але, безумовно, не можна допускати, щоб подібні міркування надавали хоч який-небудь вплив на саму модель як таку Іншими словами, як було зазначено в попередньому абзаці, не тільки не ясно, чому Під- і супер- таблиці повинні створюватися на основі структурованих під- і супер- типів, але також абсолютно не зрозуміло, для чого взагалі повинно підтримуватися цей засіб

Мова SQL і два серйозних омани

Отже, чи дозволяють описані вище функціональні засоби SQL досягти важливої ​​мети – надання якісної обєктно-реляційної підтримки Насамперед, якщо навіть у мові SQL не повною мірою виявляються два серйозні омани, безумовно, в ньому виявляються досить помітні їх ознаки І як вже було сказано, причини такого стану справ не зовсім зрозумілі, принаймні, автору даної книги мабуть, в основному вони слідують лише з смутного уявлення, що вказані кошти, які є наслідком неподоланих серйозних помилок, повинні в якійсь мірі дозволити мови SQL стати більш схожим на обєктний (Та, мабуть, ці кошти саме й сприяють досягненню саме цієї мети)

Що стосується першого серйозного омани, то створюється враження, що ідея привязки типізованих таблиць до структурованих типам має певне відношення до ідеї прирівнювання таблиць і класів Точніше, видається цілком імовірним, що якщо типизированная таблиця тт визначена за допомогою ключового слова OF як відноситься до структурованого типу ST, то передбачається, що тт повинна містити те, що іноді називають Екстенти типу ST (під цим мається на увазі безліч

14 Можна було б припустити, що відповідь на це питання має щось спільне з проблемою підтипів і супертіпа сутностей, які розглядалися в розділі 14 Але в цьому звязку автор хотів би відзначити, що для вирішення і цієї проблеми він вважає за краще використовувати підхід, заснований на застосуванні уявлень Див приклад в самому кінці розділу 145

всіх існуючих в даний час примірників типу ST) 15 Якщо справа йде інакше,

то для чого потрібна тісний звязок між TT і ST

Якщо це дійсно так, то знову виникають деякі проблеми Одна з них полягає в тому, що не виключена можливість мати дві або кілька типізованих таблиць одного і того ж структурованого типу які наслідки спричинить таке рішення, не зовсім ясно (якщо не рахувати того, що в число цих наслідків майже напевно буде входити порушення принципу ортогонального проектування) Інші проблеми описані в розділі 66

Що стосується другого серйозного омани, то має бути очевидно, що мова

SQL страждає від цього (дуже важливого) Дефекту, навіть якщо допустити, що застосовувані в ньому посилання і повязані з ними засоби є, як стверджують деякі, фактично просто скороченнями Як було зазначено вище, якщо рядки можуть матипосилання

(Адреси), то ці рядки з визначення є змінними рядків Зокрема, мова

SQL страждає від проблеми, описаної в підрозділі Несумісність покажчиків і якісної моделі успадкування розділу 263 Тут докладні відомості по цій темі не наведені, оскільки вони є досить складними досить сказати, що значення REF, яке імовірно повинно посилатися на рядок, що описує окружність, може фактично посилатися натомість на рядок, що містить еліпс, відмінний від кола

264 РЕЗЮМЕ

У цій главі коротко розглядалася проблемна область обєктно-реляційних систем Такі системи є (або повинні бути), по суті, просто реляційними системами, які належним чином підтримують реляционное поняття доменів (тобто типів) Іншими словами, обєктно-реляційні системи – це справді реляційні системи, відмітною особливістю яких є те, що вони дозволяють користувачам визначати їх власні типи Реляційна модель не вимагає ніяких доповнень для досягнення обєктно-реляційних функціональних можливостей достатньо лише повністю її реалізувати

Потім у цій главі розглядалися два серйозні омани Перше з них полягає в тому, що проводиться знак рівності між класами обєктів і змінними відносини (на жаль, це рівняння все ж занадто привабливо, принаймні, якщо не проводиться його глибокий аналіз) Автор зробив припущення, що джерелом цієї омани стає плутанина між двома абсолютно різними інтерпретаціями терміна обєкт Було детально описано, як може виглядати система, в якій виявляються сліди першого серйозного омани, і показані деякі наслідки цієї помилки Одним з важливих наслідків, мабуть, є те, що

перший оману призводить безпосередньо до виникнення також другого серйозного омани Воно полягає саме в змішуванні покажчиків і відносин (хоча фактично друга оману може проявлятися і без першого, і, на жаль, його сліди можна виявити майже в будь-якій системі, представленої на ринку) На думку автора, друга серйозна помилка в чому підриває концептуальну

15 Але цей екстент не супроводжується автоматично замість цього екземпляри типу ST зявляються в таблиці ТТ і зникають з неї тільки в результаті виконання явних операцій оновлення на цій таблиці

цілісність реляційної моделі (фактично так само, як і перше) Зокрема, в результаті нього порушуються і інформаційний принцип, і принцип взаємозамінності (базових і похідних відносин)

Після цього були коротко розглянуті деякі проблеми реалізації При цьому найбільш важлива думка полягала в тому, що введення нового пакета типівнадає

вплив, щонайменше, на такі компоненти системи, як компілятор, оптимізатор і диспетчер памяті Внаслідок цього обєктно-реляційна система не може бути реалізована (принаймні, досить якісно) просто шляхом накладення

нового рівня коду {Оболонки) на існуючу реляционную систему замість цього система має бути перебудована, починаючи від самого заснування, для того, щоб кожен її компонент став розширюваним індивідуально в міру необхідності

Надалі в цьому розділі розглядалася матриця класифікації СУБД Стоунбрейкера і були коротко описані переваги, які можуть бути досягнуті завдяки істинному зближенню між обєктної і реляційної технологіями (тут під

словом щире, крім усього іншого, мається на увазі, що розглянута система не повинна носити сліди жодного з двох серйозних помилок) Нарешті, проаналізована передбачена в мові SQL підтримка типів REF, а також підтаблиць і супертабліц

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*