Составление баз данных – непростая тема в разработке и в ноукодинге. Наши ученики говорят, что понять тему данных особенно трудно. Рассказываем, что такое реляционные базы данных, как их делать, как структурировать и почему лучше разобраться с ними, чем жить без них.
Что такое база данных в ноукоде
В классическом программировании база данных – это тяжёлая для понимания и создания вещь. Это цифры и теги, это отдельный язык, который надо знать.
Ноукод проще. База данных в ноукодинге – это реальные, осязаемые и понятные данные. Это имена и фамилии, слова и тексты, изображения, даты, время, цены и цифры. Записано это в базы данных в «первозданном» виде – буквами и цифрами.
Если открыть базу данных созданного на ноукоде продукта, там всё понятно. Перед вами будут таблицы. Колонки озаглавлены логично и знакомо, например, «Имя и фамилия клиента» или «Стоимость услуги» – обозначениями пользователей, объектов, вещей, событий, явлений. А в строках таблицы будут сами данные – имена (Иван Иванов), цена (200 руб.) и так далее.
Что такое реляционная база данных
Реляционная база данных – набор данных из нескольких таблиц, связанных между собой.
Подобно тому как в одной таблице строки и столбцы связаны между собой – так в реляционных базах данных между собой связаны таблицы.
Установление связи происходит через единое свойство – его называют ключ.
Рассмотрим на примере.
Мы делаем приложение для студентов университета. Есть база данных со студентами, группами, кураторами. Есть таблица со студентами – к каждому студенту там записаны имя и фамилия, номер студенческого, группа, средняя оценка успеваемости. Есть таблица с группами – на группу есть номер группы, количество студентов, сами студенты, куратор. В таком случае таблица со студентами связана с таблицей с группами через номер группы. Номер группы – ключ, через который установлена связь.
Это простейший пример связи в базах данных в ноукоде. Теперь поговорим о более сложных типах связей.
4 типа связей реляционных баз данных
В реляционных баз данных есть 4 типа связи, которые имеют общепринятые названия и содержание. Их названия-определения:
- один-к-одному
- один-ко-многим
- многие-к-одному
- многие-ко-многим
Тип связи один-к-одному
Одна единица данных в одной таблице связана только с одной единицей данных в другой таблице. Одна строка в одной таблице относится к одной строке в другой таблице.
Пример со студентами тут поворачивается так. Одна таблица – со студентами – связана через строчку «Номер студбилета» с таблицей, где собраны номера студбилетов студентов. У одного студента есть только один номер студбилета. Один номер студбилета принадлежит только одному студенту.
Тип связи один-ко-многим
В этом типе данных одна строка с информацией связана со многими строками в другой таблице.
Вновь пример со студентами. В таблице с группами есть куратор. У каждой группы есть один куратор – но у этого куратора в ведении много студентов. Он помогает им решить проблемы с сессиями, найти общежитие, разобраться в конфликте с преподавателем, к примеру. В общем, куратор у студентов один, а студентов у куратора много.
Тип связи многие-к-одному
Построение этого типа связи похоже на предыдущий тип, но работает в обратном направлении – и есть первичная и второстепенная таблица. Здесь связь выстраивается от более важной таблицы к менее важной.
В примере со студентами это выглядит примерно так. У студентов есть периоды сессий – для каждой группы свои. Сроки сессий – это отдельная таблица. Для одной строки – каждого периода – будет много студентов. У каждого периода сессии – много студентов, а у каждого студента – только одна сессия.
Тип связи многие-ко-многим
В этом типе связей много строк в одной таблице имеет связь со многими строками в другой таблице.
На примере с университетом опишем так. Кураторов в университете много, каждый принадлежит к определённой кафедре – но куратор одной группы может принадлежать к той же кафедре, к которой принадлежит куратор другой группы. Таким образом, на кафедре числится много кураторов групп – и получается, что к одной кафедре имеет отношение много групп.
Приведём тут ещё один пример связи многие-ко-многим. Такая связь могла бы быть установлена между таблицей студентов и таблицей занятий, на которые они ходят. У одного студента много занятий, и на занятия приходит много студентов.
Почему нельзя создать просто одну огромную таблицу
При первой попытке разобраться в теме баз можно запутаться, устать и захотеть сделать одну большую таблицу с данными. Это правда большой соблазн. Но надо держать себя в руках и стараться наоборот дробить большие таблицы на маленькие, соединяя их ключами. И вот 4 причины зачем.
- Точность данных. В реляционной базе данных с настройкой связей по ключу снижается риск задвоения данных. Вы вводите данные один раз, дробя их на отдельные единицы – и избегаете дублей и разных форматов написания данных.
- Доступ к данным. В реляционной базе данных легко фильтровать, сортировать, искать данные. Тоже потому что они раздроблены на единицы.
- Гибкость. Будет очень легко расширять таблицы, добавляя новые типы данных и сами данные в будущем. Вы не запутаетесь в бесконечном скролле одной большой таблице и в попытке разобраться, что и куда запихивать.
- Меньшая нагрузка на систему платформы. Системе проще обращаться к небольшим таблицам, чем анализировать одну большую. Платформа будет меньше тормозить.
В общем, реляционные базы данных, на первый взгляд, кажутся сложными. Но эти 4 причины доказывают – система связей наоборот сильно упрощают жизнь разработчику, и лучше действительно один раз разобраться и установить эти системные связи, а потом управлять ими и создавать рабочее приложение.
Чем больше вы узнаёте о том, как устроена разработка айти-продуктов – пусть даже разработка без кода – вы лучше разбираетесь в целом в разработке, и любой ваш продукт становится мощнее.
