Проблематика и назначение:

Разделение схем в основе своей реализуется для масштабируемости и безопасности:

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

Проблематика есть в том что если мы будем давать гранты на модификацию данных не владельцем таблиц (первичных данных), мы получаем пласт проблем:

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

Метод решения проблем:

Решение проблем с масштабируемостью/безопасностью/прозрачностью поведения системы нам поможет:

• Инкапсуляция DML внутри схемы — всё управление транзакциями, а также DML операции осуществляется в рамках схемы-владельца таблицы.

Описание архитектуры предложенного метода:

Рисунок 1 — Взаимодействие схем между друг другом

Из рисунка видно, что схемы взаимодействуют между друг другом посредством GATE_PACKAGE или гейтовых пакетов.

Есть 2 типа гейтовых пакетов:

• gate_package_in — для входящих запросов к схеме.
• gate_package_out- для исходящих запросов из схемы в другую схему.

Все изменения данных осуществляются внутри схемы, прямого DML (insert, update, delete) обращения из чужой схемы (не владелице таблицы) к таблице не происходит.
Обращение из чужой схемы к любым методам/константам/типам и другим объектам также производится через гейтовые пакеты.

Такое взаимодействие позволяет иметь одну точку выхода и входа из/в схему, а в с случае разнесения схем в разные БД, мы получим следующую схему взаимодействия:



Рисунок 2 — Взаимодействие схем при разнесении их в разные БД.

Из рисунка видно, что при разнесении схем в разные БД у нас поддерживается принцип масштабирования, т.е. 2 схемы разнеслись в разные БД без ущерба основному функционалу.
Представим какие проблемы могли возникнуть при прямых DML из одной схемы в другую.
Ниже представлен рисунок раздачи грантов при взаимодействии 2х схем: поддержка текущей структуры масштабирования, безопасности, а также исключение неопределенности с точки зрения поведения системы:



Рисунок 3 — Схема раздачи грантов при взаимодействии 2х схем.

Из рисунка видно что мы запретили DML операции insert, update, delete, а также execute на объекты одной схемы в другую, кроме in_gate_package.

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

В идеале в дальнейшем запретить грант select относительно таблиц другой схемы и использовать только методы их гейтового пакета.

При таких подходах (рисунок 1, 2, 3), мы получаем:

• Решение проблемы с масштабируемостью — Нет проблем при разнесении схем в разные БД.
• Решение проблемы с безопасностью — запрет модификации данных и прямого обращения к методам/объектам для модификации первичны данных не владельцем этих данных.
• Решение проблемы с прозрачность поведение системы — любая модификация данных происходит через одну входную/выходную точку в рамках одной схемы.