About our software
I had a hobby, and a project that turned into a full time mission.
I had set out to span the gap between Relational and XML databases, what’s been called the impedance mismatch between the two. After proving to myself that my methods could be used to transform any Relational database into an XML database, I had to build it for real this time. That’s just where the story gets interesting.
I wanted to create a mechanism whereby a User could Request specific data and have that turned into an XML database. For every Customer who may have multiple Addresses and multiple Contacts (phone, email, ...) it would include all data within that Domain. This Domain can be displayed as one record with multiple aspects in XML.
A Domain can be defined, as a hierarchical set of Objects with a single table at its apex representing relational tables and their orientation to each other. To the User this means all data about one thing in one place, or a hierarchy.
Most programs are based on Domains; I’m just coining the term with respect to data retrieval. It is made up of whatever tables a programmer would need to relate to write a full program. Access defines this as a relationship.
I simplified the User’s choices with an Ask-By-Example interface - My QBE. The Domain and its Objects (tables) and their Elements (fields) are displayed in a Treeview control, so you see which Objects are the children of which Objects. The User can see reality in this Data Tree; A Customer may have Addresses and/or Contacts.
The User can select a Subset of their Domain by choosing which Objects and Elements to use, adding sort order, conditions and other qualifiers with a few clicks. From this Request they can run reports, do on-screen edits and data entry, and imports and exports including XML databases! Whatever the User wants, they can alternate between a Data Tree, a Report Grid, and an Export with the click of a button. Just like you knew it could, knew it should.
While building the objects and structures of the program I realized that I had actually constructed an engine that could create any result data set, the basis for any output I desired. Or rather the User desired. Or selected.
I made a separate screen to define Domains. It was then I realized that all of the relational components of the data retrieval process, all the really Hard stuff, belong there and everything else is a straightforward Request for data and EZ and belong there. It just happened that way.
It's a step from there to realizing you could have an IT Professional or other Expert fill out the Hard Screen and then give the EZ Screen to a User. The job changes from writing a program to operating a program. You don’t need to know SQL to Request data from a Domain. You just have to know how to pick/type "Customer = 'Smith'".
The User has access to their data without having to know how to get their data. And IT can be secure in the knowledge that the Domain; the rules of the relations game are under their control. So that new programs that took months to create can now take a week or two, report changes that took weeks can be done right away by the person who needs them right away. IT/Experts have covered the technical end, the User commands the Business Rules.
This also means that a businessman only needs someone to create Domains for them to be able to run a company with just a database, an entrepreneur’s enthusiasm and this program.
We have the engine for your data. Off the shelf it is a powerhouse. It also reduces your network traffic by up to half by volume. And we can customize any thing you might want special, quickly and easily.
This program evolved. At several turns it surprised its creator as it grew, consolidated and grew again. Solving the puzzle of Relational to XML was just the beginning.
We have a software product that provides easy Universal Database Access to those without database knowledge.
Its called Dominus.
Anthony M. Sanders.