For the last few weeks I’ve been working on three elements of an enterprise system – high-level functional requirements, the system architecture and the geodatabase design. I’m working from a mass of information collected from weeks of on-site meetings and a mountain of documentation supplied by the client. And, for the most part, things are going pretty well. Except for the actual geodatabase design experience.

The Present
The standard practice for creating a geodatabase model is to use Visio or Rational Rose to cookup the model in UML. Ok, I can see where this started – UML is handy for designing class model diagrams, and the various elements in the geodatabase are classes. But there is a lot more in the geodatabase than can not easily be managed in UML – projections, topologies, rasters. And the whole use of tagged values is truly painful. Overall, the entire process is horribly inefficient.

One issue is that there are several hundred possible “types” for a field…

While this makes sense for a Uml model, it’s a pain for geodatabase design, as there are only 12 valid attribute types (plus the Domains in the model). Yet I still have to jump through this list for every single attribute on every single class.

Once you’ve finally created your model, and gotten it to validate, you then need to load it into a geodatabase. This is pretty smooth, but you need to manually define the projection for every featureclass (or dataset) in the model. And then you need to setup the topologies. Manually. If you need to do this iteratively – like most design processes – then you need to repeat this process several dozen times.

Don’t get me wrong here – this is a million times better than trying to manually bake a geodatabase via the ArcCatalog interface, so thanks to ESRI for giving us this option. But, if we’re wishing for 9.3 goodies, this would be a nice thing to fix.

The Future
What I’d like to see (either from ESRI, or anyone else who’s got some time, and wants to make some money) is a tool which can handle all aspects of the geodatabase. I want to define my topologies and projections in the design, not later. If I’ve got rasters, let me have them in the model. Networks? Yep. The question is: How?

Lets start at the end – How can we get a geodatabase design into a geodatabase? The current method is to use the CASE Tools in ArcCatalog to load the Visio or Rational produced Xmi file. The other option is to use an Xml Workspace document. They store all aspects of the geodatabase, so it’s an idea option. Typically these are used to transfer schemas (or data) between geodatabase instances – usually ArcSDE instances, but there is no reason that they could not be co-opted as a model storage format. Ok, that part is solved.

What we really need is a nice front end. The key here is to keep the interface simple. Designing a geodatabase is not rocket science, and should be really easy. Have some simple design surface, but I don’t see a big need to show all the fields. Just the class name, it’s type and the relationships it particpates in.

Have another design surface to show the topologies. The editor UI for the classes should be very easy to use – instead of crytpic tagged values for the geometry type – how about a pull-down? For relationships, just connect two classes with a line, and present a simple dialog for picking PK/FK, notification. Simple, focused, and all about the geodatabase. And if you offer it for $300, I think you’ll sell a ton of them. Heck – maybe ESRI buys it from you and ships it with ArcCatalog, and all our lives are just a little bit better.

For now though, it’s back to Visio for me. joy.