seeMore makes order out of data chaos

Imagine if you will: you are the chief database administrator for a large corporation. Your organization's databases are on different continents, which has never been a problem. What is a problem is that those databases have been written by different divisions, using different database technologies: Oracle here, Sybase there, some Cobol down there, and so on.

[ See also: InfoWorld Technology of the Year Awards Application and Middleware winners ]

You have been charged with providing a single point through which all those databases can be accessed and managed — and no read-only, screen-scraping, funny stuff, either. Your superiors want honest-to-goodness, read/write access to all that data, regardless of its location and structure. Oh, and don't forget security.

Before you descend into full cardiac arrest, I'm happy to tell you that seeMore Technologies may have a solution that can rustle all those wandering databases into a single corral. Welcome to the Virtual Database zone.

Grand central server

SeeMore's Virtual Database Server is sort of like a database Grand Central Station, with you at the master controls. You connect the Virtual Database Server to all your data sources, and it provides a single access point through which database clients interact with those databases. The seeMore server isn't really a database server itself; it is a combination database multiplexer and selector, with ODBC, JDBC, and OLEDB connectors on both input (where the databases connect) and output (where the users/clients connect).

But, that's not all. Although the Virtual Database Server is an ODBC/JDBC/OLEDB-pass-through system at its simplest level, it also can make nonrelational databases appear to be relational databases.

You can, for example, connect the Virtual Database Server to a Cobol database, thereby enabling an ODBC (or JDBC or OLEDB) client to access that Cobol database as though it were a set of relational tables. The same is true of a CTree database, C-ISAM (indexed sequential access method) database, or even XML and flat file databases. Once you make the data available through ODBC or JDBC, then literally every application or development environment or third-party tool that has anything to do with databases can get at it.

Furthermore, if that Cobol database includes structured items – which would not otherwise map readily to relational rows – seeMore can "flatten" the data structures (creating pseudo-columns in the process) so that SQL queries can digest what would be otherwise indigestible. The result isn't terribly pretty, but the conversion is completely automated and it works.

The seeMore Virtual Server instantly accepts popular databases. It will happily talk to Oracle, DB2, Microsoft SQL Server, MySQL, Sybase, SleepyCat's Berkeley DB, and many others (check the company Web site for the complete list of supported databases). In fact, anything that provides an ODBC or a JDBC driver can be imported into seeMore; I connected it easily to MySQL and PostgreSQL through those databases' ODBC drivers.

Designing the database

You control the mechanics of the seeMore Virtual Server through the Virtual Database Designer. The Designer is a graphical administration console within which you import data sources (making them available to clients), define users and access lists, and build the structure of the data sources that the Virtual Server presents to its clients.

Designer is home to several wizards that I felt offered a proper amount of hand holding. The Import Data Source wizard guides you through the process of importing a new data source into the seeMore server. I especially appreciated this wizard because importing a data source is not a simple, single-step process. You may decide, for example, to import only a subset of tables from a given data source; the wizard provides a list of all the data objects available (tables, stored procedures, views, and so on), and you check off which to import. In addition, you may wish to impose read-only access to a given data source; this, again, is a choice from the Import Data Wizard.

With the help of the SQLJ Wizard, you can write SQLJ stored procedures, even if you have no Java experience — a basic comprehension of SQL is all that's required. Simply name the procedure and its class, enter the SQL expression, and the wizard builds the Java "wrapper" code for you.

The resulting SQLJ procedure executes within the seeMore Server itself, as opposed to stored procedures imported from, say, a Microsoft SQL Server database that execute on the SQL Server. In fact, imported stored procedures aren't really imported at all: The seeMore Server wraps the stored procedure call. So when a client calls an imported stored procedure, seeMore calls that procedure on the client's behalf.

The benefit is, again, that all access to the data – whether through direct SQL requests or stored procedures – goes through seeMore. Among other things, that means that the DBA can manage data access through a single "switchboard."

Because seeMore employs both SQLJ procedures created on the server itself or stored procedures imported from external databases, you can build new procedures and continue to employ the capabilities of existing ones.

Beyond database transformation

One might ask if there is any real value to the seeMore Virtual Database Server, beyond its capability of making nonrelational data sources look like relational databases. A longer look reveals that the answer is yes.

First, seeMore allows you to establish users and access lists for your databases, meaning that you can apply security in places where it might not have been otherwise possible. You can set permissions on Cobol data files, flat text files, C-ISAM files, or whatever database you import into your seeMore environment.

You choose which objects (tables, stored procedures, files, etc.) are imported, so you can limit access to parts of a data source by simply not importing the database objects to be guarded; as such, they are unavailable to seeMore clients. Best of all, seeMore does all that without interfering with current applications that need continued access to those database objects.

Next, seeMore can craft whole new data sources from bits and pieces of existing ones. You could, for example, define a database that includes a customer table from an Oracle database in Ohio, an orders table from a Cobol database in Tennessee, and a shipments table from a MySQL database in Vermont. Although those three tables are hosted in three completely different database environments, a client calling into seeMore will see them as three plain old, ordinary relational tables that can be manipulated by standard ODBC, JDBC, or OLEDB calls.

Finally, seeMore supports the notion of "synonyms," or the renaming of database objects. Suppose one of your corporation's database developers has an acute bent toward the opaque and gives tables names such as "cst001" and "ortab" instead of "customers" and "orders." Import that database into seeMore, and you can create synonyms for those tables so that seeMore clients now see "customers" and "orders" rather than the more cryptic original names. And because seeMore simply renames on the fly, programs that use the original names will continue to work. This renaming capability extends across entities such as table names, column names, data types, and so on.

Virtual Database Server is steeply priced, starting at a little less than $20,000. But this is a tool for large enterprises whose squads of dissimilar databases beg for the imposition of a unifying order. And Virtual Database Server does just that: One server to rule them all, and in the darkness bind them.

OK, maybe not the "rule them all" part, but it does do a grand job of binding them, darkness or no.