Main Page

From Template Database

Jump to: navigation, search
Comparison between the traditional relational database and the template database.  In the relational database, the logical data model corresponds directly to the physical data storage model, with the data type for each column coming from the relational schema.  In contrast, the logical data model of the template database can be quite different from the physical data storage model through data access abstraction.  Values as well as template containers have types associated with them.  Type mapping is needed to convert data from various domains to a single restricted domain.
Comparison between the traditional relational database and the template database. In the relational database, the logical data model corresponds directly to the physical data storage model, with the data type for each column coming from the relational schema. In contrast, the logical data model of the template database can be quite different from the physical data storage model through data access abstraction. Values as well as template containers have types associated with them. Type mapping is needed to convert data from various domains to a single restricted domain.

The template database is an extension of the relational database that provides schema-freedom. Unlike traditional relational databases, it removes initial schema requirements and treats schema as constraints that can be added or dropped incrementally, over time. The database has no particular limits on the number of the columns, and no restrictions about there being a single specific type for a column. It also has little knowledge of what is being physically stored in the tables, and delegates most tasks to be performed dynamically, at query time. We view this behavior of the database as similar to the template design pattern, hence the name of this database.

A simple analogue of the template database table might be a BibTeX file in which each entry can have an arbitrary number of tags. Depending on the formatting style, specific tags are extracted while the rest are ignored. However the attribute-value mappings (`feature vectors') implicit in these tags also can include type and constraint information. In fact, we have a BibTeX importing utility for the template database since BibTeX entries can be stored and queried naturally inside the template database.

In a template database, a tuple is a template container, a dictionary-like structure that can hold arbitrary numbers of attributes and arbitrary types of their values, including literals such as text, integers and dates. A template container itself can also be an array, and contain annotations that are used to describe the data. There can be different types of template containers, so that we could map from one to another in a way like mapping among literals.

The template database also allows indexes and constraints, including column constraints --- unique keys, foreign keys, and required columns and data types --- to be developed as needed to improve performance or to enforce data integrity. Hence it can provide the benefits of schema constraints.

Like the traditional relational database, the template database also uses relational algebra to perform the queries.

Because template database is a container database, sometimes it is also named template container database (TCDB).

Under Construction

This site is still under construction with lots of documentation tasks to do. At the same time, bug fixes and feature adjustments are still being worked on before the first alpha release of the code. Initial preview of the code can be seen in SVN.

Note that functionality wise version 46 in SVN is complete. For later versions, a new data structure is used for performance reasons. Schema constraint functions and modelbase functions have not yet been updated to reflect the changes.

Getting started

Personal tools
Modelbase application