I am trying to create an UML diagram for a graph in MongoDB.
I have tried
but I am afraid it is wrong, since both source and target in Edge should point to Node, so I guess it should have two arrows?
Also, I don't know what to write on the question marks.
A graph can have multiple nodes and edges, so the relationship from Node to Graph and Edge to Graph is one-to-many (i.e. there can only be one Graph associated to one Node/Edge). Also there can only be one Node associated with one source and one Node associated with one target.
Is it even correct to draw these UML Diagrams for MongoDB collections since they are non-relational databases?
I would start modeling it this way:
So a graph consists of a number of nodes which are connected by edges. Edges are always between two (not necessarily different) nodes. In this way you can not individually model graphs that have different relations. If that is needed, you would need a different model here (probably you'd add an association between Graph and Edge). Alas, this shows how UML is used: starting a discussion and talk about the problem domain.
Now, how this is finally mapped to a database is completely irrelevant at this stage. You can map this to relational and non-relational DBs later.
Regarding the questions from your comment:
The position of associations in a class diagram is irrelevant. They just need to end in the right elements.
The +source and +target are role names. They are identical to properties of Edge with names source and target and type Node. The + is the scope public (- would be private; there are 2 more)
The 1..* means that the Graph has many relations to Node. It does not tell how this is realized. Could be an array later or other means of expressing multiplicity.
Yes. The position of role and multiplicity is important. This is a drawback since UML tools place them automatically and they can eventually be placed badly with many connectors/narrow element spaces.
Related
I want to understand the difference between connecting classes together with a shared line or by having classes only "connect" through other classes. Is there a significant difference here? If classes share a line are you specifically trying to convey that information is being accessed from each of the other classes on the shared line?
For "Three Objects in a Row" I mean a layout that would appear as follows (sorry my diagram is:
For "Sharing Lines" I mean a layout that would appear as follows:
difference about access
In the first case instances of Flat and instance(s) of Tenant know each other, and independently of that instances of Tenant and instances of LeaseAgreement know each other. Instances of Flat do not have direct access to instances of LeaseAgreement and instances of LeaseAgreement do not have direct access to instances of Flat, they can only access the other instances if Tenant offers these accesses whatever the way (method or public attribute).
In the second case there is an association-class, instances of Flat and Tenant know each other more the corresponding instance of LeasingContract indicating how they are associated.
difference about knowledge
In the first case supposing the hidden multiplicity are not 1 a tenant having two rents is associated with two instances of Flat and two instances of LeaseAgreement but there is nothing in the given model allowing to link the right instance of LeaseAgreement with the right instance of Flat, that means the model as it is do not say for which flat a lease agreement was written.
In the second case there is no ambiguity, each couple of instances Flat and Tenant is associated with (in fact throw) the right instance of LeasingContract
The notation in your lower picture is called Association Class (see this wiki). Bascically it's a shortcut for a 1-* AC *-1 relation where AC is connecting two classes so you can add attributes and operations. In your example the AC is Leasing contract and it would add information about duration, payment, etc. And the two * were taken from the * left and right on the AC's association's far ends. So this would be an equivalent of your lower diagram:
I work in cattle production and I am learning about database design with postgreSQL. Now I am working on an entity attribute relationship model for a database that allows to register the allocation of the pastures in which cattle graze. In the logic of this business an animal can be assigned to several grazing groups during its life. Each grazing group in turn has a duration and is composed of several pastures in which the animals graze according to a rotation calendar. In this way, at a specific time, animals graze in a pasture that is part of a grazing group.
I have a situation in which many grazing groups can be assigned to many animals as well as many pastures. Trying to model this problem I find a fan trap because there are two one-to-many relationships for a single table. According to this, I would like to ask you about how one can deal with this type of relationship in which one entity relates to two others in the form of many-to-many relationships.
I put a diagram on the problem.
model diagram
Thanks
Traditionally, using a link table (the ones you call assignment) between two tables has been the right way to do many-to-many relationships. Other choices include having an ARRAY of animal ids in grazing group, using JSONB fields etc. Those might prove to be problematic later, so I'd recommend going the old way.
If you want to keep track of history, you can add an active boolean field (to the link table probably) to indicate which assignment is current or have a start date and end date for each assignment. This also makes it possible to plan future assignments. To make things easier, make VIEWs showing only current assignment and further VIEWs to show JOINed tables.
Since there's no clear question in your post, I'd just say you are going the right way.
I've been reading a lot about Entity Frameworks and now I want to implement it on my game. An Entity Framework is based on making the game entities simple containers of Components, where a Component contains a certain characteristic of an Entity (and all the variables/accessors which describe this characteristic).
The game logic is then modularized by creating Systems. Each System implements and runs a certain aspect of the game logic (eg. Collisions, Rendering, Animation). Each System has to be able to access every Entity which has some certain combination of Components (eg. RenderSystem has to get only Entities which have PositionComponent and AnimationComponent).
My question regards the best data structure for achieving such functionality.
My current idea is to create a Vector (with N cells, where N is the number of possible components) of List of Entity. So whenever I create (instantiate and add certain Components) an Entity, I would also reference this Entity from each List for each Component it contains. "Killing" an Entity would require removing each reference from each List. The problem would be querying which entities have to be processed by a certain System, because the search-key would be a combination of Components, and not a single Component, adding overhead to the operation (many searches and comparisons would have to be done).
Is my idea good? Is there any better data structure I can use? Note that everything in the game is supposed to be an Entity, summing up to thousands of Entites on a single Level (I could possibly use some space partitioning).
They are two ways of doing it,
The purely data oriented system would lead you not to have an Entity class but just components sharing an ID. In this case, a vector or a hashmap for every system wouldn't be a problem as the search in these data structure is fast. If you want several components per system per entity you can aggregate your components in one data structure adapted for each system.
The problem is that a pure data oriented system can be less usable than a more pragmatic approach where you keep all the features of the previously described system but you keep an entity class that holds reference to his components (or aggregated components structures) of every system. Processing an entity (deleting or inspecting it) becomes much easier as you still have a place where all the information about what the entity is, i.e. what it is made of and not what state it is in, can be found in one place instead of querying every system.
In your case, the best thing is to try... It's quite easy and fast to implement a rough engine in the two ways, and once you've played with the two you'll be able to decide which one suites you better.
This article is valuable as far as it suggests 4 iterations for the data structure, but no one is a good solution in my opinion. But I recommend to read it, because there is a detailed analysis of the problem, nice estimations in terms of memory and such other good material.
I'm done DDD for a couple of years now and still its challenging when it comes to designing Aggregates. Thats the fun part of DDD and it makes your head spin. I'm asking this question since I'm architect in a project and we're in the middle of designing the model. Its an iteration when model evolves parallel with GUI and requirement gathering together with customer.
Now to the problem. Our scenario is that we are facing some Aggregates that are growing into very large AR's. I think I'm good at finding Value objects and avoiding the anemic domain model trap. But I've never been in this situation.
One example is that our system should represent a mobile telecom antenna. The antenna is located on a green field. But the antenna can have a shelter with equipment. Antenna can have microwave links, it can have fiber lines in ground, it can have radio elements, it can have power supply. Face it. If Antenna is terminated... all these dependencies are removed as well. Since they are part of the installation (except for the green field :))
But You get the picture. The antenna model is complex... And large AR's are inflexible regarding to concurrency locks, performance, memory consumption.
After reading Vaughn Vernons very good paper on Effective AR design http://dddcommunity.org/library/vernon_2011/ I realize that We need to start chopping our big AR's up in pieces.
My Idea is to do like Vernon suggest to move out for example MicrowaveLinks to a separate AR (even if its not in reality).
The MicrowaveLink Entity, now AR, is reference Antenna by Id. In MicrowaveLink Entity class we have a value object property that is AntennaId.
Our Uses cases support this scenario. We rarely list antenna and links together. So loading MicrowaveLinks is possible through a MicrowaveLinkRepository.ListByAntenna(Guid antennaId)
1) Have you done this AR split before and how did you do it?
2) Did you manage to support this AR --> AR relationship intact through both domain constraints and DB (we use EF 5 as ORM)?
My optimal goal is to be able to skip a Antenna.Microwaves Collection on Antenna. So Antenna are not aware if Links. The Links are aware of what Antenna they are mounted on.
And At MicrowaveLink Entity I only want a AntennaId Property, with hopefully, a DB Constraints that make sure that Antenna exists.
I'm aware of that I can manually add FK constraints in Seed method in EF or in DB directly through T-SQL scripting. But can this relationship be supported in some way by EF5 Code First Fluent mapping?
By the sounds of it you have an Installation AR. When requiring an AR in another you should model the contained AR as a only the ID in the container or a VO if required.
You need to have hard edges around your ARs.
Back to the Order / OrderLine example :)
An OrderLine seems to 'require' a Product but you shouldn't ever give a Product instance tot eh OrderLine. Instead only model, say, the ProductName and ProductId as a VO in the OrderLine. Now you have a distinct edge to your Order AR.
Hope that helps somewhat.
In a project I work on there is a C# library containing business objects which are related to the backing database tables/stored procedures.
We imported the code into EA model (where we already have database model) and now I'd like to show dependency between a class and a table (or stored procedure output).
Since these are loosely coupled (i.e. only a portion of properties are shared between them) I'd like to have a relation between a class A and table B and in the properties of this relation to have the mapping (A.a <-> B.a , ...).
Is this possible and how?
You can draw connectors between two elements and then link one or both ends to an element feature (an attribute or an operation). Draw the connector, then right-click near the end and select Link to Element Feature.
You can draw any number of connectors between two elements, and link any number of them to any features at either or both ends.
You should note that this is an EA feature which is not in the UML standard. As such, it is also a little trickier to automate (the feature link is not documented in the API), but I've done it before for a client so it can be done. However, from your question I assume it's the manual case you're interested in.