Conceptual Data Model

After completing the initial analysis of the system, you'll probably have a set of Entity Relationship (E/R) diagrams, a listing of domains used in the system, and some notes regarding data constraints. It's simple to get these organized into a presentable format. The entity analysis, perhaps illustrated by an appropriate E/R diagram for complex entities, is adequate documentation of the model. I usually treat the domain analysis as a kind of glossary in a separate section, referenced within the model proper.

This is one place where page after page of tables is probably inevitable. And there is no avoiding the fact that this is a fairly technical discussion, but it's one your clients can't avoid. All you can hope to do is make the process as painless as possible.

First, use the least technical terms you can, and use no more of them than you need to. "Table," "field," and "record" are probably inevitable, for example, but "entity," "relation," and "attribute" are best avoided. I know that less technical terms are imprecise. But they are close enough. Also make sure to define any terms you use (preferably without giving your users a short course in database design).

In practice, this isn't much of a problem. Once you've explained that each table represents a "thing" and that the fields are the "bits of information" about that thing, your clients are usually ready to go. You might have an occasional query about zip codes being handled as character fields or some such, but I prefer to deal with such issues informally as they arise.

If the document is doing double duty as a technical specification, you'll need to include any technical details the development team requires. I try to keep these details separate from the main tables, usually as a subheading under each entity. It doesn't take long for the clients to realize that they don't need to understand "this stuff." In these situations, I usually tell my clients that they need to review the attribute list for completeness and the domain analysis for accuracy, but they can ignore the rest.

In theory, the client should review the relationships among entities as well, but in practice I've rarely had clients catch any errors or misunderstandings in this area, and then only when I reviewed the model with them face-to-face. It's all just a little too foreign.

You'll have better luck asking users to review field sizes and data types. But even here, if you have serious concerns, it's safer to schedule a review meeting with the appropriate people. I find this tedious, but it's critical that these things be correct, so it might be unavoidable.

Alternatively, you might highlight the items you're concerned about. People's attention tends to wander when they're presented with 50 pages of tables to review, so if you highlight the items you need confirmed, you're likely to get better results.