Главная » SQL, Базы данных » ПРОЕКТ ХРОНОЛОГИЧЕСКОЙ БАЗЫ ДАННЫХ

0

В процессе проектирования хронологических баз данных возникают некоторые осо бые проблемы. Для иллюстрации некоторых из этих проблем еще раз пересмотрим наш рабочий пример следующим образом: во-первых, полностью удалим информацию о поставках, во-вторых, переопределим информацию об имени, статусе и городе постав щика. А выбранный нами проект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 из раздела 23.2.

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НФ) иногда называют проекционно-соединительной нормальной формой.

Примечание. Поскольку эти замечания относятся именно к классической нормализации, здесь упоминания операций проекции и соединения следует понимать как обозначающие классические версии этих операций, а не обобщенные версии, представленные в разделе 23.5.

Теперь следует отметить, что еще до начала исследований в области хронологических данных некоторые теоретики (см., например, [14.21]), выдвигали доводы в пользу максимально возможной декомпозиции переменных отношения, а не просто их декомпозиции до такой степени, которой требует классическая теория нормализации. Общая идея состояла в том, что переменные отношения должны быть приведены к неприводимым

компонентам [14.21]; под этим подразумеваются такие компоненты, для которых  дальнейшая декомпозиция без потерь становится невозможной. В случае нехронологических переменных отношения доводы в пользу "декомпозиции до конца" не очень убедительны, но они становятся гораздо более весомыми в случае переменной отношения наподобие 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); см. обсуждение понятия эквивалентности в самом конце раздела 23.4.   Переменная отношения 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 в общий проект отчасти просто для полноты, а частично из-за того, что благодаря такому включению удается в определенной степени предотвратить создание громоздкого и надуманного проекта, который появился бы в противном случае

[23.4].

Определение "движущейся по временной шкале позиции текущего времени"

Снова вернемся на время к обсуждению вопроса горизонтальной декомпозиции (т.е. разделения базы данных на переменные отношения "с данными,  определяющими временную позицию" и "с данными, обозначающими временной интервал"). Безусловно, что в этой базе данных недостаточно иметь  только переменные отношения, "определяющие временную позицию", поскольку такие переменные отношения являются просто полухронологическими и не могут представлять историческую информацию. Тем не менее,  в  базе  данных  могут  применяться  лишь  переменные  отношения  с  данными, "обозначающими временной интервал", но только если мы согласимся с тем, что в базе данных будет содержаться ложная информация (как описано ниже).

Рассмотрим случай с поставщиком, контракт которого еще не закончился. Безусловно, вполне возможно, что предполагаемое время завершения этого контракта известно, но, вообще говоря, чаще всего известно лишь то, что контракт продлевается автоматически (в качестве примера можно указать типичные контракты, которые заключаются при найме на работу). Поэтому, какое бы значение не было указано в качестве атрибута END (DURING) для такого поставщика в переменной отношения с данными, "обозначающими временной интервал", оно все равно скорее всего окажется ложным. Безусловно, можно было бы и даже, по-видимому, нужно принять соглашение, что такие значения атрибута END (DURING) должны задаваться как последние сутки рассматриваемого временного интервала10 (т.е. как значение, возвращаемое функцией LAST_DATE ()). Но следует отметить, что такая схема означает, что если значение "последние сутки" появится в результатах запроса, то пользователь, вероятно, обязан интерпретировать это значение как "до дополнительного извещения", а не  собственно как "последние сутки". Иными словами, утверждать, что атрибут END (DURING) для такого поставщика имеет значение "последние сутки", означает почти наверняка — давать ложную информацию.

Именно для того, чтобы избежать необходимости включать в базу данных такую ложную информацию, некоторые авторы (см., например, [23.2]) предложили  использовать специальный "маркер NOW" (сейчас) для обозначения того, что в разделе 23.1 было определено как "движущаяся по временной шкале позиция  текущего времени" (иными словами, для обозначения понятия "до дополнительного извещения"). Основная идея состоит в том, что нужно разрешить включать этот специальный маркер там, где, вопервых, разрешено применение соответствующего позиционного временного типа, и, вовторых,  действительно  придать  ему  намеченную  интерпретацию  как  "до  дополнительного извещения". Таким образом, например, переменная отношения  S_DURING может включать, допустим, кортеж с данными о поставщике S1 со значением DURING, равным [d04 :NOW], а не [d04 :d99]. (Здесь предполагается,  что 99-е сутки — это последние сутки и данное конкретное появление значения d99 действительно должно рассматриваться как имеющее смысл "до  дополнительного извещения", а не обозначает 99-е сутки как таковые.)

Но, по мнению автора, введение маркера NOW представляет собой непродуманный отход от здравых реляционных принципов. Отметив, что NOW фактически является переменной, укажем, что данный подход связан с введением очень странного понятия —

10 Безусловно, можно заменять это искусственное значение истинным значением после того, как это истинное значение становится известно.

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

■     Допустим, что i— интервал [N0W:dl4], t — кортеж, содержащий интервал i, а сегодня — десятые сутки. В таком случае кортеж t может рассматриваться как своего рода сокращенное обозначение пяти отдельных кортежей, содержащих единичные интервалы, соответственно,   [ d l 0 : d l 0 ] ,   [ d l l : d l l ] ,   [ d l 2 : d l 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 не требуется.

23.3. ОГРАНИЧЕНИЯ ЦЕЛОСТНОСТИ ХРОНОЛОГИЧЕСКИХ БАЗ ДАННЫХ

В данном разделе рассматривается проблема ограничений целостности, которые применяются к хронологическим данным. В разделе 23.2 было показано, насколько сложно даже сформулировать правильно эти ограничения в отсутствие должной поддержки интервалов, а в этом разделе показано, как можно решить эту проблему с применением понятий, представленных в предыдущих разделах.

Для определенности сосредоточим наше внимание (пока не будет указано  иное) на переменной отношения S_STATUS_DURING из предыдущего раздела, которое имеет следующее определение.

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

" В действительности, маркер NOW напоминает значение NULL, поскольку внедрение понятия NULL

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

Теперь перейдем к анализу в следующих трех подразделах тех трех основных проблем, которые могут возникать в хронологических переменных отношения, подобных указанной переменной отношения. Эти проблемы будут именоваться, соответственно, проблемой избыточности, проблемой многословия и проблемой противоречия.

Проблема избыточности

Ограничение KEY для переменной отношения S_STATUS_DURING, хотя и логически правильное, в определенном смысле является недостаточным. А именно — оно не в состоянии предотвратить появление в этой переменной отношения, например, обоих следующих кортежей одновременно.

Вполне очевидно, что эти два кортежа обнаруживают определенную  избыточность, поскольку статус поставщика S4 в шестые сутки фактически был указан дважды. Безусловно, было бы лучше заменить эти два кортежа одним следующим кортежем.

Здесь показано, что поставщик 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 можно было бы привести гораздо больше сведений [23.4]; но из-за ограничений по объему  приведем лишь следующие выводы. Во-первых, автор предлагает предусмотреть возможность вводить в определение любой конкретной переменной отношения  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 в разделе 23.2, и поэтому теперь достигнута еще одна из целей, первоначально поставленных в этой главе, а именно — обнаружен лучший способ формулировки ограничений, которые рассматривались в предыдущем разделе.

Девять требований

В заключение этого раздела следует отметить, что по вопросу поддержки ограничений в хронологической базе данных необходимо рассмотреть гораздо  более широкий круг проблем, чем предложено в данной главе. В [23.4] приведен  тщательный и подробный анализ всей этой темы; точнее, в указанной работе рассматривается в очень общих терминах набор из девяти требований, которым  должна соответствовать типичная хронологическая база данных, подобная  рассматриваемой здесь базе данных поставщиков и поставок. Список этих требований приведен ниже.

■     Требование 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.

В [23.4] глубоко проанализированы эти девять требований и показано, как можно их сформулировать в реляционно полном языке наподобие Tutorial D. В  этой главе дальнейшее обсуждение указанной темы не приведено.

23.4. РЕЗЮМЕ

Потребность в создании баз данных (особенно хранилищ данных), содержащих хронологические данные, постоянно возрастает. Хронологические данные могут рассматриваться как закодированное представление высказываний с временными отметками. В число указанных высказываний могут входить высказывания с информацией о начальной позиции на временной шкале (предназначенные для представления текущих данных) и высказывания с информацией об интервале времени (предназначенные для представления исторических данных); в этой главе дано очень точное определения двух указанных терминов. А именно — выражение "от" определено как обозначающее именно "начиная от указанной позиции на временной шкале и не включая непосредственно предшествующего времени", а  выражение "на протяжении интервала времени" рассматривается как обозначающее "на протяжении указанного интервала времени, не включая того времени, которое непосредственно предшествует или непосредственно следует за этим интервалом".

Затем в этой главе был представлен очень простой рабочий пример (база данных поставщиков и поставок) и были выполнены следующие действия: во-первых, полухронологизация этой базы данных путем введения атрибутов 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, в конечном итоге являются просто сокращенными обозначениями для некоторых других понятий, которые вполне могут быть выра жены средствами реляционной модели.

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии