Rick van der Lans states in articles and seminars that it would be nice for database implementations to be more generic. Have less business rules implemented in the database structure and more in constraints. Consequences for having rules change are enormous.

It requires re-engineering of the database, the applications and rearranging existing data. Having a rule change once a year would be not a big issue, but since requirements change more often and faster than ever, it is perhaps a trend to look at.

Conceptual

CaseTalk gives analists the tools to make flexible models. This article briefly shows the scope between an common model in structure and the flexible, more generic, model.

This is the elementary model of the apprenticeship example:

Normalized

If database developers need to have a fully optimized database structure, they'll typically perform the GLR and come up with the structure like this:

THE Corepula Method

This method is described and explained at TDAN in length. And it boils down to normalizing static structures and leaving non static structures outside of this process as much as possible. We can accomplish this very easily by tweaking some settings in our model. Suppose we want to be able to change the Apprenticeship table for future insights. Therefor we will leave all attributes in their fact based form (aka 6th normal form). By simply setting the "Apprenticeship Description" to be excluded (non grouped) in the transformation, the result will be this ERD schema:

Flexible Database Model

However if the database system needs even less rules in the structure to allow everything to change later on without re-developing applications, a simple and straight-forward lexicalization will do the trick. This will leave the elementary model as a 6NF and create many database constraints instead.

Note that the structure will be a column oriented database structure.

It will look like this:

 Conclusion

Flexible database models are also considered generic models, since the structure which is created is usable for many different systems, only the rules or constraints are to be adjusted for the specific purpose. CaseTalk allows analists to set these choices per OTFT within the tool allowing an automatic transformation from database structures with all rules implemented or a generic model with all rules as constraints.

Rick van der Lans has a Dutch article on his website with the arguments in favour of generic database models. Click here