Consider a Logical Model where Entity A and Entity B are connected via Relationship Z.
If I create a Logical Diagram (note: not another logical MODEL), I am able to drag Entity A and Entity B onto the diagram. Since the Logical Model already "knows" that Entity A and Entity B have a relationship, I would like to be able to easily add it to my logical diagram.
I am already aware of the "Show Symbols" option whereby I can select the specific relationship that I want and have it appear. That is not a solution for me.
The problem is that I have a LARGE logical model consisting of HUNDREDS of Entities and their various relationships. I then need to create application-specific diagrams consisting of a subset of those entities. I can easily identify and drag the 50+ entities onto a new diagram. But identifying and selecting all the associations is an exercise in frustration.
Is there an option or some sort of feature that I'm missing - or any other trick - that would allow me to add only the relationships between selected entities or all entities on a diagram?
Have you tried Tools > Complete Links?
Related
Problem description
I am currently working on a project which requires a relational database for storage.
After thinking about the data and its relations for a while I ran into a quite repetitive problem:
I encountered a common data schema for entity A which contains some fields e.g. name, description, value. This entity is connected with entity B in multiple n-1 relations. So entity B has n entities A in relation rel1 and n entities A in relation rel2.
Now I am trying to break down this datamodel into a schema for a relational database (e.g. Postgres, MySQL).
After some research, I have not really found "the best" solution for this particular problem.
Some similar questions I have found so far:
Stackoverflow
DBA Stackexchange
My ideas
So I have thought about possible solutions which I am going to present here:
1. Duplicate table
The relationship from entity B to entity A has a certain meaning to it. So it is possible to create multiple tables (1 per relationship). This would solve all immediate problems but essentially duplicate the tables which means that changes now have to be reflected to multiple tables (e.g. a new column).
2. Introduce a type column
Instead of multiple relationships, I could just say "Entity B is connected with n entity A". Additionally, I would add a type column that then tells me to which relation entity A belongs. I am not exactly sure how this is represented with common ORMs like Spring-Hibernate and if this introduces additional problems that I am currently unaware of.
3. Abstract the common attributes of entity A
Another option is to create a ADetails entity, which bundles all attributes of entity A.
Then I would create two entities that represent each relationship and which are connected to the ADetails entity in a 1-to-1 relationship. This would solve the interpretation problem of the foreign key but might be too much overhead.
My Question
In the context of a medium-large-sized project, are any of these solutions viable?
Are there certain Cons that rule out one particular approach?
Are there other (better) options I haven't thought about?
I appreciate any help on this matter.
Edit 1 - PPR (Person-Party-Role)
Thanks for the suggestion from AntC. PPR Description
I think the described situation matches my problem.
Let's break it down:
Entity B is an event. There exists only one event for the given participants to make this easier. So the relationship from event to participant is 1-n.
Entity A can be described as Groups, People, Organization but given my situation they all have the same attributes. Hence, splitting them up into separate tables felt like the wrong idea.
To explain the situation with the class diagram:
An Event (Entity B) has a collection of n Groups (Entity A), n People (Entity A) and n Organizations (Entity A).
If I understand correctly the suggestion is the following:
In my case the relationship between Event and Participant is 1-n
The RefRoles table represents the ParticipantType column that descibes to which relationship the Participant belongs (is it a customer or part of the service for the event for example)
Because all my Groups, People and Organizations have the same attributes the only table required at this point is the Participant table
If there are individual attributes in the future I would introduce a new table (e.g. People) that references the Participant in a 1-1 relationship.
If there are multiple tables going to be added, the foreign key of the multiple 1-1 relationship is mutually exclusive (so there can only be one Group/Person/Organization for a participant)
Solution suggested by AntC and Christian Beikov
Splitting up the tables does make sense while keeping the common attributes in one table.
At the moment there are no individual attributes but the type column is not required anymore because the foreign keys can be used to see which relationship the entity belongs to.
I have created a small example for this:
There exist 3 types (previously type column) of people for an event: Staff, VIP, Visitor
The common attributes are mapped in a 1-1-relationship to the person table.
To make it simple: Each Person (Staff, VIP, Visitor) can only participate in one event. (Would be n-m-relationship in a more advanced example)
The database schema would be the following:
This approach is better than the type column in my opinion.
It also solves having to interprete the entity based on its type in the application later on. It is also possible to resolve a type column in an ORM (see this question) but this approach avoids the struggle if the ORM you are using does not support resolving it.
IMO since you already use dedicated terms for these objects, they probably will diverge and splitting up a table afterwards is quite some work, also on the code side, so I would suggest you map dedicated entities/tables from the beginning.
I am tring to write some ETL to extract Conceptual Models, and their assoicated Diagrams and Entities, out of a powerdesigner database.
So Far, I have the querys that return:
1/ The list of Conceptual Models (based on the class name 'Conceptual Data Model').
2/ The list of Conceptual Diagrams assoicated with each Conceptual Model (based on the data in 1/ and the relationship class 'Diagrams' to the targe object class 'Conceptual Diagram').
3/ The list of entities associated with each Conceptual Model (based on the data in 1/ and the relationship class 'Entities' to the targe object class 'Entity').
My problem is that I need to understand the set of Entities, 3/ above, assoicated with each Diagram, 2/ above. There are no records in the relationship table, PMRLSH, for these.
TL;DR Does anyone know where in the powerdesigner database the set of entities contained in a conceptual diagram are stored?
This information is not directly available.
All the diagram contents (including the references toward displayed design objects) is packed as the long text (in PMTEXT, in an undocumented format) indicated by PMOBJT.BCOL.
I have a problem where I am stuck :(. I have to build a relationship of a relationship( strange !).
For example, I have a relation where one entity A can have many B (OneToMany)
A ----> B
Now I need another relationship where an entity C will have an OneToOne relationship with the composite relationship between A and B. Like,
C--> (A--->B) , not C-->A-->B
Not that C will have a relation with A and A has with B,it should be like like C--> D (A --> B).
The generated joined tables does not have any primary key in JPA and now I am thinking How can I map this relationship. Please be noted that the normal A-->B is also needed as this can not be embeddable and it should be persistent.
Thanks.
Example:
Location and Event are my two entities and I want to relate CleanPlan on it. Means one CleanPlan is related to event-1 of location-1. so I am specifying that have a cleanplan on location-1 in event-1. Does that make sense?
I would say this
or this, depending on Event-Location cardinality.
There are two aspects of this problem in JPA.
1) A mapping table is craeted.
2) A mapping row is created instead of mapping table.
I think the 2nd option will make your life easier. But that is only possible if Event and Location has an unidirectional relation. Then on ManyToOne side, put "mappedBy". And that will generate a mapping table on ManyToOne table. And you can refer that column on CleanPlan table.
I have been having previous issues regards to class inheritance and structuring a database around this and using the entity framework to no success. So I have tried to create the entities inside visual studio and see what database tables it creates automatically.
I have a Entity MediaItem which is Abstract and Game Inherits from this. Game has a Console (Int) which corresponds to ConsoleID. However, when I generate the database I get an extra unwanted column (ConsoleTypes_ConsoleID) inside MediaItems_Game table. Why is this and how can I prevent this from happening? Thanks.
First of all your model is probably wrong. ConsoleType and Game is not in one-to-one relation (unless you have single game for each console type). I expect 1 console can have multiple games. So it should be one-to-many. In reality game can be released on multiple platforms so it should be many-to-many.
You got unvanted column because your relation between ConsoleType and Game doesn't know that it should use Console property as a foreign key. This happens if you use independent association. Independent associations are used by default when you draw them from one entity to other entity in Entity designer. You must use foreign key association.
Start with this set up (draw association from ConsoleType to Game - you must have one-to-many relation):
Select relation between ConsoleType and Game an in properties click on Referential Constraint:
In Referential Constraint dialog just set up relation:
Save your model and generate database again.
I created a class diagram for a system and now I have to model it into a real system. This means converting it to a database.
Now there is a base class which has just a few attributes, but there are many classes that inherit from it. Now my checklist for converting says I have to create a table for every class.
I don't know how to handle the inheritance, I can see that associations are done with PK and FK's but what about subclasses?
Is there some article which handles that or is there someone who can explain it to me?
Thanks in advance,
You have three alternatives to translate class hierarchies into relational tables:
- Create only a table for the superclass (all attributes and associations of subclasses are moved to the table corresponding to the superclass with the possibility of taking a NULL value)
- Create only tables for the subclasses: All attributes and associations of the superclass are repeated in each subclass
- Create tables both for the superclass and for each of the subclasses. In this case, the PK of the subclasses is at the same table a FK to the superclass (this ensures that all identifiers in a subclass table correspond to an existing identifier in the superclass table. A join between both tables allows to recover the full information of the element)
The best strategy depends on the problem (for instance, the number of attributes in each class, the number of levels in hierarchy, whether the hierarchy is disjoint or not,...)
If you want to see some examples, you can upload your hierarchy to the UMLtoDB online service http://modeling-languages.com/content/uml2db-full-code-generation-sql-scripts-databases
Drop all that UML nonsense - keep it simple. Its just amounts to duplication for no gain. Does Microsoft or Sun publish UML for dOT NET or Java... FOrgetting the odd sample, the majority of these frameworks dont have any official UML anywhere.
Usually, you design your datamodel (database tables/PK/FK etc.,) in parallel when you design your actual class diagram. After identifying all the cadidate classes and the dependencies on each of the classes, you will probably go on with the design sequence diagram. By this time, your data model should have been finalized.
I cannot understand your situation here, but IMO the process that you follow seems a bad idea to me.