Хронологічні бази даних

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

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

‘ можуть містити дані, що відносяться не тільки до минулого, але і до майбутнього, тому термин&quotисторический&quotследуетпониматькакохватывающийиэтувозможность

час статус постачальника S1 дорівнює 20, але і те, що він дорівнював 20 з 1 липня минулого року, а також, можливо, що він дорівнював 15 з 5 квітня до 30 червня минулого року і тд

Дослідження в області хронологічних баз даних інтенсивно проводилися, по

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

■ Чи має час початок або кінець

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

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

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

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

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

Постачальник S1 працював за контрактом від 1 липня 2003 року

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

Цей кортеж включає атрибут номера постачальника s # і два атрибути з тимчасовими відмітками, FROM і те відповідне висловлювання з тимчасовими відмітками наведено нижче

2 Вовсейданнойглавенеуточненныйтермин&quotпредикат&quotиспользуетсядляобозначениятогопонятия, яке в розділі 9 іменувалося

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

Постачальник S1 працював за контрактом протягом інтервалу часу від 1 травня

2002 до 30 квітня 2003 року

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

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

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

2 Вираз протягом інтервалу часу розглядається як позна чающие протягом вказаного інтервалу часу, не включаючи того часу, який безпосередньо передує або безпосередньо слідує за цим ін інтервалом . Тому, якщо сказано, що постачальник S1 працював за контрактом протягом інтервалу часу від 1 травня 2002 до 30 квітня 2003 року, під цим мається на увазі, по-перше, що постачальник S1 працював за контрактом протягом всього інтервалу часу від 1 травня 2002 року по 30 квітня 2003 включітельно3

і, крім того, по-друге, що 30 квітня 2002 постачальник S1 ще не працював за контрактом, а 1 травня 2003 вже не працював за контрактом

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

Деякі фундаментальні допущення

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

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

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

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

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

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

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

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

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

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

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

слідують наведені нижче висновки

■ Послідовність тимчасова / х позицій має початок і кінець Іншими словами, в послідовності є унікальна початкова позиція, яка соответству ет початку відліку часу, і унікальна кінцева позиція, відповідна кон цу відліку часу

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

Інтервал часу визначається як непорожній відрізок тимчасової шкали4 Говорячи точніше, інтервал часу, що має початкову тимчасову позицію Ь і кінцеву тимчасову позицію в, може розглядатися як підпослідовність тимчасової шкали, що складається з усіх тимчасових позицій р, таких що b < р < е (де "<" означає "раніше ніж").

Робочий приклад

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

1 Мінлива відносини деталей Р повністю виключена

2 Мінлива відносини постачальників S спрощена шляхом видалення всіх атрибутів, крім s # Предикат для цієї переглянутої (і суттєво спрощеною) Пе пасової відносини полягає в наступному твердженні

Постачальник s # нині працює за контрактом

3 Атрибут QTY із змінної відносини поставок SP видалений, і ця переглянута мінлива відносини інтерпретується таким чином

Постачальник s # нині здатний поставляти деталь P#

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

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

На рис 231 показано безліч значень, що застосовуються в якості прикладу в цій спрощеної базі даних

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

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

Обмеження (первісна база даних) Єдині обмеження, які бажано врахувати, наведені нижче

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

■ {S #} і {S #, P #} є первинними ключами, відповідно, для змін них отношенія5 S і SP

■ {S #} є зовнішнім ключем у змінній відносини SP, який посилається на первинний ключ змінної відносини S

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

■ Запит А Отримати номери постачальників, які в даний час здатні поставляти щонайменше одну деталь

SP   {   S#   }

■ Запит в Отримати номери постачальників, які в даний час не здатні поставляти взагалі жодної деталі

S   {  S#   }  MINUS  SP  {  S#  }

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

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

Рис 231 База даних постачальників і поставок (початкова версія) і приклади значень

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

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

цілий ряд операцій для роботи з такими інтервалами часу У розділі 234 розглядаються два надзвичайно важливих реляційних оператора, PACK і UNPACK Після цього в розділі 235 наведений опис узагальнених версій знайомих операцій реляційної алгебри нарешті, розділи 236 і 237, відповідно, присвячені проблемам проектування баз даних і застосування обмежень цілісності

231 ЗАГАЛЬНА ПОСТАНОВКА ПРОБЛЕМИ

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

Рис 232 База даних постачальників і поставок (полухронологіческая версія) і приклади значень

Для спрощення на рис 232 не показані справжні тимчасові позначки натомість на даному малюнку використовуються символічні позначення у формі dOl, dO2 і тд, де d – Скорочення від day (Добу) цієї угоди ми будемо дотримуватися протягом всієї даної глави (У більшості розглянутих тут прикладів використовуються тимчасові / е позиції, що представляють собою саме добу, тому відповідна ступінь деталізації в цих прикладах становить одну добу) Передбачається, що перші добу безпосередньо передують другим добі, другу добу безпосередньо передують третій добі і тд; крім того, незначущі нулі в таких виразах, як першу добу», не будуть вказані (приклади таких виразів нам щойно зустрілися в них не застосовуються, припустимо, слова нуль-перше добу)

Нижче наведені предикати для змінних відносини S_SINCE і SPSINCE

■ S_SINCE Постачальник s # працював за контрактом від доби SINCE

■ SP_SINCE Постачальник s # був здатний поставляти деталь Р # від доби SINCE

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

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

VAR S_SINCE BASE RELATION { S# S#, SINCE DATE } KEY { S# }

VAR SP_SINCE BASE RELATION { S# S#, P# P#, SINCE DATE } KEY { S#, P# } FOREIGN KEY { S# } REFERENCES S_SINCE

Застосовуваний тут тип DATE представляє грегоріанському дати під цим маються на увазі дати, що визначаються з точністю до доби і що обмежуються правилами грегоріанського календаря (з цього, крім усього іншого, випливає, що, наприклад, дати 31 квітня 2005 року« і 29 лютого 2100 не є допустимими)

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

CONSTRAINT XST1 / * XST1 скорочення від extra semitemporal constraint no 1 * /

/ * (Додаткове полухронологіческое обмеження № 1) * /

IS_EMPTY   (   (   (  S_SINCE  RENAME  SINCE  AS   SS  )

JOIN (  SP_SINCE RENAME SINCE AS SPS ) )

WHERE SPS &lt SS )

Це обмеження можна описати словами наступним чином: Якщо кортеж sp у змінній відносини SP_SINCE посилається на кортеж s у змінній відносини S_SINCE, то значення SINCE в кортежі sp не може бути менше, ніж відповідне значення в кортежі s . На підставі цього прикладу можна приступити до визначення важливої ​​проблеми – якщо доводиться мати справу з такою полухронологіческой базою даних, яка показана на рис 232, то, мабуть, доведеться сформулювати безліч обмежень такого ж спільного і досить дивного вигляду, як обмеження XST1 і тому незабаром виникне необхідність у використанні для цієї мети деякого зручного скорочення

Запити (Полухронологіческая база даних) Тепер розглянемо наведені нижче полухронологіческіе аналоги запросовА і в

■ Запит А Отримати номери постачальників, які в даний час здатні поставляти щонайменше одну деталь, показуючи в кожному випадку дату, починаючи від якої вони отримали таку можливість

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

SUMMARIZE SP BY { S# } ADD MIN ( SINCE ) AS SINCE

Отриманий результат виглядає наступним чином

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

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

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

Рис 233 База даних постачальників і поставок (перша повністю хронологічна версія, в якій використовуються явно задані атрибути

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

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

наштовхнути читача на роздуми про те, який механізм міг би забезпечити заміну всіх цих значень dlO значеннями dll після опівнічного удару годин, який відбудеться по закінченні десятого доби На жаль, поки ми змушені відкласти обговорення цього питання Ми повернемося до нього в розділі 236

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

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

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

S_FROM_TO Постачальник S # працював за контрактом протягом інтервалу вре мени від доби FROM ДО доби то

■ SP_FROM_TO Постачальник s # був здатний поставляти деталь р # протягом інтервалу часу від доби FROM до доби то

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

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

і почати роботу по іншому контракту на наступні ж добу

2 Жоден постачальник не може працювати одночасно за двома різними контрактами

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

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

ключем для змінної відносини S_FROM_TO (наприклад) не може бути просто {S #}, оскільки, якби це було так, то ми не могли б мати справу з такими постачальниками, як S2, які працювали за контрактом протягом двох або декількох окремих інтервалів часу Аналогічне зауваження стосується і до змінної відносини SP_FROM_TO

Примітка Замість атрибутів FROM до складу первинних ключів можна було ввести атрибути ТО насправді, обидві ці змінні відносини, S_FROM_TO і SP_FROM_TO, мають два потенційних ключа і служать наочними прикладами змінних відносини, при використанні яких немає очевидних причин для вибору одного з таких потенційних ключів в якості первинного [914] Такий вибір, як у цих прикладах, був зроблений виключно заради визначеності

Нижче наведено визначення на мові Tutorial D

VAR S_FROM_TO

BASE RELATION { S# S#, FROM DATE, TO DATE } KEY { S#, FROM } KEY { S#, TO }

VAR SP_FROM_TO

BASE RELATION { S# S#, P# P#, FROM DATE, TQ DATE ^ KEY { S#, P#, FROM }

KEY { S#, P#, TO }

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

FROM-TO, в яких значення те менше значення FROM, таким чином

CONSTRAINT S_FROM_TO_OK

IS_EMPTY ( S_FROM_TO WHERE TO &lt FROM )

CONSTRAINT SP_FROM_TO_OK

IS_EMPTY ( SP_FROM_TO WHERE TO &lt FROM )

Але описані досі обмеження досі не пропонують всіх тих можливостей, які хотілося б отримати з їх допомогою Наприклад, розглянемо змінну відносини S_FROM_TO Очевидно, що якщо в цій змінної відносини мається кортеж з даними про постачальника Sx зі значенням FROM, рівним f, і значенням ТО, рівним t, то хотілося б, щоб у тієї ж змінної відношення не було кортежу з даними про постачальника Sx, що вказують, що Sx працював за контрактом на добу, безпосередньо попередні f, або на добу, безпосередньо наступні за t Як приклад розглянемо постачальника S1, якого стосується лише один кортеж із змінної відносини S_FROM_TO, де FROM = dO4 і ТО = СПО Того факту, що {S #, FROM} є потенційним ключем для цієї змінної відносини, безумовно, не достатньо, щоб можна було запобігти появі додаткового, перекриває кортежу S1 (скажімо) з FROM = dO2 і ТО = dO6, який, крім усього іншого, вказував би, що S1 працював за контрактом на добу, безпосередньо наступні за четвертими цілодобово Безумовно, бажано, щоб ці два кортежу S1 були обєднані в один кортеж зі значеннями FROM = d02HTO = dlO

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

поява дублікатів Наявність дублікатів можна розглядати як равносильное повторення одного і того ж двічі. А в зазначених двох кортежах з даними про постачальника S1, в яких інтервали часу FROM-то перекриваються, дійсно одне і те ж повторюється двічі; а саме, в обох цих кортежах вказано, що постачальник S1 працював за контрактом в четверті, пяті і шості добу Насправді, якщо у змінній відносини S_FROM_TO зявляться обидва ці кортежу, то буде мати місце порушення того предиката, який ми самі для неї визначили Повернемося до цього питання і обговоримо його більш детально в розділі 237

Потім відзначимо, що того факту, що {S #, FROM} є потенційним ключем для змінної відносини S_FROM_TO, також недостатньо для запобігання можливості появи примикає кортежу si зі значенням (скажімо) FROM = d02 і

то = Сюз, який знову показує, що постачальник S1 працював за контрактом на добу,

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

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

CONSTRAINT XFT1

IS_EMPTY

( ( ( S_FROM_TO RENAME ( FROM AS Fl, TO AS Tl ) )

JOIN ( S_FROM_TO RENAME ( FROM AS F2, TO AS

T2 ) ) ) WHERE ( Tl &gt F2 AND T2 &gt Fl ) ) OR

( F2 = Tl+1 OR Fl = T2+1 ) )

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

Примітка Фактично в тому формулюванні обмеження XFT1, яка тут приведена, є ще один недолік, а саме – вона не дозволяє відповісти на питання про те, як буде обчислюватися вираз Т1 +1, якщо виявиться, що Т1 позначає кінцеву позицію інтервалу часу.

Далі відзначимо, що поєднання атрибутів {S #, FROM} у змінній відносини SP_FROM_TO не є зовнішнім ключем, що звязує цю змінну відносини з змінної відносини S_FROM_TO (навіть незважаючи на те, що в цьому поєднанні застосовуються такі ж атрибути, як і в первинному ключі змінної відносини S_FROM_TO) Але, безумовно, необхідно забезпечити гарантію того, що якщо деякий постачальник представлений у змінній відносини SP_FROM_TO, TO ОН повинен бути також представлений і у змінній відносини S_FROM_TO, таким чином

CONSTRAINT XFT2

SP_FROM_TO {S #} З S_FROM_TO {S #}

Це обмеження є прикладом залежності включення[114]  Залежності включення можуть розглядатися як узагальнення обмежень посилальної цілісності (про що було сказано в главі 11) До того ж має бути очевидно, що будь-яка хронологічна база даних, подібна наведеної на рис 233, швидше за все, буде містити велику кількість таких залежностей (принаймні, неявно)

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

CONSTRAINT XFT3

COUNT ( SP_FROM_TO { ALL BUT P# } ) =

COUNT ( ( ( SP_FROM_TO RENAME ( FROM AS SPF, TO AS SPT ) )

{ ALL BUT P# }

JOIN

( S_FROM_TO RENAME ( FROM AS SF, TO AS ST )

) ) WHERE SF &lt SPF AND ST &gt SPT )

У даному випадку інтуїція підказує, що якщо змінна відносини SP_FROM_TO включає кортеж, що позначає постачальника Sx як здібного поставляти деяку певну деталь від доби spf до доби spt, то змінна відносини S_FROM_TO повинна включати кортеж, що позначає постачальника Sx як працює за контрактом протягом того ж інтервалу часу (При цьому передбачається, що всі обмеження, описані до цього, набули чинності) Ми навмисно не наводимо тут подальший аналіз зазначеного обмеження, а зупинимося лише на тому зауваженні, що і це обмеження є досить складним і що нам знову, ймовірно, доведеться визначити безліч обмежень такого ж загального характеру в будь-якій реальній базі даних Тому і в цьому випадку, безумовно, бажано було б мати у своєму розпорядженні якісь зручні скорочення

Запити (Перша повністю хронологічна база даних) Нижче наведені повністю хронологічні аналоги запросовА і в

■ Запит А Отримати трійки значень S #-FROM-TO, що відносяться до постачальників, які були здатні поставляти щонайменше одну деталь протягом щонайменше одного інтервалу часу, де FROM і то разом визначають та кой інтервал часу Зверніть увагу на те, що результат цього запиту мо же містити кілька кортежів, які стосуються одного і того ж постачальника (але, безумовно, з різними інтервалами часу більше того, ці інтервали часу укладання не повинні ні сполучатися, ні перекриватися)

■ Запит в Отримати трійки значень S #-FROM-TO, що відносяться до постачальників, які взагалі не були здатні поставляти будь-які деталі протягом щонайменше одного інтервалу часу, де FROM і то разом визначають та кой інтервал часу (І цей результат може містити кілька кортежів для одного і того ж постачальника)

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

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

232 ІНТЕРВАЛИ ЧАСУ

Тепер перейдемо до розробки такого відповідного безлічі скорочень Першим і найбільш важливим кроком є ​​перехід до трактування інтервалів часу в якості самостійних значень, а не у вигляді пар окремих початкових і кінцевих значень, як було досі Наприклад, розглянемо інтервал часу від четвертої доби до десятих доби Для того щоб підкреслити той факт, що цей інтервал часу тепер розглядається як самостійне значення, він буде неформально позначатися за допомогою скороченого висловлювання [d04: dl0], а не за допомогою таких словесних оборотів, як інтервал часу від четвертої доби до десятих діб . Більш конкретно прийняті угоди описані нижче

■ Значення зразок [d04: dl0] називається значенням інтервалу часу або зі кращения просто інтервалом часу

іЗначення d04 і dl0, відповідно, є початкової часової позицією і кінцевої тимчасової позицією цього значення інтервалу часу

■ Значення інтервалу часу відноситься до певного інтервального типу

■ Цей інтервальний тип визначений на підставі деякого позиційного типу

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

Предикати цієї бази даних наведені нижче

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

■ SP_DURING Постачальник S # був здатний поставляти деталь Р # протягом інтервалу часу від початкової позиції інтервалу часу DURING до кінцевої позиції інтервалу часу DURING

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

■&nbsp&nbsp&nbsp&nbsp Повний впорядкування, відповідно до якого для будь-якої пари значень v1 і v2 типу т визначений оператор >; якщо значення vl і v2 різні, то одне і тільки один з виразів vl> v2 і v2> vl є істинним, а інше – хибним

Примітка Як було зазначено в розділі 5, для типу т, безумовно, визначений оператор =. Якщо відомо, що визначено також оператор > (А також відомо, що доступний логічний оператор NOT), то можна цілком обгрунтовано вважати, що для всіх пар значень типу т фактично доступні і всі звичайні оператори порівняння: =, *, >, >, <", і "<".

■ Нуль-арні оператори FIRST_T І LAST_T, які повертають, відповідно, перше і останнє значення типу т, виходячи зі згаданого вище повного упо рядкування

Унарні операториNEXT_T  ІPRIOR_T,  які повертають, відповідно, попереднє і наступне значення для будь-якого конкретного значення типу т виходячи з згаданого вище повного упорядкування

Примітка NEXT_T – це функція визначення подальшого значення для типу т безумовно, результат виразу NEXT_T (p) не визначений, якщо р = LAST_T () Аналогічним чином, не визначений і результат вираження

PRlOR_T (p), якщо р = FIRST_T ()

Рис 234 База даних постачальників і поставок (друга повністю хронологічна версія, в якій використовуються інтервали) і приклади значень

Потім определім6генератор типу INTERVAL ЯКЩОТ– Позиційний тип, то INTERVAL_T – цеінтервальний тип,отриманий шляхом виклику відповідного генератора типу т

6 Слід зазначити, що генератор типу INTERVAL є єдиною конструкцією, описаної в цьому розділі, яка не є просто скороченим позначенням Тому застосовуваний автором підхід до визначення хронологічних баз даних (на відміну від деяких інших підходів, описаних в літературі) не передбачає введення будь-яких змін в класичну реляційну модель (хоча й повязаний з необхідністю ввести деякі узагальнення, як буде показано в розділах 235 і 237)

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

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

INTERVAL_T ([b: е])

Тут b і е – Вирази типу т, і загальний виклик селектора повертає значення інтервалу з початковою і кінцевою позиціями, які дорівнюють значенням, позначеним цими виразами

■ Відповідні оператори ТНЕ_, BEGIN І END, мають наступний синтаксис

BEGIN   (   i   ) END    (   i   )

Тут i – вираз деякого інтервального типу, і ці два виклики операторів повертають, відповідно, початкову та кінцеву позиції інтервалу, позначеного цим виразом

Примітка Як вже було зазначено, оператори BEGIN and END фактично є операторами ТНЕ_, а в мові Tutorial D такі оператори зазвичай позначаються як THE_BEGIN і THE_END Але замість цього тут і далі у цій главі для узгодження з іншими роботами в галузі дослідження хронологічних баз даних використовуються позначення BEGIN і END

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

■ Розглянемо тільки одне універсальне обмеження, а саме обмеження, згідно з яким, якщо i є інтервалом, то BEGIN (i) < END (i). Одним з наслідків цього обмеження є те, що інтервали ніколи не бувають порожніми - вони завжди містять щонайменше одну позицію. Іншим наслідком стає те, що більше не потрібні явні обмеження, "що дозволяють запобігти появі безглуздих пар FROM-TO, в яких значення те менше значення FROM " (Як було зазначено в попередньому розділі).

Тепер має бути очевидно, що тип DATE, зокрема, задовольняє вимогам до позиційного типу і тому може використовуватися як такого типу Отже, INTERVAL_DATE – це допустимий інтервальний тип, тому визначення змінних відносини S_DURING і SP_DURING можуть виглядати приблизно так

VAR S_DURING BASE RELATION

{ S# S#, DURING INTERVAL_DATE } KEY { S#, DURING }

VAR SP_DURING BASE RELATION

{ S# S#, P# P#, DURING INTERVAL_DATE } KEY { S#, P#, DURING }

Слід зазначити, що ці визначення все ще залишаються вельми неповними Ми повернемося до цієї теми і допрацюємо зазначені визначення в розділі 237 Але слід зазначити, що ці визначення дозволяють усунути проблему, повязану з необхідністю застосовувати довільний вибір щодо того, який з двох потенційних ключів повинен стати первинним А що стосується інших обмежень і запитів, наведених в розділі 232, то має бути ясно, що безпосередні аналоги цих обмежень і запитів можуть бути легко сформульовані стосовно до бази даних, показаної на рис 234, завдяки існуванню операторів BEGIN і END Але тут не показані небудь з цих формулювань, оскільки у завдання автора входить саме надання читачеві набагато більш кращого способу вираження таких обмежень і запитів

Ще раз відзначимо, що тип DATE є допустимим позиційним типом, але до цих

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

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

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

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

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

органами зору і слуху

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

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

■&nbsp&nbsp&nbsp&nbsp INTERVAL_INTEGER

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

функція складання з одиницею), а значеннями цього інтервального типу є інтервали в формі [b: е], де b і е – значення типу INTEGER і b ≤ e

■&nbsp&nbsp&nbsp INTERVAL_MONEY

Тут MONEY (зупинимося на такому допущенні) – тип, який представляє грошові суми, вимірювані в доларах і центах Функцією визначення подальшої позиції є функція складання з одним центом . Значеннями цього інтервального типу є інтервали в формі [b: е], де Ь і е – значення типу MONEY І b ≤ е

Операції над позиціями і інтервалами

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

Термінологія Припустимо, що т – позиційний тип, а р, p1 і р2 – значення типу т неформально можна припустити, що для позначення позицій, відповідно, попередньої і наступної стосовно р, можуть використовуватися вираження р +1

і р-1 Крім того, припустимо, що i, il і i2 – інтервали типу INTERVAL_T b, И та Ь2 –

початкові позиції, а е, el і е2 – кінцеві позиції, відповідно, інтервалів i, il і i2 неформально можна припустити, що для позначення інтервалів i, il і i2 використовуються, відповідно, вираження [B: e], [И: е1] і [b 2: е 2]

У такому випадку справедливі наведені нижче твердження

Вираз ls_NEXT_T (pl, p2) приймає істинне значення тоді і тільки тоді, коли позиція pi є безпосередньо попередньої по відношенню до позиції р2 Вираз is_PRlOR_T (pl, p2) приймає істинне значення тоді і тільки тоді, коли є істинним вираз ls_NEXT_T (p2, pl) це означає, що is_PRiOR_T (pl, p2) = is_NEXT_T (p2, pl)

Вираз MAX (pi, р2) повертає р2, якщо вираз pi < р2 є істинним, в іншому випадку воно повертає pi; вираз мш (р1, р2) повертає pi, якщо вираз pi < р2 є істинним, в іншому випадку воно повертає р2.

■ Вираз р £ i є істинним тоді і тільки тоді, коли вираження b < р ір < е обидва є істинними; це означає, що р е i = (b <р AND p <е). Крім то го, i зр = р е i.

Примітка Символи е і е читаються, відповідно, як міститься в і

“Містить.

Вираз COUNT (i) повертає результат підрахунку кількості різних позіційр, таких що р Е i

■ Інтервал i є одиничним інтервалом тоді і тільки тоді, коли COUNT (i) = 1 Вираз POINT FROM i повертає єдину позицію з одиничного інтервалу i

Вирази PRE (i) і POST (i), відповідно, повертають позиції b-1 і е +1 Примітка Вирази PRE (i) і POST (i), відповідно, є скороченнями ВІД PRIOR_T (BEGIN (i)) І NEXT_T (END (i))

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

■ Дорівнює (=): (i l = i2)=   (b1  = b2 AND el  =  e2)

■ Включає (⊇) і включено в (⊆): (il ⊇ i2)=   (b1 ≤ b2  AND el   ≥

e 2 )  (i 2 ⊆ il)    =    (il   ⊇  i2 )

■ Строго включає (⊃) і строго включено в (⊂): (il ⊃ i2) = (il ⊇ i2

AND il  ≠ i2 ) ( i 2   ⊂  il)    =    (il   ⊃ i2 )

■ BEFORE І AFTER: (il BEFORE i2) = (el

■&nbsp&nbsp&nbsp&nbsp MEETS:  ( i l  MEETS   i2)     =     (b2  =   el+1   OR  b1   =   e 2 +l)

OVERLAPS: ( i l    OVERLAPS    i2)    =    (b1 ≤  e2  AND b2 ≤  e1)

■&nbsp&nbsp&nbsp&nbsp MERGES: ( i l    MERGES   i2)   =   ( i l    OVERLAPS   i2   OR   il   MEETS i2)

BEGINS:  ( i l     BEGINS    i2)    =    (b1    =   b2   AND   el  ≤ e2)

ENDS: ( i l    ENDS    i2)    =    (el    =    e2    AND   b1≥ b2 )

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

■ Оператор UNION Вираз il UNION i2 повертає [MlN (bl, b2): MAX (el, e2)], якщо вираз il MERGES i2 приймає істинне значення в проти ном випадку воно не визначено Наприклад, обєднанням інтервалів [d04: d08] і

[D06: dl0] є інтервал [d04: dl0] обєднання інтервалів [d02: d03]

і [d06: dl0] не визначено

■ Оператор INTERSECT Вираз il INTERSECT i2 повертає [МАХ (И, Ь2): MIN (el, e2)], якщо вираз il OVERLAPS i2 приймає істинне значення в іншому випадку воно не визначено Наприклад, перетином інтер валів [d04: d08] і [d06: dl0] є інтервал [d 06: d0 8] перетин

[D02: d03] і [d06: dl0] не визначено

Оператор MINUS Вираз il MINUS i2 повертає [bl: MlN (b2-l, el)], якщо обидва вирази, И < b2 і el ≤ e2, приймають справжнє значення і повертає [МАХ (е2 + 1, b1): el], якщо обидва вирази, b1 ≥ b2 і el> e2,

приймають істинне значення, а в іншому випадку результат цього виразу не визначений Наприклад, різниця між інтервалами [d04: d08] і [d06: dl0] (у зазначеному порядку) дорівнює [d04: d05], різниця між інтервалами [d06: dl0] і [d04: d08] (у зазначеному порядку) дорівнює [dO9: dl0], різниця між інтервалами [d02: d03] і [d06: dl0] (в будь-якому порядку) не визначена

Приклади запитів

На завершення цього розділу розглянемо декілька прикладів запитів, які наочно ілюструють використання деяких операторів, визначених у попередньому підрозділі Спочатку розглянемо запит: Отримати номери постачальників, які були здатні поставляти деталь Р2 в восьмі добу . Нижче наведена можливе формулювання цього запиту до бази даних, показаної на рис 234

(SP_DURING WHERE Р # = Р # (Р2)

AND dO8 € DURING ) { S# }

Пояснення Вираз у зовнішніх круглих дужках скорочує безліч кортежів, присутніх в даний час у змінній відносини SP_DURING, до такого безлічі кортежів, в якому значення р # одно Р2, а в інтервалі, представляє собою значення DURING, містяться восьму добу Потім до цього безлічі кортежів застосовується операція проекції по атрибуту s # для отримання бажаного результату

Примітка На практиці застосовується тут вираз d08 необхідно було б замінити відповідним викликом селектора DATE

Як другий приклад розглянемо наведену нижче можливу формулювання запиту: Визначити пари постачальників, які були здатні поставляти одну і ту ж деталь одночасно.

WITH ( SP_DURING RENAME (   S# AS X#, DURING AS XD ) ) AS Tl , ( SP_DURING RENAME (   S# AS Y#, DURING AS YD ) ) AS T2 ,

( Tl JOIN T2 ) AS T3   , ( T3 WHERE XD OVERLAPS YD ) AS T4

,

( T4 WHERE X# &lt Y# )    AS T5 : T5 { X#, Y# }

Пояснення Тут Tl – відношення, яке є поточним значенням змінної відносини SP_DURING, за винятком того, що атрибути S # і DURING перейменовані, відповідно, в х # і XD ставлення Т2 є таким ж, за винятком того, що в ньому новими іменами атрибутів є У # і YD Ставлення ТЗ є зєднанням відносин Т1 і Т2 за номерами деталей Ставлення Т4 являє собою скорочення від ТЗ, в якому присутні тільки такі кортежі, в яких інтервали XD і YD перекриваються (це означає, що постачальники не тільки були здатні поставляти одну і ту ж деталь, але фактично були здатні поставляти одну і ту ж деталь одночасно, що й потрібно визначити за умовами запиту) Ставлення Т5 є скороченим позначенням від Т4, в якому присутні тільки ті кортежі, де номер постачальника х # менше номера постачальника Y # (порівняйте з прикладом 755 з глави 7) Заключна операція проекції пох ​​# і Y # виробляє необхідний результат

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

WITH ( SP_DURING RENAME ( S# AS X#, DURING AS XD ) ) AS Tl , ( SP_DURING RENAME ( S# AS Y#, DURING AS YD ) ) AS T2 , ( Tl JOIN T2 ) AS T3 ,

( T3 WHERE XD OVERLAPS YD ) AS T4 ,

( T4 WHERE X# &lt Y# ) AS T5 ,

( EXTEND T5 ADD ( XD INTERSECT YD ) AS DURING ) AS T6 : T6 { X#, Y#, P#, DURING }

Пояснення Відносини Tl, T2, ТЗ, Т4 і Т5 є точно такими ж, як у попередньому прикладі Після їх отримання за допомогою оператора EXTEND обчислюються відповідні інтервали, а завершальна операція проекції виробляє бажаний результат

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

*

*