Jimmy-- Multidimensional ("star" / "snowflacke" схемы) ?
Образцовый пример первого типа из перечисленных. Потому как именно что в отличие от нормализованных схем сущность почти однозначно соответствует строке в таблице.

Int23А почему "звезда" описывает одну сущность в строке таблицы фактов?
И в строке таблицы измерений тоже. Единственно, принцип несколько нарушается с иерархиями в строгой звезде.

Int23Ведь там же множество внешних ключей на размерности?
И чему это противоречит?

Допустим, я живу возле м. Сокол. Это - атрибут меня как сущности. Но само м. Сокол вместе со всеми его рельсами, поездами, сотрудниками, Ленинградским шоссе над и домами вокруг - моим атрибутом не является.

Так и здесь: атрибутом, реквизитом факта является "упоминание", ссылка на измерение, "измерение как объект", но не атрибуты собственно измерения.

Int23И получается что одна строка содержит только ничего не значащие значения (внеш. ключи). А сами данные требуется получать из других таблиц. Так или я что-то не попимаю?
Полагаю, Вы глобально заблуждаетесь.

В первую очередь, строка таблицы содержит не столько внешние ключи, сколько значения, measures. Скажем, для факта покупки - сумму покупки. Таблицы фактов, все атрибуты которых являются измерениями - вырожденный случай; я такого, пожалуй, никогда не встречал. Можно, конечно, сделать сумму покупки измерением - но смысл?

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

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

Разумеется, в измерениях в принципе могут храниться какие-то показатели. Скажем, может храниться ставка НсП, разная для разных субъектов федерации. Но во-первых, именно этот случай - скорее исключение, а во-вторых, это будет именно атрибут субъекта федерации, измерения (меняющийся по времени). Атрибутом продажи может быть "текущая ставка НсП" - которая как правило будет выделена как measure в таблице фактов, скорее даже как "В том числе НсП".

JimmyНу, насчет образцовости я бы не стал утверждать,
Скажем так, куда более близкий к образцу, нежели обычная нормализованная схема :)

Jimmy есть и другие отличия, типа истории изменения значения атрибута, которая хранится в таблице фактов.
Тут, пожалуй, околотерминологическое расхождение.

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

Разумеется, с логической точки зрения можно сказать, что таким срезом куба описывается некая "сущность реального мира". Но здесь с моей точки зрения как раз один из тех случаев, когда в проектировании уходят от однозначного соответствия реальных объектов сущностям проекта. Да, в реальном мире есть такая сущность. А в нашем проекте мы мыслим несколько другими. У этих других может быть прямой аналог в реальном мире - как у продаж, а может и не быть.

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

История как контрпример принципа "одна строка - одна сущность" опять-таки видна скорее в таблицах измерений, во всяких SCD2.