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.
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 have a question, with regards to how do you create the relationships between members of two different entities?
For example, in case of 1:1 you can create a domain-based attribute that is referencing the entity.
But in case you have a customer with multiple addresses, and you have an address entity.
When you update the member of the Address attribute of the Customer entity, based on the 1:M how would we be able to surface that relationship and connect the Address entity to the Customer entity?
So in case an Address member in the Customer entity changes, how would that update process work since we don't have a mapped relationship?
I know in M:M you would use a bridge table. And in the MDS database which table would contain that relationship info?
Any suggestions to articles and blog posts/Videos or ideas, would be greatly appreciated.
Thanks,
Andrea
In MDS (Master Data Services), you can use the Hierarchy feature.
- Option 1: create Explicit Hierarchy
If you're using SQL Server 2012 (possibly 2014 too), then an Explicit Hierarchy will solve this.
(see: Explicit Hierarchies (Master Data Services) )
Basically, you will be able to use Customer entity rows as parent nodes in the hierarchy (think of a tree structure) and assign one or more Address entity rows as child of each Customer.
As the name suggests, this needs to be "explicitly" managed.. means either someone will do this manually (drag-drop) using the MDS Hierarchy UI page or you can use an SSIS package to automate it while loading the staging table.
(see: Move Explicit Hierarchy Members by Using the Staging Process (Master Data Services) )
NOTE: Explicit Hierarchies have been Deprecated (starting SQL 2016 ...I think)
- Option 2: create Derived Hierarchy (bridge table- M:M)
This is similar to the bridge table concept that has been suggested earlier for M:M relationship, but in the MDS context.
Create another entity, call it CustomerAddressRelationship (let's say), let's call it CAR for now.
Add 2 Domain Attributes to CAR: one referring to the Customer entity, the other to the Address entity.
Now, if you want, you can create a Derived Hierarchy on this CAR entity in the format CAR > Customer > Address.
Read more about Derived Hierarchies: Many-to-Many (M2M) Relationships
- Option 3: create Derived Hierarchy (1:M)
Don't create CAR. Just add a column CustomerID (let's say) to the Address entity. This way every Address may have 0 or 1 Customer related to it.
Create a Derived Hierarchy for 1:M Relationship
Hope this helps.
From my understanding, cakephp doesn't support database inheritance relationship. However, I want to create a database with different type of Users.
In this case, there are three types of Users: Seller, Customer, and Administrator. Every users should have basic User information such as password, username, etc.
However, each types of users will have its own unique set of datas. For example, seller may have inventory_id while customer may have something like delivery_address, etc.
I have been thinking of creating a workaround to this problem without destroying cakephp convention. I was going to create three additional foreign keys, admin_id, seller_id and customer_id, inside User table, which links to other table. However, knowing that this is an IS-A relationship not HAS-A, I would have to make sure that two of the ids are NULL value. Therefore, this workaround seems ugly to me..
Is there any other simpler, better approach?
For this type of database structure I would probably look at adopting an Entity-Attribute-Value model. This would mean your customer may have a delivery_address and your user may have an inventory_id but as far as your relationship in Cake is concerned your both your user and customer would just have an attribute_id ... you can then create another table that stores what type of attributes are available.
It it's simplest form, your user and customer would be attached to an *attribute_lookup* or *attribute_link* table by a hasMany (probably) relationship. That attribute_lookup/link table would be connected by a belongsTo/hasOne relationship to the actual Attribute Type and Attribute Value models.
Providing that you normalise your tables correctly, you can stick well within Cake relationship conventions.
You can read more about EAV here.
I have been thinking about this problem for some time now, and I have eventually got around to build a solution for it. What I came up with is a new ORM that can be used on top of CakePHP.
It sort of works as CakePHP 3.0 with entities that represent an id/model, but it is much more advanced and supports multi table inheritance and single table inheritance.
Check it out: https://github.com/erobwen/Cream
I just started with the Entity Framework and started to design the model first. So in my model there is a Person who can have a PrivateTelephone, so I created an 0..1 to 1 association. As the picture below shows.
So far so good. But when I generate the database the [PrivateTelephone] is set to NOT NULL. Why can't this be just NULL?
It is becauser your relations are defined in reverse order. You should have 1 on Person and 0..1 on Telecom to specify that Person is the principal which can have one or zero phones. In your mapping you say that Telecom is principal which can have one or zero persons but person must have Telecom. It will also lead to reverse problem due to your incorrect mapping. You have six one-to-one relations to Telecom but if you reverse them as you demand you will say that all six relations (all six FKs in Telecom) will be NOT NULL = each record will have to participate in all six relations.
One-to-one relation is very special and should be used rarely. You should instead have one-to-many relation from Person to Telecom with a new column in Telecom specifying the type.
When using one-to-one relation you must have FK in dependent table configured with unique index. EF doesn't support unique indices so when you model one-to-one relation in model first it is still one-to-many in database and if database is used by another application it can break your application.
Also avoid unnecessary inheritance. Do you need Person as separate entity? = is there any instance which is only person and not employee? Are there more derived types from person? If not you don't need person and if yes it still doesn't mean that base person is a good idea. The same is true with employee. Inheritance has its own rules in EF and when using model first it will by default creates TPT inheritance = the worst one because it results in very complex and slow database queries.
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.