Простой дизайн таблицы базы данных / макет

Question

Мне просто интересно, в качестве гипотетического примера, , как лучше всего расположить таблицу для следующего сценария:

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

Итак, как мне раскладывать стол? (Если вы не понимаете, что я имею в виду, я имею в виду, какие данные следует вводить в каждый столбец, строку ...) Например, возможно, есть таблица учеников с идентификаторами учеников, и для каждого ученика каждый день создайте новую строку в Таблица посещаемости с колонкой 1: студенческий билет, колонка 2: дата, колонка 3: статус (присутствует / отсутствует). Тем не менее, это не кажется очень эффективным. Что ты думаешь?

ОБНОВЛЕНИЕ: Из всех этих первых ответов кажется, что по одному ученику в каждом ряду в таблице посещаемости учеников (где он / она обозначен как присутствующий / отсутствующий), но что если бы я был включить более одного студенческого идентификатора в строку, скажем, для всех студентов, отсутствующих в один прекрасный день? Будет ли это лучше или хуже (возможно, это неоднозначно)? На самом деле, я начинаю думать, что эффективность будет снижена, потому что единственные действия, которые даже помогает этот шаг, уже легко выполнить. Хм ...

Answer 1

Ключевым моментом при проектировании базы данных является обеспечение целостности модели. Таким образом, в вашем примере вы не захотите записывать пропуски учеников на даты, которые выпадают на выходные, праздничные дни или выходные дни. Так что вам также нужен стол КАЛЕНДАРЬ. STUDENT_ABSENCE будет таблицей пересечений между STUDENT и CALENDAR. То есть он будет иметь внешние ключи как для идентификатора в таблице STUDENT, так и для Дня в КАЛЕНДАРЕ.

Это может показаться чрезмерным инженерным делом, но почти все, что происходит в школе, включает планирование, поэтому КАЛЕНДАРЬ необходим. С тем же успехом вы можете использовать его, чтобы создать лучшую модель, какую только сможете.

Также обратите внимание на то, какие другие атрибуты нужны таблице STUDENT_ABSENCE. Вдобавок ко всему, вы можете записать, было ли уведомление об отсутствии заранее (например, для семейного отдыха во время семестра), было ли одобрение отсутствия, было ли это отсутствие по болезни.

Answer 2

STUDENTS стол

• STUDENT_ID, шт
• FIRST_NAME
• LAST_NAME

STUDENT_ATTENDANCE таблица

• STUDENT_ID, рк, фк
• ABSENT_DATE, шт

Нет необходимости в столбце IS_ABSENT - наличие даты указывает на то, что ученик отсутствовал, и на какую дату. Вероятно, будет меньше дней отсутствия, чем посещено, поэтому храните только отсутствующие даты.

Создание первичного ключа, который будет составным из двух столбцов, гарантирует, что у вас не будет дубликатов.

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

Затем вы либо сохраняете дополнительные student_ids в виде списка через запятую в одном столбце, либо дополнительных столбцов для каждого дополнительного student_id. Дополнительные столбцы для каждого student_id никогда не будут работать - вы добавляете столбец для каждого нового студента каждый год. Конкатенация списка student_ids более реалистична, но будет трудно вытащить детали, если вы хотите сообщить о конкретном ученике или группе учеников. Из-за ограничений по количеству символов существует риск невозможности сохранить каждый student_id, который может отсутствовать, в одном столбце.

Я рекомендую использовать таблицу STUDENT_ATTENDANCE, которую я предложил.

Answer 3

Если вы объединяете несколько значений в список значений и сохраняете их в одной ячейке, ваша таблица больше не будет в первой нормальной форме, как изначально определено Codd. Вы можете соответствовать первой нормальной форме, переопределенной датой, храня таблицу внутри таблицы. Большинство новичков этого не делают. Обычно они объединяют список значений в строку символов, разделенных запятыми, и сохраняют весь список, как если бы это было одно атомарное значение.

В дальнейшем они обнаружат, что они больше не могут использовать возможности реляционных операторов, в частности, объединения, для простого выражения сложных операций. Это обычно стоит новичку больше, чем "неэффективность". Даже если вы поместите таблицу в таблицу, вы обнаружите, что выполнять рутинные операции с данными гораздо сложнее, чем должно быть.

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

Это не написано для типичного 12-летнего. Ты не похож на типичного 12-летнего. Поэтому я пытаюсь познакомить вас с основами хорошего проектирования баз данных, вместо того, чтобы позволить вам изучать плохой дизайн баз данных в старшей школе, а затем придется отучиться от этого и начать все заново позже.

Answer 4

У меня была бы таблица MissedClasses с StudentID в качестве внешнего ключа, датой, курсом и, возможно, периодом, и, возможно, другим столбцом для оправданного или нет. Разместите запись, если они не посещали.

Мои рассуждения: надеюсь, большинство из них посетят большинство классов, поэтому вам нужно только отслеживать пропуски.

Answer 5

У меня была бы таблица учеников с идентификаторами учеников и информацией, специфичной для каждого ученика, такой как имя, класс и т. Д. Затем была бы таблица student_attendance с идентификатором ученика, датой, статусом (присутствует / отсутствует).

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

Вы не хотели бы помещать более одного студенческого идентификатора в одну строку, потому что, хотя у вас было бы меньше строк, у вас было бы столько же данных, и запрос таблицы / отчетности был бы неудобным.