Это типичная реализация наследования.

Есть два основных варианта:
1) - реализация наследования в виде связи 1-к-1 (атрибуты не дублируются в производных классах/таблицах )
Для вывода общего журнала документов делается простой select из главной(родительской) таблицы.
Document(ID, Date)
FinDocument(ID, Sum, ...) связан 1-к-1 с Document по ID.
2) - реализация наследования, когда атрибуты родительского класса/таблицы дублируются в производных. В этом варианте для построения общего журнала документов создается view с union all всех таблиц и общими атрибутами.
Document(ID, Date)
FinDocument(ID, Date, Sum) нет связей с Document, ID должен быть уникален в пределах БД.

select ID, Date from Document
union all
select ID, Date from FinDocument
union all
...

Минусы первого варианта - производительность (таблица Document разрастается, необходимость множества join-ов (зависит от уровня наследования) начинает
влиять на производительность)

Минусы второго - и в сопровождении (например, необходимо расширить родительский класс доп. атрибутом, тогда придется это сделать для всех производных классов), и в том что с точки зрения "реляционности" это не совсем красиво смотрится.

Я, со своей стороны рекомендовал бы при начальном проектировании или на начальной стадии проекта использовать всегда 1-ый вариант, а в последствии, если возникают проблемы с производительностью, переходить ко второму варианту, но только когда это действительно необходимо. Таким образом, ничто не мешает комбинировать эти два подхода, что я c успехом и делаю :).
При этом, подобный редизайн можно даже возложить на dba, если предоставить ему детальную road-map на случай падения производительности в подобных схемах.

ОбщЖурДок связан с ДокN 1->1 (ОбщЖурДок.DocID->ДокN.DocID),
только связь в другую сторону...:
ДокN связан с ОбщЖурДок 1->1 (ДокN.DocID(PK) -> ОбщЖурДок.DocID(PK)),