Есть два подхода по Кнуту и по Дейту.
1. Создать до поля кортежи для кураторов/принимающих.
2. Создать 2 сущности мапинга : Кураторы и Принимающие. Каждая со своим id и внешним ключом для преподавателя.
Я всегда предпочитал второй: он естественный, его проще модифицировать и он стремиться к первой нормальной форме, а абстракции не протекают.
2ой вариант прямо как у меня на пикче?
Upd studentid В проекте не нужен.
Да.
Допустим завтра тебе скажут, что членом комиссии может быть другой студент, тогда все что тебе нужно будет сделать, это добавить одно поле признак в Сущность Принимающего.
Спасибо огромное.
у тебя есть объекты, какие-то люди. иногда можно считать, что объекты разные, несмотря на то что люди, например что преподы и ученики не пересекаются, поэтому ты берешь одинаковых в целом людей, но суешь в две таблицы.
а еще у тебя есть отношения прямо вот в том смысле, про подмножество декартового произведения, и вот некоторые люди у тебя бывают в некоторых отношениях. и под эти отношения ты заводишь отдельные таблицы, и тебе норм.
бесполезные таблицы в одну колонку бесполезны, можешь ссылаться куда надо сразу. будет понятно что куратор это такой препод. а под звездочку проверяющих связка к преподам еще раз.
В первой ссылке паттерн используется, если поля разные. Для каждого типа своя таблица.
Если поля одинаковые или почти одинаковые, то таблица одна для всех, но указывается тип в столбце. http://design-pattern.ru/patterns/single-table-inheritance.html
При этом наследовании я в потомках храню лишь ссылку на субтаблицу? Например:
В данном случае у меня будет
teacher (int id, String name, Date hiringDate)
и два наследника у которых будет одно поле-ссылка на teacher, верно? (куратор от комиссии полями не отличается) Выходит это single table inheritance?
>куратор от комиссии полями не отличается
lol
STI это когда на всех одна таблица. Там поля всех сущностей плюс поле, в котором указывается тип данных.
У тебя препод может быть всеми сразу или только препод-куратор или препод-комиссия?
он может быть только:
п-куратор, п-комиссия или п-куратор-комиссия.
Именно из-за того, что он может быть и куратором и комиссией одновременно у меня и возник вопрос, как рациональнее сделать разделение.
Можно сделать сущность тичер и роли добавить. В методе, который ставит оценку надо будет проверять является ли препод оценщиком.
Наследование не нужно тогда.
а какие кейсы вообще по этой базе гонять будут? ну т.е. ты сейчас городишь какую-то статику, а транзакции какие нужны?
ну т.е. понятно что никакие, и это упражнение на рисование стрелочек, но вдруг в задании чото есть об этом. или может аналитика какая нужна, какие вообще запросы должны работать по этой схеме
Я так раньше подумал, сразу впихнуть в тичера два поля булевых: является ли куратором и является ли комиссией.
Я в рамках курсача веб приложуху делаю на джаве. Транзакции никакие не нужны. Мне просто нужно сделать простенькую бд и подгружать данные запросами. По сути проект состоит в том, чтобы сделать графический интерфейс для работы с бд.
откровенная поебень
точнее как, поебень с правом на жизнь, на такой поебени видел более чем достаточно, но без необходимости не надо этим заниматься. будет у тебя человек в двух комиссиях, и что.
или куратором в двух проектах. положил FK как в букваре и норм.
Короче, коль у тебя есть люди то запиливай модель "Физическое лицо", суть в том что студент может завтра стать преподом а препод студентом. А так у тебя будет одно ФЛ а дальше уже просто внешние ключи у модели препод, студент, небо, аллах.
Т.е. сделать одну таблицу с людьми выделив общие свойства и создать таблицы наследники в лице студента, неба и аллаха?
а почему в студенте один проект? ты пока учишься у тебя до ебеней проектов. пусть их история по годам в project лежит, сделай связь с проектами m-n
Это дипломный проект. По тз 1:1 студент и проект
okay
Но вопрос в другом:
>препод (teacher) может быть и руководителем (curator) проекта, и проверяющим (comission_member). Как рациональнее всего сделать разделение учителей на кураторов и участников комиссии?
а куратор у проекта или у студента? они конечно 1-1, но все равно интересно.
куратор 1:n проект
они= студенты-проекты
Да
Надо сделать таблицу ролей и связать с тичером многие ко многим. Когда тичер будет что-то делать, то проверять есть ли у него группа для этого действия.
Ну а как быть с
Так делаешь many to many где будут внешние ключи на ФЛ, группу, небо, аллаха.
взять вариант на оппике, выкинуть прокситаблицы левые, и будет норм.
Что такое прокситаблицы?
Кстати идея с моделью ФЛ показала себя на практике. Делал для школы бдшку и спустя пару лет один из учеников внезапно стал родителем и вот в таблице ФЛ одна запись и в связке ученик и родитель по одной.
Я уже понял, что это хорошая модель. В ООП паттерн фабрика точно такую же схему описывает
что-то такое
так чуть лучше
еще можно про lifetime подумать, в каком порядке что появляется, что без чего может быть.
есть студенты без проекта, есть проекты без студента, есть проекты без оценки. у оценки всё обязательное, проект без препода -хз. остальное вообще говоря тоже хз бывает по заданию или нет.
студент без группы наверное нет, группа без студентов вообще говоря да.
обычно такие вещи либо есть в тз, либо если его писать мудила, то надо уточнять у заказчика.
опять же, обычно на практике это по барабану, но если нужна картинка с правильными стрелочками, то стрелочки должны быть правильные.
Спасибо, понял
Это же проект уровня студента 2го курса универа. У меня тз из темы и трёх пунктов-ограничений, ёпту. У нас преподы не особо-то и компетентны. Не у кого помощи спросить. Мой препод вообще предлагал ещё средний бал каждого проекта хранить в таблице. :/
если бы у него было миллион проектов в день, то может быть это начало иметь смысл.
также стоит отметить, что у если студенты-проекты 1-1, то средний балл про проекту равен одной оценке за него.
Каждый проект оценивает 3-5 челов комиссии, оттуда и средний балл
а комиссия как сущность не нужна?
Член комиссии - это роль, как и куратор.
Просто у меня к 1 проекту будет 3 записи от разных челов комиссии с оценкой.
ну, у тебя получается что некие абстрактные члены комиссий прилетают из вакуума и оставляют оценки в журнале. обычно это не так работает. есть каферда, там есть преподы, из них собирается сборище на студентов от преподов этой же кафедры и они друг другу ставят оценки. видимо тебе ничего такого делать не надо, и хорошо.
Вы называете объект сущностью?
А-а, entity object называете сущностью. Охотники за привидениями
Вот, если интересно, задание:
Тема: сдача студентами дипломных проектов.
Объекты: студенты, группы, дипломные проекты, руководители, члены ГЭК.
Для моделирования задачи необходимо хранить следующую информацию:
ФИО студента
№ группы
№ зачетной книжки
Тема дипломного проекта
Итоговая оценка за дипломный проект
ФИО руководителя дипломного проекта
Оценки всех членов ГЭК за дипломный проект
Дополнительные условия:
один студент защищает только одну дипломную работу;
каждую дипломную работу оценивает не менее 3 членов ГЭК;
член ГЭК может одновременно быть руководителем дипломного проекта.
>члены ГЭК
вообще я бы
1. ввел некую ебань под названием коммисия, напихал в них преподов
2. сделал штуку под названием "сдача проекта" и под эту сдачу насовал детьми оценки, от членов комиссии.
и дальше эта схема должна коммутировать, в том плане что тебе оценку ставил чувак, который был в комиссии на сдаче
У меня есть БД "студенты сдают проект".
Основные сущности на пикрилейтед. Только вопрос вот в чём. У меня по ТЗ препод (teacher) может быть и руководителем (curator) проекта, и проверяющим (comission_member). Как рациональнее всего сделать разделение учителей на кураторов и участников комиссии? Обяз ли для этого создавать подсущности, которые будут хранить только айди? Хелп
Куратор просто чел, числящийся в проекте. Участник комиссии ставит оценку проекту: в таблицу project_mark заносится 3-5 оценок от разных челов из комиссии