Атрибуты сущностей в отдельных таблицах

Есть задача построения схемы б\д и каркаса классов бизнес логики на основании некоего описания (например в формате XML). Под воздействием различных материалов и конференций, прочитанных мною в последнее время, вырисовывается, на мой взгляд, интересная идея построения б\д. Хочется понять имеет ли эта схема хоть какие-то перспективы или лучше сразу выбросить её на помойку, не тратя время.

Кратко идея состоит в том, чтобы рассматривать атрибуты сущностей как связи с другими сущностями и хранить их в отдельных таблицах со связью один-к-одному.

Например есть сущность ПЕРСОНА, она имеет атрибут АДРЕС. Часто на первом этапе реализации этот атрибут становится строковым полем таблицы ПЕРСОНА.
Но в дальнейшем выясняется что атрибут АДРЕС есть и у других сущностей, например ОРГАНИЗАЦИЯ, кроме того вместо строкового поля появляется необходимость иметь структуру типа СТРАНА,ГОРОД,УЛИЦА и т.д. Конечно можно сказать, что об этом надо было думать еще на этапе проектирования, но легче от таких заявлений не становится. В предлагаемой схеме все атрибуты рассматриваются как связи с какими-либо сущностями . Т.е. схема будет выглядеть следующим образом:

PERSON( OID) PERSON_ADDRESS( PERSON_OID,ADDRESS_OID) PERSON_FNAME(PERSON_OID,STRINGDATA_OID) PERSON_... ... FIRM(OID) FIRM_PRIMARY_ADDRESS(FIRM_OID,ADDRESS_ID) FIRM_... ... ADDRESS(OID) ADDRESS_COUNTRY(ADDRESS_OID,COUNTRY_OID) ADDRESS_CITY(ADDRESS_OID,CITY_OID) ADDRESS_STREET(ADDRESS_OID,STRINGDATA_ID) ... COUNTRY_... ... CITY_... ... STRINGDATA(OID,DATA varchar(255))

на первый взгляд данная схема имеет следующие недостатки:

1. Увеличение кол-ва таблиц и связей между ними
2. Усложнение написания запросов
3. Невозможность создания индексов по нескольким полям
4. Блокировки множества таблиц при изменениях данных

с другой строны имеются и преимущества:

1. единообразное представление сущностей и атрибутов (нет необходимости делать выбор - создавать таблицу или поле), мы изначаьно закладываем возможность изменения(я бы сказал эволюции) схемы б\д.
2. изменение структуры значительно проще чем при классическом подходе (можно менять как и состав атрибутов, так и их тип )
3. таблиц становится больше, но их размер уменьшается - это может увеличить производительность
4. при выборках и обновлениях используются только те таблицы которые затрагиваются этими операциями (т.е. пользователь меняющий атрибут PERSON_FIRSTNAME не мешает пользователю считывающему PERSON_ADDRESS) - это может сгладить недостаток 4

Недостатки 1 и 2 могут быть обойдены ситемой хранения описаний данных (метаданные) и средствами динамической генерации SQL запросов.
Недостаток 3 по-видимому может быть обойден с помощью материализованных представлений, хотя я с ними не работал, потому не могу судить.

Вероятнее всего такую схему рационально применять не для всего проекта, а для тех частей, которые подвергаются частым изменениям.

Поскольку я с такой структурой не работал, мне было бы интересно услышать мнение участников форума, особенно тех кто применял этот подход в реальных разработках.

1. Далеко не все атрибуты сущностей являются связями с другими
сущностями - есть например, рост, вес, цена
2. Вряд ли имеет смысл использовать связи типа 1-1,
фактически, отказываясь от реляционного подхода (таблицы ненормализованы) теряешь довольно много

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

Тема обсасывалась здесь (Объектная БД и т.п.):\r

/topic/5961\r

/topic/12523

Если рассматривать в контексте БД я бы сделал так:
проектировал таблицы как обычно и ввел описание сущностей (фактически таблиц)

id
table
name
idcolimn --суррогатный ключ
showexpr -естественный ключ (атрибут или их комбинация)
showalias

И атрибутов:
id
tableid
column
name
datatype --Все стандартные + Ссылка на другую сущность
referenceTo --если атрибут ссылка - то идентификатор сущности
referenceType -- тип ссылки, child - в колонке хранится значение идентификатора сущности (в интерфейсе - список выбора), parent - фактически виртуальная колонка, означает что к записи привязано несколько сущностей из другой таблицы (аналог в интерфейсе - подчиненная форма).

2 Jimmy
Здесь несколько иная проблема как мне кажется.

2 Курков Михаил
Не совсем понятно в чем проблема то, во всяком случае по описанной структуре. Куда в этом случае текстовое поле "Адрес" из персоны девается?

В догонку, кажется понял в чем проблема, хотя проблемы как таковой не вижу. Разведите адреса разных сущностей на Супертип -> Подтип, и получите совершенно класическую и нормализованную схему БД.

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

Насчет ER - мне тоже не очень нравится этот способ описания моделей данных, он кажется громоздким и усилия потраченные на описание не всегда соответствуют результатам (особенно в достаточно сложных схемах и частых изменениях). На мой взгляд более перспективным является Объектно-Ролевое Моделирование (ORM). Ознакомиться с ним можно на www.orm.net.

2Курков Михаил
Если мы говорим об одном и том же, предлагаю чуть
нормализовать Вашу структуру.

В принципе, свойства объекта могут быть добавлены "на ходу"
без изменения общей структуры.

Таким образом, в простейшем случае возникают след таблицы

Список_своств(id int Primary key, ...)
Описание_Объекта(id int Primary key, ...)
Свойства_Объекта(id int Primary key,
parent int references Описание_Объекта,
child int references Свойства_Объекта...)

Как я уже писал, эта схема весьма эффективна (она у нас появилась
лет 5 назад и активно развивается)...

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