22.3. Основная проблема хронологических баз данных

В последующих примерах этой главы в качестве основы по-прежнему будет использо­ваться база данных поставщиков и деталей, но, чтобы она лучше подходила для наших целей, необходимо внести в нее несколько изменений. Прежде всего, для упрощения примеров уда­лим переменную-отношение Р. Во-вторых, откорректируем состав атрибутов переменной-отношения поставок SP, отбросив атрибут QTY и оставив лишь атрибуты Si и Р#. Измененную таким образом переменную-отношение SP можно интерпретировать так: "Поставщик с номе-, ром S# в настоящее время может поставить деталь с номером Pi". Иначе говоря, вместо то­го чтобы показывать действительные поставки деталей поставщиками, переменная-отношение SP теперь показывает лишь потенциально возможные поставки, т.е. возможно­сти поставщиков поставлять детали. На рис, 22.1 представлена исправленная версия рис. 3.8 из главы 3. Здесь отображено множество данных, содержащихся в измененной базе данных. Обратите внимание, что эта база данных по-прежнему имеет тип моментального снимка, по­скольку еще не включает никаких хронологических сведений.

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

Ограничения (для текущей версии базы данных типа моментального снимка). Единст­венные ограничения, которые будут рассмотрены, — это ограничения для ключа. Напом­ним, что {S#} и {S#,P#} — первичные ключи переменных-отношений S и SP соответствен­но, a {St} — внешний ключ переменной-отношения SP, который ссылается на первичный ключ переменной-отношения S (безусловно, внешний ключ {Р#} не учитывается).

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

■ Запрос 1.1. Определить номера поставщиков, которые в настоящее время могут поставить некоторую деталь.

Везде в этой главе неуточненный термин "предикат " используется для обозначения внеш­него предиката, который понятен пользователям (см. главу 8), а не внутреннего, понятного сис­теме (последний является, конечно, предикатом переменной-отношения/ Кроме того, мы не за­трагиваем здесь аспекты внешнего предиката, которые или "очевидны", или не имеют отноше­ния к теме нашего обсуждения.

SP { St }

■ Запрос 1.2. Определить номера поставщиков, которые в настоящее время не могут поставлять никаких деталей.

S { St } MINUS SP { St }

s#	SNAME	STATUS	CITY
SI	Smith	20	London
S2	Jones	10	Paris
S3	Black	30	Paris
S4	Clark	20	London
S5	Adams	30	Athens

S#	P#
SI	PI
SI	P2
SI	P3
SI	P4
SI	P5
SI	P6
S2	PI
S2	P2
S3	P2
S4	P2
S4	P4
S4	P5

Рис. 22.1. База данных поставщиков и деталей (значения для примера): текущая версия типа моментального снимка

Отметим, что запрос 1.1 включает простую операцию проекции, а запрос 1.2 — опе­рацию разности между двумя подобными проекциями. Позднее, при рассмотрении хро­нологических вариантов этих двух запросов, мы убедимся, что они включают хроноло­гические аналоги этих двух операторов (см. раздел 22.8).

Замечание. Возможно, читателя не удивит тот факт, что могут быть определены хро­нологические аналоги и других реляционных операторов (см. упр. 22.8).

"Полуограниченные во времени" поставщики и поставки

Чтобы изменения вносились постепенно, на следующем этапе мы введем в пере­менные-отношения S и SP только "полухронологичность" (если можно так выра­зиться). Для этого к каждой из них добавим атрибут временной отметки SINCE (Начиная с), а затем соответственно переименуем эти переменные-отношения так, как показано на рис. 22.2.

Для упрощения представления информации на рис. 22.2 показаны не реальные вре­менные отметки, а условные обозначения вида dOl, 602 и т.д., где d может для удобства произноситься как "день". Указанного соглашения мы будем придерживаться до конца этой главы. (Таким образом, во всех примерах будут использоваться временные отметки, которые являются днями.) Далее подразумевается, что день 1 непосредственно предше­ствует дню 2, день 2 непосредственно предшествует дню 3 и т.д. Кроме того, незначащие ведущие нули в таких выражениях, как ' день 1', отбрасываются.

Предикат для переменной-отношения S_SINCE формулируется так: "Поставщик с номером St и с именем SNAME имеет статус STATUS, находится в городе CITY, и договор с ним заключен с дня SINCE". Предикат для переменной-отношения SP SINCE форму­лируется так: "Поставщик с номером St может поставлять деталь с номером Pt начи­ная с дня SINCE".

Рис. 22.2. База данных поставщиков и деталей (значения для примера): "полухроноло­гическая " версия

Ограничения ("полухронологическая" база данных). Первичные и внешние ключи для новой полухронологической базы данных те же, что и раньше. Однако требуется ввести дополнительное ограничение, которое могло бы рассматриваться как расширен­ное ограничение внешнего ключа в переменной-отношении SP SINCE для переменной-отношения S_SINCE. Оно необходимо для отражения того факта, что ни один поставщик не может поставить ни одной детали прежде, чем с ним будет заключен договор. Иными словами, если кортеж sp в переменной-отношении SP SINCE ссылается на кортеж s в пе­ременной-отношении S_SINCE, то значение SINCE в кортеже sp не должно быть меньше, чем значение SINCE в кортеже S.

CONSTRAINT AUG_SP_T0_S_FK

IS_EMPTY ( ( ( S SINCE RENAME SINCE AS SS ) JOIN ( SP SINCE RENAME SINCE AS SPS ) ) WHERE SPS < SS ) ;

С этого примера мы и начнем рассмотрение основной проблемы хронологических баз данных. Для "полухронологической" базы данных, аналогичной показанной на рис. 22.2, по-видимому, потребуется установить много "расширенных ограничений внешнего клю­ча", подобных приведенному выше. Поэтому нам, скорее всего, потребуются некоторые подходящие случаю способы их сокращенной записи.

Запросы ("полухронологическая" база данных). Рассмотрим "полухронологические" версии запросов 1.1 и 1.2.

■ Запрос 2.1. Определить номера поставщиков, которые в настоящее время могут поставить некоторую деталь, показав в каждом случае дату, начиная с которой они способны выполнить эту поставку. Если поставщик с номером ' Sx' в настоящее время может поставить несколько дета­лей, он может поставить некоторую деталь начиная с наименьшей даты SINCE, которая есть среди значений дат для поставщика с номером 'Sx' в переменной-отношении SP SINCE (например, если в качестве значения номера 'Sx' взять 'S1', наименьшей да­той в столбце SINCE для него будет дата й04). Значит, получаем следующее.

SUMMARIZE SP PER SP { S|} ADD MIN { SINCE } AS SINCE Результат будет таким, как показано ниже.

s#	SINCE
SI	d04
S2	d08
S3	d08
S4	d04

■ Запрос 2.2. Определить номера поставщиков, которые в настоящее время не могут поставить ни одной детали, показав в каждом случае дату, начиная с которой они оказались в этом положении.

В нашей базе данных имеется один поставщик, который в настоящее время не может поставить ни одной детали, — это поставщик с номером 'S5'. Однако нельзя сделать какой-либо вывод о дате, начиная с которой поставщик с номером 'S5' не может поставить ни одной детали, поскольку для этого у нас нет данных — база данных пока лишь "яолухронологическая". Предположим, например, что текущий день — это dlO. Тогда может оказаться, что поставщик с номером 'S5' мог постав­лять по крайней мере одну деталь начиная с даты, которая меньше даты d2, если с ним ранее был подписан договор, срок действия которого истек не позднее, чем d09. Также возможен крайний случай, когда поставщик с номером ' S5' вообще никогда не имел возможности что-либо поставлять.

Чтобы иметь хоть какие-то шансы получить ответ на запрос 2.2, необходимо за­вершить "хронологизацию" базы данных или по крайней мере выполнить это в от­ношении переменной-отношения SP. Точнее, необходимо сохранить в базе данных исторические записи, свидетельствующие о том, какие поставщики, когда и какие именно детали могли поставлять. Именно это мы и попытаемся сделать в следую­щем разделе.

Полностью хронологическая база данных поставщиков и поставок

На рис. 22.3 показано содержимое полностью хронологической версии базы данных поставщиков и поставок. Обратите внимание, что атрибуты SINCE переименованы в ат­рибуты FROM (От) и, кроме того, в каждую переменную-отношение добавлен новый атри­бут типа временной отметки с именем ТО (До). Совместно атрибуты FROM и ТО отражают понятие интервала времени, в течение которого что-то истинно. Поэтому в именах пере­менных-отношений заменим слово SINCE (Начиная с) словом FR0MJT0 (От и до). Как ви­дите, теперь в новой базе данных стало больше кортежей, чем в предыдущем варианте, поскольку в ней сохранены исторические записи. Для определенности будем подразуме­вать, что текущая дата — это dl 0, поэтому значение даты dl 0 для атрибута ТО означает, что соответствующий кортеж отражает текущее состояние дел.

Замечание. Возможно, читателю интересно, что это за механизм, который приводит к тому, что все значения атрибута ТО, которые совпадают с текущей датой dlO, автоматиче­ски заменяются значением dl 1 по бою часов в полночь. К сожалению, ответ этот вопрос мы вынуждены на некоторое время отложить, но мы вернемся к нему в разделе 22.11.

Заметим, что хронологическая база данных, показанная на рис. 22.3, включает все данные из предыдущего "полухронологического" аналога, представленного на рис. 22 2, дополненные историческими сведениями, относящимися к предыдущему пе­риоду (от 602 до d04), в течение которого был действителен договор с поставщиком с номером 'S2'. Предикат для переменной-отношения S_FR0M_T0 можно сформулиро­вать так: "Поставщик с номером St и с именем SNAME имел статус STATUS, находился в городе CITY и имел договор на поставку, действительный с дня FROM (и не действи­тельный в день, предшествующий дню FROM) по день ТО (и не действительный в день, следующий за днем ТО)". Для переменной-отношения SP_FR0M ТО предикат построен по аналогичному принципу.

S FROM ТО	s#	SNAME	STATUS	CITY	FROM	TO
	SI	Smith	20	London	d04	dlO
	S2	Jones	10	Paris	dO 7	dlO
	S2	Jones	10	Paris	d02	d04
	S3	Black	30	Paris	d03	dlO
	S4	Clark	20	London	d04	dlO
	S5	Adams	30	Athens	d02	dlO
SP_FROM_TO		S#	P#	FROM	TO
		SI	PI	d04	dlO
		SI	P2	d05	dlO
		SI	P3	d09	dlO
		SI	P4	d05	dlO
		SI	P5	d04	dlO
		SI	P6	d06	dlO
		S2	PI	d02	d04
		S2	P2	d03	d03
		S2	PI	d08	dlO
		S2	P2	d09	dlO
		S3	P2	d08	dlO
		S4	P2	d06	d09
		S4	P4	d04	d08
		S4	P5	d05	dlO

Рис. 22.3. База данных поставщиков и деталей (значения для примера): первая полно­стью хронологическая версия с использованием временных отметок

Ограничения (первая хронологическая база данных). Прежде всего необходимо принять меры, чтобы в кортежах не появлялись ошибочные пары атрибутов FR0M-T0, в которых момент ТО предшествует моменту FROM.

CONSTRAINT S_FR0M ТО OK

IS_EMPTY ( S_FR0M~T0 WHERE TO < FROM ) ;

CONSTRAINT SP_FR0M_T0 OK

IS EMPTY ( SP FROM~T0 WHERE TO < FROM ) ;

Теперь обратите внимание на атрибуты, подчеркнутые на рис. 22.3 двойной линией. Как видите, атрибут FROM включен в первичный ключ обеих переменных-отношений, S_FR0M_T0 и SP_FR0M_T0. Очевидно, что первичный ключ переменной-отношения S_FR0M_T0 не может быть просто {Si}, поскольку в этом случае в переменную-отношение нельзя было бы включить сведения об одном и том же поставщике, с кото­рым договоры на поставку заключались на несколько различных периодов. Точно такие же соображения применимы и в отношении переменной-отношения SP_FR0M_T0.

Замечание. В первичный ключ вместо атрибута FROM можно было бы включить атри­бут ТО. Фактически обе переменные-отношения, S FROM ТО и SP_FR0M ТО, имеют по два потенциальных ключа и являются типичным примером переменных-отношений, для ко­торых нет никаких очевидных причин выбирать один из имеющихся потенциальных ключей в качестве "первичного" [8.13]. Мы сделали указанный выбор исключительно для определенности.

Однако этими первичными ключами не исчерпываются все ограничения, которые нам хотелось бы иметь. Рассмотрим, например, переменную-отношение SP_FR0M_T0. Должно быть ясно, что если в такой переменной-отношении есть кортеж для по­ставщика с номером 'Sx' со значением f атрибута FROM и значением t атрибута ТО, то нам хотелось бы, чтобы в этой переменной-отношении не было какого-нибудь другого кортежа для поставщика с номером 'Sx', из значения которого следовало бы, что этот поставщик заключил договор со дня, непосредственно предшествующе­го дню f, или по день, непосредственно следующий за днем t. Например, рассмот­рим поставщика с номером 'S1', для которого в переменной-отношении SP_FR0M_T0 имеется один кортеж со значениями атрибутов FROM=d04 и 10=dlO. Одного того, что {St,FROM} является первичным ключом для этой переменной-отношения, очевидно, недостаточно, чтобы предотвратить появление других "перекрывающихся" корте­жей для поставщика с номером 'S1', например кортежа со значениями атрибутов FROM=d02 и TO=d06. Если бы такой кортеж появился, то это, кроме всего прочего, указывало бы, что с поставщиком с номером 'S1' был заключен договор, который являлся действительным в день, непосредственно предшествующий дню d04. Веро­ятно, следовало бы объединить такие два кортежа в один кортеж, в котором значе­ния атрибутов были бы соответственно равны FROM=d02 и TO=dJ0⁵.

⁵ Заметим, что если не объединить такие кортежи, это будет почти равносильно разреше­нию существования дубликатов! Наличие дубликатов означает, что в базе данных "об одном и том же говорится дважды ". Однако два кортежа для поставщика с номером 'S1' с перекры­вающимися интервалами времени фактически "говорят об одном и том же дважды ", а имен­но — оба они "утверждают", что с поставщиком с номером 'S1 ' был заключен договор, срок действия которого включает дни 4, 5 и 6.

Кроме того, лишь одного факта, что {S|,FR0M} является первичным ключом для пе­ременной-отношения SP_FR0M_T0, также недостаточно, чтобы предотвратить появление "смежных" кортежей для поставщика с номером 'S1', например таких, в которых значе­ниями атрибутов будут FROM=d02 и T0=d03. В данном случае это означало бы, что с по­ставщиком с номером 'S1' был заключен договор, действительный, включая день, кото­рый непосредственно предшествует дню d04. Как и в предыдущем случае, такие кортежи должны быть объединены в один общий кортеж.

Ниже представлено ограничение, которое запрещает перекрытие и смежность вре-мешшх диапазонов.

CONSTRAINT AUG_S FROM Т0_РК

IS EMPTY ((Js FROMJTO RENAME FROM AS Fl, TO AS Tl ) JOIN ( S~FR0M_T0 RENAME FROM AS F2, TO AS T2 ) ) WHERE { Tl > F2 AND T2 > Fl ) ) OR ( F2 = Tl+1 OR Fl = T2+1 ) ) ;

Это выражение несколько запутанное, не говоря уже о том, что здесь допущены оп­ределенные вольности в написании (например, выражение Т1+1 используется для обо­значения дня, непосредственно следующего за днем Т1). К этому вопросу мы еще воз­вратимся в разделе 22.5.

Замечание. Фактически наличие данного ограничения позволяет обращаться к соче­танию атрибутов {Si,FROM,ТО} как к хронологическому потенциальному ключу (точнее, к хронологическому первичному ключу). Однако это не очень хороший термин, посколь­ку "хронологический" потенциальный ключ не является на самом деле потенциальным ключом переменной-отношения, которая его содержит. (В разделе 22.9 мы обсудим "хронологические потенциальные ключи", которые являются настоящими потенциаль­ными ключами в классическом смысле этого термина.)

Далее необходимо отметить, что сочетание атрибутов {Si,FROM} в переменной-отношении SP_FR0M_T0 не является внешним ключом переменной-отношения SP_FR0M_T0 для переменной-отношения S_FR0M_T0, несмотря на то что это сочетание включает те же атрибуты, что и первичный ключ переменной-отношения S_FR0M_TO. Од­нако нам необходимо быть уверенными, что если сведения о некотором поставщике имеются в переменной-отношении SP_FR0M_T0, то они присутствуют и в переменной-отношении S_FR0M_T0.

CONSTRAINT AUG_SP_T0_S_FK_AGAIN1

SP_FR0M_T0 { St } <~S_FR0M_TO { Sf } ;

(Здесь знак "<" означает "является подмножеством".)

Но ограничения AUG_SP_T0_S_FK_AGAIN1 самого по себе недостаточно. Необходимо иметь уверенность в том, что даже после выполнения всех возможных объединений кортежей, если в переменной-отношении SP FROM ТО некоторый поставщик может по­ставлять некоторую деталь в течение некоторого времени, в переменной-отношении S_FR0M_T0 обязательно есть кортеж для этого поставщика, указывающий, что на опре­деленный период договор с ним действительно был заключен. Это можно попытаться выразить так.

CONSTRAINT AUG_SP T0_S FK_AGAIN2 /* внимание - некорректно */ IS_EMPTY { ( (~S_FR0M_T0 RENAME FROM AS SF, TO AS ST ) JOIN ( SP_FR0M_T0 RENAME FROM AS SPF, TO AS SPT ) ) WHERE SPF < SF OR SPT > ST ) ;

Однако, как сказано в комментарии, данное определение фактически неверно. Чтобы разобраться, почему именно, рассмотрим пример. Пусть переменная-отношение S_FR0M_T0 будет такой, как показано на рис. 22.3, и пусть переменная-отношение

SP_FROM_TO содержит кортеж для поставщика с номером 'S2' с атрибутами, скажем, FROM=dOJ и TO=d04. Очевидно, что такое сочетание является допустимым, но на самом деле ограничение AUG_SP_T0_S_FK_AGAIN2 его запрещает.

Здесь мы не будем пытаться решить эту проблему, а отложим ее обсуждение до раз­дела 22.9. Однако отметим, что если, как указывалось ранее, сочетание атрибутов {St,FROM,ТО} в переменной-отношении S_FR0M_T0 считается "хронологическим потен­циальным ключом", то сочетание атрибутов {Si,FROM,ТО} в переменной-отношении SP_FR0M_T0 можно считать "хронологическим внешним ключом" (хотя он на самом деле не является внешним ключом как таковым). Обсуждение этого вопроса также будет про­должено в разделе 22.9.

Запросы (первая хронологическая база данных). Рассмотрим полные хронологиче­ские версии запросов 1.1 и 1.2.

■ Запрос 3.1. Получить тройки значений атрибутов SI, FROM и ТО для поставщиков, которые в некоторое время могут поставить некоторую деталь, где FROM и ТО вме­сте означают максимальный непрерывный период, в течение которого поставщик с номером St действительно мог поставить некоторую деталь.

Замечание. Здесь слово "максимальный" используется как удобное сокращение, которое в данном случае означает, что поставщик с номером St не мог поставить ни одной детали до дня FROM и после дня ТО.

■ Запрос 3.2. Получить тройки значений атрибутов St, FROM и ТО для поставщиков, которые в определенное время не могут поставить никаких деталей, где FROM и ТО вместе означают максимальный непрерывный период, в течение которого по­ставщик с номером Si действительно не мог поставлять никаких деталей.

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

Можно сделать заключение, что суть проблемы хронологических данных состоит в том, что их наличие требует создания ограничений и запросов, которые чрезмерно слож­ны, чтобы их сформулировать, если, конечно, системой не предоставляются удачно раз­работанные сокращения, которых, как нам известно, коммерческие СУБД в настоящее время не имеют.