Попробуем поточнее сформулировать. сразу оговорюсь, имеется ввиду объектно-ориентированный подход, в котором мы выделим экземпляр объекта, методы, которые к нему применимы (суть функции) и того, кто эти методы применяет (пользователя).
Теперь разберем по частям.
Что такое группа пользователей ни у кого сомнений нет - это множество пользователей. В некоторых системах группы могут быть вложены друг в друга, в некоторых системах жесткая одноуровневая иерархия, где-то вообще несколько фиксированных групп.
В тех системах, на которые я смотрю, группа функций - это роль. Ее вводят для того, чтобы не протыкивать десятки галочек на сотнях объектов, разрешая или запрещая одно и тоже. Чтобы была определенность, давайте договоримся, что функция - это некое значимое для нас действие над объектом (в зависимости от прикладной области): кнопка, нажимаемая пользователем, медод COM компонента, вызываемый контроллером автоматизации, выполняемое приложение и т.д.
Группа объектов в каждой системе выделяется по своим правилам: все записи таблицы, все таблицы одного владельца, все файлы данного каталога и т.д., все зависит от прикладной области.

В момент, когда пользователь "А" хочет применить функцию "Б" к набору данных "В", система должна понять, можно ему это или нельзя...
Как результат ей надо хранить множество разрешений или множество запрещений для того. чтобы иметь возможность вычислить функцию МОЖНО(А,Б,В).

Так вот, как обеспечить вычисление этой функции и решает каждый раз система разграничения доступа.
Один из вариантов (всего лишь один из) - хранить некий эквивалент тренарного отношения А-Б-В (кстати - это трехмерный куб). Дальше, чтобы сэкономить клики и память, куб считают заполненным исходно галочками одного вида (например, "нельзя") вдоль ребер этого куба выстраивают иерархии групп пользователей, групп функций (ролей) и групп данных, а на пересечении регионов расставляют галочки (напрмер, "можно").
Таким образом соединение объекта данных (или группы объектов или объекта-контейнера), функции (метода этого объекта в широком понимании) и пользователя (учетной записи системы) дает нам конкретное назначение прав.

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

Один из распространенных вариантов нарушения ортогональности этой системы - жесткое закрепление роли за предустановленной группой (системные администраторы, гости и т.д.) Если параллельно действует и полноценное назначение роли пользователю, начинает возникать путаница, куда добавляют пользователя в роль или в группу. На самом деле пользователя можно добавить только в группу пользователей. В случае с ролью Вы создаете связь роли и пользователя, таким образом заготавливая сразу несколько плоскостей функция-пользователь (в вышерассмотренном кубе) под соединение с объектом.
Другие варианты могут, например, не учитывать данные, давая или не давая пользователю право на исполнение некоей функции (запуск исполняемого файла, напрмер, да еще и с правами админа), полагаясь на то, что функция возьмет на себя часть забот системы разграничения прав.
Много может быть еще вариантов. Я продолжаю настаивать на том, что все в результате сводится к пляскам вокруг хранения, редактирования и выборки из объема функций-пользователей-объектов, а реализаций тут может быть масса, и каждая из них диктуется особенностями классификации и группировки сущностей вдоль каждого из ребер куба.

4321>множество ползателей - это "Олл".
Предлагаю вернуться к институтскому курсу теории множеств, чтобы не вводить аудиторию в заблуждение.
Роль - понятие нечеткое. Я предложил свою трактовку, если вам она не нравится, давайте для множества функций предложим другой термин, а роль возьмите себе.

4321>гм. У вас какое непонятная аппсолютизация группировок.
Во многих системах вы создаете группу и помещаете в нее произвольных пользователей, они не обязаны обладать никакими дополнительными признаками, кроме того, что вы выбрали их для данной группы.

guest_20040621>Опаньки... ну расскажите же скорее, что такое "значимое"
guest_20040621>действие, а что такое "незначимое"? Поясните, пожалуйста,
guest_20040621>почему вдруг какие-то действия зависят от предметной области?
Значимое - это рассматриваемое в данной модели предметной области, например, для операционной системы открытие файлов на чтение или запись, а для СУБД, чтение-запись в таблицы (при этом часто все равно сколько и каких файов при этом закрывается и открывается), для документооборотной системы - открытие и закрытие объекта, редактирование атрибутов (при этом в СУБД обычно это работа на уровне отдельных строк, а чтение и запись в целом в таблицы здесь, обычно, незначимые функции, на которые права не устанавливаются)

guest_20040621>Больший бред на sql.ru я читал только в авторстве ЧАЛа.
Не надо читать бред, умеете писать лучше, пишите :)

ModelR> Группы, наследующие функции и права суть роли.
ModelR> Группы, наследующие только функциии - группы функций однако.
Почти готов согласиться, что ролью можно назвать группу функций, с проставленными правами выполнения, возможно, это даже вернее.

>4321
Никто не спорит, что группы создаются, чтобы соединить с ролью или сразу с правами. Но группа - это группировка пользователей. а роль - это группировка полномочий. Всем понятно, что можно обойтись и без групп пользователей и без ролей и каждое атомарное полномочие сношать с каждым пользователем. Но чтобы упростить себе задачу вводят или то или другое или и то и другое (а более общего случая я не встречал).
А по поводу, для чего и то и другое: попробуйте предоставить роль читателя всем пользователям(к примеру, 100 галочек), когда группы ALL у вас нет, но есть иерархия ролей. И попробуйте предоставить пяти группам пользователей по 50 различных атомарных полномочий (5*50=250 галочек), когда нет объединения ролей в группы. Обычно сверхгибкими структурами не увлекаются. Если есть гибкая иерархия групп, то иерархия ролей чаще всего зафиксирована и не подлежит расширению.

guest_20040621> Hint: google работает.
Hint: читайте google.