Михаил89,

не стоит делать ключем таб.студенты номер зачётки,
поле "номер зачётки", конечно нужно, обязательное и с уникальным индексом,
но не ключ
ключ - обычный счётчик

по-поводу этого
ёи, имхо, тоже стоит к этому, "относится" как к документу - "экз./зачётн. ведомость" (шапка - дата, предмет, препод, ...) и строки (студент, оценка)
и этого
ёочень сомнительно, что вам удастся организовать ВСЕ приказы ДАЖЕ с однотипной шапкой документа, не говоря уже о строках (так и не понял - чего сейчас нет)) - первого или второго ... походу первого)
и ограничится только типом
невыдумывайте велик - делайте как "завещал 1с" - общая часть шапки док. (1) - специальная часть док.(1) - строки док (М)
смотрите схему,
но относительно приказов - на схеме сделано, как "если я ошибаюсь"
и вы сможете все приказы (разных типов) сделать унифицированно, все в 2-х таблицах

Михаил89...
почему не стоит делать ключем таб.студенты номер зачётки, а ключ - обычный счётчик

проще будет,
если в нём появятся буквы или ведущие нули - прийдётся переделывать на текст (лучше сразу так и сделать)
Михаил89что еще посоветуете?

забыл в прошлый раз - в таб.семестры - нужен ещё номер семестра
{id, year, semestr}, semestr(byte) = {1,2}

ну и я там ранее уже упоминал,
очень не помешает таб.УчебныйПлан (а с учётом следующего, что вы написали - просто необходима)

вот только несовсем понятно в контексте чего эта таб. у вас будет...
в идеале конечно - план для курс+специальность,
но не факт что так в риале получится

вообщем в самом пиковом случае, это будет для групп, и примерно такого вида
{id, id_группы, id_предмета, флаг_экзамен, флаг_зачёт, <ну и что там ещё вам понадобится незнаю - к-во часов, преподаватель(ли)? (ли) - это ещё одна таб.,...>}

Михаил89и вот еще вопрос.
сейчас 3,4,5 курс учатся по старой системе зачеты/экзамены
а вот 1,2 уже по новой системе. по болонской системе. они набирают баллы в течение семестра, и кто набрал получают зачеты и экзамены автоматом, кто не набрал сдает. и оценки у них иностранные: A, B, C, D, E, F.

Как посоветуете это реализовать?

а вот эти "A, B, C, D, E, F" - они как-то связанны со "старыми-добрыми" уд/неуд ?
воопщем, если такая связь есть, то можно просто добавить их в таб.Оценки - отдельным полем, - типа синонимы, ну и выводить кому что нужно...

>> по болонской системе. они набирают баллы в течение семестра, и кто набрал получают зачеты и экзамены автоматом

вот, в УчебномПлане сделаете поле КвоБалловНаАвтомат
+ ещё таб. с результатами студента по данному предмету в данном семестре
и потом сравниваете эти величины для каждого и - или отправляете на экзамен, или - автомат

воопщем, как-то так

зы
хотя, конечно, хреновенько, что прийдётся делать 2-е логики работы одновременно...
тут даже незнаю что посоветовать...делать 2-а отдельных клиентских приложения, чтоле....

Михаил89вообщем в самом пиковом случае, это будет для групп, и примерно такого вида
{id, id_группы, id_предмета, флаг_экзамен, флаг_зачёт, <ну и что там ещё вам понадобится незнаю - к-во часов, преподаватель(ли)? (ли) - это ещё одна таб.,...>}

т.е. мне нужна таблица "планирование" вида описанного Вами выше?

да, только со структурой таблицы - вопрос

всё зависит от того - одинаковая ли программа (учебный план) для групп одного курса и одной и той же специальности(факультета)
если одинаковая, то эта таблица будет примерно такая
{id_УчПлана, id_специальности, курс, номер_семестра(1,2), id_Дисциплины, ЕстьЭкзамен, ЕстьЗачет, КвоБалловНаАвтомат}
в таком случае, эту таблицу можно бы было заполнить один раз, разве что - время от времени корректировать, если что-то меняется,
т.е. - жилось бы с ней проще...

если же - программа может быть разная для групп одного курса и одной и той же специальности(факультета),
то прийдётся этот УчПлан - вводить для каждой группы... (см.рис.)

Михаил89вот, в УчебномПлане сделаете поле КвоБалловНаАвтомат
+ ещё таб. с результатами студента по данному предмету в данном семестре
и потом сравниваете эти величины для каждого и - или отправляете на экзамен, или - автомат

это что нужна таблица со всеми данными каждого студента по оценкам?

да, см.рис.

Михаил89хотя, конечно, хреновенько, что прийдётся делать 2-е логики работы одновременно...
тут даже незнаю что посоветовать...делать 2-а отдельных клиентских приложения, чтоле....

надо делать два разных приложения одно для старого, второе для нового?

вот с этим - чесно скажу - незнаю ))
и так - плохо, и так - нехорошо

с одной стороны - разница будет проявлятся в считанных ситуациях:
- подготовка приказов, экз.-зач.ведомостей, вывод оценок/баллов
так, что вроде бы логично было бы - объединить всё в одном проекте,
просто при разных значения курса - разный алгоритм действий...

но, с другой - через 2,3-и года, все эти навороты - будут уже не нужны,
а они останутся в программе и будут обрабатыватся...
тут даже не столько плохо, то что на это будет тратится доп.время,
сколько - никому не нужная сложность логики/кода для поддержки...

так, что чётко сказать - что стоит делать так и только так - я не смогу...

зы.
а вы спросите, вот именно этот вопрос на форуме Акс-а
мол, - кто бы как поступил и почему,
а там будет видно... ))

Михаил89и еще что значит в таблице "учебный план" - есть экзамен, есть зачет, т.е. есть или нет, логический тип?
да, - логический
Михаил89как используются таблицы-строки(order_row и exam_offset_row), что в них будут списки приказов?

нет, это строки приказа/экзам.ведомости
т.е. - у документа Приказ - есть "Шапка" - в которой указывается дата/номер/тип и т.д.
и "Строки" - в которых будут перечисленны студенты которых этот приказ "косается"
тоже самое и про строки ведомости

...и вот ещё что
вот у вас есть несколько полей для года
(school_year в student, year_formation в group)
и для них установлен тип - Дата/Время
меняйте на числовой