Недавно я научился разрабатывать и создавать простые схемы баз данных, и мне не терпится узнать больше о том, как это сделать лучше всего. Для тех из вас, кто не знает, схема базы данных - это своего рода план того, как наборы данных в разных таблицах могут соотноситься друг с другом, и без плана эти отношения могут стать немного запутанными. На самом деле, я подозреваю, что даже с твердым планом работа иногда все равно будет запутываться, особенно для новичков в базах данных, таких как я.
Я приведу простой пример и объясню свой мыслительный процесс при планировании схемы базы данных. В нашем примере мы рассмотрим отношения между списком фильмов, списком актеров и списком наград, а также то, как мы можем представить отношения между ними.
Прежде чем мы перейдем к деталям, я считаю, что будет разумным воспользоваться моментом и понять, как эти отношения могут выглядеть в реальной жизни по сравнению с данными, которые мы ожидаем получить или ввести.
Например, у фильма есть одно конкретное название, одна конкретная продолжительность, много оценок (хотя каждый рейтинг дан только для одной службы) и, как правило, ведущий актер / актриса, но иногда ведущая роль может быть разделена между двумя или более актерами / актрисами. .
У актеров обычно одно имя, один конкретный возраст, но за плечами у них может быть от нуля до множества наград.
Наконец, у награды есть одно конкретное название, один фильм, связанный с наградой, и от одного до многих получателей.
В этом примере вы можете заметить много возможностей для осложнений. Вы можете включить рейтинги из нескольких рейтинговых служб. Возможно, вы захотите рассмотреть награды, присуждаемые группе, а также награды, присуждаемые отдельным лицам, и если вы действительно хотите это сделать, тогда вам нужно решить, как вы собираетесь записывать информацию. Будут ли получатели групповой награды перечисляться индивидуально или вы будете указывать получателей по одному названию команды?
Как видите, задача построения схемы вокруг этого потенциально может быть довольно сложной. Иногда эти ограничения и соображения могут быть продиктованы нами, и другие (например, я, создавая этот пример) могут иметь больше свободы в процессе принятия решений относительно того, что записывать и как.
Вот диаграмма, которую я строю на основе информации, которую хочу видеть. Давайте рассмотрим, что здесь сделано и как мы можем это расширить. Здесь каждая строка фактически представляет столбец в связанной таблице. Это означает, что каждая строка в таблице актеров будет представлять одного актера, и что у одного актера есть идентификатор (не выданный правительством, а идентификатор, специфичный для таблицы, который будет использоваться в другом месте - как правило, автоматически увеличивающийся номер), имя, возраст. , и в ряде фильмов, в которых они снимались.
Создавая эти таблицы, я помню несколько вещей. Во-первых, я постоянно оцениваю, приведет ли мой подход к появлению пустого или переполненного пространства в таблице. Это восходит к предыдущему обзору реальной информации. Вещи с отношениями один к одному чисты, просты и, как правило, лежат на одном столе. Опять же, фильм имеет ровно один конкретный заголовок, поэтому наличие столбца для заголовка фильма безопасно, не беспокоясь о том, что один фильм не имеет заголовка или один фильм имеет несколько заголовков. Однако это не относится к фильмам или актерским наградам. Из-за этого необходимо экстраполировать награды в свою таблицу. Представьте, что у нас есть столбец для наград в таблице фильмов и / или в таблице актеров. Конечно, это приведет к тому, что некоторые строки (каждая строка представляет один фильм или одного актера) в столбце будут заполнены множеством наград, а в некоторых строках будет пустое место для наград.
Принцип DRY (Don’t Repeat Yourself) - еще одна направляющая, которую я регулярно рассматриваю. Если у меня уже есть имя актера, указанное в таблице актера, не имеет ли смысла просто использовать его идентификатор в другой таблице, где их имя могло использоваться в противном случае? Эта концепция может значительно сэкономить место в базе данных и вводит идею внешних ключей. Внешние ключи часто представляют собой числовые значения и связаны с данными в другой таблице в базе данных. Здесь внешние ключи представлены линиями, проведенными между таблицами.
Можете ли вы представить себе, как на самом деле будет выглядеть таблица наград при использовании? Каждая строка будет начинаться с автоматически увеличивающегося числа, за которым следует название награды, за которым следуют два целых числа. Первое целое число будет внешним ключом, представляющим имя актеров, получивших награду, а второе целое число будет представлять название фильма, связанного с наградой.
Наконец, уделите время рассмотрению других отношений и представлений, которые мы, возможно, захотим встроить в нашу схему. Что нам нужно, если мы хотим перечислить все рецензирующие агентства и их обзоры на все фильмы определенного жанра? Что, если бы мы хотели перечислить всех актеров, с которыми один актер работал в прошлом? Это примеры ситуаций, когда нам потребуется больше таблиц, больше связей и больше внешних ключей.
Я все еще пытаюсь понять, почему пустое пространство - плохая практика при построении схем. Я полагаю, что это связано с использованием памяти, и я не удивлюсь, если узнаю, что пустое пространство может указывать на возможность какой-то оптимизации либо для скорости, либо для ясности. Знаете ли вы какие-либо конкретные причины, по которым следует избегать пустых или переполненных столбцов?
Если вы увидите какие-либо ошибки в моем сообщении или у вас есть какие-либо исправления или дополнения, касающиеся схем баз данных, я буду очень признателен за ваш конструктивный отзыв!
