Об’єктні бази даних

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

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

обєктно-орієнтованих мовах програмування, наприклад в C + + і Smalltalk І, цілком природно, виникла ідея реалізувати ці можливості в системах баз даних, що й було зроблено багатьма дослідниками і декількома виробниками СУБД

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

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

Замість цього користувачеві має надаватися доступ до обєктів і операціями над цими обєктами, які більшою мірою відповідають своїм аналогам в реальному світі Наприклад, використовуючи традиційні терміни, можна представляти відділ, як кортеж DEPT з набором відповідних кортежів ОМР, тобто співробітників, які мають значення зовнішніх ключів, посилаються на значення первинного ключа в кортежі DEPT. А в новій технології користувач матиме справу з обєктом відділу, який містить відповідне безліч обєктів співробітників І замість виконання операції вставки нового кортежу в змінну відносини ОМР з відповідним значенням зовнішнього ключа, вказує на Значення первинного ключа деякого кортежу в змінної відносини DEPT, користувач повинен мати можливість безпосередньо Прийняти співробітника (представленого обєктом) на роботу у відділ (також представлений відповідним обєктом) Інакше кажучи, фундаментальна ідея обєктного підходу – підвищення рівня абстракції

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

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

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

Зокрема, нижче перераховані найбільш важливі відмінності

■ Прикладна програма за визначенням призначена для вирішення деяких конкретних завдань

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

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

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

До речі, точно такий же довід може бути приведений у відношенні дореляціонних

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

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

управління базами даних Зокрема, багато хто стверджує, що обєктні технології дуже перспективні для складних програми в таких областях:

■ системи автоматизованого проектування та автоматизованого управ ління виробництвом (САПР / АСУП)

■ системи комплексного автоматизованого управління технологічними про цессами

■ системи автоматизованої розробки програмного забезпечення

■ геоінформаційні системи

■ наука і медицина

■ системи зберігання та вибірки документів і тд

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

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

варіант вирішення цих завдань Потім, в розділі 252, пропонується огляд основних понять, таких як обєкти, класи, повідомлення і методи У розділі 253 певну увагу приділено опису деяких особливостей цих понять, а також докладно обговорюється їх зміст У розділі 254 представлений всеосяжний приклад застосування обєктної бази даних, а в розділі 255 обговорюються деякі додаткові питання Нарешті, в розділі 256 приведено резюме

На закінчення необхідно зробити наведені нижче зауваження

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

Спеціальний приклад

У даному розділі розглядається простий приклад, спочатку запропонований Стоунбрейкер (Stonebraker), доопрацьований автором цієї книги і описаний в [2515] Даний приклад ілюструє деякі проблеми, властиві класичним продуктам SQL База даних, яка може розглядатися як суттєво спрощена версія бази даних САПР / АСУП, містить відомості про прямокутниках, заданих в такій системі координат, осі Х і Y якої паралельні сторонам цих прямокутників, тобто всі сторони прямокутників є або вертикальними, або горизонтальними Отже, кожен прямокутник може бути унікальним чином представлений за допомогою координат(x1,y1)  і(Х2, у2)нижнього лівого і верхнього правого кутів, відповідно (рис 251) На мові SQL це визначення можна записати за допомогою наступного оператора

CREATE TABLE RECTANGLES

(X1 .., Y1 .., Х2 .., Y2 .

.,.., PRIMARY KEY ( X1, Y1, X2, Y2

) )

Тепер розглянемо запит: Шукати всі прямокутники, які перекривають одиничний квадрат (0, 0, 1, 1) (Рис 252)

Рис 251 Прямокутник з координатами (xl, yl, x2, у2)

Рис 252 Одиничний квадраті координатами (0, 0,1,1)

“Очевидна формулювання цього запиту на мові SQL може бути представлена ​​наступним чином

SELECT ..

FROM RECTANGLES

WHERE ( X1 &gt= 0 AND X1 &lt= 1 AND Yl &gt= 0 AND Yl &lt= 1 )

/ * Нижній лівий кут всередині одиничного квадрата * / OR (Х2> = 0 AND X2 <= 1 AND Y2> = О AND Y2 <= 1)

/ * Верхній правий кут всередині одиничного квадрата * / OR (X1> = 0 AND X1 <= 1 AND Y2> = О AND Y2 <= 1)

/ * Верхній лівий кут всередині одиничного квадрата * /

OR (Х2> = О AND X2 <= 1 AND Yl> = 0 AND Yl <= 1)

/ * Нижній правий кут всередині одиничного квадрата * / OR (X1 <= О AND Х2> = 1 AND Yl <= О AND Y2> = 1)

/ * Прямокутник повністю включає одиничний квадрат

* / OR (X1 <= О AND X2> = 1 AND Yl> = 0 AND Yl <= 1)

/ * Нижній край перетинає одиничний квадрат * /

OR (X1> = О AND X1 <= 1 AND Yl <= 0 AND Y2> = 1)

/ * Лівий край перетинає одиничний квадрат * /

OR (Х2> = О AND X2 <= 1 AND Yl <= 0 AND Y2> = 1)

/ * Правий край перетинає одиничний квадрат * /

OR (X1 <= О AND X2> = 1 AND Y2> = 0 AND Y2 <= 1);

/ * Верхній край перетинає одиничний квадрат * /

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

SELECT ..

FROM RECTANGLES

WHERE ( X1 &lt= 1 AND Yl &lt= 1

/ * Нижній лівий кут знаходиться нижче і лівіше точки

(1,1) * / AND X2> = О AND Y2> = 0)

/ * Верхній правий кут знаходиться вище і правіше

точки (00) * /

(В упр 253 наприкінці глави пропонується переконатися, що це формулювання також є правильною)

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

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

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

реляційних продуктів, в яких використовуються звичайні структури памяті, наприклад, індекси у вигляді В-дерев (В середньому, система буде перевіряти 50% елементів індексу для кожної з координат X1, Y1, X2, Y2) Іншими словами, проблема полягає не

тільки в тому, що відсутня досить хороша оптимізація

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

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

для розвитку обєктних систем

Примітка У наступному розділі (розділ 261) буде приведено ефективне рішення задачі про прямоугольніках1

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

*

*