Qwe.Qwe1как правильно реализовать такое
Строго говоря, "правильно" - правильно так как тебе удобно будет с этим работать.
Насколько я понимаю, ты пытаешься вклинить дополнительный функционал в уже существующую систему. Причем сделать это так, чтобы гарантированно не поломать старый код.
Такие вещи не всегда получается реализовать "красиво". Поэтому исходи из критерия "удобно".

Qwe.Qwe1То есть таблица должна выглядеть как-то так:
ID | имя_таблицы | ID_из_таблицы | данные_вложения
Таким образом, по связке [имя_таблицы + ID_из_таблицы] можно найти все вложения конкретного объекта в конкретной таблице.
Как вариант, можно еще завести отдельную таблицу "Справочник таблиц", в который ты занесешь имена всех своих N таблиц и присвоишь им коды (те же INT IDENTITY). А затем в "таблице вложений" вместо столбца "имя_таблицы" добавишь столбце "ID_таблицы". Ну и, естественно, "СправочникТаблиц" надо будет связать с "ТаблицейВложений" внешним ключом по ID_таблицы. Это не обязательно, просто как вариант. При большом количестве вложений это позволит сэкономить место.

Qwe.Qwe1Но как в этом случае установить связи и правильно ли так делать
Если ты под связями подразумеваешь внешние ключи (FOREIGN KEY), то никак. Это придется разруливать в бизнес-логике (ну или с триггерами можно попробовать заморочиться, чего я бы делать не стал).

Qwe.Qwe1Думал перейти на UID-ы: в каждой из N таблиц добавил бы поле с UID-ом, а в таблице с вложениями вместо пары "имя_таблицы - ID из таблицы" ввел бы тоже поле UID и как-то бы связал их.
Думаю, не получится. У тебя получается одна таблица "Вложений" на множество (N штук) таблиц данных. Получается, что первичный ключ должен быть в таблице "Вложений", а не в этих N таблицах.
Но, т.к. ты сам пишешь, что:
Qwe.Qwe1Число таких "вложений": ни одного, одно или несколько.
То и этот вариант (когда Master-таблицей становится таблица "Вложений") не прокатит.

В общем, твой вариант со структурой
Qwe.Qwe1 ID | имя_таблицы | ID_из_таблицы | данные_вложения
мне кажется неизбежным. Может быть только с модификацией касающейся выделенного "Справочника таблиц". Но нужен ли он - это тебе виднее.

Кот МатроскинВаш второй вариант можно модифицировать, добавив глобальную таблицу (UID primary key), проставив на нее ссылки из "обьектных" таблиц и связав с ней внешним ключом таблицу вложений
+1
Правда в этом случае именно тип UID будет уже не нужен. Хватит банального INT

И еще нюанс. Кот Матроскин не указал явно (наверное фраза "проставив на нее ссылки" это подразумевает?) что между предложенной им глобальной таблицей "объектными" таблицами надо будет тоже сделать внешний ключ? В этом случае, логику вставки строк в "объектные" таблицы придется модифицировать: перед вставкой строки в "объектную" таблицу надо будет вставить строку в "глобальную" таблицу, чтобы получить ID для связи с вложениями.
Изменение кода вставки строк в "объектные" таблицы допускается постановкой задачи?

Qwe.Qwe1Если бы удалось сделать так, чтобы в модели данных для каждой из N таблиц появилась бы связь (т.н. "навигационное свойство") к таблице с вложениями, то, вставка данных была бы простой.
Тогда лично я поддерживаю вариант Матроскина.
Остается только решить нужны ли FOREIGN KEY's между "глобальной" и "объектными" таблицами.