|
Разрешить связь многие ко многим
|
||
|---|---|---|
Участник
Откуда: Нижний Новгород
Сообщения: 1 802 |
||
| 24.04.2007, 15:13 |
|
|
|
|
|
Разрешить связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
Пожалуйста, посмотрите вопрос: http://www.sql.ru/forum/actualthread.aspx?tid=419905 Он на форуме Оракла. Думал решу, но пока что не получилось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2007, 10:02 |
|
||
|
Разрешить связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
Я бы начал с сущностей (ключи подчеркнуты): Специализация ( Преподаватель, Предмет ). Занятие ( Время, Аудитория , Предмет) Преподаватель_на_занятии ( Время, Преподаватель , Аудитория) Теперь нужно обеспечить правила: (1)Преподаватели могут проводить занятия по разным предметам -- видимо в пределах своей специализации? (2)Необходимо исключить возможность проведения разных занятий в одно время в одной аудитории. (3)Необходимо исключить возможность того, что один преподаватель проводит занятия в одно время в разных аудиториях. У занятия пока не обнужено иных ключей кроме Время, Аудитория - (2) выполняется автоматичеки. Далее зависит от того, какими средствами разрешается пользоваться для обеспечения правил. Например в ORACLE можно создать materialized view на предопределенных таблицах с нужными ограничениями. З.Ы. Похожий пример разбирает Дейт в своей самой известной книге. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2007, 15:13 |
|
||
|
Разрешить связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
Стандартная timetable задача. В лоб как-то так: classroom (); teacher (); course (); lecture ( rel_course); -- или использовать n:m, если необходимо (например, одна лекция читается для нескольких курсов); lecture_teacher ( rel_lecture, rel_teacher); timetable ( rel_lecture, rel_classroom, time_start, time_end); Constraints пишите в зависимости от приоритетов расписания, рассматривая интервал [time_start, time_end]. Остальные сущности (факультеты, кафедры, специализации, продолжительность курсов, семестры, типы занятий, группы, студенты, посещаемость и пр.) - в зависимости от задачи. > З.Ы. Похожий пример разбирает Дейт в своей самой известной книге. Ссылкой не поделитесь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2007, 15:31 |
|
||
|
Разрешить связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
На всякий случай: разумеется, у всех таблиц суррогатные ключи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2007, 15:33 |
|
||
|
Разрешить связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
ModelRЗанятие (Время, Аудитория, Предмет) Преподаватель_на_занятии (Время, Преподаватель, Аудитория) Спасибо, за помощь. В принципе у меня так и сделано. Посмотрите мой первый пост по ссылке. teached_subject – занятие lecture – преподаватель на занятие Время у меня состоит из 3-х частей: номер пары, день, признак недели (четная/нечетная). Только эти таблицы у меня связаны, время в «преподаватель на занятие» внешний ключ на «занятие». Я так сделал, чтобы нельзя было назначить преподавателю время, в которое нет занятий. Вопрос получился в том, что изменение «занятия» это изменение первичного ключа, что не очень приветствуется. Да и это требует каскадного обновления «преподавателя на занятия», что в Оракле стандартными средствами не делается. И ключи составные получаются, тоже не очень красиво. Но, похоже, это единственный способ выполнить требования уникальности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2007, 22:47 |
|
||
|
Разрешить связь многие ко многим
|
|||
|---|---|---|---|
|
#18+
Wasup!Только эти таблицы у меня связаны, время в «преподаватель на занятие» внешний ключ на «занятие». Я так сделал, чтобы нельзя было назначить преподавателю время, в которое нет занятий.В «занятие» первичный ключ (Время, Аудитория). Соответственно и ВК из «преподаватель на занятие» включает оба атрибута - нельзя вести не существующее занятие. Wasup!Вопрос получился в том, что изменение «занятия» это изменение первичного ключа, что не очень приветствуется. Да и это требует каскадного обновления «преподавателя на занятия», что в Оракле стандартными средствами не делается. И ключи составные получаются, тоже не очень красиво. Но, похоже, это единственный способ выполнить требования уникальности.Дык "многия знания - многия печали". Детально описывая связи данных, естественные ключи обременяют приложение необходимостью отслеживать эти связи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2007, 14:58 |
|
||
|
|
start [/forum/topic.php?fid=32&tid=1544566]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
25ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
33ms |
get tp. blocked users: |
1ms |
| others: | 233ms |
| total: | 331ms |
| 0 / 0 |
