Далі цей користувач може виконати оператор SQL, що означає передачу всіх його прав на цей об'єкт (або їх підмножини) будь-якому іншому користувачеві. Зокрема, цьому користувачеві може бути передане право на передачу всіх переданих йому прав (або їх частини) третьому користувачеві і т.д. Одним з прав користувача по відношенню до об'єкта є право на вилучення у інших користувачів всіх або деяких прав, які раніше ним були передані. Ця операція розповсюджується транзитивно на всіх подальших спадкоємців цих прав.
Наявність в мові засобів визначення представлень і авторизації в принципі дозволяє обійтися при експлуатації System R без традиційного адміністратора баз даних, оскільки практично всі системні дії проводяться на основі засобів SQL. Проте, якщо організаційно адміністратор баз даних потрібно, то його робота досить спрощується за рахунок уніфікованого набору засобів управління. Крім того, в System R каталоги баз даних підтримуються також у вигляді таблиць, і до них застосовані всі запити мови SQL. Помітимо, що в комерційній СУБД з'явився ряд додаткових утиліт, не пов'язаних з мовою SQL (наприклад, утиліти збору статистики або масового завантаження бази даних), і в цих системах, видимо, без адміністратора бази даних не обійтися.
По частині забезпечення паралельної роботи багатьох користувачів з однією базою даних, основний підхід System R полягає в тому, що користувач не зобов'язаний знати про наявність інших, конкуруючих з ним за доступ до бази даних, користувачів, тобто система відповідальна за забезпечення ізольованості користувачів з гарантією відсутності їх взаємного впливу в межах транзакцій. З цього слідує, по-перше, що в інтерфейсі користувача з системою (тобто в мові SQL) не повинно бути засобів регулювання взаємодій з іншими користувачами і, по-друге, що система повинна забезпечити автоматичну серіалізацію набору транзакцій, тобто забезпечити режим виконання цього набору транзакцій, еквівалентний за кінцевим результатом деякому послідовному виконанню цих транзакцій. Ця проблема вирішується в System R за рахунок автоматичного виконання синхронізаційних захоплень по відношенню до всіх змінних об'єктів бази даних. Є ряд тонкості, пов'язаної з такою синхронізацією, на якій ми зупинимося нижче.
Одним з основних вимог до СУБД взагалі і до System R зокрема є забезпечення надійності баз даних по відношенню до різного роду збоям. До таких збоїв можуть відноситися програмні помилки прикладного і системного рівня, збої процесора, поломки зовнішніх носіїв і т.д. Зокрема, до одного з видів збоїв можна віднести згадувані вище порушення цілісності бази даних, і автоматичний відкат транзакції, що ініціюється системою - це системний засіб відновлення бази даних після збоїв такого роду. Як ми відмічали, таке відновлення відбувається шляхом зворотного виконання транзакції на основі інформації про внесені нею зміни, записані в журналі. На інформації журналу засноване відновлення бази даних і після збоїв іншого роду. Управління журналізацією і відновленням в System R вельми цікаве, методи, що застосовуються в ряді випадків відрізняються від методів, що використовуються в іншій СУБД.
Що стосується природних вимог до ефективності системи, то тут основні рішення пов'язані зі специфікою фізичної організації баз даних на зовнішній пам'яті, буферизацією сторінок бази даних, що використовуються в оперативній пам'яті і розвиненою технікою оптимізації запитів, сформульованих на SQL, що проводиться на стадії їх компіляції.
Структурна організація System R цілком узгодиться з поставленими при її розробці цілями і вибраними рішеннями. Основними структурними компонентами System R є система управління реляційною пам'яттю (Relational Storage System - RSS) і компілятор запитів мови SQL. RSS забезпечує інтерфейс досить низького, але достатнього для реалізації SQL, рівня для доступу до даних, що зберігаються в базі. Синхронізація транзакцій, журналізація змін і відновлення баз даних після збоїв також відносяться до числа функцій RSS. Компілятор запитів використовує інтерфейс RSS для доступу до різноманітної довідкової інформації (каталоги відносин, індексів, прав доступу, умов цілісності, умовних впливів і т.д.) і виробляє робочі програми, що виконуються надалі також з використанням інтерфейсу RSS. Таким чином, система природно розділяється на два рівні - рівень управління пам'яттю і синхронізацією, фактично, що не залежить від базової мови запитів системи, і язиковий рівень (рівень SQL), на якому вирішується більшість проблем System R. Помітимо, що ця незалежність швидше умовна, чим абсолютна: мову SQL можна замінити на іншу мову, але він повинен володіти приблизно такою ж семантикою.
Далі ми послідовно розглянемо особливості організації RSS, процес компіляції і оптимізації запитів і техніку виконання відкомпілювати транзакцій (включаючи відмічену вище можливість динамічної компіляції запитів).
7.3. Організація зовнішньої пам'яті в базах даних System R
Як ми відмічали, база даних System R розташовується в одному або декількох сегментах зовнішньої пам'яті. Кожний сегмент складається з сторінок даних і сторінок індексної інформації. Розмір сторінки даних в сегменті може бути вибраний рівним або 4, або 32 кілобайтам; розмір сторінки індексної інформації рівний 512 байтам. Крім того, при роботі RSS підтримується додатковий набір даних для ведення журналу. Для підвищення надійності журналу (а це найбільш критична інформація; при її втраті відновлення бази даних після збоїв неможливе) цей набір даних дублюється на двох зовнішніх носіях.
У кожній сторінці даних зберігаються кортежі одного або декількох відносин. Фундаментальним поняттям RSS є ідентифікатор кортежу (tuple identifier - tid). Гарантується незмінність tid'а під весь час існування кортежу в базі даних незалежно від переміщень кортежу всередині сторінки і навіть при переміщенні кортежу в іншу сторінку. Реально tid являє собою парі <номер сторінки, індекс описувача кортежу в