ДОДАТКОВІ АСПЕКТИ об’єктного підходу

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

■ Довільні запити і повязані з цим проблеми

Цілісність бази даних

■ Реалізація звязків

■ Мови програмування баз даних

■ Підвищення продуктивності

■ Можливість розглядати обєктну СУБД як звичайну СУБД

Довільні запити і повязані з цим проблеми

До цих пір ми навмисно не підкреслювали, що якщо для маніпулювання обєктами задані тільки заздалегідь певні методи, то довільні запити (непередбачений цими методами) просто неможливі, якщо тільки класи та методи не розроблені відповідно до спеціальних правил Наприклад, якщо для обєкта класу DEPT визначені тільки методи HIRE_EMP (найняти співробітника), FIRE_EMP (звільнити співробітника) і CUT_BUDGET (урізати бюджет) (як описано в розділі 252), то неможливо буде виконати навіть такий простий запит: Хто є керівником відділу програмування .

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

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

1 Визначити безліч операторів (операторів ТНЕ_), за допомогою яких можна було б одержати доступ до деяким можливим уявленням рассмат Ріва обєктів, як описано в розділі 5

2 Належним чином впровадити обєкти в реляційну структуру Ця частина ре ня детально обговорюється в наступному розділі

Але розробники обєктних систем зазвичай НЕ дотримуються таких рекомендацій

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

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

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

У звязку з виконанням довільних запитів виникає ще одне важливе питання, а саме: який клас є результатом Припустимо, наприклад, що необхідно виконати запит: Визначити імена і заробітну плату всіх службовців з відділу програмування по базі даних відділів і службовців з розділу 253 Імовірно результат буде містити (відкриті) змінні екземпляра ENAME і SALARY Однак у базі даних немає класу, який має таку структуру Чи потрібно попередньо визначати такий клас, перш ніж виконувати запит (Зверніть увагу на наслідки: якби було необхідно визначити такий клас, то для класу з п змінними екземпляра, було б потрібно мати принаймні 2n таких заздалегідь визначених класів тільки для підтримки операцій вибірки) А якщо є який-небудь клас результатів, то які методи до нього застосовні

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

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

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

ENROLLMENT OFFERING COURSE

Воно означает14 наступне: Отримати доступ до унікального обєкту COURSE, на який вказує унікальний обєкт OFFERING, вказаний за допомогою заданого обєкта ENROLLMENT. Реляційний аналог цього виразу зазвичай включає дві операції зєднання і одну операцію проекції Іншими словами, в результаті відстеження шляху надається доступ тільки за попередньо певних шляхах (фактично, як в дореляціонних системах) і тільки до обєктів попередньо визначених класів (знову ж, як в дореляціонних системах)

Цілісність бази даних

У главі 9 стверджувалося, що цілісність даних в базі має абсолютно фундаментальне значення Проте, навіть ті обєктні системи, які підтримують довільні запити, зазвичай не підтримують декларативні обмеження цілісності Виконання подібних обмежень досягається за допомогою процедурного коду, тобто методів або, можливо, прикладних програм Розглянемо, наприклад, таке обмеження (Або бізнес-правило) з розділу 91: Жоден постачальник зі статусом менше 20 не може постачати будь-які деталі в кількості більше 500. Для того щоб забезпечити виконання цього обмеження, процедурний код його підтримки повинен бути включений, щонайменше, в усі перераховані нижче методи:

‘■  метод для створений ия обєкта поставки

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

■ метод для зміни статусу постачальника

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

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

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

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

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

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

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

5 Як вчинити, якщо обмеження необхідно ввести лише на час, а потім від менить

14 Насправді це вираз НЕ є допустимим шляхом для бази даних, в тому вигляді, як ми її визначили, оскільки покажчики визначають невірний напрямок Наприклад, обєкти класу OFFERING не посилаються на обєкти класу COURSE навпаки, обєкти класу COURSE посилаються на них

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

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

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

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

Реалізація звязків

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

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

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

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

CLASS ОМР ..

( .. DEPT OID ( DEPT ) INVERSE DEPTEMPS )

… CLASS DEPT ..

( .. EMPS

OID( SET ( OID ( EMP ) ) ) INVERSE EMPDEPT ) ..

Відзначимо, що ключове слово INVERSE НАЛЕЖИТЬ до двох змінним примірника: EMPDEPT і DEPTEMPS Кажуть, що ці дві змінні екземпляра є зворотними по відношенню один до одного Мінлива ОМР DEPT – це посилальна змінна екземпляра, a DEPT EMPS – мінлива набору посилань екземпляра (Якби обидві змінні були змінними набору посилань, то звязок мала б тип багато до багатьох, а не один до багатьох.)

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

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

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

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

SPP# WHERE SPS# = S#(S1)

SPS# WHERE SPP# = P#(P1)

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

SPARTSP# WHERE SS# = S#(S1) PSUPPSS# WHERE PP# = P#(P1)

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

Посилальна цілісність

Розглянемо вже згадану раніше обєктну підтримку посилальної цілісності, яка, до речі, як часто стверджують, є сильною стороною обєктних систем Рівні такої підтримки можуть бути самими різними наприклад, нижче наводиться класифікація таких рівнів, запропонована в роботі Каттелла (Cattell) [2510]

■&nbsp&nbsp&nbsp&nbsp Відсутність системної підтримки Підтримка посилальної цілісності покладає ся на код, написаний користувачем (до речі, як це було визначено в першо початковій версії стандарту мови SQL)

■&nbsp&nbsp&nbsp&nbsp Перевірка покажчиків В системі виконується перевірка того, чи відносяться всі ука затели до існуючих обєктів правильного типу Але видалення обєктів може бути не дозволено (замість цього, як у мові OPAL, може бути передбачено знищення обєктів, на які немає більше посилань, за допомогою збору сміття) Як вже пояснювалося в розділі 254, цей рівень підтримки приблизно еквівалентний (але лише дуже приблизно) правилом каскадного видалення ON DELETE CASCADE в ієрархії для підлеглих обєктів без можливості сііместного доступу і контрольованого видалення (ON DELETE RESTRICT) ДЛЯ інших обєктів (але тільки якщо покажчики вказують на правильний обєкт)

■&nbsp&nbsp&nbsp&nbsp Системна підтримка На цьому рівні відстеження і оновлення посилань проис ходить в системі автоматично (наприклад, за допомогою установки значення nil для посилань на віддалені обєкти) Цей рівень в деякій мірі подібний правилом видалення ON DELETE SET NULL

■&nbsp&nbsp&nbsp&nbsp Обумовлена ​​користувачем семантика. Правило каскадного видалення ON DELETE CASCADE (застосовується за межами ієрархії вкладення) може розглядатися як приклад обумовленою користувачем семантики . Такі можливості зазвичай

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

Мови програмування баз даних

Наведені в розділі 254 приклади на мові OPAL демонструють, що, на відміну від більшості сучасних реляційних програмних продуктів (на основі мови SQL), в обєктних системах зазвичай не використовується вбудований подязик даних Замість цього для операцій, виконуваних як з базами даних, так і з іншими обєктами, використовується один і той же інтегрований мову Відповідно до прийнятої в главі 2 термінології базовий мова і мова, орієнтований на роботу з базами даних, в обєктних системах тісно повязані (Фактично ці дві мови являють собою один і той же мова)

Такий підхід, безумовно, володіє певними перевагами (саме тому він прийнятий в мові Tutorial D) Одне з найбільш істотних – можливість здійснення вдосконаленою перевірки типів [252] У наведеній нижче цитаті з [2538] відзначено ще одна важлива гідність

“В єдиному уніфікованому мові немає невідповідності типів даних між процедурною мовою програмування і вбудованою мовою маніпулювання даними з декларативної семантикою.

Термін невідповідність типів даних (Impedance mismatch) використовується для опису відмінностей між типовими сучасними мовами програмування, функціонуючими на основі послідовної обробки записів, і реляційними мовами зразок SQL, функціонуючими на основі послідовної обробки множин Очевидно, що такі відмінності на практиці призводять до виникнення різноманітних проблем при використанні програмних продуктів SQL Але для їх вирішення НЕ потрібно переводити мову, орієнтований на роботу з базами даних, на рівень послідовної обробки окремих записів (як це прийнято в обєктних системах) Необхідно замість цього в мовах програмування ввести інструменти для переходу до послідовної обробці множин записів Застосування послідовної обробки окремих записів в обєктних мовах (тобто процедурний підхід) відкидає нас до часів, коли використовувалися такі дореляціонние системи, як IMS і IDMS

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

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

Підвищення продуктивності

Низька продуктивність – один з найбільш істотних недоліків всіх обєктних систем Знову наведемо цитату з [2510]: Відмінність продуктивності на порядок реально може призвести до виникнення функціональних відмінностей, оскільки для вирішення деяких завдань буде неможливо використовувати дану систему, якщо її

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

яке він лише трохи перефразував)

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

можна відзначити перераховані ніже15

■&nbsp&nbsp&nbsp&nbsp КластеризаціяЯк зазначено в розділі 18, фізична кластеризація логічно взаємоповязаних даних, розміщених на жорсткому диску, є одним з найбільш важливих факторів підвищення продуктивності системи У обєкт них системах логічна інформація з визначень бази даних (щодо ієрархії класів, ієрархії вкладення або інших явно заданих звязків між обєктами) зазвичай заснована на моделі системи і використовується в якості при близно плану для фізичної кластеризації даних Крім того, часто рекомендується, щоб адміністратор бази даних сам здійснював явне і непо безпосередніх управління відображенням концептуального рівня на внутрішній (за термінологією глави 2)

■&nbsp&nbsp&nbsp&nbsp КешуванняОбєктні системи зазвичай призначені для використання в середовищі клієнт / сервер, в якій користувачі копіюють на свої робочі стан ції інформацію з бази даних на сервері і зберігають її на цих робочих станціях протягом деякого часу Очевидно, що в такій системі було б корисно кешувати логічно повязані дані на робочому місці клієнта

■&nbsp&nbsp&nbsp&nbsp Підстановка Термін підстановка покажчиків (Swizzling) означає процес заміни покажчиків, організований за принципом заміни ідентифікаторів обєктів

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

■&nbsp&nbsp&nbsp&nbsp Виконання методів на сервері Як приклад розглянемо запит: Шукати всі книги, в яких міститься більше 20 глав. У традиційній системі SQL книги можуть бути представлені у вигляді обєктів типу CLOB або BLOB (див гла ву 15), і в клієнтському додатку може знадобитися виконати вибірку кож ної книги по черзі і переглянути її для визначення того, чи є в ній більше 20 глав На відміну від цього, в обєктній системі оператор визначення кількості глав міг бути виконаний на сервері і клієнтові передані тільки ті книги, які фактично потрібні Тому виконання методів на сервері зазначеним чином сприяє зниженню витрат, повязаних з передачею данних16

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

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

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

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

1 Випадкова вибірка 1000 деталей із застосуванням заданого користувачем методу для кожної деталі

2 Випадкова вставка 1000 деталей з приєднанням кожної до трьох інших

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

Згідно з даними, опублікованими в [2512], продуктивність деякої (не сказано, який) обєктної системи на два порядки вище продуктивності деякої (не сказано, який) сучасної системи SQL, особливо за умови, що кеш вже заповнений даними (так званий теплий доступ) Проте в тій же роботі [2512] наведено таке справедливе твердження

“Ця різниця .. НЕ слід приписувати відмінності між власне реляційної та обєктної моделями .. В основному ці відмінності обумовлені [особливостями реалізації] .

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

Аналогічний, але більш повний еталонний тест, ОО7, описаний в [259]

Чи справді можна розглядати обєктну СУБД як звичайну СУБД

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

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

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

1 Спільний доступ до даних з боку декількох додатків

2 Фізична незалежність від даних

3 Можливість виконання довільних запитів

4 Підтримка уявлень і логічної незалежності від даних

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

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

7 Управління паралельною роботою

8 Каталог загального призначення

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

Згодом, після представлення основної ідеї зберігання обєктів в базі даних, ці можливості були розглянуті і реалізовані як удосконалення і доповнення до вихідної обєктної моделі .. Один з важливих висновків .. полягає в тому, що обєктна СУБД і реляційна СУБД – системи, які різні по суті Насправді, можна довести, що обєктна СУБД фактично зовсім не є СУБД, по крайней мере, в тому сенсі, в якому це може бути застосовано до реляційної СУБД

Для порівняння розглянемо наведені нижче зауваження

■&nbsp&nbsp&nbsp Реляційні СУБД надходять від виробника готовими до використання Іншими словами, як тільки система встановлена, користувачі .. можуть ■ почати будувати бази даних, розробляти програми, запускати запити і тд

■&nbsp Обєктну ж СУБД можна вважати лише деякого роду набором засобів побудови СУБД Після вихідної установки обєктна СУБД не готова до негайного використання .. Спочатку вона повинна бути пристосована до певної області застосування досвідченими фахівцями, які визначать необхідні класи, методи і тп Для цього в системі надається набір будівельних блоків – засоби для супроводу бібліотеки класів, компілятори методів і тд Тільки після завершення такої підготовки систему можна передати в експлуатацію прикладним програмістам і користувачам Іншими словами, результат такої підготовки вже буде більше нагадувати СУБД в звичному сенсі цього терміну

Крім того, відзначимо, що результат підготовки такої бази буде залежати від конкретного додатка Ця система може підходити, наприклад, для додатків САПР / АСУП, але бути абсолютно непридатною, наприклад, для медичних програм Інакше кажучи, вона все ще не стала СУБД загального призначення в тому сенсі, в якому реляційна СУБД є СУБД загального призначення

У тій же статті [2516] оскаржується ідея (часто звана перманентністю, ортогональної типом [252]), відповідно з якої в базу даних можна включати (змінювані) обєкти довільної сложності17 Нижче наведена

ще одна цитата, взята з [2516]

Для обєктної моделі потрібна підтримка [великої кількості] генераторів типу .. Як приклад можна вказати такі типи, як структура (STRUCT), кортеж (TUPLE), список (LIST), масив (ARRAY), безліч (SET), мультімножество (BAG) і тд .. Разом з ідентифікаторами обєктів наявність таких генераторів типів фактично означає, що будь-яка структура даних, яка може бути створена в прикладній програмі, може бути також створена як обєкт в обєктній базі даних,і, крім того, така структура обєктів доступна користувачеві Наприклад, розглянемо обєкт (припустимо, ЕХ), який є колекцією службовців у відділі (або, швидше, позначає таку колекцію) Тоді обєкт ЕХ може бути реалізований як звязаний список або як масив, і користувачі повинні будуть знати, як саме реалізований цей обєкт, оскільки при цьому використовуються різні оператори доступу

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

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

■&nbsp&nbsp&nbsp&nbsp У реляційній моделі, по суті, також можна зберігати все що завгодно, однак потрібно, щоб те, що зберігалося в базі даних, було представлено для користувача в строго реляційної формі

Точніше, в реляційної моделі (цілком обгрунтовано) майже зовсімнічогоне говориться про те, як можуть фізично зберігатися дані .. Отже, реляційна модель не накладає ніяких обмежень на структури даних, які допустимі на фізичному рівні Єдина вимога полягає в тому, що якщо яка-небудь структура реально фізично зберігається в базі даних, вона повинна відображатися у відносини на логічному рівні і тому повинна бути прихованою від користувача Таким чином, реляційні системи дозволяють провести чітку відмінність між логічним і фізичним уявленнями, тобто моделлю даних та їх реалізацією, а обєктні системи цього не дозволяють І, як наслідок, всупереч звичайному здоровому глузду, обєктні системи можуть забезпечити лише значно меншу незалежність від даних, ніж реляційні системи Припустимо, наприклад, що в деякій обєктної базі даних для реалізації згаданого обєкта ЕХ, позначає колекцію службовців в даному відділі, замість масиву став застосовуватися звязаний список Якими будуть наслідки цього для існуючого коду, за допомогою якого здійснювався доступ до обєкта ЕХ

17 Гляньте [2519]

251 РЕЗЮМЕ

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

■&nbsp&nbsp&nbsp&nbsp Класи обєктів (Тобто типи) Класи обєктів відповідають типам даних і, без умовно, дуже важливі По суті, це найбільш фундаментальна концепція з усіх

■&nbsp&nbsp&nbsp&nbsp Обєкти Самі обєкти, змінювані і незмінні, очевидно, становлять основу обєктних систем, хоча ми воліли б їх називати просто змінними і зна нями, відповідно

■&nbsp&nbsp&nbsp&nbsp Ідентифікатори обєктів Не потрібні і навіть шкідливі (на рівні моделі), посколь ку по суті це покажчики Це питання докладно розглядається в [2519]

■&nbsp&nbsp&nbsp&nbsp Інкапсуляція Як вже зазначалося в розділі 252, інкапсульований означає просто скалярний, і ми б віддали перевагу саме такий термін, завжди памятаючи при цьому, що деякі обєкти, тим не менш, не є скалярами

■&nbsp&nbsp&nbsp&nbsp Змінні примірника По-перше, закриті захищені) змінні екзем Пляра за визначенням відносяться до реалізації, тому вони не відповідають оп ределению абстрактної моделі, яку ми тут розглядаємо По-друге, від критих змінних екземпляра в чисто обєктної системі не існує, поет му вони також тут недоречні Таким чином, приходимо до висновку, що пе ремінні примірника можна ігнорувати, а обєкти повинні оброблятися виключно методами

■&nbsp&nbsp&nbsp&nbsp Ієрархія вкладення Як вже зазначалося в розділі 253, ми вважаємо, що поняття ієрархій вкладення вводить в оману і насправді є невірним, по скільки такі ієрархії включають ідентифікатори, а не обєкти

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

■&nbsp&nbsp&nbsp&nbsp Методи Це, звичайно, важливе поняття, хоча ми воліли б більш звичний термін оператори Але обєднання методів з операторами НЕ є обовязко вим і приводить до деяких проблем [33] Роздільне визначення класів (Типів) і методів (Операторів), як було показано в розділі 6, дозволяє обійтися без використання поняття обєкта-одержувача

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

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

Примітка Проте ми б відмовилися від функцій-конструкторів Конструктори створюють змінні А оскільки для нас єдиними необхідними

змінними в базі даних є змінні відносини, єдиний конструктор, який нам потрібен, – це оператор створення змінної відносини, тобто CREATE TABLE або CREATE VIEW (за термінологією мови SQL) Оператори вибірки, навпаки, вибирають значення Звичайно, є і додаткове відмінність в тому, що конструктори повертають покажчики на створені змінні, в той час як оператори вибірки повертають самі обрані значення

■&nbsp&nbsp&nbsp&nbsp Повідомлення Це також одне з основних понять, хоча ми воліли б більш звичний термін виклик Знову ж, можна обійтися без використання поняття обєкта-одержувача, якщо відмовитися від вимоги безпосереднього звернення до деякого обєкту-одержувачу, а вважати всі фактичні параметри одно правних

■&nbsp&nbsp&nbsp&nbsp Ієрархія класів З ієрархією класів повязані такі поняття, як успадкування, поліморфізм, перевантаження, перевизначення і тд Вважаємо, що поняття ієрархії класів – потрібне, але похідне Ми розглядаємо підтримку ієрархії класів як складову підтримки самих класів

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

■&nbsp&nbsp&nbsp&nbsp Звязки У розділі 14 (розділ 146) вже оскаржувалася ідея трактування звязків як фор мально окремої конструкції (особливо якщо це лише бінарна звязок, яка і заслужила таку спеціальну трактування) Ми також не вважаємо вдалою трак товку повязаних обмежень посилальної цілісності, яка розходиться з трак товк обмежень цілісності взагалі (див нижче)

■&nbsp&nbsp&nbsp&nbsp Інтегровані мови програмування баз даних Вельми корисні, але не від носяться виключно до обєктної технології Проте, слід зазначити, що мови, які підтримуються сучасними обєктними системами, звичайно є процедурними (Мови третього покоління), тому можна дока зати, що вони невдалі (фактично це величезний крок назад)

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

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

■&nbsp&nbsp&nbsp&nbsp Уявлення Зазвичай не підтримуються (в основному з тих же причин, що і обробка довільних запитів)

Примітка У деяких обєктних системах підтримуютьсяпохідніабо

віртуальні змінні екземпляра (обовязково відкриті) Наприклад, змінна екземпляра AGE (вік) може успадковуватися за допомогою віднімання значення змінної примірника BIRTHDATE (Дата народження) з поточної дати Однак така можливість ще дуже далека від можливостей, які

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

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

■&nbsp Декларативні обмеження цілісності Зазвичай не підтримуються (в основному з тих же причин, що і представлення і обробка довільних запитів) Більше того, вони зазвичай не підтримуються навіть тими системами, які підтримують довільні запити

■&nbsp&nbsp&nbsp&nbsp Зовнішні ключі В обєктної моделі передбачено кілька різних

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

реляційної моделі

Такі поняття, як обмежене (ON DELETE RESTRICT) І каскадне (ON

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

(Розміщеного або в методах, або в коді додатків)

■&nbsp&nbsp&nbsp&nbsp Замкнутість Складно знайти обєктний аналог реляційному властивості замкнутості

Каталог Де ж каталог в обєктній системі Як він виглядає Чи какиелибо стандарти

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

Підсумувавши сказане вище, можна відзначити наведені в табл 251 корисні (істотні, фундаментальні) поняття і концепції обєктної моделі (Такі, що бажано підтримувати)

Таблиця 251 Корисні поняття і концепції обєктної моделі

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

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

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

*

*