В настоящее время я разрабатываю администрацию члена для местной ассоциации и сейчас я разрабатываю схему базы данных.Я хотел бы поделиться им с вами, чтобы улучшить его и привести другой пример модели доступа на основе ролей (RBAC).Я был бы признателен за любую конструктивную критику, особенно в отношении отношений, которые я использовал между таблицами.
Ссылка на высокое разрешение: http://i.stack.imgur.com/WG3Vz.png
Вот схема: 
Какэто работает:
Я сопоставляю существующих клиентов (фактически членов ассоциации) из внешнего приложения в мое приложение администрирования.(таблица клиентов)
Ассоциация структурирована в Отделе, Подразделениях и т. д. (таблица intern_structures).Каждый клиент может быть членом нескольких Отделов, Подразделений, Секций и т. Д.
Каждый клиент может иметь одну или несколько ролей в таких членствах (отделах, ...), как Президент, Актуарий, Казначей и т. Д., А также в каждой роли.имеет определенные привилегии, которые владелец роли может применять к другим в своем отделе, подразделении, отделе и т. д.
Учетные данные связаны с определенным действием приложения.Владелец учетных данных может выполнить это действие для других участников в своей области.Может быть несколько «автономных» приложений, но все они используют одну и ту же систему аутентификации / авторизации.
Приложение структурировано в Модули / Субмодули / Действия и т. Д. Примером может быть модуль «Личные данные», и этот модуль содержит подмодуль под названием «Изображение», и вы можете применять действия «просматривать, удалять, редактировать».на этой картинке.Но вы не можете удалить любое изображение, если человек, чье изображение вы пытаетесь удалить, не находится в подразделении / разделе, где у вас есть соответствующая роль.
Внутренняя структура и структура приложения являются деревьями, реализованными каксписок смежности и вложенный набор.Список смежности обеспечивает целостность, а вложенный набор позволяет мне быстро обходить дерево.
Исключением является то, что вы можете дать кому-то определенные учетные данные напрямую (client_credentials).Это необходимо, если кому-то необходимо выполнить определенные действия с кем-то, кто не входит в его раздел / секцию.
Таким образом, кто-то может быть участником нескольких разделов / секций и получать несколько ролей в каждом разделе / разделе, в котором он находитсячлен.Я собираюсь объединить все полномочия, которые кто-то имеет через его несколько ролей.И учетные данные всегда положительны, значит ограничительные учетные данные невозможны.