When we establish a one-to-one or many-to-one relationship, we can call it mapping. For example, we map a spouse to his/her spouse or each child to its parent. But what would be the verb singifying an establishment of a many-to-many relationship, underlining that it is not a 1+ to 1 relationship?
you can distribute, permute, or combine multiple groups to define many to many relationships. Mapping a group to other groups does not explicitly state if the members are crossed or not, like in a Cartesian product.
Permute is a more specific case because the order matters, but both permutations and combinations are the result of distributing a set among other sets (or groups among other groups).
To cross reference or to associate. I do not know if there is a definitive term but these seem plausible.
Related
I was studying about relationships in RDBMS.I have understood the basic concept behind mapping relation ship,but I am not able to spot them.
The three possibilities :
one to many(Most common) requires a PK - FK relationsip.Two tables involved
many to many(less common) requires a junction table.Three tables Involved
one to one(very rare). One table involved.
When I begin a project,I am not able to separate the first two conditions and I am not clear in my head.
Examples when I study help for a brief moment,but not when I need to put these principles in to practice.
This is the place where most begineers falter.
How can I spot these relationships.Is there a simpler way?
Don't look at relationships from a technical perspective. Use analogies and real-life examples when trying to envision relationships in your head.
For example, let's say we have a library database.
A library must have books.
M:M
Each Book may have been written by multiple Authors and each Author may have written multiple Books. Thus it is a many-to-many relationship which will reflect into 3 tables in the database.
1:M
Each Book must also have a Publisher, but a Book may only have one Publisher and a Publisher can publish many Books. Thus it is a one-to-many relationship and it reflects with the PublisherId being referenced in the Books table.
A simple analogy like this one explains relationships to their core. When you try to look at them through a technical lens you're only making it harder on yourself. What's actually difficult is applying real world data scenarios when constructing your database.
I think the reason you are not getting the answers that you need is because of the way you are framing the question. Instead of asking “How do I spot the correct type of relationship between entities”, think about “How do my functional needs dictate what relationship to implement”. Database design doesn’t drive the function; it’s the functional needs that drive the relationships you need to implement.
When designing a database structure, you need to identify all the entities. Entities are all the facts that you want to store: lists of things like book titles, invoices, countries, dog species, etc. Then to identify your relationships, you have to consider the types of questions you will want to ask your database. It takes a bit of forward thinking sometimes… just because nobody is asking the question now doesn’t mean that it might not ever be asked. So you can’t ask the universe “what is the relationship between these lists of facts?” because there is no definitive answer. You define the universe… I only want to know answers to these types of questions; therefore I need to use this type of relationship.
Let’s examine an example relation between two common entities: a table of customers and a table of store locations. There is no “correct” way to relate these entities without first defining what you need to know about them. Let’s say you work for a retailer and you want to give a customer a default store designation so they can see products on the website that their local store has in stock. This only requires a one-to-many relationship between a store and the customer. Designing the relationship this way ensures that one store can have many customers as their default and each customer can only have one default store. To implement this relationship is as easy as adding a DefaultStore field to your Customer table as a foreign key that links to the primary key of the Store table.
The same two entities above might have alternate requirements for the relationship definition in a different context. Let’s say that I need to be able to give the customer the opportunity to select a list of favorite stores so that they can query about in stock information about all of them at once. This requires a many-to-many relationship because you want one customer to be able to relate to many stores and each store can also relate to many customers. To implement a many-to-many relationship requires a little more overhead because you will have to create a separate table to define the relationship links, but you get this additional functionality. You might call your relationship table something like CustomerStoreFavorites and would have as its primary key as the combined primary keys from each of the entities: (CustomerID, StoreID). You could also add attributes to the relationship, like possibly a LastOrderDate field to specify the last date that the customer ordered something from a particular store.
You could technically define both types of relationships for the same two entities. As an example: maybe you need to give the customer the option to select a default store, but you also need to be able to record the last date that a customer ordered something from a particular store. You could implement the DefaultStore field on the Customer table with the foreign key to the Store table and also create a relationship table to track all the stores that a customer has ordered from.
If you had some weird situation where every customer had their own store, then you wouldn’t even need to create two tables for your entities because you can fit all the attributes for both the customer and the store into one table.
In short, the way you determine which type of relationship to implement is to ask yourself what questions you will need to ask the database. The way you design it will restrict the relational data you can collect as well as the queries you can ask. If I design a one-to-many relationship from the store to the customer, I won’t be able to ask questions about all the stores that each customer has ordered from unless I can get to that information though other relationships. For example, I could create an entity called "purchases" which has a one-to-many relationship to the customer and store. If each purchase is defined to relate to one customer and one store, now I can query “what stores has this customer ordered from?” In fact with this structure I am able to capture and report on a much richer source of information about all of the customer's purchases at any store. So you also need to consider the context of all the other relationships in your database to decide which relationship to implement between two particular entities.
There is no magic formula, so it just takes practice, experience, and a little creativity. ER Diagrams are a great way to get your design out of your head and onto paper so that you can analyze your design and ensure that you can get the right types of questions answered. There are also a lot of books and resources to learn about database architecture. One good book I learned a lot from was “Database System Concepts” by Abraham Silberschatz and Henry Korth.
Say you have two tables A and B. Consider an entry from A and think of how many entries from B it could possibly be related with at most: only one, or more? Then consider an entry from B and think of how many entries in A it could be related with.
Some examples:
Table A: Mothers, Table B: Children. Each child has only one mother but a mother may have one or more children. Mothers and Children have a one-to-many relationship.
Table A: Doctors, Table B: Patients. Each patient may be visiting one or more doctors and each doctor treats one or more patients. So they have a many-to-many relationship.
An example of one to one:
LicencePlate to Vehicle. One licence plate belongs to one vehicle and one vehicle has one licence plate.
I have the following relationships (Business rules):
User_Company : Many-to-many (multiple companies per user, multiple users per company)
Ownership : One-to-One (For each entry in relationship table, it specifies whether user is an owner or employee. If owner then a percentage must be there)
Company_ownership : One-to-many for company (Recursive relationship), as another company can also be an owner in a company, percentage must be given.
So ownership or a company can be made up of a number of companies and users.
So I have developed the following:
So does there have to be at least 4 tables for this sort of relationship or can it be simplified.
I feel it is quite complicated and would not be intuitive for another developer? How could it be optimized and elegantly arranged?
I think ownership and employment are different concepts, that would be more advised to have them separated.
Think about John who is one of the owners of A company and in the mean time he is the CTO of A.
Company and People can have a base to reduce redundancy of entities.
Based on the suggestions of Thilo
A separate relationship table was created for owners and employees respectively.
Furthermore, the company_ownership and ownership tables were removed as having a company as an owner is solved by adding an owning_user_id and owning_company_id where one will always be null. The percentage figure is added to this relationship table.
See below:
If I have two different types of user, Parent and Child. They have identical fields, however a Child has a one to many relationship with exams, a relationship that does not exist for Parents.
Would Parent and Child best be modelled as a single table, or combined?
What if I have two different types of user, Parent and Child. They are the same apart from a child belongs to a school (a school has many children)
again, Would Parent and Child best be modelled as a single table, or combined?
They have identical fields, however a Child has a one to many relationship with exams
Even when fields are the same, different constraints1 means you are dealing with logically separate entities. Absent other factors, separate entities should be put into separate physical tables.
There may, however, be reasons to the contrary. For example, if there is a key that needs to be unique across parents and children combined, or there is another table that needs to reference all of them etc...
If that's the case, then logically both "parent" and "child" are inheriting from the "person", containing the common constraints (and fields). Such "inheritance" can be represented by either storing the whole hierarchy into a single table (and setting unused "portion" to NULL), or by separating all three "classes" into their own tables, and referencing the "base class" from "inherited classes", for example2:
PERSON_ID is unique across all parents and children. In addition to that, OTHER_TABLE can reference it directly, instead of having to separately reference PARENT_ID or CHILD_ID.
1 A foreign key in this case.
2 A very simplified model that just illustrates the point above and does not try to model everything you mentioned in your question
Parent and Child both are Persons without a doubt. You should never put them in seperate tables.
Only time separates them : what if a Child becomes a parent?
A parent easily can have children for that you need a relationship table.
Als a relationship table is the right way to model school membership.
so tables here :
person
is_child_of (many to many, join table) --> relations between persons can be is_parent_of
plain and simple
Remember : being a child is a relation from person to person.
How would you model a grandchild if needed? Yet another table? And a great grandchild?
And supose you are fine with that and you make a lot of tables for a lot of "kind of" relationships, an all of a sudden you want you have to add a field (day of birth) or alter a field format : you have to do it in all your different tables.
You have described three different entities in your question -- Parents, Child(ren), and Exams. You have shows how the three differ in the their relationships to each other.
From everything in your question, I would say that you have three entities and you should set them up as such in your database. That is, Parent and Child should have separate tables.
If the items are modeled differently in your system, I would say that they should be different tables. Just because parents and children both have similar properties (names, ages, etc.), does not mean they will always have the same relationships with other entities in your database. You could have parent and child be in same table with column relating child to parent, but this just leads to awkward self-join queries when trying to represent this relationship. This in itself can become very odd if a child has two parents. So to me you would have a number of different tables:
parent
child
child_to_parent (many-to-many join table)
school
child_to_school (one school to many children)
classes
child_to_classes (many-to-many)
classes_exams (one-to-many table relating exams to classes)
child_to_classes_exams (many-to-many table relating children to exams for specific classes)
* and maybe things like the following
teacher
teacher_to_classes (many-to-many)
Now certainly in your class design (if you are using OOP), you could have child and parent extend from a common "person" class which would handle logic for setting common properties.
I would break children out into a separate table for the simple reason that a parent may have many children (if not now, maybe in the future).
More than the current need, it is also important to consider what may happen in the future even if it doesn't make sense now. You may have two parent users who want to administrate one child and that child's exams.
Consider the most possible future functional requirements and program with them in mind.
I have different kind of actors:
Parents;
Subsidiaries;
Insurers;
Brokers;
for each of the actors, there will be users with a personal account and user role.
I need to register the address and other (entity specific, including foreign keys) info into a table, which could be done by defining one "actor_tbl" and specifying the type of actor with an id.
However, the four types of actor have interrelations, which means that one parent can have multiple subsidiaries, one insurer can have multiple subsidiaries, one broker can have multiple parents, etc...
From this point of view, it would make more sense for me to create a separate table for each of the actor types, and create many-to-many relationships to make the right combinations. It think that it may also increase general readability and reduce the possibility for errors (all entities would be clearly separated from one another).
However, doing so takes away the principle of storing all entities with similar characteristics into a single table.
How would you take on this problem? What is the most recommended way to implement this structure?
You can see a superclass/subclass relationship between Actor and the four kinds of actors. The first point here is to clarify the constraints on this relationship. From your description, I'm assuming the participation is mandatory (every Actor will be also a member of a subclass) and the subclasses are disjoint (e.g. a Parent cannot be a Broker, and so on).
In this case, you'll need four relations, one for each subclass.
If instead the participation is optional (some Actor may not be a member of any subclass), you'll need a relation Actor(ActorID, ...) to store all the attributes in common between the subclasses (e.g. address), then one relation for each subclass, which will look like:
Parent(ActorID, ...)
Subsidiary(ActorID, ...)
Insurer(ActorID, ...)
Broker(ActorID, ...)
For these four relations, ActorID will be both primary key and foreign key referencing Actor(ActorID). The dots represent the attributes which are peculiar to the specific entity (as mentioned before, the common attributes will be in the Actor relation).
For Actors which are not member of any subclass, you just store the record in the Actor relation. For Actors which are instead member of a subclass, you'll store the record in Actor and in the specific subclass relation.
In all cases, relationships between the subclasses will be modelled depending on their cardinality.
If the disjointness between subclasses is different, i.e. non-disjoint subclasses, then the story is different.
Let's say that I have a MySQL table that I wish to use to use to model a relationship between two entities (A and B, for example). There are three columns: Person1, Person2, and Relationship. Let's further say that A and B are persons in this table and could have one of several relationship types, such as being friends, one requesting the other to be a friend, and so forth.
Is it possible (and preferable?) to use one row to do this? It seems like having one row that represents the A->B part of the relationship and another for the B->A part of the relationship would be a somewhat fragile setup, since if either of the two ever neglects to be updated the model could be in a rather odd state (A thinks B is a friend, B thinks A is something else).
The other part of my question is: how would efficient look-ups work? If there was only one row to represent the relationship, wouldn't all queries need to do a SELECT to check whether it is in the Person1 field or the Person2 field? Is there a nicer way of modelling this type of data?
(I realize this explanation is a little rough; please let me know if you'd like any clarification.)
You could have a column for the person who requested the relationship, the "requestee", the type of relationship (friend, etc), and whether the relationship has been approved by the "requestee"