[attachment 36534 _SQL.ZIP][attachment 36535 diagramma_20230410.jpg]Коллеги, приветствую!

Нужны советы и поправки в проектируемую базу.
В приложении набросал структуру таблиц и INSERTы для каждой.
Пока стоят такие вопросы.

1) Надо как-то прикрутить понятие Роль (например: Учитель, Родитель, РаботникСтоловой ). Известно, что при замене болеющего Учителя -
его функции выполняет другой. Тут можно допустить, что все замены заранее известны, у каждого какие-то три определенных класса. Учитель вводит пароль, привязанный к определенному классу.

Структура, видимо, такая:
ID - идентификатор записи
ID_CLASS - идентификатор класса
ID_TEACHER - идентификатор учителя
(и вкуда роль привязать?)


2) Посмотрите журнал питания (journal) и его связь с календарем (это по неделям, я его сам составил на 2023 год. )
Если криво/неправильно/негибко - значит видите, как лучше. Буду рад заценить.

У тебя сам подход не вполне корректен. Ты уже привязал "роли" к структуре данных. Надо более абстрактно данные организовать

- Персоны - ФИО, адреса, телефоны
- Роли - Ученик, Учитель, Родитель, Работник Столовой
- Ученики - те персоны, которые имеют роль "Ученика"
- Учителя - те персоны, которые имеют роль "Учителя"

При такой структуре, одна и та же "персона" может иметь несколько ролей. Нет жесткой привязки к таблице "учителей" при выборе заместителя. Вполне можно, например, "ученика" указать как выполняющего роль "учителя".

[attachment 36542 testdb-public_002.png]

Пароль вводится Родителем для своего сына/дочери или Учителем для управления классом. Да, у Учителя может быть несколько классов - это учитываем в таблице GRANTS.

А по Журналу питания есть замечания/предложения?

И как лучше учесть факт посещения учеником (да и остальными персонами, кроме родителей) завтрака и обеда? Может прям в таблице PERSONS добавить 2 логических поля IS_BRFST и IS_DINNER?





Исправлено 1 раз(а). Последнее : sphinx, 15.04.23 07:00

Ты делаешь слишком жесткую структуру. Может быть, для твоей задачи этого достаточно, но я бы делал более гибко


1. Связь "персон" и "ролей" - через таблицу-посредник, чтобы реализовать связь вида много-ко-многим.

Идея в том, что одна и та же "персона" одновременно может выполнять много ролей. Можно оставить прямую ссылку на роль в таблице персон, но рассматривать ее как некую "роль по умолчанию".

Ну, например, особо продвинутый ученик может на время замещать учителя. Для этого, в таблице посреднике создаешь 2 записи для этой персоны. Одна для роли ученика, другая для роли учителя


2. Таблица "персон" - это информация, не связанная с выполнением каких-то обязанностей или действий. Т.е. не надо в нее добавлять информацию о классе/учителе/обеде. Эта информация должна быть вынесена в отдельные таблицы.

Ну, например, в отношении привязки к классам - это таблица-посредник между таблицей "класс" и таблицей "персона".

Во-первых, получаешь возможность указывать одного учителя у нескольких классов, а, во-вторых, можно хранить историю, когда ученик перешел из одного класса в другой. Как ты планируешь смотреть, где ученик учился в прошлом году? А за все 11 лет учебы?

То же самое по посещению чего-либо. Связь много-ко-многим. Есть "что-либо" (завтрак, обед, урок, класс), есть таблица "персон" и есть таблица связи между "чем-либо" и "персоной". В таблицу связи можно добавить разные поля. Например, время посещения с..по..


3. Журнал питания - это просто "частный случай".

Т.е. создается таблица "график питания"

- Тип (Завтрак, Обед)
- Дата
- Время
- Ссылка на меню (если нужно)

Этому графику надо поставить в соответствие "персоны". Как? Снова через таблицу-посредника. Опять же, получаешь возможность видеть историю посещений


PS: Хотя, может, это у меня уже "проф.деформация" связанная с конкретным приложением, в котором я сейчас работаю. Там множество связей вида много-ко-многим. Но, возможно, в твоей задачи такая гибкость не нужна и достаточно будет связей вида один-ко-многим

Замечания и предложения вполне конструктивны. Но Вы правы, очень бы не хотелось усложнять структуру, времени на написание немного, это бы успеть.
Может что-то еще успеем поменять, а что-то оставим. Про перевод из класса в класс я думал (но я считал по одной параллели, типа из-за неуспеваемости перевели в соседний класс). Переход с сентября в следующий класс - не продумывал, но решил бы через отдельный функционал, он нужен раз в год, и переход явно не ручной, а массовый - сразу по всем по классам. И тут тоже не все просто, по идее нужна таблица перехода, например, - из 8В в 9А (это я так переходил, даже сразу в 10А). А вот эту таблицу должен составить, видимо, Администратор (Завуч, Директор. КтоТоЕще).

Спасибо, Владимир!

Владимир Максимов
PS: Хотя, может, это у меня уже "проф.деформация" связанная с конкретным приложением, в котором я сейчас работаю. Там множество связей вида много-ко-многим.

Не наговаривая на себя

Всё правильно, лучше "День потратить и за час долететь" (с) чем потом долго мучиться с "кривой" архитектурой.