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.
This article discusses the methods which can be used to discover and model decisions in a structured manner, analogous to data normalization. Data and decisions both have important and complementary roles in this decision-centric approach. Data models show the valid states of the system at rest; decision models describe the valid transitions between the states. However, it is the state transitions described by the decision models that generates value for any business, giving the decision model a primacy that is not shared by data.
Resistance to the use of universal data models is usually based on the belief that a particular organization has unique needs or the dreaded "not invented here" syndrome. This article describes the application of universal data models to several disparate organizations. It demonstrates that the same basic models, with minor customization, can be successfully applied in each example.