Концепция реляционной модели. Правила Кодда.

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ
«ДОНСКОЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

(ДГТУ)

КОНТРОЛЬНАЯ РАБОТА

 

Дисциплина (модуль) _____________________ Базы Данных ____________________________

наименование учебной дисциплины (модуля)

Направление подготовки/специальность _ 09.03.03 __ __ Прикладная информатика __________

код наименование направления подготовки/специальности

 

Направленность (профиль) ___ Прикладная информатика в информационной сфере _________

 

Номер зачетной книжки __ 1766925 __ Номер варианта __ 25 ___ Группа _ ВЗПИ21 ________

 

Обучающийся _______________________ __ В.О.Трегубова ___________

подпись, дата И.О. Фамилия

 

Контрольную работу проверила_____________________ ________________________

подпись, дата И.О. Фамилия

 

Ростов-на-Дону

 

 

Вариант 25

Вопрос 6: Реляционная модель данных. Концепция реляционной модели. Правила КОДДА. Составные части реляционной модели. Структура данных реляционной модели. Реляционная целостность данных. Индексирование

Вопрос 18: Хеширование. Стратегия разрешения коллизий с областью переполнения. Организация стратегий свободного замещения.

 

Вопрос 6

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

Основу модели составляет набор взаимосвя­занных таблиц, в которых хранятся данные.

Реляционная модель является удобной и наиболее привычной формой представления данных в виде таблицы (применительно к базам данных понятия «реляционная БД» и «табличная БД» по существу являются синонимами). В отличие от иерархи­ческой и сетевой модели такой способ представления:

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

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

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

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

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

Реляционный термин	Описание
Отношение	Таблица — совокупность объектов реального мира, которые характеризуются общими свой­ствами и характеристиками (поля таблицы)
Заголовок отношения	Заголовок таблицы — названия полей (столбцов) таблицы
Тело отношения	Тело таблицы — совокупность значений для всех объектов реального мира, которая представима в виде записей таблицы (строки таб­лицы)
Схема отношения	Строка заголовков столбцов таблицы (заголовок таблицы)
Атрибут отношения	Наименование столбца таблицы (поле таблицы)
Кортеж отношения	Строка таблицы (запись) — однозначное представление объекта реального мира, соз­данное с использованием значений полей таблицы
Домен	Множество допустимых значений атрибута
Значение атрибута	Значение поля в записи
Первичный ключ	Один или несколько атрибутов, который уни­кальным (единственным) образом определяет значение кортежа (значение строки таблицы)
Внешний ключ	Атрибут таблицы, значения которого соответ­ствуют значениям первичного ключа в другой связанной таблице. Внешний ключ может со­стоять как из одного, так и из нескольких ат­рибутов (составной внешний ключ). Если чис­ло атрибутов внешнего ключа меньше, чем количество атрибутов соответствующего пер­вичного ключа, то он называется усеченным (частичным) внешним ключом
Степень(арность) отношения	Количество столбцов таблицы
Мощность отношения	Количество строк таблицы (количество кортежей)
Тип данных	Тип значений элементов таблицы
Базовое отношение	Отношение, которое содержит один или не­сколько столбцов, характеризующих свойства объекта, а также первичный ключ
Производное отношение	Использу­ется для обеспечения связей между другими таблицами, может не содержать первичного ключа; если первичный ключ задан, то он со­стоит из внешних ключей, которые связаны с первичными ключами базового отношения

Таблица 1. Элементы реляционной модели.

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

Концепция реляционной модели. Правила Кодда.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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