one to many
many to one
many to many
one to one
Need some more clarifications about them. Referred that in many sites but cant able to get the perfect definitions. thanks in advance
I explain you these conceptual data modeling relations on the example.
One to many (1:n) means one entity can work with more ones.
Example: One employer can hire more employees.
Many to one (n:1) works same as the one above from the different view.
One to one (1:1) means one entity can work only with the other one.
Example: Every employee can work only with one computer
Many to many (n:m) means there is a combination of relations between entities.
Example: Each customer belongs to more employees and one employee serves for one or more customers.
Usually in database systems there will be created a new table holding these relations in case of m:n.
Related
I'm confused with designing a client software with database integration to what should be a member variable of the class or just a query to the database. Let me be specific with a trivial example:
If I have, lets say, a Student class, which has a list of "friends" that are Student objects. Should my software design have an ArrayList<Student> as a member variable of the Student class or should the Database deal with the relationship itself and the Student class doesn't account for those "friends"? How should a proper UML class-diagram be in this case?
This question is broader than you may think, as there are many ways to deal with it. Here some first ideas:
Let's start with a quick class diagram. The friendship between students is a many-to-many association.
In a database, a many-to-many association is usually implemented using an association table. So you'd have two tables: STUDENTS and FRIENDSHIPS with pairs of ids of befriended students:
To load a Student object from the database, you'd read the data in a STUDENTS row and use it to initialize your object. For the friendship, you'd have to read the relevant FRIENDSHIPS rows.
But how to use these tables in the application?
A first possibility would be to load each Student friend and insert it in the ArrayList<Student>. But each loaded student is like the first student and could have oneself friends that you'd have to load as well! You'd end up loading a lots of students, if not all, just for getting the single one you're interested in.
A second possibility would be use an ArrayList<StudentId> instead of an ArrayList<Student> and populate it. You'd then load the friends just in time, only when needed. But this would require some more important changes in your application.
A third possibility is not to expose an ArrayList. Not leaking the internals is always a good idea. Instead use a getter. So you'd load the friends only if student.getFriends() is called. This is a convenient approach, as you'd have a collection of friends at your disposal, but avoid being caught in a recursive loading of friends of friends.
In all the cases, you may be interested in using a repository object to get individual or collections of students, and encapsulate the database handling.
Advice: as said, there are many more options, the repository is one approach but there are also active records, table gateways and other approaches. To get a full overview, you may be interested in Martin Fowler's book Patterns of Enterprise Application Architecture.
You need a one-to-many relationship between Student and friends in both the relational database and the object model.
I've seen a lot of domains designed with circular reference. The image below describes a simple example for understand the question: A company has employees and departments and a department has employees, who belong to a department.
Logically, the model allows a employee who works for a company be related with a department of another company - of course, hypothetically, if business logic validation fails.
In some more complex cases, and according to the business rules, I don´t see another way to model.
Is it acceptable?
Thanks in advance.
It is absolutely fine to have such kind of circular association.
Of course there are lots of pitfall that shoot your feet. However with extra cautious such kind of relationship is fact not always harmful.
Things that you need to pay extra attention includes:
Try to define the "owner" of the relationship. This is especially important if you are going to persist the entity
Make sure the owning relationships are not circular. For example, in your example, you can define Company owning the Company-Department and Company-Employee relationship, and Department owning the Department-Employee relationship
Make sure the relationship is consistent. For example, for the bi-directional relationship between Employee and Department, when you remove an Employee from a Department, make sure you remove the Department from Employee consistently.
Try to minimize the way to manage relationship. For example, instead of providing both Department#addEmployee(Employee) and Employee#addDepartment(Department), just provide Department#addEmployee(Employee). This should make your work of keeping consistency easier.
Still, if you can manage to make it uni-directional and non-circular, it is always easier to handle.
If you really want to avoid the situation you've described (where an employee "E" is associated with a department "D", but "D" and "E" are associated with different companies), you can try making your object model a tree, with no cycles:
Company --> Department --> Employee
There are trade-offs here. For example, this model doesn't directy handle Employees with no Department (although this could be papered over with a fake department like NoDepartment). This model may also require two "hops" to get from Employee to Company.
Lets say I Have two entities with a one to one relationship, a person entity and a person detail entity. Are there any advantages to using cascade when I want to save as oppose to making a separate save for each entity?
Would it be different if it was not a one to one relationship?
To get started, one difference would be, if NOT cascade, there will be multiple network calls (N+1 effect). Based on size data, there are lot of other implications you need to worry about too.
I have little bit confusing many to many relationship between 3 entities. And i want to know how can be my object model look like. I have three Entities, A,B,C and A<->B (M:N) and associate table between both, A and B, is linked with another associate table which make another 1:n relationship with third entity. I have never seen such relationship which make 1:n relationship with another associate table. For further information please have look on following diagram.
Uploaded Image link
If i talk about object model then i will say "INSTANCE_A" has many "INSTANCE_B" instance and vice versa but i do not know how can i summarize relationship for "INSTANCE_C".
Please also let me know whether definition of such relationship between all three entities is right ? i mean is there any problem in relationship design.
Thanks in advance
EDIT: All arrows denote (1:n or m:1) relationship
The data model is correct, but the object model for these tables can be kind of trucky. I'd do something like this:
One class for TBL_A, with a List attribute of TBL_B
One class for TBL_B, with a List attribute of TBL_A
One class for TBL_C_TBL_A_B, with and an attribute for TBL_B, TBL_A and TBL_C
Mapping that in an ORM framework can get funky.
This shall bring you into the right direction. Try to design a UML diagram, or ER should be ok too. Here is some paper with a Model and the corresponding Java-Code for this model http://www.csd.uoc.gr/~hy252/references/UML_for_Java_Programmers-Book.pdf. (Go to -> Class diagrams chapter).
I have a ManyToMany relationship between two classes, for instance class Customer and class Item. A customer can buy several items and an item can be bought by different customers. I need to store extra information in this relationship, for example the day when the item was bought. I wonder how is this usually modelled in JPA, cause I'm not sure how to express this in code. Do I have to create a new class to model all the attributes of the relationship and make a manyToMany relationship between the other classes or is a better way to do this?
Thanks
The recommended way is to create a new association class to store the needed attributes, and two one-to-many associations to the two parties involved.
I guess you will indeed have to create a new class for the relationship.
Like you said yourself, the correct way is to create a new class with the additional attributes.