Постреляционные базы данных

Как уже говорилось, реляционные базы данных состоят из двумерных таблиц, связанных между собою. Таким образом, при проектировании реляционной БД вся информация разбивается на множество двумерных массивов. В некоторых случаях таблица соответствует множеству реальных объектов, например "отделы", "сотрудники", "счета" и т.п. Но иногда, когда приходится иметь дело с иерархической информацией, один и тот же объект приходится "раскладывать" на несколько таблиц.

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

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

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

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

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

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