Трехмерная модель данных

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

Рис. 1: Использование D³ для хранения множественных связей между данными

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

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

Реляционная модель данных

В обычной реляционной базе данных данные хранятся в "таблицах", элементами которых являются записи (обычно назваемые "строками"). Данные в записях разбиваются на поля (назваемые также "столбцами"), представляющими различные элементы информации (фамилия, имя, телефон, адрес и т.п.). В результате, одно поле может хранить только один "кусочек" данных. Если их требуется несколько, необходимо либо заводить дополнительные поля в текущей таблице, либо создавать новую таблицу для хранения множественных значений и поддерживать связь между двумя таблицами. Карта таких таблиц и связей назвается "схемой" базы данных

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

Рис. 2: Использование реляционной базы данных для реализации связей один-ко-многим