что такое реляционные активы

Отличия реляционных и нереляционных баз данных

С обработкой и хранением данных сегодня связаны любые компьютерные работы. Одна информация может быть представлена в форме таблиц, иметь четкие, структурированные сведения, поданные в определенном формате. Другие же, описывают самые разные объекты, с произвольными характеристиками. Они не имеют структуры, четкого распределения, формата. Исходя из этого в IT-среде выделяют два варианта баз данных (БД): реляционные (SQL) и нереляционные (NoSQL). Говоря простым языком, первые – структурированные, а вторые – неструктурированные. Оба варианта жизнеспособны, но имеют кардинальные расхождения, которые надо учитывать в процессе выбора БД. Так в чем отличие реляционной базы от нереляционной и для решения каких задач лучше всего подходит каждая из них.

Чтобы ответить на этот вопрос, необходимо познакомиться более подробно с каждой из них.

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

Система управления базами данных (СУБД) – передовое программное обеспечение высокого уровня, работающее с API низкого уровня. Под данным термином понимают всевозможные инструменты, начиная от компьютерных приложений и до встроенных библиотек. Если говорить о реляционной системе, то она помогает управлять большими объемами четко структурированных данных. Преимущественно представлена в табличной форме. В строках указываются записи, а в столбцах – типы данных. При этом информация вносится в таблицу согласно установленному шаблону.

Впервые реляционная модель вошла в использование в 70-е годы 20 века. Предполагала математический способ для структуризации, хранения и применения сведений. В таблицы записывалась основная информация (например, ФИО человека) и соответствующие ей значения (год рождения, возраст, пол, семейное положение, наличие/отсутствие детей и пр.). За годы существования на рынке она успела доказать свою эффективность, надежность, гарантируя высокую защиту информации от утраты. Наряду с жесткими требованиями к формированию данных и их обработки, SQL может быть наделена и гибкостью. Но обеспечить это свойство сможет только профессиональный подход и дополнительные усилия.

Среди особенностей реляционных БД стоит выделить два основных момента:

Соблюдать целостность в процессе каждой транзакции, реляционные базы данных должны быть:

Краткий итог: реляционные БД в работе используют язык структурированных запросов, при помощи которого обрабатывают данные и управляют ими. Он подходит для любых запросов в том числе и сложных, но есть и ограничения. В SQL применяются только схемы, заданные наперед, чем достигается высокая согласованность. Также требуется заранее определять структуру данных, подстраивая их к некому «стандарту». Реляционную базу можно масштабировать по вертикали, увеличивая нагрузку на каждый отдельный server. В результате повысится мощность центрального процессора, оперативной памяти, твердотельного диска.

Источник

Заметки Датасатаниста: реляционные vs связанные данные

Сегодня мы поговорим о простой, казалось бы, теме, как реляционные и связанные данные.

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

Мы обсудим, что такое реляционная модель и связанные с ней SQL и реляционная алгебра. Потом перейдем к примерам связанных данных из Викидата, а далее RDF, SPARQL и чутка поговорим про Datalog и логическое представление данных. В конце выводы — когда применять реляционную модель, а когда связно-логическую.

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

Если у вас есть сомнения, чем одно отличается от второго и зачем вообще нужны связанные данные (LinkedData), то добро пожаловать под кат.

Реляционные данные

Начнем со стандартного определения

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

В такой ситуации, единицей моделирования является таблица и связи между таблицами (как например внешние ключи). По сути — таблица это предикат с фиксированными атрибутами т.е. мы всегда знаем арность табличного предиката.

Приведем в качестве примера связей ограничений внешний ключ: ключ “p(_, X, _) → q(_, Y, _)”, который задает ограничения в виде X \subset Y, где X — это атрибут отношения p, а Y атрибут отношения q.

Еще более важно, что по сути в мире реляционных данных — у нас все таблица! И операции берут на вход таблицу и возвращают таблицу, например:

Язык реляционных данных: SQL и реляционная алгебра

Реляционная алгебра (алгебра Кодда) — это по сути набор операций над таблицами, которые возвращают таблицы. То есть, для вас центральным элементом моделирования являются именно фиксированные таблицы и их преобразования.

Язык SQL — это декларативная надстройка и конкретная имплементация идей реляционной алгебры.

Пример простого запроса и соответствующие ему реляционные операторы из алгебры.

Пока все, что мы рассмотрели это классические вещи, которые мы знаем из любого курса по базам данных.

Связанные данные (linked data) и графы знаний (knowledge graphs)

Просто представим, что будет, если у нас появляются новые свойства и это происходит, возможно, в режиме реального времени? То есть домен не фиксированный — а гибкий и расширяемый?

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

Представьте, что вы моделируете жизнь людей во всех ее возможных аспектах. Даже два разных человека у вас будут иметь достаточно разный набор ключевых свойств и это абсолютно нормально!

У вас нет фиксированного списка того, как будет описан конкретный персонаж Писатель и Футболист — это два Человека, которые имеет немало важных, но, тем не менее, разных свойств.

Начнем с писателя Дугласа Адамса — верхние свойства довольно типичны для любого человека — здесь и далее мы используем Wikidata в качестве примера LinkedData.

www.wikidata.org/wiki/Q42

Но копнем чуть глубже и

и видим набор свойств, который будет существенно отличаться от, например, Диего Марадонны

Поговорим чуть подробнее о свойствах указанных здесь. Например, свойство gender: male

По сути является отражением логического факта: p21(Q42, Q6581097).

Где p21 → это gender_identity/2 — бинарный предикат
Q42 → дуглас адамс
Q6581097 → male

Таким образом все данные представлены в виде либо унарных предикатов, например is_dead(Q42), либо в виде бинарных p21(Q42, Q6581097).

По сути это другая парадигма парадигма моделирования — логика первого порядка, но на унарных и бинарных предикатах.

И здесь очень просто добавлять новые данные: все, что не указано в виде предиката над объектами — это false, в литературе это известно, как Closed-world assumption.

Более того данный формат допускает абсолютно естественное мета-моделирование

https://www.wikidata.org/wiki/Q42395533

Есть несколько основных хранения и написания запросов к таким данным — разберем популярные опции.

RDF и Язык запросов SPARQL

RDF — это формальный язык описания связанных данных для последующей обработки с помощью запросов, то есть это машиночитаемый формат.

По сути для него ключевые является понятие тройки:

И вот пример записи данных в данной моделе (префиксы определяют, где лежат “описания” данных предикатов)

Этот формат записи позволяет графически изображать данные об объектах — например, так можно записать информацию о городе Берлин.

Для формата RDF создали языка запросов SPARQL: который по сути описывает ограничения на логические предикаты и говорит, какую переменную из логического выражения надо извлечь:

В настоящем коде это может выглядеть следующим образом:

Итого: RDF — это формат представления данных в виде троек (бинарные предикаты) и SPARQL — это язык запросов к тройкам на основе логики.

Язык запросов Datalog и производные

Также для написания запросов к RDF (и не только к нему, об этом позже) можно использовать Datalog — декларативный (часто) язык, который синтаксически представляет собой подмножество Prolog (чаще всего).

В нем запросы имеют следующий вид:

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

Еще одно важное преимущество логических языков запросов на основе Datalog — для них RDF — это просто формат записи фактов (утверждений) бинарной логики. С таким же успехом они могут обрабатывать и любые другие логические утверждения — совершенно необязательно бинарные.

Выводы

Во-первых, реляционные данные хорошо подходят для моделирования фиксированных доменов, где схема либо меняется редко, либо изменения касаются не просто единичных записей, а целых сегментов.

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

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

В-четвертых, стандартным представлением является RDF и его имеет смысл попробовать в первую очередь. Прикрутив к нему нужные базы и используя SPARQ-образные языки, можно извлекать нужные данные.

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

Источник

SQL и NoSQL: инь и ян в мире баз данных

SQL или NoSQL — вот в чём вопрос. Чем они различаются? Это конкуренты или сотрудники? Что о них спрашивают на собеседовании?

Про реляционные и нереляционные СУБД на техническом интервью спрашивают часто, причём не только администраторов баз данных, но и бэкенд-разработчиков, тестировщиков, специалистов по кибербезопасности, аналитиков и много кого ещё.

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

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

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

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

Программист, консультант, специалист по документированию. Легко и доступно рассказывает о сложных вещах в программировании и дизайне.

Реляционную модель данных придумал Эдгар Кодд ещё в семидесятых годах прошлого века.

Математик по образованию, он предложил использовать для обработки данных аппарат теории множеств.

Кодд доказал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, который в математике называется отношением (relation) — отсюда и слово «реляционная» в переводе названия.

Он же вывел 12 правил Кодда, которым должна подчиняться любая реляционная база данных. Они помогли бороться с устаревшими базами, которые недобросовестные поставщики пытались выдать за реляционные.

А ещё Эдгар Кодд дал жизнь языку SQL.

Основные понятия

Отношение — это двумерная таблица с уникальным именем. Она состоит из строк (записей) и столбцов (атрибутов).

Каждая строка таблицы представляет некоторый объект реального мира (экземпляр сущности) или соотношения между объектами.

Столбцы — это атрибуты сущности, для сущности каждого типа они свои.

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

А что там внутри. Пример нормализации

Разберём устройство реляционной БД подробнее на примере. Позже это поможет нам понимать и сравнивать базы разных типов.

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

Телефон у компании многоканальный. Поэтому одному и тому же оператору могут звонить разные клиенты, а один и тот же клиент может попадать на разных операторов с разными вопросами.

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

Конечно, это делается с помощью запроса, а не вручную. Однако даже запрос будет выполнять 99 лишних операций — из-за дублирования информации.

О подобном заботятся ещё на этапе проектирования базы, а предотвращают это путём нормализации отношений.

Что такое нормализация

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

Избыточность данных — это когда одни и те же данные хранятся в базе сразу в нескольких местах.

Проверим наш пример на избыточность

Каждая строка таблицы Messages содержит имя клиента и никнейм оператора, а также их телефоны. Причём в 1-й и 3-й строках мы видим звонки от одного и того же клиента, а в 1-й и во 2-й — ответы одного и того же менеджера. То есть в 1-й и 3-й строках дублируются имя и телефон клиента — Васи, а в 1-й и 2-й — никнейм менеджера «Оператор1».

Чтобы избавиться от дублирования информации, выделим сущности Клиент и Оператор. И вынесем специфичные для каждой атрибуты в отдельные таблицы.

В первой ( Clients) будут храниться имена и телефоны клиентов, а во второй ( Operators) — операторов. Кроме того, каждой записи в этих таблицах мы присвоим атрибут id — так называемый первичный ключ (его значение уникально, то есть не может повторяться в пределах таблицы). С его помощью мы установим связь с записями таблицы Messages.

Для этого к каждой записи в Messages (напомним, она всё ещё представляет сущность «звонок») добавим два новых атрибута (внешних ключа): id_client и id_oper. Они будут ссылаться на первичные ключи из таблиц Clients и Operators соответственно. Столбцы с именами и телефонами из таблицы Messages уберём.

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

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

Системы управления реляционными базами данных

Данные в таблицах не лежат мёртвым грузом — с ними работают системы управления базами данных ( СУБД ).

С их помощью создают базы (метасхемы), заполняют их данными и проводят операции над всем этим: добавляют, удаляют, меняют структуру, анализируют и так далее.

Языки манипулирования данными

Это декларативный язык. То есть инструкции в нём не идут одна за другой (не как в императивных языках). Каждый оператор SQL описывает только необходимое действие, а СУБД сама принимает решение, как его выполнить.

Например, чтобы выбрать все данные из таблицы Messages за 10.11.2020, делается запрос:

SELECT * FROM messages WHERE date = ‘10.11.2020’

Язык структурированных запросов делится на несколько частей (группы операторов) и позволяет:

В SQL изначально нет средств для создания печатных отчётов, экранных форм и других инструментов для разработки программ. Хотя SQL сам по себе не является полноценным (Тьюринг-полным) языком программирования, но его стандарт позволяет создавать процедурные расширения. Они доводят его функциональность до полноценного языка программирования.

При этом синтаксис SQL в разных СУБД может различаться. Кое-где даже используются его отдельные диалекты, например:

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

Это такие базы, в которые включены средства работы с объектными типами данных. А возникли они в связи с развитием объектно-ориентированных языков программирования.

В структуре таких баз и языке запросов используются классы, объекты, наследование. В этом направлении развиваются, например, Oracle и PostgreSQL.

Какие реляционные БД популярны в веб-разработке

MySQL

Это открытая СУБД, купленная Oracle в придачу к Sun Microsystems. С ней работают более половины (55,6%) всех разработчиков (по результатам опроса, который в 2020 году провёл сайт StackOverflow.com среди 65 тысяч респондентов).

Главные её преимущества — бесплатность и высокая скорость работы с данными. MySQL создавалась для обработки огромных массивов информации в промышленных масштабах, но благодаря доступности и быстродействию оккупировала Всемирную паутину, заслужив звание «СУБД всея интернета». И сегодня MySQL всё ещё самая удобная СУБД для работы с интернет-страницами и веб-приложениями.

MySQL пользуется мощной поддержкой у создателей языков программирования: практически во всех популярных языках есть интерфейс для работы с ней.

SQLite

Эта СУБД использует большую часть стандартного языка SQL.

Главное преимущество SQlight — встраиваемость. Это объясняется тем, что SQlight не приложение типа «клиент-сервер» (в отличие от других реляционных СУБД), а библиотека, которую подключают непосредственно к программе.

И она тоже весьма популярна: достаточно сказать, что SQLite есть в каждом смартфоне. Например, в смартфонах на Android там хранятся контакты и медиа, а в iOS её используют многие приложения.

PostgreSQL

Её можно назвать самой продвинутой. Это не просто реляционная, а объектно-реляционная свободная СУБД.

PostgreSQL поддерживает не только типы данных, которые есть в других реляционных СУБД. Помимо числовых, текстовых, булевых и других стандартных типов, в ней можно хранить и обрабатывать геометрические и денежные данные, сетевые адреса, JSON, XML, массивы, а также создавать собственные типы данных.

Ограничения реляционных СУБД

Реляционные СУБД просты, удобны и предсказуемы. А их рынок один из самых консервативных в IT-отрасли. Поэтому даже при появлении множества NoSQL реляционные базы остаются самым востребованным инструментом в очень разных отраслях.

По данным DB-Engines за февраль 2021 года, мировая доля реляционных СУБД составляет 74% от всех:

Однако реляционные БД не лишены недостатков.

Масштабируемость

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

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

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

Сложность

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

Представьте себе, что таблиц 100, 200, 1000, — СУБД будет работать медленно, а код запроса будет очень громоздким.

Гибкость

Реляционные СУБД подходят для обработки данных с чёткой структурой. Например, сообщений, информации о товарах, сведений о пользователях и так далее. Но в них сложно организовать хранение и обработку сущностей с произвольным набором атрибутов или иерархических данных.

NoSQL как альтернатива традиционным БД

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

И вот, в начале 2000-х появились нереляционные базы. Помимо решения новых задач, их разработчики сделали упор на исправление главных недостатков реляционных баз — проблем с гибкостью, низкой производительностью и масштабируемостью.

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

Виды нереляционных баз данных

Базы NoSQL делятся на четыре основные категории (в зависимости от решаемых с их помощью задач).

Ключ-значение

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

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

Базы «ключ-значение» часто используют для кэширования данных и организации очередей.

Их достоинства — быстрый поиск и простое масштабирование.

Их недостаток — нельзя производить операции со значениями. Например — сортировать их или анализировать.

Базы «ключ-значение» применяют в поисковой системе Google, «Википедии», «Фейсбуке», интернет-магазине Amazon.

Одна из самых популярных — Redis. Её используют Uber, Slack, Stack Overflow, сайты гостиниц и туристические, социальная сеть Twitter.

Документоориентированные СУБД

В таких данные хранятся в виде иерархических структур (документов) с произвольным набором полей и их значений. Документы объединяются в коллекции.

Если провести аналогию с реляционными СУБД, то коллекциям соответствуют таблицы, а документам — строки в них.

Например, фрагмент документа с информацией о фильмах:

Документоориентированные базы используют в системах управления содержимым (CMS) — для хранения каталогов и пользовательских профилей.

Одна из самых популярных — MongoDB (там можно создавать процедуры на JavaScript).

Колоночные

Эти базы отличаются от реляционных лишь способом хранения данных на накопителе.

Если реляционная база создаёт для каждой таблицы по файлу, то в колоночной отдельный файл создаётся для каждого столбца таблицы.

Например, если реляционная таблица выглядит так:

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

Что это даёт? Представьте, что вам нужны только названия объектов, а их свойства вас не интересуют.

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

Колоночные базы применяются в различных каталогах и архивах данных, работа с которыми основана на подобных выборках.

Одна из самых популярных СУБД такого типа — Apache Cassandra.

Графовые

В некоторых предметных областях данные удобно представлять в виде графов. Для их хранения лучше всего подходят графовые базы.

Вершины (или узлы графа) — это объекты (сущности), а рёбра графа — взаимосвязи между ними.

Например, информация о друзьях в социальных сетях просто идеальна для представления в виде графа:

Графовые базы применяют в социальных сетях, сервисах рекомендаций, системах выявления мошенничества и им подобных.

Одна из популярнейших графовых СУБД с открытым кодом и собственным языком запросов — это Neo4j.

Что дальше?

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

Источник