ER модель

← →
Рулон Обоев © (2004-02-26 23:37) [0]

может ли в E-R модели быть более одной связи между двумя объектами?

← →
kaif © (2004-02-27 00:52) [1]

Мне кажется, что в одну сторону может быть лишь одна связь. Таким образом две связи возможны только если они направлены встречно. А иначе две связи (в одну сторону) означают , что имеется 2 внешних ключа, указывающих на один и тот же объект, что с точки зрения нормализации, ИМХО, неправильно.
Хотя черт его знает... Но у меня нет таких задач. где это имело бы смысл. Возможно потому что я всегда использую суррогатные ключи в качестве первичных и ссылки (внешние ключи) организую только по ним.

← →
Nikolay M. © (2004-02-27 09:35) [2]

> может ли в E-R модели быть более одной связи между двумя
> объектами?

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

← →
Johnmen © (2004-02-27 09:42) [3]

Пример двух связей в одну сторону:
В таблице заказов указывается человек, который оформил заказ, и человек, который скомплектовал. Причем, это м.б. один и тот же. Человеки берутся из таблицы человеков.
:)

← →
Соловьев © (2004-02-27 09:49) [4]

или дерево

← →
VLAD-MAL (2004-02-27 12:14) [5]

Или в счете - 1.клиент-заказчик 2.клиент-плательщик

← →
Рулон Обоев © (2004-02-27 16:51) [6]

спасибо, вроде разобрался. впереди реляционная алгебра - ждите вопросов =)

← →
Курдль © (2004-02-27 16:59) [7]

Для этой цели есть даже специальная сущность, называемая "ассоциация".

← →
kaif © (2004-02-28 02:31) [8]

Johnmen © (27.02.04 09:42) [3]
Пример двух связей в одну сторону:
В таблице заказов указывается человек, который оформил заказ, и человек, который скомплектовал. Причем, это м.б. один и тот же. Человеки берутся из таблицы человеков.
:)
Хороший пример. Признаюсь, был неправ. У меня есть такие связи.

2 Nikolay M. © (27.02.04 09:35) [2]
Ваш пример с резидентами и нерезидентами мне кажется сомнительным. Я нахожу, что это пример недостаточной нормализации. Можно разделить сущности резидентов и нерезидентов и не хранить в одной таблице их всех скопом. И тогда будет по одной связи от каждой таблицы.

> Ваш пример с резидентами и нерезидентами мне кажется сомнительным.
> Я нахожу, что это пример недостаточной нормализации. Можно
> разделить сущности резидентов и нерезидентов и не хранить
> в одной таблице их всех скопом.

Этот пример всего лишь абстракция. А вот разделять клиентов на резов и нерезов - крайне нерациональное занятие. Как потом клиентов по заказам вытягивать? Запросы к разным таблицам строить в зависимости от его типа? Увольте...
И вообще, немного офф: я в последнее время наблюдаю тенденденцию сводить практически все справочники (города, клиенты, товары и тд) всего в 2-3 таблицы. Например, в главной таблице - названия (полное, краткое и на англ. языке) конкретного экземпляра некоторой сущности, а другие, вспомогательные таблицы раскрывают ее по различным атрибутам, присущим этой сущности: телефонный код города, номер паспорта, цена товара... Большой плюс от такого подхода в том, что пользователь может сам расширять характеристики каждой сущности, заводить новые сущности, классифицировать их в любом, удобном для него виде, а не бежать каждый раз к программисту с просьбой добавить к характериситкам клиента юр. адрес. Минус, конечно, в раздутости такого "справочника".

2 Nikolay M. © (28.02.04 15:08) [9]
У меня есть строго нормальное решение для таких справочников. Так называемые справочники с наследованием атрибутов. Общие атрибуты хранятся в одной таблице. Если какой-то класс-наследник (например, нерезиденты) обладает дополнительным атрибутом (атрибутами), то этот атрибут (атрибуты) хранится (хранятся) в отдельной таблице. В этом случае каждый нерезидент имеет 2 вхождения - одно в таблицу "клиенты", а другой - в таблицу "нерезиденты".

ER модель Найти похожие ветки