Как расшифровывается субд каково назначение этого вида программного обеспечения

Обновлено: 16.05.2024

Более точно, к числу функций СУБД принято относить следующие:

1. Непосредственное управление данными во внешней памяти

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

2. Управление буферами оперативной памяти

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

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

3. Управление транзакциями

Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое.

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

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

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

4. Журнализация

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

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

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

Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД . Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

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

5. Поддержка языков БД

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

язык определения схемы БД (SDL - Schema Definition Language) и
язык манипулирования данными ( DML - Data Manipulation Language ).

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

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

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

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

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

Функциональные возможности СУБД

По степени универсальности различают два класса СУБД :

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

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

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

СУБД - лидеры на рынке программ:

dBASE IV, компании Borland International;
Microsoft Access 2007;
Microsoft FoxPro 2.6 for DOS;
Microsoft FoxPro for Windows, Microsoft Corp:
Paradox for DOS 4.5:
Paradox for Windows, версия 4.5 Borland.

Производительность СУБД оценивается:

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

На производительность СУБД оказывают влияния 2 фактора:

правильное проектирование
построения БД.

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

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

Операции , обеспечивающие безопасность :

шифрование прикладных программ;
шифрование данных;
защита паролем;
ограничение уровня доступа

Хороший уровень безопасности в СУБД dBase IV, Access

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

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

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

Краткие итоги

Рассмотрены вопросы классификации БД и СУБД .

По технологии обработки данных БД делятся на централизованные БД и распределённые БД . Централизованные БД могут быть с сетевым доступом. Архитектуры систем централизованных БД с сетевым доступом подразделяются на файл-сервер и клиент- сервер . Распределённая БД разделяется по способу доступа к данным БД с локальным и удаленным доступом.

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

Для системы управления базой данных сложились три языка: язык описания данных (ЯОД), язык манипулирования данными (ЯМД), язык запросов .

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

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

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

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

Нужно обязательно сделать ремарку, что некоторые крупные производители, имеют в своем арсенале несколько типов СУБД, как в виде отдельных продуктов, так и в виде внутренней реализации. Например, у Oracle на самом деле чего только нет, начиная с классической реляционной СУБД, продолжая с отдельным продуктом Oracle NoSQL Database, который может использоваться и как документная, и как колоночная, и как ключ-значение. Отдельное решение от того же Oracle, Autonomous Data Warehouse – это уже специализированное решение для хранилищ данных. Еще один отдельный продукт от Oracle – Oracle Graph Server для работы с графами, и еще много другого. Этому можно посвятить отдельную серию статей.

Реляционные СУБД

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

Наиболее известные СУБД такого типа - Oracle, Microsoft SQL, PostgreSQL, MySQL.

Когда выбирать реляционную СУБД

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

Когда не выбирать реляционную СУБД

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

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

СУБД типа ключ-значение

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

Наиболее известные СУБД такого типа - Redis и Memcached.

Когда выбирать СУБД ключ-значение

Когда не выбирать СУБД ключ-значение

Если вы предполагаете хранить в базе данных много сущностей (таблиц), а у сущностей будут сложные структуры с разными типами данных. Так же, если вы предполагаете делать из этой таблицы сложные запросы которые возвращают множества строк.

Документные СУБД

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

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

Так же, само название "документо-ориентированная" подчас вводит в заблуждение, и мне встречались коллеги, которые считали, что это база для систем документооборота. Нет, это не так.

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

Известными представителями таких СУБД являются CouchDB, MongoDB, Amazon DocumentDB.

Когда выбирать документную СУБД

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

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

Когда не выбирать документную СУБД

Не самое лучшее решение для реализации транзакционная модели, и точно не лучший вариант для формирования отчетности.

Графовые СУБД

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

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

Известные представители этого типа субд - Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid.

Когда выбирать графовые СУБД

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

Когда не выбирать графовые СУБД

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

Колоночные СУБД

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

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

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

Яркие представители колоночных СУБД - Sybase IQ (ныне SAP IQ), Vertica, ClickHouse, Google BigTable, InfoBright, Cassandra.

Когда выбирать колоночные СУБД

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

Когда не выбирать колоночные СУБД

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

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

Итоги

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

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

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

В данной статье я намеренно не делаю акцент на выбор между облачными и on-premise решениями - эта тема одной из следующих статей.

Итак, в таблице представленной ниже, кратко собрано то, что описано выше в статье.

Тип СУБД

Когда выбирать

Примеры популярных СУБД

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

Oracle, MySQL, Microsoft SQL Server, PostgreSQL

Для хранения объектов в одной сущности, но с разной структурой; хранение структур на основе JSON

CouchDB, MongoDB, Amazon DocumentDB

Задачи подобные социальным сетям; системы оценок и рекомендаций

Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid

Хранилища данных; выборки со сложными аналитическими вычислениями; количество строк в таблице превышает сотни миллионов

Vertica, ClickHouse, Google BigTable, Sybase \ SAP IQ, InfoBright, Cassandra

Надеюсь данная статья оказалась полезной.

В следующих статьях посмотрим на выбор между облачными и on-premise СУБД, платными и бесплатными, и многое другое.

Что такое СУБД

Итак, давайте сразу начнем с расшифровки, что же такое СУБД.

СУБД – это система управления базами данных.

Иными словами, СУБД относится к сфере компьютерных баз данных.

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

Что такое база данных

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

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

Реляционная база данных – это упорядоченная информация, связанная между собой определёнными отношениями.

Логически такая база данных представлена в виде таблиц, в которых и хранится вся эта информация.

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

И здесь возникает вопрос, если база данных — это файлы, созданные в специальном формате, то как создать такие файлы и редактировать их?

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

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

Какие бывают СУБД

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

Что такое SQL

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

SQL (Structured Query Language) — язык структурированных запросов, с помощью него пишутся специальные запросы к базе данных с целью получения данных из базы данных или для манипулирования этими данными.

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

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

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

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

Microsoft SQL Server

Microsoft SQL Server – это система управления базами данных от компании Microsoft. Она очень популярна в корпоративном секторе, особенно в крупных компаниях.

Microsoft SQL Server – это очень функциональная СУБД, и она, конечно же, распространяется платно. Однако у SQL Server есть редакция Express, которую можно использовать абсолютно бесплатно, например, для обучения или для разработки приложений, которые будут обрабатывать данные на небольших серверах (размером до 10 ГБ).

В Microsoft SQL Server для программирования в базах данных используется расширение языка SQL – Тransact-SQL, сокращенно T-SQL.

Oracle Database

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

В Oracle Database используется язык PL/SQL (Procedural Language / Structured Query Language) — это процедурное расширение языка SQL, разработанное компанией Oracle.

MySQL

MySQL – это система управления базами данных также от компании Oracle, но только она распространяется бесплатно. MySQL получила очень широкую популярность в интернете, так как именно на MySQL работают чуть ли не все web-сайты, иными словами, большинство сайтов в интернете используют эту СУБД как средство хранения данных.

PostgreSQL

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

В PostgreSQL используется язык PL/pgSQL – это процедурное расширение языка SQL.

Выводы

В заключение давайте подведем итог.

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

На сегодня это все, удачи Вам, пока!

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

Каталог СУБД-решений и проектов доступен на TAdviser.

Содержание

Чем крупнее компания, чем дольше она существует на рынке, тем больше данных скапливается в ее архивах. Причем, в соответствии с реалиями сегодняшнего дня, вся информация хранится в электронной форме. По данным исследования Aberdeen Group, три года назад в крупных компаниях объемы хранимой информации увеличивались на 32% ежегодно. Сегодня бизнес-аналитика оперирует уже многотерабайтными объемами данных, а сами хранилища отчетливо перемещаются на облачные платформы.

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

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

Аутсорсинг СУБД

2020: В каких случаях нужно передавать на аутсорсинг СУБД и бизнес-приложения

В апреле 2020 года директор центра технического консалтинга РДТЕХ Павел Шмелев перечислил основные плюсы аутсорсинга и рассказал, зачем компании отдают на сторону сопровождение собственных СУБД. Подробнее здесь.

Каким требованиям должна отвечать современная СУБД?

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

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

Необходимо отметить, что количество информации увеличивается не только в объеме, но и качественно. В результате появляется необходимость одновременной работы с ней нескольких экспертов. Кроме того, появляется возможность привлечения специализированных экспертов для выполнения сложных процедур анализа данных (Data mining Интеллектуальный анализ данных). Сегодня не только для формирования будущей стратегии, но и для выполнения повседневных задач все большее значение имеет прогнозная аналитика, которая для формирования верного вектора развития использует объективные, а не субъективные данные.

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

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

Рынок СУБД в России

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

Классификация

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

Иерархические
Многомерные
Реляционные
Сетевые
Объектно-ориентированные
Объектно-реляционные

Файловые системы

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

распределение внешней памяти;
отображение имеет файлов в соответствующие адреса во внеш-ней памяти;
обеспечение доступа к данным.

Рассмотрение особенностей реализации отдельных систем управления файлами выходит за рамки данной темы. На данном этапе достаточно знать, что прикладные программы видят файл как линейную последовательность записей и могут выполнить над ним ряд операций. Основные операции сфайлами в СУФ:

создать файл (определенного типа и размера)
открыть ранее созданный файл
прочитать из файла определенную запись
изменить запись
добавить запись в конец файла

СУБД крупных ЭВМ

Данный этап развития связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС-ЭВМ и различных моделях фирмы Hewlett Packard. В таком случае информация хранилась во внешней памяти центральной ЭВМ. Пользователями баз данных были фактически задачи, запускаемые в основном в пакетном режиме. Интерактивный режим доступа обеспечивался с помощью консольных терминалов, которые не обладали собственными вычислительными ресурсами (процессором, оперативной памятью, внешней памятью) и служили только устройствами ввода-вывода для центральной ЭВМ. Программы доступа к БД писались на различных языках программирования и запускались как обычные числовые программы. Особенности данного этапа:

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

Настольные СУБД

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

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

Стандартизация высокоуровневых языков манипулирования данными (разработка и внедрение стандарта SQL92 во все СУБД).

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

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

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

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

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

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

Сравнительно скромные требования к аппаратному обеспечению со стороны настольных СУБД. Вполне работоспособные приложения, разработанные, например, на Clipper, работали на PC 286. В принципе, их даже трудно назвать полноценными СУБД. Яркие представители этого семейства — очень широко использовавшиеся до недавнего времени СУБД Dbase (DbaseIII+, DbaseIV), FoxPro, Clipper, Paradox.

Продукты

Каталог СУБД-решений и проектов доступен на TAdviser.

История

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

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

Рост производительности персональных вычислительных машин спровоцировал развитие СУБД, как отдельного класса. К середине 60-х годов прошлого века уже существовало большое количество коммерческих СУБД. Интерес к базам данных увеличивался все больше, так что данная сфера нуждалась в стандартизации. Автор комплексной базы данных Integrated Data Store Чарльз Бахман (Charles Bachman) организовал целевую группу DTG (Data Base Task Group) для утверждения особенностей и организации стандартов БД в рамках CODASYL - группы, которая отвечала за стандартизацию языка программирования COBOL. Уже в 1971 году был представлен свод утверждений и замечаний, который был назван Подход CODASYL, и спустя некоторое время появились первые успешные коммерческие продукты, изготовленные с учетом замечаний вышеупомянутой рабочей группы. В 1968 году отметилась и компания IBM, которая представила собственную СУБД gпод названием IMS.

Фактически данный продукт представлял собой компиляцию утилит, которые использовались с системами System/360 на шаттлах Аполлон. Решение было разработано согласно коцпетам CODASYL, но при этом была применена строгая иерархия для структуризации данных. В свою очередь в варианте CODASYL за базис была взята сетевая СУБД. Оба варианта, меж тем, были приняты сообществом позднее как классические варианты организации работы СУБД, а сам Чарльз Бахман в 1973 году получил премию Тьюринга за работу Программист как навигатор. В 1970 году сотрудник компании IBM Эдгар Кодд, работавший в одном из отделений Сан Хосе (США), в котором занимались разработкой систем хранения, написал ряд статей, касающихся навигационных моделей СУБД. Заинтересовавшись вопросом он разработал и изложил несколько инновационных подходов касательно оптимальной организаци систем управления БД. Работа Кодда внесла значительный вклад в развитие СУБД и является действительным основоположником теории реляционных баз данных. Уже 1981 году Э.Ф.Кодд создал реляционную модель данных и применил к ней операции реляционной алгебры.

Читайте также: