Кстати, типы полей тоже помогают контролировать целостность данных,
то есть нельзя записать в поле с типом число строку, например.
Соответственно, ошибочные данные записать нельзя.
Также мы видим пунктирчиками связи между таблицами. Тут я не могу не упомянуть
про нормализацию как тоже один из принципов реляционных баз данных.
Вот, например, издатель или жанр. У одной книги мы будем считать,
что есть только один издатель, но у одного издателя может быть несколько книг изданных.
И также у книги, допустим, есть только один жанр, к которому она принадлежит,
но книг одного жанра может быть много.
Мы могли бы поместить описание издателя прямо внутрь книги,
то есть прямо текстовую информацию, особенно название издателя.
Но у издателя могут быть ведь и другие поля,
и каждый раз дублировать их в каждой книге не очень удобно.
Поэтому удобнее вынести издателя в отдельную таблицу и поместить там его название
и может быть какие-то другие поля: адрес, телефон и так далее.
А в книге просто ссылаться на издателя. Это и называется нормализацией данных,
то есть данные не дублируются, а если есть одинаковый набор данных у разных объектов,
их проще вынести в отдельную таблицу и ссылаться на них.
Это повышает опять-таки целостность данных, потому что,
представьте, в одной книге вы ошиблись в одной буковку у издателя,
и уже можете потом не найти по одному написанию издателя нужную книгу.
А когда он у вас в отдельной таблице, написано один раз его название,
ошибиться уже гораздо сложнее, все книги просто ссылаются на издателя.
Таким образом, в реляционных базах данных есть связи и ограничения.
Связи бывают один к одному, один ко многим и многие ко многим.
Вот, например, связь между издателем и книгой - это один ко многим.
У одной книги может быть только один издатель,
но у одного издателя может быть много книг, изданных им.
То же самое с жанрами. А вот, например, авторов книги может быть несколько.
Книга может быть написана в соавторстве.
С другой стороны, у одного автора может быть тоже много книг.
Таким образом, это - связь многие ко многим. У книги может быть много авторов,
и у автора может быть много книг.
Связь один к одному в теории считается, в общем-то, чем плохим,
потому что если у вас одна строка одной таблицы
связана с ровно с одной строкой другой таблицы,
то есть они жестко связаны,
то в принципе поля можно было бы сразу добавить в первую таблицу и не нужна вторая.
Поэтому в теории связь один к одному -
это какая-то уже денормализация, это не очень хорошо.
Но, с другой стороны, например,
какие-то данные могут использоваться чаще на практике, а какие-то реже,
их может быть, причем, этих редко используемых очень много.
И тогда для оптимизации скорости,
например, можно действительно разделить эти данные на несколько таблиц,
в одной таблице хранить только самые нужные данные, а в
другой какие-то уже дополнительные, которые не всегда используются,
и иметь связь один к одному. Дальше ограничения. Когда связь между таблицами,
связь реализуется с помощью внешних ключей, когда один
id ссылается на другой id в другой таблице.
Ограничение помогает нам сохранить целостность.
Например, книга ссылается, как мы говорили, внешним ключом на издателя.
Что будет, если мы удалим издателя? Все, его нет в таблице издателей,
а книга по-прежнему ссылается на какие-то отсутствующие строки.
Это - нарушение целостности данных, это очень плохо на самом деле.
На связи между книгой и издателем можно наложить ограничения, например,
в случае удаления издателя, сказать базе данных, чтобы
она удаляла все книги этого издателя. Тогда целостность данных не будет нарушена.
Это может быть обосновано, например, мы удаляем издателя,
когда мы перестали с ним работать, и книги этого издателя нам больше не нужны.
Все автоматически делает база данных. Или мы можем применить другую тактику.
Мы можем запретить удалять издателей, на которых ссылается хотя бы одна книга.
Это тоже поможет нам контролировать целостность данных.
Или мы можем сказать базе данных, что, если мы удаляем издателя,
то все книги, которые на него ссылаются, мы помещаем в поле "publisher id",
ссылку на издателя, ничего. То есть, они перестают иметь издателя.
Это уже не очень хорошо, но тоже вариант гораздо лучше,
чем ссылаться на несуществующего издателя. То есть, вот эти внешние ключи и
ограничения нужны для обеспечения целостности баз данных.
Давайте еще раз взглянем на картинку. Итак, у нас пунктирами показаны отношения.
Жанр с книгой - один ко многим, издатель с книгой - один ко многим,
а автор с книгой через промежуточную таблицу - многие ко многим.
Почему через промежуточную таблицу? Мы говорили о том,
что таблицы имеют жесткую структуру,
то есть количество колонок в каждой строке одинаковое.
Соответственно, мы не могли бы сделать так, чтобы у одной книги был один автор,
как эта одна колоночка для автора, а у другой две колоночки для автора.
Поэтому мы используем промежуточную таблицу-блок автор.
Как раз она одним ключом ссылается на книги, а вторым на автора.
То есть, у нас есть список книг и список авторов,
и мы хотим, чтобы у одной книги было два автора,
мы добавляем две записи в таблицу book author.
Обе они ссылаются на одну и ту же книгу.
То есть, у них одинаковый book id, который ссылается на книгу, и разные author id,
они ссылаются на двух разных авторов.
Вот так реализуются связи многие ко многим.
Давайте еще поговорим о выборке данных.
Вот у нас есть эта база данных, которую мы сейчас видели,
и мы хотим выбрать все книги какого-то конкретного автора,
мы знаем его author id.
Например, мы получили его из таблицы author заранее,
и хотим получить их упорядоченными по году.
В качестве данных мы хотим получить заголовок книги,
год издания, имя издателя и имя автора.
Мы можем написать такой запрос: SELECT title,
year, это из таблицы книг,
p.name, это из таблицы авторов,
и назовем его pubname,
ключевое слово as позволяет как бы переименовать колонку в результате a.name как автора.
Вот видите, у двух таблиц одинаковы имена,
было бы нехорошо, если бы мы их оставили,
в принципе, ничего не страшного,
просто две колонки назывались бы одинаково в ответе,
было бы не очень удобно.
Откуда, ключевое слово, from book,
дальше используется ключевое слово join,
соединить с таблицей издателей, join publisher,
и назвать эту таблицу P просто для сокращения,
чтобы не писать в сериях,
где publisher.name, а написать просто p.name, короче.
То есть мы переименовываем табличку при этом.
Как мы соединяем табличку publisher с табличкой книг?
Используя publisher id, то есть у обоих табличек есть этот publisher id,
и при соответствии publisher id в обоих строчках,
эти строчки совмещаются, и результаты их берутся.
То есть, мы, используем ключевое слово unsing,
чтобы соединить две таблицы, join и using.
Соединяем с book author по book id и соединяем с авторами по author id.
Также мы добавляем фильтр WHERE author id = 1,
то есть