![]() |
Thousands of Objects in a Graph |
Post Reply
|
Page <123 |
| Author | |||
janne
MetaCase
Joined: 25.Mar.2008 Points: 58 |
Post Options
Thanks(0)
Quote Reply
Posted: 02.Dec.2009 at 08:54 |
||
|
Hi,
Please try following: ![]() Or by using the form based metamodeling tools structure like: ![]() |
|||
![]() |
|||
stevek
MetaCase
Joined: 11.Mar.2008 Points: 643 |
Post Options
Thanks(0)
Quote Reply
Posted: 02.Dec.2009 at 12:03 |
||
|
I'm not sure Janne answered your question, so I'll have a go too. Pick whichever answer you like :-).
It's generally not a good idea to make Datatype or Item type = Object, because that would allow absolutely any kind of object. If you need to do it, hold shift down while opening the dialog from which you choose the object type, and Object will magically appear in the list. The best way is probably to make a common supertype of Entity and Attribute, and mark it as abstract (start its name with an underscore), e.g. _Content. The property type then has Datatype = Collection and Item type = _Content. Looking at the names you use and the examples, I wonder if you might actually want something else. If Entity_With_Attributes only ever has one Entity, then make that a separate property, of Datatype Entity, and you can have the second property, a Collection of Attirbutes, without needing to allow contents of different types.
Alternatively, if what you really want is to draw the Entity_With_Attributes as a big box that contains attributes, you may want it not to have properties, but to simply visually contain the Entity and Attribute objects that you put in the graph. You can then use the MERL commands, contents and containers, to access this information both for rules (making the symbol show an error if the enclosure is wrong) and generation.
What is the semantics of ER diagram (type B)? And why do you want two different graphs showing the same thing (in this example at least)? Think about whether the objects in the lower graph are identical to those in the upper graph, or are themselves new objects that refer to the objects in the upper graph. Think about whether you can use 'convention over configuration', e.g. if the default situation is that a Type A graph has a roughly isomorphic Type B graph, then you don't need to draw the Type B graph, since it adds no information: you can already generate what you want directly from the Type A graph.
|
|||
![]() |
|||
sap630
Contributor
Joined: 22.Sep.2009 Points: 10 |
Post Options
Thanks(0)
Quote Reply
Posted: 03.Dec.2009 at 00:44 |
||
|
Thanks Steve and Janne - "Collection" was the key.
^ This was what I was after. But I can see how the first thing you mentioned would also work:
Where you mention:
Correct, however, the problem isn't generation but modeling without cluttering the screen. As the thread title mentions, we would eventually have thousands of objects in a low-level graph (similar to subgraph of type A) with "chunks" or "views" of those objects as groupings in another subgraph (similar to subgraph of type B). We would like the modellers using the type B subgraph to have direct access to the underlying object from the type A subgraph (to avoid duplicating information). Cheers. Edited by sap630 - 03.Dec.2009 at 00:47 |
|||
![]() |
|||
Post Reply
|
Page <123 |
| Tweet |
| Forum Jump | Forum Permissions ![]() You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |