поле Специальность - нафик не надо - группа достаточно (или это должна быть характеристика группы)
курс - характеристика группы, а не студиоза, да и вообще - вещь - расчётная

Михаил89Senya_L,

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

Михаил89,

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

и кафедры факультета (ну или если вам нравится - специальности) - непомешают
1:M - к факультетам,
ну и уже группы - 1:M к кафедрам

зы
опишите, что воопще обозначают все остальные таблицы,
ну неохота гадать как-то

Михаил89,

>> course - курсы.

настаиваю,
в таб студенты - это не нужно
если для группы добавить поле - год формирования, - то ненужная характеристика ваапщче

>> type - тип приказа - на отчисление, в академ, перевод на следующий курс, восстановление.
>> order - сами приказы - на отчисление, в академ, перевод на следующий курс, восстановление.

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

ну и статуса приказа (подписан/не подписан/пьяный бред секретарши), чёта незаметил...

>> summary - сводная таблица (используется для создания ведомостей).
полная фигня,
убирайте

>> exam - экзамены.
>> offset - зачеты

имхо, нужно объеденить
или - добавить признак экзамен/зачёт
или - в оценках (score) ещё будет зачёт/незачёт (правда, бывают ещё диффер.зачёты...)

и, имхо, тоже стоит к этому, "относится" как к документу - "экз./зачётн. ведомость" (шапка - дата, предмет, препод, ...) и строки (студент, оценка)

>> semester - семестры.
...а что на данный момент вы в это вкладываете ?
это таблица с 2-мя цифрами {1,2} ?
где год ??

>> Подскажите как на основе приказов оформить перевод в другую группу, на другой курс. И статус также должен меняться при помощи приказов. Статус - отчислен, учится, академ.

это уже - вопрос реализации, к проектированию имеющий мало отношения
но если вы "твёрдо нацелились" на Акцес, то там это делается
1
просто - в формах - обработкой событий
2
сложнее - триггер Бенедикт-а

зы
не стесняйтесь выкладывать БД в мдб

nosovавторну и статуса приказа (подписан/не подписан/пьяный бред секретарши), чёта незаметил...какой еще статус ? пока приказ не подписан -- считается что его нет и вносить его в БД это глупость (имхо).

ага,
а набирать его будет секретарша на печатной машинке, наверна ??
с чего его распечатать на подпись ?

nosovчерновик приказа можно и в WORD распечатать.
кстати черновик может быть капитально почиркан или ваще отменен.

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

>> или ваще отменен.
ну вот это и был "статус" = "пьяный бред секретарши" ))
хотя, ничто не мешает "выносить" их из БД физически, это уже - на усмотрение ТС

ну и самое главное,
приказы ведь ТС непросто от нечего делать в БД ввёл - что б было,
это способ, которым будет изменятся состояние статуса у студента,
т.е. - нужно какое-то инициирующее эти изменения событие,
вот изменение статуса Приказа на Подписан - вполне на это подходит, имхо
вполне - дёшево, и не очень сердито

Михаил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)
и для них установлен тип - Дата/Время
меняйте на числовой