|
|
|
Помогите плииз найти ошибки проектирования...
|
|||
|---|---|---|---|
|
#18+
sevenaХорошо давайте будем решать вопросы с простых вещей и в понятных обозначениях : Цунами это BASE RELATION TSUNAMI (TSU_ID#, ... DAMAGE_ID#) PRIMARY KEY (TSU_ID#) FOREIGN KEY (DAMAGE_ID#) REFERENCES DAMAGE Разрушения это BASE RELATION DAMAGE (DAMAGE_ID#, ... TSU_ID#) PRIMARY KEY (DAMAGE_ID#) FOREIGN KEY (TSU_ID#) REFERENCES TSUNAMI Получилась нехорошая циклическая связь! Как этого избежать? Можно добавить просто поля DAMAGE к TSUNAMI и считать, что как раз эти поля и есть наиболее достоверные характеристики разрушения для данного цунами - это будет верным? 2 ModelR : Поймите правильно - есть различные Разрушения соответствующие одному Цунами . Но среди этих Разрушений выделяется одно - наиболее достоверное для данного Цунами , причем это достоверное не может соответствовать другому Цунами . Вот спрашивается как это корректно сделать? Один вариант я предложил - вот только верен ли он на ваш взгляд? :) Зачем делать циклическую ссылку?! Хватит и одной ссылки из ЦУНАМИ в РАЗРУШЕНИЯ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2006, 09:42 |
|
||
|
Помогите плииз найти ошибки проектирования...
|
|||
|---|---|---|---|
|
#18+
Хорошо - с этим понятно - правда база данных в Аксессе - не совсем понятно, как это можно там реализовать. Но это в вопрос на другую тему. :) Теперь, как вы думаете быть с ссылками на публикации??? Ситация на данный момент такова : ЦУНАМИ BASE RELATION TSUNAMI (TSU_ID#, ... BIBLIO1_ID#, BILBLIO2_ID#, BILBLIO2_ID#...) PRIMARY KEY (TSU_ID#) FOREIGN KEY (BIBLIO1_ID#, BIBLIO2_ID#, BIBLIO3_ID# ...) REFERENCES BIBLIO NULLS ALLOWED Публикации BASE RELATION BIBLIO(BIB_ID#, ... ) PRIMARY KEY (BIB_ID#) Исправим же ее следующим образом : ЦУНАМИ BASE RELATION TSUNAMI (TSU_ID#, ... BIBLINK_ID#) PRIMARY KEY (TSU_ID#) FOREIGN KEY (BIBLINK_ID#) REFERENCES BIBLINKS ССЫЛКИ BASE RELATION BIBLINKS (BIBLINK_ID#, TYPEOFLINK, TSU_ID#, BIBLIO_ID#) PRIMARY KEY (BIBLINK_ID#) FOREIGN KEY (TSU_ID#) REFERENCES TSUNAMI (BIBLIO_ID#) REFERENCES BIBLIO где TYPEOFLINK как раз и показывает что это за ссылка (RI, Rm и тд и тп ...) Как на ваш взгляд - это верно? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2006, 11:44 |
|
||
|
Помогите плииз найти ошибки проектирования...
|
|||
|---|---|---|---|
|
#18+
sevenaХорошо - с этим понятно - правда база данных в Аксессе - не совсем понятно, как это можно там реализовать. Но это в вопрос на другую тему. :) Теперь, как вы думаете быть с ссылками на публикации??? Ситация на данный момент такова : ЦУНАМИ BASE RELATION TSUNAMI (TSU_ID#, ... BIBLIO1_ID#, BILBLIO2_ID#, BILBLIO2_ID#...) PRIMARY KEY (TSU_ID#) FOREIGN KEY (BIBLIO1_ID#, BIBLIO2_ID#, BIBLIO3_ID# ...) REFERENCES BIBLIO NULLS ALLOWED Публикации BASE RELATION BIBLIO(BIB_ID#, ... ) PRIMARY KEY (BIB_ID#) Исправим же ее следующим образом : ЦУНАМИ BASE RELATION TSUNAMI (TSU_ID#, ... BIBLINK_ID#) PRIMARY KEY (TSU_ID#) FOREIGN KEY (BIBLINK_ID#) REFERENCES BIBLINKS ССЫЛКИ BASE RELATION BIBLINKS (BIBLINK_ID#, TYPEOFLINK, TSU_ID#, BIBLIO_ID#) PRIMARY KEY (BIBLINK_ID#) FOREIGN KEY (TSU_ID#) REFERENCES TSUNAMI (BIBLIO_ID#) REFERENCES BIBLIO где TYPEOFLINK как раз и показывает что это за ссылка (RI, Rm и тд и тп ...) Как на ваш взгляд - это верно? :) Слушайте, Вы про нормализацию слышали? А про функциональные зависимости? Про универсальное отношение? Так вот. По собранным данным составьте универсальное отношение, выделите функциональные зависимости и проведите нормализацию. И только после этого задавайте вопросы... А то просто неприятно смотреть на ЦУНАМИ BASE RELATION TSUNAMI (TSU_ID#, ... BIBLIO1_ID#, BILBLIO2_ID#, BILBLIO2_ID#...) PRIMARY KEY (TSU_ID#) FOREIGN KEY (BIBLIO1_ID#, BIBLIO2_ID#, BIBLIO3_ID# ...) REFERENCES BIBLIO NULLS ALLOWED Публикации BASE RELATION BIBLIO(BIB_ID#, ... ) PRIMARY KEY (BIB_ID#) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2006, 12:08 |
|
||
|
Помогите плииз найти ошибки проектирования...
|
|||
|---|---|---|---|
|
#18+
To gardenman: Но вот объясните, чем плохо id в каждой таблице??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2006, 18:53 |
|
||
|
Помогите плииз найти ошибки проектирования...
|
|||
|---|---|---|---|
|
#18+
Не зарег.Но вот объясните, чем плохо id в каждой таблице??? Отсутствием гемороя при работе с БД ;))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2006, 11:26 |
|
||
|
Помогите плииз найти ошибки проектирования...
|
|||
|---|---|---|---|
|
#18+
sevena Исправим же ее следующим образом : Гораздо лучше. Насчет типа ссылки в БИБЛИНК. Раз их, атрибутов, теперь трое, то проверьте, нет ли функциональных зависимостей, запрещающих дублирование: ЦУНАМИ + БИБЛИО -> ТИП ЦУНАМИ + ТИП -> БИБЛИО От последнего очевидно также зависит, как (и нужно ли вообще) ссылаться из таблиц данных (ЦУНАМИ, ВЫСОТА) на БИБЛИНК для указания источника сведений. Если нужно, то возникает интересная проблема контроля целостности. Нужно контролировать что имя поля, имя таблицы соответсвуют значению поля из другой таблицы. Т.е. ЦУНАМИ.ИСТОЧНИК_RMI_ИД должен ссылаться на БИБЛИНК, такой, что БИБЛИНК.ТИП ='RMI'. Некоторые советуют ввести константное поле в ЦУНАМИ.ИСТОЧНИК_RMI_ТИП =='RMI' и реализовать обычным ФК, однако ИМХО это перебор. Лучше триггерами. Но это чисто ИМХО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2006, 13:05 |
|
||
|
|

start [/forum/topic.php?fid=32&startmsg=33607123&tid=1545357]: |
0ms |
get settings: |
5ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
159ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 186ms |
| total: | 435ms |

| 0 / 0 |
