Данные в базах данных организуются в соответствии с одной из моделей данных. Наибольшее распространение получила реляционная модель. Кроме нее, существуют несколько моделей, называемых в целом дореляционными (например, иерархическая и сетевая модели), а также постреляционная модель, которая будет рассмотрена в следующем разделе.
Основными элементами любой из этих моделей являются объекты и взаимосвязи между ними. Отличительным признаком указанных моделей является различие в способах представления взаимосвязей между объектами базы или сущностями.
В реляционной модели данные представляются в виде двумерных таблиц, связанных между собой определенными отношениями. Все операции над базой данных сводятся к манипуляциям с этими таблицами.
В настоящее время реляционные базы данных используются практически повсеместно. Во многом это связано с простотой и наглядностью реляционной базы данных - представление данных в виде таблиц вполне соответствует традиционным «некомпьютерным» технологиям обработки информации, оно достаточно понятно большинству пользователей. Таблицы реляционной базы данных можно просмотреть на экране компьютера или распечатать; в то же время содержимое, например, сетевой базы при достаточно сложной структуре связей сложно представить наглядно. Отметим также, что реляционная модель данных наилучшим образом соответствует структуре экономической информации.
|
|
Таблица реляционной БД состоит из некоторого числа однотипных записей, или кортежей. Слово «однотипных» означает, что все записи обладают одним и тем же набором атрибутов, или полей, хотя для каждой записи атрибут может принимать свое собственное значение.
Рассмотрим таблицу, содержащую данные о сотрудниках предприятия.
Табельный № | Фамилия И.О. | Код отдела | Рабочий телефон |
ПЕТРОВ А.В. | 555-12-67 | ||
РОМАНЕНКО С.Т. | 555-12-80 | ||
СТЕПАНОВА И.С. |
Можно увидеть, что у всех трех записей атрибуты одинаковы, однако принимают разные значения. Так, для записи №1 атрибут "табельный №" принимает значение "008976", а для записи №2 - "008980" и т.д.
Значения некоторых атрибутов у разных записей может совпадать, например, у записей №1 и №2 одинаковое значение атрибута "код отдела". Однако в каждой таблице должен иметься атрибут (или совокупность атрибутов), значение которых никогда не повторяется и однозначно идентифицирует каждую ее строку. Это нужно для того, чтобы при работе с базой можно было недвусмысленным образом отличать одну запись от другой. Такие атрибуты называют уникальными. Уникальный атрибут таблицы или совокупность ее уникальных атрибутов называют первичным ключом или ключевым полем. В данной таблице ключом является атрибут "табельный №".
|
|
В том случае, когда запись однозначно определяется значениями нескольких полей (или совокупностью уникальных атрибутов) то имеет место составной ключ.
В ряде случаев атрибут может не получать никакого значения, например, у сотрудника №3 нет рабочего телефона, и соответствующий атрибут не заполнен. В этом случае говорят, что атрибут имеет нулевое значение. Ключ не может иметь нулевое значение.
Но простая совокупность таблиц не может считаться базой данных, если между ними не существует определенных отношений. В реляционных базах данных отношения указывают на соответствие между записями двух таблиц. Возьмем вторую таблицу, содержащую информацию об отделах:
Код | Наименование отдела |
ДИРЕКЦИЯ | |
БУХГАЛТЕРИЯ | |
ОТДЕЛ КАДРОВ | |
КАНЦЕЛЯРИЯ |
Между двумя приведенными таблицами можно установить отношение "СОТРУДНИК - работает в - ОТДЕЛЕ". Если требуется узнать информацию об отделе, в котором работает сотрудник, нужно взять значение атрибута "код отдела" в таблице "СОТРУДНИКИ" и найти соответствующий код в таблице "ОТДЕЛЫ". Таким образом, две записи из разных таблиц как бы объединятся в одну:
Табельный № | Фамилия И.О. | Код отдела | Рабочий телефон |
РОМАНЕНКО С.Т. | 555-12-80 |
+
Код | Наименование отдела |
ОТДЕЛ КАДРОВ |
=
Табельный № | Фамилия И.О. | Код отдела | Рабочий телефон | Наименование отдела |
РОМАНЕНКО С.Т. | 555-12-80 | ОТДЕЛ КАДРОВ |
Можно увидеть, что отношения между двумя таблицами устанавливаются на основе соответствия значений атрибутов двух таблиц, в нашем случае это атрибут "код отдела" таблицы "СОТРУДНИКИ" и атрибут "код" таблицы "ОТДЕЛЫ". Такие атрибуты называют атрибутами связи. Атрибут связи в одной таблице должен быть ключом. В приведенном примере атрибут "код" является ключом для таблицы "ОТДЕЛЫ". Если бы это было не так, и коды отделов в этой таблице повторялись, невозможно было бы определить, о каком из отделов говорится в первой таблице. Второй атрибут связи - в данном случае атрибут "код отдела" таблицы "СОТРУДНИКИ" – называют внешним ключом, так как он ссылается на ключ другой ("внешней") таблицы.
Для поддержания целостности данных необходимо, чтобы внешний ключ всегда ссылался на существующий ключ. Например, если в таблице "СОТРУДНИКИ" указать код отдела со значением 028, а в таблице "ОТДЕЛЫ" отдела с таким кодом не будет, то целостность данных нарушится - сотрудник будет показан работником несуществующего отдела. Поэтому сама база данных или работающее с ней приложение должно запрещать ввод значений внешнего ключа, ссылающегося на несуществующий ключ.
Подобное нарушение целостности может возникнуть и в том случае, когда удаляется одна из записей таблицы, содержащей ключевое поле. Например, при удалении из таблицы "ОТДЕЛЫ" записи №3, содержащей ключ 024, записи №1 и №2 таблицы "СОТРУДНИКИ" будут ссылаться на несуществующий отдел.
Целостность данных в этом случае поддерживается одним из нескольких способов:
· Запрещается удаление записей, на которые существуют ссылки. В приведенном примере это означает, что нельзя удалить запись об отделе с кодом 024, пока хотя бы один из сотрудников указан работником этого отдела.
· Если запись удаляется, то все внешние ключи ссылающихся на нее записей принимают нулевое значение. В нашем случае атрибут "код отдела" для первых двух сотрудников примет нулевое значение.
· Ссылающиеся записи "каскадно" уничтожаются. При удалении записи об отделе 024 в таблице "ОТДЕЛЫ" все записи о сотрудниках этого отдела в таблице "СОТРУДНИКИ" также будут удалены.
|
|
Современные СУБД поддерживают несколько способов поддержания целостности. Выбор одного из них зависит от особенностей предметной области.
Итак, реляционная база данных - это такая база данных, которая воспринимается ее пользователем как совокупность таблиц.