Выбор субд для построения информационных систем. Базы данных и субд

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

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

тип модели данных, которую поддерживает данная СУБД, адекватность модели данных структуре рассматриваемой ПО;

характеристики производительности СУБД;

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

степень оснащенности СУБД инструментарием для персонала администрирования данными;

удобство и надежность СУБД в эксплуатации;

стоимость СУБД и дополнительного программного обеспечения.

СУБД MS Access

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

Microsoft Access предоставляет максимальную свободу в задании типа данных (текст, числовые данные, даты, время, денежные значения, рисунки, звук, электронные таблицы). Можно задавать также форматы хранения представления этих данных при выводе на экран или печать. Для уверенности, что в базе хранятся только корректные значения, можно задать условия на значения различной степени сложности. Так как Microsoft Access является современным приложением Windows, можно использовать в работе все возможности DDE (динамический обмен данными) и OLE (связь и внедрение объектов). DDE позволяет осуществлять обмен данными между Access и любым другим поддерживающим DDE приложением Windows. В Microsoft Access можно при помощи макросов или Access Basic осуществлять динамический обмен данными с другими приложениями. OLE является более изощренным средством Windows, которое позволяет установить связь с объектами другого приложения или внедрить какие-либо объекты в базу данных Access. Такими объектами могут быть картинки, диаграммы, электронные таблицы или документы из других поддерживающих OLE приложений Windows.

В Microsoft Access для обработки данных базовых таблиц используется мощый язык SQL (структурированный язык запросов). Используя SQL можно выделить из одной или нескольких таблиц необходимую для решения конкретной задачи информацию. Access значительно упрощает задачу обработки данных. Совсем не обязательно знать язык SQL. При любой обработке данных из нескольких таблиц Access использует однажды заданные связи между таблицами.

В Microsoft Access имеется также простое и в то же время богатое возможностями средство графического задания запроса - так называемый «запрос по образцу» (query by example), которое используется для задания данных, необходимых для решения некоторой задачи. Используя для выделения и перемещения элементов на экране стандартные приемы работы с мышью в Windows и несколько клавиш на клавиатуре, можно буквально за секунды построить довольно сложный запрос. Microsoft Access спроектирован таким образом, что он может быть использован как в качестве самостоятельной СУБД на отдельной рабочей станции, так и в сети - в режиме «клиент-сервер». Поскольку в Microsoft Access к данным могут иметь доступ одновременно несколько пользователей, в нем предусмотрены надежные средства защиты и обеспечения целостности данных. Можно заранее указать, какие пользователи или группы пользователей могут иметь доступ к объектам (таблицам, формам, запросам) базы данных. Microsoft Access автоматически обеспечивает защиту данных от одновременной их корректировки разными пользователями. Access также опознает и учитывает защитные средства других подсоединенных к базе данных структур.

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

Microsoft Access предоставляет дополнительные средства разработки приложений, которые могут работать не только с собственными форматами данных, но и с форматами других наиболее распространенных СУБД. Возможно, наиболее сильной стороной Access является его способность обрабатывать данные электронных таблиц, текстовых файлов, файлов dBASE, Paradox, Btrieve, FoxPro и любой другой базы данных SQL, поддерживающей стандарт ODBE. Это означает, что можно использовать Access для создания такого приложения Windows, которое может обрабатывать данные, поступающие с сетевого сервера SQL или базы данных SQL на главной ЭВМ.

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

Современные базы данных можно разделить на три категории:

1. Программные продукты корпоративного направления - Oracle и MS SQL Server;

2. СУБД, предназначенные для работы с информационными массивами в небольших компаниях, - MS Access и Borland Interbase;

3. СУБД для Web, реализующих создание web-сайтов с небольшими базами данных, - MySQL и опять-таки Borland Interbase.

Какими свойствами должна обладать СУБД в зависимости от этих категорий?

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

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

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

Сегодня наиболее популярными СУБД являются Oracle, MS SQL Server, Borland Interbase, MySQL и MS Access.

знать

База данных - организованная совокупность данных, предназначенная для длительного хранения во внешней памяти ЭВМ, регулярного обновления и использования.

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

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

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

Реляционные БД (РБД) - наиболее распространенный тип БД, использующий табличное представление данных.

Основные понятия организации данных в РБД : таблица, запись, поле, тип поля, главный ключ таблицы.

Технология работы с базами данных имеет несколько этапов, а именно:

Ø построение мифологической модели БД,

Ø создание структуры таблиц базы данных,

Ø обработку данных, содержащихся в таблицах,

Ø и вывод информации из БД.

Контрольные вопросы

1. Дайте определение БД.

2. Дайте определение СУБД.

3. Как вы понимаете структуру базы данных?

4. Назовите основные требования, предъявляемые к организации СУБД?

5. Как классифицируются СУБД в зависимости от технологии обработки данных?

6. Как классифицируются СУБД в зависимости от способа доступа к данным ?

7. Какие информационно-логическим моделям баз данных вы знаете?

8. Дайте определение иерархической, сетевой и реляционной моделям баз данных?

9. Какие существуют варианты классификации БД?

10.Почему реляционный тип БД является наиболее распространенным?

11. Что такое запись в БД?

12. Как осуществить выбор СУБД для создания системы автоматизации?

13. Перечислите этапы обобщенной технологии работы с БД.

15. Перечислите возможности, достоинства и недостатки MS Access.

16. Перечислите современные СУБД для корпоративного применения.

1. Какие тренды в развитии серверных СУБД вы бы могли отметить в 2015–2016 годах?

Виталий Чесноков , QSOFT
Самые главные тренды в развитии современных СУБД: использование виртуализации и GRID-технологии, самодиагностика и автоматическое исправление, использование NoSQL-СУБД в Big Data, использование NewSQL-СУБД, выполнение C/C++ кода в адресном пространстве СУБД.

За последние несколько лет многократно выросли объемы данных, подходящих для обработки и хранения в БД. Был принято изменение закона «О персональных данных», гласящее, что персональные данные граждан РФ необходимо хранить на территории РФ. В некоторых западных странах так же действуют подобные законы. Все это приводит нас к необходимости кластеризации и разбиения данных на части.

Повсеместно растет процент использования NoSQL-СУБД, где это возможно, ввиду высокой скорости работы с данными и возможности сравнительно простой кластеризации. Получает распространение новый тип СУБД - NewSQL. В основные беспрецедентные функции NewSQL входят: возможность асинхронной мастер-мастер репликации, заменяющей классическую master-slave схему и обеспечивающей большую гибкость для высоконагруженных проектов; упрощение администрирования и обеспечение динамического управления базой; поддержка хранимых процедур на C/C++ и возможность выполнения C/C++ кода в адресном пространстве СУБД (обеспечивают практически неограниченную расширяемость и невероятный прирост в производительности); улучшение средств диагностики и отладки.

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

Николай Фетюхин , MST
Переход к NoSQL и специализация баз данных. Например, можно обратить внимание на Redis и Tarantool. Последний содержит даже свой сервер приложений. Интересный тренд - совмещенные СУБД и backend, как Parse от Facebook. Также плавная миграция баз данных в облака.

Петр Урваев , SimbirSoft
Функции, успешно себя зарекомендовавшие в одних СУБД, через некоторое время реализуются и в других продуктах. Например, материализованные представления, вначале появившиеся в Oracle DBMS, через некоторое время были реализованы в MS SQL Server, а затем появились и в PostgreSQL. Преимущества, которые предоставляют NoSQL-решения постепенно также реализуются в реляционных СУБД. Например, в последних версиях PostgreSQL реализована поддержка работы с данными в формате JSON.

Евгений Гусев , ITECH
Изменения последних лет в сегменте СУБД носили как частный - применительно к отдельным лидирующим продуктам, так и структурный характер, так что трендов множество. Во-первых, гетерогенность. Переход к модели микросервисов дал возможность гибко подбирать средства решения задачи хранения данных, не ограничиваясь одним. Во-вторых, развитие NoSQL, in-memory storages. В-третьих, Big Data - революция, потребовавшая переосмыслить как методику хранения данных, так и само понятие «данные». В-четвертых, колоночные (column-oriented) БД.

2. По-вашему мнению, существует ли тенденция перехода СУБД в «облака»? Какие существуют плюсы и минусы данного подхода?

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

Первый - разворачивание в облаке виртуальной машины с СУБД. Можно загрузить на нее собственный образ или воспользоваться заранее заготовленным, с уже оптимизированной СУБД. По сути такая виртуальная машина принципиально не отличается от обычного физического сервера. Основным преимуществом по сравнению с физическим сервером является легкость масштабирования, как вертикального (можно в любой момент выделить для данной «виртулки» больше ресурсов), так и горизонтального (создание новой «виртуалки» занимает всего несколько минут). Еще один существенный плюс - высокая доступность облачных виртуальных машин (99,9%–99,99%). Также облачные хостеры предоставляют множество дополнительных услуг, таких как мониторинг, резервное копирование, панель управления сервером и т.д.

Принципиально иным подходом является облачная СУБД. В данном случае клиент покупает не сервер, а просто услугу использования СУБД. Текущий рынок публичных облачных СУБД, составляющий $400 млн, к 2017 году увеличится до $1,2 млрд. Основные плюсы данного подхода: оплата не предоставленных ресурсов (которые могут и «простаивать»), а лишь реально использованных: объем хранимых данных, количество обрабатываемых СУБД операций; нет необходимости настраивать и администрировать СУБД - эти задачи полностью лежат на хостере; нет необходимости задумываться о масштабировании; хостер предоставляет множество удобных и интуитивно понятных инструментов для управления СУБД; высокая доступность. Основным минусом является отсутствие возможности тонкой настройки СУБД.

Также можно отдельно выделить такой подвид облачной СУБД как DbaaS (Database as a Service). Практически всегда конкретный DbaaS - это одна определенная СУБД, предоставляемая в облаке непосредственными разработчиками. Отсюда очевидно выводится и разница в бизнес-моделях: облачные СУБД подходят для масштабных типовых задач, а DbaaS - для специализированных, под конкретную марку движка БД, с возможностью прямого общения с его разработчиками. Кроме того, DbaaS позволяет значительно точнее подобрать систему под нужную нагрузку, в частности за счет регулирования количества клиентских подключений.

Николай Апурин , Artwell
Тенденция существует. Большинство крупных (общероссийских) систем уже используют облачные БД.

Николай Фетюхин , MST
Тенденция слабая. Использование облаков хоть и снижает некоторые издержки, но приводит к новым расходам. Использование облака может быть выгодно лишь для проектов со слабой посещаемостью.

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

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

Евгений Гусев , ITECH
Существует и является одной из первичных. Плюсов у размещения БД в облаке масса: простота шардинга и репликации, возможность эффективно в контексте производительности отделить данные от бизнес-логики, легкое и понятное управление вычислительными мощностями и целый ряд других. Критичных минусов, основываясь на опыте, мы не видим. Чем большими объемами данных приходится оперировать, чем больше требуется горизонтального масштабирования, тем более оправданным становится использование облаков.

3. Какие факторы влияют на выбор СУБД? Для каких проектов больше подходят SQL базы данных, а для каких - NoSQL?

Виталий Чесноков , QSOFT
Основным фактором при выборе между SQL и NoSQL-СУБД являются нужды приложения. Для одних задач лучше подходит SQL, для других - NoSQL.

Можно выделить несколько ключевых различий между этими типами СУБД. Формат данных в SQL очень строгий, есть четкие схемы таблиц с указанием, где используется какой тип данных. В NoSQL нет заранее заданных схем документов - любая информация может быть добавлена в любой документ.
В SQL существуют сложные связи между различными таблицами. Данные в одной таблице часто являются ссылкой на данные в другой (принцип нормализации данных). В NoSQL, как правило, каждый документ является изолированной информационной единицей и хранит в себе все имеющиеся данные (принцип денормализации).
В SQL есть встроенные механизмы поддержки целостности данных (например, нельзя удалить запись из таблицы, если на нее ссылаются в других таблицах). В NoSQL таких механизмов нет, поэтому важна денормализация данных (в идеале - каждый документ хранит абсолютно всю информацию о каком-либо объекте).
В SQL есть механизм транзакций, который позволяет выполнить несколько SQL-запросов по принципу «все или ничего». В NoSQL подобный механизм существует только в пределах одного документа.
В идеальном случае NoSQL работает быстрее, чем SQL, за счет более простого метода хранения данных, который позволяет получить всю информацию об объекте простым запросом одного документа. Однако есть проблема, связанная с тем, что наиболее популярные NoSQL-СУБД появились достаточно недавно. Следствием этого является меньшее количество информации по этим СУБД и большее количество пока нерешенных проблем.
NoSQL гораздо проще масштабировать за счет отсутствия сложных логических связей между документами. К тому же большая часть NoSQL-СУБД изначально создавалась с упором на механизмы масштабирования.

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

Николай Апурин , Artwell
NoSQL - для нестандартных вычислений с огромным объемом данных. Но как показала практика, объемы до 20 миллионов записей отлично перерабатываются SQL-базами.

Николай Фетюхин , MST
Технологии NoSQL активно используются известными компаниями, в том числе в высоконагруженных проектах. Сохранение данных и простые выборки при использовании NoSQL будут действительно быстрыми. В случае более сложных запросов задачу придется решать на стороне продукта, что усложняет сам продукт. В чистом виде мы не выбираем NoSQL. Усложнение логики продукта и эмуляции базовых вещей SQL приводит к удорожанию проекта. И не каждое NoSQL-решение обеспечивает безопасность данных в критических ситуациях.

Петр Урваев , SimbirSoft
Выбор БД зачастую зависит от предпочтений архитектора, возможной нагрузки, необходимого функционала. SQL-БД позволяют четко определять схемы хранения данных и извлекать данные с использованием сложных запросов, NoSQL-БД позволяют хранить данные в менее упорядоченном формате и поддерживают горизонтальное масштабирование. Зачастую в распределенных системах используются одновременно SQL и NoSQL базы данных, каждая из которых решает свои задачи.

Евгений Гусев , ITECH
В современном состоянии SQL / NoSQL - скорее не конкурирующие, а дополняющие друг друга сущности. Использование в одном приложении SQL-решений, когда требуется работать со сложными данными в их взаимосвязи, и NoSQL, когда на передний план выходит скорость работы с неструктурированной информацией, - совершенно естественная практика.

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

Виталий Чесноков , QSOFT
Есть два различных варианта разделения СУБД па платные и бесплатные.

Первый - бесплатные версии коммерческих СУБД (есть у MS SQL, Oracle и т.д.) По сути это урезанная версия СУБД, в которой отсутствует часть функционала. Здесь основной фактор выбора очень прост - нужен ли данному проекту данный функционал. Реже бывает бесплатная версия, которая не отличается от коммерческой по функционалу, но реже обновляется (Couchbase Server).

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

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

Николай Апурин , Artwell
Зачем платить, если есть бесплатные? Тем не менее, много решений, которые могут работать только с платными БД. В основном, это иностранные практики.

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

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

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

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

Базовая функциональность СУБД

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

изменение;
только чтение.

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

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

Концепции систем управления данными

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

Остальные модели данных:

иерархическая;
сетевая;
ER-модель (сущность - связь);
объектно-ориентированная;
объектно-реляционная и др.

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

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

Классификация систем управления данными

модель данных;
распределенность;
способы доступа;
уровень универсальности.

Это общая классификация современных СУБД.

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

Способы доступа к данным тоже важны: сайт может требовать информациию из БД, управляемой Oracle, но получение/запись здесь будут вовсе не так устроены, как при использовании MySQL.

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

Функциональность СУБД

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

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

представление данных (видео, аудио, текст, различные комбинации);
структуризация/формализация (структурированные, неструктурированные);
характер/источник (иерархические, реляционные, сетевые);
формат и место хранения (локальные, распределенные);
пользователи (один, много).

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

Большие СУБД и сложный connect

Современный информационный уровень СУБД (классификация по значимости и ответственности):

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

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

Обычно первый критерий определяет в качестве безусловного лидера Oracle, второй - MySQL. У них много общего, но очень много кардинальных различий. Когда возникает задача соединить веб-ресурс с базой данных Oracle без использования её собственных инструментов и технологий, возникает множество вопросов. Сложный connect - давно не редкость, а часто просто условие для достижения решения.

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

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

Безопасность доступа и хранение данных

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

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

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

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

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

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

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

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

Социальный аспект СУБД

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

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

файл-сервер;
клиент-сервер;
встроенная база данных.

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

Реляционные отношения: перспективы

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

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

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

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