Реляционные базы данных: объяснение для непрограммистов

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

Что такое база данных в ноукоде

В классическом программировании база данных – это тяжёлая для понимания и создания вещь. Это цифры и теги, это отдельный язык, который надо знать.

Ноукод проще. База данных в ноукодинге – это реальные, осязаемые и понятные данные. Это имена и фамилии, слова и тексты, изображения, даты, время, цены и цифры. Записано это в базы данных в «первозданном» виде – буквами и цифрами.

Если открыть базу данных созданного на ноукоде продукта, там всё понятно. Перед вами будут таблицы. Колонки озаглавлены логично и знакомо, например, «Имя и фамилия клиента» или «Стоимость услуги»  – обозначениями пользователей, объектов, вещей, событий, явлений. А в строках таблицы будут сами данные – имена (Иван Иванов), цена (200 руб.) и так далее. 

Что такое реляционная база данных 

Реляционная база данных – набор данных из нескольких таблиц, связанных между собой.

Подобно тому как в одной таблице строки и столбцы связаны между собой – так в реляционных базах данных между собой связаны таблицы.

Установление связи происходит через единое свойство – его называют ключ. 

Рассмотрим на примере.

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

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

Это простейший пример связи в базах данных в ноукоде. Теперь поговорим о более сложных типах связей.

4 типа связей реляционных баз данных 

В реляционных баз данных есть 4 типа связи, которые имеют общепринятые названия и содержание. Их названия-определения:

• один-к-одному
• один-ко-многим
• многие-к-одному
• многие-ко-многим

Тип связи один-к-одному

Одна единица данных в одной таблице связана только с одной единицей данных в другой таблице. Одна строка в одной таблице относится к одной строке в другой таблице. 

Пример со студентами тут поворачивается так. Одна таблица – со студентами – связана через строчку «Номер студбилета» с таблицей, где собраны номера студбилетов студентов. У одного студента есть только один номер студбилета. Один номер студбилета принадлежит только одному студенту.  

Тип связи один-ко-многим

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

Вновь пример со студентами. В таблице с группами есть куратор. У каждой группы есть один куратор – но у этого куратора в ведении много студентов. Он помогает им решить проблемы с сессиями, найти общежитие, разобраться в конфликте с преподавателем, к примеру. В общем, куратор у студентов один, а студентов у куратора много. 

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

Тип связи многие-к-одному

Построение этого типа связи похоже на предыдущий тип, но работает в обратном направлении – и есть первичная и второстепенная таблица. Здесь связь выстраивается от более важной таблицы к менее важной.

В примере со студентами это выглядит примерно так. У студентов есть периоды сессий – для каждой группы свои. Сроки сессий – это отдельная таблица. Для одной строки – каждого периода – будет много студентов. У каждого периода сессии – много студентов, а у каждого студента – только одна сессия. 

Тип связи многие-ко-многим

В этом типе связей много строк в одной таблице имеет связь со многими строками в другой таблице. 

На примере с университетом опишем так. Кураторов в университете много, каждый принадлежит к определённой кафедре – но куратор одной группы может принадлежать к той же кафедре, к которой принадлежит куратор другой группы. Таким образом, на кафедре числится много кураторов групп – и получается, что к одной кафедре имеет отношение много групп. 

Приведём тут ещё один пример связи многие-ко-многим. Такая связь могла бы быть установлена между таблицей студентов и таблицей занятий, на которые они ходят. У одного студента много занятий, и на занятия приходит много студентов. 

Почему нельзя создать просто одну огромную таблицу

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

• Точность данных. В реляционной базе данных с настройкой связей по ключу снижается риск задвоения данных. Вы вводите данные один раз, дробя их на отдельные единицы – и избегаете дублей и разных форматов написания данных.
• Доступ к данным. В реляционной базе данных легко фильтровать, сортировать, искать данные. Тоже потому что они раздроблены на единицы.
• Гибкость. Будет очень легко расширять таблицы, добавляя новые типы данных и сами данные в будущем. Вы не запутаетесь в бесконечном скролле одной большой таблице и в попытке разобраться, что и куда запихивать.
• Меньшая нагрузка на систему платформы. Системе проще обращаться к небольшим таблицам, чем анализировать одну большую. Платформа будет меньше тормозить.

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

Чем больше вы узнаёте о том, как устроена разработка айти-продуктов – пусть даже разработка без кода – вы лучше разбираетесь в целом в разработке, и любой ваш продукт становится мощнее.