ModelRЕсли бы не проблема доступа, не вижу смысла вторую сущность вводить в логическую модель.
Согласен. Я даже не настаиваю на ее формальном введении. Тем не менее, если мы ставим задачу именно с ограничением доступа - формально должны будем сделать именно так.

Имхо ситуация такова: есть некий формализованный процесс разработки. Любой нормальный человек приспосабливает его к ситуации, в том числе убирая ненужные в данном случае формальности. Однако при этом стоит таки "держать в уме" то, что не сочли нужным записывать на бумаге. Не факт, что я нарисую в ER-ке такую вот суммарную вьюху, но имхо действовать следует так, как если бы она была нарисована; по крайней мере - не противоречить явно. Иначе получится уже "напрасно отменили эти формальности".

ModelRЕе также нет смысла вводить, если право дается на отчет. Отчет тогда считается частью системы, и использует сырые незащищенные данные. Нет?
Нет. Такой подход означает следующее: вместо того, чтобы реализовать защиту в одном месте, она заново реализуется в каждом отчете. Этот подход имеет все минусы копирования кода по сравнению с выделением стандартных подпрограмм. Достаточно подумать о цене тестирования - одно дело протестировать вьюху, не дает ли она кому-либо из двадцати пользователей лишней информации, другое дело - протестировать сотню отчетов, не дает ли он кому-либо из двадцати пользователей лишней информации. Если мы говорим о защищенной информации.... лично я просто не назову "защитой" то, что программист или постановщик может нарушить элементарной рассеянностью.

Поэтому я полагаю что первая часть - обязательна. Второй подход - возможен в порядке исключения в конкретном случае (конкретном отчете).

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

Обратите внимание, как идет цепь рассуждений. Правильная (с моей точки зрения):

1. Определить объекты доступа и политику ограничений к ним (разная политика - разные объекты).
2. Спокойно работать.

В примере же с дополнительными полномочиями получается следующее:

1. Определить "вроде как один" объект.
2. Наткнуться на то, что невозможно посчитать требуемый отчет.
3. Родить простое и кривое решение - дополнительные полномочия отчета.

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

?Вот этот хитрый отчет, судя по всему, тоже так должен сделать:
Не "должен". Просто "постановщику лень подумать", и он находит "простой путь".

мод1. К сожалению не всякий отчет сводится к вьюхе.
Разумеется. Это просто удобное слово-упрощение. Можно читать "любой объект - источник данных".

Суть в том, что проверка прав должна кодироваться в одном месте, пока нет очень существенной причины отойти от этого правила.

мод2. Ввод параметров всех отчетов реализуется одним набором процедур => проверка прав кодируется один раз.
Это покрывает только простые случаи. Проверка прав не сводится к ограничению допустимого множества параметров, хотя согласен, это типовой вариант.

мод3. Самое неправильное - это раздавать пользователям права на объекты БД (таблицы, вью и пр.), пользователи про БД вообще не должны ничего знать, даже про ее существование.
Я не вижу логики в сказанном Вами и не думаю, что обсуждение этого будет полезным.

Впрочем, мне слегка интересно, каким образом работает пользователь, если он не имеет прав на процедуры, через которые "вводятся параметры отчетов".

ModelRГрамотные и продуманные на эн лет вперед постановки - это было бы прекрасно.
Но не является необходимым или хотя бы названным мной условием. Я нигде об этом не говорил и этого не подразумевал; предлагаю не уводить в сторону.

ModelRНо реально получится, что для нового отчета нужно переосмысливать ранее созданные
Вот это уже плохая постановка, плохо выполненное обследование. Ближе так: время от времени, при изменении бизнеса, нужно переосмысливать некую часть ранее сделанного. Нормальная и естественная задача сопровождения.

ModelRотслеживать что в каком отчете используется,
Нет. Это как раз при "отчетной" модели придется что-то отслеживать. Если права обрезают источники данных - на отчеты становится глубоко наплевать. Можно сотворить хоть тысячу отчетов, можно дать пользователю конструктор отчетов - все равно до скрытых от него данных он не доберется. И программист по рассеянности их ему не откроет.

ModelRа также администратору возится с раздачей прав.
Ничуть. У меня такое ощущение, что Вы сейчас попали в сеть одной вредной привычки - оценивать "другое решение", подсознательно рассматривая его через призму существующего, перенося на него накопленные рефлексы.

ModelRБудет ли это надежней чем отладить отчет - вопрос...
Отладить один источник данных заведомо надежнее, чем отладить N отчетов.

ModelRИ грань между отчетом и вьюхой стирается.
Непринципиально в данном случае. Отчет - это не источник данных; это в общем случае форма представления дополнительно обработанных данных из нескольких источников. Его можно рассматривать как вторичный источник данных, но в силу вторичности - данные в отчете специфически обрабатываются и фильтруются - у него мал коэффициент повторного использования.

Конечно, можно все на свете обозвать отчетом, но это сугубое теоретизирование.

Что интересно - в системе, в проектировании которой я относительно недавно принимал участие, мне пришлось приложить кучу усилий как раз для убеждения в правильности такого сведения. Но там существенно особый случай.

ModelRВ общем одно место как-то все время расползается
Хм. Скажем так, по моим ощущениям расползаться склонно то, что сделано не на месте. Например, если изначально в одной подпрограмме сделали то, что надо было разделить на три - велика вероятность того, что треть ее кода захочется откопировать в другое место. Но правильным будет - выделить подпрограмму.

модЯ не раздаю права на процедуры.
В контексте дальнейшего я скорее понимаю это как "я каждому даю права на все процедуры".

модГрубо говоря, main может вызвать каждый, кто прошел авторизацию, дальше вызов пойдет по правам на функции программы.
Для этого есть ровно два пути - либо раздавать права на хранимки, либо полагаться только на собственный велосипед.

модЕсли есть право на данный отчет, то процедуры ввода параметров вызовутся, а вот что через них можно ввести, определяется правами на данные.
То есть, если я правильно понимаю, я беру старый-добрый SQL*Plus, подключаюсь к БД, чихая на все права на отчеты, запускаю "процедуры ввода параметров", и остается надеяться на то, что уж они-то не пустят меня к чужим данным.

Не вижу в этой схеме ничего правильного.

модДа, конечно, если пользователи могут прямо ходить в БД, то от них надо защищаться, раздавать права.
OK.

модПри большом числе объектов БД это трудоемко.
Не сказал бы. Раздача прав на один объект малозаметна на фоне разработки и тестирования этого одного объекта. Трудоемко - если сначала сделали кучу всего чер-те-как, а потом подумали, не раздать ли права.

модПроще, наверное, вообще лишить их всяких прав. Т.е. работать можно только через прикладнуху.
Это лечение перхоти методом доктора Гильотена. Я не назову ни одного метода сделать так, который бы

1) Был надежен на уровне более чем "тупые пользователи"
2) Не обладал бы куда более существенными минусами, нежели стоимость раздачи прав.

Кроме того, такая постановка вопроса живет ровно до первого интеграционного проекта - когда начинается "а вот мы хотим подключаться к этой БД нашим генератором отчетов", или "мы хотим брать эти справочники для репликации в другую ИС" итп.