Вопрос, потянет ли Акцесс с миллионом записей и что из кода можно найти здесь для реализации схемы на картинке.
Одна запись (в сумме все поля) может тянуть на 2 кб символьного представления.
Желательно применить язык поиска (как в яндекс поиске), либо regexp на край.
Принципиальна скорость пересчета таблиц 4 и 6 семантических мепингов.

/что смутно - спрашивайте

Уточню конечную задачу.
Этот пример с должностями упрощённый, в реальной БД десятки полей, с текстовым представлением, которые хотелось бы объединить как текст и по ним искать шаблоны.

Итак. Задача классифицировать записи по принадлежности к темам, основываясь на тексте полей и сочетаниях значений полей.
Размерностей тематик - больше 1, т.е. справочник тем по контексту 1, отдельный справочник по контексту 2 - от 5 до десятков контекстов. Контекст, для понимания, например - это тип должности по иерархии управления, или отнесение статьи к случаю применения agile и гибких методов управления проектами.
Текст написан людьми и не всегда без ошибок, много синонимов, терминов, склонения.
Таких записей сейчас например 1 млн., десятки контекстов, каждый контекст может иметь десяток шаблонов.
Решать задачу перебором 1млн Х 100 Х 10 записей? потянет акцесс? Или колоночные БД - единственно производительный вариант?

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