Perfis de usuários (herança?) VS banco de dados

Debugger Membro desde: 29/06/2010 02:16:38 Mensagens: 72 Offline

Boa tarde.
Tenho uma dúvida boba, mas parece que meu cérebro deu um nó agora.

Estou começando a fazer um sistema de abertura de chamados, e estou modelando meu banco de dados, porém:

terei 2 tipos de usuários:
Operador
Administrador

O Administrador faz tudo o que o Operador faz, porém ele pode cadastrar novos usuários e algumas outras funções.

Estou pensando em fazer uma classe Usuário (Operador) e outra Administrador herdando de Usuário.
Ou Operador e Administrador herdando de Usuário.

A pergunta é: como modelar o banco de dados baseando-se nesses perfis de usuário ?
Usarei o Hibernate no projeto.

Talvez seja uma alternativa: Eu faria com que "Administrador" e "Operator" fossem um tipo de usuário. Você pode até ter uma tabela de Tipo, onde seu sistema pode expandir para mais tipos de usuários.

Debugger Membro desde: 29/06/2010 02:16:38 Mensagens: 72 Offline

Entendi

uma tabela TIPO, contendo os tipos de usuário, e na tabela USUARIO uma chave estrangeira pra TIPO.
não tinha pensado nisso... pqp hehe

alguma outra maneira ?

JWizard Membro desde: 01/10/2006 15:29:40 Mensagens: 2047 Offline

Você usou a palavra certa ao criar seu POST.

Usuários todos serão, mas você quer controlar o Acesso usando PERFIS...

Ou seja, tenha uma tabela Perfil e um Usuário pode ter 1 - N Perfis, porém fica a critério do Sistema. Aconselho a fazer, por enquanto, somente 1 perfil por usuário, pra não crescer muito o relacionamento. Conforme você for clareando as possibilidades, vai aumentando o Sistema.

Abs [] e sucesso

This message was edited 3 times. Last update was at 08/11/2011 22:47:43

Boa noite a todos.

Dê uma olhada neste diagrama de dados.

Bom agora vamos as funções de cada tabela,

1º) A tabela "Usuario" (cor amarela), lógico e evidente armazenará os dados do Usuário, podendo até ser uma tabela simples, somente com os campos "Nome", "Login" e "Senha".

2º) A tabela "Grupo" vai armazenar os grupos de perfís de usuários, lembra de como o Windows armazena seus perfís (Administrador, Usuário Avançado, Usuário Restrito e etc.), pois e nesta tabela "Grupo" que voce vai armazenar estes perfis.

3º) A tabela "Funcionalidade" vai armazenar cada função de "Inserção", "Edição", "Atualização" e "Consulta", configurando cada função destas para cada tabela de seu banco de dados, inclusive a tabela "Usuario".

4º) Ora cada Perfil que está no grupo, poderá ter mais de uma funcionalidade destas, assim como a recíproca é verdadeira, ou seja, cada funcionalidade poderá estar em mais de um perfil, e ai que entra a tabela "Acesso" funcionando como um tabela tupla, ligando o "Grupo" a "Funcionalidade, e por isso os campos "gru_id_grupo" e "fun_codigo" tem que ser chaves primárias compostas.

5º) Assim como a tabela "Perfil", o mesmo ocorrerá com a tabela "Membro", ligando o Usuário ao Grupo, onde também a reciprocidade de relacionamente também e verdadeiro, ou seja, cada perfil ou grupo poderá tem mais de um usuário e cada usuário pode ter mais de um perfil, onde os campos "usu_id_usuario" e gru_id_grupo também são chaves primárias compostas.

A ordem de inserção de dados nestas tabelas devem obedecer a seguinte ordem: 1º)"Funcionalidade", 2º)"Grupo", 3º)"Usuarios", 4º)"Acesso" e 5º) "Membro", lembrando que "Acesso" e "Membro" apenas fazem associações entre "Funcionalidade com Grupo" e "Grupo com Usuarios", respectivamente.

Pois bem, agora vamos implementar a aplicação. Pois é, voce vai carregar dados para dentro de sua aplicação somente da tabela "Funcionalidade" que em outras palavras significa "Permissões", dados estes de acordo com o id_usuario. Onde estes dados serão armazenados na aplicação

Dentro da classe Usuário, armazenando dentro de um atributo do tipo ArrayList ou até mesmo um HashMap. A instrução SQL para este caso ficaria assim:

Agora é só popular um ArrayList ou HashMap da classe Usuario, com todas as funcionalidades, cujos valores poderão ser Ler tabela tal, Atualizar tabela tal e assim por diante, e o acesso a esta instrução SQL acima voce vai fazer dentro da classe Login, logo assim que autenticar o usuario, Após isso, crie um método booleano dentro do DAO do usuário com a seguinte sintaxe:

Assim que voce acessar o form de cadastro de clientes, poderá fazer a verificação com o método acima, da seguinte forma:

É claro que eu não te passei a codificação toda, pois esta dica serve apenas para te orientar de como implementar uma aplicação considerada tão complexa de modo simples, sem precisar de abrir mão de configurar vários perfis para cada usuário, sem a necessidade de ampliar sua aplicação, como foi comentado aqui, onde voce sabendo utilizar todos os recursos que não só a linguagem Java oferece, mas também o SGDB e suas linguagens SQL, e combinando ambas, voce cria implementações simples com grande poderio de processamento.

Debugger Membro desde: 29/06/2010 02:16:38 Mensagens: 72 Offline

preciso de um tempo pra digerir o que o amigo acima falou... hehe

Notícias, artigos e o maior fórum brasileiro sobre Java