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

Данные и программы

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

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

Википедия

Базой данных, пускай и примитивной, могут выступать текстовые файлы.

Что не так с файлами?

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

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

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

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

Основы реляционных баз данных

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

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

Так как строки в таблицах не упорядочены, то мы не можем получить запись по номеру строки, в таблице нет нумерации строк. В правильно построенных таблицах выделяют специальный столбец или группу столбцов — первичный ключ (primary key) — значения столбца (или комбинации столбцов) во всех строках должны быть уникальны. Таблица, в которой все строки уникальны, может быть интерпретирована как отношение (на англ. relation), что и объясняет название данной модели данных.

Связи между таблицами

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

Транзакции

В приложении многое может пойти не так:

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

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

Принцип ACID

ACID описывает требования к системе, обеспечивающие надежную и предсказуемую ее работу. Принцип ACID состоит из четырех требований: Atomicity, Consistency, Isolation и Durability.

Atomicity — Атомарность

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

Consistency — Согласованность

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

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

Isolation — Изолированность

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

Durability — Стойкость

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

---

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

CAP-теорема

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

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

Подробнее

Вместо вывода

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