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

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

Применение флажков условий

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

В качестве примера, соответствующего даннор! теме, рассмотрим приложение, в котором пред)смотрено сопровождение разнообразной информации, относящейся к продаваемым товарам. Информация о товарах может быть представлена в виде сертификатов качества, сведений о поставщиках и многих других документов, количество которых не ограничивается. Предположим также, что данные о товарах хранятся в базе данных AdventureWorks и количество этих товаров превышает 504 (нередко приходится сталкиваться с тем, что деловые предприятия хранят в своих каталогах сведения о 50 тысячах и более товарных позиций). Таким образом, возможное количество строк с информацией о товарах может оказаться весьма высоким.

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

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

определить, доступна ли дополнительная информация. После этого можно ввести в таблицу Product Information триггер, который обновляет битовый флажок в таблице Products. В таком случае вставка любой строки в таблицу ProductInf ormation приводит к тому, что для соответствующего товара указанному битовому флажку присваивается значение TRUE. А при удалении строки из таблицы ProductInf ormation достаточно проверить, бьша ли эта строка последней относящейся к рассматриваемому товару, и в случае положительного ответа на этот вопрос снова присвоить битовому флажку в таблице Products значение FALSE.

Ниже приведен очень краткий пример. Прежде всего проведем подготовку к использованию битовых флажков; для этого введем дополнительный столбец битовых флажков и создадим таблицу Product Document:

ALTER TABLE Production.Product

ADD InformationFlag bit NOT NULL CONSTRAINT InformationFlagDefault DEFAULT 0 WITH VALUES

После этого внесем изменения в данные таблицы с учетом того, что к некоторым товарам уже прилагается документация:

UPDATE р

SET р.InformationFlag = 1 FROM Production.Product p WHERE EXISTS (

SELECT 1

FROM Production.ProductDocument pd WHERE pd.ProductID = p.ProductID

Теперь можно добавить триггер:

CREATE TRIGGER DocumentBelongsToProduct ON Product ion.ProductDocument FOR INSERT, DELETE

DECLARE ©Count int

SELECT ©Count = COUNT(*) FROM Inserted

IF ©Count > 0 BEGIN

UPDATE p

SET p.InformationFlag = 1

FROM Inserted i

JOIN Production.Product p

ON i.ProductID = p.ProductID

IF ©©ERROR != 0 ROLLBACK TRAN

SELECT ©Count = COUNT{*) FROM Deleted

IF ©Count > 0

BEGIN

UPDATE p

SET p.InformationFlag = 0

FROM Inserted i

RIGHT JOIN Production.Product p ON i.ProductID = p.ProductID WHERE i.ProductID IS NULL

IF @@EFLROR != О ROLLBACK TFAN

На данный момент все готово для проведения проверки:

SELECT ProductID, InformationFlag FROM Production.Product p WHERE p.ProductID = 1

INSERT INTO Production.ProductDocument

(ProductID, DocumentID) VALUES

(1, 1)

SELECT ProductID, InformationFlag FROM Production.Product p WHERE p.ProductID = 1

В результате формируются правильные результаты обновления: ProductID InformationFlag

(1 row(s) affected) (1 row(s) affected)

(1 row(s) affected) ProductID InformationFlag

(1 row(s) affected)

DELETE Production.ProductDocument WHERE ProductID = 1 AND DocumentID = 1

SELECT ProductID, InformationFlag FROM Production.Product p WHERE p.ProductID = 1

И в этом случае результаты обновления являются правильными: ProductID InformationFlag

(1 row(s) affected)

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