Database Schema

The information in the database schema is critical to the development team, but since it contains little additional information, it's largely irrelevant to the client. If you're not preparing separate documents, consider putting the table and query specifications in an appendix. The data architecture and security specifications, however, need to be confirmed by the client.

Dimensional databases can be an exception to this "developer-only" principle, however. As we saw in Part II, the data models for dimensional databases depend on the production databases from which they derive their data. Clients may very well want to confirm the data sources, and will certainly need to see a discussion of how the data will be derived, and the impact of implementing the dimensional database on the production system(s).

Whatever type of system being implemented, I usually document the data architecture using a combination of diagrams and a narrative description. This is another case of the two forms of communication reinforcing each other. The security requirements can be documented by a simple narrative description, but sometimes an outline or graphic can be useful if the security structure is complex.