To recap, each model (which includes the physical database schema) in Theon is represented as a SchemaTree, and the XML-Schema documents in that SchemaTree are indirectly manipulated by changing the content of the snapshot in XSDDB. The XSDDB content can be changed in a number of ways, but the basic workflow for manipulating a model is normally:

The supposition above is that there is a pre-existing SchemaTree containing the model for the physical database structure to be managed. This will be the case for example when changing a publically available model (or one in an organisational repository) as the SchemaTree will be included in the installation of the packaged ModelLibrary (or directly accessible via public repository). Otherwise there is nothing to work from, or more likely a pre-existing physical database where the intention is to now manage it with Theon. In the former case the model must be created in XSDDB from scratch. In the latter case a modified workflow would normally be used:

Subsequent updates can then be based on the new SchemaTree as in the first workflow. However, due to this live database import facility, an entirely different workflow is possible - often more useful during development due to its immediacy:

In practice a combination of all workflows (importing direct database modifications as well as making manual changes within XSDDB) is likely. For example, if there is a live physical database which is the current realisation of a model in an accessible SchemaTree, to add a column to a table:

The above would be a bit much to do on every trivial structure change, so more likely many live database changes would be made prior to being pushed through the XSDDB for any necessary direct updates and to extract an updated version of the SchemaTree. While this is a fast development workflow for purely physical database schema changes, note that for the live database structure changes to be visible (and consistent) under TheonUI then the SchemaTree in XSDDB must eventually be updated, extracted and processed.

Using an import from a live physical database is just one way to change the content of XSDDB, alongside manual changes. Another way to change the content of XSDDB is using external processes such as templating engines. This means that the XSDDB content can be generated in a consistent way for multiple elements that are perhaps each just a variation on a theme - or are simply more easily maintained in a format that is not native to XSDDB. All elements can be updated for a single change in the template by one operation, and the new values pushed into XSDDB. This is not something that could be so easily guaranteed with hand editing of all the elements. There is no constraint in Theon on what external processes can be used to do this, howwver the SchemaFactory is provided as one implementation. The body definitions of views and functions would commonly be produced by the SchemaFactory for example. While these could be manually updated in XSDDB, this would not be sensible as any changes would be lost the next time the templating engine was run to reproduce the values.

To implement a version controlled schema, obtain the SchemaTree from a checked out working copy and then commit the changes back at the end:

It is important to remember that the XSDDB database is effectively just an editing tool for the XSD files held in the SchemaTree. It is these raw XSD files that always remain the master copy of the schema, and if so desired these can be edited separately by other means (in principle at least; in practice this would be rather difficult without an equivalent tool). Any instance of the XSDDB database can be destroyed and re-created at any time - although destroying the database before exporting the content as a SchemaTree would obviously lose any changes that had been made. Developers are likely to each have their own instance of XSDDB, just like they have their own working copy of the Schema Tree itself. In practice the XSDDB is not likely to be regularly destroyed: instead (like a working copy) it would be kept around and simply "updated" to the most recent working copy of the SchemaTree files. Note that this "update" actually first deletes the current relevant content and then creates it again from the SchemaTree files. This is because merge conflicts are entirely under the jurisdiction of the version control system being used and are done by differencing the individual XSD files themselves (hence why some knowledge of the structure is useful if merging is necessary). So it is sensible to always make sure that the XSDDB is first brought up to date before any changes are made, and that any changes then made are written out as an updated SchemaTree which is committed.

Figure 11.1. Theon Architecture Flow

The diagram shows (some of) the Theon toolkit commands which are described in the following sections, and how they are associated with the flow from the data masters.