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

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

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

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

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

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

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

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

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

1.2 Реляционная модель данных

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

В ответ на неправильное использование термина "реляционный" Кодд в 1985 году написал статью, где сформулировал 12 правил (Таблица 1), которым должна удовлетворять любая база данных, претендующая на звание реляционной.

Таблица 1 – Требования к реляционным базам данных