Современная жизнь немыслима без web-сервисов, ежедневно приносящих дивиденды в самых разных областях человеческой деятельности. А значит, профессия web-разработчика еще долго будет оставаться высокооплачиваемой и востребованной на рынке IT-специалистов. Существует множество решений и инструментов на разных языках программирования, упрощающих и ускоряющих web-разработку. В рамках данного курса освещается построение web-приложений на языке Python. Курс читают разработчики, применяющие Python в проектах, которыми ежедневно используют миллионы людей. В данном курсе вы сможете приобрести как базовые знания о функционировании современного интернета в целом, так и практические навыки создания интернет-приложений на языке Python.
Реляционные базы данных
Loading...
En provenance du cours de Moscow Institute of Physics and Technology
Создание Web-сервисов на Python
41 note
Moscow Institute of Physics and Technology
41 note
Cours 3 sur 4 dans Specialization Программирование на Python
À partir de la leçon
Хранение данных. SQL / NoSQL
В этом модуле нас ждёт знакомство с системами управления базами данных. Мы узнаем, зачем и когда их лучше использовать, в чём отличие реляционных баз данных от нереляционных? После этого глубже погрузимся в MySQL, как пример реляционной базы данных, и познакомимся с Redis, как примером нереляционной базы данных.
Rencontrer les enseignants
Абрамов Тимур
Пестров Никита
Опрышко Александр
Партилов Алексей
Всем привет. В предыдущих видео мы говорили о том,
что данные для длительного хранения и удобной выборки
лучше всего помещать в систему управления базами данных.
В этом видео мы начнем изучать реляционные базы данных.
Рассмотрим их логическую организацию и методы обеспечения целостности данных.
Итак, реляционная база данных - это набор таблиц, чем-то похожих на таблицы Excel.
Каждая таблица - это набор строк и столбцов,
и она содержит информацию об объектах определенного типа.
То есть, в одной таблице информация об одинаковых по типу объектах.
И может иметь связи с другими таблицами. Связи - это, собственно, ключевой момент.
Реляционные базы данных и происходят от слова "relation" - связь.
Итак, в каждой таблице данные находятся в виде строк и столбцов.
В каждой строке таблицы находятся данные одного объекта, это
может быть пост, комментарий, пользователь и так далее.
А столбцы описывают свойства этого объекта, например, логин,
имя, пароль, если речь идет о пользователе.
Все строки одной таблицы имеют одинаковую структуру, то есть одни и те же поля,
не может быть двух строк с разным набором полей в одной и той же таблице.
А каждое поле, в свою очередь, имеет строго определенный тип данных:
число, строка, дата, ну или какие-то другие типы данных,
поддерживаемые конкретной базой данных.
Давайте взглянем на картинку. У нас есть некая таблица пользователей.
В ней три строчки, три пользователя. У всех из них одинаковые поля,
разные значения, но набор полей одинаковый. Столбцы описывают свойства: это id,
password, name, created add. Каждый столбец опять-таки имеет определенный тип данных.
Id, например, - это число, login - это строка, а created at - это дата.
Все строки имеют один и тот же набор полей,
и каждое поле, как я уже сказал, имеет определенный тип данных.
Вот так это происходит в базах данных.
Структура базы данных описывается схемой базы данных,
которая включает в себя описание содержания, структуры и ограничения целостности.
Описывается эта структура на языке СУБД, как правило, это SQL.
Но удобно эту структуру представить графически.
Вот на картинке схема простенькой базы данных, хранящей информацию о книгах.
Давайте посмотрим. Здесь пять таблиц, в них есть поля, они представлены,
типы полей указаны: INT, VARCHAR, DATE. VARCHAR - это строка переменной длины,
но не больше, например, 1024 символов для поля title книги.
Кстати, типы полей тоже помогают контролировать целостность данных,
то есть нельзя записать в поле с типом число строку, например.
Соответственно, ошибочные данные записать нельзя.
Также мы видим пунктирчиками связи между таблицами. Тут я не могу не упомянуть
про нормализацию как тоже один из принципов реляционных баз данных.
Вот, например, издатель или жанр. У одной книги мы будем считать,
что есть только один издатель, но у одного издателя может быть несколько книг изданных.
И также у книги, допустим, есть только один жанр, к которому она принадлежит,
но книг одного жанра может быть много.
Мы могли бы поместить описание издателя прямо внутрь книги,
то есть прямо текстовую информацию, особенно название издателя.
Но у издателя могут быть ведь и другие поля,
и каждый раз дублировать их в каждой книге не очень удобно.
Поэтому удобнее вынести издателя в отдельную таблицу и поместить там его название
и может быть какие-то другие поля: адрес, телефон и так далее.
А в книге просто ссылаться на издателя. Это и называется нормализацией данных,
то есть данные не дублируются, а если есть одинаковый набор данных у разных объектов,
их проще вынести в отдельную таблицу и ссылаться на них.
Это повышает опять-таки целостность данных, потому что,
представьте, в одной книге вы ошиблись в одной буковку у издателя,
и уже можете потом не найти по одному написанию издателя нужную книгу.
А когда он у вас в отдельной таблице, написано один раз его название,
ошибиться уже гораздо сложнее, все книги просто ссылаются на издателя.
Таким образом, в реляционных базах данных есть связи и ограничения.
Связи бывают один к одному, один ко многим и многие ко многим.
Вот, например, связь между издателем и книгой - это один ко многим.
У одной книги может быть только один издатель,
но у одного издателя может быть много книг, изданных им.
То же самое с жанрами. А вот, например, авторов книги может быть несколько.
Книга может быть написана в соавторстве.
С другой стороны, у одного автора может быть тоже много книг.
Таким образом, это - связь многие ко многим. У книги может быть много авторов,
и у автора может быть много книг.
Связь один к одному в теории считается, в общем-то, чем плохим,
потому что если у вас одна строка одной таблицы
связана с ровно с одной строкой другой таблицы,
то есть они жестко связаны,
то в принципе поля можно было бы сразу добавить в первую таблицу и не нужна вторая.
Поэтому в теории связь один к одному -
это какая-то уже денормализация, это не очень хорошо.
Но, с другой стороны, например,
какие-то данные могут использоваться чаще на практике, а какие-то реже,
их может быть, причем, этих редко используемых очень много.
И тогда для оптимизации скорости,
например, можно действительно разделить эти данные на несколько таблиц,
в одной таблице хранить только самые нужные данные, а в
другой какие-то уже дополнительные, которые не всегда используются,
и иметь связь один к одному. Дальше ограничения. Когда связь между таблицами,
связь реализуется с помощью внешних ключей, когда один
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,
то есть
мы считаем,
что id автора должен быть один.
И упорядочиваем по году.
Правда похоже на просто английскую фразу выбрать то-то,
назвать так-то, из такой-то таблицы,
соединить с такой-то таблицей, их соединить с такой-то таблицей,
где author id=1, упорядочить по году.
Достаточно все просто.
Таким образом мы получим на каком-то примере,
смотрите, данные: заголовок, год,
имя издателя и имя автора.
Итак, подведем итоги.
Мы поговорили о логической организации баз данных,
о свойствах таблиц и их полей, узнали
о способе обеспечения целостности данных посредством внешних ключей и ограничений,
поговорили о том, как данные разных таблиц объединяются
в запросе, чтобы получить конечный результат.
А дальше мы поговорим о транзакциях,
ACID, уровнях изоляции и индексах.
Explorer notre catalogue
Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.
Coursera propose un accès universel à la meilleure formation au monde,
en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.
© 2019 Coursera Inc. Tous droits réservés.
