Maksim SBEКакие базы данных (из реально существующих,желательно назвать область применения) Вы считаете наиболее сложными для разработки
Предметная облась которых часто меняется, и на изменения которой надо реагировать быстро.

drevБазы, в которых исходные данные недостоверны и многократно дублируются
Это исключительно проблема алгоритмов обработки таких данных и к БД прямого отношения не имеет.

drevНапример, иногда осмысленно разделить хранение полной и неполной/недостоверной информации. Т.е. меняется структура базы
Что значит "разделить"? Вынести в отдельную БД, в отдельную таблицу, или просто добавить поле с признаком "достоверности" (например, оценку вероятности истинности информации)? По-прежнему не понимаю, как может существенно повлиять вероятностный характер данных на сложность именно самой БД. Пусть даже меняется структура, ничего сложного в этом нет.

drevДалее, Представьте себе дубликатные объекты, у которых названия введены на разных языках, либо с использованием транслитерации.
Не очень понятно, дубликат чего именно в БД (объекта, наименования,...) рассматривается. В любом случае, больше похоже на ошибку проектирования БД. А то, что БД с ошибками поддерживать сложнее, чем без ошибок, считаю в большой степени верным утверждением. То же связано со старыми и новыми названиями. Хранение истории изменений делается один раз, работает как часы и проблем вообще не доставляет, если сделать его сразу по уму.

drevОтдельную таблицу. Представьте, что у нас сущность описывается десятками атрибутов, многие из которых являются ссылками на другие сущности. А в поступившей нам неполной информации присутствует 3-4. Причём, таких процентов 90. Естественно создать две таблицы, правда?
Пока не вижу оснований тупо увеличивать количество таблиц. Считаю "вероятность" значения атрибута атрибутом этого атрибута, а не атрибутом сущности.

drevИ все ссылки уже становятся более сложными, не так ли? Либо нужно вводить третью таблицу?
По-прежнему не вижу необходимости в третей таблице. Да и что значит "ссылки уже становятся более сложными"?

drevБолее того, "алгоритмы обработки таких данных", ИМХО, логично реализовать средствами базы? Нет?
Хм, если хранимые процедуры доступны и их язык Вы считаете "средствами базы" - возможно. По мне так это уже некая "надстройка". Изменить текст процедуры и структуру таблицы с данными - вещи несравнимые по сложности в продакшне.

drevну почему сразу "на ошибку проектирования БД"? Дубликаты объектов с различным способом введенными наименованиями, которые на момент ввода нельзя опознать как дубликаты (пока данных мало). Где Вы видите "ошибку"?
Я допустил существование ошибки проектирования, не более. В описываемом случае надо сделать только процедуру поиска и исключения дубликатов, а априори все записи считать разными. Это вполне очевидное решение. А так как алгоритмы поиска и устранения дубликатов могут существовать не только вследствие недостоверности данных, то я просто не считаю данную "тонкость" особенностью описываемой Вами ситуации.

drevНу поменялась улица А на Б, В на Г. а Д на А. И пришёл документ с улицей А. Какой актуальный адрес? "как часы" не получается, не так ли?
Если у документа нет даты для сопоставления с историей или других признаков для идентификации, то любой из 2-х вариантов может быть правильным. Соответственно, имеем не более чем уже обсуждавшуюся ситуацию, что адрес как атрибут документа имеет свой атрибут (свои атрибуты), связанный с неоднозначностью ссылки на справочник адресов (но не неоднозначность собственно значения, то есть, значение адреса в документе однозначно и корректно!).