Как мне построить отношения между моими таблицами?

Могут быть реализованы полиморфные отношения, которые решают проблему присоединения «n» различных типов сущностей.

Недостатком полиморфных отношений, насколько мне известно, является то, что их невозможно реализовать без некоторой потери ссылочной целостности.

Хорошим чтением об этом будет https://hashrocket.com/blog/posts/modeling-polymorphic-associations-in-a-relational-database. Одной из популярных и самых простых реализаций будет полиморфное соединение, приведенное в статье ниже:

Полиморфные соединения

Простой подход к подключению ACL к ресурсу заключается в использовании двух столбцов в таблице ACL: resource_type и resource_id. Этот подход был популяризирован Ruby on Rails. Таблица acl может быть определена следующим образом:

create table acl(
  id serial primary key,
  resource_type varchar not null,
  resource_id integer not null,
  -- other fields omitted
  unique(resource_id, resource_type)
);

Запрос для получения списка контроля доступа для документа с идентификатором: 42 будет выглядеть следующим образом:

select *
from acl
where resource_type='document'
  and resource_id=42;

Серьезная проблема с этим подходом заключается в том, что база данных очень ограничена в целостности данных, которую она может обеспечить из-за отсутствия ограничений внешнего ключа. Он может гарантировать, что у ресурса не более одного списка ACL, но это все. В ресурсе может отсутствовать ACL, а ACL может указывать на отсутствующий ресурс.

Метод Exclusive Belongs To — хороший метод повышения ссылочной целостности, но для каждого возможного типа объекта потребуется новый столбец. Цитата из статьи:

Exclusive Belongs To (также известный как Exclusive Arc) В этой модели список ACL имеет внешние ключи ко всем таблицам, которым он может принадлежать.

create table acl(
  id serial primary key,
  document_id integer references document,
  image_id integer references image,
  file_id integer references file,
  report_id integer references report,
  -- other fields omitted
  check(
    (
      (document_id is not null)::integer +
      (image_id is not null)::integer +
      (file_id is not null)::integer +
      (report_id is not null)::integer 
    ) = 1
  )
);

create unique index on acl (document_id) where document_id is not null;
create unique index on acl (image_id) where image_id is not null;
create unique index on acl (file_id) where file_id is not null;
create unique index on acl (report_id) where report_id is not null;

Обратите внимание на контрольное ограничение. Это гарантирует, что список ACL принадлежит ровно одному ресурсу любого типа. При таком дизайне список ACL не может быть потерян, но нет способа обеспечить наличие ACL у ресурса. Также важны частичные уникальные индексы. Ограничение уникальных индексов только ненулевыми значениями значительно экономит место, а также сокращает количество операций записи при вставке.

Чтобы четко ответить на ваш вопрос, вы не можете сохранить реляционную целостность, не создав по крайней мере еще две таблицы, одну для хранения реляционных идентификаторов между вашей моделью и вашими элементами, а другую для хранения всех данных для элементов, которые вы хотите создать, в этом случае у вас останется всего две таблицы, но боль в будущем будет излечена сейчас.