Метод создания базы данных для ТВ-шоу

Question

Это мой первый вопрос к stackoverflow, поэтому, если я что-то не так, пожалуйста, дайте мне знать, что я исправлю это как можно скорее.

Итак, я пытаюсь создать базу данных для ТВ-шоу, и я хотел бы узнать лучший способ и сделать мою текущую базу данных более простой (нормализация).

Я хотел бы иметь следующую структуру или подобное.

    Fringe  
        Season 1 
            Episodes 1 - 10(whatever there are)
        Season 2 
            Episodes 1 - 10(whatever there are)
        ... (so on)

    Burn Notice
        Season 1 
            Episodes 1 - 10(whatever there are)
        Season 2 
            Episodes 1 - 10(whatever there are)
        ... (so on)

    ... (More Tv Shows)

Извините, если это кажется неясным. (Пожалуйста, уточните)

Но у меня сейчас есть 3 таблицы (tvshow_list, tvshow_episodes, tvshow_link)

    //tvshow_list//
    TvShow Name | Director | Company_Created | Language | TVDescription | tv_ID

    //tvshow_episodes//
    tv_ID | EpisodeNum | SeasonNum | EpTitle | EpDescription | Showdate | epid

    //tvshow_link//
    epid | ep_link

Директор и компания связаны идентификатором с другой таблицей со списком компаний и директоров.

Я почти уверен, что есть более упрощенный способ сделать это.

Заранее спасибо за помощь,
Кришантан Лингесваран

Answer 1

Я почти уверен, что есть более упрощенный способ сделать это.

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

• Я бы стандартизировал имена вашего внешнего ключа и первичного ключа.В качестве примера можно привести столбцы shows.id, episodes.id, episodes.show_id, link.id, link.episode_id.
• . Помещение SeasonNum, как я полагаю, будет int в таблице эпизодов, на мой взгляд, нарушает ограничение нормализации.Это не является серьезным нарушением, но если вы действительно хотите придерживаться его, я бы создал отдельную таблицу сезонов и связал бы ее многие к одному с таблицей шоу, а затем связал бы эпизоды только с сезонами.Это дает вам возможность, например, прикреплять информацию к каждому сезону.Кроме того, он предотвращает повторение информации (хотя тип столбца внешнего ключа идентификатора сезона в таблице «Эпизоды» якобы все еще будет INT, внешний ключ философски хранит связь, что вы хотите, а не тупые данные, что у вас есть).
• Вы можете рассмотреть вопрос о том, чтобы поместить язык, директора и компанию в свои собственные таблицы, а не в список своих телешоу.Это та же проблема, что и выше, и в вашем случае незначительное нарушение нормализации.
• У языка, директора и компании есть интересные вопросы, связанные с уровнем ассоциации.Большинство телешоу имеют разных режиссеров для разных эпизодов.Многие из них выпускаются на нескольких языках и несколькими разными компаниями, а иногда и сетями.Так на каком уровне вы планируете хранить эту информацию?Я не архитектор программного обеспечения, поэтому кто-то другой может лучше ответить на этот вопрос, чем я, но я бы создал полиморфную ассоциацию «многие ко многим» для языков, директоров и компаний, а также модель наследования, которая позволяет этим значениямуказываться для каждого эпизода, сезона или сезона, наследуя значение от своего родителя, если ничего не указано.

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

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

Answer 2

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

Есть два основных способа смоделировать то, что вы пытаетесь сделать здесь, с помощью эпизодов и шоу.В мире баз данных мы, возможно, слышали термин «один ко многим» или «многие ко многим».И то, и другое полезно, это зависит только от вашей конкретной ситуации, чтобы знать, какую из них использовать.В вашем случае, большой вопрос, который нужно задать себе, состоит в том, может ли один эпизод принадлежать только одному шоу, или эпизод может принадлежать нескольким сериям одновременно?Я объясню две формы, и почему вам нужно знать ответ на этот вопрос.

Первая форма - это просто связь с внешним ключом.Если у вас в таблице эпизодов есть две таблицы «Эпизоды» и «Шоу», у вас будет столбец с именем «Шоу_идей», содержащий идентификатор одного (и только одного!) Шоу.Можете ли вы увидеть, как вы никогда не могли иметь эпизод, принадлежащий более чем одному шоу таким образом?Это называется отношением «один ко многим», т. Е. У шоу может быть много эпизодов.

Вторая форма - использование таблицы ассоциации, и именно эту форму вы использовали в своем примере.Эта форма позволит вам связать эпизод с несколькими шоу и поэтому называется отношением «многие ко многим».

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

Примером ситуации, когда вам понадобятся отношения «многие ко многим», может быть, если вы моделируете библиотеку и должны отслеживать, кто какую книгу проверил.У вас будет таблица книг, таблица пользователей, а затем таблица «книг для пользователей», которая будет иметь идентификатор, book_id и user_id и будет отношением «многие ко многим».

Надеюсь, это поможет!