Hello,
I have a case where I have two sets of data. Both sets share a subset which is equal.
I want to access the documents from one OverviewEngine. My idea for this case is to model the common data in a document model and have a relation to both superset document models. When I click on the subset model in the overview engine I want to open the respective connected dataset + subset in a single form.
Is it a good way to model the behavior as a set of relationships and composed document models, or will this not work and we should look in a different direction?
Thanks!
Hi @christoph-wintry-light
Composed Data Models works more or less as you described it.
Yes, you can use Relationship Models to model a 1 to 1 relationship from CommonDocData to DocAData and also to DocBData as you showed in the picture on the left.
Yes, you can create a Composed Document Model to be able to retrive the CommonDocData and it’s linked DocAData and DocBData.
Yes, you can create an Overview Model that references this Composed Document Model and displays the CommonDocData. This Overview can display any non-repeatable data from CommonDocData, linked DocAData or linked DocBData
Yes, you can create a Form Model that references this Composed Document Model. Please note that this Form Model only controls how the data is displayed and not which data is loaded. If the Composed Document Model references all 3 Document Models and their Relationship Models, then all 3 Documents will be loaded.
This slight issue comes when you talk about clicking on CommonDocData and opening different FormModels, DocADataFormModel and DocBDataFormModel. As a modeler, I cannot link two different Form Models and offer a choice of which Form is opened.
However, your diagram is not 100% clear and I have a few follow up questions.
- Is CommonDocData always linked to both DocAData and DocBData?
- Is CommonDocData linked to either DocAData or DocBData but never both?
- Do DocAData and DocBData share any features or could be logically grouped?
I’m trying to understand if Heterogeneity could help you to get the UI interaction that you describe.
Hi,
thanks for your reply!
CommonDocData is always linked to either DocAData or DocBData never to both and always to just one.
When clicking on a row to open the form, there is no choice between DocADataForm or DocBDataForm. Either DocADataForm or DocBDataForm needs to be opened.
Maybe 3. would be a solution. But looking at it from the domain, it would make sense to keep both of them different.
I will have a look at heterogeneity.
A Heterogeneous Relationship sounds like the easiest way to enforce the link constraints that:
You can model a 1 to 1 relationship to the superType Model and the user can choose to link either DocAData or DocBData. DocAData and DocBData are still modeled as separate Document Models and are therefore still separate parts of the database.
This is also supported in Composed Documetn Models as described here.
