SyncHub draws data from cloud platforms and stores it in a _relational_ format in your data warehouse. To use the warehouse, you need to know the relationships between the tables. This article
explains the two primary methods you can use.
### Method one - as provided by the cloud platform
In many cases, your cloud platform will provide "relationship" fields out-of-the-box. The naming scheme for these varies, but it is intuitive. In this example, our ProductPrice table has a column called ProductGuid. It is logical that this refers to the Guid column of the Product table:
![Data relationships provided by the cloud platform](https://www.synchub.io/i/kb/datarelationships?api=/saasrelationship.png)
### Method two - SyncHub auto-relationships
The above method only works if the cloud platform formats its API in a relational format. However, many APIs return their data nested. In these cases, there is no parent "column" provided because it is inferred by the nesting relationship.
By definition, your relational data warehouse does not store "nested" data - each entity is in its own table. In these scenarios, SyncHub will helpfully create additional columns which allow you to tie the child tables back to their parents:
- Every table has a RemoteID column - regardless of whether it is a parent or child table
- If a table has a Child table, then the child will have a column named [Parent]RemoteID. In this example below, the column is called TaskRemoteID because the parent is the "Task" table
![Data relationships provided by SyncHub](https://www.synchub.io/i/kb/datarelationships?api=/synchubrelationship.png)