Will Oracle8 Be Universal?

David Wells,
Переклад – Сергій Кузнєцов, ЦІТ
www.sitforum.ru

  • Погляд компанії Oracle на об'єктно-реляційний підхід
  • Об'єктно-реляційні розширення
  • Оцінка функціональних можливостей Oracle8

    Після випуску в червні 1997 р. продукту Oracle8 маркетингова

    політика компанії орієнтована на поліпшену масштабованість

    системи і значення мережевий обчислювальної архітектури (NCA –

    Network Computing Architecture). Однак Oracle8 має

    істотним набором об'єктно-реляційних засобів, про які

    компанія говорить несправедливо мало.

    Погляд компанії Oracle на об'єктно-реляційний підхід

    Компанія обіцяє надати своїм користувачам

    об'єктно-реляційні можливості з 1992 р. П'ятирічна еволюція

    серверних продуктів відбувалася вигляді компромісу між

    потребами ринку і необхідністю перепису частин системи в

    розумному порядку.

    У Oracle6 були внесені зміни в архітектурні компоненти

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

    кошти розпаралелювання та блокувань рівня запису). У Oracle7

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

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

    двофазна фіксація розподілених транзакцій. Випущена в

    першому кварталі 1996 р. версія Oracle 7.3 була першою, яку

    компанія назвала "універсальним сервером", оскільки в цій

    версії підтримувалися поліпшені засоби документального пошуку

    (ConText Option) і просторові типи даних (Spatial Data

    Option). У теперішній випуск Oracle8 включені основні

    архітектурні зміни, що торкаються не тільки

    об'єктно-реляційні можливості, але також засоби копіювання і

    відновлення й нові якості масштабування для підтримки

    надвеликих баз даних.

    Загальна стратегія компанії являє собою цікаву суміш

    консерватизму та інновації. Прагматичний підхід Oracle до

    об'єктно-реляційної технології є відносно

    консервативним, хоча NCA являє собою одне з перших

    дійсно суттєвих рішень провідного незалежного

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

    розподіленої об'єктної технології CORBA. Крім того, рішення

    компаніями щодо використання Oracle8 для підтримки репозиторію її

    власних засобів розробки додатків забезпечує кращу

    середовище для проектування додатків, ніж конкуруючі

    об'єктно-реляційні системи.

    Стратегія Oracle здається виключно розумною. Дослідження та

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

    1996 ринок мало потребував об'єктно-реляційної технології. У

    результаті, коли Informix і IBM почали в середині 1996 р.

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

    Oracle здавалася налаштованої суворо. Це враження підтверджували

    агресивні заяви і рекламна діяльність компанії.

    Виникало враження, що компанія Oracle прагнула

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

    запропонувати не могла. Об'єктно-реляційна технлологія,

    з'явилася в Oracle8, категорично спростовує цю точку зору.

    Oracle як і раніше вважає, що вимоги поліпшеної

    масштабованості не менш важливі, ніж об'єктно-реляційна

    технологія, і що хоча вимоги до останньої в даний час

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

    низькому рівні.

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

    виключно до сервера баз даних; багато компонентів більш

    природно розташувати на сервері додатків. Oracle

    протиставляє цей підхід сервер-орієнтованим

    архитектурам, пропонованих у Informix Universal Server і DB2

    Universal Database компанії IBM.

    Об'єктно-реляційні розширення

    Принципові розширення в підтримці великих об'єктів і

    тригерів INSTEAD-OF можуть бути ліцензовані окремо від

    основної частини сервера Oracle8 у вигляді Object Option. Що стосується

    додаткових вбудованих типів даних, то Oracle пропонує

    чотири розширених реляційних типу даних: великі об'єкти з

    поліпшеним керуванням вмістом; два види типів даних

    колекції – VARRAY і вкладені таблиці; розширений тип даних,

    реалізує покажчики.

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

    доменів. Типи категорії VARRAY дозволяють зберігати масиви в

    стовпцях таблиць; для більшості типів даних Oracle8, включаючи

    об'єктні типи, їх значення можуть зберігатися в VARRAY. Ряд

    обмежень у VARRAY ускладнює їх застосування в деяких цілях.

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

    Нині такі масиви та їх вміст не повністю

    доступні з SQL (хоча доступ до них можливий з PL / SQL або коду

    додатки на 3GL).

    Іншим типом колекції є вкладені таблиці. Як випливає з

    назви, вкладені таблиці дозволяють зберігати в стовпцях

    табличні значення. На відміну від VARRAY, вкладені таблиці

    повністю доступні з SQL.

    Нарешті, є розширений тип даних, який реалізує покажчики,

    які в Oracle8 називаються REF. REF реалізуються за

    використанням генеруються системою об'єктних ідентифікаторів;

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

    основі покажчиків можлива навігація. Покажчиками можна

    маніпулювати і виробляти навігацію з SQL з використанням

    ключових слів REF, DEREF і VALUE. Покажчики грають важливу роль

    при виконанні операцій об'єктного кешу клієнта.

    Об'єктні типи. Система об'єктних типів Oracle8 дозволяє

    визначати і зберігати іменовані структури даних, наприклад:

    
    CREATE TYPE customer_type AS OBJECT (
    
            name VARCHAR2 (20),
    
            no_of_purchases NUMBER,
    
            MEMBER FUNCTION get_no_of_purchases RETURN NUMBER);
    
    

    Будь-який тип Oracle8 може виступати в якості члена об'єктного

    типу, включаючи VARRAY, вкладені таблиці і інші об'єктні типи.

    У бета-версіях Oracle8 об'єктні типи називалися "абстрактними

    типами даних "(термін, використовуваний у проектах SQL3 і в

    академічних колах), але пізніше було вирішено, що термін

    "Об'єктні типи" є більш зрозумілим і точним. (На самому

    справі, об'єктні типи Oracle8 є узагальненням

    іменованих типів рядків і абстрактних типів даних SQL3.)

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

    може бути представлена на PL / SQL або у вигляді викликів функцій 3GL.

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

    PL / SQL для обчислення та отримання інформації про об'єкти даного

    типу та / або їх модифікації. Кожен об'єктний тип має по меншій

    мірою один метод – конструктор. Це певна в системі

    функція, яка створює об'єкт даного типу. На додаток до

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

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

    сортування та операції порівняння.

    Об'єктні типи можна використовувати двома способами. По-перше,

    з використанням об'єктного типу можна визначити об'єктні

    таблиці, специфікуючи тип таблиці цілком:

    
          CREATE TABLE customers OF customer_type
    
    

    У цьому прикладі кожен рядок результуючої таблиці буде

    містити об'єкт типу customer_type з членами-атрибутами,

    специфікованою при оголошенні цього об'єктного типу (іншими

    словами, "name" і "no_of_purchases"). До кожної рядку-об'єкту

    Oracle8 додає "прихований" стовпець, що містить генерований

    системою унікальний ідентифікатор (ID) об'єкта. Цей ID можна

    використовувати в покажчиках (REF) на об'єкти таблиці з інших

    таблиць або реалізовувати покажчики між об'єктами цієї ж

    таблиці. При бажанні стовпець ID можна індексувати для більш

    швидкого пошуку REF.

    По-друге, об'єктні типи можна використовувати для визначення

    типів стовпців. У цьому випадку при визначенні типів стовпців

    таблиці імена об'єктних типів поміщаються замість імен базових

    типів. Наприклад, оголошений вище тип customer_type можна було б

    використовувати для визначення структурованого стовпця

    "Customer" у звичайному таблиці. Члени такого "об'єктного стовпця"

    доступні з SQL з використанням розширеної точкової нотації,

    наприклад, шляхом вибірки my_table.customer.name.

    Ці два види застосування об'єктних типів відповідають двом

    способам відображення структурованих об'єктів в реляційну

    схему.

    Об'єктний кеш клієнта. У Oracle8 також забезпечуються

    значні можливості маніпулювання об'єктами на стороні

    клієнтських додатків. Об'єктний кеш клієнта може бути

    реалізований і доступний для маніпулювання з використанням

    викликів нового інтерфейсу OCI (Oracle Call Interface), з

    застосуванням прекомпілятора C / C + + з вбудованим SQL (набувається

    окремо), або на основі бібліотеки класів C + + і середовища

    підтримки часу виконання, керованої очікуваним незабаром

    продуктом Oracle Object Database Designer (розвиток

    Designer/2000).

    З використанням інтерфейсу рівня OCI об'єкти з об'єктних

    таблиць Oracle8 можуть бути завантажені у кеш поосле виконання

    запиту на розширеному SQL, що вибирає ідентифікатори об'єктів;

    після цього можливо маніпулювання об'єктами. Всі зміни

    можуть бути згодом виштовхнуті на сервер. OCI також дає

    можливість додатком зберегти покажчики на інші об'єкти,

    які будуть підкачуватися в кеш клієнта в міру необхідності.

    Підтримується керований рівень читання, що в кеш

    об'єктів, на які посилається базовий об'єкт. Ця можливість

    схожа на "листання об'єктів", яке забезпечується в деяких

    об'єктних системах баз даних.

    Прекомпілятор надає подання більш високого рівня

    тих же функціональних можливостей, які надаються

    розробникам традиційних баз даних. Більш детальний інтерфейс

    OCI більше підходить для розробників додатків.

    У Oracle8 забезпечується компонент Object Type Translator (OTT),

    який може генерувати відповідний С-структури для

    використання клієнтськими додатками при роботі з об'єктним

    кешем.

    Підтримка компанією узгодженого багатоверсійності читання

    розширюється на кешовані об'єктні дані і дозволяє поліпшити

    масштабованість за рахунок можливості клієнтів об'єктного кешу

    працювати без запиту блокувань з читання в базі даних. Кожен

    клієнт кешу бачить свою власну приватну версію бази даних у

    тієї точки, в якій цей клієнт почав маніпулювати об'єктами.

    У кеші клієнта може підтримуватися кілька ниток (thread),

    кожна з яких володіє власною сесією з базою даних і

    бачить приватну порцію кешу, відповідну власної транзакції

    нитки.

    Об'єктні подання. Oracle8 забезпечує об'єктні

    уявлення, які особливо істотні для поступового

    переходу до використання можливостей об'єктно-реляційного

    підходу і для нових застосувань існуючих баз даних без

    зміни їх схеми. Об'єктні подання схожі на

    традиційні реляційні подання, але в них можуть

    використовуватися строга типізація, складні структури (не в першій

    нормальної формі), методи і можливості посилань на існуючі

    реляційні дані.

    Багатотабличні об'єктні уявлення можуть бути зроблені

    оновлюваними за рахунок наявності нового виду тригера INSTEAD OF,

    який перехоплює команди SQL, спрямовані на оновлення

    уявлення, і виконує відповідну дію. Осмислено

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

    будь-яке традиційне реляційне представлення.

    Деякі прості, але корисні об'єктні подання є

    оновлюваними за своєю природою. Наприклад, за допомогою об'єктного

    подання можна представити таблицю customers, що складається з

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

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

    об'єкти address. Оскільки такі структури є оновлюваними,

    вони легко надбудовуються над існуючою схемою.

    "Віртуальними об'єктами", певними за допомогою об'єктного

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

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

    "Реальними" об'єктами з об'єктних таблиць. Для створення

    придатних ідентифікаторів віртуальних об'єктів у визначеннях

    об'єктної таблиці повинен бути специфікований відповідний

    унікальний складовою ключ для об'єктного представлення.

    Через наявність деяких незначних обмежень об'єктні

    уявлення не повністю еквівалентні об'єктним таблиць.

    Наприклад, зазвичай неможливо зберігати покажчики на віртуальні

    об'єкти в об'єктних уявленнях, оскільки такі покажчики

    повинні конструюватися з використанням складеного первинного

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

    ідентифікаторів реальних об'єктів).

    Розвиток можливостей у майбутньому. Поки компанія Oracle не оголосила

    час випуску і точний набір функціональних можливостей

    Oracle 8.1. Однак, якщо основививаться на історії компанії, вона

    повинна оголосити наступний загальний випуск у другій половині 1998

    р., включивши в нього підтримку мови Java для виконання функцій

    управління базами даних (реалізації збережених процедур і

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

    картриджів баз даних. Картридж для роботи з тимчасовими рядами

    планується випустити трохи раніше.

    Оцінка функціональних можливостей Oracle8

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

    зацікавлені по-крупному у швидкому розвитку

    об'єктно-реляційної технології. До цих пір жоден постачальник не

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

    даних основного потоку. Більше того, у всіх провідних продуктах

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

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

    різні засоби. На основі чого користувачі можуть порівняти ці

    продукти?

    Важко обговорювати природу і значення об'єктно-реляційної

    технології, оскільки, на відміну від реляційної моделі, ця

    концепція не є єдиною і добре оформленої.

    Об'єктно-реляційна парадигма є скоріше слабо пов'язаними

    набором багатьох окремих корисних компонентів. Більше 120

    функціональних аспектів називають "об'єктно-реляційними", від

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

    розширюваної індексації та кешування та кластеризації складних

    об'єктів. Деякі з цих аспектів враховуються в процесі

    вироблення стандарту SQL3, інші (наприклад, кешування і

    кластеризація) – ні. У провідних продуктах реалізуються істотно

    різні підмножини функцій.

    Тому не дивно, що багато потенційні користувачі

    цієї технології знаходяться в замішанні. Аргументи окремих

    постачальників щодо того, які частини технології є

    обов'язковими для "справжніх" об'єктно-реляційних баз даних, не

    допомагають. Для того, щоб усунути це замішання і залишитися

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

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

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

    увагу реалізаційні особливості.

    Розвинена технологія баз даних може (і повинна) забезпечити

    наступні категорії властивостей:

    1. Програми обробки даних наступного покоління. Можливість

      просто і швидко створювати інформаційні системи, орієнтовані

      на використання баз даних, у більшій мірі задовольняють

      потребам користувачів. До відповідних властивостей відносяться

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

      рядкові типи в дусі SQL3 і які визначаються користувачами функції.

    2. Управління вмістом. Можливість отримувати користь з

      змішаної текстової, документальної та мультимедійної інформації з

      використанням структурованих даних існуючий

      інформаційних систем. До відповідних властивостей відносяться

      хороша підтримка великих об'єктів і застосовність SQL-запитів

      для текстового пошуку.

    3. Проектування прілооженій. Більш спеціальні переваги

      реалізації програм, які працюють зі складними даними і

      транзакціями (CAD, CASE, офісна автоматизація). Це та ніша, в

      якої найбільш успішно застосовувалися чисті об'єктні бази

      даних. До необхідним властивостям відносяться підтримка нетрадиційних

      типів транзакцій, ідентифікованих об'єктів і навігація по

      вказівниками.

    4. Інтеграція на основі об'єктної орієнтованості. Перевага

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

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

      включаючи об'єктно-орієнтовані мови програмування і брокери

      об'єктних заявок (ORB – Object Request Broker).

    5. Адаптивність. Зменшення витрат та / або підвищення

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

      які полегшують модифікацію існуючих додатків при

      потреби їх зміни.

    6. Керованість. Зменшення витрат у зв'язку з більш простим

      управлінням системою баз даних і додатками. Наприклад,

      введення нетрадиційних або розширених типів може утруднити

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

      чином із засобами адміністратора баз даних.

    7. "Універсальна" настроюваністю. Можливість домогтися

      прийнятною ефективності різного роду додатків, що грунтуються

      на різних архітектурах, шляхом налаштування програмного

      забезпечення (а не купуючи більшу кількість апаратури).

      Відповідні властивості включають розширювану індексацію,

      простоту використання в різних архітектурних середовищах, кешування

      і кластеризацію складних об'єктів.

    8. Простота освоєння. Можливість отримувати користь від нової

      технології без істотних витрат, перепідготовки штату і

      модифікації існуючих програм. У цьому відношенні істотні

      відповідність стандартам SQL і забезпечення інтероперабельності з

      успадкованими базами даних і додатками.

    На основі наведеної моделі можна оцінити функціональні

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

    даних – Oracle8, Informix Universal Server, DB2 Unversal

    Database, Sybase Adaptive Server і Microsoft SQL Server (разом з

    OLE DB). Модель можна з тим же успіхом застосувати до чисто

    реляційних або суто об'єктним баз даних, а також для

    ілюстрації зв'язку між різними технологіями та їх еволюції.

    В оригіналі статті наведені діаграми, іллюстірующіе еволюцію

    технології баз даних від базових СУБД, що підтримують стандарт

    SQL-89, до "ідеального" універсального сервера. Крім того, з

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

    очікувані характеристики Oracle 8.1.

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


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

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

    Ваш отзыв

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

    *

    *