Ортогональне проектування (невеликий відступ від ТЕМИ)

У цьому розділі, слідуючи опису, наведеному в [1312], коротко розглядається ще один принцип проектування баз даних, який безпосередньо не повязаний з принципом подальшої нормалізації, але дуже схожий на нього тим, що також є науково обгрунтованим Він називається принципом ортогонального проектування (principle of orthogonal design) Звернемося до рис 137, на якому представлений, безумовно, поганий, але цілком допустимий проект подання даних про постачальників Тут змінна відносини SA відповідає постачальникам, які знаходяться в Парижі, а змінна

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

Рис 137 Поганий, але цілком допустимий проект подання даних про постачальників Відзначимо, що даний кортеж з даними про постачальника S3 повинен знаходитися в обох

змінних відносини Припустимо протилежне, тобто що він знаходиться у змінній відносини SB, але відсутній у змінній відносини SA Застосувавши допущення про замкнутість світу до змінної відносини SA, можна зробити висновок, що постачальник з номером S3 не знаходиться в Парижі Але дані в змінній відносини SB свідчать про зворотне, тобто про те, що він знаходиться в Парижі Інакше кажучи, ми отримали протиріччя, і, отже, база даних знаходиться в суперечливому стані

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

Принцип ортогонального проектування {Початкова версія) Ніякі дві змінні відносини в базі даних не повинні мати перекриваються смислових значень

З цього випливають наведені нижче висновки

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

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

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

Наведемо кілька додаткових зауважень з приводу останнього пункту Безумовно, що в даний час при вставці кортежу зазвичай потрібно вказувати імя тієї змінної відносини R, в яку вставляється даний кортеж Але це аж ніяк не суперечить наведеним вище доводам, оскільки, по суті, імя R є всього лише скороченим позначенням для відповідного предиката (Припустимо, PR) Дійсно, команда вставки має такий зміст: INSERT кортеж t, де t повинен задовольняти предикату PR Більш того, змінна відносини R може бути поданням, певним, наприклад, за допомогою виразу типу A UNION в Як було сказано в главі 10, дуже бажано, щоб системі було відомо, куди вставляти новий кортеж-тільки в змінну відносини А, тільки в змінну відносини в або одночасно в обидві ці змінні відносини

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

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

Перш ніж завершити обговорення принципу ортогонального проектування, необхідно зробити одну важливу поправку На рис 138 показаний ще один приклад явно поганого, але цілком допустимого проекту відносин з даними про постачальників У цьому випадку дві змінні відносини самі по собі не мають перекриватися смислового значення, але їх проекції по атрибутах {S #, SNAME}, безумовно, мають таке значення Внаслідок цього спроба вставки деякого кортежу, наприклад, (S 6, Lopez), в подання, визначене як обєднання цих двох проекцій, призведе до вставки кортежу (S 6, Lopez, t) в змінну відносини SX і кортежу (S 6, Lopez, с) – в змінну відносини SY (де t і з – відповідні використовувані за замовчуванням значення) Ясно, що для усунення подібних проблем принцип ортогонального проектування необхідно дещо розширити

Рис 138 Ще один невдалий, але цілком допустимий варіант проекту відносин з даними про постачальників

■&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp П ри нці п орто го на л ь но го пр е кт і р про в а н ия{Вікон ч а тель н а я версія)Порожній ь А і B явл я ються двома різними базовими змінними відносини в деякій базі даних Тоді для змінних відносини А і в не повинно існувати декомпозицій без втрат, відповідно, на такі проекції А1, А2, .., Am і Bl, B2, .., Вт, що деяка проекція Ai в безлічі проекцій А1, А2, .., Am і деяка проекція Bj в безлічі проекцій Bl, B2, .., Вт володітимуть перекриваються смисловими значеннями

З цього випливають наведені нижче висновки

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

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

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

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

Додаткові зауваження

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

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

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

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

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

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

ACTIVITIES_2001{ ENTRY#,DESCRIPTION,   AMOUNT, NEW_BAL }

ACTIVITIES_2 002{ ENTRY#,DESCRIPTION,   AMOUNT, NEW_BAL }

ACTIVITIES_2 003{ ENTRY*,DESCRIPTION,   AMOUNT, NEW_BAL }

ACTIVITIES_2004{ ENTRY*,DESCRIPTION,   AMOUNT, NEW_BAL }

ACTIVITIES_2005{ ENTRY*, DESCRIPTION,   AMOUNT, NEW_BAL }

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

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

■ A UNION в Завжди є обєднанням непересічних відносин

■ A INTERSECT в Завжди є порожнім ставленням

■ A MINUS в Завжди одно А

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

*

*