Модель данных в реляционных СУБД

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

Теория реляционных СУБД была разработана Коддом из IBM в 60-х годах ХХ века и базируется на математической теории отношений. Важнейшие понятия этой теории – таблица, строка, столбец, отношение, первичный и вторичный ключ.

Реляционная СУБД представляет собой совокупность именованных двумер­ных таблиц данных, логически связанных (находящихся в отношении) между собой. Таблицы состоят из строк и именованных столбцов, строки представляют собой экземпляры информационного объекта, столбцы – атрибуты объекта. В рассмотренном ранее примере таблица (назовем ее “Склад”) состоит из информационных объектов-строк, отдельная строка содержит сведения об отдельном товаре. Каждый товар характеризуется некими параметрами-атри­бутами (“Наименование”, “Цена” и т.д.). Строки иногда называют записями, а столб­цы – полями записи.

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

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

Пример логически взаимосвязанных таблиц:

Сотрудники
Табельный №	Фамилия	Должность	№ отдела
	Иванов	Начальник
	Петров	Инженер
	Сидоров	Менеджер

Отделы
№ отдела	Наименование
	Производственный отдел
	Отдел продаж

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

• Первичный ключ (или главный ключ, primary key, PK). Представляет собой столбец или совокупность столбцов, значения которых однозначно идентифицируют строки. В данном примере первичным ключом в таблице “Сотрудники” является столбец “Табельный №”, ибо в одной организации не бывает сотрудников с одинаковыми табельными номерами. Очевидно, что в таблице “Отделы” первичным ключом является столбец, содержащий номер отдела;
• Вторичный (или внешний ключ, foreign key, FK). Столбец или совокупность столбцов, которые в данной таблице не являются первич­ными ключами, но являются первичными ключами в другой таблице. В рассматриваемом примере столбец “№ отдела” таблицы “Сотрудники” содержит вторичный ключ, с помощью которого может быть установлена логическая взаимосвязь строк таблицы с соответствующими строками таблицы “Отделы”.

Если какая-либо таблица содержит вторичный ключ, то она считается логически взаимосвязанной с таблицей, содержащей соответствующий первичный ключ. В общем случае эта связь имеет характер “один ко многим” (одному значению первичного ключа может соответствовать несколько значений вторичного, пример – отдел № 15). Возможны варианты, когда вторичный ключ входит в состав первичного ключа. Всё зависит от предметной области, которую описывает модель. В общем случае СУБД ничего “не знает” о логической взаимосвязи таблиц модели. При обращении к СУБД с запросом пользователь должен в явном виде указать условия связывания двух таблиц. В нашем примере условие будет выглядеть примерно так: “Сотрудники”.”№ отдела” = “Отделы”.”№ отдела”. Следовательно, в процессе написания запроса возможно связать две таблицы по любым произвольным полям (не только по первичным и вторичным ключам), которые
в принципе могут быть сравнимы друг с другом. В этом случае связь носит характер “многие ко многим”. Иногда это бывает необходимо делать при написании сложных и специфических запросов, но в общем случае не рекомендуется и свидетельствует об ошибках при проектировании логической модели БД.

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