База данных

В рассматриваемом нами примере в качестве первичного ключа отношения СТУДЕНТЫ можно рассматривать атрибут №_студенческого_билета. Причем данный ключ будет естественным, так как он несет вполне определенную информацию.

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

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

Недостатки естественных ключей:

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

 

В некоторых реляционных  СУБД допускается изменение первичного ключа. Иногда это бывает действительно полезно. Однако прибегать к этому следует лишь в случае крайней необходимости.

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

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

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

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

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

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

• UNIQUE — ограничение уникальности, значения вторичных ключей при данном ограничении не могут дублироваться;
• NOT NULL — при данном ограничении ни один из атрибутов, входящих в со став вторичного ключа, не может принимать значение NULL.

Перекрывающиеся ключи — сложные ключи, которые имеют один или несколько общих столбцов.

 

1.3 Индексы

 

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

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

Индекс предоставляет  информацию о точном физическом расположении данных в таблице.

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

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

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

Рассмотрим пример индекса. На рисунке 13.2 показан фрагмент таблицы  СТУДЕНТЫ и индекса, построенного по полю «Имя» данной таблицы. При выполнении поиска по имени студента, просматривая индекс, можно сразу определить порядковый номер записи, содержащей необходимую информацию, и затем быстро найти в таблице сами данные. Если бы у таблицы отсутствовал индекс по полю «Имя», то выполнение поиска по имени студента потребовало бы просмотра всей таблицы. Таким образом, использование индексов снижает время выборки данных.

 

Рисунок 13.2 - Поиск информации в таблице с помощью индекса

Различают несколько  типов индексов. Наиболее часто выделяют три типа: 

• простые; 
• составные; 
• уникальные.

Ускорение поиска информации при использовании индекса может  показаться неочевидным — ведь количество записей в индексе совпадает с количеством записей в таблице. Однако следует учитывать два обстоятельства:

• обращение к индексу выполняется быстрее, чем к таблице;                                     
• в индексе записи хранятся в упорядоченном виде (в рассматриваемом примере — в алфавитном порядке) и поэтому при поиске информации в индексе нет необходимости просматривать все данные до конца индекса.

Простые индексы представляют собой простейший и вместе с тем наиболее распространенный тип индекса. Простой индекс строится на основе только одного столбца реляционной таблицы (индекс, приведенный на рисунке 13.2, является простым).

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

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

Можно назвать два  условия оптимальности следования столбцов в составном индексе:

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

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

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

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

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

 

1.4 Отношения: свойства, виды, связи, внешние ключи

 

Свойства и виды отношений

Отношения имеют ряд  основных свойств, а именно:

• в самом общем случае в отношении не бывает двух одинаковых кортежей. Это следует из самого определения отношения, однако для некоторых СУБД в ряде случаев допускается отступление от этого свойства. Действительно, поскольку в отношения имеет место первичный ключ, то одинаковые кортежи исключены;
• кортежи не упорядочены сверху вниз - в отношении просто отсутствует понятие позиционного номера. В отношении без потери информации можно с успехом расположить кортежи в любом порядке;

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

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

 

В реляционных системах поддерживаются несколько видов отношений:

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

 

 

 

Связанные отношения

 

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

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

Для рассмотрения связанных  отношений воспользуемся рассмотренным  ранее примером — отношением СТУДЕНТЫ. Данное отношение может быть связано с отношением УСПЕВАЕМОСТЬ, в котором содержатся сведения об успеваемости студентов по разным предметам. Фрагмент такого отношения может иметь вид, приведенный в таблице 13.2.

Таблица 13.2 - Фрагмент отношения УСПЕВАЕМОСТЬ, связанного с отношением

                                СТУДЕНТЫ

№_студенческого_билета	Предмет	Оценка
…	…	…
23980282	Высшая математика	4
23980282	Философия	5
22991380	Высшая математика	3
22991380	Философия	NULL
22657879	Общая физика	5
24356783	Общая физика	NULL
…	…	…

Атрибут «№_студенческого_билета»  таблицы УСПЕВАЕМОСТЬ содержит идентификатор студента (в данном примере в качестве такого идентификатора используется номер студенческого билета). Если нужно узнать имя студента, соответствующее строкам в таблице УСПЕВАЕМОСТЬ, то следует поискать это же значение идентификатора студента в поле «№_студенческого_билета» таблицы СТУДЕНТЫ и в найденной строке прочесть значение поля «Имя». Таким образом, связь между таблицами СТУДЕНТЫ и УСПЕВАЕМОСТЬ устанавливается по атрибуту «№_студенческого_билета».

При рассмотрении связанных  таблиц важное значение имеет понятие внешнего ключа. Рассмотрим его более подробно.

 

Внешние ключи отношения

В базах данных одни и  те же имена атрибутов часто используются в разных отношениях. В рассматриваемом примере атрибут «№_студенческого_билета» присутствует как в отношении СТУДЕНТЫ, так и в отношении УСПЕВАЕМОСТЬ. В этом примере атрибут «№_студенческого_билета» иллюстрирует понятие внешнего ключа (foreign key).

Внешний ключ — это атрибут (или множество атрибутов) одного отношения, являющийся ключом другого (или того же самого) отношения.

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