Databases, records management, and XML

I asked Owen Ambur to clarify something he said at yesterday's meeting and he sent me this reply:

Alice, when data is parsed into relational tables, the effect is to "shred" its presentation, i.e., the way it appeared to those who saw it when it was created. The techie weenies view that as a strength, because it means the records can be manipulated and reconstructed in many different ways. While that is all well and good for purposes of analyses, performing "what if" comparisons, etc., it is obviously very bad with respect to records management, i.e., the need to know who knew what and when they knew it.

One of the beauties of XML is that it enables us to have our cake and eat it too. That is, the original source records can be stored in *inviolate* form, with their presentation intact, in a DoD Std. 5015.2 certified E-records management system for as long as required by business requirements, while the data or subsets thereof can be parsed into databases for manipulation and analyses as needed and desired. (For
example, social security numbers (SSNs)) should not be stored in large databases with single points of failure, nor is there any good reason to store digital signatures or "binary large objects" (BLOBs) in relational databases. RDBMs are simply not the right technology to use for such purposes.) Moreover, to the degree that decisions may be based upon the data in relational databases rather than upon the original source records themselves, the process of auditing the data in the databases can largely be automated -- by comparing it to the original source records (which cannot be manipulated in *any* way).

Separating Content from Presentation: What We Don't Know (Because We Can't See It) Can Hurt Us