Сетевые СУБД

появились позже всех. Они появились в ответ на требование расширить иерархическую модель. Смысл расширения: убрать ограничение, что у каждого потомка только один предок. Рассмотрим задачу «Поставщики – потребители».

Поставщики	потребители
S1	D1
S2	D2
S3	D3
	D4

Сетевые СУБД общего вида не рассматривают. Существует модель CODASYL. Сетевая БД должна содержать два набора: записей и связей между этими записями. Тип записей – информационная часть; тип связей определяется для двух типов записей: запись-предок и запись-потомок. Экземпляр типа связей содержит один экземпляр типа записей предка и упорядоченный набор экземпляров типа потомка.

, где L – связь, P – предок, C – потомок.

Для типа связей каждый экземпляр P является предком только в одном экземпляре L, и каждый экземпляр C является потомком не более, чем в одном экземпляре L.

L – поставки i – ого поставщика j – ому потребителю.

	L11
S1	L12	D1
	L21
S2	L23	D2
	L24
	L31	D3
S3	L32
	L33	D4
	L34

В модели «Сотрудники»:

Манипулирование данными:

Примерный набор операций:

– найти запись в наборе однотипных;

– перейти от предка к потомку по некоторой связи;

– перейти от потомка к предку по некоторой связи;

– создать запись;

– уничтожить запись;

– модифицировать запись;

– включить в связь;

– исключить из связи;

– переставить в другую запись.

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

Преимущество реляционных моделей перед тремя выше перечисленными: эти модели могут быть строго формализованы, т.е. описаны математическим языком. Есть реляционные операции, которые могут быть либо корректными, либо некорректными. Т.е. реляционные модели поддерживают только правильные операции. 80-е и 90-е годы – “триумф” реляционных моделей. И сейчас они в моде.