Ну, это-то, как раз, понятно. Не только под фонограмму, но и под видеограмму:)

ViPRosСуррогат , смотри что за ней спрячено
Я знаю, "что за ней спрячено":) Я Вам то же самое объяснил, когда рассказывал про вычисляемые характеристики и триггеры:) И зачем здесь еще одно понятие - "суррогат"?

ViPRosКлассификатор не Макротип.В Макротипе Типы связаны. Из любого типа есть путь к любому.

Вы имеете в виду, что нет ПРЯМОЙ СЯВЗИ между Домом и Страной в Вашем примере "классификатора"? Но ведь связь-то есть, так что путь (на уровне типов, то есть в первом значении модели данных по Дейту) есть, как раз, от любого типа к любому. На уровне экземпляров, конечно, нет, так как в одном направлении связь 1:1, а в другом 1:М. Но Вы же на уровне типов рассуждаете. Так что из Вашего же объяснения следует, что "классификатор" - это именно "макротип". Что-то нужно подправить в консерватории:)
ViPRosА в Классификаторе типы могут быть не связаны межу собой, роль связующего звена тут играет виртуальный тип - сам классификатор.

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

Если не называть "целостность" "семантикой", то можно сказать, что "классификатор" - это "макротип", обеспечивающий "семантику" ("целостность" он само собой обеспечивает, как и любой "макротип"):)
А что за "целостность", и что за "семантика"?
ViPRosПри этом классификатор классифицирует и макротипы.

Ну, то, что макротипы объединяются в макротипы - это можно понять. Но зачем? Я продолжаю настаивать, что классификатор - это просто тип характеристики объекта, не такой простой, как сторока или число, но, все-таки, просто тип характеристики объекта. Это применительно к развитию классифеской объектной модели данных. Применительно к Вашей "неизвестной модели данных" классификатор - это макротип, пока, Вы меня не убедили, что это не так:)

Ну и по Вашему примеру. Здесь же Город (и т.п.) - это не объект с многочисленными характеристиками, а просто "элемент классификатора". Тогда это все решается двумя объектами и двумя связями между ними:

Элемент адреса --Состоит из/Входит в--> Элемент адреса
Элемент адреса <--Имеет/Используемый для-- Тип элемента адреса

У объекта Тип элемента адреса (его экземплярами в Вашем примере являются "квартира", "дом", "улица", "город", "страна", "планета", "галактика") могут быть характеристики:
1 Наменование
2 Номер уровня в КЛАДР
3 и др.

Так что в такую конструкцию несложно загрузить КЛАДР:)

ViPRos"Элементы адреса" есть Классификатор.
Начиная с Галактика и ниже любой Тип может образовать Макротип на любую глубину.
Макротип с главным типом Человек есть сам тип Человек.

Почему Человек - "главный тип"? Как можно понять последнее предложение? Почему А + B = "само B" ???
ViPRosКлассификатор отображется на навигационное меню пользователя.

Надеюсь и типы, и макротипы, и, так и непонятые какие-то связи и роли, так же отображаются "на навигационное меню пользователя". Пользователь не с одними же "классификаторами" имеет дело.
ViPRosМакротип (частным случаем является тип) отображется на доменные объекты (бизнес объекты, документы и т.д.), суть в пользовательскую форму.

"Суть" - это как-то не убедительно. "Документы" и "бизнес объекты" - это что??? Какую роль они играют в модели данных? При использовании классической объектно модели данных пользователю отображаются именно ее структурные элементы: объекты, характеристики объектов, связи между объектами. Как их отображать решает сам пользователь. А у Вас какие-то "документы" и "бизнес объекты" появились?
ViPRosМетоды типов макротипа отображется на групп меню (действие, отчет и т.д., какие сами сочтете нужным).

Методы - это отдельная "песня" ООП. Туманное понятие. Нет в БД никаких методов, кроме создать, обновить и удалить, грубо говоря. Другие методы могут появиться, если Вы, например, программируете завод-автомат, где один робот посылает другому роботу сообщение: "Ты готов к приему заготовки такой-то?":)
ViPRosНа все это наложено ограничение доступа по ролям.

Это вполне убедительная фраза, если понятно что такое "всё это":)

ViPRos"Мигрирующие свойства" наследуются в основном (рекомендовано) виртуально (обеспечение человекочитаемости - лукап), только ради производительности выборки можно сделать их персистентными.
Лукап обеспечивается параллельно еще одним механизмом. Создается и ведется словарь всех идентификаторов и их человекочитаемых расшифровок с учетом каскадности ссылок типов.
Я пока не готов к тому, чтобы это прокомментировать. Понятно что Вы своими словами говорите о вычисляемых характеристиках объектов, значения которых не хранятся в БД, но могут и хранится (вычисляться в триггерах при обновленнии тех или иных характеристик тех или иных экземпляров тех или иных объектов).

ViPRosСвойсто - самый примитивный тип (может ссылаться только на меру, пока не реализовано, потому что до конца не понято), которое является именованным подмножеством базисных множеств.
Тип может содержать в себе ссылки на другие типы и свойства.
Не понятный момент, видимо, поэтому и не реализованный:)
Свойство объекта нельзя измерить, и, следовательно, у него не может быть никакого значения.

ViPRos"Вычислимы" я конечно ошибся в отношении типов и макротипов.
Просто через типизированные Связи и Роли (так же и Классификаторы) можно получить столько информации, что выбор соответсвующих типов е составляет труда. Т.е., если нам нужно удалит все типы в "Элементы адреса", то пофиг как они называются и как устроены, у нас есть более общий способ их идентификации. Тем самым не надо глубоко знать структуру БД.

Конечно, просто удалил связь Человека с Квартирой и весь Адрес удалился:) А при чем здесь "типизированные связи" и "роли"? Где они здесь?
ViPRosИли если нам надо найти входимость всех "Составные сущности", то мы выбираем типы где есть ссылка на типы с таким Ролем.

Как же нелегко:) Теперь еще "составные сущности":) Это не "макротипы"?
"Составная сущность" - это что "роль"? Чья роль ("артист") и где ("персонаж" и "пьеса")?
ViPRosИли если мы ищем "Экземплярные классы", то ищем все типизированные связи "Наследование" и т.д. Структура БД практически не нужна, как больше семантики, так меньше нужды в логической структуре.
Появились дополнительные структурные элементы модели: "экземплярные классы" и т.д. И тут же утверждение, что структура не нужна :)

ViPRosЧтоозначает, что структур можно и нужно делать как можно точнее для описания объектов, нефиг Икру и Сталь называть Товаром, Товар - Классификатор, Икра где то в Морских деликатесах, Насыщенных белковых структурах, Сталь в Сталях. :)
А то блин надоели эти , "а куда совать непохожие характреистики похожих фиговин", в Разные места!
Прямо крик души какой-то:) Но, Вы должны определиться что именно НЕ ЯВЛЯЕТСЯ товаром: икра или сталь:)

ViPRosКласификатор добавляет в каждый из типов новое свойство, которое равно имени Классификатора.

Классификатор добавляет? Это как? В каждый из каких типов? Свойство не может быть ничему равно, так как не может иметь никакого значения.
Пока я понимаю так, что, например, в тип (?) Город добавляется свойство Элемент адреса. Это так? А зачем???
ViPRosПри этом структура типа не изменяется, тип воще может не знать , что какой то козел его как-то обозвал, хотя в реализации у типа есть метод для этого.

Пользователь, конечно, может изменять названия объектов и характеристик объектов в создаваемых им схемах данных, но в данном случае "козел" - это не пользователь, насколько я понял, а классификатор:)
ViPRosКлассификатор какой-то вертикальный агрегат, может агрегировать (создать подсхему) несвязанные типы.

Ну да, "вертикальный макротип", другими словами:)
ViPRosВ типе может быть явная ссылка на Классификатор, тогда тип ссылается на все типы по всей глубине классификации.
Макротип почти то же самое, но тут все входящие типы явно связаны, это какой - то горизонтальный агрегат. Тип не может в явном виде ссылаться на Макротип.

Ага, значит "горизонтальный макротип":) Тяжеловато получается, очевидно, что нужно минимизировать систему понятий и дать их определения.
ViPRosОбе образуют подсхему, но по разному, Классификатор как угодно, а Макротип инкрементно от точки входа(главного типа макротипа). У Классификатор точка входа сам Классификатор, а у Макротипа Тип на который ссылаются явно или косвенно (и через классифиактор тоже) другие типы.

Я сейчас выпью сто грамм и подумаю над этим:)
ViPRosКлассификатор может НИЧЕГО не классифицировать.

Не, двести:)
ViPRosа Макротип хотя бы один тип.

Не, я сейчас куплю квашеной капусты, и выпью все поллитра.
ViPRosКак все запущено блин. :(

Вы тоже за капустой пошли?

ViPRosКроме
Свойство, Тип, ССылкаНаТип, Макротип, Классификатор, Тип связи, Роль Типа, Событие Типа, Метод Типа, Ограничение Типа (+ некоторые технические вещи для маппинга в РСУБД) в модели ничего нет.
Все другие Имена, которые мною названы - ПРИМЕРЫ.
Это радует, хорошо, что я еще не успел обуться:) Итак:

1) Свойство - это что? Я Вам уже раз пять про свойство сообщал:) Видимо это характеристика объекта .
2) Тип - это что? Может быть объект ?
3) Ссылка на тип . Ссылка из чего??? В классической объектной модели тоже на сегодняшний день помимо явнях связей есть ссылки. Там это ТИП ХАРАКТЕРИСТИКИ ОБЪЕКТА (второй, и явно избыточный, механизм связей между объектами). А у Вас в модели это что?
4) Макротип . Дайте определение. Что это? Зачем? в чем объективная необходимость?
5) Классификатор . Ну про это отдельный разговор. Хорошо (в научно-познавательном плане), что Вы это включили в модель. Но, что это такое, и почему в Вашей модели это понятие имеет самостоятельное значение?
6) Тип связи . Скорее всего, заблуждение. Я вот только что провел ревизию одного "ядра" для разработки web-приложений. Там тоже есть понятие "тип связи". Например, "имеет" (это такой тип). Его потом назначаем конкретным связям между конкретными "объектами". Это ошибочный подход, и его ошибочность хорошо проверена на практике. Понятие "тип связи" бессмысленно. Ну можно его использовать для извлечения из списка шаблонов при создании новой связи. Но практической пользы от этого нет никакой.
7) Роль типа . Я уже спрашивал: роль типа в чем??? Как я уже объяснял уровень абстракции классической объектной модели данных можно изменить, детализировав "объект" на "сущность" и "событие". Участниками события являются сущности. Но даже и здесь нет места понятию "роль" (роль участника события в событии), так как это определяется семантикой связи участника события с событием:)
8) Событие типа . Нет я, все-таки, пошел обуваться, пока магазин не закрылся.
9) Метод типа . Греет душу, конечно, как ученому. Метод, методика, методология... Но абсолютно сырое и, скорее всего, малопригодное понятие для баз данных.
10) Ограничение типа . Полезная вещь, скорее всего, но нужно четкое определение.
11) + некоторые вещи для маппинга в РСУБД . Приехали:) Я Вам объясняю, что нужно использовать вместо РСУБД, чтобы не мучиться, а Вы предпочитаете строить какую-то невероятно сложную конструкцию (более одиннадцати структурных понятий) В ДОПОЛНЕНИЕ К РСУБД, чтобы эту несчастную РСУБД можно было хоть как-то использовать:)

Все. Решил просто поесть сала с горчицей и черным хлебушком:) Даже пить нет причины.