I am looking for some clarification on when to use the aforementioned relationships.
As an example i have a class A which is referenced by instances of class B.
Should this relationship be modelled OneToMany and have a collection of class B defined in class A or be modelled by ManyToOne and have a reference to class A in class B?
My question is whether the choice of relationship is entirely up to the programmer, or application dependent or JPA dependent?
OneToMany and ManyToOne are two sides of the same coin. If the association is unidirectional (that is, it's not bidirectional) then the choice of relationship is the same as choosing which side owns the relationship. Examples:
You want a unidirectional relationship from 1 A to many Bs, where A is the owner. The only choice is OneToMany.
You want a unidirectional relationship from 1 A to many Bs, where B is the owner. The only choice is ManyToOne.
If the association is bidirectional then, by assumption, you're using both OneToMany and ManyToOne. Choosing the owner side does not force you to make an either-or decision.
More reading # The Java EE 6 Tutorial: Entities.
Related
I am new to the RDBMS.
I am Learning ER model in RDBMS.
In ER model, the entity is an real world object and it has an attributes.
The relationship is an mapping between entity set.
The relationship also have a the attributes.
Please explain the difference between entity and relationship.
You seem to have the definition differences available. But I assume you still do not understand the differences. Here is a very simplified example of two entities and the relationship that may exist between them:
A Bank and a Person are each an entity. The relationship that exists between a Bank and a Person is that a Person is a Customer to a Bank. Therefore Customer is the relationship. An attribute for a Person for example would be Date_of_Birth. An attribute for a Bank would be Bank_Name . An attribute for a Customer would be Customer_Bank_Acc_Number.
Update:
For those that like to pick at details here is a better relationship example:
A Person can have a relationship with a Bank of either being a Debtor or Creditor.
Update
There is also what is called an Associative Entity. Click the link for details on how that is different to an Associative Relationship.
I hope this makes sense. Cheers
I'm a bit confused about this naming convention.
What is the difference between them and are target/source interchangeable with owning/not owning?
One thing in particular is hard to understand:
"The main difference between a OneToOne and a ManyToOne relationship in JPA is that a ManyToOne always contains a foreign key from the source object's table to the target object's table, where as a OneToOne relationship the foreign key may either be in the source object's table or the target object's table"
JPA wikibooks
I can't imagine such situation in uni one-to-one
Differences between them are a little confusing. You should practice a lot to understand very well.
At first, you should understand some terminology:
Role : In every relationship there are two entities that are related to one another, and each entity is said to play a role in the relationship.
Direction : Relationships can be unidirectional or bidirectional. For e.g.. a Person has an address is normally unidirectional whereas Employee working on a project is normally bidirectional. We will look at how to identify and define directionality while coming up with a Data Model.
In order to have relationships at all, there has to be a way to create, remove, and maintain them. The basic way this is done is by an entity having a relationship attribute that refers to its related entity in a way that identifies it as playing the other role of the relationship. It is often the case that the other entity, in turn, has an attribute that points back to the original entity. When each entity points to the other, the relationship is bidirectional. If only one entity has a pointer to the other, the relationship is said to be unidirectional. A relationship from an Employee to the Project that they work on would be bidirectional. The Employee should know its Project, and the Project should point to the Employee working on it. A UML model of this relationship is shown here. The arrows going in both directions indicate the bidirectionality of the relationship (Form this book >> Pro JPA 2)
Then dive into this link (archived from the original)
I'd like to comment only the links, but I need 50 reputation
If I have two entities; Foo and Bar. And Foo has two properties; bar1 and bar2 of type Bar. Now does Foo have a one-to-many releationship to Bar? At least should it be modeled as that in Core Data? Or is it two one-to-one releationship? How do I set that up properly in Core Data with inverse? The one-to-many releationship I understand but not the last releationship type? Is that even possible or good way to that?
And Foo has two properties; bar1 and bar2 of type Bar. Now does Foo
have a one-to-many releationship to Bar?
No, Foo has two relationships with Bar, and those relationships are named bar1 and bar2. Whether they're "to-one" or "to-many" depends on how you specified them. Select each in the model and see whether the "to-many" checkbox is checked.
At least should it be modeled as that in Core Data?
That depends on what you're trying to model. Do you want to have two separate relationships to specific object (that'd be two different "to-one" relationships), or do you want a single relationship to a group of objects (one "to-many" relationships)? Here's an example that might help clarify things...
A business may have zero or more employees. A business also has a single chief executive officer and a single chairman of the board. So the Business entity might have a "to-many" relationship named employees with the Person entity. It might also have "to-one" relationships named ceo and chairman, again with Person. Those might not be strictly necessary -- maybe the CEO and Chairman are both employees, so you could find them by searching the set of employees and filtering by job title. But it can be handy to have them as separate relationships if you're going to use them often and don't want to have to search through thousands of other employees every time you do.
How do I set that up properly in Core Data with inverse?
Again, it'll depend on what you're modeling. For example, the inverse of the employees relationship would be Person's employer "to-one" relationship.
Entities have several different kind of properties, they have attributes and relationships (and fetched properties, but that's beside the point). It sounds like Foo and Bar are two classes you created with Foo having Bar properties. Then you want assimilate those as Entities in a Core Data model.
Typically, things are done the other way around. You create Entities in the Core Data model editor. You then link the entities by creating relationships. If you add a relationship from Foo to Bar, then it is good practice to create an inverse relationship from Bar to Foo.
Create the relationship from Foo to Bar
Create the relationship from Bar to Foo
Select that last relationship and set its inverse to the first one
Now if you want Xcode to generate the matching NSManagedObject subclasses Foo and Bar, then you can select the Entities and in the Xcode Editor menu, select "Create NSManagedObject subclasses"
You'll then see you're two classes with the proper attributes to match how your model is set up.
I've authored a book on Core Data that explains all this is much deeper details.
This is two one-to-one releationship.
To make inverse just select you entity in inverse field (When you create relation).
I have an Eentity Framework model with a Table Per Hierarchy (Brand) and also a Table Per Type (Vehicle) inheritance like this:
(Vehicle and Brand are abstract classes).
So far so good, I can access derived entities on linq queries using Vehicle.OfType<> or Brand.OfType<> method.
Now, Brand entity is one to many related with Vehicle on my conceptual model, So the question is, how should I make relationships on EF model so I can keep using navigation properties between Vehicle and Brand but at the same time keep the consistency of the TPH inheritance on Brand?, my first approach was to relate only derived clases, like:
But if I do this, I have no access to Brand directly from Vehicle, so I would have to do a double relation (between derived and base), like:
This works for me now, but I still have a duplicated relationship somehow, is this right?, do you have a better approach?, am I'm making some silly mistake on my modelling?
It seems to me that the reason you are running into cross-linking in your model is because you are artificially separating Brand and Vehicle as top-level sibling entities. If you start with Brand, which seems essentially equivalent to Make, that becomes the true top-level entity. There is no need to separate Make for each vehicle type (car, motorcycle, truck, etc.); just introduce the entity Model between Make and Vehicle and I think that solves most of your cross-linking problems.
Then the relationships aren't strictly parent-child, but are more accurate as composition. So you have Make, which has a one-to-many composite relationship to Model, which in turn has a one-to-many composite relationship to Vehicle. Vehicles are instances of a Model, so there isn't really a parent-child relationship there either. With this structure, there is no need to branch the EF for each type of Vehicle, because that is just part of what is described by the Model entity.
I hope my answer is helpful and that I haven't missed any of the essential points of what you are trying to model-
Consider that i have two entities with following relationship:
Entity A <-->> Entity B (one-to-many and inverse)
Now consider that i have another entity Entity C that contains all the attributes of Entity B and some others, with following relationship:
Entity A <-->> Entity C (one-to-many and inverse)
Now i can improve the architecture by making Entity B the parent of Entity C.
Entity B
^
|
Entity C
Now, my question is, will the attribute(s) AS WELL AS the relationship(s) be inherited by Entity C? Meaning, do i still need to keep the following relationship (separately)?:
Entity A <-->> Entity C
Also, i couldn't find a good example for entity inheritance in Apple documentation for Core Data. Does anyone know of an online resource that explains this, with example (preferably)?
Yes, attributes and relationships and everything else will be inherited. Be careful though, child entities like that will share the same table in sqlite with the parent entity. So if you have C inheriting from B, then a table will be created in sqlite that has the properties for both B and C which the obvious voids in the table. This is not too much of an issue with a simple inheritance like this but if you decide to get "creative" you can end up with your entire model in one table.
Now, my question is, will the
attribute(s) AS WELL AS the
relationship(s) be inherited by Entity
C? Meaning, do i still need to keep
the following relationship
(separately)?:
Yes all attributes and relationships are inherited.
Only little documentation is available at ADC