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

Электронные таблицы. В течение многих лет преимущественно использовались плоские таблицы (плоские БД) типа списков в табличном процессоре Excel. Телефонный справочник представляет собой так называемую "плоскую"базу данных, в которой вся информация располагается в единственной таблице. Каждая запись в этой таблице содержит идентификатор конкретного человека - имя и фамилию и его номер телефона. Таким образом таблица состоит из записей, информация в которых разделена на несколько частей - полей. В данном случае названиями столбцов являются: фамилия, имя, отчество, номер телефона, примечание (дополнительные сведения о человеке). В Excel 2007 рабочий лист насчитывает 16384 столбцов (полей) и 1048576 строк (записей). При желании в табличном процессоре можно создать список (таблицу) из миллиона человек с номерами телефонов. Поиск нужного человека осуществляется с помощью команды Фильтр. С помощью пользовательского автофильтра можно за доли секунды выделить из миллионного списка нужного человека.

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

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

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

Поле (столбец) содержит значения одного из признаков, характеризующих объекты. Если в качестве объекта рассматривать паспорт человека, то названием поля может быть "Фамилия". Объект в теории реляционной алгебры называется сущностью, а описание конкретного объекта - экземпляром. В теории реляционной алгебры поле называется атрибутом. Число полей в таблице соответствует числу признаков, характеризующих объекты.

Запись - это строка таблицы. Она содержит значения всех признаков, характеризующих один объект (экземпляр). Число записей соответствует числу объектов, данные о которых содержатся в таблице. В теории реляционной алгебра понятию записи соответствует понятие кортеж - последовательность атрибутов, связанных между собой отношением And (И).

Ячейка содержит конкретное значение соответствующего поля (признака одного объекта).

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

· данные хранятся в таблицах, состоящих из столбцов и строк;

· на пересечении каждого столбца и строчки стоит в точности одно значение;

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

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

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

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

Логические связи между таблицами дают возможность объединять данные из разных таблиц. Связь каждой пары таблиц обеспечивается одинаковыми в них полями - ключом связи. В первой (главной, родительской) таблице ключ называется первичным ключом. Ключ во второй (подчиненной, дочерней) таблице ключ называется внешним ключом. Таким образом, внешние ключи используются для организации связей между таблицами базы данных и для поддержания ограничений ссылочной целостности данных.

Таким образом гарантируется рациональное хранение недублированных данных и их объединение в соответствии с требованиями решаемых задач.

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

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

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

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

СУБД позволяют сопоставить родственные записи из обеих таблиц и совместно вывести их в форме, отчете или запросе.

Ключи двух таблиц устанавливают логические связи между ними.

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

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

· один-к-одному, каждой записи из одной таблицы соответствует одна запись в другой таблице;

· один-ко-многим, каждой записи из одной таблицы соответствует несколько записей другой таблице;

· многие-к-одному, множеству записей из одной таблицы соответствует одна запись в другой таблице;

· многие-ко-многим, множеству записей из одной таблицы соответствует несколько записей в другой таблице.

Тип отношения в создаваемой связи зависит от способа определения связываемых полей:

· Отношение один-ко-многим создается в том случае, когда только одно из полей является полем первичного ключа или уникального индекса (пример отношения: в одной группе много студентов).

· Отношение "один-к-одному" создается в том случае, когда оба связываемых поля являются ключевыми или имеют уникальные индексы(пример отношения: у одного студента одна зачетная книжка).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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