powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Помогите плииз найти ошибки проектирования...
6 сообщений из 31, страница 2 из 2
Помогите плииз найти ошибки проектирования...
    #33607123
Станислав C.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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 :
Поймите правильно - есть различные Разрушения соответствующие одному Цунами . Но среди этих Разрушений выделяется одно - наиболее достоверное для данного Цунами , причем это достоверное не может соответствовать другому Цунами . Вот спрашивается как это корректно сделать? Один вариант я предложил - вот только верен ли он на ваш взгляд? :)
Зачем делать циклическую ссылку?! Хватит и одной ссылки из ЦУНАМИ в РАЗРУШЕНИЯ...
...
Рейтинг: 0 / 0
Помогите плииз найти ошибки проектирования...
    #33607544
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 и тд и тп ...)
Как на ваш взгляд - это верно? :)
...
Рейтинг: 0 / 0
Помогите плииз найти ошибки проектирования...
    #33607630
Станислав C.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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#)
...
Рейтинг: 0 / 0
Помогите плииз найти ошибки проектирования...
    #33612905
Не зарег.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
To gardenman:

Но вот объясните, чем плохо id в каждой таблице???
...
Рейтинг: 0 / 0
Помогите плииз найти ошибки проектирования...
    #33613833
Estets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не зарег.Но вот объясните, чем плохо id в каждой таблице???
Отсутствием гемороя при работе с БД ;)))
...
Рейтинг: 0 / 0
Помогите плииз найти ошибки проектирования...
    #33614215
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sevena
Исправим же ее следующим образом :
Гораздо лучше.
Насчет типа ссылки в БИБЛИНК. Раз их, атрибутов, теперь трое, то проверьте, нет ли функциональных зависимостей, запрещающих дублирование:
ЦУНАМИ + БИБЛИО -> ТИП
ЦУНАМИ + ТИП -> БИБЛИО

От последнего очевидно также зависит, как (и нужно ли вообще) ссылаться из таблиц данных (ЦУНАМИ, ВЫСОТА) на БИБЛИНК для указания источника сведений.

Если нужно, то возникает интересная проблема контроля целостности. Нужно контролировать что имя поля, имя таблицы соответсвуют значению поля из другой таблицы.
Т.е. ЦУНАМИ.ИСТОЧНИК_RMI_ИД должен ссылаться на БИБЛИНК, такой, что БИБЛИНК.ТИП ='RMI'. Некоторые советуют ввести константное поле в ЦУНАМИ.ИСТОЧНИК_RMI_ТИП =='RMI' и реализовать обычным ФК, однако ИМХО это перебор. Лучше триггерами. Но это чисто ИМХО.
...
Рейтинг: 0 / 0
6 сообщений из 31, страница 2 из 2
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Помогите плииз найти ошибки проектирования...
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]