Реструктуризация

Иногда может стать необходимой реструктуризациябазы данных. Хотя при этом общее информационное содержание остается тем же самым, размещение информации в этой базе данных изменяется, т. е. некоторым образом изменяется размещение полей в таблицах. Прежде чем продолжить обсуждение, отметим, что такая реструктуризация вообще нежелательна. Однако иногда она неизбежна. Например, может оказаться необходимым «вертикально» расщепить таблицу так, чтобы часто требующиеся столбцы могли храниться на более быстром устройстве, а реже требующиеся столбцы—на более медленном устройстве. Рассмотрим этот случай более подробно. Предположим для примера, что необходимо по некоторой причине — точная причина не является здесь важной — заменить базовую таблицу S следующими двумя базовыми таблицами:

SX (НОМЕР_ПОСТАВЩИКА, ФАМИЛИЯ, ГОРОД)

SY (НОМЕР-ПОСТАВЩИКА, СОСТОЯНИЕ)

Примечание. Эта операция замены, между прочим, не совсем тривиальна. Один из способов ее осуществления состоит в следующей последовательности операций языка SQL:

CREATE TABLE SX

(НОМЕР_ПОСТАВЩИКА CHAR (5) NOT NULL,

ФАМИЛИЯ CHAR (20),

ГОРОД CHAR (15));

CREATE TABLE SY

(НОМЕР_ПОСТАВЩИКА CHAR (5) NOTNULL,

СОСТОЯНИЕ SMALLINT);

CREATE UNIQUE

CREATE UNIQUE INDEX XSX ON SX (НОМЕР_ПОСТАВЩИКА);

CREATE UNIQUE I NDEX XSY ON SY (НОМЕР_ПОСТАВЩИКА);

INSERT INTO SX (НОМЕР_ПОСТАВЩИКА, ФАМИЛИЯ, ГОРОД)

SELECT НОМЕР_ПОСТАВЩИКА, ФАМИЛИЯ, ГОРОД

FROM S;

INSERT INTO SY (НОМЕР_ПОСТАВЩИКА, СОСТОЯНИЕ)

SELECT НОМЕР_ПОСТАВЩИКА, СОСТОЯНИЕ

FROM S;

DROP TABLE S;

Важный факт, который обнаруживается в данном примере, заключается в том, что старая таблица S представляет собой соединение двух новых таблиц SX и SY по номерам поставщиков. В таблице S, например, была строка ('S1', 'Смит', 20, 'Лондон'). В таблице SX мы имеем теперь строку ('S1', 'Смит', 'Лондон'), а в SY—строку ('S1', 20). Соединение их дает, как и ранее, строку ('S1', 'Смит', 20, 'Лондон'). Поэтому создадим представление, которое является в точности этим соединением, и назовем его S:

CREATE VIEW S (НОМЕР_ПОСТАВЩИКА, ФАМИЛИЯ, СОСТОЯНИЕ,

ГОРОД)

AS SELECT SX.НОМЕР_ПОСТАВЩИКА, SX.ФAMИЛИЯ,

SY СОСТОЯНИЕ, SX ГОРОД

FROM SX,SY

WHERE SX НОМЕР_ПОСТАВЩИКА =

SY.HOMEP_ПОСТАВЩИКА;

Каждая программа, которая ранее обращалась к базовой таблице S, теперь будет вместо этого обращаться к представлению S. Операции SELECT будут продолжать работать в точности как и ранее, хотя они потребуют дополнительного анализа во время процесса связывания и дополнительных накладных расходов на стадии исполнения. Однако операции обновления больше не будут работать, поскольку система DB2, как уже пояснялось в разделе 8.4, не будет допускать обновлений представления, определяемого как соединение. Иными словами, выполняющий операции обновления пользователь не обладает иммунитетом к этому типу изменений. Он должен вручную внести некоторые изменения, касающиеся предложений обновления, а затем произвести их прекомпиляцию и повторное связывание.

Таким образом показано, что система DB2 не обеспечивает полной защиты от изменений в логической структуре базы данных. И в этом в первую очередь причина того, что проведение таких изменений вряд ли является хорошей идеей. Но дела могут быть не настолько плохими, как кажется, даже если требуются ручные изменения. Во-первых, легко обнаружить, какие программы должны быть изменены в связи с любыми такими изменениями. Эта информация может быть получена из каталога. Во-вторых, легко найти такие предложения, которые необходимо изменить в этой программе. Все они совершенно отдельны от всего другого и начинаются с префикса EXEC SQL. В-третьих, SQL — язык очень высокого уровня. Поэтому число подлежащих изменениям предложений обычно невелико, и смысл этих предложений можно легко уяснить. В результате необходимые изменения делаются, как правило, легко. Это не похоже на предложения обновления в языках сравнительно низкого уровня, таких, как PL/1 или КОБОЛ, где смысл данного предложения в большой степени зависит от динамической логики управления—от программы к предложению в запросе. Поэтому, хотя и справедливо, что должны быть сделаны некоторые поправки вручную, требуемый объем работ на практике не будет настолько большим.

Вернемся на минутку к примеру с таблицами SX и SY. Фактически представление S, определенное как соединение SX и SY, это хороший пример представления — соединения, которое теоретически обновляемо. Если предположить, что всегда существует взаимно однозначное соответствие между SX и SY таким образом, что любой поставщик, указанный в SX, должен быть указан также в SY, и наоборот, то воздействие на представление S всех возможных операций обновления понятным образом определяется в терминах SX и SY. (Упражнение. Согласны ли Вы с этим утверждением?) Таким образом, данный пример иллюстрирует, не только почему способность обновлять представления — соединения была бы полезной системной возможностью, но и случай, где такое обновление, по-видимому, является осуществимым.