CDS - difference between lookup and 1:N relationship

[JohnYu500]

Hello,

The project I am working on has a few One To Many relationships.  I have successfully set up one 1:N relationship between two tables. When I view data of the parent table in CDS, I see the records of the child table. So the relationship is right.

But I do not see a column in the parent table that points to the child table. I need to create a calculated column on the parent table and the value of the calculated column will be determined by its child records. For this reason, I think I need to be able to access the child records of a given parent record. But the calculated/rollup interface does not show me that option. But I do get to see the lookup tables that the lookup columns of the parent table point to.

Could someone please tell me:

1) What is the difference between a lookup table and a relationship? When should I use one vs the other? The concepts seem different from the old relational database design concepts.

2) If setting up a 1:N relationship is the right thing to do, how do I populate a calculated column on the parent table based on the values of the child table?

Thank you for your help.

John

[poweractivate]

@JohnYu500 

In Dataverse (formerly Common Data Service or CDS)  the way to get an aggregate value of a field across multiple child entity records associated with a parent entity, and get that aggregated result to show up on what you call a "calculated field" on the parent entity, would be to, instead of using a "calculated field", to use a Rollup Field on the parent entity.

More information:

https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/define-rollup-fields

https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/calculated-rollup-attribute...

[poweractivate]

@JohnYu500 

---

@JohnYu500 wrote:

Could someone please tell me:

1) What is the difference between a lookup table and a relationship? When should I use one vs the other?

---

We are unfamiliar with the terminology of a "lookup table" in Dataverse.

If you meant a "lookup column" (ref) versus a "relationship", here is explanation:

The "relationship" you are referring to, the main kind which is 1:N , let's suppose that one Account record can have many Contact records. The subgrid would be on the Account record, and can list 0, 1, or more than 1 Contact records associated with it.

On the other side of the perspective, the same relationship exists as Many to One, or N:1 between Contacts and Accounts - which is the same relationship actually, just seen from the other end.

Only this time, any one distinct Contact  record optionally has a specific reference to exactly one Account record, usually visually represented through a lookup column (previously called a lookup field) on the Contact. Another distinct Contact record, also can have the reference in the lookup column pointing to that same specific Account record as well. This would cause there to be those two exact contact records to be shown in the subgrid on the Account record side, and on each of the two distinct Contact records, the lookup field set to be pointing to the same Account record. So many Contacts can have one Account or N:1 from Contact to Account.

The N side of the relationship usually has the lookup field on it, or what is called a lookup column. (note that field has recently been renamed to column, as part of the round of name changes related to CDS rename to Dataverse)

---

@JohnYu500 wrote:

The concepts seem different from the old relational database design concepts.

---

No this part is the same actually. 

In our opinion it is just being represented in a little bit easier way actually. When you see a lookup column (formerly lookup field) on a record form, you can already tell that this Table (formerly called an Entity) has to have an N:1 there in some way. When you see a subgrid on a record form, you can already tell it has to have a 1:N in there for that Table (formerly called an Entity).

So that is why Dataverse is quite useful and powerful in this respect as it matches very well with database design concepts.

Let us know which part you think is very different from relational database design concepts.

Finally, here are some visual examples to help more with the above:

Account View

Contact View

Account Records:

Account 1 Record Form Subgrid listing both of the 1:N associated Contact Records

Account 2 Record Form Subgrid listing the associated 1:N associated Contact Records(there happens to just be one here, but there can be zero associated records, one associated record, or more than one associated record)

Contact Records:

Contact Number One  Record Form with lookup column (previously called a lookup field) N:1 pointing to Account 2: 

Contact Number Two  Record Form with lookup column (previously called a lookup field) N:1 pointing to Account 1: 

Contact Number Three Record Form with lookup column (previously called a lookup field) N:1 pointing to Account 1: 

In all three of the above screenshots of each Contact record, the lookup column (previously called a lookup field) points to exactly one Contact record. However, notice that more than one of these records can possibly point to the same record - that is why it is N:1 and not 1:1. 

In Dataverse, a true 1:1 relationship between two tables cannot be modeled natively in the specific way you might have in mind (without some specific potential workarounds), this might be the only real difference. A one to one relationship in Dataverse is  usually natively built as just another regular column (formerly called a field) on the same Table.

Moreover, note it is also possible for the lookup column (N:1) on a Contact record to be simply left blank and not point to any single Account record at all (unless it is set as a required field) - the relationship and lookup by themselves do not necessary imply that the record must be associated, only that it can be associated.

We also use the word record very often to deliver the following point.

The definition of a Table (formerly called an Entity) is very different from the actual records contained in that table. The 1:N relationship is best understood keeping the records of the Tables in mind. The records are the actual things that end up having the relationship with other records - the Tables are just the ones that determine through definitions of the relationships, that the relationships are possible between the records of those Tables in those specific ways. The lookup column is usually the hint of the N:1 relationship, and subgrid the sign of the 1:N relationship. Note that the column and the subgrid need not be actually present on the form for the relationship to exist, but if they are present, they are how you can easily tell the relationships and in what direction they are.

In other words, placing a subgrid on a form to show one, or more than one associated record from another table,
usually requires the 1:N relationship to be defined first between the two tables,

and placing a lookup column on a form to reference one associated record from another table,
usually requires the N:1 relationship to be defined first between the two tables.

Hope this helps.

[JohnYu500]

@poweractivate,

Thank you for your prompt reply.

With the 1:N relationship where both the parent table and the child table have a currency column, I am able to populate the currency column on the parent table using rollup.

I have another column, which of data and time type, on the parent table and I want to auto-populate it with the value of one of the datetime column of the child table based on some condition. When I tried to do this, I do not even see the child table listed in the Entity list.

I am not sure if I have made myself clear.

Thank you again.

John

[poweractivate]

@JohnYu500 

Canvas Apps can be embedded in Model Driven App Forms with context , so you could embed a Canvas App in a Model Driven App and implement the functionality in the Canvas App.

It is also possible to use instead a
web resource, 
Power Automate

or

Plugin

(because Business Rules may or may not be enough to do this specific scenario)

Other than this, we are unsure if it possible to do this only from a calculated field or rollup field in this case.

We would be curious how to do this only with the Calculated Field or Rollup Field. It may be possible but we are not sure in your specific scenario how it would be done. For that we would welcome another user in this forum to suggest a solution using only the Calculated Field or Rollup Field - or to elaborate more on another possible approach.

[JohnYu500]

@poweractivate ,

Thank you so much for the detailed explanation. 

Regarding the lookup column: you are right. I did not make myself clear. I did mean to say the lookup column of a table. I believe the table a lookup column points to (or references) is the lookup table. 

I now understand that this lookup concept is actually the same as it is in relational databases.

I also understand what the 1:N or N:1 relationship means. But somehow I still cannot get what I am trying to do.

Here is exactly what I am trying to do.

I have a contract table and an options table. A one-to-many relationship is set up between the contract and the options table, which means a contract has one or more options. Pretty straight forward.

On the contract table, I have a column of data and time type called RenewDate. And on the options table, there are some columns: StartDate, EndDate, isActive, fundingAmount, etc.

Now what I need is automatically populate the RenewDate on the parent table with the EndDate of the option that is Active.

When I was trying to use the calculate inteface to implement it, the interface does not even give the option to get to the options table. But the interface does give access to the lookup columns. This is where I need help.

It seems difficult to explain. Hope I made myself clear. 

Greatly appreciate your assistance.

John

[JohnYu500]

@poweractivate ,

I do not necessarily have to use the calculated feature to achieve. This happens to be the only thing I know/learned for PowerApps. But I do want to achieve this from the Dataverse because I'd like to centralize the logic.

Thanks.

John

[poweractivate]

@JohnYu500 

---

@JohnYu500 wrote:

On the contract table, I have a column of data and time type called RenewDate. And on the options table, there are some columns: StartDate, EndDate, isActive, fundingAmount, etc.

Now what I need is automatically populate the RenewDate on the parent table with the EndDate of the option that is Active.

---

One thing we notice here, is in this way you  set it up, more than one contract could have the isActive state set upon it. Presuming you do not want this, and presuming only one option must be active at a time - then using a web resource, Canvas App, or Power Automate could be insufficient as it would not enforce the integrity in the server side in a solid way, because for example suppose an embedded Canvas App has it all there. However the integrity rules can be violated from say a Model Driven App form, that is existing elsewhere, and then cause more than one Active option to occur, and violate the integrity. And also, we are unsure that  the simpler alternative one should always check first, the Business Rules can actually do something of this complexity - if they could though, those are enforced when the scope is set on the whole Table, so those would work if it were possible - but we are unsure Business Rules can do it for this scenario.

So it is likely a custom Plugin (this is written in C#) is needed to be developed and registered against the appropriate message on that Table, so that when the record is updated from the N side to set isActive to true, first it must fetch the associated record (the one side) by the Lookup Field - then it must enumerate all the N side of the records to see if any other associated record form the N side is set to Active. If one already is, it must throw the error message and then block the change attempt in the current record - then it will work.

The same Plugin can then also do as follows for rest of your functionality: If the condition above is false, then it will also just lookup the 1 side from that record N side and just go ahead and directly set that date you want from the N side, over on that field from the one side.

The same Plugin also can check - if the value is being changed from Yes to No on isActive, it can then clear the above one side's field to the blank value.

Now to implement this with the sample C# code, we would need to take quite some time to do this, it is very advanced to do this. If we happen to have some time to do this, we might reply with a specific sample and details of it so you can check it.

Which is why if someone else on this forum have the more creative idea than this, it is most welcome  and we would also be interested to know of it - in our opinion though, we are unsure if any of the possible creative ideas, do not have a tradeoff, such as that there is a way to set two isActive states outside of the app. The creative idea that other person may have, may have to suggest you to rethink the way you set up the data in the first place to avoid this pitfall.

If later we happen to have such idea, we might check back and let you know in a reply as well.

If you do not care if two isActive states are set, there may be more options such as the web resource - however, the moment we say "if you do not care if two isActive states are set" it already does not feel good, the only way we could feel comfortable with it with the way the data is set up is with custom Plugin so it is a very solid solution is what we can say for now.

[JohnYu500]

You are right. There could be more than one option record that is IsActive (true).

I do care about data integrity and I planned to use Business Rules to enforce that although I have yet to figure out how to do this.

I seem to read from your message that the way I set up the relationship between these two tables is not appropriate. If this is the case, how would you set it up? I want to get my data model right. I am talking about U.S. federal contracts that usually have some option periods - which is a typical one-to-many relationship.  So it is natural to create a 1:N relationship between contract and options.

Hope I do not have to go through the custom C# code route.

John

[poweractivate]

@JohnYu500 

---

@JohnYu500 wrote:

You are right. There could be more than one option record that is IsActive (true).

I do care about data integrity and I planned to use Business Rules to enforce that although I have yet to figure out how to do this.

I seem to read from your message that the way I set up the relationship between these two tables is not appropriate. If this is the case, how would you set it up? I want to get my data model right. I am talking about U.S. federal contracts that usually have some option periods - which is a typical one-to-many relationship.  So it is natural to create a 1:N relationship between contract and options.

---

The thing is we think you set this all up correctly in our opinion. We are unsure right now of another way to set it up to be honest with you. We were just saying we suspect there might be some other, different way to set it up (that could require some time to think of it), that would result in suddenly not having to go to the custom C# code route. However, right now we are not so sure what that way is.

For this reason - if we think of either a) the other way to avoid the custom C# route or b) to just do it that C# way and provide it to you (but this can take time, we'd have to check if we have the time to do this - you are also welcome to try it of course) - we would let you know if we have either of these two cases.

Right now we don't have either yet - so in the meantime we welcome the response from another perspective if someone else here on this forum would like to volunteer to check on this for you.