Потрібно помітити, що ми описали спосіб використання механізму зв'язків, який підтримувався в ранніх версіях SEQUEL. У інтерфейсі RSS System R цього періоду допускалася можливість довільного проведення зв'язків без урахування збігу значень полів скріплення. Тим самим, в системі загалом не використовувалися всі можливості RSS, які з лишком перевершували потребі організації ієрархічних бінарних зв'язків по збігу полів скріплення.

Для одного відношення допускалося створення багатьох зв'язків: кортеж відношення міг бути родителем декількох ієрархій і входити в дещо інших ієрархій як нащадок. При цьому один зв'язок міг бути оголошений кластеризованим. Тоді система прагнула вмістити в одну сторінку даних всі кортежі однієї ієрархії. При цьому, природно, використовувалася можливість розміщення в одній сторінці даних кортежів декількох відносин. Основне значення такої кластеризації полягало в можливості оптимізації виконання деяких запитів, що включають (екві)з'єднання двох пов'язаних відносин у відповідності зі значеннями полів скріплення.

У більш пізніх публікаціях по System R згадки про механізм зв'язків зникли, з чого можна укласти, що розробники відмовилися від його використання. Думається, що основними причинами відмови від використання зв'язків були наступні. По-перше, засоби побудови зв'язків, що забезпечуються RSS, були дуже низького рівня, набагато більш низького, ніж засоби підтримки індексів. Якщо при занесенні кортежу RSS забезпечувала автоматичну корекцію всіх індексів, то для корекції зв'язків був потрібен виконати ряд додаткових звертань до RSS, через що час виконання операції занесення кортежу, звичайно, збільшувалося (те ж торкається операцій видалення і модифікації кортежу). По-друге, при реалізації цього механізму, виникають додаткові синхрозаційні проблеми нижнього рівня (рівня спільного доступу до сторінок даних). Зокрема, наявність прямих посилань між сторінками даних збільшує імовірність виникнення синхронізаційних тупиків. Нарешті, по-третє, всі ці додаткові накладні витрати не окупалися що надаються механізмом зв'язків перевагами. Дійсно, максимального ефекту від використання зв'язків можна досягнути тільки при виконанні операції з'єднання двох кластеризованих по цьому зв'язку відносин, якщо поле з'єднання співпадає з полем скріплення, і умови, що накладаються на батьківське відношення, виділяють в ньому рівне один кортеж. Очевидно, що такі запити на практиці рідкі. (Зазначимо, що приведені міркування належать автору і не викладалися в публікаціях по System R, так що насправді причини могли бути і іншими.)

Крім відносин і індексів при роботі System R на зовнішній пам'яті можуть розташовуватися ще і тимчасові об'єкти - списки (lists). Список - це миттєвий знімок деякої вибірки з проекцією кортежів одного відношення, можливо, впорядкований у відповідності зі значеннями деяких полів. Засоби роботи зі списками є в інтерфейсі RSS, але їх, природно, ні в SQL. Відповідно, ці засоби використовуються тільки всередині системи при виконанні запитів (зокрема, один з найбільш ефективних алгоритмів виконання з'єднань заснований на використанні відсортованих списків кортежів). Публікації по System R не дають точного уявлення про структури даних, що використовуються при організації списків, але виходячи із здорового глузду можна передбачити, що вони влаштовані не так, як відносини (наприклад, для кортежу, що входить в список, не потрібна адресація через tid), і що розташовуються вони у тимчасових файлах (у разі збою системи всі тимчасові об'єкти пропадають).

7.4. Інтерфейс RSS

Ми опишемо своє уявлення про інтерфейс RSS, яке не відповідає в точності жодній з публікацій з приведеного списку літератури, а є швидше деякою компіляцією, що узгоджується із завершальними публікаціями.

Як ми вже відмічали, на рівні RSS відсутнє іменування об'єктів бази даних, що вживається на рівні SQL. Замість імен об'єктів використовуються їх унікальні ідентифікатори, що є прямими або непрямими адресами внутрішніх описувачів об'єктів на зовнішній пам'яті для постійних об'єктів або в оперативній пам'яті для тимчасових об'єктів.

Можна виділити наступні групи операцій:

операції сканування відносин і списків;

операції створення і знищення постійних і тимчасових об'єктів бази даних;

операції модифікації відносин і списків;

операція доповнення поля до відношення;

операції управління проходженням транзакції;

операція явної синхронізації.

Операції групи сканування дозволяють послідовно в порядку, що визначається типом сканування, прочитати кортежі відношення або списку, що задовольняють необхідним умовам. Група включає операції OPEN, NEXT і CLOSE, що означають, відповідно, почало сканування, вимога наступного кортежу, що задовольняє умовам, і кінець сканування.

Для відносин можливі два режими сканування: по відношенню і по індексу. При скануванні по відношенню єдиним параметром операції OPEN є ідентифікатор відношення (що включає, до речі, і ідентифікатор сегмента, в якому це відношення зберігається). Внаслідок того, що в System R допускається розміщення в одній сторінці даних кортежів декількох відносин, сканування по відношенню передбачає послідовний перегляд всіх сторінок сегмента з виділенням в них кортежів, що входять в дане відношення; це дуже дорогий спосіб сканування відношення. При цьому порядок вибірки кортежів визначається їх фізичним розміщенням в сторінках сегмента, тобто приречений системою.

При відкритті сканування відношення по одному з його індексів в число параметрів операції OPEN входить ідентифікатор індексу, визначеного раніше на полях цього відношення. Крім того, можна указати діапазон сканування в термінах значень полів, що складають ключ індексу. При відкритті сканування по індексу проводиться початкова установка покажчика сканування в позицію листа В-дерева індексу, відповідну лівій межі заданого діапазону. Процес сканування складається в послідовному просуванні по листових вершинах індексу до досягнення правої межі діапазону сканування з вибіркою tid'ів і читанням відповідних кортежів. Легко бачити, що якщо сканування проводиться не по кластеризованому індексу, то в гіршому випадку може бути потрібні стільки читання сторінок даних із зовнішньої пам'яті, скільки tid'ів було зустріти, тобто ефективність