Схема БД управления доступом на основе ролей

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

Ссылка на highres: http://i.stack.imgur.com/WG3Vz.png

Вот схема:

Как это работает:

Я отображаю существующих клиентов (фактически членов ассоциации) из внешнее приложение в мое административное приложение. (таблица клиентов)

Ассоциация структурирована по разделам «Подразделения», «Подразделения» и т. д. (таблица intern_structures). Каждый клиент может быть членом нескольких Подразделений, Подразделений, Секций и т. Д.

Каждый клиент может иметь одну или несколько ролей в таких членствах (подразделениях, ...), как Президент, Актуарий, Казначей и т. Д., И каждая роль имеет определенные привилегии которые владелец роли может применять к другим участникам своего Подразделения, Подразделения, Раздела и т. д.

Учетные данные связаны с определенным действием приложения. Владелец учетных данных может выполнить это действие над другими участниками в своей области. Может быть несколько " Это необходимо, если кому-то нужно выполнить определенные действия над кем-то, кто не входит в его подразделение / раздел.

Таким образом, кто-то может быть членом нескольких подразделений / разделов и получить несколько ролей в каждом подразделении / разделе, членом которого он является. . Я собираюсь объединить все полномочия, которые есть у кого-то в его нескольких ролях. И учетные данные всегда положительные, что означает, что ограничительные учетные данные невозможны.