Можно в один запрос включить джойны на все таблицы материалов типа:
Этот запрос для каждой строки из карты будет искать соответствие в связанных таблицах. Если в какой-либо таблице соответствие не будет найдено, то нужное поле этой таблицы будет иметь значение NULL. Функция coalesce выдаст значение поля только из той таблицы, где было найдено соответствие типа и ид.
Ну, или NULL, если такого соответствия не было найдено ни в одной таблице.

Akina подсказал уже, как сделать гибкое решение - делаете VIEW-представление, в которое из всех нужных таблиц будут собираться записи. И в основном запросе будете использовать выборку только из этого VIEW-представления по уникальному коду материала.
При изменении/добавлении/удалении таблиц материалов прийдется редактировать только это VIEW-представление.

Основная здесь проблема - как сделать все идентификаторы из всех таблиц материалов уникальными.
Исходя из задачи выход только один - конструировать уникальный идентификатор из типа материала и внутреннего идентификатора материала в своей таблице.
Есть два варианта - каждой таблице назначить свой диапазон значений идентификаторов.
К примеру, дать на каждую таблицу по 100млн. записей. В этом случае уникальный идентификатор формируется как:

Второй вариант - использовать символьный идентификатор, который формируется из префикса - название типа материала и ид этого материала:


Т.е., сами таблицы материалов мы не трогаем, но во VIEW-представление "собираем" новую таблицу из нужных колонок и формируем уникальный идентифкатор материала по одному из вышеприведенному варианту.
Соответственно, выборку из карты делаем только с джойном по VIEW-представлению, подставляя в условие выборки ON поиск по сформированному идентификатору:
или


Выборка для формирования самого VIEW-представления будет примерно такой:
или

webzillaКаким образом формируется VIEW.Ответ в виде ссылки на статью уже дали. Я лишь добавлю, что можно воспринимать VIEW как некую таблицу, в которой реально нет данных. Т.е., создаем в базе VIEW и пишем в ней запрос на выборку данных из других таблиц. После сохранения эта VIEW будет храниться в базе как и прочие таблицы. При обращении к этой VIEW
автоматически запускается тот запрос, который прописан в свойствах этой VIEW и мы получаем результат такой двойной выборки.
Удобно в случаях типа Вашего - когда структуру базы менять нельзя или нужен достаточно сложный запрос, который будет использоваться часто в разных местах пользовательского приложения - вместо дублирования этого запроса просто ставим вызов нужной VIEW.
В последнем случае выигрышь еще и в том, что если нужно будет изменить запрос (изменились таблицы или изменилось условие), то не прийдется его менять в самой клиентской программе - просто изменим его в свойствах VIEW в базе!