Внедрить управление разрешениями пользователя в бизнес -системах
Разрешения в системе B/S важнее, чем в C/S. Поскольку система C/S имеет специальный клиент, разрешение обнаружения доступа пользователей может быть реализовано через клиент или через обнаружение сервера Client +. В B/S браузеры уже доступны для каждого компьютера. Если полное обнаружение разрешений не установлено, «нелегальный пользователь» может легко получить доступ ко всем функциям в системе B/S через браузер. Таким образом, бизнес -системы B/S должны иметь одну или несколько систем разрешений для реализации обнаружения разрешений на доступ, чтобы авторизованные пользователи могли использовать авторизованные функции нормально и юридически, и эти несанкционированные «нелегальные пользователи» полностью «отклоняют их». Давайте посмотрим, как разработать систему разрешений, которая может соответствовать управлению разрешениями пользовательской функции в большинстве систем B/S.
Заявление о требовании
• Персонал с различными обязанностями должен иметь разные разрешения для системных операций. Отличная бизнес -система, это самая основная функция.
• Вы можете назначить разрешения группе. Для бизнес-системы крупного предприятия требует много времени и неудобно просить администраторов назначить системы эксплуатации системы своим сотрудникам один за другим. Таким образом, система предлагает концепцию работы в «группах» и организует людей с последовательными разрешениями в одну и ту же группу, а затем распределяет разрешения на группу.
• Система управления разрешениями должна быть расширяемой. Он должен быть в состоянии присоединиться к любой системе с возможностями управления разрешениями. Так же, как компоненты, их можно постоянно использовать повторно, вместо того, чтобы перестроить часть управления разрешением для каждой разработанной системы управления.
• Следить за функциональными разрешениями в бизнес -системе. В традиционных бизнес -системах существует два типа управления разрешениями. Одним из них является управление функциональными разрешениями, а другим - это управление разрешениями ресурсов. Между различными системами функциональные разрешения могут быть использованы повторно, в то время как разрешения ресурсов не могут.
О дизайне
С помощью концепции программирования действий Ноахвеба, на этапе проектирования, проектировщики систем не должны рассматривать проектирование структуры программы, но начинаются с программного потока и структуры базы данных. Чтобы реализовать требования, дизайн базы данных чрезвычайно важен. Будь то концепция «групповой» операции или повторного использования всего набора систем управления разрешениями, заключается в разработке базы данных.
Давайте сначала проанализируем структуру базы данных:
Во -первых, таблица действий ( в дальнейшем названа «таблицей разрешений» ), таблица Gorupmanager ( в дальнейшем, называемой «таблицей группы управления» ), а главная таблица ( далее, называемая «таблицей персонала» ) - это три таблицы объектов, которые записывают информацию о «разрешениях», информации о «группе управления» и информацией о персонале ». Как показано на рисунке ниже:
Отношения между этими тремя таблицами-много-многие. Одно разрешение может принадлежать к нескольким группам управления одновременно, и одна группа управления может также содержать несколько разрешений одновременно. Точно так же человек может одновременно принадлежать к нескольким группам управления, а группа управления может также включать несколько сотрудников одновременно. Как показано на рисунке ниже:
Поскольку между этими тремя таблицами существует множество отношений, лучше всего использовать две другие таблицы для завершения взаимодействия. Эти две таблицы играют картирующую роль, а именно таблицу «Группа действий» (в дальнейшем, называемая «таблицей отображения разрешений») и таблицей «Mastergroup» (далее, называемой «таблицей картирования персонала») . Первые отображают взаимодействие между таблицей разрешений и таблицей группы управления. Последнее отображает взаимодействие между таблицей персонала и таблицей группы управления. Как показано на рисунке ниже:
Кроме того, также необходима таблица для управления столбцом разрешений в левом меню времени выполнения системы, то есть «таблица столбца разрешения», как показано на рисунке ниже:
На основании приведенного выше анализа мы проводим конструкцию структуры базы данных, как показано на рисунке ниже:
Нажмите здесь, чтобы просмотреть проект поля данных системы управления разрешением
Чтобы выполнить хороший анализ, мы разделили структуру базы данных. Роль трех таблиц сущностей уже очень ясна. Теперь давайте посмотрим на роль двух таблиц картирования.
Таблица отображения разрешений показана ниже:
Во -первых, давайте посмотрим на полевую ассоциацию между таблицей картирования разрешений и таблицей группы управления и таблицей разрешений .
Глядя на красный круг на картинке, сначала посмотрите на ассоциацию поля Горупида. Производительность этого метода ассоциации в фактической базе данных заключается в следующем:
Как показано на рисунке, группа «супер -администратора» в таблице группы управления составляет 1, поэтому разрешение с группой из 1 в таблице отображения разрешений заключается в том, что это разрешение, принадлежащее «супер -администратору».
Используйте Groudid Полевую ассоциацию, чтобы выяснить, какие разрешения может выполнить группа управления. Тем не менее, подробная информация об этих разрешениях находится в Ассоциации поля действий.
Поведение поля действия в базе данных следующее:
Только через эту ассоциацию может быть найдена подробная информация об этих разрешениях в таблице отображения разрешений . Таким образом, мы знаем, какие разрешения может выполнить группа управления и каковы подробности этих разрешений.
Может быть, вы спросите, почему бы не использовать поле ActionID для ассоциирования? потому что:
• Поле ID в таблице разрешений может измениться после нескольких операций базы данных.
• Таблица карты разрешений записывает только разрешения, которые может выполнить одна группа управления.
• Как только идентификатор в таблице разрешений изменится, записи в таблице карт разрешений также изменяются.
• Будет ошибка в разрешениях, которые может выполнить административная группа, которая очень нежелательна.
Учитывая вышеупомянутую ситуацию, поле действия должно быть связано, потому что:
• В таблице разрешений идентификатор может измениться, но поле действия не может измениться ни при каких обстоятельствах.
• Поля действия, записанные в таблице карт разрешений, не изменятся.
• Не будет никаких ошибок в разрешениях, которые может выполнить административная группа.
Таблица картирования двух человек выглядит следующим образом:
Давайте узнаем о полевой ассоциации между таблицей картирования персонала , таблицей группы управления и таблицей персонала , как показано на рисунке ниже:
Глядя на часть красного круга на картинке, сначала посмотрите на Групповую полевую ассоциацию. Этот метод ассоциации работает в базе данных, как показано на рисунке ниже:
Как показано на рисунке, группа группы «супер -администратора» является 1. Давайте посмотрим на таблицу картирования персонала . Администратор принадлежит к группе супер администраторов, в то время как администратор принадлежит к группе супер администраторов, а также принадлежит группе администратора.
Этот метод ассоциации используется, чтобы выяснить, кто находится в группе управления. Как указано выше, подробная информация о человеке запрашивается в связи с общением с полем ID (поле Masterid в таблице картирования персонала ).
Поле ID (поле Masterid в таблице картирования персонала ) связано с базой данных, как показано на рисунке ниже:
Человек может принадлежать к нескольким «группам управления» одновременно. Как показано на рисунке, администратор принадлежит к двум «группам управления» одновременно. Таким образом, в таблице картирования персонала будет два записи о администраторах.
Только таким образом мы можем запросить подробную информацию о персонале в группе управления. Только комбинируя его, мы можем знать, кто находится в группе управления и подробной информации этого персонала.
Объединение таблицы разрешений и таблицы отображения разрешений , упомянутая выше, выполняется операция «группы» в требованиях, как показано на рисунке ниже:
Фактически, таблица группы управления только записывает основную информацию группы, такую как имя, идентификатор группы и т. Д. Что касается деталей людей в группе, а также подробности разрешений, которые группа может выполнить, они записываются в таблице персонала и таблице разрешений . Только две таблицы отображения действительно записывают, какие люди в группе и какие разрешения могут быть выполнены. Только через соединение двух таблиц отображения может быть реализовано взаимодействие между тремя таблицами объекта, что выполняет операцию «группы», упомянутую в требованиях .
Давайте посмотрим на взаимодействие между таблицей столбцов разрешений и таблицей разрешений . Поля между этими двумя таблицами следующие:
Две таблицы используют поле ActionColumnid, которое будет связано. Метод взаимосвязи в базе данных показан на рисунке ниже:
Как показано на рисунке, с помощью этого метода ассоциации мы можем четко увидеть, к какому столбцу принадлежат разрешения в таблице разрешений .
Теперь структура базы данных очень ясна, и была реализована функция назначения разрешений и операций «группы». Давайте проанализируем проблемы повторного использования систем управления разрешением, упомянутые в требованиях.
Почему система, созданная с помощью этого метода проектирования базы данных, может быть повторно использована?
Три решающих элемента в системе записаны в трех таблицах объектов. «Разрешения», «группы» и «люди». Эти три элемента могут быть добавлены по желанию, не будучи затронутыми друг другу. Независимо от того, какой это тип бизнес -системы, эти три решающих элемента не изменятся, что означает, что структура не изменится, но только данные изменятся.
Отношения между тремя элементами записаны в двух таблицах отображения. Но эти отношения полностью созданы человеком. Когда необходимы изменения, они работают только в записях в базе данных без изменения структуры.
Таблица столбца разрешений записывает столбцы, отображаемые при использовании системы . Независимо от того, хотите ли вы добавить столбцы, изменить столбцы или уменьшить столбцы, это просто запись операции.
Подводя итог, система может быть полностью повторно использована путем разработки базы данных таким образом и может противостоять тесту «изменения».
Суммировать:
Ключ к этой системе заключается в том, что три физических таблица твердо понимают основные компоненты системы, и две таблицы сопоставления идеально сопоставляют взаимодействие между тремя физическими таблицами. Трудность заключается в понимании работы таблицы картирования, которая записывает отношения и реализует концепцию операции «группы». Общая конструкция системы заключается в соответствии с настройками функциональных разрешений различных систем путем «повторного использования» в разных системах MIS.
Приложение:
Полевой дизайн системы управления разрешением таблицы данных
Давайте посмотрим на дизайн таблицы базы данных системы управления разрешениями, которая разделена на шесть таблиц, как показано на рисунке ниже:
Действие таблица:
Таблица действий записывает все действия в системе и связанное с действием описание.
Таблица ActionColumn:
Таблица ActionColumn записывает столбец действия. Когда система работает, левая строка меню предоставляет несколько различных функций. Каждый блок - это столбец. В каждом столбце добавлен одна запись в таблице. Соответственно, в левой строке меню будет добавлен новый столбец.
Таблица групп действий:
Таблица ActionGroup записывает группу, в которой находится действие.
Таблица GroupManager:
Таблица GroupManager записывает соответствующую информацию о группе управления. Для каждой добавленной группы управления одна запись будет добавлена здесь.
Таблица MasterGroup:
Таблица MasterGroup записывает группу управления, где находится администратор. Поскольку администратор может принадлежать к нескольким группам одновременно, в таблице может быть несколько записей о администраторе.
Мастер -таблица:
Мас -таблица записывает информацию всех администраторов. Для каждого добавленного администратора таблица добавит запись.
Приведенный выше общий дизайн управления разрешениями (рекомендуется) в Java - это весь контент, которым я делюсь с вами. Я надеюсь, что вы можете дать вам ссылку, и я надеюсь, что вы сможете поддержать Wulin.com больше.