Тема 3.2 Базовые понятия реляционных баз данных. Проектирование реляционных баз данных с использованием нормализации

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

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

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

На рис. 1.4 приведен пример таблицы catalog базы данных электронного магазина компьютерных комплектующих, которые распределены по разделам. Каждая строка этой таблицы представляет собой один вид товарных позиций, для описания которых используется поле id_catalog - уникальный номер раздела, name название раздела и description discription- его описание.

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

Определение__________________________________

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

Объектно-ориентированные и гибридные базы данных

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

Особенности реляционных баз данных

Можно кратко сформулировать особенности реляционной базы данных.

-Данные хранятся в таблицах, состоящих из столбцов и строк.

-На пересечении каждого столбца и строки находится только одно значение.

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

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

-Запросы к базе данных возвращают результат в виде таблиц, которые тоже могут выступать как объект запросов.

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

Примечание__________________________________

Правила Кодда и их разъяснение приведены в конце данной главы. Они не являются догматическими — реляционные базы данных постоянно развиваются и совершенствуются, на рынке появляются новые продукты, которые поддерживают не все требования к реляционным базам данных. Например, MySQL долго не соответствовала многим стандартам SQL. Исторически сложилось так, что последним стандартам SQL не соответствует ни одна из баз данных.

Первичные ключи

Строки в реляционной базе данных неупорядочены. То есть в таблице нет "первой", "последней", "тридцать шестой" и "сорок третьей" строки, а есть просто неупорядоченный набор строк. Возникает вопрос: "Каким же образом выбирать в таблице конкретную строку?" Для этого в правильно спроектированной базе данных для каждой таблицы создается один или несколько столбцов, значения которых во всех строках различны. Такой столбец называется первичным ключом таблицы. Первичный ключ обычно сокращенно обозначают как РК (primary key). Никакие из двух записей таблицы не могут иметь одинаковых значений первичного ключа— т. е., благодаря наличию первичных ключей, каждая строка таблицы обладает своим уникальным идентификатором.

Примечание______________________________________

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

По способу задания первичных ключей различают логические (естественные) ключи и суррогатные (искусственные).

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

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

Совет___________________________________________

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

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

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

Первичным ключом таблицы themes является id_theme, а таблицы posts — id_post. Обратите внимание, что поле id_theme присутствует и в таблице posts. Каждое значение этого поля в таблице posts является внешним ключом (в данном случае это внешний ключ для первичного ключа таблицы themes). Внешний ключ сокращенно обозначают как FK (foreign key).

Примечание______________________________________

Внешний ключ также часто называют вторичным ключом.

Как видно из рис. 1.5, внешний ключ ссылается на первичный ключ таблицы themes, устанавливая однозначную логическую связь между записями таблиц themes и posts. Иначе говоря, если внешний ключ для записи (сообщения) с РК=1 в таблице posts имеет значение внешнего ключа равное 1, то это значит, что данное сообщение относится к теме с РК=1 таблицы themes.

Нормализация базы данных

Определение_____________________________________

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

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

Теперь каждый тип профессии обозначен уникальным числом, и строка в базе данных присутствует только в единственном экземпляре: в таблице профессий. Размер поля "профессия" уменьшился, т. к. строка занимает больше памяти, чем число.

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

Замечание_______________________________________

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

Правила Кодда

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

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

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

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

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

• определение данных;

• обработку данных;

• определение представлений;

• идентификацию прав доступа;

• условия целостности данных;

• границы транзакций.

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

Примечание__________________________ < ______

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

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

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

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

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

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

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

Примечание______________________________________

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