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

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

Пример - имеем БД из трех таблиц с информацией о студентах, результатах сессии и таблицы для начисления стипендии (предполагается, что величина стипендии определяется набранными в сессию баллами).

СТУДЕНТ(номер зачетной книжки, фамилия, имя, отчество, дата рождения, группа)

СЕССИЯ(номер зачетной книжки, оценка1, оценка2, оценка3, оценка4, результат)

СТИПЕНДИЯ(результат, процент)

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

Таблицы СТУДЕНТ и СЕССИЯ имеют совпадающие ключи - номер зачетной книжки, что дает возможность организовать связь между ними. Таблица СЕССИЯ имеет первичный ключ - номер зачетной книжки и внешний ключ - результат, который и обеспечивает ее связь с таблицей СТИПЕНДИЯ.

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

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

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

При разработке информационно-логической модели предметной области (инфологическое проектирование) - определяется состав и структура данных: предметная область отображается в виде информационных объектов ИнО и их структурных связей. ИнО - информационное описание реального объекта, явления, процесса. Н-р, ИнО СТУДЕНТ, ключ - номер зачетной книжки, описательные реквизиты - фамилия, имя, отчество, дата рождения, группа, ИнО СТИПЕНДИЯ содержит ключ - результат и описательный реквизит - процент. Описательные реквизиты связаны логически с общим для них ключом, эта связь функциональная, в экземпляре ИнО (записи) определенному значению ключевого реквизита соответствует только одно значение описательного реквизита.

Для двух ИнО возможны 3 вида отношений (связей). Связь 1:1 (один к одному) предполагает, что одному экземпляру ИнО А соответствует не более одного экземпляра ИнО В и наоборот. Например, каждый студент имеет определенный набор оценок за сессию, обозначение

А1 ß—> В1

А2 ß—> В2

... или А ß—-> В или СТУДЕНТ ß—> СЕССИЯ. При связи один ко многим (1:М) одному экземпляру объекта А соответствует 0, 1 и более экземпляров объекта В, например, установленный по результатам сессии размер стипендии может быть одинаковым у разных студентов, обозначение А ß—>> B или СТИПЕНДИЯ ß—>> СЕССИЯ. Связь многие ко многим (М:М) предполагает, что одному экземпляру объекта А соответствует 0, 1 или более экземпляров объекта В и наоборот. Например, если ввести еще один ИнО ПРЕПОДАВАТЕЛЬ, то один студент обучается у многих преподавателей, один преподаватель обучает многих студентов - отношение М:М, обозначение А <ß—>> B или СТУДЕНТ <ß—> ПРЕПОДАВАТЕЛЬ. Иногда используется и четвертый вид связи (отношения) М:1

Графическое представление инфологической модели имеет вид

ПРЕПОДАВАТЕЛЬ<ß>>СТУДЕНТß>СЕССИЯ<ß>СТИПЕНДИЯ

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

n обеспечить быстрый доступ к данным в таблице

n исключить ненужное повторение данных

n обеспечить целостность данных таким образом, чтобы при изменении одних объектов автоматически происходило соответствующее изменение связанных с ним объектов.

Процесс уменьшения избыточности информации в БД называется нормализацией.

Рассмотрим базу данных, состоящую из таблиц ПОКУПАТЕЛЬ (код покупателя, фамилия, имя, отчество, адрес, телефон, предприятие, руководитель) и ПРОДАЖИ (Код покупателя, код товара, наименование, цена, дата заказа, дата продажи). Ее можно представить в виде одной таблицы, но она будет содержать избыточную информацию - сведения о каждом покупателе повторяются для каждого сделанного им заказа.

При этом может возникнуть ряд проблем

n значительное время тратится на ввод повторяющихся данных

n при изменении адреса покупателя необходимо корректировать все записи, содержащие сведения о его заказах

n таблица имеет большой размер, что снижает время ее обработки

n при многократном вводе повторяющихся данных возрастает вероятность ошибки

Первая нормальная форма должна удовлетворять следующим условиям

n таблица не должна иметь повторяющихся записей

n таблица не должна иметь повторяющихся групп полей

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

Таблица находится во второй нормальной форме, если она находится в первой и любое неключевое поле однозначно идентифицируется полным набором ключевых полей. Понятие второй формы применимо только к таблицам с составным ключом. Такой является таблица ПРОДАЖИ, но поля наименование и цена однозначно описываются только одним из ключевых полей (код товара). Чтобы привести эту таблицу ко второй форме выделим из нее таблицу ТОВАРЫ(код товара, наименование, цена).. Связывание второй и третьей таблиц - по полю код товара. Таблицы, не имеющие ключевых полей или имеющие одно ключевое поле, автоматически считаются удовлетворяющими второму условию второй нормальной формы.

Таблица находится в третьей нормальной форме, если она удовлетворяет условиям второй и ни одно из неключевых полей таблицы не идентифицируется с помощью другого неключевого поля. Это предполагает разделение таблицы с целью помещения в отдельную таблицу столбцов, которые не зависят от полного ключа. В таблице ПОКУПАТЕЛИ поле руководитель однозначно определяется полем предприятие - оба эти поля неключевые, поэтому таблица ПОКУПАТЕЛИ не находится в третьей нормальной форме. Для приведения этой таблицы к третьей нормальной форме создадим новую таблицу РУКОВОДИТЕЛИ (предприятие, руководитель), связь с первой таблицей - по полю предприятие.

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