|
|
|
Как правильно спроектировать связи в БД?
|
|||
|---|---|---|---|
|
#18+
Доброе время суток, нужна ваша помощь, товарищи. В БД есть таблицы Преподаватели, Кафедры и Факультеты. Кафедра относится к конкретному факультету либо к институту в целом (NULL). Требуется выразить: а) закреплённость преподавателей за кафедрами (как правило, преподаватель относится к конкретной кафедре, однако есть единичные прецеденты, когда кафедр может быть несколько, тогда в более общих запросах надо учитывать, в ипостаси представителя какой кафедры выступает преподаватель); б) заведующих кафедр и деканов факультетов (институт не берём). У каждой кафедры 1 заведующий, и у каждого факультета 1 декан, из числа преподавателей этой кафедры\этого факультета. Должности заведующего и декана может совмещать одно лицо (но это не обязательно). Каждый заведующий\декан закреплён, как преподаватель, строго за 1 кафедрой. Можно ли выразить эти отношения так, чтобы невозможно было с одной стороны указать в качестве заведующего\декана преподавателя с посторонней кафедры\факультета, с другой -- нельзя было указать несколько заведующих\деканов для одной кафедры\факультета? Насчёт преподавателей с неоднозначной принадлежностью: я склоняюсь к тому, чтобы закрепить каждого преподавателя за 1 кафедрой, а для нескольких мультоводов завести дублирующиеся записи, но закреплённые за разными кафедрами; по идее это упростит и архитектуру, и различение ипостасей. Или возможно более красивое решение? Если возможно, то какое? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 15:13 |
|
||
|
Как правильно спроектировать связи в БД?
|
|||
|---|---|---|---|
|
#18+
Делать структуру, которая будет железно зажимать такие условия можно, но это представляет интерес больше в академическом плане. Практически удобнее работать с более простой структурой, на которую наложены только базовые ограничения, а соответствие всех ограничениям проверять на этаре ввода/редактирования данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 15:37 |
|
||
|
Как правильно спроектировать связи в БД?
|
|||
|---|---|---|---|
|
#18+
Эдуард Л.Доброе время суток, нужна ваша помощь, товарищи. В БД есть таблицы Преподаватели, Кафедры и Факультеты. Кафедра относится к конкретному факультету либо к институту в целом (NULL). Требуется выразить: а) закреплённость преподавателей за кафедрами (как правило, преподаватель относится к конкретной кафедре, однако есть единичные прецеденты, когда кафедр может быть несколько, тогда в более общих запросах надо учитывать, в ипостаси представителя какой кафедры выступает преподаватель); б) заведующих кафедр и деканов факультетов (институт не берём). У каждой кафедры 1 заведующий, и у каждого факультета 1 декан, из числа преподавателей этой кафедры\этого факультета. Должности заведующего и декана может совмещать одно лицо (но это не обязательно). Каждый заведующий\декан закреплён, как преподаватель, строго за 1 кафедрой. Можно ли выразить эти отношения так, чтобы невозможно было с одной стороны указать в качестве заведующего\декана преподавателя с посторонней кафедры\факультета, с другой -- нельзя было указать несколько заведующих\деканов для одной кафедры\факультета? Насчёт преподавателей с неоднозначной принадлежностью: я склоняюсь к тому, чтобы закрепить каждого преподавателя за 1 кафедрой, а для нескольких мультоводов завести дублирующиеся записи, но закреплённые за разными кафедрами; по идее это упростит и архитектуру, и различение ипостасей. Или возможно более красивое решение? Если возможно, то какое? Отношение Факультет:Кафедра 1:M Отношение Кафедра:Преподаватель N:M Отношение Факультет:Декан 1:1 Отношение Кафедра:Заведующий 1:1 Декан кстати может и не быть преподавателем. ;-) А вообще нужно заводить новую сущность "штатное расписание". И привязывать "людей" к "штатному расписанию" А штатное расписание к уже привязывать к "Факультетам" и "Кафедрам" Грубо говоря, например. Штатная единица декан (1 шт) Штатная единица заведующий кафедрой (1 шт) Штатная единица старший преподаватель (2 шт) Штатная единица профессор кафедры (1 шт) Штатная единица преподаватель (3 шт) Штатная единица ассистент (2 шт) От этого уже дальше выводить все остальное. Не забыть "дробность" штатных единиц 0.5, 0.75, 1.0, 1.25, 1.5 (обычно это все типы штатных единиц) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 15:50 |
|
||
|
Как правильно спроектировать связи в БД?
|
|||
|---|---|---|---|
|
#18+
Эдуард Л.Можно ли выразить эти отношения так, чтобы ... Можно. Хотя последнее требование - про отсутствие совмещений у заведующего/декана - не только нелепо по смыслу, но и выражается довольно извратно. Если у Вас стоит задача просто разработать некоторую курсовую, то стоит понять следующую вещь: на уровень схемы данных следует выносить наиболее "врождённые", железобетонные требования. В то же время довольно многие требования бизнес-логики относятся к "мелким реалиям сегодняшнего дня". Завтра они изменятся, и переделывать схему данных будет очень неудобно. Такие вещи стоит решать адекватно мелкими и отдельными средствами, в частности, проверками в коде ввода данных. Эдуард Л.Насчёт преподавателей с неоднозначной принадлежностью: я склоняюсь к тому, чтобы закрепить каждого преподавателя за 1 кафедрой, а для нескольких мультоводов завести дублирующиеся записи, Тут есть забавный момент. В том виде, в котором Вы это сформулировали, это совершенно неправильно и ведёт к куче проблем. Хотя правильное решение почти ничем не отличается. Просто дублирующиеся записи означают постоянные проблемы в бизнес-логике. Ну например, при увольнении есть все шансы "недоуволить" совместителя или напротив, уволить заодно его полного тёзку. Вам нужна сущность "преподаватели", связанная с кафедрами отношением многие ко многим. Различение ипостасей при этом несложно сделать, ссылаясь на связь преподаватель-кафедра. но закреплённые за разными кафедрами; по идее это упростит и архитектуру, и различение ипостасей. Или возможно более красивое решение? Если возможно, то какое?[/quote] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 16:04 |
|
||
|
Как правильно спроектировать связи в БД?
|
|||
|---|---|---|---|
|
#18+
Спасибо ответившим. Даже если это непрактично, хотелось бы знать способ решения. Потому что пока я даже вообразить себе не могу, как добиться такого результата. mad_nazgul Именно так (без штатного расписания) сейчас и сделано. Однако остаётся возможность добавить в заведующие\деканы людей "со стороны"; идея со штатным расписанием интересная, возьму её на заметку, однако указанной проблемы она не решает. То же самое будет, если всех заведующих\деканов перечислить в отдельных таблицах. Другой вариант - добавить в сущность Преподаватель логические поля "заведующий" и "декан", т.о. если, например, поле "заведующий" установлено в "истину", по принадлежности преподавателя к кафедре можно определить, что он - её заведующий, то же самое - с деканом и факультетом. Возможность назначить чужака таким образом исключается, зато появляется возможность заводить произвольное количество заведующих\деканов на одной кафедре\факультете. Спасибо за замечание насчёт декана, по моим условиям он обязательно - преподаватель. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 16:24 |
|
||
|
Как правильно спроектировать связи в БД?
|
|||
|---|---|---|---|
|
#18+
mad_nazgulДекан кстати может и не быть преподавателем. Преподаватель - это вообще не есть разумный термин в рамках предметной области. Есть сотрудники (в том числе, заметим, внештатные), есть учебные курсы, есть связь сотрудников с курсами (причём один курс могут читать несколько человек). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 16:33 |
|
||
|
Как правильно спроектировать связи в БД?
|
|||
|---|---|---|---|
|
#18+
softwarermad_nazgulДекан кстати может и не быть преподавателем. Преподаватель - это вообще не есть разумный термин в рамках предметной области. Есть сотрудники (в том числе, заметим, внештатные), есть учебные курсы, есть связь сотрудников с курсами (причём один курс могут читать несколько человек). Под преподавателем я понимаю сотрудника у которого есть учебные часы. Он быть как штатным, так и вне штатным. Я согласен с вами, что в рамках предметной области нужно ввести еще курсы. Но это потянет за собой учебный план и прочие вещи связанные с часами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2014, 07:27 |
|
||
|
Как правильно спроектировать связи в БД?
|
|||
|---|---|---|---|
|
#18+
Эдуард Л. Потому что пока я даже вообразить себе не могу, как добиться такого результата. Судя по форуму, у студентов затруднения обычно со связью N:M Это отдельная табличка с двумя колонками: -id преподавателя -id кафедры ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2014, 10:15 |
|
||
|
Как правильно спроектировать связи в БД?
|
|||
|---|---|---|---|
|
#18+
DirksDRСудя по форуму, у студентов затруднения обычно со связью N:M Это отдельная табличка с двумя колонками: -id преподавателя -id кафедры Думаю, затруднение это вызвано тем, что абстрактная учебная формулировка "связано" неприменима в реальной жизни. На практике эта "связанность" преподавателя с кафедрой является частью более сложных сущностей, одной или даже нескольких. Например, преподаватель может быть "связан" с кафедрой преподаванием каких-то часов. Тогда запись о связанности - часть учебного плана (преподаватель, кафедра, предмет, тип занятия, детали расписания...). И независимо от этого, преподаватель может работать на кафедре независимо от преподавания, например, как заведующий ею, или материально ответственый кладовщик. Тогда запись о связанности - часть штатного расписания (преподаватель, кафедра, должность...). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2014, 11:05 |
|
||
|
Как правильно спроектировать связи в БД?
|
|||
|---|---|---|---|
|
#18+
[quot Эдуард Л.]Доброе время суток, нужна ваша помощь, товарищи. В БД есть таблицы Преподаватели, Кафедры и Факультеты. Кафедра относится к конкретному факультету либо к институту в целом (NULL). Требуется выразить: а) закреплённость преподавателей за кафедрами (как правило, преподаватель относится к конкретной кафедре, однако есть единичные прецеденты, когда кафедр может быть несколько, тогда в более общих запросах надо учитывать, в ипостаси представителя какой кафедры выступает преподаватель); б) заведующих кафедр и деканов факультетов (институт не берём). У каждой кафедры 1 заведующий, и у каждого факультета 1 декан, из числа преподавателей этой кафедры\этого факультета. Должности заведующего и декана может совмещать одно лицо (но это не обязательно). Каждый заведующий\декан закреплён, как преподаватель, строго за 1 кафедрой. вообще не понятно в чем проблемы. все делается, все можно. Можно ли выразить эти отношения так, чтобы невозможно было с одной стороны указать в качестве заведующего\декана преподавателя с посторонней кафедры\факультета, с другой -- нельзя было указать несколько заведующих\деканов для одной кафедры\факультета? Насчёт преподавателей с неоднозначной принадлежностью: я склоняюсь к тому, чтобы закрепить каждого преподавателя за 1 кафедрой, а для нескольких мультоводов завести дублирующиеся записи, но закреплённые за разными кафедрами; по идее это упростит и архитектуру, и различение ипостасей. Или возможно более красивое решение? Если возможно, то какое? да, есть, нужно просто сделать возможность преподавателю работать на нескольких кафедрах. твоя идея — бред. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2014, 13:03 |
|
||
|
Как правильно спроектировать связи в БД?
|
|||
|---|---|---|---|
|
#18+
Эдуард Л.Кафедра относится к конкретному факультету либо к институту в целом (NULL). Постановщика сослать на галеры. Кафедра является подразделением факультета, или института, и так и должна быть представлена в иерархии. Но значение имеет, с кем у человека договор. Факультет нанимает или институт? Вообще если это и правда курсовая, то делайте как-нибудь - идеальное решение с точки зрения преподавателя вряд ли вы угадаете, умнее его точно быть не стоит, практические нюансы обсуждать вообще лениво. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2014, 17:40 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38686958&tid=1540837]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
7ms |
check topic access: |
7ms |
track hit: |
54ms |
get topic data: |
78ms |
get forum data: |
3ms |
get page messages: |
126ms |
get tp. blocked users: |
2ms |
| others: | 10ms |
| total: | 308ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...