|Schemation is an
out-of-the-box Database Environment Management (DEM) tool that
has been designed to meet most database build and management
Environment Build Process.
Environment Build Process.
defined Schemation Directory System for your Code
Script Call Performs all Duties
and Powerful Security Map Definition
you want it' Builds
Data Sets (Allows Modular Development)
Load Reports (Summary and Detailed)
for BLOBs and CLOBs
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.
DEM allows you to clone database environments easily without the
need of high-power DBA privileges.
Schemation Directory System for your Code
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.
Single Script Call
Performs all Duties
Performing database builds after the initial installation and
set-up requires just one command.
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
Simple and Powerful
Security Map Definition
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
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
|Developers usually like
to work with the latest version of a database. When a
new version is produced, by the DBA or the data modellers, a
repository can built to this new standard. Once a
repository is available, developers may then choose when they
would like to have their own environment rebuilt.
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
allows you to control your environments using a very simple and
comprehensive web interface. Through this interface, you
may check the status of any environment and request the complete
rebuild of environments which are based on repositories.
These builds may be requested at any time by pressing just a
single button on the web interface. No logging into UNIX
or performing difficult activities in Windows. Just fire
up your browser, find your environment's control panel and push
the build button. - You can then keep your browser running
and watch as all the work is performed by Schemation's 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.
|Schemation allows the
DBA to build super environments called repositories.
These are very useful when you have a number of different
individuals who require access to standard database releases.
Testers, developers, QA assessors, data entry individuals and
DBAs all fit into this category. Each may be given a
totally separate personal environment, or group environment
which remains their responsibility. The DBA will then
build standard repositories.
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!
'When you want
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.
Schemation, it is often the case, that the DBA will perform a
new database release, publish the fact and then sit back and
watch others pick up the reigns and build their environments
when required. This may be a manual activity, where a
controller of an environment logs in to the web-site and
requests a rebuild online. Or it may be a timed re-build,
where the time and/date of a rebuild request is entered, or it
may be requested to be performed overnight. Either way,
your users will get the environments they want at the time of
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
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.
Named Data Sets
(Allows Modular Development)
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.
Data Load Reports
(Summary and Detailed)
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
Support for BLOBs
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
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
|Once installed, Schemation
allows you to perform all of its system administration functions
using your web browser. This simplifies the tasks involved
and gives you freedom from having to learn lots of difficult
functions. Schemation is simple to use, simple in concept
and can be easily administered through the administration pages
of the Schemation site.
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