The Innovative 3-Dimensional Data Model

D³ significantly improves on the relational data structure by providing the ability to store all of the information that would require three separate tables in a relational database, in a single 3-dimensional file. Through the use of variable field and variable record lengths, the D³ database system uses what is called a "post-relational" or "three-dimensional" data model. Using the same example (project reporting by state and fiscal period), a single file can be set up for a project. Values that are specific to each state are grouped logically and stored in the project record itself. In addition, the monthly budget and actual numbers can then be located in the same project definition item. There is no limit to the amount of data that can be stored in a single record using this technology. Figure A shows how the same data that requires a multi-table relational database structure can be constructed using a single file in D³.

Figure A: Using D³ to Maintain Unlimited Data Relationships

In this diagram, the entire cube represents a single project. For each state participating in the project, a row is added to the face of the cube. There is no limit to the number of states that can be added, nor is there a minimum number. Reporting months that are established for a project are represented by the columns on the face of the cube. And finally, reporting years are established simply by adding another "layer" to the cube, thus making it a truly 3-dimensional data structure.

It is important to note that in D³, the data items themselves are not tied to a specific database schema. In other words, files can be added to the database, and up to three levels of fields can be added to any file without requiring any additional database or schema maintenance. In addition, since the database uses variable length fields and items, there are no minimums or maximums on the total database size. D³ only stores data when data is there. The total amount of data that can be stored is limited only by the total physical disk space available.

Other Relational Data Models

In a typical relational database, data is stored in "tables" with separate table elements broken into records (typically represented as "rows"). Data in records is categorized into fields (also referred to as "columns") representing the different data elements (e.g., name, phone number, ZIP Code, etc.). The result is that for each record, only one piece of data can be assigned to a specific field. If multiple entries are required for a field, either additional fields must be provided in the table, or a separate table must be set up and links established between the tables defining the relationship between the two tables. The layout of such a database is referred to as a "schema."

A simple example of a schema design would be one that can be used to store budget and actual spending information for a project. Assume that the data is to be stored by state and fiscal period. If projects are always managed identically across all states, and projects always last a fixed number of months (periods), a table can easily be constructed to contain the budget and actual numbers by state. If, however, projects are managed differently in different states, and the number of months for projects varies from project to project (as is usually the case), things become more complex. One table must be set up to contain basic project information, a second table must be set up to contain the project information specific to a state, and a third table must be established to store the monthly budget and actual amounts. The three tables are then linked using what is called a "one-to-many" relationship. This means that there is one project record and many state records. Additionally, each state record has a one-to-many relationship with the monthly records.

Figure B: Using a Relational Database to Maintain
One-To-Many Table Structures