Когда разбивать таблицы в SQL?

Question

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

Я смотрел лекцию, где у преподавателя была таблица «Клиенты», а одна из колонок была «Город», и многие клиенты были из одного города, поэтому данные были избыточными. Затем он разбил «Сити» на собственный стол, но для меня это не имело никакого смысла.

Например, я создаю базу данных курса колледжа и заметил, что некоторые столбцы в измерении «Курс» повторяются очень часто (например, кредитные часы). Должен ли я разбить кредитные часы на свою собственную таблицу, где эта таблица будет иметь только пару строк? Что это делает? Мне все равно придется использовать внешний ключ для ссылки на одно и то же значение для каждой новой записи данных, так что это даже сэкономит на хранилище или это будет просто ненужное объединение?

У меня есть и другие столбцы, такие как «Дни недели», «Местоположение», «Время класса», которые также имеют только несколько значений, которые часто повторяются. Должны ли они быть разбиты на отдельные таблицы или оставлены частью таблицы курса?

Answer 1

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

курс

• PK course_ID (int)
• credit_hours (int)

• местоположение (варчар)

    |
  

  (отношения один ко многим)

    |
  

график

• PK schedule_ID (int)
• FK course_ID (int)
• day_of_week (varchar)
• start_time (varchar)
• end_time (varchar)

Answer 2

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

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

Для ваших конкретных вопросов:

• "кредитный час больше похож на атрибут сущности курсаКогда они будут своей собственной организацией? Хорошо, если бы у них была другая информация, относящаяся к часам кредитования. Трудно привести примеры, но, например,: стоимость, диапазон дат вступления в силу, отделы, где применяются кредиты.
• "дни недели". Если это для даты, то просто используйте дату и выведите день недели, используя функции базы данных для даты или календарной таблицы.
• "дни«недели» для планирования. Этот способ сложнее. Есть несколько способов представить это; наилучшее представление зависит от того, как оно используется.
• «местоположение». Звучит как сущность.имейте имя, адрес, контакт, указания и другую информацию. Фактически, могло быть больше чем одно юридическое лицо, чтобы поддержать это.
• "время класса".s, вероятно, является атрибутом курса с временем начала и окончания.