Implementar o gerenciamento de permissão do usuário em sistemas de negócios
As permissões no sistema B/S são mais importantes do que as de C/S. Como o sistema C/S possui um cliente especial, a detecção de permissão de usuários de acesso pode ser implementada através do cliente ou através da detecção do cliente + servidor. Em B/S, os navegadores já estão disponíveis para todos os computadors. Se uma detecção completa de permissão não for estabelecida, é provável que um "usuário ilegal" acesse facilmente todas as funções no sistema B/S através do navegador. Portanto, os sistemas de negócios da B/s precisam ter um ou mais sistemas de permissão para implementar a detecção de permissão de acesso, para que os usuários autorizados possam usar funções autorizadas normalmente e legalmente, e os "usuários ilegais" não autorizados "os rejeitarão completamente. Vamos dar uma olhada em como projetar um sistema de permissão que possa atender ao controle das permissões de função do usuário na maioria dos sistemas B/S.
Declaração de requisito
• O pessoal com diferentes responsabilidades deve ter permissões diferentes para operações do sistema. Excelente sistema de negócios, essa é a função mais básica.
• Você pode atribuir permissões ao grupo. Para um sistema de negócios de uma grande empresa, é demorado e inconveniente pedir aos administradores que atribuam permissões de operação do sistema a seus funcionários, um por um. Portanto, o sistema propõe o conceito de operar em "grupos" e organiza pessoas com permissões consistentes no mesmo grupo e, em seguida, aloca permissões para o grupo.
• O sistema de gerenciamento de permissão deve ser extensível. Deve ser capaz de ingressar em qualquer sistema com recursos de gerenciamento de permissão. Assim como os componentes, eles podem ser constantemente reutilizados, em vez de reconstruir a parte de gerenciamento de permissão para cada sistema de gerenciamento desenvolvido.
• Atenda às permissões funcionais no sistema de negócios. Nos sistemas de negócios tradicionais, existem dois tipos de gerenciamento de permissão. Um é o gerenciamento de permissões funcionais, e o outro é o gerenciamento de permissões de recursos. Entre diferentes sistemas, as permissões funcionais podem ser reutilizadas, enquanto as permissões de recursos não podem.
Sobre design
Com a ajuda do conceito de programação de ação de Noahweb, no estágio de design, os designers de sistemas não precisam considerar o design da estrutura do programa, mas comece com o fluxo do programa e a estrutura do banco de dados. Para realizar os requisitos, o design do banco de dados é extremamente importante. Seja o conceito de operação de "grupo" ou a reutilização de todo o conjunto de sistemas de gerenciamento de permissão está no design do banco de dados.
Vamos analisar a estrutura do banco de dados primeiro:
Primeiro, a tabela de ação ( a seguir denominada "tabela de permissão" ), a tabela GorupManager ( a seguir denominada "Tabela de Grupo de Gerenciamento" ) e a tabela mestre ( a seguir denominada "tabela de pessoal de pessoal" ), são três tabelas de entidade que registram as informações de "permissões", as informações do "grupo de gerenciamento" e as informações ". Como mostrado na figura abaixo:
A relação entre essas três mesas é muitos para muitos. Uma permissão pode pertencer a vários grupos de gerenciamento ao mesmo tempo, e um grupo de gerenciamento também pode conter várias permissões ao mesmo tempo. Da mesma forma, uma pessoa pode pertencer a vários grupos de gerenciamento ao mesmo tempo, e um grupo de gerenciamento também pode incluir vários funcionários ao mesmo tempo. Como mostrado na figura abaixo:
Como existe uma relação de muitos para muitos entre essas três tabelas, é melhor usar as outras duas tabelas para concluir a interação. Essas duas tabelas desempenham um papel de mapeamento, a tabela "ActionGroup" (a seguir denominada "tabela de mapeamento de permissão") e a tabela "MasterGroup" (a seguir referido como "Tabela de mapeamento de pessoal") . O primeiro mapeia a interação entre a tabela de permissão e a tabela do grupo de gerenciamento. Este último mapeia a interação entre a tabela de pessoal e a tabela do grupo de gerenciamento. Como mostrado na figura abaixo:
Além disso, também é necessária uma tabela para controlar a coluna de permissão no menu esquerdo do tempo de execução do sistema, ou seja, a "tabela de coluna de permissão", como mostrado na figura abaixo:
Com base na análise acima, realizamos o design da estrutura do banco de dados, como mostrado na figura abaixo:
Clique aqui para ver o design do campo de dados do sistema de gerenciamento de permissão Design de campo
Para realizar uma boa análise, dividimos o gráfico de estrutura do banco de dados. O papel das três tabelas de entidade já é muito claro. Agora, vamos dar uma olhada no papel das duas tabelas de mapeamento.
Uma tabela de mapeamento de permissão é mostrada abaixo:
Primeiro, vamos dar uma olhada na associação de campo entre a tabela de mapeamento de permissão e a tabela do grupo de gerenciamento e a tabela de permissão .
Olhando para o círculo vermelho da imagem, primeiro olhe para a associação do campo Gorupid. O desempenho desse método de associação no banco de dados real é o seguinte:
Conforme mostrado na figura, o grupo de "Super Administrador" na tabela do grupo de gerenciamento é 1, portanto, a permissão com o grupo de 1 na tabela de mapeamento de permissão é que é a permissão de propriedade do "Super Administrador".
Use a GroupID Field Association para descobrir quais permissões um grupo de gerenciamento pode executar. No entanto, as informações detalhadas dessas permissões são encontradas na Associação de Campos de Ação.
O comportamento do campo de ação no banco de dados é o seguinte:
Somente por meio dessa associação as informações detalhadas dessas permissões na tabela de mapeamento de permissão . Em resumo, sabemos quais permissões um grupo de gerenciamento pode executar e quais detalhes dessas permissões são.
Talvez você pergunte, por que não usar o campo ActionID para se associar? porque:
• O campo ID na tabela de permissão pode mudar após várias operações de banco de dados.
• A tabela de mapas de permissões registra apenas as permissões que um grupo de gerenciamento pode executar.
• Depois que o ID na tabela de permissão mudar, os registros na tabela de mapas de permissão também mudam.
• Haverá um erro nas permissões que um grupo administrativo pode executar, o que é muito indesejável.
Considerando a situação acima, o campo de ação deve ser associado porque:
• Na tabela de permissão, o ID pode mudar, mas o campo de ação não pode mudar em nenhuma circunstância.
• Os campos de ação registrados na tabela de mapas de permissão não serão alterados.
• Não haverá erros nas permissões que um grupo administrativo possa executar.
A tabela de mapeamento de duas pessoas é a seguinte:
Vamos aprender sobre a associação de campo entre a tabela de mapeamento de pessoal , a tabela do grupo de gerenciamento e a tabela de pessoal , conforme mostrado na figura abaixo:
Olhando para a parte do círculo vermelho da imagem, primeiro veja a Associação de Campo do Grupo. Este método de associação executa no banco de dados, conforme mostrado na figura abaixo:
Como mostrado na figura, o grupo do grupo "Super Administrador" é 1. Vejamos a tabela de mapeamento de pessoal . O administrador pertence ao Grupo Super Administrador, enquanto o administrador pertence ao Super Administrator Group e também pertence ao Grupo de Administrador.
Esse método de associação é usado para descobrir quem está em um grupo de gerenciamento. Como acima, as informações detalhadas de uma pessoa são consultadas por associação com o campo de identificação (o campo MasterID na tabela de mapeamento de pessoal ).
O campo de identificação (campo MasterID na tabela de mapeamento de pessoal ) está relacionado ao banco de dados, como mostrado na figura abaixo:
Uma pessoa pode pertencer a vários "grupos de gerenciamento" ao mesmo tempo. Como mostrado na figura, o administrador pertence a dois "grupos de gerenciamento" ao mesmo tempo. Portanto, haverá dois registros sobre os administradores na tabela de mapeamento de pessoal .
Somente dessa maneira podemos consultar as informações detalhadas do pessoal no grupo de gerenciamento. Somente combinando, podemos saber quem está em um grupo de gerenciamento e nas informações detalhadas desse pessoal.
Combinando a tabela de permissão e a tabela de mapeamento de permissão mencionada acima, a operação "Grupo" nos requisitos é realizada, conforme mostrado na figura abaixo:
De fato, a tabela do Grupo de Gerenciamento registra apenas as informações básicas do grupo, como nome, ID do grupo, etc. Quanto aos detalhes das pessoas em um grupo, bem como os detalhes das permissões que o grupo pode executar, elas são registradas na tabela de pessoal e na tabela de permissão . Somente as duas tabelas de mapeamento realmente registram quais são as pessoas em um grupo e quais permissões podem ser executadas. Somente através da conexão de duas tabelas de mapeamento a interação entre as três tabelas de entidade, concluindo assim a operação de "grupo" mencionada nos requisitos .
Vamos dar uma olhada na interação entre a tabela de coluna de permissão e a tabela de permissão . Os campos entre essas duas tabelas são os seguintes:
As duas tabelas usam o campo ActionColumnId para ser associado. O método de relacionamento no banco de dados é mostrado na figura abaixo:
Como mostrado na figura, através deste método de associação, podemos ver claramente a qual coluna as permissões na tabela de permissão pertencem.
Agora, a estrutura do banco de dados é muito clara e a função de atribuir permissões e operações de "grupo" foi implementada. Vamos analisar os problemas de reutilização dos sistemas de gerenciamento de permissão mencionados nos requisitos.
Por que um sistema criado usando esse método de design de banco de dados pode ser reutilizado?
Três elementos decisivos no sistema são registrados nas três tabelas de entidade. "Permissões", "grupos" e "pessoas". Esses três elementos podem ser adicionados à vontade sem serem afetados um pelo outro. Independentemente do tipo de sistema de negócios, esses três elementos decisivos não mudarão, o que significa que a estrutura não mudará, mas apenas os dados mudarão.
A relação entre os três elementos é registrada nas duas tabelas de mapeamento. Mas esses relacionamentos são completamente criados pelo homem. Quando as alterações são necessárias, elas operam apenas nos registros no banco de dados sem alterar a estrutura.
A tabela de coluna de permissão registra as colunas exibidas quando o sistema é usado . Se você deseja adicionar colunas, modificar colunas ou reduzir colunas, é apenas um registro de operação.
Em resumo, o sistema pode ser completamente reutilizado projetando um banco de dados dessa maneira e pode suportar o teste de "mudança".
Resumir:
A chave desse sistema é que as três tabelas físicas compreendem firmemente os componentes principais do sistema e as duas tabelas de mapeamento mapeiam perfeitamente a interação entre as três tabelas físicas. A dificuldade está em entender o trabalho da tabela de mapeamento, que registra o relacionamento e implementa o conceito de operação de "grupo". O design geral do sistema é atender às configurações de permissão funcional de diferentes sistemas "reutilizando" em diferentes sistemas MIS.
apêndice:
Design de campo da tabela de dados do sistema de gerenciamento de permissão
Vamos dar uma olhada no design da tabela de banco de dados do sistema de gerenciamento de permissão, dividido em seis tabelas, como mostrado na figura abaixo:
Tabela de ação:
A tabela de ação registra todas as ações no sistema e a descrição relacionada à ação.
tabela de ação:
A tabela ActionColumn registra a coluna de ação. Quando o sistema está em execução, a barra de menu esquerda fornece várias funções diferentes. Cada bloco é uma coluna. Cada coluna é adicionada, um registro na tabela será adicionado. Da mesma forma, uma nova coluna será adicionada à barra de menu esquerda.
tabela de ação de ação:
A tabela ActionGroup registra o grupo onde a ação está localizada.
Tabela GrupoManager:
A tabela GroupManager registra informações relevantes sobre o grupo de gerenciamento. Para cada grupo de gerenciamento adicionado, um registro será adicionado aqui.
Tabela de Mastergroup:
A tabela MasterGroup registra o grupo de gerenciamento em que o administrador está localizado. Como um administrador pode pertencer a vários grupos ao mesmo tempo, pode haver vários registros sobre um administrador na tabela.
Tabela mestre:
A tabela mestre registra as informações de todos os administradores. Para cada administrador adicionado, a tabela adicionará um registro.
O design de gerenciamento de permissão geral acima (recomendado) em Java é todo o conteúdo que compartilho com você. Espero que você possa lhe dar uma referência e espero que você possa apoiar mais o wulin.com.