Ну что, пришло время занудствовать на тему реляционных баз данных. Хорошо быть занудой или нет я не знаю, но точно знаю что без понимания основ СУБД далеко не уедешь.
Основы реляционных баз данных преподают в университетах, начиная со 2-3 курса (по-разному, в зависимости от программы). В непосредственном моменте обучения, теория р-СУБД выглядит совершенно бездушной, безнадёжно устаревшей, скучной и "и так понятной". Спустя же годы практики, так или иначе приходится возвращаться к основам теории, и сопоставлять эту самую скучную теорию с реальной производственной необходимостью. Так что, уважаемый Войтишник - не игнорируй теорию, хотя бы в базовой части - она важна и нужна!
Когда-то давно, в течение нескольких лет подряд, меня активно интересовало устройство баз данных изнутри. В те весёлые годы я прокопал устройство различных СУБД достаточно глубоко. Попустило меня где-то на уровне алгоритмов для физического хранения данных на дисках. С тех пор, в любой непонятной ситуации и спорах вокруг баз данных, я с удовольствием заваливаю оппонентов умными высказываниями на эту тему. Так что, мне определённо есть что рассказать!
Важный момент. В комментариях к прошлым статьям, кто-то писал что не едиными реляционными базами живёт современный IT мир. Это действительно так. Но обратимся к статистике! На основе данных исследований и отчетов за предыдущие годы, можно приблизительно оценить долю рынка именно реляционных баз данных. Например, по данным от Gartner на 2020 год, реляционные базы данных составляли около 70% от общего рынка баз данных (70%, КАРЛ!).
Таким образом, на мой субъективный взгляд, в современном мире именно на реляционных СУБД держится хранение большей части существующей информации. Банки, госучреждения, больницы, малый и средний бизнес. Даже 1С в определённой степени является реляционной базой данных (оболочкой над реляционной базой данных).
Так вот, давай разбираться что же это за слово такое непонятное, и как оно относится к реальной жизни.
Почему реляционные базы данных называют реляционными? 🔌
Слово "Реляционные" звучит как-то космически, правда? На самом же деле, оно описывает вполне понятные и простые вещи. Есть такое слово английское, "relation" - которое переводится как "отношения, связь, родство". Смысл этого слова в применении к СУБД можно объяснить как-то так: "Данные, которые находятся внутри базы данных, очень желательно должны быть связаны между собой, а не просто болтаться в пустоте".
Иначе говоря, данные должны относиться друг к другу по каким-то признакам, принципам, механизмам. Короче, данные должны иметь между собой "отношения" - то есть relations. В оригинальном переводе с Английского на Русский, следовало бы назвать реляционные базы данных "отношенческими базами данных". Но что-то это как-то слишком странно звучит, по-этому остановились на прямой танслитерации - как слышится, так и пишется - relational - реляционные. "Allow, Allow, Ya vas ne slishu, perezvonite!"
Иными словами, смысл реляционных баз данных - в связности данных между собой. Когда в базу добавляется какая-то информация, то она является связанной с другой информацией, или самой с собой в рамках добавляемого объекта данных. И обратная логика здесь в том, что при поиске данных в базе, мы находим зависимости между существующими данными, и извлекаем из базы какую-то целостную информацию, а не просто сырые "куски" данных.
Кто и когда придумал реляционные базы данных? 🧐
Реляционная модель данных была предложена в 1970-х годах американским ученым Эдгаром Коддом. Он предложил использовать математическую теорию множеств и предикатов для описания и манипулирования данными.
В 60-х и 70-х годах Эдгар Кодд работал над своими теориями хранения данных. В июне 1970 года он опубликовал работу под названием "A Relational Model of Data for Large Shared Data Banks", которая считается первой работой по реляционной модели данных. Вот оригинал этой работы в PDF-формате - скачай, переведи и почитай если интересуешься.
После этого Кодд продолжал разрабатывать и расширять реляционную модель. Одна из нормальных форм данных была названа в его честь и известна как Нормальная форма Бойса-Кодда.
В начале 80-х годов реляционная модель стала достаточно популярной. На то время на рынке уже присутствовали разработчики СУБД. Некоторые из них, недолго думая и видимо рассчитывая на лояльность уже имеющейся аудитории, стали заявлять что их СУБД и так поддерживают реляционность (хотя это было не всегда так). На что Эдгар Кодд поступил достаточно просто - и выпустил разъясняющие правила в количестве 12 штук, которые позволяли легко понять, является СУБД реляционной или нет. Вот ссылка на эти правила в вики, можно почитать формальное описание реляционной СУБД.
Таблица - основа реляционной базы данных 📝
Значительно упрощая терминологию СУБД, скажу так. Основа любых реляционных баз данных - это "таблица". По аналогии с Excel, таблица представляет из себя набор строк и набор столбцов, пересекающихся внутри условных "ячеек".
Таблица всегда характеризует один тип объектов, без условного разделения на "листы" как это бывает в Excel. Внутри такой таблицы должен быть представлен один набор предсказуемых данных, как-то соотносящихся между собой. Каждая строка - это объект некоторого типа. Ну и пожалуй, перейдем от умных слов к живым примерам.
Допустим, у нас есть некоторая таблица внутри СУБД, которая называется "Люди". Допустим что мы будем хранить там данные некоторых живых людей. В этом случае, у такой таблицы могут быть столбцы "Возраст", "Имя", "Фамилия", "Год рождения", "Пол", "Место жительства". Соответственно, если внутри таблицы будут заполнены 10 строк - то они будут представлять собой 10 разных людей, с разными данными. Одна строка такой таблицы "объединит общими отношениями" все столбцы для конкретного человека - возраст, год, пол, и так далее. Это и следует понимать как "реляционность" - то есть общность разных столбцов, которые объединяет одна родительская сущность. В нашем случае, человек.
Отношения между таблицами 🤝
В отличие от условного Excel, реляционные базы так же могут объединять строки в разных таблицах. То есть, на уровне базы данных можно устанавливать отношений между разными таблицами, через специальные "ключи". Представим себе, что в ячейке Excel есть кнопка "подробнее", при нажатии на которую открывается другой файл, и подсвечивает какую-то строку, относящуюся к тому на что мы кликнули.
Отношения между таблицами - это вторая важная особенность реляционных СУБД. Когда создаётся некоторая база данных, то иногда прописываются отношения между входящими в неё таблицами (если конечно таблицы являются связанными друг с другом). В таком случае, реляционность базы проявляется не только на уровне ячеек внутри таблицы, но и на уровне таблиц по отношению друг к другу.
При наличии связей между таблицами, SQL-запросы позволяют извлекать комплексные наборы данных (а не только какие-то части каких-то таблиц). SQL запросы для соединения нескольких таблиц между собой вообще являются отдельной философией и отдельной большой темой. Вероятно я расскажу об этом чуть подробнее, в следующих статьях.
Практика проектирования СУБД 🤦♂️
Особенность хороших реляционных баз данных в том, что их надо уметь правильно проектировать. Точно так же как и программный код - его можно написать хорошо или плохо, понятно или непонятно. Аналогичным образом эти принципы применимы к созданию баз данных.
Из личной практики. Когда я начинаю работу над каким-то проектом или делаю аудит какой-то существующей системе, то в первую очередь стараюсь смотреть на базу данных. На структуру таблиц, их связи друг с другом. И знаешь уважаемый читатель, я видел всякое 😳
Как правило, проекты в рамках малого и среднего бизнеса, сделаны из рук вон плохо. Нет ни описания таблиц, ни какой-то фундаментальной логики связности этих таблиц между собой. Принципы реляционных СУБД игнорируются вдоль и поперёк. Для того, чтобы понять изначальные идеи автора, часто приходится выискивать этого самого автора и устраивать с ним очную ставку.
Исходя из этого, следует простой и логичный совет - прежде чем начинать создавать архитектуру базы данных, задай себя вопрос - "не делаю ли я сейчас полную ерунду". И если ты не уверен в ответе, лучше отложить этот этап работ, и подумать ещё чуть-чуть.
Применение реляционных СУБД 📖
В общем и целом, реляционные базы данных применяются практически везде. Любая современная программа хранит в своей базе данных десятки или даже сотни таблиц. Таблицы так же связываются между собой различными отношениями, специальными функциями, правилами работы. И в конечном итоге, программы обращаются к таким таблицам на языке SQL.
С точки зрения программ, СУБД служит единой точкой входа, которая быстро находит нужные записи в нужных таблицах, или добавляет новые записи. Программа может включаться и выключаться, глючить или работать странно. А вот СУБД - работает практически всегда, надёжно сохраняя добавленные данные в таблицах и управляя ими.
Инженеры по СУБД получают порядка 200-500т.р. в месяц, в зависимости от направления, опыта и места трудоустройства. Хороших специалистов по базам данных так вообще - единицы.
Поэтому, если ты хочешь связать свою жизнь с высокооплачиваемой обработкой данных, хранением и анализом больших массивов информации - рекомендую посмотреть в сторону реляционных баз данных в общем смысле, и СУБД PostreSQL / MySQL / Oracle в частности. Успехов!
🔥 Понравилось? Подпишись! Победим восстание роботов вместе! 🔥
🚀 P.S. Ты можешь круто поддержать меня и проект "Войти в IT" на boosty! Я публикую там более эксклюзивный и профессиональный, иногда немного личный контент. Хочешь посмотреть как я выгляжу в реальной жизни? Тогда жми: Ссылка 🚀
P.S.2 У меня ещё есть Telegram-канал. Там посты чуть попроще, и чуть повеселей. Ссылка
P.S.3 Если тут есть специалисты по базам данных - предлагаю делиться в комментах самыми необычными историями про базы данных, которые с Вами случались. Личная история - дропнул базу с объемом данных в 2 месяца, следом за ней не отходя от кассы, убил хранилку бэкапов. Было очень стыдно и больно, как морально так и финансово 😄