Over the last few years we've developed a number of techniques that allow a database design to evolve as an application develops. This is a very important capability for agile methodologies. The techniques rely on applying continuous integration and automated refactoring to database development, together with a close collaboration between DBAs and application developers. The techniques work in both pre-production and released systems.
There is an assumption in database design that all design can be represented in data models. I have not actually heard this assumption stated, but I have not heard it challenged either. It is true that data modelers will question whether a denormalized data model intended for direct implementation as a database truly represents the enterprise’s view of its data. This is often a reason for disagreement between those responsible for logical data models and those responsible for instantiating physical databases. However, ardent purists never act in a way that questions whether a sound logical data model can capture everything that is needed to understand a database design.
This paper describes how data professionals can take an evolutionary approach to software development, showing how techniques such as Agile Modeling, Test-Driven Development (TDD), database refactoring, and performance tuning work together on an agile project.
Modeling of relationships, especially many-to-many relationships, is particularly challenging in XML. It's no surprise that XML, being inherently hierarchical, accommodates basic one-to-many relationships relatively easily. If all one needs to represent is that a suspect has many addresses, this can be laid out in an XML schema with multiple Address elements as sub-elements within a Suspect element. Other techniques are also available for modeling relationships in XML, and attempts to settle on a standard from among this meta-modeling grab bag has caused significant controversy within XML-based efforts.
There has been much discussion about “atomic” data, but what about “molecular” data? This concept encompasses not only more concrete data specifications, but also more abstract function specifications, than conventional application development techniques.
XML is a perfectly good vehicle for describing data to be transmitted from one place to another. It is not so good for describing the semantics – the nature of – the underlying data. It cannot replace data modeling and sound database design. XML, data modeling, and database design are all ways to structure data. Each has its place. Unfortunately, our industry is somewhat confused as to what those places are. This article attempts to sort that out.