Дизайн базы данных. Многим многим. Каким должен быть Основной ключ?

Я разрабатываю систему управления университетом. У меня есть 5 столов: студент, учитель, курсы, доступные_курсы и учебы.Дизайн базы данных. Многим многим. Каким должен быть Основной ключ?

Student: 
    student_id (PK) 

Teacher: 
    teacher_id (PK) 

Courses: 
    courses_id (PK) 

Available_Courses: 
    available_courses_id 
    teacher_id 
    course_id 

Courses_Taken: 
    courses_taken_id 
    student_id 
    courses_available_id

Что должно быть PK в доступных курсах и курсах_Также таблица?

Если я не делаю доступным primary_courses_id (в таблице Available_Courses) первичным ключом, тогда я не смогу подключить Courses_Table, и если я сделаю составной ключ из всех трех атрибутов в таблице Available_Courses, то один учитель может снова зарегистрироваться с тем же курсом и еще раз. Создание составного ключа из двух атрибутов, то есть teacher_id и course_id будет работать, но увеличит повторение в моей базе данных, поскольку они оба будут также находиться в таблице Courses_Taken для создания отношений.

То же самое с таблицей Courses_Taken, поскольку мне нужно использовать его ПК в таблице. Посещение (еще не сделано).

Так что же делать в такой ситуации?

источник

2016-11-23 Azeem Ullah

Кажется, что available_courses содержит строки, где курс учит учитель. Можно было бы ожидать, что доступными курсами станут курсы, которые появляются в некоторой строке в этой таблице. Не важно, чтобы ваш вопрос определял ваши таблицы, вам просто нужно сказать нам, какие ограничения существуют. (CK, FD, FK). – philipxy

Там нет необходимости для искусственного ключа в available_courses или courses_taken таблиц, просто используйте комбинацию двух внешних ключей в качестве первичного ключа:

student 
    id   int unsigned(P) 

teacher 
    id   int unsigned(P) 

course 
    id   int unsigned(P) 

available_courses 
    teacher_id int unsigned (F teacher.id)--\__(P) 
    course_id int unsigned (F course.id)---/ 

courses_taken 
    student_id int unsigned (F student.id)--\__(P) 
    course_id int unsigned (F course.id)---/

источник

2016-11-23 14:28:08

Я знаю, что нет необходимости, но позволяет сказать, что нужно добавить другую таблицу с именем Exam_Results, как бы мы интегрировали ее в этот дизайн. Насколько я вижу, нам нужно будет повторить student.id, teacher.id и course.id в этой новой таблице с именем Exam_Results. Есть ли другой способ повторить? –

@AzeemUllah Нет ничего * неправильного * с повторением их. В противном случае вы повторяете * ids * in * точно в тех же местах *. Резервирование - это не то, что данные появляются дважды, но * одно и то же дважды *. – philipxy

Ск (кандидат ключ) представляет собой набор столбцов уникальный в таблице, который не содержит меньшего уникального набора столбцов. Один CK может называться PK (первичный ключ).

Какие уникальные колоны зависят от того, что строки вашей таблицы говорят о ваших ситуациях применения и могут возникнуть ситуации приложения.

Querying не имеет ничего общего с «соединительными таблицами» (независимо от того, что это означает) или CK или FK (внешние ключи). Запрос запрашивает строки, которые делают истинными утверждения о ситуации приложения, построенные из того, что строки базовых таблиц говорят о ситуации приложения и о том, как их сочетают и логические операторы.

Если столбцы образуют CK или FKs (то есть подныри для значений для некоторого списка столбцов всегда присутствуют как значения надстроек для конкретного CK), тогда мы сообщаем СУБД, чтобы он мог обеспечить это. Это не влияет на состав запросов.

Нет ничего Неправильно per se с повторяющимися значениями. Резервирование - это не данные, которые появляются дважды, но говорят то же самое дважды. Нет необходимости вводить столбец идентификатора вместо естественных ключей. Это просто повторяет id значения в точно в тех же местах.

Предполагая, что вы используете идентификаторы, available_courses имеет CKS {available_courses_id} {& teacher_id, course_id} и courses_taken имеет CKS {courses_taken_id} {& student_id, courses_available_id}. (Хотя вам не нужны идентификаторы.)

источник

2016-11-24 00:05:17 philipxy

Дизайн базы данных. Многим многим. Каким должен быть Основной ключ?

ответ

Смежные вопросы