Реляционные структуры данных

Элементы реляционной модели

Иерархические и сетевые модели

Первые коммерчески доступные системы управления базами данных соответствовали стандарту CODASYL, и многие из них по-прежнему используются в написанных на КОБОЛе приложениях, работающих на мэйнфреймах. Сложность как сетевых, так и иерархических баз данных объясняется тем, что они построены с использованием внутренних физических указателей, связывающих записи между собой. Например, в системе учета счетов-фактур запись о продавце могла бы содержать физический указатель на записи о заказах. Каждая запись заказа, в свою очередь, содержит указатели на записи строк товаров в заказе.

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

 

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

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

 

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

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