7 типов современных баз данных: предназначение, достоинства и недостатки

История создания

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

Идея системы электронных БД стала одним из наиболее актуальных нововведений в компьютерных разработках. Первыми моделями, которые были разработаны, были иерархические и сетевые базы данных. IBM в семидесятых произвела революцию в этом секторе, с разработкой модели реляционных БД. Наиболее успешными продуктами в то время были язык запросов БД Oracle SQL и преемники IBM, SQL/DS и DB2.

Типы баз данных

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

Это:

1. Иерархическая база данных.
2. Сетевая (распределенная) база данных.
3. Реляционная база данных.

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

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

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

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

Как именовать конкретные реляционные отношения — не суть важно

SQLite

Провозгласившая себя самой распространенной СУБД в мире, SQLite зародилась в 2000 году и используется Apple, , Microsoft и . Каждый релиз тщательно тестируется. Разработчики SQLite предоставляют пользователям списки ошибок, а также хронологию изменений кода каждой версии.

Достоинства

• Нет отдельного серверного процесса;
• Формат файла – кросс-платформенный;
• Транзакции соответствуют требованиям ACID;
• Доступна профессиональная поддержка.

Недостатки

Не рекомендуется для:

• клиент-серверных приложений;
• крупномасштабных сайтов;
• больших наборов данных;
• программ с высокой степенью многопоточности.

Динамика организации данных

Жесткая модель данных существует до того момента, пока не изменились внешние обстоятельства. В начале 90-х никто не думал, что две цифры в поле даты, отведенные под год — достаточны. Сколько паники и проблем вызвал барьер 640 Кб памяти на заре компьютеростроения.

Насколько ужасно выглядит сегодня способ доступа к данным в dBase, Clarion, FoxPro, в то время как в начале 90-х всех все устраивало. Довольны были и разработчики, и пользователи. Но тогда информации было мало, да и алгоритмы были примитивные.

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

Сегодня иерархическая база данных — это не только вариант реляционных отношений, учитывающий неравноправие данных, подчиненность одного другому или зависимость чего-либо от события, объекта или действия потребителя. Иерархия дополняет реляционную концепцию в том смысле, что разграничивает работу на уровне базы данных, таблицы, запросов и собственно информации.

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

Сетевая модель данных

Стандарт
сетевой модели впервые был определен в 1975 году организацией CODASYL (Conference
of Data System Languages), которая определила базовые понятия модели и формальный
язык описания.

Базовыми
объектами модели являются:

• элемент данных;
• агрегат данных;
• запись;
• набор данных,

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

Агрегат данных
—
соответствует следующему уровню обобщения в модели. В модели определены
агрегаты двух типов: агрегат типа вектор и агрегат типа повторяющаяся группа.

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

Адрес
Город	Улица	дом	квартира

Агрегат типа
повторяющаяся группа соответствует совокупности векторов данных. Например, агрегат
Зарплата соответствует типу повторяющаяся группа с числом повторений 12.

Зарплата
Месяц	Сумма

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

Следующим
базовым понятием в сетевой модели является понятие «Набор».

Набор
—
это двухуровневый граф, связывающий отношением «один-ко-многим» два типа записи.

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

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

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

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

	Преподаватель	Группа	День недели	№ пары	Аудитория	Дисциплина
	Иванов	4306	Понедельник	1	22-13	КИД
	Иванов	4307	Понедельник	2	22-13	КИД
	Карпова	4307	Вторник	2	22-14	БЗ и ЭС
	Карпова	4309	Вторник	4	22-14	БЗ и ЭС
	Карпова	84305	Вторник	1	22-14	БД
	Смирнов	4306	Вторник	3	23-07	ГВП
	Смирнов	4309	Вторник	4	23-07	ГВП

Экземпляров
набора Ведет занятия будет 3 (по числу преподавателей), экземпляром набора Занимается
у будет 4 (по числу групп). На рис. 3.6 представлены взаимосвязи экземпляров
данных наборов.

Рис.
3.6. Пример взаимосвязи экземпляров двух наборов

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

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

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

Представления о преимуществах и недостатках

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

Одни авторы относят к преимуществам:

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

Другие смотрят на преимущества иначе:

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

Недостатки определяют обычно так:

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

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

Представления о преимуществах и недостатках

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

Одни авторы относят к преимуществам:

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

Другие смотрят на преимущества иначе:

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

Недостатки определяют обычно так:

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

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

Виды баз данных и их структура, примеры

Выделяют несколько видов баз данных. Основными из них являются:

1. Фактографическая, с краткой информацией об объектах какой-то системы, формат которой строго фиксирован.
2. Документальная, включает документы разного вида, в том числе текстовые, графические, звуковые, мультимедийные.
3. Распределенная, является базой данных с разными частями, которые хранятся на различных компьютерах, объединенных в сеть.
4. Централизованная, представляет собой базу данных, местом хранения которой является один компьютер.
5. Реляционная, имеет табличную организацию данных.
6. Неструктурированная (NoSQL), является базой данных, в которой делается попытка решить проблемы масштабируемости и доступности с помощью атомарности и согласованности данных без четкой структуры.

Базы данных разных систем обладают неодинаковой структурой. Для ПЭВМ характерно использование реляционных баз данных с файлами в виде таблиц, в которых столбцы являются полями, а строки – записями. В базе данных находятся данные определенного множества объектов. Для каждой записи характерна информация по одному объекту. Такую базу определяют:

• имя файла;
• список полей;
• ширина полей.

В качестве примера можно привести школьную базу с данными «Ученик», «Класс», «Адрес». Также базой данных является расписание движения поездов или автобусов. В этом случае каждой строке соответствует запись с данными конкретного объекта. Возможные поля: номер рейса, маршрут, время отправления и прибытия. Классической базой данных является телефонный справочник.

Определение

Запрос к базе данных – предписание с указанием на данные, которые необходимы пользователю.

Примечание

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

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

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

В случае Access роль таких звеньев выполняют:

1. Table.
2. DataSource.
3. DBGrid.

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

БД => набор данных –=> источник данных => визуальные компоненты => пользователь

Набор данных:

• Table, в виде таблицы, навигационного доступа;
• Query, включая запрос, реляционный доступ.

Визуальными компонентами являются:

1. Сетки DBGrid, DBCtrlGrid.
2. Навигатор DBNavigator.
3. Разные аналоги Lable, Edit.
4. Компоненты подстановки.

Access характеризуется наличием следующих типов полей:

• текстовый, в виде текстовой строки с максимальной длиной до 255, заданной параметром «размер»;
• поле МЕМО, является текстом длиной до 65535 символов;
• числовой, в параметре «Размер поля» можно задать поле: байт, целое, действительное и другие;
• дата/время, необходимо для записи данных о времени;
• денежный, является специальным форматом для решения финансовых задач;
• счетчик, в виде автоинкрементного поля, который предназначен для ключевого поля, увеличивается на единицу после добавления новой записи и сохраняется в данное поле новой записи, что гарантирует разные значения для неодинаковых записей;
• логический, в виде «да или нет», «правда или ложь», «включен или выключен»;
• объект OLE, предназначен для хранения документов, картинок, звуков и другой информации, представляет собой частный случай BLOB, то есть полей (Binary Large Object), которые можно встретить в разных базах данных;
• гиперссылка, необходима для хранения ссылок на ресурсы в Интернете, характерна не для всех форматов баз данных, например, отсутствует в dBase и Paradox;
• подстановка.

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

Классификации СУБД

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

СУБД по модели данных бывают:

• Иерархические СУБД
• Сетевые СУБД
• Реляционные СУБД
• Объектно-ориентированные СУБД
• Объектно-реляционные СУБД

В настоящее время в серьезных проекта используются 2 последних типа.

СУБД по степени распределённости

• Локальные (СУБД размещается только на одном компьютере)
• Распределённые (части СУБД могут размещаться на 2-х и более компьютерах).

По способу доступа к БД

Файл-серверные СУБД

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

Плюсом этой архитектуры можно назвать низкую нагрузку на файловый сервер.

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

Сейчас её при создании крупной информационной системы не используют.

Примеры файл-серверных СУБД:

• dBase,
• FoxPro,
• Microsoft Access,
• Paradox,
• Visual FoxPro.

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

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

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

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

Примеры клиент-серверных СУБД:

• Caché,
• Firebird,
• IBM DB2,
• Informix,
• Interbase,
• MS SQL Server,
• MySQL, Oracle,
• PostgreSQL,
• Sybase Adaptive Server Enterprise,
• ЛИНТЕР.

Встраиваемые СУБД

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

Примеры встраиваемых СУБД:

• Firebird Embedded,
• BerkeleyDB,
• Microsoft SQL Server Compact,
• OpenEdge,
• SQLite,
• ЛИНТЕР.

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

Какие реляционные БД популярны в веб-разработке

MySQL

Это открытая СУБД, купленная Oracle в придачу к Sun Microsystems. С ней работают более половины (55,6%) всех разработчиков (по  опроса, который в 2020 году провёл сайт StackOverflow.com среди 65 тысяч респондентов).

Главные её преимущества — бесплатность и высокая скорость работы с данными. MySQL создавалась для обработки огромных массивов информации в промышленных масштабах, но благодаря доступности и быстродействию оккупировала Всемирную паутину, заслужив звание «СУБД всея интернета». И сегодня MySQL всё ещё самая удобная СУБД для работы с интернет-страницами и веб-приложениями.

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

SQLite

Эта СУБД использует большую часть стандартного языка SQL.

Главное преимущество SQlight — встраиваемость. Это объясняется тем, что SQlight не приложение типа «клиент-сервер» (в отличие от других реляционных СУБД), а библиотека, которую подключают непосредственно к программе.

И она тоже весьма популярна: достаточно сказать, что SQLite есть в каждом смартфоне. Например, в смартфонах на Android там хранятся контакты и медиа, а в iOS её используют многие приложения.

PostgreSQL

Её можно назвать самой продвинутой. Это не просто реляционная, а объектно-реляционная свободная СУБД.

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

O(1) vs O(n2)

В настоящее время многие разработчики не заботятся о временной сложности алгоритмов … и они правы!

Но когда вы имеете дело с большим количеством данных (я не говорю о тысячах) или если вы боретесь за миллисекунды, становится критически важным понять эту концепцию. И как вы понимаете, базы данных должны иметь дело с обеими ситуациями! Я не заставлю вас потратить больше времени, чем необходимо чтобы ухватить суть. Это поможет нам позже понять концепцию оптимизации на основе затрат (cost based optimization).

Концепция

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

Например, когда я говорю «этот алгоритм имеет сложность O (some_function() )», это означает, что для обработки определенного объема данных алгоритму требуется some_function(a_certain_amount_of_data) операций.

При этом важно не количество данных**, а то, ** как увеличивается количество операций при увеличении объема данных. Сложность по времени не дает точное количество операций, но хороший способ для оценки времени выполнения

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

• O(1) или постоянная сложность остаются постоянными (иначе это не будет называться постоянной сложностью).
• O(log(n)) остается низкой даже с миллиардами данных.
• Наихудшая сложность — O(n2), где количество операций быстро растет.
• Две другие сложности так же быстро увеличиваются.

Примеры

При небольшом количестве данных разница между O(1) и O(n2) незначительна. Например, предположим, что у вас есть алгоритм, который должен обрабатывать 2000 элементов.

• Алгоритм O (1) обойдется вам в 1 операцию
• Алгоритм O (log (n)) обойдется вам в 7 операций
• Алгоритм O (n) обойдется вам в 2 000 операций
• Алгоритм O (n * log (n)) обойдется вам в 14 000 операций
• Алгоритм O (n2) обойдется вам в 4 000 000 операций

Как я уже сказал, по-прежнему важно знать эту концепцию при работе с огромным количеством данных. Если на этот раз алгоритм должен обработать 1 000 000 элементов (что не так уж много для базы данных):

• Алгоритм O (1) обойдется вам в 1 операцию
• Алгоритм O (log (n)) обойдется вам в 14 операций
• Алгоритм O (n) обойдется вам в 1 000 000 операций
• Алгоритм O (n * log (n)) обойдется вам в 14 000 000 операций
• Алгоритм O (n2) обойдется вам в 1 000 000 000 000 операций

Я не делал расчетов, но я бы сказал, что с помощью алгоритма O (n2) у вас есть время выпить кофе (даже два!). Если вы добавите еще 0 к объему данных, у вас будет время, чтобы вздремнуть.

Идем глубже

Для справки:

• Поиск в хорошей хеш-таблице находит элемент за O (1).
• Поиск в хорошо сбалансированном дереве дает результат за O (log (n)).
• Поиск в массиве дает результат за O (n).
• Лучшие алгоритмы сортировки имеют сложность O (n * log (n)).
• Плохой алгоритм сортировки имеет сложность O (n2).

Примечание: в следующих частях мы увидим эти алгоритмы и структуры данных.

Есть несколько типов временной сложности алгоритма:

• сценарий среднего случая
• лучший вариант развития событий
• и худший сценарий

Временная сложность часто является наихудшим сценарием.

Я говорил только о временной сложности алгоритма, но сложность также применима для:

• потребления памяти алгоритмом
• потребления дискового ввода / вывода алгоритмом

Конечно, есть сложности хуже, чем n2, например:

• n4: это ужасно! Некоторые из упомянутых алгоритмов имеют такую сложность.
• 3n: это еще хуже! Один из алгоритмов, которые мы увидим в середине этой статьи, имеет эту сложность (и он действительно используется во многих базах данных).
• факториал n: вы никогда не получите свои результаты даже с небольшим количеством данных.
• nn: если вы столкнетесь с этой сложностью, вы должны спросить себя, действительно ли это ваша сфера деятельности …

Реляционные базы данных SQL

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

Достоинства:

• Поддержка SQL
• ACID-транзакции (атомарность, согласованность, изоляция и долговечность)
• Поддержка индексации и разделения

Недостатки:

• Плохая поддержка неструктурированных данных / сложных типов
• Плохая оптимизация обработки событий
• Сложное / дорогое масштабирование

Примеры: Oracle DB, MySQL, PostgreSQL.

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

MySQL — это система управления реляционными базами данных с открытым исходным кодом, основанная на SQL. Он был разработан и оптимизирован для веб-приложений и может работать на любой платформе. По мере появления в Интернете новых и различных требований MySQL стала предпочтительной платформой для веб-разработчиков и веб-приложений. Поскольку MySQL предназначен для обработки миллионов запросов и тысяч транзакций, он является популярным выбором для предприятий электронной коммерции, которым необходимо управлять несколькими денежными переводами. Гибкость по запросу — основная особенность MySQL.

MySQL — это СУБД, стоящая за некоторыми из ведущих веб-сайтов и веб-приложений в мире, включая Airbnb, Uber, LinkedIn, Facebook, Twitter и YouTube.

Как автономные технологии улучшают управление базами данных

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

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

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

Основой для многих информационных систем (прежде всего, информационно-справочных систем) являются базы данных.

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

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

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

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

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

Термины и понятия, связанные с расширенными событиямиTerms and concepts in extended events

В приведенной ниже таблице перечислены термины, используемые в связи с расширенными событиями, и объясняется их смысл.The following table lists the terms used for extended events, and describes their meanings.

ТерминTerm	ОписаниеDescription
сеанс событийevent session	Целью является конструкция, основанная на одном или нескольких событиях, а также вспомогательные элементы, такие как действия.A construct centered around one or more events, plus supporting items like actions are targets. Инструкция CREATE EVENT SESSION создает каждый сеанс событий.The CREATE EVENT SESSION statement constructs each event session. С помощью инструкции ALTER можно по желанию запускать и останавливать сеансы.You can ALTER an event session to start and stop it at will. Сеанс событий часто называется просто сеансом, если из контекста понятно, что имеется в виду именно сеанс событий.An event session is sometimes referred to as just a session, when the context clarifies it means event session. Более подробные сведения о сеансах событий см. в статье Сеансы расширенных событий SQL Server.Further details about event sessions are described in: SQL Server Extended Events Sessions.
eventevent	Определенное событие в системе, наступление которого отслеживается активным сеансом событий.A specific occurrence in the system that is watched for by an active event session. Например, событие sql_statement_completed представляет момент завершения какой-либо инструкции T-SQL.For example, the sql_statement_completed event represents the moment that any given T-SQL statement completes. Событие может сообщать различные данные, например длительность.The event can report its duration and other data.
targettarget	Элемент, который получает выходные данные из регистрируемого события.A item that receives the output data from a captured event. Служит для вывода данных.The target displays the data to you. Примерами могут служить event_file и его облегченная версия ring_buffer, хранимая в памяти.Examples include the event_file, and its handy light-weight cousin the memory ring_buffer. Более сложная целевая гистограмма выполняет ряд задач по обработке данных перед их выводом.The fancier histogram target performs some processing of your data before displaying it. Любой целевой объект можно использовать для любого сеанса событий.Any target can be used for any event session. Дополнительные сведения см. в разделе Целевые объекты для расширенных событий в SQL Server.For details, see Targets for Extended Events in SQL Server.
actionaction	Поле, известное событию.A field known to the event. Данные из этого поля отправляются в целевой объект.Data from the field is sent to the target. Поле действия тесно связано с фильтром предиката.The action field is closely related to the predicate filter.
фильтром предикатаpredicate filter	Проверка данных в поле события, благодаря которой только нужное подмножество экземпляров события отправляется целевому объекту.A test of data in an event field, used so that only an interesting subset of event occurrences are sent to the target. Например, фильтр может включать только те экземпляры события sql_statement_completed , в которых инструкция T-SQL содержит строку HAVING.For example, a filter could include only those sql_statement_completed event occurrences where the T-SQL statement contained the string HAVING.
Пакетpackage	Квалификатор имени, добавляемый к каждому элементу в наборе элементов, связанном с пакетом событий.A name qualifier attached to each item in a set of items that centers around a core of events. Например, пакет событий может включать события, связанные с текстом T-SQL.For example, a package might have events about T-SQL text. Одно из событий может быть связано с кодом T-SQL в пакете, отделенном командой GO.One event could be about all the T-SQL in a GO-delimited batch. А другое более частное событие может быть связано с отдельными инструкциями T-SQL.Meanwhile another narrower event is about individual T-SQL statements. Кроме того, для каждой инструкции T-SQL есть события начала и завершения.Further, for any one T-SQL statement, there is are start and completed events. Соответствующие событиям поля также содержатся в пакете с событиями.Fields appropriate for the events are also in the package with the events. Большинство целевых объектов находятся в пакете package0 и используются с событиями из многих других пакетов.Most targets are in package0 and are used with events from many other packages.

Использование баз данных для повышения эффективности бизнеса и принятия решений

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

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

Настоящее и будущее

Если упрощённо, то реляционный подход описывает данные в формате таблиц, то есть вся информация неразрывно связана отношениями и структурой (вспомните Excel со столбцами и строками, где каждый новый объект записывается по тому же шаблону). Это неизбежно приводит к ограничениям по производительности и масштабированию, но с точки зрения создания и управления – это просто и удобно.

NoSQL подход позволяет избежать этих проблем за счёт отсутствия строгих информационных связей. Но тут возникает другая проблема – организация доступа. Решается она 4 основными способами: с помощью документной ориентации, расширяемых записей (разреженных матриц), ключей доступа и теории графов. Естественно, что подход NoSQL требует от разработчика больше знаний и умений, но результаты куда эффективнее. Именно поэтому считается, что SQL уже сейчас уходит в историю, а NoSQL – будущее всех БД.

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