Лекция №4 Реляционная модель данных

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

Не все таблицы являются отношениями. Чтобы таблица стала отношением она должна соответствовать следующим условиям:

· Каждый столбец имеет уникальное имя. Порядок столбцов в таблице не существенен.

· В таблице не может быть одинаковой записи. Порядок записей в таблице не существенен.

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

· Все записи в столбце должны быть одного типа. Все используемые типы данных должны быть простыми.

Тип данных – это множество значений, которые может принимать переменная.

Типы данных бывают простые, составные и ссылочные.

Простые, или атомарные, типы данных не обладают внутренней структурой. К простым типам данных относятся следующие типы:

• Логический.
• Строковый.
• Численный.

Различные языки программирования могут расширять и уточнять этот список, добавляя такие типы как:

• Целый.
• Вещественный.
• Дата.
• Время.
• Денежный.
• Перечислимый.
• Интервальный.
• И т.д.…

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

• Массивы
• Записи (Структуры)

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

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

Домен- это семантическое понятие. Домен можно рассматривать как подмножество значений некоторого типа данных имеющих определенный смысл. Домен характеризуется следующими свойствами:

• Домен имеет уникальное имя(в пределах базы данных).
• Домен определен на некотором простомтипе данных или на другом домене.

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

Например, домен , имеющий смысл "возраст сотрудника" можно описать как следующее подмножество множества натуральных чисел:

Если тип данных можно считать множеством всех возможных значений данного типа, то домен напоминает подмножество в этом множестве.

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

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

Таблица – отношение Таблица не является отношением:

Функциональная зависимость – это связь между атрибутами. Если мы знаем значение одного атрибута, то мы можем найти и значений второго атрибута, тогда говорят, что второй атрибут функционально зависит от первого атрибута. Например, если мы знаем номер счета клиента, то мы можем определить и состояние этого счета. В таком случае мы скажем, что атрибут СостояниеСчетаКлиента функционально зависит от атрибута НомерСчетаКлиента.

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

Детерминант - любой атрибут, от которого полностью функционально зависит некоторый другой атрибут.

Ключи – это группа из одного или более атрибутов, которая уникальным образом идентифицирует строку.

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

Каждое отношение имеет минимум один ключ.

Атрибут Секция в этом примере функционально определяет атрибут Плата, но не является ключом.

Аномалии отношений

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

1. Аномалия удаления. Удаляя данные из одной сущности, мы непроизвольно удаляем факты, касающиеся другой сущности. Пример. Если мы удалим студента с номером 100 из это таблицы, то мы удалим также информацию о том, что секция Лыжи стоит 200 руб.

2. Аномалия вставки. Мы не можем записать в таблицу информацию о некоторой сущности до тех пор, пока не запишем информацию о некоторой другой сущности. Пример. Добавили новую секцию Гольф, ее стоимость 500 р. Но ввести информацию о стоимости мы можем только после того, как какой-нибудь студент запишется в эту секцию.

Как устраняются аномалии? Разбиением таблиц и установкой связи между таблицами.

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

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

Для установки такого рода ограничений используют внешние ключи.

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

Пример. Допустим, что у вас есть две таблицы:

Клиенты – содержит имена людей и состоит из полей идентификатора (ключевое поле), имя.

Телефоны – таблица телефонов, которая состоит из идентификатора (ключевое поле), внешний ключ для связи с таблицей Клиенты и строковое поле для хранения номера телефона.

У одного человека может быть несколько телефонов, поэтому мы разделили хранение данных в разные таблицы.

Наша задача сейчас увидеть, в чем заключаются ограничительные действия внешнего ключа, давайте разберемся. Мы указали явную связь между двумя полями в разных таблицах. Если попытаться добавить в таблицу телефонов строку со значением в поле "id_Клиенты", не существующим в одноименном поле (имя можно было сделать и другим) таблице с фамилиями, то произойдет ошибка. Это нарушит связь между двумя таблицами, а ограничение внешнего ключа не позволит существовать записям без связи.

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

Таким образом:

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

Требование целостности по ссылкам состоит в следующем: