Проектирование базы данных, нужно знать, правильно ли я делаю это

Question

У меня есть сайт, который я создаю для бизнеса друга, и мне интересно, как хранить данные. Пока я разработал эту диаграмму. Позвольте привести пример:

Скажите, что в турнире по каратэ есть 2 события: спарринг и формы. Каждое событие может иметь свое собственное разделение: спарринг 4-6 лет, спарринг 8-10 лет и т. Д. И каждый ученик может зарегистрироваться для 1 или всех событий.

Мой вопрос: достаточно ли изображения ниже, чем я объяснил в этом примере, минус мощность.

Мои второстепенные вопросы: какова будет фактическая база данных? Прямо сейчас, я могу думать о следующих таблицах добавить:

• студентов
• события
• подразделения
• student_divisions (student_id, division_id) Является ли это правильно? Потому что мне нужно, чтобы иметь возможность хранить несколько подразделений для одного студента

Спасибо, любые указатели, чтобы помочь мне стать лучшим дизайнером было бы полезно.

Answer 1

Держите его простым, сделайте это весело.

• потерять термин «id» (сделать его student_id или division_id или event_id) Использовать термины, которые делают его действительно понятным, что идентифицируется. То же самое для «name» .. это имя student_name или event_name?
• Помещенные так много деталей, насколько это возможно на каждом студенте (student_id, current_belt_ranking, date_of_birth (-.> Возраст), student_name
• События (event_name, division_id, дата, место) (я бы сделал ключ = event_name/деление пара) или в качестве альтернативы «Sparing_8-10», «Forms_4-6»
• дивизион (деление И.Д., другие вещи, как указано)
• студента/таблица событий (student_id соответствие с event_name/division_id пары)

Анализ для первой, второй, третьей нормальной формы.

• Первая нормальная форма (1NF): на простом английском языке ни одна строка данных не может иметь повторяющихся элементов. Все записи типа записи должны содержать одинаковое количество полей. ex (вы бы не помещали события, на которые студент был зарегистрирован в пределах таблицы учеников. Поместите этот материал в отдельную таблицу.)

• Вторая нормальная форма (2NF): Проще говоря, существуют ли какие-либо элементы данных в одной строке, которая зависит только от части конкатенированного первичного ключа? Если это так, удалите эти элементы в дополнительную таблицу. (например: у вас не было бы имени, возраста и даты студента в таблице ученика/событий ...)

• Третья нормальная форма (3NF): каждый атрибут нестандартного типа ваших таблиц не зависит от транзита на каждом суперклассу таблиц. 3NF нарушается, когда не-ключевое поле является фактом о другом неключевом поле. (Да, как это имеет смысл?И, откровенно говоря, я не могу привести пример этого для вас вашим примером ... Позвольте мне сделать немного исследований ... С вашей системой я не думаю, что есть таблицы с большим количеством полей, чтобы даже получить близко к этому нарушению. Помните, что 3NF имеет дело с не ключевыми полями, относящимися к другим неключевым полям.)

Сделайте снимок, затем создайте свои запросы и посмотрите, имеют ли они смысл?