Структура данных реляционной модели.
Понятие реляционный (от англ. relation – отношение) связанно с разработками известного американского специалиста в области систем баз данных Е. Кодда.
Эта модель характеризуются простотой структуры данных, удобным для пользователя табличным представлением.
Реляционная модель построена на основе двумерного массива, т.е. таблицы или связанных между собой двумерных таблиц. Каждая таблица содержит однородную информацию об объектах, процессах или явлениях некоторой предметной области. Так, например, в таблице Группа, представлена информация о музыкальных группах. Свойствами же характеризующими объект Группа, являются: Код группы, Название, Дата создания, Страна. Эти характеристики называют атрибутами объекта.
Атрибут– некий показатель, характеризующий объект.
Каждая строка таблицы есть совокупность значений атрибутов, относящихся к конкретному объекту. В терминах реляционных баз данных строку называют записью (кортеж), а столбец полем
| Код группы | Название | Дата создания | Страна |
| The Beatles | Англия | ||
| Queen | Англия | ||
| U2 |
Не каждая таблица является реляционной, реляционные таблицы обладают определенными свойствами.
Свойства реляционной таблицы:
1. каждый элемент таблицы – это один элемент данных
2. все столбцы однородные
3. каждое поле таблицы имеет уникальное имя
4. отсутствуют одинаковые записи
5. порядок строк и столбцов может быть произвольным
Первое свойство требует, чтобы на пересечении строки и столбца находилось атомарное (неделимое, не имеющее внутренней структуры) значение.
Пример В поле Альбом таблицы нарушено свойство атомарности значения атрибута.
| Код группы | Название | Дата создания | Альбом | Страна |
| The Beatles | Help!, Love Songs | Англия | ||
| Queen | The Game, Jazz | Англия |
Второе свойство требует, чтобы все значения определенного поля были одного типа данных (число, дата, текст …).
Четвертое свойство говорит о том, что в таблице не должно быть одинаковых строк данных. Следствием этого является положение, что в любой таблице должно быть поле или набор полей, значения данных, в которых отличаются для каждой записи этой таблицы.
Потенциальный ключ – это поле или набор полей, которые однозначно определяют соответствующую запись.
Если потенциальный ключ состоит из одного поля его называют простым ключом, а если же в состав потенциального ключа входят несколько полей, он называется составным ключом.
Пример В таблице представлена информация о студентах, проживающих в городе Красноярске. Потенциальными ключами здесь являются: № личного дела, № зачетки и Фамилия + Имя + Отчество + Дата рождения + Улица + Дом + Квартира
Студент
| № личного дела | Фамилия | Имя | Отчество | № зачетки | Дата рождения | Улица | Дом | Квартира |
| Петров | Иван | Иванович | 13.07.81 | Мира | 12а | |||
| Бойко | Петр | Андреевич | 01.01.81 | Щорса | ||||
| Ким | Ольга | Петровна | 12.01.81 | Лазо | ||||
| Петров | Петр | Иванович | 12.01.82 | Мира | 12а |
Если потенциальных ключей несколько, то один из них выбирается за основной (первичный ключ). По первичному ключу выполняется автоматическое упорядочивание записи, что ускоряет поиск информации. Первичные ключи в СУБД обеспечивают основной механизм адресации на уровне записи.
Чаще всего структура БД представлена в виде нескольких таблиц, связанных между собой через общие атрибуты. Необходимость использования в БД нескольких таблиц можно продемонстрировать на примере
Пример В данном примере представлена информация о музыкальных группах и их альбомах объединенная в одну таблицу.
| Название группы | Страна | Дата создания | Название альбома | Год издания | Фирма |
| The Beatles | Англия | With The Beatles | Parlophone | ||
| The Beatles | Англия | Pleas, pleas me | Parlophone | ||
| The Beatles | Англия | Rubber Soul | Parlophone |
Из примера видно, что при внесении в нее данных об альбомах определенной группы, каждый раз приходиться дублировать информацию первых трех полей таблицы. Многократное введение в БД одних и тех же данных (Название группы, Страна, Дата создания) приводит к неэффективному использованию памяти и к тому же возрастает вероятность появления ошибок при вводе данных.
Если разбить данные по нескольким таблицам, то можно в значительной степени избежать этих трудностей. Так нашу таблицу можно разбить на две: Альбомы и Группы (ключевые поля представленных ниже таблиц выделены двойной линией).
Группы
| Номер группы | Название группы | Страна | Дата создания |
| The Beatles | Англия | ||
| Led Zeppelin | Англия | ||
| U2 | Ирландия |
Альбомы
| Номер альбома | Название альбома | Год издания | Фирма |
| With The Beatles | Parlophone | ||
| Pleas, pleas me | Parlophone | ||
| Rubber Soul | Parlophone |
Для обеспечения связи между таблицами используются внешние ключи. Значения внешнего ключа формируются на основе значений соответствующего ему первичного ключа. На рисунке 1 в поле Код Группы является внешним ключом для первичного ключа Код Группы таблицы Группа
Типы связей между таблицами
Связи между таблицами очень важны, поскольку они указывают, как находить, размещать и использовать информацию из полей двух или более таблиц. Кроме того, связи отражают правила отношения между объектами, представленными в различных таблицах.
Существует три типа связей: один-к-одному, один-ко-многим, многие-ко-многим.
Связь один-ко-многим (1 – М):
Группы 1 - М Альбомы
Этот тип связи соответствует отношению между таблицами Группа и Альбом. У каждой группы может быть несколько альбомов, но любой альбом может быть выпущен одной определенной группой. Таблица со стороны отношения 1 называется главной, таблица же со стороны многие – подчиненной.
Группы
| Номер группы | Название группы | Страна | Дата создания |
| The Beatles | Англия | ||
| Led Zeppelin | Англия | ||
| U2 | Ирландия |
Альбомы
| Номер альбома | Номер группы | Название альбома | Год издания | Фирма |
| With The Beatles | Parlophone | |||
| Pleas, pleas me | Parlophone | |||
| Rubber Soul | Parlophone |
Эти таблицы связаны между собой через общие атрибуты (номер группы).
Экономичность размещения данных в виде связанных таблиц (а не в виде одной) становится более ощутимой при увеличении числа записей в таблицах.
Связь многие-ко-многим (М –М):
группа М – М музыкант
Например, в группе может играть несколько музыкантов, а любой музыкант может играть в нескольких музыкальных группах.
Группы
 Номер группы
| Название группы | Страна | Дата создания |
| The Beatles | Англия | ||
| Led Zeppelin | Англия | ||
| U2 | Ирландия |
Музыканты
| Номер музыканта | Фамилия | Имя |
| АА | А | |
| ББ | Б | |
| СС | С |
Таблица 3 показывает соответствие связи многие-ко-многим.
Связь один-к-одному (1 – 1): Каждой записи одной таблицы может соответствовать только одна запись из другой таблицы. Эта связь редко используется в базах данных. По сути дела она применяется тогда, когда по каким либо причинам необходимо хранить информацию об одном объекте в разных таблицах. При необходимости вся информация из этих таблиц может быть собрана в одну.
Целостность данных
Часть реляционной модели связанна с целостностью данных, подвергалась и подвергается наибольшему изменению. В некоторых ее деталях ведущие специалисты до сих пор не имеют общей точки зрения. В этом разделе будут кратко изложены общие положения, связанные с целостностью данных.
Когда говорят о целостности данных, подразумевается наличие некоторых правил призванных обеспечить непротиворечивость (достоверность) информации хранимой в БД.
Существуют общие правила, которые относятся ко всем реляционным БД и частные правила, относящиеся к конкретно взятой БД. Обеспечение выполнения этих правил берет на себя СУБД.
Частные правила
Как уже отмечалось, для каждой БД может требоваться выполнение своих частных правил.
Пример Список частных правил для БД «студент» мог бы включать следующие правила:
- Год поступления студента в ВУЗ должен находится в интервале от 1995 до текущего года
- Год окончания обучения >= Год поступления +5
- Номера групп должны выбираться из списка 10,11, 20, 21, 30, 31, 40, 50
- № студенческого билета должен быть представлен в виде nnnnnn, где n-это цифра
и т.д.
Общие правила
Общие правила целостности, связаны с понятиями первичных и внешних ключей.
Правило целостности объекта. Ни один элемент первичного ключа не может содержать пустого значения.
В качестве первичного ключа нужно выбирать поля, которые обязательно будут содержать однозначно интерпретируемые значения.
Пример Первичный ключ № банковского счета содержит пустые значения. Такая ситуация недопустима, для реляционных БД. Здесь пустое значение может интерпретироваться по разному: 1) у сотрудника есть № банковского счета, но он, по какой то причине не указан; 2) у сотрудника нет № банковского счета 3) не известно есть ли у сотрудника № банковского счета или нет.
Сотрудники
| № банковского счета | Фамилия | Имя | Должность |
| Проворов | Илья | директор | |
| Калугин | Степан | программист | |
| Гордеева | Анна | бухгалтер | |
| Павленко | Ольга | секретарь | |
| ……….. | ………. | ……… | ……… |
Правило ссылочной целостности. Любое текущее значение внешнего ключа должно совпадать со значением соответствующего ему первичного ключа или являться пустым значением.
Пример Во внешнем ключе № отдела таблицы Сотрудники не должно быть значения номера отдела, которое не представлено в таблице Отделы. Исключения составляют случаи, когда некоторые записи в подчиненной таблице в принципе не могут иметь связанной записи в главной таблице. Например, сотрудник Иваненко не является работником какого либо отдела и поэтому для него значение № отдела остаётся пустым.
Отделы
| № отдела | Название | Бюджет |
| Бухгалтерия | 230000 р. | |
| Технического обслуживания | 221000 р. | |
 4
| Информационный | 332000 р. |
Сотрудники
| Код сотрудника | Фамилия | Имя | Должность | № отдела |
| Калугин | Степан | Программист | ||
| Гордеева | Анна | Бухгалтер | ||
| Павленко | Ольга | Секретарь | ||
| Иваненко | Олег | Консультант | ||
| ……….. | ………. | ……… | ……… | ……… |
В любой СУБД должны быть средства позволяющие задавать как общие, так и частные правила целостности данных. Позже Вы узнаете, как можно реализовывать подобные правила в СУБД Access.