Подтвердить что ты не робот

Как создать базу данных фильмов?

Я пытаюсь разобраться в этом разумом, что они называют Database Design без особого успеха, поэтому я попытаюсь проиллюстрировать свою проблему на примере.

Я использую MySQL, и вот мой вопрос:

Скажем, я хочу создать базу данных для хранения моей коллекции DVD. У меня есть следующая информация, которую я хочу включить:

  • Название фильма
  • Актеры
  • Время выполнения
  • Жанр
  • Описание
  • Год
  • директор

Я хотел бы создать отношения между ними, чтобы сделать его более эффективным, но не знаю, как это сделать.

Вот что я думаю о дизайне базы данных:

Таблица фильмов = > фильм, название фильма, время работы, описание

Таблица года = > год

Жанр Таблица = > жанр

Таблица директора = > директор

Актеры Таблица = > имя_актера

Но как бы я начал создавать отношения между этими таблицами?

Кроме того, я создал уникальный идентификатор для таблицы Films с первичным ключом, который автоматически увеличивается, мне нужно создать уникальный идентификатор для каждой таблицы?

И, наконец, если бы я обновил новый фильм в базе данных через форму PHP, как бы вставить все эти данные в (с отношениями и всего?)

спасибо за любую помощь, которую вы можете дать, Кит

4b9b3361

ОТВЕТЫ

Ответ 1

Вы должны различать атрибуты и сущности. Сущность - вещь - обычно существительное. Атрибут больше похож на часть описания информации. В jargon базы данных, entity = table, attribute = field/column.

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

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

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

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

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

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

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

films_directors => **filmid, directorid**

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

films => **filmid**, title, otherstuff...
people => **personid**, name, ....
roles => **roleid**, role name, ....
film_people => **filmid, personid, roleid**
genre => **genreid**, name, ...
film_genre => **genreid, filmid**

У вас также может быть поле role_details в таблице film_people, которое может содержать дополнительную информацию в зависимости от роли (например, имя той части, которую играет актер).

Я также показываю жанр как много-много отношений, потому что фильм возможен в нескольких жанрах. Если бы вы этого не хотели, то вместо таблицы film_genre фильмы просто содержали бы жанр.

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

Ответ 2

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

Таблица актеров

  • id (первичный ключ)
  • имя
  • фамилия
  • и т.д.. (любые дополнительные столбцы, которые вы хотите сохранить на актере)

Таблица директора

  • ID
  • имя
  • фамилия
  • и др.

Таблица жанров

  • ID
  • имя
  • и др.

Таблица фильмов

  • ID
  • название
  • Описание
  • время выполнения
  • дата выпуска
  • id директора - это внешний ключ, который ссылается на идентификатор (первичный ключ) директора, который руководил фильмом
  • genre id - как и идентификатор режиссера, это относится к идентификатору жанра, к которому принадлежит фильм.

Таблица индексов пленки актера

  • film id - это внешний ключ, который ссылается на идентификатор фильма
  • actor id - это внешний ключ, который ссылается на идентификатор одного актера в фильме.

Для каждого актера в фильме вы добавили бы строку в индекс актера-фильма. Итак, если актеры 5 и 13 (первичные ключи для этих актеров) снялись в фильме 4 (опять же, первичный ключ для этого фильма), у вас будет две строки, отражающие этот факт в вашем индексе: один с изображением id = 4, и actor id = 5, а другой - с пленкой id = 4, а actor id = 13.

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

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

Ответ 3

Это таблицы, которые я использовал:

films (_id_, title, runningtime, description)
genres (_id_, name)
people (_id_, name, birthdate, etc...)
roles (_roleid_, rolename)
filmgenres (_filmid_, _genreid_)
castandcrew (_filmid_, _roleid_, _personid_)

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

Таблица ролей не обязательно означает характер, который играет актер, но он может. Это может быть "Режиссер", "Продюсер", "Актер"... или даже "Люк Скайуокер", если вы хотите получить этот мелкозернистый... Я считаю, IMDB делает это.

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

Ответ 4

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

Films Table => filmid, filmtitle, runningtime, description, genreid, directorid
Genre Table => genreid, genre
Director Table => directorid, director
Actors Table => actorid,actor_name
FilmActor link table => actorid, filmid (with a record linking each actor to each film)

Любая таблица, которая может быть много для многих, нуждается в таблице ссылок.

Ответ 5

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

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

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

Что касается фактического дизайна, я бы предложил что-то вроде:

Films => Primary Key(filmid), Unique Constraint(filmtitle, year), 
         runningtime, description, 
         Foreign Key(Genre), Foreign Key(DirectorId)

Genre Table => Primary Key(Genre)

Director Table => Primary Key(DirectorId), DirectorName

Actors Table => Primary Key(ActorId), ActorName

Films_Actors => Primary Key(Foreign Key(ActorId), Foreign Key(FilmId))

Для вставки, честно говоря, это PITA. Вам нужно вставить в обратном порядке (и это означает, что клавиши автоматического увеличения могут быть еще более крупными PITA - если вы можете добавить дату рождения или что-то в таблицу Актеров и Директоров, то уникальное ограничение может упростить).

Итак, вы должны добавить Актеры, Режиссер, Фильм, а затем Films_Actors. В идеале, все в одной транзакции. Кроме того, я предполагаю, что жанр уже заполнен и является списком выбора, поэтому его не нужно вставлять.

Ответ 6

Вы можете скачать схему Imdb здесь.

Ответ 7

Иногда актеры - режиссеры, и наоборот, может быть, вам нужна таблица "людей"?

Ответ 8

Вам действительно не нужен YearTable, и все, что вам нужно, это колонки genre_id, director_id и actor_id в таблице ваших фильмов.

Кроме того, ваши таблицы жанра, режиссера и актера должны иметь свои уникальные идентификаторы.

Изменить: Это, конечно, предполагается, что у вас будет только 1 жанр, режиссер и актер для каждого фильма. Скорее всего, это не так.

Чтобы иметь много актеров, принадлежащих ко многим фильмам, вам понадобится отдельная таблица отношений. Вы можете назвать это "moviesActors" (или actMovies), и каждая строка будет иметь actor_id, а movie_id - , этот актер был в этом фильме.

Ответ 9

Я понимаю, что на ваш вопрос уже был дан ответ, однако я хотел бы указать вам:
 http://www.imdb.com/interfaces

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

Ответ 10

Каждая таблица должна иметь уникальный первичный ключ.

Вы должны читать в нормализация базы данных.

Годовая таблица, вероятно, не нужна.

Если это год выпуска, скажем, тогда год может быть сохранен в фильме.

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