Об’єктно-реляційні бази даних

Наприкінці 1990-х років деякі постачальники випустили програмні продуктиобєктно-реляційнихСУБД, відомі також під назвою універсальних серверів До прикладів таких продуктів відносяться версія Universal Database СУБД DB2, опція Universal Data Option сервера Informix Dynamic Server і програмний продукт Oracle Universal Server (для цих продуктів використовуються й інші назви) Випускаючи всі ці програмні продукти, постачальники керувалися тим основним задумом, що в них повинна забезпечуватися підтримка і обєктних, і реляційних можливостей іншими словами, що розглядаються продукти представляли собою спробу домогтися зближення цих двох технологій

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

фундаментом всієї сучасної технології баз даних в цілому, як було описано в частині II цієї книги)

Отже, ми прагнемо до того, щоб реляційні системи развівалісь1 і включали в себе засоби (або, принаймні, позитивні засоби) обєктних систем (безумовно, ми не допускаємо можливості повної відмови від реляційних систем, а також не хочемо того, щоб нам довелося мати справу з двома окремими системами, реляційної та обєктної, існуючими пліч-о-пліч) І таку думку поділяють багато інші фахівці, включаючи, зокрема, авторів Маніфесту систем баз даних третього покоління [2644], які категорично стверджують, що СУБД третього покоління повинні бути створені на основі СУБД другого покоління (Коротко пояснимо, що мається на увазі під поколіннями СУБД: назва СУБД першого покоління відноситься до дореляціонним системам, таким як IMS, СУБД другого покоління – це системи SQL, а СУБД третього покоління – ті, що прийдуть за ними) Але очевидно, що така думка не поділяють деякі постачальники обєктних систем, а також певні фахівці в області обєктної технології Нижче наведена типова цитата, Підтверджує цю думку [267]

Компютерна наука бачила багато поколінь засобів управління даними, починаючи з індексованих файлів, потім мережевих і ієрархічних СУБД, .. [а] останнім часом зявилися реляційні СУБД .. Тепер ми стаємо свідками появи чергового покоління систем баз даних, .. [які] забезпечують управління обєктами, [підтримуючи] набагато більш складні види даних

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

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

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

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

А що можна сказати про обєктних системах Чи створені вони з нагоди У це питання дозволяє внести ясність наступна цитата з Маніфесту обєктно-орієнтованих систем баз даних [202], [251]: Що стосується специфікації даної системи,

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

то ми є прихильниками дарвінівського підходу – ми сподіваємося, що після створення цілого ряду експериментальних прототипів [відбудеться природний відбір і] зявиться відповідна [обєктна] модель . Іншими словами, тут явно простежується думка, що необхідно розробляти код і створювати системи без будь-якої заздалегідь певної моделі, а потім дивитися, що з цього вийде

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

Отже, у главі 25 було показано (див також анотацію до [2631]), що обєктна орієнтація просто наштовхує нас на одну хорошу ідею – а саме, на те, що необхідно забезпечити належну підтримку типів даних (або дві хороші ідеї, якщо розглядати спадкування типів окремо) Тому питання переходить в іншу площину: Як включити належну підтримку типів даних в реляційну модель”. А відповідь, безумовно, полягає в тому (як вже, безсумнівно, зрозумів читач), що ця підтримка вже існує, у формі доменів (які автор, у всякому разі, краще називати типами) Іншими словами, в реляційну модель не потрібно нічого вносити, щоб домогтися появи обєктних функціональних можливостей в реляційних системах, вірніше, нічого, крім повної і належної реалізації того, чого так явно бракує в сучасних системах SQL2

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

2 Зокрема, сучасні системи стали причиною появи широко поширених хибних поглядів, що реляційні системи здатні підтримувати лише обмежена кількість дуже простих типів Вельми типовими є наступні цитати: Реляційні .. системи підтримують невелику, фіксовану колекцію типів даних (наприклад, цілі числа, дати, рядки) [2634], реляційні СУБД здатні підтримувати тільки свої вбудовані типи [по суті, лише цілі числа, рядки, значення дати і часу] [2531], обєктно-реляційні моделі даних розширюють реляционную модель даних, надаючи більш розвинену систему типів [1621] і тд

Як приклад знову повернемося до деяких незакінченою темам з глави 25 і розглянемо якісне реляционное рішення задачі з прямокутниками (Це рішення дано на мові Tutorial D підготовку його аналога мовою SQL залишаємо читачеві як вправа) Спочатку визначимо тип прямокутника такий спосіб

TYPE RECTANGLE POSSREP ( X1 RATIONAL, Y1 RATIONAL,

X2 RATIONAL, Y2 RATIONAL ) ..

Передбачається, що прямокутники представлені фізично за допомогою однієї з тих структур даних, які спеціально призначені для ефективної підтримки просторових даних: дерев квадрантів (Квадрадеревьев), R-дерев і тд [2637]

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

OPERATOR OVERLAP ( R1 RECTANGLE, R2 RECTANGLE ) RETURNS BOOLEAN

RETURN ( THE_X1 ( Rl ) &lt THE_X2 ( R2 ) AND THE_Y1 ( Rl ) &lt THE_Y2 ( R2 ) AND THE_X2 ( Rl ) &gt THE_X1 ( R2 ) AND THE_Y2 ( Rl ) &gt THE_Y1 ( R2 ) ) END OPERATOR

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

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

VAR RECTANGLES BASE RELATION { R RECTANGLE, .. } KEY { R }

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

RECTANGLES

WHERE OVERLAP ( R, RECTANGLE ( 00, 00, 10, 10 ) )

У даному рішенні подолані всі недоліки, що обговорювалися у звязку з цим запитом в главі 25

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

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

необхідно обговорити ці помилки і, зокрема, показати, чому ми розглядаємо їх як омани, тому план інших частин цієї глави полягає в наступному У розділах 262 і 263 розглядаються два серйозні омани Потім у розділі 264 обговорюються деякі аспекти реалізації обєктно-реляційної системи У розділі

265 демонструються переваги справжньої обєктно-реляційної системи (тобто

системи, в якій немає слідів жодного з цих двох помилок) У розділі 266

описані відповідні кошти SQL У розділі 267 представлено резюме

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

*

*