Сегодня говорим про базы данных и разбираем самую популярную из них — реляционную. Это статья с теорией про основные принципы и правила работы. Если хотите что-нибудь из практики, у нас есть такое:
Что такое реляционная база данных
По сути это одна или несколько связанных между собой таблиц. Внешне она выглядит просто как файл Excel с несколькими листами. Что такое реляционные базы данных, хорошо видно на иллюстрации — здесь одна база данных из трёх таблиц:
Почему тут есть одинаковые поля и что означают разноцветные стрелочки, пока неважно — дальше мы всё это разберём.
Главное, что нужно понять:
Реляционная база данных — это таблица. Одна или несколько.
Реляционная модель данных: основа всего
Реляционная БД может хранить практически любую информацию, но делает она это чаще всего в текстовом виде. Обычно в базе находится текст, числа, булевы переменные типа True — False и другие текстовые форматы. Если нужно хранить большие двоичные файлы вроде видео или картинок, то в базе чаще всего будет ссылка на облако или путь к файлу.
Без базы данных не получится создать ни один серьёзный проект, потому что информация должна где-то храниться. В интернет-магазине нужны записи о товарах, ценах и заказах, в социальной сети — профили, посты и комментарии, в играх — данные об игроках, инвентаре и квестах.
Кто и когда предложил модель
Устройство реляционной базы данных придумал в 1970 году программист Эдгар Кодд.
В 1960-х годах информационные системы в бизнесе стали использовать огромные объёмы данных, и работа с ними была неэффективной. Первые базы данных использовали сложные навигационные схемы для связи информации на магнитных лентах. Программисты писали целые программы, чтобы получить доступ только к одному фрагменту информации.
Всё это работало на больших и дорогих компьютерах-мейнфреймах:
Кодд придумал программную архитектуру, которая давала возможность использовать базу данных даже людям без технического образования. База данных Кодда организовывала записи в таблицы по общим характеристикам. Пользователи могли создавать новые таблицы на основе существующих, а компании стали гораздо лучше понимать связи в собственных данных.
Новая схема базы данных упростила управление базами, запросы к ним и снизила расходы на содержание. Если раньше нужно было покупать отдельный мейнфрейм, то сейчас базу данных можно было установить на любой компьютер. Простая структура таблиц сделала хранение и процесс доступа к данным намного эффективнее.
Чтобы установить правила для новой системы, Кодд вывел 12 правил. Например, вся информация должна быть представлена таблицами, а каждое отдельное значение должно быть доступно через имя таблицы, название столбца и уникальное значение-ключ.
Ключевые элементы модели: таблицы, строки, столбцы
Основная составная часть реляционной базы данных — таблица:
Каждая таблица состоит из строк и столбцов. Таблиц может быть несколько. Например, в одной будут храниться данные о клиентах, во второй — о поставщиках, в третьей — о заказах. Если делать всё по правилам хорошего тона, то одна таблица должна описывать что-то одно — например, лучше не смешивать в одной таблице заказы и курьеров.
Как устроена реляционная БД: основные компоненты
С базами данных связано много технических статей, из которых можно узнать интересные, полезные и сложные вещи. Но даже самые сложные статьи будут включать основные термины, поэтому дальше мы разберём главные компоненты БД.
Таблицы (Отношения)
Одна база данных может включать много таблиц. Отношения — это просто другое, более техническое слово для таблиц.
В каждой таблице должны храниться данные одного типа. Это не строгое техническое правило, но для удобства лучше делать так, иначе легко запутаться.
Строки (Записи) и столбцы (Атрибуты)
Все таблицы состоят из строк и столбцов:
- Строки и записи — это одно и то же.
- Столбцы и атрибуты — это одно и то же.
Названия столбцов не могут повторяться внутри одной таблицы, но в разных можно — например, в таблицах «Коты» и «Кошки» могут быть столбцы «Имя», «Вес», «Порода». Но в одной таблице не может быть два одинаковых столбца с разными породами.
Первичный ключ (Primary Key)
У каждой строки есть неповторимый параметр, уникальный идентификатор записи. Чаще всего он называется id и обозначает номер. В этой таблице собрана информация о королевствах «Игры престолов». У каждой есть свой уникальный номер:
Первичный ключ не может быть равен нулю и не может повторяться в пределах одной таблицы. Ещё, как правило, он не изменяется после занесения. Но иногда первичный ключ может быть составным: может включать два и более значения из строки. Как это может выглядеть:
- По отдельности два значения строки не уникальны. Например,
regionиsigil. - Но вместе они составляют уникальную комбинацию, которая и будет первичным составным ключом.
Внешний ключ (Foreign Key): основа связей между таблицами
Внешний ключ ссылается на уникальный столбец в другой таблице. Чаще всего это первичный ключ, но главное правило — значения такого столбца не должны повторяться, так же как и значения первичного ключа.
В таблице ниже в каждой строке есть запись о персонаже. Персонаж связан со своим королевством и локацией, информация о которых хранится в других таблицах. Поэтому столбцы house_id и location_id ссылаются на первичные ключи из других таблиц.
Если бы внешний ключ не ссылался на уникальное значение, программа просто не поняла, какое значение нужно брать.
Нормализация данных
Чтобы с данными было удобно работать, есть семь правил их обработки — это называется нормализацией данных. Все этапы нужно проводить по порядку, то есть для третьего шага уже должны быть выполнены первые два.
Чтобы рассказать про нормализацию данных в БД подробно и просто, нужна отдельная статья, но вот сокращённый сложный список:
- Каждое поле содержит только одно значение.
- Все значения строки зависят от первичного ключа.
- Все столбцы, кроме первичного ключа, не зависят друг от друга.
- Любой столбец, от которого зависит другой столбец, должен быть ключом.
- Один столбец не должен определять несколько независимых наборов данных одновременно.
- Таблицы нужно разделить на минимальные части без потери информации.
- Таблицы делят на отдельные события и факты. Это часто используется для данных с временными метками и историей изменений.
Виды связей в реляционных базах данных на примерах
В базе данных обычно несколько разных таблиц, которые могут быть связаны друг с другом несколькими способами организации. Дальше рассмотрим, как это может быть.
Один ко многим (One-to-Many)
Это самый распространённый тип связей.
Продолжим с примерами из «Игры престолов» и возьмём такую таблицу с персонажами дома Старков:
У каждого персонажа есть первичный ключ id. Но вторичный ключ у всех один и ссылается на вторую строку в таблице с домами:
Получается, что один дом связан со многими персонажами, но каждый персонаж принадлежит только одному дому.
Один к одному (One-to-One)
Означает связь строго между двумя записями из разных таблиц.
Для примера добавим таблицу с расположением каждого дома:
Каждое место связано только с одним королевством, и каждое королевство связано только с одним местом.
Многие ко многим (Many-to-Many)
Это хорошо видно на примере таблицы локаций и таблицы персонажей:
- В одной локации может появиться несколько персонажей. Тогда одна запись из таблицы Location будет связана со многими в таблице Ruler.
- Один персонаж появляется во многих местах. Поэтому наоборот тоже работает: одна строка из Ruler может быть связана с несколькими в Location.
Популярные системы управления реляционными базами данных (СУБД)
С базами данных не работают как с отдельным инструментом. Для этого нужна DBMS — Database Management System. По-русски это СУБД, или система управления базами данных. Программист устанавливает и общается с СУБД, а уже она создаёт базы данных и управляет всей информацией.
MySQL, PostgreSQL, SQL Server, Oracle
Сейчас есть несколько популярных СУБД. Все они создают таблицы и работают через язык запросов SQL, но при этом отличаются друг от друга.
MySQL — самая распространённая на сегодня, простая и удобная, поддерживает разные технологии хранения данных. Она бесплатная, по ней много информации в интернете и подробная документация.
PostgreSQL известна как самая функциональная из бесплатных баз данных SQL. Она поддерживает много интересного и сложного: сложные типы данных, расширения, географические данные. PostgreSQL считается идеальной для аналитики и сложных систем, которые растут.
Microsoft SQL Server часто используется в сервисах на Windows для больших корпоративных приложений. Она легко интегрируется с другими microsoft-продуктами и в целом поддерживает мощные возможности. Но она платная, а документация и примеры в основном ориентированы на Windows.
Oracle — мощная база для крупных корпораций. Поддерживает много функций для бизнеса, очень надёжная и масштабируемая, но сложная и дорогая.
Плюсы и минусы реляционных баз данных
Реляционные БД удобные и быстрые, но недостатки у них тоже есть.
Основные преимущества: надёжность, безопасность, гибкость запросов
Плюсов больше, чем минусов.
Данные удобно структурированы: таблицы удобно читать, дополнять, организовывать.
Реляционные базы данных надёжны, потому что каждая операция в них или выполняется полностью или не выполняется совсем. Это добавляет целостности.
Для работы используется язык запросов SQL, очень удобный инструмент, который позволяет извлекать и комбинировать данные почти как угодно.
Первичные и внешние ключи защищают от создания противоречивых данных. Например, в магазине нельзя будет создать заказ без клиента.
Недостатки и ограничения
У реляционных баз данных почти единственный минус: их сложно масштабировать.
Масштабирование — это способ увеличить производительность системы, когда данных и пользователей становится много. Есть вертикальное и горизонтальное масштабирование:
- При вертикальном масштабировании увеличивают мощность одного сервера — добавляют память, более мощный процессор и вместительный жёсткий диск. Это легко сделать, но мощность одного сервера нельзя повышать бесконечно. Ещё если с ним что-то случится, то все данные потеряются.
- При горизонтальном добавляют новые серверы. Тогда систему можно увеличивать бесконечно и, если один из серверов выйдет из строя, другие продолжат работать.
Большим корпорациям нужно горизонтальное масштабирование, и вот тут у реляционных баз начинаются проблемы: они зависят от связей между таблицами и, если их распределить по разным серверам, это нарушает целостность работы и связи ломаются.
Чтобы база данных SQL работала как единое целое на разных серверах, нужна сложная координация. У нереляционных баз такой проблемы нет.
Кто работает с базами данных
Ещё несколько лет назад мы бы сказали, что только бэкенд-разработчики.
Но сегодня IT-направление настолько выросло, что с БД работает много разных других специалистов: администраторы баз данных, дата-инженеры, аналитики данных и специалисты Data Science.
Во всех этих профессиях есть свои интересные нюансы. Если хотите вникнуть в какую-то из специальностей поглубже, приходите на курсы Практикума. Попробуйте бесплатные части, почитайте другие наши статьи про разные профессии — почти наверняка найдёте что-то интересное для себя.
Полезный блок со скидкой
Если вам интересно разбираться со смартфонами, компьютерами и прочими гаджетами и вы хотите научиться создавать софт под них с нуля или тестировать то, что сделали другие, — держите промокод Практикума на любой платный курс: KOD (можно просто на него нажать). Он даст скидку при покупке и позволит сэкономить на обучении.
Бесплатные курсы в Практикуме тоже есть — по всем специальностям и направлениям, начать можно в любой момент, карту привязывать не нужно, если что.
Бонус для читателей
Скидка 20% на все курсы Практикума до 30 ноября! «Чёрная пятница» и такие скидки бывают раз в год.
Вам слово
Приходите к нам в соцсети поделиться своим мнением о статье и почитать, что пишут другие. А ещё там выходит дополнительный контент, которого нет на сайте — шпаргалки, опросы и разная дурка. В общем, вот тележка, вот ВК — велком!
