Файл: Системы управления базами данных и их классификация.pdf

ВУЗ: Не указан

Категория: Реферат

Дисциплина: Не указана

Добавлен: 08.07.2023

Просмотров: 63

Скачиваний: 4

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

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

Практически все разработчики современных приложений, предусматривающих связь с системами баз данных, ориентируются на реляционные СУБД. По данным аналитиков на 2010 год, реляционные СУБД используются в абсолютном большинстве крупных проектов по разработке информационных систем. По результатам исследований компании IDC 2009 года всего около 7% составляют проекты, в которых используются СУБД нереляционного типа.

По оценке Gartner в 2013 году рынок реляционных СУБД составлял 26 млрд долларов с годовым приростом около 9 процентов, а к 2018 году рынок реляционных СУБД достигнет 40 млрд долларов. В настоящее время абсолютными лидерами рынка СУБД являются компании Oracle, IBM и Microsoft, с общей совокупной долей рынка около 90%, поставляя такие системы как Oracle Database, IBM DB2 и Microsoft SQL Server.

Единственной коммерчески успешной СУБД российского производства является реляционная СУБД Линтер для операционных систем Windows, UNIX, QNX.

В 1974 году компания IBM начала исследовательский проект по разработке РСУБД, получивший название System R. Её первым коммерческий продуктом был IBM SQL/DS, выпущенный в 1982 году.

Однако первой коммерчески успешной РСУБД стала Oracle, выпущенная в 1979 году компанией Relational Software, которая впоследствии была переименована в Oracle Corporation.

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

В связи с резким ростом популярности РСУБД в 1980-х годах многие компании стали позиционировать свои СУБД как «реляционные» в рекламных целях, иногда не имея для этого достаточных оснований, вследствие чего автор реляционной модели данных Эдгар Кодд в 1985 году опубликовал свои знаменитые «12 правил Кодда», которым должна удовлетворять каждая РСУБД.

  1. Постреляционные(Объектно-реляционные).

Постреляционная модель основана на тех же принципах, что и реляционная, но без учета требования неделимости данных. Их достоинством является более высокая скорость работы, а недостатком – сложности в обеспечении целостности данных. Типичным представителем являются СУБД uniVerse и UniData;


Постреляционная модель данных представляет собой расширенную реляционную модель, в которой отменено требование атомарности атрибутов. Поэтому постреляционную модель называют "не первой нормальной формой" (NF2) или "многомерной базой данных". Она использует трехмерные структуры, позволяя хранить в полях таблицы другие таблицы. Тем самым расширяются возможности по описанию сложных объектов реального мира. В качестве языка запросов используется несколько расширенный SQL, позволяющий извлекать сложные объекты из одной таблицы без операций соединения.

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

  1. No sql (нереляционные).

Модель no sql отличается простотой и гибкостью. Она позволяет добавлять элементы данных в таблицы без предварительного объявления об изменении структуры. Наиболее известные представители MongoDB и CouchDB. Объектные. Этот класс СУБД хранит данные в виде объектов. Такой подход очень удобен для предметных областей со сложной структурой. Недостатком является необходимость использовать процедурные языки для доступа к данным. К современным объектным СУБД относятся POET, Jasmine, Versant, O2, ODB-Jupiter. Объектно-реляционные.

Некоторые производители СУБД совмещают в своих продуктах реляционную и объектную модели. К таким «гибридам» относятся Informix Universal Server и Oracle8 Universal Data Server Многомерные. Если реляционная модель хранит данные в двумерных таблицах, то многомерная позволяет добавлять дополнительные измерения. В результате данных хранятся не в таблицах, а в гиперкубах. Многомерные СУБД используются в задачах анализа данных. На многомерной технологии основаны СУБД jBASE, EssBase.

NoSQL (от англ. not only SQL — не только SQL) — термин, обозначающий ряд подходов, направленных на реализацию систем управления базами данных, имеющих существенные отличия от моделей, используемых в традиционных реляционных СУБД с доступом к данным средствами языка SQL. Применяется к базам данных, в которых делается попытка решить проблемы масштабируемости и доступности за счёт атомарности (англ. atomicity) и согласованности данных (англ. consistency).

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


В начале 2000-х годов Google построил свою высокомасштабируемую поисковую систему и приложения: GMail, Google Maps, Google Earth и т. п., решая проблемы масштабируемости и параллельной обработки больших объёмов данных. В результате была создана распределённая файловая система и распределённая система координации, хранилище семейств колонок (англ. column family store), среда выполнения, основанная на алгоритме MapReduce. Публикация компанией Google описаний этих технологий привела к всплеску интереса среди разработчиков открытого программного обеспечения, в результате чего был создан Hadoop и запущены связанные с ним проекты, призванные создать подобные Google технологии. Через год, в 2007 году, примеру Google последовал Amazon.com, опубликовав статьи о высокодоступной базе данных Amazon DynamoDB.

Поддержка гигантов индустрии менее чем за пять лет привела к широкому распространению технологий NoSQL (и подобных) для управления «большими данными», а к делу присоединились другие большие и маленькие компании, такие как: IBM, Facebook, Netflix, eBay, Hulu, Yahoo!, со своими проприетарными и открытыми решениями.

Традиционные СУБД ориентируются на требования ACID к транзакционной системе: атомарность, согласованность, изолированность, надёжность, тогда как в NoSQL вместо ACID может рассматриваться набор свойств BASE:

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

Решения NoSQL отличаются не только проектированием с учётом масштабирования. Другими характерными чертами NoSQL-решений являются:

  • Применение различных типов хранилищ.
  • Возможность разработки базы данных без задания схемы.
  • Линейная масштабируемость (добавление процессоров увеличивает производительность).
  • Инновационность: «не только SQL» открывает много возможностей для хранения и обработки данных.

Типы систем

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

В зависимости от модели данных и подходов к распределённости и репликации в NoSQL-движении выделяются четыре основных типа систем: «ключ — значение» (англ. key-value store), документоориентированные, «семейство столбцов», графовые.


  1. Ключ — значение

Модель «ключ — значение» является простейшим вариантом, использующим ключ для доступа к значению. Такие системы используются для хранения изображений, создания специализированных файловых систем, в качестве кэшей для объектов, а также в системах, спроектированных с прицелом на масштабируемость. Примеры таких хранилищ — Berkeley DB, MemcacheDB, Redis, Riak, Amazon DynamoDB.

  1. Семейство столбцов

Запрос «Семейство столбцов» перенаправляется сюда. На эту тему нужно создать отдельную статью.

Другой тип систем — «семейство столбцов», прародитель этого типа — система Google BigTable. В таких системах данные хранятся в виде разреженной матрицы, строки и столбцы которой используются как ключи. Типичным применением этого типа СУБД является веб-индексирование, а также задачи, связанные с большими данными, с пониженными требованиями к согласованности. Примерами СУБД данного типа являются: Apache HBase, Apache Cassandra, ScyllaDB, Apache Accumulo, Hypertable.

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

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

  1. Документоориентированная СУБД

Документоориентированные СУБД служат для хранения иерархических структур данных. Находят своё применение в системах управления содержимым, издательском деле, документальном поиске. Примеры СУБД данного типа — CouchDB, Couchbase, MongoDB, eXist, Berkeley DB XML.

  1. Графовая СУБД

Графовые СУБД применяются для задач, в которых данные имеют большое количество связей, например, социальные сети, выявление мошенничества. Примеры: Neo4j, OrientDB, AllegroGraph, Blazegraph, InfiniteGraph, FlockDB, Titan.