Проблемы и цель: Разделение схем реализовано в основном для масштабируемости и безопасности:
- Масштабируемость с точки зрения базы данных должна быть такой, чтобы схему можно было переместить в другую базу данных без ущерба для функциональности.
- Безопасность с точки зрения базы данных должна быть такой, чтобы внешние пользователи работали только с бизнес-логикой, на которую распределяются гранты, и не имели доступа к первичным данным.
- Проблема масштабируемости заключается в том, что невозможно распределить схемы по разным базам данных.
- Проблема безопасности заключается в том, что когда мы получаем доступ к одной схеме, мы получаем доступ к первичным данным другой схемы.
- Проблема с прозрачностью поведения системы.
Невозможно понять, где изменяются данные схемы, что приводит к непредсказуемому поведению системы.
Метод решения проблемы:
Решить проблемы с масштабируемостью/безопасностью/прозрачностью поведения системы нам поможет:- Инкапсуляция DML внутри схемы — все управление транзакциями, а также операции DML выполняются в рамках схемы-владельца таблицы.
Описание архитектуры предлагаемого метода:
Рисунок 1 – Взаимодействие цепей друг с другом Из рисунка видно, что схемы взаимодействуют друг с другом через GATE_PACKAGE или пакеты шлюза.
Существует 2 типа пакетов ворот:
- Gate_package_in — для входящих запросов к схеме.
- Gate_package_out — для исходящих запросов из схемы в другую схему.
Такое взаимодействие позволяет нам иметь одну точку выхода и входа из/в схему, а в случае разделения схем на разные базы данных мы получаем следующую схему взаимодействия: 
Рисунок 2 — Взаимодействие схем при их распределении по разным базам данных.
Из рисунка видно, что при разделении схем по разным базам данных мы поддерживаем принцип масштабирования, т.е.
2 схемы переносились в разные базы без ущерба для основного функционала.
Давайте представим, какие проблемы могут возникнуть при прямом DML из одной схемы в другую.
Ниже представлена картина распределения грантов при взаимодействии 2-х схем: поддержка текущей структуры масштабирования, безопасность, а также устранение неопределенности в плане поведения системы: 
Рисунок 3 — Схема распределения грантов при взаимодействии 2-х схем.
Из рисунка видно, что мы запретили DML-операции вставки, обновления, удаления, а также выполнение над объектами из одной схемы в другую, кроме in_gate_package. Мы разрешаем запуск из гейт-пакетов, также возможны запросы с планшетов другой схемы, только в случае проблем с производительностью и необходимости использования планшетов в рамках больших запросов.
В идеале в будущем отключить разрешение выбора относительно таблиц другой схемы и использовать только методы их гейт-пакета.
При таких подходах (рис.
1, 2, 3) получаем:
- Решение проблемы масштабируемости.
При распределении схем по разным базам данных проблем не возникает.
- Решение проблемы безопасности состоит в запрете модификации данных и прямом доступе к методам/объектам модификации первичных данных лицами, не являющимися владельцами этих данных.
- Решение проблемы прозрачности поведения системы заключается в том, что любая модификация данных происходит через одну точку ввода/вывода внутри одной схемы.
-
Рекомендации На Основе Изображений Продуктов
19 Oct, 24 -
Рынок Серверов Идет На Поправку
19 Oct, 24 -
Прозрачный Общественный Туалет
19 Oct, 24 -
Превращение В Гаджет
19 Oct, 24
