Hello Jos,
If you read through a number of the older threads in this and the technical forum, you'll see that the issue of implementing ring constraints not a new one. Like you, I feel that the use of ring constraints is a natural and very useful approach to a number of ORM problems. It's frustrating not to be able to have a well modeled UofD automatically and completely projected as a Data Definition Language for a relational database schema. At first, I thought is was just a matter of the nORMa team not having gotten to the implementation of RCs, in a given release candidate of the tool. As you may have seen, there have been some "enter your code here" placeholders in the DLLs where RC implementation ought to be. Realizing my own limited skills in writing DDL scripts, I first assumed that it was just a matter of getting a better hand at scripting to take up the challenge. I haven't used VEA (though I did use a beta version of the tool), but saw, by looking into some articles about the tool, that RCs weren't fully implemented there either - which surprised me. Given the talent and resources that went into that production tool, I began to suspect that there was a more fundamental problem than coding skills in RC implementation. Taking a few stabs at thinking it through, it looks to me that there is a core discrepancy between the processes used to structure, control and manipulate relational databases (by RDBMS implementations), and the conceptual logic of at least some types of ring constraints.
Most of what is accomplished in a relational database is accomplished by the establishment of a structure, or schema, that reflects the logical structure of a conceptual model of the given domain - the RDBMS taking care of the process details that allow the data to be treated AS IF it were manipulated as complete sets, rather than as individual values being looped through programmatically. A RDBMS is, after all, a program; and as such really doesn't "do" set manipulations - only process flow that produces results that simulate set manipulation (and if the RDBMS is any good, it does this simulation in a very efficient manor).
At least some types of ring constraints don't seem to be expressible in terms of a data structure; they seem to require an awareness of the values in within the structure as these values change. It doesn't appear to be enough to know the "type" for a set of values, but rather to know what ALL the actual values are for ALL the types concerned with the RC, at a given given time (state of the DB). If you used RCs to model a rule about grandparents, the rule may be easy to express in the conceptual model; but when it comes to the physical implementation, it's pretty easy to see that who is to be considered a grandparent will depend on if and when grandchildren are entered into the database. As each person is added to or removed from the DB, that will effect who will be considered a parent, which then will determine another person's status as grandparent.
It's my guess that there won't be a DDL solution to these types of problems, but that some recursive procedures will be needed to implement at least some types of RCs. This raises issues of efficiency. RDBMS are highly efficient at data that fits within the constraints of the Relational Model. Programmatic approaches can't match that efficiency on RDB's home turf; but can perform manipulations that the RM was never designed to address. A hope is that new approaches to integrating general purpose programming language code with relational database structures will allow the strengths of each to work together in as efficient a solution as possible. So, an RC might be implemented not only within the data definition language of am RDBMS, but will also include data manipulation and data control language elements.
I still foresee theoretical limits to just how efficient such hybrid language solutions can be. It will be up to the modeler to assess the value of implementing those rules that require RC usage, for a given modeling challenge. Will the inefficiencies of the code required to recursively step through the values in a DB be worth the implementation of a given rule/FactType? That will be a judgment call, that will depend on a number of factors: the importance of enforcing the rule within the DB, the size of the DB, the efficiency of the code and the power of the processors, among other considerations.
Some bright person may well show that I got this wrong (which, ironically, would make my life easier), and there IS a a way to implement all types of RCs efficiently in DDL alone, but I'm not holding my breath. I see ring constraints as conceptually elegant, but difficult to implement in a physical instance of a RDBMS.
By the way, I haven't had a chance yet to test the extent of RC implementation in the Sept. CTP of the nORMa tool. ANY progress they made in here will be appreciated. Bottom line for me is that RCs are too useful conceptually to abandon; I'll just keep in mind that they will likely remain a tough nut to crack for physical DB implementation. BRN..