Thanks a lot for your answer! I was definitely a bit stuck that putting it in one table didn't even come to my mind. I was able to successfully adjust and rebuild my model in a way better more appropriate manner now.

@DocBrown Now that's unfortunate, I was not aware I couldn't see something like that. I would be more than happy to provide more detail, but I am unaware about what's missing. Probably the "use case" is missing. I will edit the question by providing what I am looking to query for and hope this will be enough detail supplied. Thanks for informing me.

@DocBrown Yes there is a reason for different tables. Not all users will have permission to query all documents and their relations. Also this structure might be better suited in my mind when it comes to the "updating a document" problem.

@DanWilson We actually have business goals/metrics in textual form which are not quantified by scalars that need to be stored that way. Text is scraped from internal documents. The relations will be Querried by an REST or GraphQL API; from a frontend, hence the idea of a database.