In our often used example about blood pressure, we wanted to add a fact for the appointments our patients need to make beforehand.

The fact expressions are pretty straightforward and the rules are similarly simple. The fact "Patient 564432 has an appointment for a checkup on 2010/10/13" contains a structure similarly straight forward:

And when added to the model, and complemented with a wide unicity constraint, it shows in the diagram as such:

With the embedded model transformations, we can have this model be depicted in a relational form, and we can see how the appointment is an optional N:M relationship between the patient table and the table for our days:

The beauty of being able to generate other models with CaseTalk, shows by adding a new business rule:

Patients can only have a checkup when they had an appointment.

To implement this rule, we can simply add a subset constraint tot the model. All populations under the Checkup must occur in the Appointment:

When we now look again at the generated relational diagram, you will notice we need to instantiate the appointment table. It cannot remain just a many-to-many relationship, for now the Checkup Table will also need to refer to it. Also, the other Employee - Workday linking table remains invisible and is still depicted as a many-to-many relationship.

As you can see, the power of CaseTalk is not just that it is great at capturing the domain expert communication, maintain the communication so they may even verify a relational model, but to truly model elementary building blocks, creates a powerful transformation engine saving hours of work to remodel relation data models when business requirements changes.

This transformative power will also work for your UML diagrams, Python Code, or Database scripts generated by CaseTalk. It demonstrates the "model once, and develop anywhere" paradigm.