Структура таблицы и внешние ключи

Question

В базе данных mysql у меня есть в общей сложности 7 таблиц. В нормальных условиях инструктор принадлежит только одной академии, но в академии может быть много инструкторов. Точно так же многие курсы можно преподавать в одной академии. Я не помню, какой преподаватель преподавал, какой курс, но какой курс преподается в x или y академии. Кроме того, каждая академия имеет основного контактного лица и в отличие от инструкторов, контактное лицо может быть частью нескольких академий. В конце концов, я хотел бы запустить запрос, где я могу видеть связанные данные в определенной академии по своему выбору.

Являются ли приведенные ниже таблицы структурированными, чтобы хранить/отображать данные вдали от того, что нет повторных значений тех же инструкторов, курсов и т. Д.?

CREATE TABLE IF NOT EXISTS `academies` (
    `id` int(11) NOT NULL auto_increment, 
    `name` varchar(25) NOT NULL, 
    `mou_id` int(11) default NULL, 
    `academy_id` int(11) NOT NULL, 
    `street_address` varchar(50) NOT NULL, 
    `city` varchar(25) NOT NULL, 
    `state` varchar(25) NOT NULL, 
    `country` varchar(25) NOT NULL, 
    `zipcode` varchar(5) NOT NULL, 
    `telephone` varchar(15) NOT NULL, 
    `comments` text, 
    `last_contacted` date default NULL, 
    PRIMARY KEY (`id`) 
) ; 



CREATE TABLE IF NOT EXISTS `academy_courses` (
    `id` int(11) NOT NULL auto_increment, 
    `academy_id` int(11) NOT NULL, 
    `course_name` varchar(75) NOT NULL, 
    `course_id` int(11) NOT NULL, 
    `instructor_id` int(11) NOT NULL, 
    `start_date` date default NULL, 
    PRIMARY KEY (`unique_id`), 
    KEY `course_id` (`academy_id`,`course_id`) 
); 


CREATE TABLE IF NOT EXISTS `courses` (
    `course_id` int(11) NOT NULL auto_increment, 
    `course_name` varchar(75) NOT NULL, 
    PRIMARY KEY (`course_id`) 
); 


INSERT INTO `courses` (`course_id`, `course_name`) VALUES 
(1, 'Math'), 
(2, 'English'), 
(3, 'Science'), 
(4, 'HIstory'); 


CREATE TABLE IF NOT EXISTS `instructors` (
    `instructor_id` int(11) NOT NULL auto_increment, 
    `academy_id` int(11) NOT NULL, 
    `instructor_name` varchar(50) NOT NULL, 
    `instructor_phone` varchar(15) default NULL, 
    `instructor_email` varchar(55) default NULL, 
    PRIMARY KEY (`instructor_id`), 
    KEY `academy_id` (`academy_id`) 
); 


CREATE TABLE IF NOT EXISTS `last_contacted` (
    `talkedto_id` int(11) NOT NULL auto_increment, 
    `academy_id` int(11) NOT NULL, 
    `talkedto_name` varchar(50) NOT NULL, 
    PRIMARY KEY (`talkedto_id`), 
    KEY `academy_id` (`academy_id`) 
); 


CREATE TABLE IF NOT EXISTS `main_contact` (
    `contact_id` int(11) NOT NULL auto_increment, 
    `academy_id` int(11) NOT NULL, 
    `contact_name` varchar(50) NOT NULL, 
    `contact_phone` varchar(15) default NULL, 
    `contact_email` varchar(55) default NULL, 
    PRIMARY KEY (`contact_id`), 
    KEY `academy_id` (`academy_id`) 
); 



CREATE TABLE IF NOT EXISTS `main_contact_bridge` (
    `academy_id` int(11) NOT NULL, 
    `contact_id` int(11) NOT NULL, 
    PRIMARY KEY (`contact_id`,`academy_id`), 
    KEY `academy_id` (`academy_id`) 
); 

UPDATE: на основе Ответ на Emmad Карима

CREATE TABLE IF NOT EXISTS `person` (
id int(11) NOT NULL auto_increment, 
`academy_id` int(11) NOT NULL, 
`person_name` varchar(50) NOT NULL, 
`person_email` varchar(50) default NULL, 
`person_phone` varchar(15) default NULL, 
PRIMARY KEY (`id`), 
CONSTRAINT `academy_id` FOREIGN KEY (`academy_id`) REFERENCES `academy` (`academy_id`) ON DELETE CASCADE ON UPDATE CASCADE, 
); 

Answer 1

Вы изложили следующие правила:

1-инструктор принадлежит только одна академия но академия может иметь много инструкторы

2 - Точно так же многие курсы можно преподавать в одной академии.

3-я не сохраняя запись о том, что инструктор учил, какой курс, но какой курс преподается на х или у академии

4-Также каждая школа имеет главный контактное лицо и в отличие от преподавателей, контактное лицо может быть частью нескольких академий.

Вот некоторые из проблем, которые вы можете рассмотреть и исправить.

A-Использовать единственную форму формы имя таблицы. Пример: Академия

B- AcademyCource Таблица

Определение столбца:

`instructor_id` int(11) NOT NULL, 

Противоречит ваше правило # Таблица 3

C- курс

Определение таблицы не имеет Ссылка FK на таблицу Академии. Это противоречит требованиям # 2,3

D-Table LastContacted

Вы не дали правила для этой таблицы в требованиях, но я бы предположил, что это будет связано с контактным лицом и не имеют контакта имя как бесплатный текст, в противном случае, что такое контактное лицо?

Е-MainContact Стол и Main_Contact_Bridge

Правило номер 4:

4-А Каждый Acaddemy назначает 1 главный контакт

4-Б Каждый контакт может быть назначен в качестве главного контакта для 0, 1 или более Академия

Если вы не отслеживаете встречи с историей, приведенное выше правило не требует Main_Contact_Bridge. Отношения становятся «один ко многим», с одной стороны - контакт, а многие стороны - академия.

Если вы хотите отслеживать историю, то Main_Contact_Bridge является оправданным, но вам нужно добавить 2 столбца, чтобы показать дату начала и дату окончания встречи. Как бы вы обеспечили соблюдение правила, в котором есть только 1 контактное лицо для Академии в данный момент времени? Это требует дальнейшего анализа.

Еще одна проблема заключается в том, что если у вас есть отдельная контактная таблица, и этот контакт является одним из инструкторов, информация этого человека будет введена 2 раза в системе. Это может быть приемлемым в случаях, но в хорошем дизайне вы хотите избежать этого. Один из способов избежать этого - создать таблицу под названием «Лицо» и добавить столбец, чтобы указать, кто это инструктор или контакт.

F-инструктор Таблица

Ваша конструкция предполагает, что преподаватель может работать в течение 1 Академии только в точке поддавки времени. Если это так, тогда все в порядке. Если нет, у вас есть отношения «многие-ко-многим», которые вам нужно адресовать по таблице мостов.

Также обратите внимание на точку, поднятую выше о контакте.

E-Вы должны использовать правильный синтаксис ограничения/FK. См. Например: MySQL FK