Разработка, Технический дизайн 8-10 минут на прочтение

Дизайн данных (часть 5). Матчасть: базы данных.

Поделиться:

Те, кто читает мой цикл про дизайн данных регулярно, уже наверняка приметил, что каждую статью я начинаю с того, что советую сперва ознакомиться с первыми частями. Делаю я это по понятным причинам: если сразу залезть в дебри, можно очень быстро растерять мотивацию, ибо нифига не понятно. А чтобы не пришлось ковыряться в блоге, вот ссылки:

В прошлый раз мы говорили про самый базис матчасти: хранение, передачу информации, типы данных. Так вот эта статья будет посвящена именно хранению информации в БД, а следующая — передаче данных по API.

Мы не будем упарываться и съедать мозг сложными техническими историями — чаще всего продуктовому дизайнеру достаточно лишь верхнеуровневого понимания работы и различий между базами данных.

Зачем это дизайнеру

Затем же, зачем и остальной data design. Понимая, каким образом данные могут храниться и соотноситься между собой, грамотный продуктовый дизайнер может выстроить определенную модель отношений между сущностями в проекте. Стабилизация дальнейшей разработки стоит того, чтобы в самом начале потратить немного времени на выбор, например, подходящего типа БД.

При этом я вовсе не призываю всех дизайнеров бросать фигму и мчаться проектировать базы данных. Чаще всего, этим должен заниматься более технически подкованный человек (архитектор или даже специальный «дизайнер баз данных» — такой тоже есть). Однако понимание основ такого проектирования позволит существенно упростить работу этого самого архитектора. А заодно сделать более качественно проработанный продукт.

Немного вводных

Для начала — давайте вкратце пройдёмся по терминологии.

СУБД

Как я уже рассказывал в предыдущей статье, для управления базами данных требуется определённый софт. Без него БД — это просто файлы. Которые, к тому же, нельзя открыть обычными программами, вроде блокнота (чаще всего). Этот софт, необходимый для манипуляций с базами данных, называется СУБД — Системы Управления Базами Данных. Они позволяют создавать базы, структурировать, изменять/удалять/добавлять данные, защищать их и так далее.

Связи

Данные в БД должны быть связаны друг с другом. В основном, используются три вида таких связей:

  • связь «один к одному»;
  • связь «один ко многим»;
  • связь «многие ко многим».

В чем их различие, понятно из названия. Но я всё равно немного расскажу об этом.

Один к одному

Этот тип связи встречается редко. И является, чаще всего, ошибкой проектирования.

При связи «один к одному» объект из одной части БД может быть связаны только с одним объектом из другой части. Сложно, поэтому покажу на примере.

Классический пример связи «один к одному» — это серия и номер паспорта. Здесь каждый номер привязан к серии и наоборот. Серия паспорта без номера бессмысленна, равно как и номер без серии.

Связь "один к одному"
Связь «один к одному»

Как я уже говорил, чаще всего это ошибка проектирования. Куда правильнее сделать элемент «паспорт» со свойствами «серия» и «номер».

Один ко многим

В этом случае один объект может быть связан с одним или несколькими объектами в другой части БД. Но эти «вторые» объекты могут связаны только с одним «первым» объектом. Давайте снова на примере.

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

Связь "один ко многим"
Связь «один ко многим»

Многие ко многим

Этот тип связи походит, когда связи могут «перекрещиваться» — когда один объект может иметь отношение к нескольким объектам из другой части БД, но и эти «вторые» объекты могут относиться к нескольким «первым» объектам.

Хороший пример — кино и актёры. В одном фильме могут сниматься несколько актёров (множественная связь «фильм-актёр»), но и у одного актёра может быть несколько фильмов, в которых он снимался (множественная связь «актёр-фильм»).

Связь "многие ко многим"
Связь «многие ко многим»

Такой тип связи очень популярен в реляционных БД, о которых мы поговорим ниже.

Виды баз данных

Все БД можно очень чётко разделить на виды — в зависимости от модели данных, которую они используют.

Иерархическая БД

В иерархической БД данные хранятся, как папки на компьютере: всегда есть родительские элементы, а есть дочерние. Этот вид является самым «древним» — первые БД были преимущественно именно иерархическими. В современном мире они применяются редко, разве что для очень специфических задач.

Структура иерархической базы данных
Структура иерархической базы данных

Здесь нельзя выстроить связи между данными типа «многие ко многим» — а это очень часто требуется в проектировании. Отчасти поэтому иерархический вид БД не особенно популярен.

Пример иерархической БД - реестр Windows
Классический пример иерархической БД — реестр Windows.

Иерархические БД следует использовать только в том случае, когда данные в вашем проекте всегда подчиняются строгой иерархии, а неожиданных связей между ними не возникнет даже при развитии системы.

Пример СУБД для иерархической базы данных — IMS от IBM.

Сетевая БД

Сетевая база данных — это те же иерархическая, но на стероидах. В ней можно устанавливать какие угодно связи: дочерний объект может обращаться к «предку предка» напрямую, минуя лишние шаги.

Здесь (обычно) тоже нельзя использовать связи типа «многие ко многим», но это компенсируется скоростью работы с большим количеством связанных данных.

Структура сетевой базы данных
Структура сетевой базы данных

Сетевые БД стоит использовать, если в вашем проекте большое количество связей между объектами, и эти связи реально сложны и запутаны.

Отдельного упоминания заслуживают так называемые «графовые» БД — разновидность сетевых. Не буду на них останавливаться, если интересно, загуглите сами.

Пример сетевой графовой СУБД, распространяемой по свободной лицензии — OrientDB.

Реляционная БД

Самый распространённый вид баз данных. Особенность реляционных БД в чёткой и понятной структуре информации, представленной в виде двумерных таблиц. В каждой такой таблице есть строки (собственно, объекты данных) и столбцы (свойства этих объектов). При этом столбцы, как правило, подчиняются очень чёткой типизации: конкретный столбец может содержать только один тип данных — например, строку или число. При этом одинаковых строк (элементов) в таблице не может быть.

На рисунке ниже «столбцы» представлены «строками» не только для удобства восприятия, но и потому что именно так обычно визуализируются реляционные БД (об этом я расскажу чуть ниже).

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

Вот так выглядит реляционная база данных в редакторе. По сути, каждая такая БД — это просто список тех самых двумерных таблиц:

Таблицы реляционной БД
Таблицы реляционной БД

А вот пример структуры отдельной таблицы. Слова «meta_id», «post_id», «meta_key» и «meta_value» — это те самые «столбцы», которые несут в себе свойства элементов:

Структура таблицы реляционной БД
Структура таблицы реляционной БД

И вот, наконец, уже сами данные этой самой таблицы. Здесь строки — это элементы (объекты данных), а у столбцов «meta_id», «post_id», «meta_key» и «meta_value» есть конкретные значения — свойства этих элементов:

Данные отдельной таблицы реляционной БД
Данные отдельной таблицы реляционной БД

Если данные в вашем проекте структурированы, по ним нужен быстрый поиск, то ваш выбор однозначно должен пасть на реляционную БД. Да и вообще, если сомневаетесь — используйте именно этот вид.

Сейчас самая популярная реляционная СУБД — MySQL от Oracle.

Остальные виды

На самом деле, существует еще довольно много других видов БД: объектно- или документо-ориентированные, функциональные и разные смеси, вроде объекто-реляционных баз. Но это, чаще всего, диковинки, заточенные под выполнение конкретных, довольно специфических задач. Но если тема вас зацепила, можете погуглить.

Визуализация

Результатом проектирования БД должен стать какой-то графический или текстовый объект — здесь всё понятно. Обычно это схема или несколько таблиц, связанных между собой. Человечество придумало огромное количество способов передать структуру данных, но наибольшее распространение получила так называемая ER-модель (её ещё называют ER-диаграммой).

По сути, это и есть диаграмма, в которой указаны все элементы, свойства и связи между ними. Стилизованную ER-диаграмму вы можете увидеть на всех миниатюрах к этому циклу статей. Вот она без лишней графики:

ER-диаграмма
Пример ER-диаграммы

А вот — настоящая ER-диаграмма (к слову, отнюдь не самая большая):

ER-диаграмма
ER-диаграмма

Наверное, стоило бы рассказать про ER-модель поподробнее, но мне, признаться, лень создавать еще один материал на эту тему. Нотация описана уже миллион раз и без проблем гуглится.

В заключение

Конечно, это только начало. Я многое не рассказал, и не собираюсь — просторы интернета ломятся от серьезных, вдумчивых статей про базы данных. Но подступаться к ним с нулевого уровня знаний всегда очень сложно. Теперь же вы хотя бы немного погружены в контекст. Хотя бы понимаете, куда копать — если захотите, конечно.

Следующие статьи цикла:

4.9/5 (21 голос)
, Ваша оценка:

Комментарии (1)

Василий Туркин
Спасибо за статью! И за весь цикл. Это прям находка))

Добавить комментарий

Чтобы оставить комментарий, войдите:
Нет соединения с сервером.Сервер получил неверные данные, попробуйте еще раз.

Похожие посты

Top