Discussion Forum

To insert a relation with multi role players, do I have to 'match' all those players first?

If I have a relation ‘office_experience’ with many role players, such as below:

office_experience sub relation,
  relates e-person,
  relates r-start_time,
  relates r-end_time,
  relates r-office_clerk,
  relates r-office_leader,
  relates r-work_area;

work_area sub relation,
  plays r-work_area,
  relates e-state,
  relates e-county;

office_leader sub relation,
  has name,
  plays r-office_leader,
  relates a-leader,
  relates a-rank,
  relates a-level,
  relates a-duty;

office_clerk sub relation,
  has name,
  plays r-office_clerk,
  relates a-rank,
  relates a-level,
  relates a-duty;

start_time sub relation,
  plays r-start_time,
  relates a-year,
  relates a-month;

end_time sub relation,
  plays r-end_time,
  relates a-year,
  relates a-month;

When insert the relation, do I have to ‘match’ all player first? What if some information about certain player is missing?

If so and if ‘office_leader’ and ‘office_clerk’ don’t exist at the same time, do I have to generate ‘office_experience’ for each one of them, such as ‘office_experience_leader’ and ‘office_experience_clerk’?

Thanks for your attention and help!

Hey @yiouyou

First of all, for me it looks like not everything in your schema has to be relation :slightly_smiling_face:
Usually, relation means some sort of logical connection between A and B, for example, employee-employer, wife-husband, etc.

In your example I see start_time sub relation, it looks like it has to be attribute rather than relation since a particular year doesn’t connect to a particular month. Same for the end time and work area. For me, it doesn’t seem right that you are defining work_area as a relation between state and country. Relations are more about connecting entities in db, rather than real-world concepts like a year - month or country - city. Consider using attributes for that type of data. So maybe it will fit your model better if office_experience would be a relation with a start, end time, and work area as attributes, and relate clerk, leader and person as it does right now?

The same goes for the clerk’s rank, level, and duty. It doesn’t look for me that specific rank, level, and duty form an office clerk. It’s more like an office clerk is an entity, that has name, level, rank, and duty.

Regarding your question, you don’t have to match every player. You have to specify at least one player in relation when you are inserting it, and later update that relation to include the rest of the players if you want.

@vladyslav Thanks for your suggestion. I agree with you that to set up lots of relations instead of entities may not be appropriated. The difference I can think of is that relations set up a lot of links and entities set up a lot of instances, in other words, entities make many copies of some piece of information, however, relations make many links to those unique information. If considering the performance of quering, what do you recommend to do?


@yiouyou performance should be similar but I would suggest going with a better semantics :slightly_smiling_face:

Agree, thanks for your help!