A model in Theon contains a representation of a physical database structure. In normal database terminology this would be referred to as its schema. A model in Theon does not just contain the definition of the database structure, but also (if necessary) the presentation of that structure within TheonUI (to define interfaces for specific business workflows) and the configuration of streams for TheonCoupler (to define external sources of data and how to integrate them into a database).

Theon itself is not necessarily operated as a single centralised service. Any number of users could have their own independent installation of Theon to manage their own private models - and if necessary run the databases and application services such as TheonUI - within that instance. Commonly though, models managed in Theon would be shared (via an independent and central version control system) and delivered as one live production service. Users responsible for making changes to models would then just run their own Theon instances to make and test changes prior to committing and having them deployed onto the central production service.

Managing a model means controlling the development and change of that model (and its use in associated applications) over time as user requirements shift, but in such a way as to prevent user disruption (breakage of the live service). Theon does this by using an external schema representation that can be held in a version controlled repository (one which is independent of Theon itself). This external representation defines all (supported) aspects of a database structure, as well as dependent application specific structures such as how it is presented in TheonUI. Having unified and version-controlled development means that multiple people can be working independently on aspects of the service using their own development instances of databases. Their individual changes can then all be committed into a central repository and rolled out as staged releases onto the actual live production databases - or via test services in the first instance. There is no requirement to define anything over and above the basic database structure in Theon, but if TheonCoupler or TheonUI are being used for a particular database instance it makes little sense to represent their application specific structures elsewhere. Conversely it is not feasible to use TheonCoupler on a database unless the basic structure of that database is also being managed as a model in Theon (TheonUI can be however).

While models managed in Theon can describe the basic fundamental relational database structure, they do not cover anything like the full range of structure that can be defined directly in a PostgreSQL database. If the structure of a database is too complicated to be described in Theon, two approaches can be taken.

One is to isolate the unsupported structures and manage them outside of Theon in whatever way is most appropriate. This means that installations and upgrades cannot be entirely driven by Theon as they will need to include the additional external structures in some fashion.

Alternatively, if the unsupported structures can be effectively isolated from managed structures and are relatively static, they can be included raw in the model, effectively as blobs which are incorporated into the model’s derived database schema as-is. They can in this way also be made dependent on, or be dependencies of, other structures that are maintained in Theon.

A model in Theon is also extensible to add unsupported minor functionality to supported structures, for example to add options which are not natively supported. In some cases unsupported structures can also be adapted into supported structures in a way that does not affect functionality and/or performance. Refer to Appendix C, Supported PostgreSQL DDL Syntax which documents supported PostgreSQL DDL SQL syntax.

See Part II, “Model” for more details.