ЗАСОБИ МОВИ SQL

Явна підтримка спадкування в мові SQL обмежується (тільки) одинарним спадкуванням (тільки) для структурованих типів в цій мові відсутня явна підтримка наслідування для згенерованих типів, немає явної підтримки для множинного спадкоємства і взагалі не підтримується спадкування для вбудованих типів АБО ТИПІВ DISTINCT14

Нижче показаний синтаксис визначення структурованого типу (трохи упро-

щенний)

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

CREATE TYPE &lttype name&gt

[ UNDER &lttype name&gt ]

[ AS &ltrepresentation&gt ]

[ [ NOT ] INSTANTIABLE ]

NOT FINAL [ &ltmethod specification commalist&gt ]

А тут представлені приклади можливих визначень SQL для типів

PLANE_FIGURE, ELLIPSE І CIRCLE

CREATE  TYPE PLANE_FIGURE NOT INSTANTIABLE NOT FINAL  

CREATE TYPE ELLIPSE UNDER PLANE_FIGURE AS (A LENGTH, В LENGTH, CTR POINT) INSTANTIABLE NOT FINAL

CREATE   TYPE   CIRCLE   UNDER ELLIPSE AS   (  R   LENGTH  )

INSTANTIABLE NOT  FINAL   

На підставі наведених визначень можна зробити перераховані нижче висновки

(Деякі з них взяті з глави 5)

1 Ключове слово NOT INSTANTIABLE означає, що розглянутий тип не має примірників, де під терміном примірник (Здебільшого) мається на увазі значення, для якого найбільш конкретним типом є розглянутий тіп15 Іншими словами, розглянутий тип являє собою те, що в дан ной чолі згадується під назвою обєднаного типу Ключове слово INSTANTIABLE означає, що розглянутий тип має щонайменше один примірник це означає, що він не представляє собою обєднаний тип і тому існує щонайменше одне значення, найбільш конкретним типом якого є розглянутий тип У даному прикладі тип PLANE_FIGURE визначений як NOT INSTANTIABLE, а ТИПИ ELLIPSE І CIRCLE – Як INSTANTIABLE (по

замовчуванням застосовується ключове слово INSTANTIABLE)

2 Як було зазначено в розділі 5, має бути обовязково вказано ключове слово NOT FINAL (хоча в специфікації SQL: 2003, мабуть, замість нього буде раз вирішено здавати альтернативне ключове слово FINAL) Ключове слово NOT FINAL означає, що для розглянутого типу дозволено визначати строгі підтипи, а ключове слово FINAL, коли воно буде підтримуватися, повинно озна чать зворотне

3 Специфікація UNDER визначає безпосередній супертіп даного типу (або, в термінології SQL, прямий супертіп – direct supertype), якщо він має ся Тому, наприклад, CIRCLE – це прямий підтип типу ELLIPSE і властивості,

15 В [423] екземпляр визначений як фізичне уявлення значення (!)

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

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

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

в) Розглянуті оператори поділяються на три категорії: функції, про цедури і методи Як було зазначено в розділі 5, функції та процедури приклад але відповідають операторам, призначеним тільки для читання, і операто рам оновлення методи діють аналогічно функцій, але викликаються з використанням іншого синтаксичного стилю Крім того, функції і про цедури визначаються за допомогою окремих операторів CREATE FUNCTION і CREATE PROCEDURE, а методи визначаються у вигляді вбудованих конструк ций у складі відповідного оператора CREATE TYPE, як зазначено в син таксіческой структурі оператора CREATE TYPE (ДЛЯ спрощення в приведений них тут прикладах специфікації методів не застосовуються) Звязування на етапі компіляції (тобто звязування на основі тільки оголошених типів) при змінюється до функцій і процедур, а звязування на етапі прогону применя ється до методів, але здійснюється на основі тільки одного з існуючих фактичних параметрів (як це зазвичай прийнято в обєктних системах див розділ 25)

4 Аналогом термінакореневої типв мові SQL ємаксимальний супертіп (Maximal supertype), тому в даному прикладі PLANE_FIGURE – це максимальний супертіп (Але, як не дивно, в мові SQL для позначення листового типу

застосовується термін НЕ мінімальний підтип, а листової тип, тому в розглянутому прикладі тип CIRCLE – це листовий тип)

5 Опція &ltrepresentation&gt з позначенням уявлення, якщо вона задана, зі стоїть з розділеного комами списку визначення атрибутів &ltattribute definition    commalist&gt,   укладеного в круглі дужки, де атрибут

&ltattribute&gt складається з імені атрибута &ltattribute name&gt, за яким сле дме імя типу name&gt. Але слід зазначити, що таке подання

&ltrepresentation&gt є дійсним фізичним представленням для значень розглянутого типу, а не можливим поданням (І тому

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

вже було зазначено в п 3) Зокрема, заслуговує на увагу те, що в мові SQL неможливо визначити два або більше різних уявлень &ltrepresentation&gt для одного і того типу

Примітка Але, як було зазначено в розділі 5, проектувальник типу може в кінцевому підсумку приховати той факт, що подання &ltrepresentation&gt  є фізичною завдяки продуманому вибору та проектуванню операторів

6 Для кожного атрибута &ltattribute&gt передбачені метод-спостерігач (observer method) і метод-модифікатор (mutator method), що надаються авто матически і можуть спільно використовуватися для реалізації функціональних можливостей, певною мірою аналогічних можливостям операторів ТНЕ_, передбаченим у мові Tutorial D (деякі приклади на цю тему при ведені у розділі 5) Оператори селекторів не надаються автоматично, але для кожного типу передбачена надається автоматично функція конст руктора, яка після її виклику повертає таке унікальне значення цього ти па, що для будь-якого і кожного атрибута встановлюється застосовне значення за замовчуванням Як було сказано в розділі 5, це значення має бути порожнім для будь-якого атрибута, який, у свою чергу, відноситься до типу, який визначається користувачем Тому, наприклад, наступний вираз повертає еліпс, в якому і А, і в мають порожню довжину, a CTR є вільної точки (Її не слід, безумовно, плутати з такою точкою, де обидва компонента, х і Y, є порожніми)

ELLIPSE    ()

А наведене нижче вираз повертає еліпс, в якому довжина півосі а дорівнює чотирьом, довжина півосі b – трьом, а центр знаходиться на початку координат

ELLIPSE () А (LENGTH () L (40)) В (LENGTH () L (30)) CTR (POINT () X (00) Y (00))

(Тут передбачається, що тип LENGTH має уявлення, що складається лише з одного атрибута L типу FLOAT)

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

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

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

У мові SQL підтримуються аналоги запропонованого автором оператора TREAT DOWN та операторів перевірки типів, наприклад, як показано нижче

■ Аналог в мові SQL оператора TREAT_DOWN_AS_CIRCLE (E) – TREAT (E AS CIRCLE)

■ Аналог в мові SQL оператора I S_CIRCLE (E) – ТУРІ (Е) IS OF (CIRCLE)

■ Аналогом в мові SQL оператора

R: IS_CIRCLE (Е)

є наступний оператор

SELECT TREAT ( E AS CIRCLE ) AS E, F, G, .., H FROM R

WHERE TYPE ( E ) IS OF ( CIRCLE )

Тут до складу атрибутів F, G, , Н входять всі атрибути R, крім Є

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

DECLARE E ELLIPSE

SET Е = СХ

; SET Е = EX

Тут СХ і ЕХ-вирази, які повертають, відповідно, значення найбільш конкретного типу CIRCLE і ELLIPSE Тому після першого присвоювання змінна Е (який має оголошений тип ELLIPSE) характеризується найбільш конкретним типом CIRCLE, а після другого присвоювання вона має найбільш конкретний

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

Нарешті, нагадаємо сказане у главі 5, що будь-який конкретний структурований тип не обовязково повинен мати повязаний з ним оператор =, і навіть якщо для нього

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

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

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

Порівняння принципів наслідування і делегування

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

CREATE TYPE ELLIPSE UNDER PLANE_FIGURE

AS (A LENGTH, В LENGTH, CTR POINT) ..;

CREATE TYPE CIRCLE UNDER

ELLIPSE AS ( R LENGTH ) ..

;

У цих визначеннях тип CIRCLE має атрибути А, в, CTR (успадковані від типу ELLIPSE) і R (певний тільки для типу CIRCLE) А якщо є справедливим твердження про те, що задані атрибути утворюють фізичне уявлення, то кожна конкретна окружність повинна бути фізично представлена ​​у вигляді колекції з чотирьох значень, притому три з них у звичайних умовах будуть мати однакове значення З цієї причини, цілком ймовірно, що у визначенні типу CIRCLE фактично не буде взагалі вказуватися-яка власна опція подання &ltrepresentation> замість цього даний тип буде просто наслідувати уявлення, яке визначено для типу ELLIPSE З іншого боку, якщо подання для типу CIRCLE не має компонента R (radius – радіус), то для радіусом не будуть автоматично передбачені такі методи, як спостерігач і модифікатор А з цього випливає ще одне зауваження – якщо подання окружності включає компонент R і ми його модифікуємо, то в кінцевому підсумку отримаємо некруглу окружність, тобто Окружність, в якій, безумовно, не є однаковими всі значення А, в і R

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

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

CREATE TYPE CIRCLE

AS ( R LENGTH, CTR POINT

) INSTANTIABLE NOT FINAL

CREATE TYPE COLORED_CIRCLE UNDER CIRCLE AS ( COL COLOR )

INSTANTIABLE NOT FINAL

Цей приклад є саме тим, який ми визнали невдалим раніше, в розділі 209, де було сказано, що кольорові кола не можна назвати колами в тому ж сенсі, наприклад, в якому окружності є еліпсами Але якщо мова йде про спадкування і, можливо, навіть доповненні уявлень, то цей приклад набуває трохи більше сенсу Безумовно, цілком резонно розглядати кольорові окружності як обєкти, що представлені за допомогою таких атрибутів, як радіус, центр і колір Слід також відзначити, що якщо тип COLORED_CIRCLE визначений як підтип типу CIRCLE за допомогою ключового слова UNDER, ТО цілком припустимо також розглядати оператори, застосовні до кіл в цілому (наприклад, оператор визначення радіуса), як застосовні і до кольорових окружностям зокрема (Кольорові кола можуть бути підставлені замість звичайних кіл) Але залишається одна ідея, позбавлена ​​сенсу, – розглядати кольорові кола як обмежену форму кіл в цілому або, що рівносильно, формувати кольорові кола зі звичайних за принципом уточнення за допомогою обмежень Іншими словами, створюється враження, що механізм успадкування SQL розроблений взагалі не для використання в процесі спадкування в тому сенсі, в якому цей термін був визначений раніше в цій главі, а скоріше для використання в тому процесі, який деякі автори називають делегуванням Делегування означає, що відповідальність за реалізацію деяких операцій, повязаних з даним типом, доручається (Або делегується) типу деякого компонента подання даного типу (наприклад, операція отримання радіусу для кольорової окружності реалізується за допомогою виклику операції отримання радіусу у відповідному компоненті кола) Тому було б більш зрозуміло, якби цей механізм SQL іменувався в першу чергу механізмом делегування, а не висувалися претензії на те, що він має якесь відношення до спадкоємства і підтипів

202 РЕЗЮМЕ

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

■ Безліч значень в є строгим підмножиною множини значенійА

■ На тип В поширюється суворе надмножество тих обмежень, які відно сятся до типу А

Тип в має суворе надмножество таких операцій тільки читання, які відносяться до типу А

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

Потім у цій главі було описано відмінність між одинарним і множинним спадкуванням (але наведені відомості тільки про одинарному спадкуванні), а також відмінність між спадкуванням скалярів, кортежів івідносин (Але дано опис тільки спадкування скалярів) 16, крім того, представлено поняття ієрархії типів До того ж визначені терміни строгий підтип і супертіп, безпосередній підтип і супертіп, а також кореневої тип і листової тип і сформульовано припущення про неперетинання, згідно з яким типи Т1 і Т2 є непересічними, якщо жоден з них не є підтипом іншого З цього припущення випливає, що кожне значення має унікальний найбільш конкретний тип (Не обовязково листової тип)

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

Потім ми перейшли до опису впливу спадкування на операції присвоювання

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

(Значення зберігають свій найбільш конкретний тип після привласнення змінним з менш конкретним оголошеним типом), і тому змінна оголошеного типу т може мати значення, найбільш конкретним типом якого є будь підтип типу т (Аналогічним чином, якщо оператор Ор визначений як має результат оголошеного типу т, то фактичним результатом виклику оператора Ор може бути значення, найбільш конкретним типом якого є будь підтип типу т) Тому була запропонована модель змінної V (або в більш загальному сенсі, довільного вираження) як впорядкованої трійки у формі , де DT – оголошений тип, MST – поточний найбільш конкретний тип і v – поточне значення Потім був представлений оператор TREAT DOWN, Дозволяє виконувати операції таким чином, щоб можна було запобігти виникненню на етапі компіляції помилок через невідповідність типів при обробці таких виразів, найбільш конкретним типом яких на етапі прогону стає деякий строгий підтип їх оголошеного типу (Помилки через невідповідність типів на етапі прогону все ще можуть виникати, але тільки в контексті оператора TREAT DOWN)

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

16 Але автор може, принаймні, стверджувати, що описані в даній главі ідеї, що стосуються одинарного успадкування та скалярного спадкування скалярів, поширюються виключно успішно (до того ж напрочуд легко) на множинне спадкування, а також на спадкування кортежів і відносин, як показано в [33]

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

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

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

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

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

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

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

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

“Повна підтримка розподілених баз даних означає, що окремий додаток може «Прозоро» обробляти дані, розподілені між безліччю різних баз даних, управління якими здійснюють різні СУБД, що працюють на зєднаних комунікаційними мережами компютерах різних типів з різними операційними системами Тут поняття «прозоро» означає, що додаток виконує обробку даних з логічної точки зору так, як ніби управління даними повністю здійснюється однією СУБД, що працює на єдиному компютері . У цьому розділі ми поговоримо про розподілених базах даних докладніше, а саме – більш точно визначимо, що таке розподілена база даних, чому такі бази даних відіграють все важливішу роль (досить лише подумати про сучасних масштабах розвитку World Wide Web – Див главу 27) і які технічні проблеми існують в галузі розподілених баз даних

Крім того, в розділі 2 обговорювалися системи клієнт / сервер, які можна розглядати як простий окремий випадок розподілених систем взагалі Системи клієнт / сервер будуть розглянуті в розділі 215

Загальний план даної глави наведено в кінці наступного розділу

ПОПЕРЕДНІ ВІДОМОСТІ

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

■ Система розподілених баз даних складається з набору вузлів (Site), повязаних комунікаційною мережею, в якій:

а) кожен вузол – це повноцінна СУБД сама по собі, але

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

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

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

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

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

Найчастіше передбачається, що вузли розділені фізично (а можливо, і територіально, як показано на рис 211), хоча насправді досить того, щоб вони були розділені логічно Два вузла можуть навіть співіснувати на одному і тому ж фізичному компютері (особливо на початковому етапі тестування) Головна мета створення розподілених систем з часом змінювалася У ранніх дослідженнях в основному передбачалася територіальна розподіленість, але в більшості перших комерційних реалізацій передбачалося локальнерозподіл, коли кілька вузлів розміщувалося в одній будівлі і поєднувалося з допомогою локальної мережі (ЛОМ) Проте пізніше стрімке поширення глобальних мереж (ГВП) знову пробудило

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

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

називати це припущенням про суворої однорідності Можливості та не вельми

однорідних систем будуть проаналізовані в розділі 216

Рис 211 Приклад типової системи розподіленої бази даних Переваги

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

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

Для того щоб краще в цьому розібратися, наведемо приклад Розглянемо ще раз рис 211 Для простоти припустимо, що є тільки два вузли, Лос-Анджелес і СанФранциско, і що наша система – це банківська система Дані про рахунки ЛосАнджелесе зберігаються в Лос-Анджелесі, а дані про рахунки Сан-Франциско – у Сан-Франциско Переваги подібної розподіленої системи очевидні:ефективність обробки (Дані зберігаються в тому місці, де доступ до них потрібно найбільш часто) і розширені можливості доступу (При необхідності за допомогою комунікаційної мережі з Сан-Франциско можна отримати доступ до рахунків Лос-Анджелеса і навпаки)

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

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

Приклади розподілених систем

Для посилань надалі ми коротко перерахуємо деякі відомі реалізації розподілених систем Спочатку розглянемо прототипи Серед численних дослідницьких систем найбільш відомі три системи По-перше, це система SDD-1, створена в науково-дослідному відділенні корпорації Computer Corporation of America в кінці 1970-х і початку 1980-х років [2132] По-друге, система R * (читається R-star або R-зірочка) 1, розподілена версія системи-прототипу System R, створена в дослідницькому відділі компанії IBM на початку 1980-х років [2137] І по-третє, система Distributed Ingres, розподілена версія прототипу системи Ingres, створена також на початку 1980-х років в Каліфорнійському університеті в Берклі [2134]

Що стосується комерційних реалізацій, то більшість сучасних продуктів SQL включає певну підтримку розподілених баз даних, але, безумовно, з різними рівнями функціональних можливостей Найбільш відомі серед них такі: Ingres / Star (розподілений компонент бази даних СУБД Ingres), версія для розподілених баз даних СУБД Oracle і засоби розподілу даних для СУБД DB2

-&gt Примітка Розробники програмних продуктів часто випускають нові версії своїх продуктів під іншими назвами, тому автор не може гарантувати, що перераховані вище назви (а в деяких випадках навіть продукти) в даний час

все ще продовжують використовуватися Крім того, цей список продуктів і прототипів

1 У даному позначенні зірочка – це так званий оператор Клину (KJeene), а конструкція R * означає від нуля або большеекземпляровСУБД [System] R:

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

Фундаментальний принцип

Тепер сформулюємо твердження, що може розглядатися як фундаментальний принцип створення розподілених баз даних [2113]

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

Іншими словами, користувачі розподіленої системи повинні мати можливість діяти так, як якщо б система НЕ була розподілена Всі проблеми розподілених систем відносяться або повинні ставитися до внутрішніх проблем (або проблемам реалізації), а не до зовнішніх проблем (або проблемам користувача рівня)

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

логічно незмінними Але для операцій визначення даних, навпаки, в розподіленої системі обовязково будуть потрібні деякі доповнення, наприклад, для того щоб користувач (можливо, адміністратор бази даних) на вузлі X мав можливість вказати, що розглянута змінна відносини буде розділена нафрагменти, які будуть зберігатися на вузлах Y і z (див обговорення фрагментації в наступному розділі)

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

1 Локальна незалежність

2 Відсутність залежності від центрального вузла

3 Безперервне функціонування

4 Незалежність від розташування

5 Незалежність від фрагментації

6 Незалежність від реплікації

7 Обробка розподілених запитів

8 Управління розподіленими транзакціями

2 Правила – Це термін, використовуваний в статті, в якій ці правила вперше були представле ни [2113] Зазначений фундаментальний принцип був названий Правилом нуль. Однак насправді тут більш доречний термін цілі – Слово правила звучить занадто категорично У цій главі буде використовуватися більш помірне назва – мети.  

9 Апаратна незалежність

10 Незалежність від операційної системи

11 Незалежність від мережі

12 Незалежність від типу СУБД

Зверніть увагу на те, що НЕ всі ці цілі незалежні одна від іншої Крім того, вони не вичерпні і не всі однаково важливі (різні користувачі можуть надавати різне значення різним цілям в різних середовищах, і, крім того, деякі з цих цілей можуть бути взагалі незастосовні в деяких ситуаціях) Але дані цілі корисні як основа для розуміння самої розподіленої технології і як загальна схема опису функціональних можливостей конкретних розподілених систем Тому ми будемо використовувати список цих цілей як організаційний принцип для більшої частини даної глави У розділі 213 стисло обговорюється кожна з цілей У розділі 214 деякі конкретні питання розглядаються більш докладно, а в розділі 215, як уже зазначалося, наводиться обговорення систем клієнт / сервер. У розділі 216 ми детально обговоримо деякі конкретні проблеми, повязані з досягненням незалежності від СУБД Нарешті, розділ 217 присвячений підтримці мови SQL, а в розділі 218 міститься резюме і представлено декілька заключних зауважень

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

Джерело: Дейт К Дж, Введення в системи баз даних, 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>

*

*