База как модель бизнеса субд

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

Данные

Вокруг нас всегда много разных данных, например:

• телефонные номера;
• дела на день;
• записи на бумажках, стикерах и в блокнотах;
• опубликованные мысли разных людей;
• фотографии в смартфоне;
• и всё остальное, что можно прочитать, увидеть или услышать.

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

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

Если это служба слежения за гражданами — фотография, имя, посещённые станции метро и улицы, место работы.

Что такое базы данных? ДЛЯ НОВИЧКОВ / Про IT / Geekbrains

База данных и СУБД

Есть понятие базы данных — это набор данных, организованных каким-то способом. Например, если у вас в квартире есть гардеробная или кладовка, то всё это помещение со всем её содержимым может считаться базой (но не данных, а вещей или банок с огурцами, что не меняет сути).

Есть понятие системы управления базой данных (СУБД) — это когда семья села за стол и самого младшего отправляют в кладовку за огурцами, он приносит её и не разбивает по дороге. То есть СУБД — это какое-то средство для манипуляции данными в базе, например программа.

Для чего нужны

Вот основные задачи БД на примере гардеробной:

• Сохранить наши данные по запросу — чтобы вы могли открыть дверь, повесить куртку, закрыть дверь и больше не думать ни о куртке, ни о гардеробной.
• Изменить наши данные по запросу — чтобы можно было легко извлечь из гардеробной все дырявые носки и положить на их место целые.
• Найти эти данные по запросу — чтобы быстро найти приличный пиджак или парный носок.
• Не дать прочитать эти данные тем, кому не следует, а кому надо — дать. Например, младший брат может смотреть на ваши кроссовки, но не может их брать. А девушка (или парень) может положить свои вещи, но только на определённую полку.
• Поддерживать порядок и не дать захламиться — если вам было лень и вы просто кинули толстовку куда попало, чтобы гардеробная либо сама нашла, куда эту толстовку правильно положить, либо сказала: «Э БРАТ ЗАЧЕМ ЗАХЛАМЛЯЕШЬ ПОЛОЖИ НОРМАЛЬНО ДАВАЙ»
• Масштабироваться — чтобы вы могли просто вешать в гардеробную вещи и не думать об объёме полок.
• Не потерять данные — если квартира будет гореть, приличная гардеробная не должна даже нагреться. Или, если она всё-таки горит, чтобы где-то в защищённом подземном гараже была точная копия этой гардеробной со всеми актуальными вещами.

В чём преимущества

Базы данных и их системы управления заточены на работу с большим объёмом данных и от лица большого числа пользователей. Сейчас вы поймёте.

Что такое архитектура СУБД и БД? — простыми словами ► ПРАКТИЧЕСКОЕ ПРОГРАММИРОВАНИЕ

Представьте, что у вас есть экселька со списком клиентов. Это не база данных, это просто таблица. Чтобы прочитать или записать что-то в эту эксельку, вам нужно её открыть, сделать дело, сохранить.

❌ Допустим, экселька с клиентами лежит на сетевом диске. Вы открыли её и ковыряетесь в данных, вносите изменения. Пока вы это делаете, ваш коллега тоже её открыл и тоже вносит изменения. Потом вы сохранились и закрыли эксельку. Экселька перезаписалась вашими данными. Но у вашего коллеги эти данные не отобразились, он-то открыл её раньше.

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

❌ Или у вас в компании правило: экселька всегда на одной флешке, работаем только с неё. Сейчас флешка в вашем компьютере, вы с ней работаете. А вашему коллеге нужно с ней тоже поработать. Он говорит: «Дай». Вы ему «Отстань». Ну и слово за слово…

✅ Но можно организовать своего рода СУБД. Один ответственный сотрудник назначается главным по эксельке. Она открыта на его компьютере, а вы ему говорите: «Петруха, добавь в клиента такого-то вот такие данные». «Петруха, а шо, когда дедлайн по поставке для этих ребят из Воронежа?», «Петруха, питерские отказались, поставь там отказ».

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

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

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

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

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

• Связывать одну единицу данных с множеством других. Например, если один человек совершил много заказов со множеством товаров внутри каждого, база данных способна хранить и обрабатывать такие связи.
• База может хранить дерево данных — вроде того, о котором мы писали недавно. Попробуй в реальной жизни похранить дерево!
• В базах могут жить ссылки на другие фрагменты и отделы базы.

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

База данных — это отдельный файл?

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

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

Где их используют

Базы данных сейчас используются почти везде:

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

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

Как это работает

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

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

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

Если пользователю нужно будет найти телефон Михаила Максимова по фамилии, происходит следующее:

Запрос от пользователя: Выдай мне из базы «Контакты» все записи, где поле «Фамилия» равно «Максимов»

Ответ от базы данных: ЛОЛ КЕК Ты кто такой

Запрос пользователя: Я хозяин этой базы Админ Админыч, пароль •••••. Выдай мне из базы «Контакты» все записи, где поле «Фамилия» равно «Максимов»

Ответ от базы данных: Найдена одна запись: [Михаил, Максимов, +79057362163, вот фото]

Разные базы — разные правила

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

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

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

А если она разрешит открыть карточку, то что будет, если двое сотрудников напишут там разный лимит — какой из них сохранять в итоге? СУБД задаёт эти правила и следит за их выполнением.

Что дальше

В следующей статье поговорим про MySQL — бурерождённую мать всех баз. Если разобраться, как она работает, то можно творить чудеса.

Текст и последняя схема

Редактура и остальные схемы

Источник: thecode.media

Модели баз данных — шпаргалка для начинающих

СУБД используют различные модели баз данных . Самые старые системы можно разделить на иерархические и сетевые базы данных — это пререляционные модели.

Модели баз данных — иерархическая база данных

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

« Система управления информацией » ( Information Management System ) компании IMB — пример иерархической СУБД.

Иерархическая модель данных организует их в форме дерева с иерархией родительских и дочерних сегментов. Такая модель подразумевает возможность существования одинаковых ( преимущественно дочерних ) элементов. Данные здесь хранятся в серии записей с прикреплёнными к ним полями значений. Модель собирает вместе все экземпляры определённой записи в виде « типов записей » — они эквивалентны таблицам в реляционной модели, а отдельные записи — столбцам таблицы. Для создания связей между типами записей иерархическая модель использует отношения типа « родитель-потомок » вида 1:N . Это достигается путём использования древовидной структуры — она « позаимствована » из математики, как и теория множеств, используемая в реляционной модели.

Иерархическая база данных — пример

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

Данные о сотруднике и его детях формируют иерархическую структуру, где информация о сотруднике – это родительский элемент, а информация о детях — дочерний элемент. Если у сотрудника три ребёнка, то с родительским элементом будут связаны три дочерних. Иерархическая база данных подразумевает, что отношение « родитель-потомок » — это отношение « один ко многим ». То есть у дочернего элемента не может быть больше одного предка.

Иерархические БД были популярны, начиная с конца 1960-х годов, когда компания IBM представила свою СУБД «Система управления информацией. Иерархическая схема состоит из типов записей и типов « родитель-потомок »:

• Запись — это набор значений полей.
• Записи одного типа группируются в типы записей.
• Отношения «родитель-потомок» — это отношения вида 1:N между двумя типами записей.
• Иерархическая база данных данных состоит из нескольких иерархических схем.

Сетевая модель базы данных

Сетевая модель базы данных подразумевает, что у родительского элемента может быть несколько потомков, а у дочернего элемента — несколько предков. Записи в такой модели связаны списками с указателями. IDMS (« Интегрированная система управления данными ») от компании Computer Associates international Inc. — пример сетевой СУБД.

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

Сетевая модель позволяет более естественно моделировать отношения между элементами. И хотя эта модель широко применялась на практике, она так и не стала доминантной по двум основным причинам. Во-первых, компания IBM решила не отказываться от иерархической модели в расширениях для своих продуктов, таких как IMS и DL/I . Во-вторых, через некоторое время её сменила реляционная модель, предлагавшая более высокоуровневый, декларативный интерфейс.

Популярность сетевой модели совпала с популярностью иерархической модели. Некоторые данные намного естественнее моделировать с несколькими предками для одного дочернего элемента. Сетевая модель как раз и позволяла моделировать отношения «многие ко многим». Её стандарты были формально определены в 1971 году на конференции по языкам систем обработки данных ( CODASYL ).

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

Запись старшего уровня (« запись-владелец ») также может быть « членом » или « владельцем » в других наборах. Модель данных — это простая сеть, связи, типы пересечения записей ( в IDMS они называются junction records , то есть «перекрёстные записи ). А также наборы, которые могут их объединять. Таким образом, полная сеть представлена несколькими парными наборами.

В каждом из них один тип записи является « владельцем » ( от него отходит «стрелка» связи ), и один или более типов записи являются « членами » ( на них указывает «стрелка» ). Обычно в наборе существует отношение 1:М , но разрешено и отношение 1:1 . Сетевая модель данных CODASYL основана на математической теории множеств.

Известные сетевые базы данных:

• TurboIMAGE;
• IDMS;
• Встроенная RDM;
• Серверная RDM.

Реляционная модель базы данных

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

В отличие от двух других типов СУБД, в реляционных моделях данных нет необходимости просматривать все указатели, что облегчает выполнение запросов на выборку информации по сравнению с сетевыми и иерархическими СУБД. Это одна из основных причин, почему реляционная модель оказалась более удобна. Распространённые реляционные СУБД: Oracle , Sybase , DB2 , Ingres , Informix и MS-SQL Server .

« В реляционной модели, как объекты, так и их отношения представлены только таблицами, и ничем более ».

РСУБД — реляционная система управления базами данных, основанная на реляционной модели Э. Ф. Кодда. Она позволяет определять структурные аспекты данных, обработки отношений и их целостности. В такой базе информационное наполнение и отношения внутри него представлены в виде таблиц — наборов записей с общими полями.

Реляционные таблицы обладают следующими свойствами:

• Все значения атомарны.
• Каждый ряд уникален.
• Порядок столбцов не важен.
• Порядок рядов не важен.
• У каждого столбца есть своё уникальное имя.

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

Часто у полей будет одно и то же имя в обеих таблицах. Например, таблица « Заказы » может содержать пары « ID-покупателя » и « код-товара ». А в таблице « Товар » могут быть пары « код-товара » и « цена ». Поэтому чтобы рассчитать чек для определённого покупателя, необходимо суммировать цену всех купленных им товаров, использовав JOIN в полях « код-товара » этих двух таблиц. Такие действия можно расширить до объединения нескольких полей в нескольких таблицах.

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

Сравниваем три модели баз данных

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

Вторая, сетевая модель данных , имеет более гибкую структуру, чем иерархическая модель данных, и поддерживает отношения « многие ко многим ». Но быстро становится слишком сложной и неудобной для управления.

Третья модель — реляционная — более гибкая, чем иерархическая и проще для управления, чем сетевая. Реляционная модель сегодня используется чаще всего.

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

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

Объекты связываются отношениями, основные типы которых можно определить следующим образом:

«Один к одному»

В этом виде отношений один объект связан с другим. Например, Менеджер -> Отдел .

У каждого менеджера может быть только один отдел, и наоборот.

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

В моделях данных отношение одного объекта с несколькими. Например, Сотрудник -> Отдел .

Каждый сотрудник может быть только в одном отделе, но в самом отделе может быть больше одного сотрудника.

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

В заданный момент времени объект может быть связан с любым другим. Например, Сотрудник -> Проект .

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

В реляционной модели объекты и их отношения представлены двухмерным массивом или таблицей.

Каждая таблица представляет объект.

Каждая таблица состоит из рядов и столбцов.

Отношения между объектами представлены столбцами.

Каждый столбец представляет атрибут объекта.

Значения столбцов выбираются из области или набора всех возможных значений.

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

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

Преимущества реляционной модели данных:

1. Простота использования.
2. Гибкость.
3. Независимость данных.
4. Безопасность.
5. Простота практического применения.
6. Слияние данных.
7. Целостность данных.

1. Избыточность данных.
2. Низкая производительность.

Другие модели баз данных (ООСУБД)

В последнее время на рынке СУБД появились продукты, представленные объектными и объектно-ориентированной моделью данных, такие как Gem Stone и Versant ОСУБД. Также производятся исследования в области многомерных и логических моделей данных.

Особенности объектно-ориентированных систем управления базами данных (ООСУБД):

• При интеграции возможностей базы данных с объектно-ориентированным языком программирования получается объектно-ориентированная СУБД.
• ООСУБД представляет данные как объекты одного или нескольких языков программирования.
• Такая система должна отвечать двум критериям: являться СУБД и должна быть объектно-ориентированной. То есть должна насколько это возможно соответствовать современным объектно-ориентированным языкам программирования. Первый критерий подразумевает: длительное хранение данных, управление вторичным хранилищем, параллельный доступ к данным, возможность восстановления, а также поддержку нерегламентированных запросов. Второй критерий подразумевает: сложные объекты, идентичность объектов, инкапсуляцию, типы или классы, механизм наследования, переопределение в сочетании с динамическим связыванием, расширяемость и вычислительную полноту.
• ООСУБД дают возможность моделирования данных в виде объектов.

А также поддержку классов объектов и наследование свойств и методов классов подклассами и их объектами.

На данный момент не существует общепринятого стандарта ООСУБД. Считается, что подобные модели данных находится на ранней стадии развития.

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

МК Михаил Кузнецов автор-переводчик статьи «

Источник: www.internet-technologies.ru

II. Реляционные БД

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

• поле в таблице, называемое внешним ключом, может содержать ссылки на столбцы в других таблицах, что позволяет их соединять;
• высокоорганизованная структура и гибкость делает реляционные БД мощными и адаптируемыми ко различным типам данных;
• для доступа к данным используется язык структурированных запросов (SQL);
• надёжный выбор для многих приложений.

III. NoSQL базы данных

NoSQL – группа типов БД, предлагающих подходы, отличные от стандартного реляционного шаблона. Говоря NoSQL, подразумевают либо «не-SQL», либо «не только SQL», чтобы уточнить, что иногда допускается SQL-подобный запрос.

5. Базы данных «ключ-значение»

В базах данных «ключ-значение» для хранения информации вы предоставляте ключ и объект данных, который нужно сохранить. Например, JSON-объект, изображение или текст. Чтобы запросить данные, отправляете ключ и получаете blob-объект.

• хранилища обеспечивают быстрый и малозатратный доступ;
• часто хранят данные конфигураций и информацию о состоянии данных, представленных словарями или хэшем;
• нет жёсткой схемы отношения между данными, поэтому в таких БД часто хранят одновременно различные типы данных;
• разработчик отвечает за определение схемы именования ключей и за то, чтобы значение имело соответствующий тип/формат.

6. Документная база данных

Документные базы данных (также документоориентированные БД или хранилища документов), совместно используют базовую семантику доступа и поиска хранилищ ключей и значений. Такие БД также используют ключ для уникальной идентификации данных. Разница между хранилищами «ключ-значение» и документными БД заключается в том, что вместо хранения blob-объектов, документоориентированные базы хранят данные в структурированных форматах – JSON, BSON или XML.

• база данных не предписывает опредёленный формат или схему;
• каждый документ может иметь свою внутреннюю структуру;
• документные БД являются хорошим выбором для быстрой разработки;
• в любой момент можно менять свойства данных, не изменяя структуру или сами данные.

7. Графовая база данных

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

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

• выглядят аналогично сетевым;
• фокусируются на связях между элементами;
• явно отображает связи между типами данных;
• не требуют пошагового обхода для перемещения между элементами;
• нет ограничений в типах представляемых связей.

8. Колоночные базы данных

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

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

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

9. Базы данных временных рядов

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

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

IV. Комбинированные типы

NewSQL и многомодельные БД являются разными типами баз данных, но решают одну группу проблем, вызванных полярными подходами SQL или NoSQL-стратегии. Почему бы не объединить преимущества обеих групп?

10. NewSQL базы данных

NewSQL базы данных наследуют реляционную структуру и семантику, но построены с использованием более современных, масштабируемых конструкций. Цель – обеспечить большую масштабируемость, нежели реляционные БД, и более высокие гарантии согласованности, чем в NoSQL. Компромисс между согласованностью и доступностью является фундаментальной проблемой распределённых баз данных, описываемой теоремой CAP.

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

11. Многомодельные базы данных

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

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

• помогают уменьшить нагрузку на СУБД;
• позволяют расширяться до новых моделей по мере изменения потребностей без внесения изменений в базовую инфраструктуру;
• обеспечивают непрерывный доступ и простое распределение данных;
• имеют линейную масштабируемость и просты для разработки.

Больше полезной информации вы найдете на наших телеграм-каналах «Библиотека программиста» и «Книги для программистов».

Заключение

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

Источник: proglib.io