ПРОЕКТ хронологічно БАЗИ ДАНИХ

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

VAR S_SINCE BASE RELATION

{ S#    S#,     S#_SINCE

DATE, SNAME NAME,    SNAME_SINCE DATE, STATUS INTEGER, STATUS_SINCE DATE, CITY  CHAR,   CITY_SINCE DATE } KEY { S# }

VAR  S_DURING BASE RELATION J

{  S#                                           S#,

DURING  INTERVAL^DATE  }

9 Зверніть особливу увагу на те, що в цьому проекті мінлива відносини SSINCE відрізняється від змінної відносини SSINCE з розділу 232

KEY { S#, DURING }

VAR S_STATUS_DURING BASE RELATION

{ S#    S#, STATUS INTEGER,

DURING INTERVAL_DATE }

KEY { S#, DURING }

VAR

S_NAME_DURING BASE RELATION

{ s#   s#, SNAME  NAME,

DURING INTERVAL_DATE }

KEY { S#, DURING }

VAR

S_CITY_DURIN G                                        BASE RELATION   { S#    S#,

CITY  CHAR,

DURING INTERVAL_DATE } KEY { S#, DURING }

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

■ S_SINCE Постачальник S # працював за контрактом починаючи від тимчасової позиції S # _SINCE, носив імя SNAME починаючи від тимчасової позиції SNAME_SINCE, мав статус STATUS починаючи від тимчасової позиції STATUS_SINCE і знаходився в го роді CITY починаючи від тимчасової позиції CITY_SINCE

■ S_DURING Постачальник s # працював за контрактом протягом інтервалу

DURING

■ S_NAME_DURING Постачальник s # носив імя SNAME протягом інтервалу

DURING

■ S_STATUS_DURING Постачальник s # мав статус STATUS протягом інтервалу

DURING

■ S_CITY_DURING Постачальник S # знаходився в місті CITY протягом інтер валу DURING

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

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

інформація – у множині змінних відносини з атрибутами у вигляді інтервалу.

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

Горизонтальна декомпозиція

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

■ Стосовно до історичної інформації, відомо і час початку, і час закінчення відповідного інтервалу

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

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

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

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

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

S_SINCE { S#, SNAME, STATUS, CITY, SINCE }

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

а) постачальник S # працював за контрактом

б) постачальник S # носив імя SNAME

в) постачальник S # мав статус STATUS

г) постачальник S # знаходився в місті CITY

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

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

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

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

Вертикальна декомпозиція

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

S_DURING { S#, SNAME, STATUS, CITY, DURING }

Нижче наведений предикат цієї змінної відносини

Протягом інтервалу DURING все наступні чотири висловлювання були істинними:

. а) постачальник S # працював за контрактом

б) постачальник S # носив імя SNAME

в) постачальник S# мав статус STATUS

г) постачальник Si знаходився в місті CITY

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

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

Тепер слід зазначити, що для подання інформації про те, що статус протягом інтервалу [d02: d03] дорівнював 10, застосовуються два окремих кортежу замість одного, а для подання інформації про те, що протягом інтервалу [d03: d04] містом постачальника був Париж, також використовуються два окремих кортежу замість одного

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

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

S_DURING                                          { S#, DURING } KEY { S#, DURING }

S_NAME_DURING  { S#, SNAME, DURING } KEY { S#, DURING }

S_STATUS_DURING { S#, STATUS, DURING } KEY { S#, DURING }

S_CITY_DURING  { S#, CITY, DURING } KEY { S#, DURING }

Мінлива відносини S_DURING показує, коли той чи інший постачальник працював за контрактом, змінна відносини S_NAME_DURING показує, коли той чи інший постачальник носив те чи інше імя, змінна відносини S_STATUS_DURING показує, коли той чи інший постачальник мав той чи інший статус, а змінна відносини S_CITY_DURING показує, коли той чи інший постачальник знаходився в тому чи іншому місті

Шоста нормальна форма

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

визначенням є операцією вертикальної декомпозиції), а відповідної операцією рекомпозиції є зєднання Безумовно, як було описано в розділі 13, саме з цих причин остаточну (з точки зору класичної теорії нормалізації) нормальну форму, тобто пяту нормальну форму (скорочено 5НФ) іноді називають проекційно-сполучної нормальною формою

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

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

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

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

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

Нагадаємо, що пята нормальна форма заснована на так званих залежностях зєднання (Join Dependency-JD) Як нагадування відзначимо також, що змінна відносини R задовольняє JD * {А, B, .., Z} (де A, B, .., Z – підмножини атрибутів R) тоді і тільки тоді, коли кожне допустиме значення R одно зєднанню його проекцій за атрибутами А, в, , Z, тобто тоді і тільки тоді, коли може бути виконана декомпозиція R без втрат по цих проекціям А оскільки в

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

■ Припустимо, що R-змінна відносини, А, B, , Z – підмножини атрибутів R, a ACL – розділений комами список атрибутів R зі значеннями у вигляді інтервалу Тоді можна стверджувати, що R задовольняє узагальненої Залежно зєднання

USING (ACL) * {А, В, .., Z}

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

USING   (  ACL  )   ◄ R  =  R’ ►

Тут R – і_соедіненіе U_проекцій змінної відношення R за атрибутами А, B, , Z, притому що всі розглянуті U_соедіненія і U_проекціі включають специфікацію US ING у формі US ING {ACL)

Примітка У цьому визначенні за замовчуванням визнається істинним той факт, що операція U_зєднання, як і операція зєднання, є асоціативною це означає, що визначення, в якому йдеться про операцію U_соедіненія будь-якої кількості відносин, не містить протиріччя Слід також зазначити, що твердження про те, що наведене вище вираз є істинним, рівносильно твердженням, що R і R еквівалентні (по відношенню до списку ACL) див обговорення поняття еквівалентності в самому кінці розділу 234 Мінлива відносини R знаходиться в шостий нормальній формі (скорочено 6НФ) тоді і тільки тоді, коли вона задовольняє всім нетривіальним залежностям зєднання взагалі, де залежність зєднання є тривіальною тоді і тільки тоді, коли щонайменше одна з розглянутих проекцій (можливо, U_проекцій) виконується по всіх атрибутів зазначеної змінної відносини

З цього визначення безпосередньо випливає, що кожна змінна відносини, яка знаходиться в 6НФ, знаходиться також в 5НФ Крім того, з нього також безпосередньо випливає, що будь-яка змінна відносини знаходиться в 6НФ тоді і тільки тоді, коли вона Непріводімие, в тому сенсі, що визначений вище

Отже, відзначимо, що версія змінної відносини S_DURING, яка має атрибути s #, SNAME, STATUS, CITY і DURING, згідно з цим визначенням не знаходиться в

6НФ, оскільки вона володіє наступними характеристиками:

а) ця змінна відносини задовольняє узагальненої залежності зєднання USING DURING * {SND, STD, SCD} (де ІМЯ SND НАЛЕЖИТЬ До безлічі атрибутів {S #, SNAME, DURING}, а імена STD і SCD мають аналогічні ухвали)

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

Тому автор рекомендує виконати декомпозицію зазначеної змінної відносини на проекції 6НФ, як було описано в попередньому підрозділі

Примітка Читач міг помітити, що в наведеному вище прикладі було б досить виконати декомпозицію тільки на три змінні відносини, а не на чотири змінні відносини 6НФ, оскільки, строго кажучи, в цій декомпозиції мінлива відносини S_DURING з атрибутами s # і DURING не потрібна це повязано з тим, що вона завжди дорівнює (узагальненої) проекції по атрибутах s # і DURING будь-який з трьох інших змінних відносини Проте, автор вважав за краще включити змінну відносини S_DURING в загальний проект почасти просто для повноти, а частково через те, що завдяки такому включенню вдається певною мірою запобігти створення громіздкого і надуманого проекту, який зявився б в іншому випадку

[234]

Визначення рухається по часовій шкалі позиції поточного часу

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

Розглянемо випадок з постачальником, контракт якого ще не закінчився Безумовно, цілком можливо, що передбачуваний час завершення цього контракту відомо, але, взагалі кажучи, найчастіше відомо лише те, що контракт продовжується автоматично (як приклад можна вказати типові контракти, які укладаються при наймі на роботу) Тому, яке б значення не було вказано як атрибуту END (DURING) для такого постачальника до змінної відносини з даними, позначають часовий інтервал, воно все одно швидше за все виявиться хибним Безумовно, можна було б і навіть, мабуть, потрібно прийняти угоду, що такі значення атрибута END (DURING) повинні задаватися як останню добу розглянутого часового інтервала10 (тобто як значення, що повертається функцією LAST_DATE ()) Але слід зазначити, що така схема означає, що якщо значення останню добу зявиться в результатах запиту, то користувач, ймовірно, зобовязаний інтерпретувати це значення як до додаткового повідомлення , а не власне як останню добу . Іншими словами, стверджувати, що атрибут END (DURING) для такого постачальника має значення останню добу, означає майже напевно – давати неправдиву інформацію

Саме для того, щоб уникнути необхідності включати до бази даних таку неправдиву інформацію, деякі автори (див, наприклад, [232]) запропонували використовувати спеціальний маркер NOW (Зараз) для позначення того, що в розділі 231 було визначено як рухається по часовій шкалі позиція поточного часу (Іншими словами, для позначення поняття до додаткового повідомлення) Основна ідея полягає в тому, що потрібно дозволити включати цей спеціальний маркер там, де, вправах, дозволено застосування відповідного позиційного тимчасового типу, і, подруге, дійсно надати йому намічену інтерпретацію як до додаткового повідомлення. Таким чином, наприклад, змінна відносини S_DURING може включати, допустимо, кортеж з даними про постачальника S1 зі значенням DURING, рівним [d04: NOW], а не [d04: d99] (Тут передбачається, що 99-у добу – це останні добу і дане конкретне поява значення d99 дійсно повинно розглядатися як має сенс До додаткового повідомлення, а не позначає 99-у добу як такі)

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

10 Безумовно, можна замінювати це штучне значення істинним значенням після того, як це справжнє значення стає відомо

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

■ Припустимо, що i-інтервал [N0W: dl4], t – кортеж, що містить інтервал i, а сьогодні – десяту добу У такому випадку кортеж t може розглядатися як свого роду скорочене позначення пяти окремих кортежів, що містять одиничні інтервали, відповідно, [dl 0: dl ​​0], [dll: dll], [dl 2: dl 2],

f dl 3: dl 3] і [d l4: d l4] Але після того, як час підійде до півночі в деся ту добу, перший з цих кортежів повинен бути (по суті) автоматично знищений Аналогічна ситуація виникне в 11-е добу, 12-у добу, 13-е добу, .., і що фактично відбудеться опівночі в 14-у добу

■ Яким є результат порівняння d9 9 = NOW

■ Яким є значення виразу N0W +1 або N0W-1?

■ Якщо il і i2 являють собою, відповідно, інтервали [d01: NOW] і

[D 06: d07], то чи є ці інтервали суміжними або перекриваються

■ Яким є результат розпаковування відносини, що містить кортеж, в кото ром інтервальний атрибут, призначений для розпакування, має значення [d04: NOW]

■ Яка кардинальність безлічі {[d01: NOW], [d01: d04]}

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

233 ОБМЕЖЕННЯ ЦІЛІСНОСТІ ХРОНОЛОГІЧНИХ БАЗ ДАНИХ

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

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

S_STATUS_DURING  {   S#,   STATUS,    DURING   } KEY  {   S#,    DURING  }

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

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

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

Проблема надмірності

Обмеження KEY для змінної відносини S_STATUS_DURING, хоча і логічно правильне, в певному сенсі є недостатнім А саме – воно не в змозі запобігти появі в цій змінній відносини, наприклад, обох наступних кортежів одночасно

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

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

Проблема багатослівя

Обмеження KEY для змінної відносини S_STATUS_DURING є також незадовільним з іншої причини А саме – воно не дозволяє запобігти появі в цій змінній відносини, наприклад, обох наступних кортежів одночасно

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

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

Усунення проблем надмірності і багатослівя

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

Обмеження А Якщо в будь-який визначений момент часу змінна відносини S_STATUS_DURING містить два різних кортежу, які є повністю ідентичними, за винятком своїх значень i1 і i2 атрибута DURING, то вираз il MERGES i2 повинно бути помилковим

Нагадаємо, що, неформально висловлюючись, операція MERGES є результатом застосування логічної операції АБО до операцій OVERLAPS і MEETS: якби ми замість неї включили в обмеження А операцію OVERLAPS, то отримали б обмеження, яке необхідно ввести в дію, щоб уникнути виникнення проблеми надмірності, а якби замість операції MERGES була включена в обмеження А операція MEETS, то було б отримано обмеження, яке необхідно ввести в дію, щоб уникнути виникнення проблеми багатослівя

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

VAR S_STATUS_DURING BASE RELATION ( S# S#, STATUS INTEGER, DURING INTERVAL_DATE } PACKED ON DURING KEY { S#, DURING }

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

962 Частина V Додаткові теми

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

згадуване під назвою обмеження XFT1 в розділі 232

Проблема протиріччя

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

Тут показано, що постачальник S4 в пятому і шосту добу має одночасно і статус 10, і статус 25, – безумовно, такий стан справ є неприпустимим Іншими словами, маємо суперечність фактично ця змінна відносини знову порушує свій власний предикат, оскільки передбачається, що в будь окремо взяті добу кожен постачальник повинен мати один і тільки один статус

Рішення проблеми протиріччя

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

Обмеження в Якщо в будь-який визначений момент часу змінна відносини S_STATUS_DURING містить два кортежу S #, які розрізняються за своїм значенням STATUS, то для них значення i1 і 12 атрибута DURING повинні бути такими, що вираз i1 OVERLAPS i 2 є помилковим

Слід звернути особливу увагу на те, що підтримку обмеження У (як уже було показано), безумовно, не можна забезпечити просто за рахунок того, що змінна відносини буде постійно залишатися упакованої по атрибуту DURING Ще більш очевидно те, що не можна забезпечити виконання цього обмеження лише за рахунок того, що поєднання атрибутів {S #, DURING} буде визначено як потенційний ключ Але припустимо, що змінна відносини постійно залишається розпакованої по атрибуту DURING (на час будемо ігнорувати той факт, що дане припущення фактично виконати неможливо, оскільки вже було обумовлено така вимога, що змінна відносини повинна постійно залишатися упакованої по атрибуту DURING) У такому випадку буде підтримуватися описане нижче стан

■ Всі значення DURING в цій розпакованої формі представлятимуть собою еди нічной інтервали і тому фактично будуть відповідати окремим вре менним позиціях

■ Єдиним потенційним ключем для цієї розпакованої форми продовжуватиме залишатися безліч атрибутів {S #, DURING}, оскільки в цей врємя будь-який окремо взятий постачальник, працює за контрактом, буде мати один і тільки статус в кожен конкретний момент часу

З цього випливає, що якщо б ми мали можливість ввести в дію таке обмеження, згідно з яким безліч атрибутів {S #, DURING} було б потенційним КЛЮЧЕМ ДЛЯ розпакованої форми UNPACK S_STATUS_DURING ON DURING, TO чинності

цього ввели би в дію обмеження в Тому автор пропонує створити нове обмеження, WHEN / THEN, яке може бути присутнім у визначенні змінної відносини скрізь, де може бути присутнім просте ограніченіеКЕУ, як показано нижче

VAR S_STATUS_DURING BASE RELATION

{ S# S#, STATUS INTEGER, DURING INTERVAL_DATE }

PACKED ON DURING WHEN UNPACKED ON DURING THEN KEY { S#, DURING } KEY { S#, DURING }

Тут вираз WHEN UNPACKED ON DURING THEN KEY {s #, DURING} представляє собою обмеження для змінної відносини S_STATUS_DURING (воно знову-таки є обмеженням для змінної відносини, як і описане вище обмеження PACKED ON) ЦЕ вираз інтерпретується таким чином: мінлива відносини S_STATUS_DURING повинна постійно залишатися такою, щоб ніякі два кортежу в результатах вираження UNPACK S_STATUS_DURING ON DURING не мали одного і того ж значення комбінації атрибутів {S #, DURING} (неформально можна стверджувати, що {S #, DURING} є потенційним ключем для результатів вираження UNPACK S_STATUS_DURING ON DURING ) Таким чином, для вирішення проблеми суперечності також досить ввести зазначену вище спеціальну синтаксичну конструкцію

U_ключі

Щодо обмежень KEY, PACKED ON і WHEN / THEN можна було б навести значно більше відомостей [234] але через обмеження за обсягом наведемо лише такі висновки По-перше, автор пропонує передбачити можливість вводити у визначення будь-якої конкретної змінної відносини R скорочені специфікації у зазначеній нижче формі

USING (ACL) KEY {До}

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

PACKED ON ( ACL )

WHEN UNPACKED ON (ACL) THEN KEY {До} KEY {До}

Автор пропонує скорочено називати {До} як U_ключ (Але см наведене нижче опис) З використанням цього скорочення, наприклад, визначення змінної відносини S_STATUS_DURING можна спрощено представити таким чином

VAR S_STATUS_DURING BASE RELATION

{ S# S#, STATUS INTEGER, DURING INTERVAL_DATE } USING DURING KEY { S#, DURING }

Тепер припустимо, що в специфікації U_ключа для змінної відносини R розділений комами список імен атрибутів ACL порожній, тому має місце наступна конструкція

USING () KEY {До}

За визначенням ця специфікація є скороченим позначенням наступній комбінації обмежень

PACKED ON ( )

WHEN UNPACKED ON () THEN KEY {До} KEY {До}

Іншими словами, в оголошенні змінної відносини R задані наведені нижче вимоги

1 Мінлива відносини R повинна залишатися упакованої взагалі ні по одному атрибуту Але операція упаковки відносини r взагалі ні по одному атрибуту про сто повертає r, тому неявно задана специфікація PACKED ON НЕ оказ кість ніякої дії

2 Мінлива відносини R повинна бути такою, що якщо вона розпакована взагалі ні по одному атрибуту, то {до} є потенційним ключем для отриманого результату Але операція розпакування відносини r взагалі ні по одному атрибуту просто повертає r, тому неявно задана специфікація WHEN / THEN просто означає, що {до} є потенційним ключем для R, і тому неявне ог раничения KEY стає надлишковим

З цього випливає, що замість деяких обмежень U_ключа можна в якості скороченого позначення застосовувати звичайне обмеження KEY у формі KEY {До}, а саме скорочення у формі USING () KEY {До} Іншими словами, звичайні обмеження KEY, по суті, являють собою просто окремий випадок запропонованого автором нового синтаксису Тому, якщо синтаксис звичайного обмеження клієнта KEY буде перевизначений наступним чином:

[USING (ACL)] KEY {До}

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

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

USING DURING FOREIGN KEY { S#, DURING

} REFERENCES S_DURING

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

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

Девять вимог

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

■ Вимога R1 Якщо в базі даних показаний постачальник Sx як працює за контрактом на добу d, то вона повинна містити один і тільки один кортеж, який показує цей факт

■ Вимога R2 Якщо в базі даних показаний постачальник Sx як працює за контрактом на добу d і d +1, то вона повинна містити один і тільки один кортеж, який показує цей факт

■ Вимога R3 Якщо в базі даних показаний постачальник Sx як працює за контрактом на добу d, то вона повинна також показувати постачальника Sx як маю щий певний статус на добу d

■ Вимога R4 Якщо в базі даних показаний постачальник Sx як має визна ленний статус на добу d, то вона повинна містити один і тільки один кортеж, до торий показує цей факт

■ Вимога R5 Якщо в базі даних показаний постачальник Sx як має один і той же статус на добу d і d +1, то вона повинна містити один і тільки один кортеж, який показує цей факт

■ Вимога R6 Якщо в базі даних показаний постачальник Sx як має визна ленний статус на добу d, то вона повинна також показувати постачальника Sx як ра працюючого за контрактом у добу d

■ Вимога R7 Якщо в базі даних показаний постачальник Sx як здібний постав лять деяку певну деталь Ру на добу d, то вона повинна містити один і тільки один кортеж, який показує цей факт

■ Вимога R8 Якщо в базі даних показаний постачальник Sx як здібний постав лять одну і ту ж деталь Ру на добу d і d +1, то вона повинна містити один і лише то один кортеж, який показує цей факт

■ Вимога R9 Якщо в базі даних показаний постачальник Sx як здібний поставляти деяку деталь Ру на добу d, то вона повинна також показувати постачальника Sx як працює за контрактом на добу d

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

234 РЕЗЮМЕ

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

Потім у цій главі був представлений дуже простий робітник приклад (база даних постачальників і поставок) і були виконані наступні дії: по-перше, полухронологізація цієї бази даних шляхом введення атрибутів SINCE, і, по-друге, її повна хронологізація шляхом введення атрибутів FROM і ТО Крім того, було показано, що впровадження обох цих проектів призводить до значного зростанню складності формулювань обмежень і запитів Тому була запропонована ідея розглядати інтервали як самостійні значення, тобто було визначено поняття позиційного типу та генератора типу INTERVAL, після чого дано опис відповідних операторів селектора інтервалу, а також операторів BEGIN І END Надалі було визначено багато інших операторів для позицій і інтервалів, включаючи оператори Аллена і такі оператори з інтервалами, як UNION, INTERSECT І MINUS

На наступному етапі були визначені два надзвичайно важливих реляційних оператора, званих PACK І UNPACK (А в якості проміжного етапу на шляху до їх визначення були введені два простіших оператора на унарних відносинах, звані COLLAPSE і EXPAND) Оператори EXPAND і UNPACK дозволяють зосередитися на вивченні інформаційного наповнення їх реляційних фактичних параметрів на рівні нерозривних компонентів, не турбуючись про те, що існує безліч різних способів, за допомогою яких ця інформація може бути обєднана в проміжні конгломерати. Аналогічним чином, оператори COLLAPSE і PACK дозволяють зосередитися на інформаційному наповненні їх реляційних фактичних параметрів, представленому в стислій (конгломерірованной) формі, не турбуючись про те, що може існувати ймовірність сполучення або перекриття окремих конгломератів. Було також показано, як можна скористатися операторами PACK і UNPACK для спрощення формулювань хронологічних запитів Крім того, ці

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

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

Після цього були проаналізовані деякі проблеми, які можуть бути повязані з використанням хронологічних даних у відсутність прийнятних обмежень цілісності (а саме проблеми надмірності, багатослівя і протиріччя) і було показано, як можливі обмеження PACKED ON І WHEN / THEN ДЛЯ вирішення зазначених проблем Була визначена узагальнена версія звичайного обмеження KEY, що отримала назви обмежень U_ключа, і потім показано, що звичайне обмеження KEY фактично є просто окремим випадком узагальненої версії

Нижче наведено два заключних зауваження до даної глави

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

■ Рекомендований автором підхід до проектування (зокрема горизонтальна декомпозиція) тягне за собою такі наслідки, що застосовувані запити (а так само, у разі необхідності, оновлення) часто охоплюють кілька змін них відносини і тому можуть виявитися досить складними В [234] наведено ряд пропозицій щодо введення додаткових скорочень, що дозволяють устра нитка також і ці складності

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

*

*