Database Tables and Records

Firstly I would simplify the relationships between your tables. You only need a Foreign Key from an entity to its direct parent. In Tab le B you have a Foreign Key to Table A which is fine. But in Table C you have a FK to tables B and Table A. But you don't need the latter because you know Table B is linked to Table A. And the same for Table D. You only need to FK to Table C. The FKs for tables B and C are redundant.

To your actual request: There are different ways the data and their relationships could be presented. You could provide a "de-normalized" view, where you'd have one row for every row in Table D, and all of the Table C, B and A data would be repeated. Or you could literally replicate the relationships by have 4 tables where when you select a row in Table A and that then shows all related Table B rows; and then the same for Table to reveal all Table C rows, and then again for Table D.

Your design needs to follow the requirement(s) that you have gathered from the target user community - what is it they need to see? why? what are they going to do with that or in response to that data? Do they really need to see it all (would that even be 'consumable' by a User?) 

Firstly I would simplify the relationships between your tables. You only need a Foreign Key from an entity to its direct parent. In Tab le B you have a Foreign Key to Table A which is fine. But in Table C you have a FK to tables B and Table A. But you don't need the latter because you know Table B is linked to Table A. And the same for Table D. You only need to FK to Table C. The FKs for tables B and C are redundant.

To your actual request: There are different ways the data and their relationships could be presented. You could provide a "de-normalized" view, where you'd have one row for every row in Table D, and all of the Table C, B and A data would be repeated. Or you could literally replicate the relationships by have 4 tables where when you select a row in Table A and that then shows all related Table B rows; and then the same for Table to reveal all Table C rows, and then again for Table D.

Your design needs to follow the requirement(s) that you have gathered from the target user community - what is it they need to see? why? what are they going to do with that or in response to that data? Do they really need to see it all (would that even be 'consumable' by a User?) 

As said i will design the tables as below

TableA: ID-A, Cluster-A
TableB: ID-B, VM-B, ID-A
TableC: ID-C, Node-C, ID-B
TableD: ID-D, Instance-D, ID-C

The end user need to be able to export the file which should have all the columns from the tables
Cluster-A,VM-B, Node-C, Instance-D

That is the reason i am trying to create a report which has all the columns from all the table

So i am trying to create a report interface with record data, and adding relations between tables. can i do that ??