База данных и СУБД: основные понятия и определения

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

База данных (БД) — структурированное поименованное хранилище информации.

Из самого первого определения должно быть понятно, что содержащий начисленные квартальные премии сотрудников файл формата CSV  — текстовый формат, предназначенный для представления табличных данных (CSV от англ. Comma-Separated Values — значения, разделённые запятыми). Каждая строка файла — это одна строка таблицы. Значения отдельных колонок разделяются разделительным символом (запятой).) является хоть и очень простой, но базой данных, а текстовый файл с научным описанием мышей-полёвок ей не является.

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

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

Исторически, в устройстве СУБД выделяли три уровня, предложенных ещё в 1975 году в отчёте ANSI/X3/SPARC :

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

Внутренний уровень не всегда связан с файловой системой. Наиболее развитые современные СУБД представляют собой по сути специализированную операционную систему (см. например информацию по SQLOS в составе Microsoft SQL Server), способную управлять физическими устройствами хранения, кешем данных, процессами и потоками, оперативной памятью, асинхронным запуском и внутренним планировщиком задач минуя собственно операционную систему компьютера.

Вернёмся к примеру с CSV-файлом и приложением LibreOffice Calc, наглядно показывающему, что даже в примитивной СУБД все три упомянутых уровня можно чётко выделить:

  • внутренний уровень представлен собственно файлом формата CVS со спецификацией его полного имени в файловой системе, кодовой страницы и символа разделителя;
  • логический уровень представлен объектом «Электронная таблица» (spreadsheet), позволяющим описать данные в терминах листов, колонок и строк независимо от того, работаем ли мы с CSV-файлом или с файлом в другом формате, возможно даже двоичном;
  • внешний уровень не только позволяет пользователям проводить над данными специфичные операции путём создания встроенных программ на бейсик-подобном языке, но и разграничить доступ к ним на уровне видимости, чтения и записи.

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

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

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

В реляционной СУБД любой оператор SQL является одиночной транзакцией по умолчанию. Некоторые реализации, например, Firebird, по умолчанию открывают новую транзакцию при выполнении каждого оператора SQL, оставляя её «висеть» до выдачи команды завершения. Это так называемый режим неявных транзакций (implicit transaction). Для управления соответствующим поведением, СУБД обычно имеет опцию включения и отключения неявных транзакций, например, set implicit_transaction on|off в SQL Server.

Основными аббревиатурами, касающимися транзакций, с которыми вам придётся сталкиваться будут OLTP (On-Line Transaction Processing) — собственно интерактивная транзакционная обработка, и ACID (Atomicity- Consistency-Isolation-Durability) — принципы неделимости, целостности, изолированности и надёжности. О них мы поговорим в дальнейшем, рассмотрев на примерах принципы изоляции.

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

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

Аналогичной аббревиатурой для интерактивной аналитической обработки является OLAP (On-Line Analytical Processing). Соответственно, интерактивное приложение, работающее с СУБД в режиме OLAP, относится к аналитическим.

Важное здесь слово «интерактивная». Действительно, в отличие от транзакционной, аналитическая обработка может вестись и в пакетном режиме: пользователь формулирует задачу в понятных приложению терминах, ставит обработку в очередь и, например, утром следующего дня получает результаты. Таковой, например, является заблаговременная ночная генерация регулярных отчётов, рассылаемых по утрам или с другой заданной периодичностью группам пользователей (см., например, Microsoft SQL Server Reporting Services).

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

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

 

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

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

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

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

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

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

Рис. 1. Взаимодействие приложения с СУБД в системах с разным числом звеньев

Встроенные СУБД по сравнению с клиент-серверными имеют ряд преимуществ и недостатков. К преимуществам встроенных СУБД можно отнести следующие особенности.

  1. Простота разработки приложений. Программисту не требуется установка и настройка СУБД на своём рабочем месте. Программа имеет полный контроль над логикой работы с БД.
  2. Простота развёртывания приложений. В большинстве случаев достаточно скопировать файлы динамически подгружаемых библиотек в директорий приложения, при этом пользователю даже не нужно иметь права администратора на своём компьютере или другом устройстве, например, на планшете.
  3. Простота обслуживания локальной базы данных. Как правило, приложение со встроенной СУБД эксплуатируется в однопользовательском режиме, а размер базы данных относительно невелик, поэтому необходимость в дополнительной настройке прав доступа и оптимизации быстродействия практически отсутствует. Регулярные операции обслуживания базы данных (резервное копирование, индексация, очистка, дефрагментация и т. п.) могут быть автоматизированы и реализованы непосредственно приложением, например, при его запуске.
  4. Возможность работы в однозадачной операционной системе. Хотя времена господства MS DOS на персональных компьютерах давно прошли, разработчики встраиваемых систем для различных устройств и оборудования смогут по достоинству оценить эту возможность.
  5. Как правило, более высокое быстродействие на операциях вставки, удаления и считывания одиночных записей. Это связано не только с однопользовательским режимом работы, но и с отсутствием затрат на упаковку данных приложением с последующей их передачей по сети СУБД-серверу. По сути, приложение напрямую работает с локально расположенными файлами через слой программных интерфейсов (API) встроенной СУБД.

Следует отметить, что возможно также использование встроенной СУБД в многопользовательском режиме для работы с разделяемыми по сети файлами данных. Такая технология получила название «файл-сервер» и была весьма популярна до широкого распространения клиент-серверных СУБД. Интересующихся я отсылаю к системам разработки под общим названием xBase. Сюда относятся такие продукты, как dBase, Paradox, FoxPro или Clipper (современная открытая кросс-платформенная реализация Clipper называется Harbour). Тем не менее, как минимум одна популярная встраиваемая СУБД до сих пор нередко используется в таком качестве, это Microsoft Access и его «мотор» MS Jet, являющийся компонентом операционной системы Windows.

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

  1. Более высокий риск потерь и повреждения данных. Как мы помним, встроенная СУБД находится в том же процессе операционной системы, что и приложение. Соответственно, аварийное завершение работы приложения в момент записи данных может повредить их. Транзакции также контролируются непосредственно приложением, поэтому при аварийном останове некому будет откатить незавершённые модификации базы данных и она останется в несогласованном состоянии.
  2. Ориентация на автономные однопользовательские клиентские и многопоточные серверные приложения. Хотя с помощью разделения файлов в сети можно организовать доступ к одной БД из нескольких приложений, находящихся на разных устройствах, такое решение будет ограничено небольшим числом пользователей и малыми размерами базы данных. Не касаясь серьёзных проблем обслуживания и обеспечения безопасности такой БД, на практике в сети передачи данных 100 мегабит/сек проблемы быстродействия начинаются уже при десятке пользователей, работающих с файлами размером нескольких сотен мегабайт данных.
  3. Невозможность распределения вычислительной нагрузки. Встроенная СУБД работает на одном устройстве, а вычисления производит непосредственно приложение. Клиент-серверная СУБД может быть развёрнута в кластере из многих устройств, при этом она способна сама производить вычисления, возвращая приложению- клиенту результат.
  4. Низкий уровень безопасности. Файлы базы данных должны быть целиком доступны пользователю как минимум на чтение. Таким образом, невозможно предотвратить копирование этих файлов злоумышленниками.
  5. Как правило, функционал встроенной СУБД урезан по сравнению с клиент-серверной версией того же продукта. Например, встроенная версия Microsoft SQL Server Compact несовместима с клиент­серверными версиями и сравнима с Microsoft Access.

СУБД и базы данных. Определения

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

На практике иногда я встречал отношение к вопросам выбора СУБД на уровне высказывания: «Не будем ломать голову, возьмём Oracle: он, как танк, везде пройдёт и нам уж всяко подойдёт». Действительно, если вы не хотите поднапрячь голову сейчас, но согласны, что спустя некоторое время, возможно, придётся на этой же голове рвать волосы, то можно, не напрягаясь, попросить сделать за вас работу продавцов-консультантов продуктов «Большой тройки»[3].

Из ряда многочисленных встроенных СУБД, опробованных непосредственно на практике или в тестовом режиме, таких как xBase, Microsoft, Access, Microsoft SQL Server Compact, SQLite, Oracle Lite) наиболее интересным современным решением мне представляется Firebird по следующим причинам.

  1. Кросс-платформенная СУБД, доступны версии для Windows, Linux и Mac.
  2. Свободно распространяемая СУБД с открытым исходным кодом, допускающая использование в закрытых коммерческих продуктах.
  3. Всего один основной DLL-файл для развёртывания (могут также понадобиться файлы ресурсов), одновременно работающий и как встроенная СУБД, и как клиентская библиотека для связи с СУБД- сервером Firebird. Соответствующий режим выбирается указанием или пропуском имени сервера в строке соединения.
  4. Практически полностью поддержана функциональность своей клиент-серверной версии, включая поддержку встроенных типов данных, видов, триггеров, хранимых процедур и системы безопасности. Это значит, что разработанное программистом приложение будет иметь минимум специфики при работе со встроенной или клиент-серверной версией СУБД с возможностью переключения изменением всего одного параметра соединения.
  5. Версионность данных, благодаря которой читающие транзакции не блокируют пишущие транзакции и наоборот. Разработчики отчётов оперативного контура информационных систем оценят эту возможность, когда требуется выдача согласованной информации на текущий момент времени.

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

 

Сноска. Firebird 2.5: состояние

Firebird достаточно лёгок в администрировании: для относительно небольших

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

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

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

Штатных средств соединения в однопользовательском режиме нет. Поддержка предлагает утилитой gfix отключить базу данных в эксплуатации (!), потом включить её в режиме sysdba, что, впрочем, тоже не гарантирует единственного соединения, если более одного сотрудника имеют доступ с уровнем sysdba.

Редакций Firebird по-прежнему несколько, к SuperServer и Classic добавилась SuperClassic. Исторически, Interbase, на основе открытого кода которого возник Firebird, использовал classic-архитектуру: на каждое соединение СУБД стартует отдельный серверный процесс. Такой подход обеспечивает достаточно высокую надёжность (если один процесс аварийно завершается, то на работу остальных это не влияет) и параллелизм средствами операционной системы, но отсутствует разделяемый кэш данных в оперативной памяти. В SuperServer серверный процесс один, каждое соединение работает в своём потоке с разделяемым кэшем. Но SuperServer не умеет распараллеливать запросы: пока один запрос выполняется со 100% загрузкой одного ядра (одного процессора), остальные ждут. Ситуацию призвана исправить появившаяся редакция SuperClassic.

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

Собственно, кэш данных у Firebird весьма условный, СУБД использует кэш файлов операционной системы, поэтому сбросить его для проверки производительности «холодных» запросов невозможно даже перезапустив СУБД. К примеру, в SQL Server для этого есть специальная команда.

Средства администрирования, прежде всего аудита и мониторинга из комплекта достаточно примитивны. Например, трассировщик запросов, [4] образцом которого вполне может служить MS SQL Server Profiler, являет собой утилиту командной  строки,     запускаемую со своим конфигурационным файлом. Последующую расшифровку полученных результатов надо проводить вручную при помощи регулярных выражений. Есть коммерческие утилиты, предоставляющие более дружественный интерфейс. В версии 2.5 появились возможности накопления статистики в системных таблицах мониторинга вида MONSXXX.

Средством «полной очистки» БД от так называемого мусора до сих пор является процедура резервного копирования и последующего за ним восстановления при помощи утилиты gbak. Однако, подобная процедура означает отключение пользователей от СУБД на всё время восстановления, делая проблематичной работу в режиме 24x7. Файл базы данных понемногу растёт даже при нулевом балансе добавленных и удалённых записей с постоянной фиксацией транзакций, данные дефрагментируются, что может снизить производительность. Ощущается нехватка аналога команды VACUUM, имеющейся в СУБД PostgreSQL.

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

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

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

 


 

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

[2]      Первые тиражируемые системы аналитической обработки данных относятся к 1970 году (Express), но окончательно, как самостоятельное направление, OLAP оформилось только в начале 1990-х годов.

[3]      На данный момент и уже в течение многих лет Big-3 поставщиков СУБД на мировом рынке составляют корпорации Oracle, IBM и Microsoft.

[4]      Запрос к СУБД, требующий преимущественно операции с долговременной памятью (дисковой памятью)

Вас заинтересует / Intresting for you:

База данных как объект правово...
База данных как объект правово... 1567 просмотров Денис Wed, 27 Mar 2019, 03:16:24
Перенос корпоративных баз данн...
Перенос корпоративных баз данн... 2775 просмотров Дэн Fri, 27 Sep 2019, 07:52:18
Что такое база данных  и СУБД?
Что такое база данных и СУБД? 9051 просмотров Светлана Mon, 21 Oct 2019, 17:58:45
Оптимизация структур баз данны...
Оптимизация структур баз данны... 1652 просмотров Ирина Светлова Sun, 24 Mar 2019, 06:25:41
Войдите чтобы комментировать

Fasenger аватар
Fasenger ответил в теме #8984 6 года 2 нед. назад
Правильно ли я понимаю, что на сегодняшний день клиент-серверные базы данных все еще занимают лидирующее место в мире?