Выбор системы управления базами данных для программного комплекса приемной комиссии ДонНТУ

Аннотация

Чередникова О.Ю., Щедрин С.В., Ногтев Е.А., Исаков А.Ю. Выбор системы управления базами данных для программного комплекса приемной комиссии ДонНТУ. В статье анализируется пять самых популярных СУБД - Oracle, MySQL, Microsoft SQL Server, PostgreSQL и MongoDB. Сравнение производилось в соответствии с критериями, выдвигаемыми к комплексу приемной комиссии ДонНТУ. Сделан вывод о наиболее предпочтительной СУБД для поставленной задачи.

Ключевые слова:СУБД, таблицы базы данных, SQL, индексы.

Введение

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

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

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

Рейтинг 10 наиболее популярных СУБД, согласно ресурсу DB-Engines по состоянию на октябрь 2018 года, приведен в таблице 1.

Таблица 1 – Десять самых популярных СУБД

Рейтинг	Название СУБД	Тип СУБД
1	Oracle	реляционная СУБД
2	MySQL	реляционная СУБД
3	Microsoft SQL Server	реляционная СУБД
4	PostgreSQL	постреляционная СУБД
5	MongoDB	документоориентированная СУБД
6	DB2	реляционная СУБД
7	Redis	NoSQL
8	Elasticsearch	Поиск и индексация
9	Microsoft Access	реляционная СУБД
10	Cassandra	NoSQL

Постановка задачи

Программный комплекс Приемной комиссии ДонНТУ представляет собой систему автоматизации работы операторов, членов приемной комиссии, представителей деканатов и других служб университета в период вступительной кампании. До настоящего времени в качестве СУБД в программном комплексе использовалась MS SQL Server. С каждым годом в соответствии текущими потребностям структура БД расширялась, усложнялась, появлялись новые разработчики программного обеспечения, которые вносили, как в сам программный комплекс, так и в структуру базы данных свои особенности. В итоге программный комплекс представляет собой набор разрозненных приложений, написанных с использованием различных технологий программирования. Поэтому на данном этапе перед разработчиками комплекса стоит задача проектирования нового программного обеспечения. И прежде всего необходимо оптимизировать структуру БД, в частности устранить избыточности и противоречивости существующей БД. Необходимо также определиться с СУБД, которая могла бы обеспечить большую защищенность данных и позволяла бы более оптимально работать с ними, как на стороне сервера, так и на стороне клиента. На данный момент существует множество систем моделирования. Анализ научно-технической литературы показывает, что наиболее популярными являются системы моделирования DyMoLa, Dynast, Multisim, VisSim, МВТУ, MVS, SimuLink[1] Для сравнения при изучения гармонических колебаний были выбраны специализированные системы SimuLink и МВТУ.

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

Анализ СУБД в соответствии с особенностями структурирования информации в программном комплексе приемной комиссии

Сравнительный анализ проведен среди наиболее популярных в настоящее время СУБД: Oracle, MS SQL Server, MySQL, PostgreSQL, MongoDB.

Рассмотрим основные критерии, которым должна соответствовать СУБД программного комплекса приемной комиссии и какие СУБД им удовлетворяют:

Возможность хранить в ячейке таблицы набор нескольких объектов.

Структура некоторых таблиц предполагает наличие столбцов, содержащих набор информации. Например, сведения о сертификатах абитуриента (ЕГЭ, ГИА, ВНО) должны содержать оценки по нескольким предметам. Логично было бы хранить их в одном столбце, который бы содержал массив записей типа предмет – оценка.

В Oracle типом столбца может быть коллекция - структура данных, по своей функциональности сходная со списком или одномерным массивом [2]. Этот термин может иметь несколько значений: столбец таблицы, где хранятся значения типа вложенной таблицы - TABLE или массива VARRAY. Главное различие между вложенными таблицами и структурами VARRAY проявляется при использовании их в качестве типов данных столбцов. Хотя массив VARRAY, подобно вложенной таблице, позволяет сохранить в одном столбце множество значений, для него необходимо указать максимальную длину массива, который будет храниться в таблице вместе с остальными данными. Поэтому разработчики компании Oracle рекомендуют использовать столбцы типа VARRAY для маленьких массивов, а вложенные таблицы — для больших. Доступ к любому элементу вложенной таблицы или varray-массива осуществляется по его индексу, который указывается в скобках после имени переменной типа коллекции.

MySQL по умолчанию не поддерживает тип данных массива [3]. Поэтому нет возможности хранить массив непосредственно в базе данных mysql.

В Transact-SQL Microsoft SQL Server нет такой структуры, как массив. T-SQL не предусматривает полностью функциональную структуру массива. Однако SQL 2000 ввел новую возможность, называемую переменной табличного типа, которая позволяет имитировать массив и/или использоваться вместо курсора в SQL Server.

PostgreSQL позволяет определять колонки таблицы как многомерные массивы переменной длины. Элементами массивов могут быть любые встроенные или определённые пользователями типы, перечисления или составные типы [4]. Массивы доменов в данный момент не поддерживаются. Столбцы в таблице в PostgreSQL могут представлять массивы, например, массивы чисел INTEGER или массивы строк VARCHAR или массивы других типов данных. Массив определяется в кавычках, как и строка, но внутри кавычек все элементы массива помещаются в фигурные скобки. Каждый отдельный элемент массива заключается в двойные кавычки. C помощью индексов можно конкретизировать, какие именно элементы массива необходимо получить:

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

Данный критерий неприменим к MongoDB, так как это документо-ориентированная СУБД.

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

В Oracle хранимые процедуры можно писать на языках PL/SQL и Java. Тело процедуры строится по правилам PL/SQL. Вызов процедуры состоит просто в употреблении ее имени со списком параметров.

Можно определить три типа параметров, которые могут быть объявлены:

IN — Параметр может ссылаться на процедуру или функцию. Значение параметра не может быть изменено процедурой или функцией.

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

IN OUT — Параметр может ссылаться на процедуру или функцию и значения параметра может быть изменено процедурой или функцией.

В MySQL хранимые процедуры появились в 5 версии. Они позволяют автоматизировать сложные процессы на уровне MySQL, нежели использовать для этого внешние скрипты. Процедуры можно создавать как запросы, например, через командную строку MySQL, но для удобства можно использовать MySQL GUI Tools. Данный пакет включает в себя три программы — MySQL Administrator, MySQL Query Browser и MySQL Migration Toolkit. При создании, модификации, удалении хранимых процедур сервер манипулирует с таблицей mysql.proc

Начиная с MS SQL 2005 появилась возможность написания хранимых процедур на любом языке .NET. Хранимые процедуры являются полноценными объектами базы данных, а потому каждая из них хранится в конкретной базе данных. Непосредственный вызов хранимой процедуры возможен, только если он осуществляется в контексте той базы данных, где находится процедура.

В SQL Server имеется несколько типов хранимых процедур.

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

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

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

В PostgreSQL имеются очень мощные функции, которые в своём большинстве совместимы с тем, что в других СУБД называют хранимыми процедурами, а в некоторых случаях они могут больше. Эти функции могут быть различных типов и могут быть написаны на разных языках программирования (PgSQL, C, Perl, Java, PHP, Python, R, Ruby, Scheme, PL/sh). Основные ограничения хранимых функций в PostgreSQL по сравнению с - настоящими хранимыми процедурами это:

• неспособность возвращать несколько наборов данных;
• отсутствие поддержки автономных транзакций (BEGIN, COMMIT и ROLLBACK внутри функций);
• отсутствие поддержки стандартного SQL-синтаксиса CALL;

MongoDB позволяет сохранять функции, написанные на языке JavaScript, который используется как скриптовый язык в оболочке и как язык встроенных хранимых процедур. Это позволяет исполнять почти любой код на сервере БД. Для этого используется специальная системная коллекция system.js.

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

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

MySQL использует безопасность, основанную на Access Control Lists (ACL) для всех соединений, запросов и других операций, которые пользователи могут попытаться выполнить. Есть также поддержка SSL-зашифрованных соединений между клиентами и серверами MySQL. Но есть и недостатки модели безопасности MySQL при её стандартной базовой настройке и установке из коробки:

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

Отсутствие развитой подсистемы управления паролями:

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

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

Среда MS SQL Server предоставляет множество различных функций для создания безопасных приложений баз данных. Платформа безопасности MS SQL Server управляет доступом к защищаемым сущностям при помощи проверки подлинности и авторизации. MS SQL Server поддерживает два режима проверки подлинности: режим проверки подлинности Windows и режим смешанной проверки подлинности.

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

Подсистема аудита появилась в версии MS SQL Server 2008, она позволяет проверять события ядра базы данных и настраивать параметры проверки.

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

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

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

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

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

Такие ограничения можно осуществить с помощью политик безопасности, основанных на технологии RLS (row-level security или безопасность на уровне строк). Политики безопасности позволяют либо закрыть информацию полностью или частично, либо разрешить лишь определенные операции над ней.

RLS-технология была впервые представлена в Oracle 8i, но в последующих версиях ее возможности были значительно расширены. При связи объекта БД с политикой безопасности контроль доступа осуществляется через логику, занесенную в специальную PL/SQL-функцию. Для обеспечения детального управления безопасностью внутри базы данных в Oracle используются два связанных между собой механизма: контекст приложения (application context) и политику детального контроля доступа (fine-grained access control — FGAC). Для обозначения реализации политик детального контроля доступа посредством контекстов приложений в Oracle применяется термин виртуальная приватная база данных (virtual private database). Часто понятия детальный контроль доступа, виртуальная приватная база данных и безопасность на уровне строки используют взаимозаменяемо для ссылки на возможность Oracle обеспечения безопасности на уровне отдельной строки, а не на уровне таблицы.

В MySQL существует возможность создавать только свои роли и закреплять за ними нужные привилегии, политик безопасности не реализованы.

Во всех версиях MS SQL Server используется безопасность на основе ролей. Однако, начиная с SQL Server 2016, предоставляется возможность создания политик безопасности, основанных на RLS.

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

В MongoDB есть только роли, которые выключены по умолчанию.

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

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

Триггеры для Oracle можно писать на собственном языке программирования этой СУБД, носящим название PL/SQL (Programming Language for SQL - язык программирования для SQL), или на Java. Oracle поддерживает три вида триггеров: предваряющие (BEFORE), замещающие (INSTEAD OF) и завершающие (AFTER). Каждый из них, как и любой другой объект БД, после создания хранится в словаре данных в виде P-кода. Ранее до версии Oracle 7.3 триггеры хранились в словаре данных, в виде исходного кода. И каждые раз при вызове компилировались, а затем исполнялись. В более старших версиях Oracle, триггеры хранятся уже в скомпилированном виде. Активация триггеров происходит при выполнении операторов DML.

Триггеры были введены в MySQL начиная с версии 5.0.2. Синтаксис триггеров несколько чужероден. MySQL использует стандарт ANSI SQL:2003 для процедур и других функций. Триггеры выполняются как процедуры при событиях UPDATE, DELETE и INSERT. Они могут быть выполнены либо до, либо после определения события. Таким образом Вы можете определить триггер, которые будет выполняться перед DELETE или после DELETE, и так далее. Это значит, что можно иметь один триггер, который выполнится до INSERT и совершенно другой, который выполнится после INSERT, что является весьма мощным инструментом.

В самом SQL Server есть два основных типа триггеров: триггеры Data Definition Language, или языка определения данных (DDL), и Data Manipulation Language, или языка управления данными (DML). До версии SQL Server 7.0, можно было создать только три триггера на одной таблице, один INSERT, один UPDATE и один DELETE. Ситуация изменилась с выходом SQL Server 7.0. Появилась возможность на одну таблицу задать большое количество (Ограничено числом объектов в базе данных) триггеров каждого типа. Порядок запуска триггеров при этом никак не определен и не гарантирован. В SQL Server 2000 появилась документированная процедура sp_settriggerorder, которая позволяет изменять порядок запуска триггеров. Можно указать какие триггеры AFTER срабатывают первыми или последними. Триггеры AFTER, срабатывающие между первым и последним триггерами, выполняются в неопределенном порядке.

В PostgreSQL можно создавать триггерные процедуры, которые будут вызываться при изменениях данных или событиях в базе данных. Триггерная процедура создаётся командой CREATE FUNCTION, при этом у функции не должно быть аргументов, а типом возвращаемого значения должен быть trigger (для триггеров, срабатывающих при изменениях данных) или event_trigger (для триггеров, срабатывающих при событиях в базе). Для триггеров автоматически определяются специальные локальные переменные с именами вида TG_переменная, описывающие условие, повлекшее вызов триггера.

В MongoDB нет поддержки триггеров.

Возможность хранить выборку из нескольких таблиц как виртуальную таблицу

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

Представление в Oracle — результат хранимого запроса, поэтому в словаре данных сохраняется только определение представления. При экспорте базы данных Oracle можно видеть предложение exporting views (экспорт представлений), но под этим имеется в виду только определения представлений, а не физические объекты. При условии, что пользователь имеет соответствующие права доступа к лежащим в основе представления таблицам, можно запрашивать представления или даже модифицировать, удалять либо добавлять данные с использованием операторов UPDATE, DELETE и INSERT. Например, если выдать только привилегию INSERT для базовой таблицы, на которой определено представление, то этот пользователь сможет только вставлять строки в таблицу, но не сможет ни выбирать, ни вставлять, ни удалять строки.

MySQL начиная с версии 5.0 поддерживает представления, включая обновляемые. Представление действует как виртуальная таблица и беспечивают гибкую настройка прав доступа к данным за счет того, что права даются не на таблицу, а на представление. Сервер MySQL довольно быстро работает с представлениями за счет того, что MySQL кэширует результаты запросов, в принципе, многие современные системы управления базами данных. Команды манипуляции данными (за исключением SELECT, который можно применять к любому представлению) можно применять к VIEW в том случае, когда строки VIEW совпадают со строками таблицы в базе данных

Ограничения представлений в MySQL:

1. Невозможно создать индекс на представлении.
2. Индекс может использоваться для представлений, обработанных, используя алгоритм слияния. Однако, представление, которое обработано алгоритмом temptable, неспособно использовать в своих интересах индекс на его основных таблицах (хотя индекс может использоваться во временных таблицах).

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

1. Индексированные представления;
2. Секционированные представления;
3. Системные представления.

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

В MongoDB представления отсутствуют.

Выводы

Проанализировав пять самых популярных СУБД, можно сделать вывод, что требованиям, предъявляемым к СУБД программного комплекса Приемной комиссии, наиболее полно удовлетворят две из них - Oracle и PostgreSQL. Однако у СУБД PostgreSQL есть одно существенное преимущество - PostgreSQL Pro сертифицирована ФСТЭК России.

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

Учитывая стойкие интеграционные тенденции ДонНТУ с российскими стандартами, предпочтение стоит отдать именно этой СУБД.

Дальнейшие исследования связаны с возможностями интеграции PostgreSQL с MS SQL Server, т.к. АСУ Деканат использует в качестве СУБД MS SQL Server и должен получать данные с сервера Приемной комиссии.

Литература

1. Андрей Николаенко. Эталонные тесты СУБД: что было, что стало, что будет // Открытые системы.СУБД. — 2017. — №2. — С. 35–39. [Электронный ресурс]. – Режим доступа: https://www.osp.ru/os/2017/02/13052225 — Загл. с экрана.
2. Фейерштейн, С. Oracle PL/SQL для профессионалов / С. Фейерштейн, Б. Прибыл. - М.: СПб: Питер, 2005. - 941 c.
3. MySql DEVELOPER ZONE Data Type Overview. [Электронный ресурс]. – Режим доступа: https://dev.mysql.com/doc/refman/8.0/en/data-type-overview.html — Загл. с экрана.
4. Панченко И. PostgreSQL: вчера, сегодня, завтра // Открытые системы. СУБД. 2015. № 3. С. 34-37.

Чередникова О.Ю., Щедрин С.В., Ногтев Е.А., Исаков А.Ю. Выбор системы управления базами данных для программного комплекса приемной комиссии ДонНТУ. В статье анализируется пять самых популярных СУБД - Oracle, MySQL, Microsoft SQL Server, PostgreSQL и MongoDB. Сравнение производилось в соответствии с критериями, выдвигаемыми к комплексу приемной комиссии ДонНТУ. Сделан вывод о наиболее предпочтительной СУБД для поставленной задачи.

Ключевые слова:СУБД, таблицы базы данных, SQL, индексы.

Cherednikova Olga, Shchedrin Sergey, Nogtev Evgeniy, Isakov Andrey. The Choice of a database management system for admissions DonNTU. The article analyzes five most popular DBMS - Oracle, MySQL, Microsoft SQL Server, PostgreSQL and MongoDB. The comparison was made in accordance with the criteria put forward to the complex of the admissions Committee of DonNTU. The conclusion about the most preferable DBMS for the task is made.

Key words: DBMS, database tables, SQL, indexes