Agile data modeling and databases.
In a previous interview with our expert Dr. Michael Blaha, we talked about Patterns of Data Modeling. This is a follow up interview with Dr. Blaha on a related topic: Agile data modeling and databases.
RVZ
Q1. Many developers are familiar with the notion of agile programming. What is the main promise of agile programming? And how does it relate to conceptual data modeling?
Blaha: Agile programming focuses on writing code quickly and showing the evolving results to the customer. Agile programming is a reaction to broken software engineering practices where a lengthy and tedious process keeps software hidden until the very end.
However, software engineering need not be ponderous if you use agile modeling. Conceptual data models can be constructed live, in front of an audience — I know this for a fact, because I often build models this way. Business users understand a data model, if you explain it as you go. They are patient as long as there is clear progress and
they can see that the data model reflects their business goals.
Q2. You have posted a series of videos on YouTube that demonstrate agile data modeling. What is the main message you want to convey?
Blaha: The videos demonstrate that it is possible to rapidly construct a conceptual data model. (Many developers do not realize that it is possible.) The videos use the example of developing library asset management software and are representative of how I build models.
Q3. What about object oriented databases?
Blaha: When I develop data-oriented applications I always start with a data model — this applies to relational databases, object-oriented databases, flat files, XML, and other formats.
For object-oriented databases, the UML class model specifies the structure of domain classes. Several books elaborate the mapping details, such as my book Object-Oriented Modeling and Design for Database Applications.
The trickiest issue for mapping a UML class model to OO databases is the handling of associations. An association relates objects of the participating classes and is inherently bidirectional. For example, the WorksFor association can be traversed to find the collection of employees for a company, as well as the employer for an employee.
By their very nature, associations transcend classes and cannot be private to a class. Associations are important because they break class encapsulation.
OO databases vary in their association support. ObjectStore uses dual pointers — a class A to class B association is implemented with an instance variable in A that refers to B and an instance variable in B that refers to A. The ObjectStore database engine automatically keeps the dual pointers mutually consistent across inserts, deletes, and
updates.
Many other OO databases lack association support and require that you architect your own solution. You can have dual references that application software maintains. Or you can build a generic association mechanism apart from your application. Or you can just implement a single direction when that suffices.
In any case, a data model documents associations so that they are clearly recognized and understood. Then you are sure not to overlook the associations in your application architecture.
You can watch here the series of videos:
I like what you say. I do not understand why one would attempt to develop a data oriented system without first performing a few rapid iterations of a conceptual model.
Think about it, a conceptual model calls out concepts, definitions, and associations. A high level object model calls out objects, responibilities, and collaborations.