A comparative analysis of the features of designing and realization of requests in relational and document-oriented database using DBMS SQL Server and MongoDB as an example

Cover Page

Cite item

Full Text

Abstract

All modern automated systems use storages or database for data storage. There are many types of database management system, that assist relational, object, document-oriented and other data models. The goal of this work is determining of advantages and disadvantages, manipulation of data in relational and document-oriented database using the database management system MS SQL Server and MongoDB. The first stage of this task is comparing of rules of moving from conceptual model to logical database model. When designing any databases the first step is a conceptual designing. The most popular model of this stage is an entity-relationship model. For moving from conceptual model to logical model of relational database is used the rule of Jackson. The rules of moving to document-oriented database weren’t described before.

Full Text

  1. Анализ особенностей проектирования систем баз данных SQL и NoSQL

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

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

Базовыми понятиями в MongoDB являются коллекции и документы [2]. Коллекция является эквивалентом таблицы в реляционных системах управления базами данных. Коллекция существует в одной базе данных [2].

Документ – запись в коллекции и базовая единица данных в MongoDB [2]. Документы в коллекции могут иметь разные поля. Как правило, все документы в коллекции имеют аналогичное или связанное назначение. Документы аналогичны объектам JSON, но существуют в базе данных в формате с большим количеством типов, известным как BSON [2].

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

 

Таблица 1

Правила перехода от концептуальной модели к логической

 

 

Правила перехода от концептуальной модели к документно-ориентированной модели базы данных:

  1. Если степень связи 1:1 и класс принадлежности обоих сущностей является обязательным, то в документно-ориентированной модели создается один документ, одним из полей которого является вложенный документ, содержащий данные о второй сущности.
  2. Если степень связи 1:1 и класс принадлежности одной сущности является обязательным, а другой – необязательным, то в документно-ориентированной модели создается один документ, одним из полей которого может быть вложенный документ, содержащий данные о второй сущности.
  3. Если степень связи 1:1 и класс принадлежности ни одной сущности не является обязательным, то в документно-ориентированной модели создается два документа, при этом в каждом из них может содержаться поле, хранящее ссылку(идентификатор) на другой документ.
  4. Если степень связи 1:n и класс принадлежности n-связной сущности является обязательным, то в документно-ориентированной модели возможны 2 варианта:

- один документ, одним из полей которого является вложенный документ, содержащий данные о второй сущности

- два документа, при этом второй документ содержит поле, хранящее ссылку(идентификатор) на первый документ.

  1. Если степень связи 1:n, класс принадлежности n-связной сущности является необязательным и нет дополнительных полей, то в документно-ориентированной модели возможны 2 варианта:

- один документ, одним из полей которого может быть вложенный документ, содержащий данные о второй сущности

- два документа, при этом второй документ может содержать поле, хранящее ссылку(идентификатор) на первый документ.

Если степень связи 1:n, класс принадлежности n-связной сущности является необязательным и есть дополнительные поля, то создается два документа, при этом второй документ содержит массив объектов следующего типа:

arr1:[{                          K1id: ObjectId,                    data: String                       }, ...              ], где KNid – ссылка на другой документ

  data – дополнительное поле

  1. Если степень связи m:n и нет дополнительных полей, создается 2 документа, каждый из которых содержит массив ссылок на другой документ. Если степень связи m:n и есть дополнительные поля, создается 2 документа, каждый из которых содержит массив объектов следующего типа:

arrN:[{                          KNid: ObjectId,                               data: String                       }, ...              ], где KNid – ссылка на другой документ

  data – дополнительное поле

  1. Сравнительный анализ применения правил перехода от концептуальной модели к логической для реляционных и документно-ориернтированных баз данных на примере описания предметной области «Студент вуза»

Описанные правила использованы на примере концептуальной модели базы данных “Студент вуза”. Модель сущность-связь базы данных “Студент вуза” приведена ниже (рис. 1).

Согласно правилам Джексона, осуществлен переход к логической модели реляционной базы данных по методологии IDEF1X (рис. 2).

Согласно разработанным правилам перехода от концептуальной модели к логической, осуществлен переход к документно-ориентированной модели (рис. 3).

Видно, что по количеству объектов более предпочтительна документно-ориентированная модель (4 коллекции против 7 таблиц).

  1. Разработка алгоритмов и программная реализация решения задачи сравнительного анализа выполнения запросов в системах баз данных SQL и NoSQL на примере СУБД MS SQL Server и MongoDB

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

 

Рис. 1. Концептуальная модель базы данных «Студент вуза»

 

Рис. 2. Логическая модель базы данных «Студент вуза» по методологии IDEF1X

 

Рис. 3. Документно-ориентированная модель базы данных “Студент вуза”

 

MongoDB (от англ. humongous – огромный) – документо-ориентированная СУБД с открытым исходным кодом, не требующая описания схемы таблиц. Классифицирована как NoSQL, использует JSON-подобные документы и схему базы данных. Написана на языке C++. MongoDB реализует новый подход к построению баз данных, где нет таблиц, схем, запросов SQL, внешних ключей и многих других вещей, которые присущи реляционным базам данных.

Для подсчета времени выполнения запросов в MS SQL Server в работе использована утилита SQL Server Profiler - это интерфейс для создания трассировок и управления ими, а также для анализа и воспроизведения полученных результатов[3].

Для подсчета времени выполнения запросов в MongoDB – системная коллекция system.profile. Профилировщик базы данных собирает подробную информацию о коман-дах базы данных, выполняемых для работаю-щего экземпляра mongod. Профилировщик записывает все данные, которые он собирает, в коллекцию system.profile, ограниченную коллекцию в базе данных администратора[2].

Для заполнения реляционной и объектно-ориентированной базы данных тестовыми записями были написаны соответ-ственно хранимые процедуры в SQL Server и программный код на языке JavaScript с использованием NodeJS.

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

Результаты измерения времени выпол-нения перечисленных запросов в разных системах для разного объема данных приведены в таблицах 2 и 3.

На рисунках 4, 5 и 6 представлены графики зависимости среднего времени выполнения запросов на выборку и удаление от количества записей в базе данных.

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

Заключение

По количеству объектов более предпочтительна документно-ориентирован-ная модель (4 коллекции против 7 таблиц). По объему памяти, занимаемому данными для рассматриваемого примера при одинаковом количестве записей в SQL и NoSQL базах данных, выигрывает также документно-ориентированный подход.

 

Таблица 2

Запросы на выборку данных

100000 записей

MS SQL Server

MongoDB

1.1. выборка из одной таблицы

1957ms

310ms

1.2. выборка из двух таблиц

2251ms

417ms

1.3. выборка из двух таблиц с условием

475ms

181ms

1.4. выборка из двух таблиц с условием и сортировкой

555ms

272ms

1.5. выборка с группировкой

1270ms

17922ms

1.6. выборка с соединением всех таблиц

4980ms

53010ms

1000 записей

SQL Server

MongoDB

1.1. выборка из одной таблицы

121ms

4ms

1.2. выборка из двух таблиц

165.2ms

7ms

1.3. выборка из двух таблиц с условием

3.4ms

3ms

1.4. выборка из двух таблиц с условием и сортировкой

10ms

3ms

1.5. выборка с группировкой

15.6ms

327ms

1.6. выборка с соединением всех таблиц

622ms

551ms

10 записей

SQL Server

MongoDB

1.1. выборка из одной таблицы

1.8ms

0ms

1.2. выборка из двух таблиц

1.16ms

0ms

1.3. выборка из двух таблиц с условием

3.4ms

1ms

1.4. выборка из двух таблиц с условием и сортировкой

2.4ms

1ms

1.5. выборка с группировкой

1.7ms

4ms

1.6. выборка с соединением всех таблиц

343ms

29ms

 

Таблица 3

Запросы на изменение данных

100000 записей

SQL Server

MongoDB

2.1. вставка записи

3.2ms

0ms

2.2. обновление записи

1.2ms

0ms

2.3. удаление записи

112ms

64ms

2.4. вставка записи

7.8ms

55ms

2.5. обновление записи

9.8ms

0ms

2.6. удаление записи

1.8ms

0ms

 

Продолжение табл. 3

1000 записей

SQL Server

MongoDB

2.1. вставка записи

1.2ms

0ms

2.2. обновление записи

1.1ms

0ms

2.3. удаление записи

20.4ms

0ms

2.4. вставка записи

8.6ms

0ms

2.5. обновление записи

2ms

0ms

2.6. удаление записи

1.7ms

0ms

10 записей

SQL Server

MongoDB

2.1. вставка записи

2.6ms

0ms

2.2. обновление записи

1ms

0ms

2.3. удаление записи

11.8ms

0ms

2.4. вставка записи

2.6ms

0ms

2.5. обновление записи

1.8ms

0ms

2.6. удаление записи

1.5ms

0ms

 

Рис. 4. График зависимости среднего времени выполнения запроса на выборку из одной таблицы от количества записей

 

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

 

Рис. 6. График зависимости среднего времени выполнения запроса на удаление от количества записей

 

×

About the authors

Vladislav Vyacheslavovich Filatov

Samara University

Author for correspondence.
Email: phil182@mail.ru

undergraduate student of the Faculty of Informatics

Russian Federation, 443086, Russia, Samara, Moskovskoye Shosse, 34

Elena Ivanovna Chigarina

Samara University

Email: chigarinaei@gmail.com

associate professor of the Department of Information Systems and Technologies of the Samara University

Russian Federation, 443086, Russia, Samara, Moskovskoye Shosse, 34

Supplementary files

Supplementary Files
Action
1. JATS XML

Copyright (c) 2020 Proceedings of young scientists and specialists of the Samara University

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Proceedings of young scientists and specialists of the Samara University

ISSN 2782-2982 (Online)

Publisher and founder of the online media, journal: Samara National Research University, 34, Moskovskoye shosse, Samara, 443086, Russian Federation.

The online media is registered by the Federal Service for Supervision of Communications, Information Technology and Mass Communications, registration number EL No. FS 77-86495 dated December 29, 2023

Extract from the register of registered media

Regulation of the online media

Editor-in-chief: Andrey B. Prokof'yev, Doctor of Science (Engineering), associate professor,
head of the Department of Aircraft Engine Theory

2 issues a year

0+. Free price. 

Editorial address: building 22a, room 513, Soviet of Young Scientists and Specialists, 1, Academician Pavlov Street, Samara, 443011, Russian Federation.

Address for correspondence: room 513, building 22a, 34, Moskovskoye shosse, Samara, 443086, Russian Federation.

Tel.: (846) 334-54-43

e-mail: smuissu@ssau.ru

Domain name: VMUIS.RU (Domain ownership certificate), Internet email address: https://vmuis.ru/smus.

The previous certificate is a printed media, the journal “Bulletin of Young Scientists and Specialists of Samara University”, registered by the Office of the Federal Service for Supervision of Communications, Information Technologies and Mass Communications in the Samara Region, registration number series PI No. TU63-00921 dated December 27, 2017.

© Samara University

This website uses cookies

You consent to our cookies if you continue to use our website.

About Cookies