Реляционные системы берут свое начало в математической теории множеств. Они были предложены в конце 1968 года доктором Э.Ф. Коддом из фирмы IBM, который первым осознал, что можно использовать давно разработанный математический аппарат для придания надежной основы и строгости области управления базами данных.

Нечеткость многих терминов, используемых в сфере обработки данных, заставила Кодда отказаться от них и придумать новые или дать более точные определения существующим. Так, он не мог использовать широко распространенный термин "запись", который в различных ситуациях может означать экземпляр записи, либо тип записей, запись в стиле Кобола (которая допускает повторяющиеся группы) или плоскую запись (которая их не допускает), логическую запись или физическую запись, хранимую запись или виртуальную запись и т.д. Вместо этого он использовал термин "кортеж длины n" или просто "кортеж", которому дал точное определение. В литературе [3, 4, 5] можно подробно познакомиться с терминологией реляционных баз данных, а здесь мы будем использовать неформальные их эквиваленты: таблица - для отношения, строка или запись - для кортежа, столбец или поле - для атрибута.

Появление теории реляционных баз данных и предложенного Коддом языка запросов "alpha", основанного на реляционном исчислении [6], инициировало разработку ряда языков запросов, которые можно отнести к двум классам:

1. Алгебраические языки, позволяющие выражать запросы средствами специализированных операторов, применяемых к отношениям (JOIN - соединить, INTERSECT - пересечь, SUBTRACT - вычесть и т.д.).
2. Языки исчисления предикатов, представляющие собой набор правил для записи выражения, определяющего новое отношение из заданной совокупности существующих отношений. Другими словами исчисление предикатов есть метод определения того отношения, которое нам желательно получить (как ответ на запрос) из отношений, уже имеющихся в базе данных.

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

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

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

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

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