Данные - это всегда структура и содержание, синтаксис и семантика. В контексте баз данных - это таблицы, связи между таблицами, запросы и их результаты. Нельзя сказать, что господствующая идея реляционных баз данных - идеал, но она практична, удобна и позволяет описать любую область применения.
Если база данных - это совокупность таблиц, то система управления базами данных (СУБД) - это поддержка сразу нескольких баз данных и предоставление по каждой из них надлежащего функционала в части администрирования, работы и чтения. С течением времени СУБД обрели множество вполне конкретных функций, которые принято считать стандартом де-факто, и получили собственный язык описания, работы и выборки.
Базовая функциональность СУБД
Базы данных позволяют представить совокупности данных через систему таблиц, указать связи между таблицами, определить нужные запросы, форму нужных результатов и обеспечить два варианта работы:
- изменение;
- только чтение.
Собственно, от СУБД большего и не требуется, нужно обеспечить доступ программного кода для целей администрирования или работы (изменения или чтение). Пользователь не имеет непосредственного доступа к данным, но через определенный код ему доступен широкий функционал, реализуемый СУБД.
Формат, протокол и общий алгоритм использования базы данных всегда известен, хотя сложившаяся система классификации СУБД свидетельствует о большом многообразии концепций и вариантов реализации.
Концепции систем управления данными
Основная концепция, которая, безусловно, лидирует с момента рождения и совершенствуется по сей день, представляет собой фундамент проектирования систем управления базами данных - реляционные отношения. БД - это набор таблиц и связей между ними. Так было, так есть, но так будет ещё не слишком продолжительное время.
Остальные модели данных:
- иерархическая;
- сетевая;
- ER-модель (сущность - связь);
- объектно-ориентированная;
- объектно-реляционная и др.
Они имеют свои ниши, но в каждой из них в основе лежат все те же реляционные отношения. По сути, у разных концепций о данных, организованных в системы данных, бесспорно и очевидно только одно: все данные всегда имеют смысл.
Как отразить смысл в формальной компьютерной модели базы данных? Судя по немногочисленным наименованиям моделей БД, особой проблемы здесь нет, но все же «чистые реляционные отношения» находят самое что ни на есть практичное применение: как назвать решенную задачу обработки данных, какое прилагательное приложить к наименованию её базы данных - неважно, важно, что задача решена.
Классификация систем управления данными
Самая основная категория, которая имеет важное практическое значение: применимость системы для решения задачи. Здесь можно все СУБД разделить на четыре основные группы:
- модель данных;
- распределенность;
- способы доступа;
- уровень универсальности.
Это общая классификация современных СУБД.
Понятие распределенности имеет важное значение, хотя с семантической точки зрения неважно, как распределена база данных, важно, что к ней есть нужный вариант доступа.
Способы доступа к данным тоже важны: сайт может требовать информациию из БД, управляемой Oracle, но получение/запись здесь будут вовсе не так устроены, как при использовании MySQL.
Уровень универсальности - критерий относительный, но в большинстве случаев его следует учитывать. Не всякий проект требует динамики и обеспечения высокого уровня безопасности доступа, надежности хранения и пр. Многие задачи нуждаются в развитии соответственно области применения. Выбор СУБД с ограниченной функциональностью может привести в будущем к лишним тратам на замену системы, которая имеет ограниченные возможности.
Функциональность СУБД
Следуя сложившейся традиции, классификация и функции СУБД играют существенную роль при разработке технического задания или ИТ проекта, в котором фигурируют большие объемы данных. При этом термин «большие» может означать уровень конкретного данного (обработка изображений) или количества записей (обработка текста).
Функциональность задачи и ожидаемого решения может выставлять четкие требования. В частности, выбор СУБД (классификация по данным):
- представление данных (видео, аудио, текст, различные комбинации);
- структуризация/формализация (структурированные, неструктурированные);
- характер/источник (иерархические, реляционные, сетевые);
- формат и место хранения (локальные, распределенные);
- пользователи (один, много).
Эта сторона вопроса затрагивает только часть важных моментов для предпочтения одной СУБД другой. Есть множество прикладных сфер, в которых для выбора СУБД классификация по любому критерию не имеет никакого значения. Например, выбор системы управления сайтом для целей разработки сайта поставит разработчика перед однозначным выбором только одной конкретной базы данных.
Большие СУБД и сложный connect
Современный информационный уровень СУБД (классификация по значимости и ответственности):
- террабайты информации (один большой файл, очень много маленьких файлов);
- мегабайты (несколько файлов, описывающих одну БД, и содержащиеся в ней данные).
Но значимость и ответственность здесь всегда велики не только в первом случае. Есть много ответственных проектов, когда малые объемы информации обусловливают принятие ответственных решений.
Обычно первый критерий определяет в качестве безусловного лидера Oracle, второй - MySQL. У них много общего, но очень много кардинальных различий. Когда возникает задача соединить веб-ресурс с базой данных Oracle без использования её собственных инструментов и технологий, возникает множество вопросов. Сложный connect - давно не редкость, а часто просто условие для достижения решения.
Неменьшее количество проблем с доставкой данных возникает при их нахождении в локальной сети на сервере MS SQL Server, к которому соединение доступно через несколько аппаратных маршрутизаторов.
Фактически в реальной практике важны все составляющие: архитектура СУБД, классификация СУБД по функциональности, вариантности подключения и пропускной способности каналов связи.
Безопасность доступа и хранение данных
Знания СУБД, классификация, теория баз данных вообще, практический опыт и другие концептуальные моменты, несомненно, имеют важное значение. Надежность аппаратной составляющей сегодня очень высока, но вопрос качества кода, и особенно его семантики, по сей день актуален.
Обеспечить безопасный доступ к базе данных могут все СУБД, но как быть с общепринятой практикой копирования баз данных для создания резервных копий?
Эта порочная идея характерна для БД, располагающихся как в одном файле, так и во множестве файлов. В первом случае пропажа одного байта или бита испортит весь файл, а во втором случае неполное копирование описания БД или файлов, содержащих данные, приведет также к непредсказуемым последствиям.
Странно, что разработчики СУБД не озабочены этими фактами, но если бы они предприняли нужные шаги и закрыли раз и навсегда вопрос доступности данных за пределами системы управлениями ими, то образовалась бы дилемма: по СУБД классификация упростилась бы до предела:
- имеет смысл использовать (безопасно, надежно, всегда всё доступно);
- нельзя использовать (все контролируется разработчиком СУБД).
Нельзя все контролировать, чем опытнее программист, тем больше вариантов он оставляет заказчику. Закрыть данные для внешнего контроля и изменения - значит обеспечить решенной задаче не долгую жизнь.
Вопрос безопасности и доступности данных лежит за пределами всякого решения. Он относится к инфраструктуре компании, локальной сети, периметра безопасности и пр.
Сами по себе данные, базы данных и системы управления ими должны быть максимально открытыми и доступными при соблюдении сложившихся, проверенных длительной практикой правил и естественных требований.
Социальный аспект СУБД
Рассматривая разные способы классификации СУБД, следует особое внимание уделить социальной составляющей в контексте теории и её применимости на практике.
Когда появились локальные сети и базы данных разместились на сервере, а СУБД предоставили доступ многим пользователям, всё было исключительно просто: архитектура файл-сервер - это очень практично, сегодня есть:
- файл-сервер;
- клиент-сервер;
- встроенная база данных.
Три стороны одной медали. Неважно, где находится сама база данных, непринципиально, какая выбрана СУБД. Важно, что данные и код, их использующий, должны быть максимально мобильны и доступны, но находиться в пределах периметра общей безопасности под пристальной защитой не только от технологических факторов (атаки, угрозы, деструктивное вмешательство), но и от поведенческого момента в смысле сотрудников, которые разрабатывают код или используют данные.
Реляционные отношения: перспективы
Сложившиеся представления о СУБД, их классификация, накопленный уникальный потенциал в теории и на практике применения несомненны. Разработчики СУБД и потребители информации прошли долгий путь, причем с каждым днем динамика совершенствования стремительно ускорялась.
Реляционная концепция занимает по-прежнему сильные позиции и никакой иной архитектуре или идее ничего уступать не собирается. Но так ли верна её фабула: таблица - это отношения между данными, а взаимосвязи между таблицами - это тоже отношения? Почему в таблице должна быть шапка, а если нет данных, то нет таблицы? Почему таблица всегда прямоугольная, а данные в ней имеют строгий тип и размер?
Мир информации характеризуется плавными формами, а не только прямоугольниками. Не пора ли допустить удивительно простую мысль: есть таблица, но будет в ней шапка или нет - дело конкретного случая. Сколько будет в таблице строк - всегда ясно: от нуля до ограничений конкретной СУБД, но почему нельзя отнести этот позитив на количество колонок?
Если применить абстракцию, к которой так долго идет современное объектно-ориентированное программирование, к реляционным отношениям, то получается очень перспективный следующий шаг: СУБД, в которой неважно, таблица или просто данное, а если таблица, то какая она будет и будут ли там строки или колонки и как они будут взаимосвязаны на её уровне, - вопрос применения. Как все будет увязано по всем данным и таблицам - тоже вопрос сферы применения, а не компетенция разработчика, делающего СУБД или код её использующий.
