I beg to differ. The one-one relationship is not called for by some abstract nature of "data" but by business or social rules. I don't care if someone wants to call it "assignment" or whatever. If a company assigns one desk to one person, one can philosophize that it really is just an instance of one person to many desks or many persons to one desks, or many persons to many desks. It takes nothing from the one-to-one relationship required by the rule. Once you take assign a desk to a person, that person can't get a second desk, or the assigned desk can't be allocated to someone else while in use. You may even believe that monogamy is a special case of polygamy but again such notion is unhelpful in organizing data. The point is that if a business/social rule calls for a pairing of data elements then one-to-one relationship is what is called for.
Sorry, but that's not a one to one in the sense that we are discussing. That's just a normal relationship. A true 1 to 1 relationship is where both records need to use the same primary key.
Monogamy/polygamy is a good example, and deciding how to structure relationships would be part of the data analysis, but I can't see that modelling a personal relationship is ever 1 to 1. Parenthood (as opposed to marriage) is different, but it's not really a relationship, it's just a simple attribute. A parent is an ancestor of an individual. To model genealogy all you need to store for any person is the personID of the mother, and the personID of the father, and then everything is determined recursively. A grandparent is a parent of a parent. A cousin is a child of a sibling of one of your parents. A sibling is another person who shares (one of) your parents, You don't need to store a "sibling" link at all.
Marriages, divorces, and personal family circumstances are completely different. I can't believe anyone would consider those as 1-to-1. Legally polygamy is permitted in certain countries anyway, and in any event serial marriages are always possible.
If a desk is assigned to one person, you just store the personID in the desk table, as if it is an attribute of the desk, similar to the size, or the colour. You can turn it round, and store the allocated desk in the person record, and then the desk is an attribute of the employee. The ID for the desk and the employee are different. You just treat the allocation as an attribute because you aren't bothered about the history.
If you want a history of previous assignments then you need a junction table. You can't just store all the previous assignments in the desk table, or in the employee table. (well you can, but then it's not normalised). That's what I was endeavouring to understand: how the OP deals with many to many without a junction table.
Note that in your example you need indexes or similar to prevent an employee being allocated to multiple desks, or a desk being allocated to multiple employees. And then maybe your system falls down, when you decide to work 2 shifts, and you therefore DO need to allocate the same desk to multiple users., or desks are used for hot-desking where any employee can take any vacant desk. This is all just normal data analysis.
I can only repeat that in strict data terms I think you never need a one to one relationship. That is one where records in different tables have the same primary key, because they are uniquely related, so there can only ever be one (at most) related record, and you don't need any business rules to control the data.
The only situations I can conceive of needing a one to one are that
a) you have more fields that can all fit into a single record because of size restrictions, so you put some of the fields in a 1-1 table
b) you have some fields that are rarely used, so to save a bit of space, you put these in a 1-1 table
b) you want some fields subject to different security settings. (eg payroll). You don't mind all staff seeing the name, home address or payroll number of an employee, but you don't want everyone to see the salary. Name, Home Address, Payroll Number and Salary are all attributes of employee and all belong in the employee record, but you put the "confidential" stuff in a separate record/table for protection