Rel Var

A relvar -- short for "relation variable" or "relation-valued variable" -- is a variable associated with some representation of a relation. In the RelationalModel, a database consists of one or more (usually persistent) relvars plus zero or more database constraints. Most RelationalLanguages implement RelVars, which generally employ typical programming language variable semantics; SqlLanguage implements tables, which do not have typical variable semantics.

Any and all relevant database meta-data, such as triggers, procedures, constraint-definitions, views, type-definitions, etc., are represented as relvars and their associated relations. However, RelationalLanguages will typically provide user-friendly views of these. For example, procedure definitions may be represented in the database as tuples in a relation referenced by a Procedures relvar, but they will usually be available to the RelationalLanguage as conventional procedures that can be invoked by name, passed arguments, etc., using a familiar call syntax.

FirstClass support for RelVars qualifies, without much contest, among the KeyLanguageFeatures. This implies support for automatic and appropriate performance optimisation -- e.g., indexes, without which RelVars wouldn't see much practical use -- and support for language-integrated queries.

---

The current tools of our industry have limited our thinking and made a distinct separation of database from application. But really, the database is just another variable accessible within our application.

Regarding a database as relvars rather than tables encourages the view that database queries consist of algebraic expressions (via the RelationalAlgebra) on relations. Database updates are performed by assigning the result of evaluating such expressions -- i.e., the results of queries -- to relvars, rather than being a series of ad-hoc table mutations. INSERT, UPDATE and DELETE operations on relvars are considered a convenient short-hand for assigning the result of a relational expression to a relvar.

For example (using TutorialDee syntax), given the following database relvar:

 VAR myRelvar REAL RELATION {x INTEGER, y RATIONAL} KEY {x};

...the following INSERT...

 INSERT myRelvar RELATION {TUPLE {x 1, y 2.3}};

...is conceptually short-hand for:

 myRelvar := myRelvar UNION RELATION {TUPLE {x 1, y 2.3}};

The analogue between the RelationalAlgebra and variable assignments as used above, and (say) numeric algebra and variable assignment should be obvious. E.g., given:

 VAR myIntvar INTEGER;

...the following...

 myIntvar += 3;

...is conceptually short-hand for:

 myIntvar := myIntvar + 3;

This view is subject to some debate. For example:

During mutation, students of the RelationalModel are generally encouraged to view the relvar as changing from one relation to another on the temporal dimensions, with the relations themselves being immutable. Viewing mutation in this fashion might (stated without evidence) aide young programmers who have been weened on Basic and other imperative languages in getting comfortable with the relatively 'massive' relations, but there isn't any computation-theory reason to do so - it is just as valid to view the database as a variable with a single, immutable value that changes from one transaction to another, or to view a tuple identified by a particular candidate-key as a single mutable object whose attributes and even state-of-existence can change from one transaction to the next. I find it discouraging that purveyors of a model designed to handle such a wide array of 'views' refuse to get issues of BundleSubstanceMismatch right. In computation theory, all that matters are the identifiers and the attributed properties.

Regarding a database as a variable with a single, immutable value (in particular, a tuple with a relation-valued attribute for each "relvar") is described by DateAndDarwen in Appendix D of the 3rd edition of TheThirdManifesto.

---

ObjectVsModel suggests that projective data can be reasonably dropped into objects (offering encapsulation should you wish it) while reflective data ought to be held within a RelVar (since it is inherently global and should not be encapsulated).

---

See the RelationalModel.

---

EditHint: Merge with RdbRelVar and RelationalVariable