|
Действия ...
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
10.06.2004, 16:59
|
|||
|---|---|---|---|
|
|||
Identifying relationship |
|||
|
#18+
Подскажите плизз почему при создании сабжа, в child таблицу переносятся все FK parent таблицы ?. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
10.06.2004, 17:03
|
|||
|---|---|---|---|
Identifying relationship |
|||
|
#18+
Может PK ? и где это происходит ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
10.06.2004, 17:36
|
|||
|---|---|---|---|
|
|||
Identifying relationship |
|||
|
#18+
Среда ERWin Есть три сущности: E/1(PK:E1_ID) E/2(PK:E2_ID) E/3(PK:E3_ID) Создаю identify relationship - E/1 -* E/2, в E/2 получается E/2(PK:E2_ID, FK:E1_ID). Создаю identify relationship - E/2 -* E/3, в E/3 получается E/3(PK:E3_ID, FK:E2_ID, FK:E1_ID). Интересует зачем FK:E1_ID в E/3 ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
10.06.2004, 18:07
|
|||
|---|---|---|---|
|
|||
Identifying relationship |
|||
|
#18+
ИМХО Identify Relationship, в отличие от Non-Identify , добавляет поле в первичный ключ сущности. Соответственно, в E/3 уже переносятся все поля первичного ключа из E/2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.06.2004, 00:06
|
|||
|---|---|---|---|
|
|||
Identifying relationship |
|||
|
#18+
Identifying relationship - это когда первичный ключ сущности полностью мигрирует в дочернюю сущность. После создания первой идентифицирующей связи ПК первой сущности мигрировал во вторую. Стало быть, первичный ключ во второй стал составным. Теперь куда бы Вы не делали идентифицирующую связь из второй сущности, её ПК будет целиком мигрировать в дочерние сущности. Совершенно нормальное явление. Создаю identify relationship - E/1 -* E/2, в E/2 получается E/2(PK:E2_ID, FK:E1_ID). Я думаю, что FK:E1_ID, он ещё и часть PK при этом. Оба над чертой, правильно? Значит ПК - составной. Думаю, чтение стандарта всё объяснит. Или доки по ERWin почитайте. Там тоже про это пишут. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.06.2004, 03:12
|
|||
|---|---|---|---|
Identifying relationship |
|||
|
#18+
Идентифицирующая связь говорит о том, что для однозначной идентификации подчиненного detail-объекта требуется идентификатор master-объекта. В результате, идентификатор master-объекта мигрирует в primary key detail-объекта. В противном случае, связь считается неидентифицирующей, так как она является лишь ограничением, которое накладывается на допустимые значения некоторого(ых) атрибута(ов) объекта. Типичным примером идентифицирующей связи является связь типа "Документ_имеет_Позиция документа" между соответствующими таблицами. Если бы идентификатор(ключ) из таблицы Документ не мигрировал в таблицу Позиция документа, то невозможно было бы определить, какому документу принадлежит позиция, или, наоборот, какие позиции принадлежат документу. Примером неидентифицирующей связи может служить связь типа "Документ_связан_Партнер". Таблица партнеров не определяет документ, а всего лишь описывает допустимые значения атрибута "Партнер" в таблице "Документ". Несколько утрированно, но надеюсь понятнее :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=32&tablet=1&tid=1546423]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
56ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 342ms |
| 0 / 0 |
