|
|
|
Синхронизация лог. и физ. моделей в PoswrDesigner 12
|
|||
|---|---|---|---|
|
#18+
Привет всем. Есть следующая схема. Таблица Account содержит данные идентификации пользователей. Часть пользователей является сотрудниками, и для хранения специфичной информации о них имеется таблица Employee. Каждый сотрудник должен иметь свой account (один и только один), но не всякий account относится к сотруднику. Есть ещё, например, таблица Customer, аналогичного (в данном контексте) с Employee назначения. Построена логическая модель, где Account и Employee соединены так Account to Employee сardinality: 0,1 Employee to Account сardinality: 1,1 То же самое и с Customer. После перехода к физической модели (SQL2005) обнаруживается, что для пары Account - Employee построено два противоположно направленных внешних ключа, причём поле EmployeeId, появившееся в таблице Account, обязательное(!), что противоречит указанной в лог. модели мощности связи. И с Customer та же история. При таком подходе получается, что каждая запись в Account должна быть связана и с сотрудником и с заказчиком. С другой стороны, не обеспечивается уникальность индекса по AccountId, то есть можно с одним account'ом связать много сотрудников. Но это опять противоречи указанной мощности. Короче говоря, не совсем понятно как PD использует мощность связи при переходе к физ. модели. Хотелось бы добиться следующего результата. В физ. модели должен появиться только один внешний ключ в таблице Employee. Обязательный, с ограничением уникальности. Как этого добиться? Модели прилагаются. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 12:40 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=34669797&tid=1544401]: |
0ms |
get settings: |
9ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
170ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
19ms |
get tp. blocked users: |
1ms |
| others: | 227ms |
| total: | 449ms |

| 0 / 0 |
