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.
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 trying to create a relational schema using this image.
But i don't know where to start. Can someone suggest some references to help get me started?
Start by specifying the types of facts that you want to record, in the form of predicate sentences with placeholders for values. For example:
The country with code <COUNTRY_CODE> is named <COUNTRY_NAME>
The language with code <LANGUAGE_CODE> is an official language of <COUNTRY_CODE>
<COUNTRY_CODE> has a <SUBDIVISION_TYPE> called <SUBDIVISION_NAME>
<COUNTRY_CODE> has a city called <CITY_NAME> in <SUBDIVISION_NAME>
Next, identify the domains of each placeholder as well as subset relationships between domains (these are your IS-A relationships and will eventually be enforced via foreign key constraints). Identify functional and multivalued dependencies, and normalize where required. If you kept your fact types simple you won't need much of the latter.
For more information, look into fact-based (i.e. relational) modeling disciplines like Object-Role Modeling.
I have been asked to add a new address book table to our database (SQL Server 2012).
To simplify the related part of the database, there are three tables each linked to each other in a one to many fashion: Company (has many) Products (has many) Projects and the idea is that one or many addresses will be able to exist at any one of these levels. The thinking is that in the front-end system, a user will be able to view and select specific addresses for the project they specify and more generic addresses relating to its parent product and company.
The issue now if how best to model this in the database.
I have thought of two possible ideas so far so wonder if anyone has had a similar type of relationship to model themselves and how they implemented it?
Idea one:
The new address table will additionally contain three fields: companyID, productID and projectID. These fields will be related to the relevant tables and be nullable to represent company and product level addresses. e.g. companyID 2, productID 1, projectID NULL is a product level address.
My issue with this is that I am storing the relationship information in the table so if a project is ever changed to be related to a different product, the data in this table will be incorrect. I could potentially NULL all but the level I am interested in but this will make getting parent addresses a little harder to get
Idea two:
On the address table have a typeID and a genericID. genericID could contain the IDs from the Company, Product and Project tables with the typeID determining which table it came from. I am a little stuck how to set up the necessary constraints to do this though and wonder if this is going to get tricky to deal with in the future
Many thanks,
I will suggest using Idea one and preventing Idea two.
Second Idea is called Polymorphic Association anti pattern
Objective: Reference Multiple Parents
Resulting side effect: Using dual-purpose foreign key will violating first normal form (atomic issue), loosing referential integrity
Solution: Simplify the Relationship
The simplification of the relationship could be obtained in two ways:
Having multiple null-able forging keys (idea number 1): That will be
simple and applicable if the tables(product, project,...) that using
the relation are limited. (think about when they grow up to more)
Another more generic solution will be using inheritance. Defining a
new entity as the base table for (product, project,...) to satisfy
Addressable. May naming it organization-unit be more rational. Primary key of this organization_unit table will be the primary key of (product, project,...). Other collections like Address, Image, Contract ... tables will have a relation to this base table.
It sounds like you could use Junction tables http://en.wikipedia.org/wiki/Junction_table.
They will give you the flexibility you need to maintain your foreign key restraints, as well as share addresses between levels or entities if that is desired.
One for Company_Address, Product_Address, and Project_Address
Is there such a thing? I'm not implementing anything, I'm just creating an E-R Diagram from it. Here is a simple example:
ENT(Ent_ID, Group_IDs)
GROUP(Group_ID, Att)
The attribute Group_ID would have an one-to-many relationship with different instances of GROUP. (Is the word instance correct here?)
P.s: I know I could create a third entity with Ent_ID and Group_ID as attributes to make the relations if I was implementing it, but I don't know if this has to be specified in the diagram.
The way I understand your example, you have a one-to-many relation:
Each GROUP instance can have many ENT instances related, but every ENT instance is related to one and only one GROUP instance.
I have 3 entities in my system. Let's call them entity A,B and C. Entity A becomes Entity B, and in turn entity B becomes Entity C. I have to keep copies of all 3 entities.
My dilemma is how to represent them in a relational data. All 3 entities have similar fields. However, some fields are applicable to some entities and some are not.
What is the recommended approach in this case. Should I use one table and then make a 'Type' field ? The problem with this approach is that some fields will be empty for soem entities. Or should I create separate tables?
Any recommendation on best practice would be greatly appreaciated
this sounds like the manager -> personnel type of hierarchical design. You may have separate tables for each entities. But if they are of same base type when you want to get list of all people, then you have to union all tables. If you use a hierarchy column with a single table approach then you have to join the table with itself. Consider these two options while choosing one solution. Both are right but have their own difficulties.