No cardinality at Relation between Information Concepts
Hi, it is quite common to model a Domain Object Model. It consists of Domain Objects an Relationships incl. Cardinality. With Essential Meta Model it is possible to model Information Concepts. But there is only a simple relationship without catdinalities. What is the best thing to model cardinality? Thx Wolfgang
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Hi Wolfgang.
In Essential Architecture Manager, we take a slightly different approach to the traditional data modelling tools for how we build the model of our Information and Data.
When we are defining Information Concepts, we are working at the Conceptual level of abstraction which is focussed on 'the what'. We don't describe anything more detailed than the types of things that exist and so we allow any of these dependencies to be always 0 or more. At this level we're saying that, e.g. Customer depends on an Address object, rather than how many Address objects. All quite abstract in the conceptual.
This definition of 'conceptual' is sometimes a bit different to what many data designers might consider conceptual models. Many of those sorts of models would actually be models of our Information Views ('upper' - logical).
However, we use this definition of conceptual consistently across our meta model and by considering all design to be logical, we find this works well.
It's at the logical level (which is focussed on 'the how') that we'd start to look at design and therefore constraints on cardinality. We capture that on the Data Attributes of a Data Object - in the Logical Perspective.
Similarly, we don't define specific relationship types - beyond 'dependency' / 'relationship to' in the conceptual perspective. This level of detail is captured at the Logical level via the attributes of the Information Views and Data Objects.
Although we've slightly improved the modelling of Information and Data attributes in the Essential Meta Model v3 (coming very soon), the Information and Data pack should provide what you need to capture your information models.
Capturing the model in this way means that we can dynamically generate things like ERDs or UML Class models (or any other notations) of the information or data elements from the content of the model.
Hope this helps
Jonathan
In Essential Architecture Manager, we take a slightly different approach to the traditional data modelling tools for how we build the model of our Information and Data.
When we are defining Information Concepts, we are working at the Conceptual level of abstraction which is focussed on 'the what'. We don't describe anything more detailed than the types of things that exist and so we allow any of these dependencies to be always 0 or more. At this level we're saying that, e.g. Customer depends on an Address object, rather than how many Address objects. All quite abstract in the conceptual.
This definition of 'conceptual' is sometimes a bit different to what many data designers might consider conceptual models. Many of those sorts of models would actually be models of our Information Views ('upper' - logical).
However, we use this definition of conceptual consistently across our meta model and by considering all design to be logical, we find this works well.
It's at the logical level (which is focussed on 'the how') that we'd start to look at design and therefore constraints on cardinality. We capture that on the Data Attributes of a Data Object - in the Logical Perspective.
Similarly, we don't define specific relationship types - beyond 'dependency' / 'relationship to' in the conceptual perspective. This level of detail is captured at the Logical level via the attributes of the Information Views and Data Objects.
Although we've slightly improved the modelling of Information and Data attributes in the Essential Meta Model v3 (coming very soon), the Information and Data pack should provide what you need to capture your information models.
Capturing the model in this way means that we can dynamically generate things like ERDs or UML Class models (or any other notations) of the information or data elements from the content of the model.
Hope this helps
Jonathan
Essential Project Team
