I don't know the complete specs but here's a very (very!) generic solution to your problem.
Start with one entity called 'generic entity' and another entity called 'relationship_generic entity'.
Then draw two references from the 'relationship_generic entity' to 'generic entity'. This will allow you to draw references from any generic enitity to any other generic entity using the two references.
Then add subclasses of 'generic entity' called hardware, software etc.and if necessary add attributes to specify the hardware / software etc.
For the references between these subclasses there are two options;
The advantage of the latter option is that you can use different attributes on the different subclasses to store additional information on backups, runs on etc.
Very generic and a bit abstract perhaps, let me know if this helped you!
Perhaps I can help you. I drew a meta model:
I am having trouble with the front end view. Basically i have used the method michel told me, so i have a generic relation with a attribute enum for the type of relation. I then have two associations to the CI. The first is for the 1st CI and the 2nd for the 2nd. On the front end i have a list of the CI's and i select one and click view relations. This form has a data view of CI then a data grid for the general relations. I then try and add a relation to another CI by selecting the 2nd association however when i select a CI that is different to the 1st CI it does not appear in the data set. I hope this makes sense and if you have any tips on how to resolve could you please let me know
Yeah that is basically what i want to do. I am trying to work on it currently. So lets hope it works lol
due to the default context behaviour and the dual references all datagrids need to have their context set to 'private' and you should get the correct data using Xpath [proper_reference = CurrentObject]
You could try making an association from your change_item entity to the same entity. You can do this by right clicking your entity, Add -> Association and choosing the same entity again. You could restrict the option to, say connect a software object to another software object, with microflows in a before commit action or custom save button. A simple enumeration could help you separate software from hardware of a database.
Hope I'm in the right direction here. Let us know how it works out and we might be able to help you with working out the details.