Инструменты пользователя

Инструменты сайта


examination:bd:question20

Понятие реляционной СУБД.

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

-каждый элемент таблицы — один элемент данных

-все ячейки в столбце таблицы однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.)

-каждый столбец имеет уникальное имя

-одинаковые строки в таблице отсутствуют

-порядок следования строк и столбцов может быть произвольным

Базовыми понятиями реляционных СУБД являются:

Кортеж - строки таблицы, отличные от главной.

Отношения - множество кортежей, один и тот же кортеж не может дважды входить в отношение.

Атрибуты - заголовки столбцов.

Домен - допустимое потенциальное множество значений для данного атрибута.

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

Внешний ключ: если сущность С связывает сущности А и В, то С должна включать внешние ключи, соответствующие главным ключам.


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

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

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

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

3) обеспечивает необходимую гибкость при обработке непредвиденных запросов.

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

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

Основными понятиями, с помощью которых определяется реляционная модель, являются следующие: домен, отношение, кортеж, кардинальность, атрибуты, степень, первичный ключ. Соотношение этих понятий иллюстрируется рис. 3.14.

 |Домен              |    Совокупность допустимых значений|
 |Кортеж             |    Таблица                         |
 |Кардинальность     |    Количество строк в таблице      |
 |Атрибут            |    Поле, столбец таблицы           |
 |Степень отношения  |    Количество полей(столбцов)      |
 |Первичный ключ     |    Уникальный идентификатор        |

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

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

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

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

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

  1. данные в ячейках таблицы должны быть структурно неделимыми;
  2. данные в одном столбце должны быть одного типа;
  3. каждый столбец должен быть уникальным (недопустимо дублирование столбцов);
  4. столбцы размещаются в произвольном порядке;
  5. строки размещаются в таблице также в произвольном порядке;
  6. столбцы имеют уникальные наименования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

examination/bd/question20.txt · Последние изменения: 2014/01/15 08:11 (внешнее изменение)