Основные понятия реляционной модели данных

Часть 2. Реляционная модель данных

Реляционная модель является удобной и наиболее привыч­ной формой представления данных в виде таблицы.

В отличие от иерархической и сетевой моделей, такой способ представления:

1. понятен пользователю-непрограммисту;

2. позволяет легко изменять схему - присоединять новые элементы данных и запи­си без изменения соответствующих подсхем;

3. обеспечивает не­обходимую гибкость при обработке непредвиденных запросов. К тому же любая сетевая или иерархическая схема может быть представлена двумерными отношениями.

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

Пользо­ватель модели сам должен для себя решить вопрос, обладают ли соответствующие сущности реального мира однородностью. Этим самым решается проблема пригодности модели для пред­полагаемого применения.

Основными понятиями, с помощью которых определяется реляционная модель, являются следующие:

1. домен,

2. отношение,

3. кортеж,

4. кардинальность,

5. атрибуты,

6. степень,

7. первичный ключ.

Соотношение этих понятий иллюстрируется рисунок 7.

Рис. 7. Основные понятия реляционной модели

Таблица 7.

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

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

В математических дисциплинах понятию «таблица» соответствует понятие «отношение» (relation). Отсюда и произошло название модели - реляционная. То есть, применительно к базам данных понятия «реляци­онная БД» и «табличная БД» по существу являются синонимами.

Первичный ключ - это столбец или некоторое подмножество столбцов, которые уникально, т. е. единственным образом опре­деляют строки. Первичный ключ, который включает более одно­го столбца, называется множественным, или комбинированным, или составным. Правило целостности объектов утверждает, что первичный ключ не может быть полностью или частично пус­тым, т. е. иметь значение null.

Остальные ключи, которые можно также использовать в ка­честве первичных, называются потенциальными или альтерна­тивными ключами.

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

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

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

Модель предъявляет к таблицам следующие требования:

1. данные в ячейках таблицы должны быть структурно неде­лимыми¹;

2. данные в одном столбце должны быть одного типа;

3. каждый столбец должен быть уникальным (недопустимо дублирование столбцов);

4. столбцы размещаются в произвольном порядке;

5. строки размещаются в таблице также в произвольном по­рядке;

6. столбцы имеют уникальные наименования.

В целом концепция реляционной модели определяется сле­дующими двенадцатью правилами Кодда (в лекции правила приводятся по [1]).

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

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

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

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

5. Правило исчерпывающего подъязыка данных. Реляционная система может поддерживать различные языки и режимы взаи­модействия с пользователем (например, режим вопросов и отве­тов). Однако должен существовать, по крайней мере, один язык, операторы которого можно представить в виде строк символов в соответствии с некоторым четко определенным синтаксисом и который в полной мере поддерживает следующие элементы:

• определение данных;

• определение представлений;

• обработку данных (интерактивную и программную);

• условия целостности;

• идентификацию прав доступа;

• границы транзакций (начало, завершение и отмена).

6. Правило обновления представлений. Все представления, ко­торые теоретически можно обновить, должны быть доступны для обновления.

7. Правило добавления, обновления и удаления. Возможность работать с отношением как с одним операндом должна сущест­вовать не только при чтении данных, но и при добавлении, об­новлении и удалении данных.

8. Правило независимости физических данных. Прикладные программы и утилиты для работы с данными должны на логиче­ском уровне оставаться нетронутыми при любых изменениях способов хранения данных или методов доступа к ним.

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

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

11. Правило независимости распространения. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.

12. Правило единственности. Если в реляционной системе есть низкоуровневый язык (обрабатывающий одну запись за один раз), то должна отсутствовать возможность использования его для того, чтобы обойти правила и условия целостности, вы­раженные на реляционном языке высокого уровня (обрабаты­вающем несколько записей за один раз).

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

Правило 3 требует, чтобы отсутствующие данные можно было представить с помощью недействительных значений (NULL).

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

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

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

Правило 7 акцентирует внимание на том, что базы дан­ных по своей природе ориентированы на множества. Оно требу­ет, чтобы операции добавления, удаления и обновления можно было выполнять над множествами строк. Это правило предназначено для того, чтобы запретить реализации, в которых под­держиваются только операции над одной строкой.

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

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

Правило 11 гласит, что язык базы данных должен обеспечи­вать возможность работы с распределенными данными, располо­женными на других компьютерных системах.

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

­

Литература

1. Дейт К. Введение в системы баз данных: Пер. с англ. - М.: Наука, 1980.- 463 с.

2. Грофф Дж., Ваинберг П. SQL: полное руководство / Пер. с англ. 2-е изд. К.: BHV, 2001.

­

Дата добавления: 2014-11-29