Лекция 2.

Основные понятия и определения проектирования БД.

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

Выше было сказано, что основой банка данных является база данных. Естественно, если предметная область достаточно сложна, то и ее модель должна быть определенным образом структурирована. Единицей структуры БД, ее «кирпичиком» является таблица. Таблицы СУБД имеют очень мало общего с рабочими листами табличных процессоров. По своей структуре они ближе к файлу записей (file of record в Pascal), хотя имеется ряд весьма существенных отличий.

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

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

• Не допускается применение вычисляемых полей (только на уровне хранения таблицы, для приложений это обычный прием).

• Можно считать, что количество строк (записей) таблицы ограничено только объемом жесткого диска, что намного превосходит возможности табличных процессоров.

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

В теории проектирования баз данных синонимом понятия «таблица», принятого у разработчиков программного обеспечения является термин «отношение». Приведем строгое определение этого понятия [2].

Пусть даны N множеств D₁ , D₂ , … D_N . Тогда R есть отношение над этими множествами, если R есть множество упорядоченных кортежей вида <d₁, d₂,…d_N>, где d₁ – элемент из D₁ , d₂ – элемент из D₂ , и т.д., d_N – элемент из D_N . D₁ , D₂ , … D_N называют доменами отношения R.

990001	Иванов	4301	Тула
990002	Петров	4301	Тула
990005	Сидоров	4302	Венев
990010	Кузнецов	4401	Москва

Рис. 5 Структура отношения.

Рис. 5 показывает, что у термина «отношение» очень много общего с рассмотренным ранее термином «таблица». Действительно, можно говорить, что отношение является как бы логическим представлением понятия «таблица». Или, наоборот – ­таблица есть физическая (на уровне хранения) реализация отношения.

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

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

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