1. Database Environment Build Process.
2. Clone Database Environments
3. Well defined Schemation Directory System for your Code
4. Single Script Call Performs all Duties
5. Simple and Powerful Security Map Definition
6. Modular Builds
7. Named Modules
8. Full Auditing
9. Timed Builds
10. 'When you want it' Builds
11. Automated Builds
12. Data Supersets
13. Data Refreshes
14. Simple Data Definition
15. Named Data Sets (Allows Modular Development)
16. Data Load Reports (Summary and Detailed)
17. Support for BLOBs and CLOBs
18. Constrained Loads
19. Parallel Loads
20. System Administration

Schemation DEM's core feature is its ability to build, deploy and manage a complete database environments from your source code easily and without the need for DBA privileges.

Our schemation_build process works with a pre-defined and very flexible structured directory system.  We call this the Schemation Directory System.  This is just a normal operating system directory that has been given a particular structure.  Under this structure you will be able to define your system, in a modular way.  This leads to greater understanding from the start about where things should go and how to break things up into workable modules. 

Performing database builds after the initial installation and set-up requires just one command.

% schemation_build

The code will then do everything else required to either build from scratch, or to rebuild an existing environment.  You then simply 'watch' the build take place using your web-browser.

We like things to be simple and powerful.  So we devised our security map file.  A single definitional file which establishes all security privileges between schemas in your environment.  Our method enables you to very simply see who is allowed to do what, with which objects.  For simple environments this can be edited in a simple text editor, for more elaborate environments you may use your preferred spreadsheet program such as Excel.  Either way Schemation will pick up your 'map' of the layout of security for your environment from one simple file.

Entire environments are built from the contents of the Schemation Directory System.  However, there are times when you may not wish to perform a full environment build.  Suppose you have written a partition split script that breaks up a data warehouse table into many partitions, ready for the production build.  But, in development you don't wish all these partitions to be created every time, as you are at the stage that only expects the table's structure to be correct and not its physical implementation.  Then by placing your partition split code in a separate directory in the Schemation Directory System, you will be able to include or exclude this stage by listing it in the environment's code list file, or commenting it out.  This makes it very easy to develop components and to add then them to the final build when complete.

Our modular building method also provides developers with the ability to build environments to specification.  The naming of modules in the Schemation Directory System can enable developers to customise their own 'Repository Based' builds using the Web-Based Interface.  All modules defined will appear in a multi-choice menu list from which the developer or tester may choose which are required and which are not.  So, therefore, to build a full volume test database for production volume testing, the controllers of the test environment need to ensure that they build a fully partitioned environment, and this they do by selecting the 'full_partitioning' option in the code build list menu, and then re-build their environment. 

All environment builds, executed with Schemation, receive meticulous attention to detail by our logging process.  After each build, and even during, you can use your web-browser to drill down to all commands executed to build or rebuild your environments.  This includes details of all errors encountered and summaries of all data load errors.  All commands are recorded including the DBA commands issued to seal up and then remove the previous environment's schemas.

Using the web interface a user that has controlling rights to an environment may request to build from a repository at a convenient time.  This may be while at lunch or in the middle of the night.  Schemation will wake up and build the requested environments, at the appropriate time.

Developers may choose if they wish to rebuild right away.  Sometimes, it is not convenient for them to have the latest database model and they can defer a rebuild.  Others may choose to continue working for the rest of the day using the old version, and have their environments rebuilt to the new version overnight.

Schemation’s Auto-Build functionality provides an easy way to have your database automatically built for you without having to do anything - apart from connect to the database and use it of course. 

All you have to do is use Schemation’s web-based configuration tool to specify which version of the database you want, which dataset you want loaded and what time you want it built and Schemation does the rest.  The Auto-Build also allows you to restore/reload data to its original state at any given time without a full database rebuild.

When an individual decides that they would like the latest version, or maybe a version one week old, using the web-based interface, they can select which version of the environment they wish to work with next.  This selection will be presented as a pull down list in their environment's profile page.  Building to a specific (or Standard) release is just a matter of making a selection and pressing a button on the web-page!  Schemation will then perform a fully audited build, clearing down their existing environment and rebuilding it to the specification requested. Complete with data!

The DBA would normally be responsible for performing the build of the project's repositories and would then publish the availability via an email.  It is then up to the controllers of an environment as to whether they get the latest version straight away or leave it until later.  This introduces a level of independence between the DBA and the users of environments.  Each being able to work without having to be constrained by the others.

Repositories may be defined to hold supersets of data.  This means that a repository may hold a number of 'named' sets of data.  As long as the original Primary Key remains intact with all named sets of data present, then the repository is able to hold many named sets of data.  This is particularly useful in handling the differing requirements of your project team.  Some users may require 10,000 rows of test data, others may just require a handful of records for design proving.  The controllers of each environment get to choose what they want using a multiple selection menu in their environment profile page.  It is quite typical that the DBA will compile all required data sets into the same repository and let the users decide what they want.  Rebuilding with different data, maybe different test scenarios, is just a case of making the new selection and pressing the build button from your browser.

Schemation enables an environment's controller to make changes to the environment's data set list, and then to request a data only refresh.  Under these conditions, the environment's structure is retained and all data is removed.  Using the new data set list, Schemation will then fill the environment according to the new specification.  If a controller requests a refresh of data, without making changes to the environment's data set list, then Schemation will reset the data back to its freshly built state.  This facility is particularly useful when data has been corrupted by program activities, and you just wish to back out these operations.

Our approach to defining and including data is simple and effective.  The data to be loaded into a table is stored as a delimited file in a file named after the table.  The file is placed into a directory named according to the function of the data stored within.  Then the name of this directory is placed in the environment's directory listing file.  When the next 'Custom build' is performed, all data found in files in the listed directories is loaded into the corresponding tables.  The order in which loading is performed is determined by Schemation from any referential integrity built into the schema.

The name of the dataset is the name of the directory in which data files are located.  Adding a new section of data can be as simple as defining a new directory.  In this way, Schemation eases the process of modular construction for data allowing easy identification and separation of unrelated data.  When this data is built into a Repository, the name of the data set is used to identify every row of data.  This provides the mechanism by which we can offer a list of available data sets to anyone wishing to produce a Standard build from this Repository.

Every file containing data for a table which is part of the data load for an environment is processed by our data loader.  Based on SQL*Loader technology, the loader creates it's own control file for the load, and then loads data.  On completion of the load, an analysis of any errors is performed, and an error message for each type of error is recorded in Schemation's data logging tables.  We don't just report every single error.  Instead we interpret the errors.  For each different type of error encountered, we will report the identities of the first 10 records rejected.  (If you have 10,000 rejects because the value of a NOT NULL column had been forgotten about, then we tell you the identities of the first ten.  This should be enough for you to pick up the generic issues.  We do, however tell you that there were 10,000 rejects.)

Schemation makes loading BLOBs and CLOBs easy.  For CLOBs, you may either enter your string value into the data file directly, if the string is short, or you place a tag in the data field which points to a file on the system that contains the CLOB to be loaded.  In the later case, the file is specified relative to the location of the data in which the tag is located.  For loading BLOBs, only the tag system is available and it works the same as for CLOBs.

Schemation's policy, and of course good practice guidelines, dictate that data is loaded into target schemas with all referential integrity constraints enabled.  This enables the quality of configuration and control data, that might driver your application to be presented with data that has passed, at least the basic quality checks of integrity.  But, referential integrity means that we set up a dependency order between our database objects and this leads to a loading order expected from an data load activities.  Schemation automatically adjusts its data load order to suit the integrity constraints defined on the schema's objects.  This again, frees the DBA from working out what to load first, or from disabling the constraints before loading.

With referential integrity in place, Schemation works out 'phases' of load.  These are sets of tables which may be loaded without regard to each other.  All tables at the same phase can be loaded at the same time and carry no dependencies between themselves.  Schemation speeds up the process of loading data into all tables in the same phase by running load jobs in parallel.  The number of concurrent load jobs that may run in parallel is defined at parameter level.

Schemation's Custom-Build, works from the file system level of Windows/UNIX/Linux.  Any developer may check out the directory system, which contains your database definition, using your existing source control system.   The developer may then edit these files, as required, then execute the Schemation custom build process.

The custom build process is then able to use the environment management powers of Schemation to completely recreate the environment from scratch, including: performing all DBA actions required to clear down the existing environment; re-creating user accounts; building objects; instantiating security privileges and grants; loading data and executing SQL data-generation scripts; analysing schemas after loading.  Using our modular approach to building, it is possible for such a developer to build environments which only contain the sections of interest, thereby saving time and resources during environment re-builds.