Контроль целостности данных — одна из важнейших функций СУБД. Чем тщательнее этот контроль организован, тем проще реализовывать прикладную логику, ведь чем больше ограничений контролируется базой данных, тем меньше вариаций «а что, если» следует предусмотреть при реализации логики. В то же самое время контроль целостности оказывается достаточно удобно использовать и для проверки корректности работы прикладного слоя. Что-то вроде юнит-тестов. «Лишняя» проверка, порой может сослужить очень добрую службу.

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

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

Казалось бы, зачем вообще может возникнуть необходимость разбирать XML на стороне БД?

Но на то может быть много причин, и у каждого они могут быть своими. Некоторых, и меня в том числе, вовсе не гнушает реализация прикладной логики средствами БД, а кому-то это кажется архаичным пережитком и полезность инструментария для работы с XML в СУБД, таким людям может показаться сомнительной. Однако, полагаю, мало кто станет возражать в полезности наличия такой возможности на этапе эксплуатации приложения. К примеру — не приняло у нас приложение прайс-лист оптовика — сумбурно выругалось на отсутствие перекодировки по каким-то позициям. Более 20к позиций в XML — поди там разберись, где собака порылась, что конкретно смутило приложение. Согласитесь, ведь тут здорово было бы иметь возможность представить список товаров, перечисленных в XML в виде набора данных, который можно соединить с перекодировочной таблицей, чтобы выявить одним махом все позиции, не имеющие перекодировки? И подобных примеров может быть приведено множество. Мне доводилось заниматься поддержкой приложения, интегрирующегося с внешними системами посредством обмена XML сообщений, и, не смотря на то, что приложение самостоятельно не использовало предоставляемый Oracle инструментарий, он оказался и весьма кстати мне и моим коллегам при поддержке этого продукта.

В этой статье я хотел бы продемонстрировать на сколько легко и непринужденно можно разобрать XML различной степени сложности используя инструментальные средства Oracle Database.