Первый вопрос, который требует уточнения, это "что такое база данных"?
Цитата:
База данных — представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ).
А теперь СУБД:
Цитата:
Система управления базами данных (СУБД) — совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных.
Мы видим, что определения настолько общие, что даже HTML-страница может выть рассмотрена как база данных, а jQuery может быть рассмотрено как СУБД. И, соответственно, операции не выглядят настолько уж сложными:
$("div.test").add("p.quote").addClass("blue").slideDown("slow");
Вопрос, наверное, был связан с современными распространенными СУБД а-ля MySQL, PostgeSQL, Oracle, ..? Тогда уместнее задать вопрос, в каких областях требуется транзакционность, где требуется обработка больших объемов данных? И где клиенты готовы платить
деньги? Очевидно, что мы выходим в банковскую сферу, SAP и т. д. и т. п. и др. и пр., где таблицы возникли исторически задолго до этого. А потом все остальные чуть-непохожие задачи просто сводились к этому и все :)
Но, например, для шахматных баз партий и типичных запросов использование всей этой кухни дает настолько злобный оверхед, что не используется практически нигде. ChessAssistant, ChessBase, scuid используют самописные форматы и движки. Аналогично с базой данных го-партий, и т. п.
А какая связь с математикой? Ну... математика это наука рассуждений. Когда рассуждения становятся очень нетривиальными, желательно иметь способ формализации и возможность решения вопросов в спорных случаях. Например, когда один человек говорит, что он доказал теорему Ферма, а второй не соглашается. Углубляясь в доказательство, мы можем дойти до формального текста, хотя на практике этого обычно не требуется. Все программирование можно легко формализовать при помощи математической нотации. В 70-х годах это казалось важным, компьютерного времени было мало, времени подумать было много. Сейчас на это просто не хватает времени, да и большой пользы во всем этом нет, потому как все вопросы практические, и каких-либо сложных доказательств (рассуждений) там или нет, или уже все сделано.
"Поставщик 
находится в городе 
и имеет статус 
", 
"Деталь 
называется 
и цвета 
", 
"Поставщик 
штук". Соответственно, когда мы подставляем в предикат кортеж, мы получаем высказывание — истинное или ложное. С каждым предикатом естественно связывается множество (множество истинности), состоящее из всех кортежей, которые при подстановке в предикат дают истинные высказывания, и только из них. Это множество является отношением, в математическом смысле (в реляционной теории, правда, принято определять отношения и кортежи чуть иначе, чем в математике: компоненты не нумеруются, а именуются). Ну вот, и мы храним в БД эти отношения.
"Поставщик 
и 
и сделаем операцию 
. И все остальные реляционные операции соответствуют каким-то логическим операциям с предикатами. Если нам нужно что-то узнать, мы формулируем запрос в терминах предикатов, соответствующих хранящимся в БД отношениям, автоматически переводим его в выражение реляционной алгебры — и высчитываем по имеющимся отношениям множество истинности интересующего нас запроса.