База данных. 11

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

Реляционная модель данных была предложена Е. Коддом, известным американским специалистом в области баз данных. Основные концепции этой модели были впервые опубликованы в 1970 г. в статье «A Relational Model of Data for Large Shared Data Banks» (CACM, 1970, Vol. 13, № 6).

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

1.1 Базовые понятия реляционной модели данных

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

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

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

Термин «реляционный» (от английского relation — отношение) указывает прежде всего на то, что такая модель хранения данных построена на взаимоотношении составляющих ее частей, которые удобно представлять в виде двумерной таблицы. Кодд показал, что набор отношений (таблиц) может быть использован для хранения данных об объектах реального мира и моделирования связей между ними. Таким образом,

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

• тип данных;
• домен;
• атрибут;
• кортеж;
• ключ.

Рассмотрим смысл этих понятий на примере отношения (таблицы) СТУДЕНТЫ, содержащего информацию о студентах некоторого вуза (таблица 13.1).

Таблица 13.1. Пример отношения СТУДЕНТЫ реляционной базы данных

Тип данных

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

• целочисленные;
• вещественные;
• строковые;                                                                                                     
• специализированные типы данных для денежных величин;                          
• специальные типы данных для временных величин (дата и/или время);       
• типы двоичных объектов (данный тип не имеет аналога в языках программирования; обычно для его обозначения используется аббревиатура BLOB — Binary Large Object).                                                                                            

Достаточно активно  развивается подход к расширению возможностей реляционные систем абстрактными типами данных (соответствующими возможностями обладают, например, системы семейства Ingres/Postgres).                                                           

В рассматриваемом примере используются три типа данных:

1. строковый (столбцы «Имя» и «Специальность»),
2. временной тип (столбец «Дата_рождения»),
3. целочисленный тип («Курс» и «№_студенческого_билета»).                                 

Домен                                                                                         

Наименьшая единица  данных реляционной модели — это  отдельное атомарное (неразложимое) для данной модели значение данных.

 В нашем примере  (таблица 13.1) можно для каждого  столбца таблицы определить домен  (рисунок 13.1):           

Рисунок 13.1 Пояснение  понятий реляционных БД

• домены «Имена» и «Специальности» для столбцов «Имя» и «Специальность» соответственно будут базироваться на строковом типе данных — в число их значений могут входить только те строки, которые могут изображать имя и название специальности (в частности, такие строки не должны начинаться с мягкого знака);
• домен «Даты_рождения» для столбца «Дата_рождения» определяется на базовом временном типе данных — данный домен содержит только допустимый диапазон дат рождения студентов;
• домены «Номера_курсов» и «Номера_студенческих_билетов» базируются на целочисленном типе — в число его значений могут входить только те целые числа, которые могут обозначать номер курса университета (обычно от 1 до 6) и номер студенческого билета (обязательно положительное число).

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

Следует отметить также  семантическую нагрузку понятия  домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. Если же значения двух атрибутов берутся из различных доменов, то их сравнение, вероятно, лишено смысла. В нашем примере значения доменов «Номера_курсов» и «Номера_студенческих_билетов» основаны на одном типе данных — целочисленном, но не являются сравнимыми.

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

Атрибуты, схема отношения, схема базы данных

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

Пример. Схема нашего отношения СТУДЕНТ запишется так:

Отношение степени один называют унарным, степени два — бинарным, степени три — тернарным,..., а степени п — n-арным.

Степень отношения СТУДЕНТЫ равна  пяти, то есть оно является 5-арным.

Кортеж

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

Понятие схемы отношения  напоминает понятие структурного типа данных в языках программирования (структура в C/C++, запись в Pascal). Однако в реляционных базах данных имя схемы отношения всегда совпадает с именем соответствующего отношения-экземпляра. В классических реляционных базах данных после определения схемы базы данных изменяются только отношения-экземпляры. В них могут появляться новые и удаляться или модифицироваться существующие кортежи. Однако во многих реализациях допускается и изменение схемы базы данных: определение новых и изменение существующих схем отношения. Это принято называть эволюцией схемы базы данных.

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

Мощность отношения  СТУДЕНТЫ равна 6. В отличие от степени  отношения кардинальное число отношения изменяется во времени.                                              

Пустые значения

В некоторых случаях  какой-либо атрибут отношения может  быть неприменим. Например, в рассматриваемом  в качестве примера отношении  СТУДЕНТЫ может же храниться информация о потенциальных абитуриентах, посещающих подготовительные курсы вуза. В этом случае неприменимыми оказываются атрибуты "№_студенческого_билета» и «Курс» (так как абитуриенты еще не поступили в вуз и, следовательно, не имеют студенческого билета и не могут быть отнесены к какому-либо курсу). Кроме того, иногда при вводе информации в строку реляционной таблицы некоторые данные могут быть неизвестны и выяснятся позже (для нашего примера — при поступлении на подготовительные курсы абитуриент еще не определился окончательно, на какую специальность он будет поступать).

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

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

Для обозначения пустых значений полей используется слово NULL.

1.2 Ключи отношения

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

Более строго определить понятие первичного ключа можно  следующим образом:

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

В зависимости от количества атрибутов, входящих в ключ, различают  простые и сложные (или составные) ключи.

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

Сложный или составной ключ — ключ, состоящий из нескольких атрибутов.

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

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

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

Естественный ключ — ключ, в который включены значимые атрибуты и который, таким образом, содержит информацию.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3 Индексы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                СТУДЕНТЫ

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

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

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

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

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

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