Every time I create a relationship, it creates it as a one-to-many. I do not see the method by which to alter a relationship to one-to-one or many-to-many.

For example, I have an entity (PERSONS) (simplified example)

PERSON_ID (my primary key)

NAME

MANAGER_ID (my foreign key to the PERSON_ID)

When I draw a relationship, it is by default a 1-to-many. In this case, it would be a one-to-one. If I select the attribute, and change it to my PERSONS Identifier, it still designates it as one-to-many.

I am obviously doing something wrong, but I cannot figure out how to resolve it. The documentation on one-to-one, one-to-many, and many-to-many is not clear how to change the relationship type.

Have a look at the following section of the Developing Web Apps course:

https://www.outsystems.com/learn/lesson/1770/modeling-data-relationships/?LearningPathId=2

It walks through the three different relationship types, and how they work.

Short answer is that you can't simply change the relationship type.

1-1 relationship is where you have a parent entity and an extension entity, the latter of which shares the Id attribute of the parent (it has no independent Id attribute of its own).

1-many relationships exist where one entity has an attribute that is the Id type of a related entity (foreign key relationship, essentially).

Many-many relationships require the use of a Junction Entity, which maps the Id attributes of two related entities.


This is what I did. But, in this case, the relationship is designated as a 1-to-many (even though it should be 1-to-1). If twisting, a 1-to-1 is a subset of 1-to-many. So, it should work. But, I didn't want to assume that it did work. Are you saying that this is OK?

Hi Bill, 

Why to you think this is a 1:1 relationship? A person will be manager of a single other person? Usually a manager is manager of more than one person 1:m (that is what you did). 

If you really wants to enforce a 1:1 relationship here, you will have to do it through logic, where you usually create a wrapper to the create and update actions and use logic to guarantee that if a value for the FK is provided, no other row in the entity have the same value already. 

Alternatively you could extract the FK to a second entity, where you change the Identifier to your person Identifier, creating a 1:1 relationship between them and this way, and than you create a unique index for the FK. 

You could try this approach index in your person entity, but the FK, not being mandatory, could create problems, that you would have to deal in the same way with logic. 

So, what exactly is the meaning of this FK of yours? What it says about the record where it is? 

Cheers

P. S. The way it is now, without extra logic it will be possible to the same person to be manager of many other persons. 

Eduardo Jauch wrote:

Hi Bill, 

Why to you think this is a 1:1 relationship? A person will be manager of a single other person? Usually a manager is manager of more than one person 1:m (that is what you did).

Well, since this is a single PERSON record, and has just a single value for the MANAGER_ID, and that single MANAGER_ID will connect to just one PERSON record, it seemed to be a 1:1. Yes, I know that a manager can have several people, but that is not the information I am storing.

I figured I was going to have to include additional logic to enforce it properly. Thanks. That will put me on the right track.

Also, I am thinking about just implementing this in the DB, creating an integration to my DB, and then I will inherit the proper foreign key relationships I want. Ultimately, that may be the more advantageous path for this.

Thanks for the input. You've given me lots to consider.


Hi, if this is really a 1:2 relationship, you may find better to use a secondary entity (1:1 to person) with this information FK for the manager (that is also a person) with a unique index on it (you can set it in this entity in OutSystems), as this will make logic much simpler and will avoid many potential errors. 

It is as I would habe done if this was my requirement. 

Also, I don't recommend at all to implement anything directly into the DB if there is a non external solution (and here we have more than one). 

Cheers