Hybrid Database Relationships? - mysql

Question

What is a relationship called when there are three entities, Table1 Table2 and Table3
Table1 has a One To One Relationship with Table3
Table2 has a One To Many Relationship with Table3
Table3 has two composite keys, Table1ID and Table2ID.
What is this relationship called? I'm trying to figure out how to model this in an ORM but because I don't even know what the relationship is, I don't even know where to begin.

Answer 1

We'd normally refer to that as reflexive or bi-directional.
Handling this in an ORM is non-trivial.
If you could remove the Table1ID column from Table3 (removing the foreign key pointing back), that would simplify the model. But that may not be an option for you.
Hibernate would refer to this as a bi-directional association; Hibernate only persists one "end" of that association; it won't maintain foreign keys in both directions.
EDIT
I reviewed the model diagram (from the link you provided in a comment).
It looks very much like the personVehicle table is an association table, between person and vehicle. This is the same pattern we would see in resolving a many-to-many relationship. Your model looks like a special case of a many-to-many, where one side of the relationship is constrained to just one.
In terms of keys, your model looks like this:
person
id PK
vehicle
id PK
personVehicle
person_id PK, FK->person(id)
vehicle_id PK, FK->vehicle(id)
If I understood what you are asking, you are wanting to represent a foreign key constraint on the vehicle table that points back to a row in the personVehicle table:
vehicle
id PK, FK->personVehicle(vehicle_id)
I don't know of any ORM that is going to maintain that type of bi-directional foreign key in the vehicle table for you automatically. (I don't think it's impossible to maintain the value in a foreign key column, it's not just possible to "declare" this association in a way where an ORM will maintain the foreign keys in both directions.
(Some databases, such as Oracle, allow us to create and maintain relationships like this, by allowing foreign constraints to be DEFERRED while we are inserting, updating and deleting, and postponing the checks on foreign key constraints until COMMIT.)
If there was a foreign key, from vehicle, pointing to a row in personVehicle, and there's a requirement that the row in personVehicle is required to refer back to the EXACT same row in the vehicle table (and not just some row) then you don't really need a foreign key in the vehicle table. The relationship is already represented sufficiently in the model by the foreign key in the personVehicle table.
If you need to enforce a constraint that a vehicle can be related to at most one personVehicle, that calls for a UNIQUE constraint on personVehicle(vehicle_id). That represents the requirement sufficiently in the model.
If this is truly one-to-one, and you need a foreign key, then this would actually be equivalent to removing the vehicle table entirely, and merging the attributes from that table into the personVehicle table.
EDIT
My use of the term reflexive may be incorrect. I usually refer to a table that has a foreign key reference to a column in the same table as being recursive.
In terms of a relationship between two tables, where each table has foreign key that refers to the other table... in the case where row in t1 refers to a row in t2, and that row in t2 refers back to t1, not to just any row, but back to the EXACT same row that referred to it... I think of that in terms of the relationship being "reflected" back.
The relationship reflects back. But we don't use the term "reflection" since that term has a special meaning in Java. So, maybe the only term that is appropriate is "bi-directional".
The typical bi-directional one-to-one relationship is the row in one table points to a row in the other table, which points back to the EXACT same row in the original table:
For example:
t1 t2
id t2_id id t1_id
--- ----- ---- ------
1 A A 1
2 B B 2
3 C C 3
Another form would be where a row did not necessarily refer back to the same row that referenced it. (This is not usually limited to a one-to-one), but we still have foreign keys that point in both directions (from t1 to t2, and from t2 to t1)
For example:
t1 t2
id t2_id id t1_id
--- ----- --- ----
1 A A 2
2 B B 3
3 C C 1
In the first case, we have a requirement where a row has a foreign key value that refers ONLY to a row in the other table that refers back to original row. The relationship "reflects" back.
In the second case, we don't have that requirement. If I start with row 1, it points to row A, which points back to row 2.
In terms of defining the foreign key relationships in the database, thee definition of the constraint is the same. The difference is usually whether the foreign key columns can be NULL, or have to be UNIQUE.
I thought there was a term other than just "bi-directional" that distinguished the first case from the more general second case. I thought I had used the term "reflexive" or "reflective", but I may be mistaken.
In terms of a "recursive" relationship, where a foreign key points back to a row in the same table, that foreign key (almost) always refers to a DIFFERENT row in the table; it does not refer back to itself.