Traditional thinking holds that objects are records with methods. Those methods, whether byte coded or compiled, deal with a single object at a time and make very rigid assumptions about the physical representation of the data on which they operate. While this is an intuitively appealing model, it is a bad implementation paradigm in a database.

Traditional thinking holds that objects and databases are linked either by discarding the key principles of database management system design (who needs that other stuff, we do navigation right) or by treating objects as external encapsulations of the rules governing the data in the database. In the former case, if programming language strategies alone could do the job, all that ‘other stuff’ would not be needed and we wouldn’t be here today. In the latter case, the operative word is external. The more critical the rules and the more data to which those rules must apply, the more external looms large as an obstacle to scaleability and, ultimately, successful implementation. To date, the approaches for internalizing objects have been cumbersome, rigid, and generally not up the expressive power of the object languages they seek to replace or supplement.

Vision is not traditional. For well over a decade now, Vision has been quietly and successfully powering large, mission critical, operational and analytic data collection and warehousing applications in areas as diverse as media ratings and financial information systems. Vision is a true database management system that does ‘that other stuff’ like concurrency control, isolated transactions, and update atomicity. It also takes a radically different approach to data and object representation to give it its power, flexibility and scaleability and a mathematical foundation for its data representations and computational generality.

To start with, even though the Vision language looks like a traditional object-oriented language, Vision objects are not records. A traditional thinker looking for traditional record-like objects inside a Vision database would be lost. In fact, Vision objects have no direct state at all!

The physical structures that one does find in a Vision database represent sets and the ‘functions’ that map the elements of one set to another. While these notions resemble notions found in functional programming languages, the proper theoretical underpinnings are found in category theory. Note that Vision didn’t start out as an implementation of an object-oriented database based on category theory; however, the fit is a natural one that helps to solidify and extend the outside-the-box thinking that makes Vision work.

In Vision, application level objects correspond to the elements of sets; however, the sets themselves are structure-less. They represent abstractions like the set of companies in the database, the subset of values of a property of a particular type, or the set of integers. They are not enumerations of elements. In fact, their ‘elements’ don’t matter. From Vision’s point of view, the only thing that matters is that the elements of a set be distinct and distinguishable.

Everything there is to know or characterize about an object is found in or characterized by the properties of maps and families of maps that relate set elements. The values of an object’s properties are among the most important, however, maps also encode meta-information like the update trajectory taken by a collection of objects. Properties of maps, such as injectivity, serve as the basis for modeling traditional concepts like set membership and keys. Families of appropriately constrained maps serve as the basis for modeling object oriented concepts like inheritance and polymorphism, database concepts like product and union, and important semantic concepts like time-varying data and temporal dependency and correlation. Transformations of maps model join, projection, grouping, navigation and update and do so at a level of completeness that permits these transformations to serve as the computational foundation of the Vision language. Because all computation is expressed in terms of the composition and derivation of maps between sets, parallelism is inherent in the model.

It is difficult to overstate the power of the underlying paradigm. It provides a conceptual and implementation model for the computational and structural components of a general purpose object-oriented database and programming environment and it provides those models in terms of an underlying theory that generalizes the mathematical underpinnings of the relational model. And it works.

So you think that objects are records with byte codes on the side?