ПЕРШЕ серйозна помилка ОБ’ЄКТОВОГО ПІДХОДУ

Почнемо з наведеної нижче цитати з Третього Маніфесту [33]

“[Перш ніж] ми зможемо розглянути питання про [зближенні між] обєктами і відносинами більш докладно, необхідно проаналізувати надзвичайно важливий попередній питання, який наведено нижче.

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

■&nbsp&nbsp&nbsp&nbsp домен = клас обєкта

■ змінна відносини = клас обєкта

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

Насправді те, що перше рівняння є правильним, цілком очевидно, оскільки і класи обєктів, і домени являють собою просто типи Безумовно, якщо виходити з того, що змінні відносини – це змінні, а класи – це типи, має бути також відразу ж ясно, що друге рівняння є неправильним (змінні і типи – НЕ одне і те ж) саме з цієї причини в [33] приведено категоричне твердження, що змінні відносини – це НЕ домени Проте, багато фахівців, а також розробники деяких програмних продуктів, фактично керуються другим рівнянням, тобто роблять помилку, яку ми називаємо першим серйозним помилкою (The First Great Blunder) Тому було б дуже повчальним уважне вивчення другого рівняння, що і буде зроблено в цьому розділі

Примітка Інша частина даного розділу в основному являє собою більш-менш буквальну цитату з [33]

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

CREATE OBJECT CLASS EMP ( EMP# CHAR(5), ENAME

CHAR(20), SAL NUMERIC, HOBBY CHAR(20), WORKS_FOR CHAR(20) ) ..

Тут ОМР #, ENAME і тд – Відкриті змінні екземпляра (Автор спеціально визначив їх як відносяться до простих вбудованим типам, а не до визначеним користувачем типами до того ж аналогічної угоди автор буде для спрощення дотримуватися у всіх інших прикладах даної глави) Тепер розглянемо наступне визначення базової змінної відносини на мові SQL

CREATE TABLE EMP

( EMP#     CHAR(5)   NOT     NULL, ENAME    CHAR(20)  NOT     NULL, SAL          NUMERICNOT NULL,

HOBBY    CHAR(20)  NOT    NULL,

WORKS_FOR CHAR(20)  NOT    NULL ) ..;

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

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

критичні зауваження, які будуть наведені нижче в даному розділі, з відповідними застереженнями, відносяться до будь-якій системі, яка заснована на рівнянні змінна відносини = клас обєкта .

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

відносини або, можливо, з тієї ж самої змінної відносини (!) У даному прикладі можна замінити початкове пропозицію CREATE TABLE наступною колекцією пропозицій (рис 261)

Рис 261 Атрибути, що містять кортежі (покажчики на кортежі), –

CREATE TABLE EMP

(ОМР # CHAR (5) NOT NULL, ENAME CHAR (20) NOT NULL, SAL NUMERIC NOT NULL,

HOBBY    ACTIVITY    NOT NULL, WORKS_FOR COMPANY NOT NULL )

CREATE TABLE ACTIVITY

( NAME     CHAR(20)    NOT NULL, TEAM     INTEGER NOT NULL )

CREATE TABLE COMPANY

( NAME     CHAR(20)    NOT NULL, LOCATION CITYSTATE   NOT NULL )

CREATE TABLE CITYSTATE

( CITY     CHAR(20)    NOT NULL,

STATE    CHAR(2) NOT NULL )

Пояснення Атрибут HOBBY (Захоплення) у змінній відносини EMP оголошений як відноситься до типу ACTIVITY (Вид спорту), а сам тип ACTIVITY, в свою чергу, являє собою змінну стосунки з двома атрибутами, NAME І TEAM, де TEAM задає кількість гравців у команді, відповідної назві NAME наприклад, можливим видом спорту може бути той вид футболу, в якому команда складається з 11 гравців, (Soccer, 11) Тому кожне значення HOBBY являє собою фактично пару значень – значення NAME І значення TEAM (точніше, це – Пара значень, яка в даний час присутня в якості кортежу у змінній отношeнія ACTIVITY)

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

Аналогічним чином, атрибут WORKS_FOR у змінній відносини ОМР оголошений як відноситься до типу COMPANY, a COMPANY також являє собою змінну стосунки з двома атрибутами, один з яких визначено як відноситься до типу CITYSTATE, який представляє собою ще одну змінну стосунки з двома атрибутами, і тд Іншими словами, всі змінні відносини ACTIVITY, COMPANY і CITYSTATE розглядаються як типи (домени) і разом з тим як змінні відносини Таке ж твердження, безумовно, є справедливим і стосовно до самої змінної відносини ОМР

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

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

Але було б точніше охарактеризувати це доповнення як дозвіл використовувати атрибути, що містять покажчики на кортежі; ця тема буде більш докладно розглядатися трохи пізніше, а ще більше детально – у наступному розділі (Тому на рис 261 фактично слід замінити три згадки терміну кортеж термінами покажчик на кортеж)

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

CREATE TABLE EMP

(ОМР # CHAR (5) NOT NULL, ENAME CHAR (20) NOT NULL,

SAL    NUMERIC                                           NOT NULL,

HOBBIES SET OF ( ACTIVITY ) NOT NULL,

WORKS_FOR COMPANY                                         NOT NULL )

Пояснення Тепер значення HOBBIES в кожному конкретному кортежі змінної відносини ОМР (концептуально) являє собою безліч пар, те кортежів (NAME, TEAM) із змінної відносини ACTIVITY У кількості від нуля і більше Тому дане друге доповнення приблизно аналогічно тому, що дозволяється використовувати обєкти, які включають обєкти колекцій – це більш складна версія ієрархії вкладення

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

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

Рис 262 Атрибути, що містять безлічі кортежів (покажчиків на кортежі), –

Нерекомендовані варіант

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

CREATE TABLE EMP

( EMP#   CHAR(5) ,                                           NOT NULL,

ENAME   CHAR (20)                                           NOT NULL, SAL     NUMERIC                                            NOT NULL, HOBBIES SET OF ( ACTIVITY ) NOT NULL,

WORKS_FOR                                                                                     COMPANY     NOT NULL ) METHOD RETIREMENT_BENEFITS ( ) : NUMERIC

Пояснення Тут RETIREMENT_BENEFITS – це метод, який приймає в якості фактичного параметра заданий кортеж ОМР і виробляє результат типу

Рис 263 Змінні відносини, які визначені як суперкласу і

NUMERIC Останнє доповнення в області оголошення полягає в тому, що повинні бути дозволені підкласи, наприклад, наступним чином (рис 263):

підкласи, – Нерекомендовані варіант

CREATE TABLE PERSON

( SS#                                        CHAR(9)                                           NOT NULL, BIRTHDATE DATE                                                                                NOT NULL, ADDRESS  CHAR(50)                                           NOT NULL )

CREATE TABLE EMP AS SUBCLASS OF PERSON

( EMP#     CHAR(5)                                           NOT NULL, ENAME    CHAR (20)                                           NOT NULL, SAL                                        NUMERIC                                            NOT NULL,

HOBBIES  SET OF ( ACTIVITY ) NOT NULL,

WORKS_FOR COMPANY                                           NOT NULL ) METHOD RETIREMENT_BENEFITS ( ) : NUMERIC

Пояснення Тепер змінна відносини ОМР має три додаткових атрибута (SS #, BIRTHDATE і ADDRESS), які успадковані від змінної відносини PERSON (оскільки кожен екземпляр EMP is a, тобто являє собою також екземпляр4 PERSON, висловлюючись неформально) Якби таблиця PERSON мала які-небудь методи, то вони також могли бути успадковані

Примітка Тут PERSON і ОМР являють собою приклади того, що іноді, відповідно, іменується супертабліцамі і підтаблицях Додаткове обговорення (і критика) цих понять наведено в [1413], а також в розділі 266

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

■&nbsp Позначення шляху (Наприклад, ОМР WORKS_FOR LOCATION STATE) Слід зазначити, що такі вирази, взагалі кажучи, можуть повертати скаляри, кортежі або відношення Заслуговує також на увагу те, що в останніх двох випадках

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

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

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

(Е 0 0 1, Smith, $ 50000,

( ( Soccer, 11 ), ( Baseball, 9 ) ),

( IBM, ( San Jose, CA ) ) )

■ Реляційні оператори порівняння (наприклад, SUBSET, SUBSETEQ і тд)

Примітка Дані конкретні оператори взяті з певного рассматри ваемого програмного продукту У цьому програмному продукті під оператором

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

а під оператором SUBSETEQ – оператор виділення підмножини (?)

■ Оператори для проходження по ієрархії класів (наприклад, для одночасної вибірки інформації ОМР і PERSON)

Примітка Тут також необхідно дотримуватися обережності, оскільки цілком може виявитися, що запит на вибірку інформації PERSON разом з отриманням відповідної інформації ОМР призведе до отримання результату, яка не є відношенням Це означає, що порушене вкрай важливе реляционное властивість замкнутості, а це цілком може привести з руйнівних наслідків У цьому звязку в [2641], де такий результат називається непередбачуваним поверненням (Jagged return), просто приведено легковажне зауваження, що клієнтська програма повинна мати здатність справлятися зі складнощами непередбачуваного повернення.

■ Здатність викликати методи, наприклад, в конструкціях SELECT і WHERE

(У термінології SQL)

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

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

■ З рівняння змінна відносини = клас обєкту слід інші уравне ня: кортеж = обєкт і атрибут = (відкрита) змінна екземпляра. Отже, (Як було показано в главі 25), справжній клас обєкта (принаймні, ска лярні або інкапсульований клас обєкта) має методи і не має відкритих

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

■ Між двома визначеннями атрибутів (наприклад) SAL NUMERIC І WORKS_FOR COMPANY є важливе відмінність Справа в тому, що NUMERIC пред ставлять собою справжній тип даних (в рівній мірі його можна розглядати як справжній, хоча і примітивний домен) він накладає не залежить від часу обмеження на значення, які допускаються використовувати в атрибуті SAL На відміну від нього, COMPANY – це не справжній тип даних обмеження, яке він накладає на значення, дозволені для застосування в атрибуті WORKS_FOR, за висять від часу (безумовно, вони залежать від поточного значення змінної від носіння COMPANY) Фактично, як було зазначено вище, тут не враховується відмінність між змінною відносини і доменом або, якщо завгодно, відмінність між колекцією і класом

■ Вище було показано, що на перший погляд дозволено включати до обєкти корті жей інші такі обєкти наприклад, може здатися, що обєкти ОМР включа ють обєкти COMPANY Але фактично в даному випадку справа йде не так, що одні обєкти включають інші обєкти замість цього вони містять покажчики на містяться в них обєкти, і користувачі повинні мати абсолютно чітке по нимание цього питання Наприклад, припустимо, що користувач якимось про разом оновлює деякий конкретний кортеж COMPANY (див рис 261) Тоді це оновлення стане відразу ж видимим у всіх кортежі ОМР, які містять даний кортеж COMPANY

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

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

а) Чи можна вставити кортеж ОМР і задати значення для міститься в ньому кортежу COMPANY, який в даний час не існує у змінній відносини COMPANY Якщо відповідь є позитивним, той факт, що атрибут WORKS_FOR визначений як належить до типу COMPANY, мало що означає, оскільки він не дозволяє так чи інакше в якоїсь помітної ступеня накладати обмеження на операцію INSERT А якщо відповідь негативна, то операція INSERT стає занадто складною, оскільки користувач буде змушений здавати не тільки імя існуючої компанії (тобто значення зовнішнього ключа), як треба було б в аналогічній ситуації з використанням реляційних обєктів, але і весь існуючий кортеж COMPANY Більш того, задаючи весь існуючий кортеж COMPANY, користувач в кращому випадку

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

б) Припустимо, що потрібно ввести для даних про компанії правило ON DELETE RESTRICT (для того щоб спроби видалити дані про компанію закінчувалися невдачею, якщо в базі даних залишається інформація про співробітників цієї компа нії) Цілком можна припустити, що це правило має бути наказано з по потужністю процедурного коду, скажімо, за допомогою деякого методу M (зверніть увагу на те, що змінна відносини ОМР не має зовнішнього ключа, за яким можна було б закріпити декларативну версію цього правила) Крім того, звичайні операції DELETE мови SQL тепер не повинні вико няться над змінної відносини COMPANY, окрім як за допомогою коду, до торий реалізує даний метод М Яким чином можна було б наказати виконання цієї вимоги Аналогічні зауваження та питання, безуслов але, відносяться і до інших правил роботи з зовнішніми ключами, таким як ON DELETE CASCADE

в) Слід також відзначити, що видалення кортежу ОМР може не спричинити за собою виконання каскадної операції видалення відповідного кортежу COMPANY, незважаючи на видиме враження, що кортеж ОМР містить такий кортеж COMPANY

З усього сказаного вище випливає, що, строго кажучи, мова більше не йде про реляційної моделі Фундаментальний обєкт даних більше не є відношенням, що містить значення його, швидше, можна назвати Відношенням в лапках (фактично взагалі не справжнім ставленням в тому сенсі, який мається на увазі реляційної моделлю), що містить значення і покажчики Іншими словами, тутпідірвана концептуальна цілісність реляційної моделі Примітка Термін концептуальна цілісність (Conceptual integrity) був введений Фредом Бруксом (Fred Brooks), який дав йому таке визначення [263]: [Концептуальна] цілісність – це найбільш важлива вимога в проектуванні системи Найкраще виключити з системи деякі аномальні кошти, щоб втілити в ній єдиний набір проектних вимог, ніж створювати систему, яка реалізує багато важливих, але незалежних і нескоординовані вимог (Курсив оригіналу) А в іншій своїй роботі, яка вийшла через 20 років, він додає: Якісний, витончений програмний продукт повинен являти собою реалізацію .. цілісної теоретичної моделі .. Для зручності експлуатації .. найбільш важливим фактором є .. [концептуальна] цілісність .. Тепер я в цьому переконаний ще більше, ніж будь-коли Концептуальна цілісність є основою забезпечення якості продукту (Напівжирний шрифт і курсив оригіналу)

■ Припустимо, що визначено уявлення V як проекція змінної відносини ОМР тільки (скажімо) по атрибуту HOBBIES Зрозуміло, що V – це також мінлива відносини, але похідна, а не базова Тому, якщо рівняння змінна відносини = клас обєкту є правильним, то V – також клас Але який це клас До того ж класи мають методи які методи застосовуються до подання V

Очевидно, що клас ОМР має тільки один метод, RETIREMENT_BENEFITS, і цей метод, безумовно, не застосуємо до класу V Фактично, навряд чи можна назвати розумним таке припущення, що будь-які методи, застосовні до класу ОМР, будуть ставитися і до класу V а те ж саме, безумовно, стосується інших уявлень Тому (в цілому) створюється враження, що до результатів проекції не можуть застосовуватися взагалі будь-які методи це означає, що результат проекції, яким би він не був, насправді взагалі не є класом (Ми могли б, зрозуміло, просто назвати його класом, але від цього він не став би таким Справа в тому, що це був би клас, що має відкриті змінні екземпляра і не має методів, притому що вже було зазначено, що справжнійінкапсульованийклас має методи і не має відкритих змінних екземпляра) Цілком очевидно, що фактично ті фахівці, які ставлять знак рівності між змінними відносини і класами, мають на увазі саме базові змінні відносини, але забувають про похідні змінних відносини (Безумовно, покажчики, описані вище, являють собою покажчики на кортежі в базових, а не в похідних змінних відносини) Але проведення відмінності між базовими і похідними змінними відносини зазначеним чином є помилкою вищого порядку, оскільки задача визначення того, яка мінлива відносини є базовою, а яка похідною (і це дуже важливо), вирішується повністю довільно, залежно від потреб конкретного додатка (Як було сказано в описі принципу взаємозамінності в розділі 10) ■ Нарешті, які домени підтримуються Мабуть, ті, хто вважає правильним рівняння змінна відносини = клас обєкту, намагаються в основному уникати обговорення питання про домени, швидше за все, з тієї причини, що не можуть визначити, яким чином домени як такі вписуються в розроблену ними загальну схему Проте, як відомо, поняття доменів є одним з істотних

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

Аналіз джерел виникнення першого серйозного омани

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

термінології слід було б називати або значенням, або змінної (а можливо, і обидва ці поняття) Але, на жаль, цей термін застосовується також фахівцями в деяких інших областях, зокрема, він зустрічається в певних областях семантичного моделювання в складі всіляких методів і методологій обєктного аналізу і проектування або обєктного моделювання (Див, наприклад, [143]) А в цих областях, мабуть, даний термін трактується не як значення або змінна, а скоріше як те, що в співтоваристві користувачів баз даних найчастіше прийнято називати сутністю (до речі, під цим, крім усього іншого, мається на увазі, що, на відміну від обєктів з мов програмування, обєкти, звані сутностями, безумовно не інкапсульовані) Іншими словами, так зване обєктне моделювання насправді являє собою просто моделювання сутностей / звязків під іншою назвою фактично в [143] в тій чи іншій мірі визнається справедливість цього твердження Внаслідок цього, інформаційні структури, виявлені з допомогою цих методологій як обєкти, потім (цілком обгрунтовано) відображаються на кортежі в змінних відносини, а не на значення в доменах При цьому виникає неймовірна плутанина

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

*

*