XIII Международная студенческая научная конференция Студенческий научный форум - 2021

ВВЕДЕНИЕ

СУБД (Система управления базами данных) – совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования баз данных (БД) многими пользователями.

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

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

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

Цель настоящей работы – проклассифицировать СУБД по различным признакам.

В соответствии с поставленной целью необходимо решить следующие задачи:

– изучить теоретическую литературу по заданной теме,

– систематизировать полученный материал,

– изложить различные классификации СУБД.

1 КЛАССИФИКАЦИЯ СУБД ПО МОДЕЛИ ДАННЫХ

По модели данных СУБД можно разделить на:

– иерархические,

– сетевые,

– реляционные,

– объектно-ориентированные,

– объектно-реляционные.

Здесь и далее при описании типа СУБД имеется в виду, что данная СУБД поддерживает конкретную модель данных.

Рассмотрим каждый из перечисленных выше типов СУБД подробнее.

1.1 Иерархические СУБД

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

Иерархическая модель данных – это модель данных, где используется представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней [4].

Связи между объектами в такой модели можно представить в виде отношений предок/потомок. Предком в данном случае называется объект, который находится ближе к корню, а потомком – объект более низкого уровня, непосредственно связанный с потомком.

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

На рисунке 1 представлена схема такой модели.

Рисунок 1 – Схема иерархической модели данных

Когда иерархические СУБД были на пике популярности, их достоинствами считались:

– эффективное использование памяти,

– достаточно высокая скорость выполнения простейших операция над данными,

– удобство работы с упорядоченной информацией,

– простота работы с небольшим объёмом данных [3].

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

– при большом объёме данных медленный доступ к объектам нижних уровней,

– сложность организации неиерархических связей,

– трудность в понимании модели конечным пользователем [5].

С появлением других моделей данных были обнаружены другие существенные недостатки иерархической модели, основным из которых является её строгая ориентация на конкретные виды запросов. Это лишает пользователя возможности гибко изъяснять свои намерения при фильтрации объектов модели. Одной из первых СУБД с поддержкой иерархической модели считается Information Management System (IMS), разработанная компанией IBM [4].

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

1.2 Сетевые СУБД

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

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

Преимуществом сетевой модели над иерархической является в некоторой степени более эффективная реализация с точки зрения использования памяти.

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

Пример сетевой модели представлен на рисунке 2.

Рисунок 2 – Пример сетевой модели данных

1.3 Реляционные СУБД

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

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

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

Следует отметить, что любая таблица в реляционной БД отвечает следующим принципам:

– она состоит из столбцов, каждый из которых имеет оригинальное имя, отличное от имен других столбцов,

– порядок следования строк и столбцов не имеет значения,

– в таблице отсутствуют одинаковые кортежи (строки с заданным набором конкретных атрибутов) и домены (значения некоторого атрибута).

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

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

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

Пример реляционной модели представлен на рисунке 3.

Рисунок 3 – Пример реляционной модели данных

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

– легкость понимания пользователем,

– регламентированное проектирование,

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

К недостаткам модели относятся:

– высокие расходы памяти,

– относительно низкая скорость доступа к данным [2].

Первые реляционные СУБД появились в начале 80-х годов от компаний IBM, Oracle, Relation Technology Inc.

На современном этапе своего развития реляционные СУБД совершенствуются с каждым днем и предоставляют возможности решения всё более и более сложных задач. Примеры таких СУБД: MySql, PostgreSql, Visual FoxPro, Access.

1.4 Объектно-ориентированные СУБД

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

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

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

Серьёзным недостатком баз данных, созданных при помощи ООСУБД, является их связь с конкретным языком программирования. Объект, созданный на одном языке программирования, будет невозможно связать с объектом, созданном на другом языке [6].

К ООСУБД можно отнести GemStone [10].

Пример объектно-ориентированной модели приведён на рисунке 4.

Рисунок 3 – Пример объектно-ориентированной модели данных

1.5 Объектно-реляционные СУБД

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

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

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

В качестве примеров таких СУБД можно привести DB2 и Microsoft SQL Server. Довольно часто СУБД, называемые реляционными, относятся на самом деле к объектно-реляционным [10].

2 КЛАССИФИКАЦИЯ СУБД ПО СТЕПЕНИ РАСПРЕДЕЛЁННОСТИ

2.1 Локальные СУБД

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

Преимущество такого подхода – безопасность. Однако возникает существенная проблема тогда, когда необходима синхронизация данных у нескольких пользователей сразу. Она заключается в том, что необходимо выполнять редакцию на компьютере каждого пользователя и совмещать изменения, вносимые каждым пользователем. Ввиду существования такой проблемы локальные СУБД обычно не используются [9].

ПримерылокальныхСУБД: Microsoft Access, Paradox, dBase.

2.2 Распределённые СУБД

В таком типе СУБД её части могут располагаться сразу на нескольких ЭВМ. Распределённые СУБД используются для создания распределённых баз данных.

Распределённая база данных – это совокупность нескольких взаимосвязанных баз данных, которые физически распределены по различным местам, которые обмениваются данными через компьютерную сеть [7].

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

Примеры распределённых СУБД: Ingres и Oracle.

3 КЛАССИФИКАЦИЯ СУБД ПО СПОСОБУ ДОСТУПА К БД

3.1 Файл-серверные СУБД

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

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

В настоящее время файл-серверные СУБД считаются устаревшей технологией и обычно не применяются.

Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro [10].

3.2 Клиент-серверные СУБД

Как сама СУБД, так и созданные с помощью неё БД располагаются на одном сервере, и доступ к БД осуществляется непосредственно. Любые пользовательские запросы обрабатываются прямо на сервере, поэтому к самому серверу предъявляются существенные требования. Достоинствами таких СУБД, по сравнению с файл-серверными, являются:

– более низкая нагрузка на локальную сеть,

– удобство централизованного управления,

– обеспечение надёжности, доступности и безопасности.

Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛИНТЕР [10].

3.3 Встраиваемые СУБД

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

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

Доступ к данным приложения может происходить как через язык SQL, так и через специальные интерфейсы.

Примеры встраиваемыхСУБД: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact, ЛИНТЕР [10].

4 КЛАССИФИКАЦИЯ СУБД ПО СТЕПЕНИ УНИВЕРСАЛЬНОСТИ

По степени универсальности СУБД принято разделять на общего назначения и специального.

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

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

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

ЗАКЛЮЧЕНИЕ

В ходе данной работы:

– была изучена научная литература по теме исследования,

– представлена история и теория вопроса,

– выявлены преимущества и недостатки различных типов СУБД,

– указаны наиболее используемые в настоящее время СУБД,

– проведена подробная классификация СУБД.

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

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

– необходимость в совместном использовании СУБД по сети,

– необходимость встраивания СУБД в конечное приложение,

– направленность на конкретную предметную область,

– предполагаемое использование нестандартных типов данных.

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

SQLite, MySQL и PostgreSQL: сравниваем популярные реляционные СУБД [Электронный ресурс] – URL: https://tproger.ru/translations/sqlite-mysql-postgresql-comparison/amp/ (дата обращения 14.04.2020);

Достоинства и недостатки реляционной модели данных [Электронный ресурс] – URL: https://agro7group.ru/raznoe/dostoinstva-i-nedostatki-modeli.html (дата обращения 14.04.2020);

Иерархическая модель данных [Электронный ресурс] – URL: https://ru.bmstu.wiki/Иерархическая_модель_данных (дата обращения 14.04.2020);

Иерархическая модель данных [Электронный ресурс] – URL: https://ru.wikipedia.org/wiki/Иерархическая_модель_данных (дата обращения 17.04.2020);

Иерархическая СУБД [Электронный ресурс] – URL: https://www.tadviser.ru/index.php/Статья:Иерархическая_СУБД (дата обращения 14.04.2020);

Классификация СУБД. Типы и виды СУБД [Электронный ресурс] – URL: https://www.sqlhome.org.ua/klassifikaciya-tipy-vidy-subd/ (дата обращения 15.04.2020);

Распределенная СУБД — Основные понятия [Электронный ресурс] – URL: https://coderlessons.com/tutorials/akademicheskii/izuchite-raspredelennuiu-subd/raspredelennaia-subd-kratkoe-rukovodstvo (дата обращения 13.04.2020);

Реляционная модель данных [Электронный ресурс] – URL: http://www.bseu.by/it/tohod/lekcii2_3.htm (дата обращения 15.04.2020);

Система управления базами данных [Электронный ресурс] – URL: http://informatics-lesson.ru/bd/subd.php (дата обращения 14.04.2020);

Системы управления базами данных [Электронный ресурс] – URL: https://lecturesdb.readthedocs.io/databases/dbms.html (дата обращения 16.04.2020).

Код для цитирования: Скопировать