Dúvida, como organizar login e senha, etc

7 respostas
W

Olá pessoal,

Me surgiu uma grande dúvida agora:

No meu sistema tenho o cadastro de psicólogos, médicos, pacientes, doenças, etc…
alguns desses cadastros (psicólogos, médicos, etc.) possuem login e senha para acessar o sistema, mas o login e senha são definidos em uma outra janela da aplicação e não na mesma janela que se faz o cadastro do mesmo.

  • Como devo fazer no banco? - Crio atributos login, senha, grupo pra cada tabela (psicologo, médico, etc.)?? E na hora de validar o login na aplicação tenho que correr em todas essas tabelas pra ver se esse usuário existe???
  • Como faço na aplicação? - Eu tinha criado um objeto Usuario (a principio ia ser só um usuario mas agora mudou pra esse monte de usuários) que ficava em memória pra que, quando ele tentasse acessar algo, eu verificasse se há permissão através desse objeto. Mas agora que são diferentes tipos de usuários como faço isso?

7 Respostas

RyuSayajin

eu acho que já que você tem vários usuários deve fazer usuário e pessoa onde o usuário terá login, senha e id daquela pessoa e a pessoa o cadastro normal, tipo nome, endereço…eu acho

espero ter ajudado

thiagodelgado

Olá wellingtonfoz!

A escolha mais sensata depende muito do tipo de sistema que você pretende desenvolver, exemplo: a) um sistema que cadastre e administre um consultório que tem até 5 psicólogos, b) um sistema que administre um hospital psiquiatrico.

Não sei bem se é a melhor analogia, mas na minha opinião, esse é um dos primeiros pontos a se analisar, por unanimidade os sistemas “multi-usuários” possuem uma base de dados, já em relação à criação de classes para lidar com esses valores vindos das tabelas, depende da sua metodologia, se estiver usando orientação à objeto (como esse aqui é um fórum de java, suponho que esteja usando, rs) você pode criar classes com os atributos das tabelas, por exemplo:

Tabela:

tbUsuario
*********
|idUsuario|
|nmLogin |
|cdSenha |

Classe:

Class tbUsuario {


private int idUsuario=0;
private String nmLogin='';
private String cdSenha='';


public tbUsuario(){}

}
W

thiagodelgado:
Olá wellingtonfoz!

A escolha mais sensata depende muito do tipo de sistema que você pretende desenvolver, exemplo: a) um sistema que cadastre e administre um consultório que tem até 5 psicólogos, b) um sistema que administre um hospital psiquiatrico.

Não sei bem se é a melhor analogia, mas na minha opinião, esse é um dos primeiros pontos a se analisar, por unanimidade os sistemas “multi-usuários” possuem uma base de dados, já em relação à criação de classes para lidar com esses valores vindos das tabelas, depende da sua metodologia, se estiver usando orientação à objeto (como esse aqui é um fórum de java, suponho que esteja usando, rs) você pode criar classes com os atributos das tabelas, por exemplo:

Tabela:

tbUsuario
*********
|idUsuario|
|nmLogin |
|cdSenha |

Classe:

Class tbUsuario {


private int idUsuario=0;
private String nmLogin='';
private String cdSenha='';


public tbUsuario(){}

}

ACho que vc não entendeu direito o meu problema.
Sim, é claro que tenho as classes pra serem usadas para instanciar os objetos Psicologo, Medico, etc. A dúvida é:
Como estes podem ser usuários do sistema também eu preciso saber se é melhor criar uma tabela separada de login com atributos usuario e senha no banco ao invés de colocar esses atributos em cada tabela. Se for em cada tabela, na hora de validar login de um usuario, tenho que percorrer todas as tabelas verificando se existe o login e a senha.
Outra dúvida é como eu controlo as permissões do usuário logado. Devo deixar um objeto Usuario com as permissões em memória durante toda a execução do programa??

henriqueluz

Opa wellingtonfoz,

Uma pergunta antes de tomar sua decisão:

  1. Você terá muitos Pacientes, Médicos, etc. que não serão usuários?

Caso você tenha muitos registros desse tipo, ocorrerá de ter muitos campos null, se você optar pela opção de colocar tudo junto.
Eu acho a melhor forma organizar sua tabela de Usuário separada. Criando uma nova apenas com os atributos referentes ao Usuário com uma FK em cada tabela que referencie o seu id de usuário. Até pensando na manutenção e caso você futuramente queira adicionar mais informações a um usuário, bastaria criar o campo nesta tabela e não criar em todas as outras. Entendeu?

Para controlar as permissões utilize as sessões para controlar o acesso de cada usuário.

Espero ter ajudado.

Abraços,

thiagodelgado

O que eu quis dizer, foi o mesmo que o amigo acima, se você tiver muitos usuários, é mais conveninente criar uma tabela para usuários, com os atributos necessários e usar FK’s pra relaciona-los com a tabela dos médicos, dos psicólogos e etc…

Vitoriano

Acho que uma solução seria criar um “nível de acesso”.

Por Exemplo, tem um médico que ele pode apenas consultar e não editar no seu banco, certo? Ele teria um nível de acesso M1 (M - Tipo de acesso | 1 - Nível de acesso)
Se você tem um Psicologo que pode editar, mas não pode fazer TUDO no sistema (apenas consultar e alterar algumas coisas de psicologia), ele teria nível de acesso P2 (P - Tipo de acesso | 2 - Nível de acesso)
Ou você tem algum administrador do sistema, ou medico responsável pela clinica por exemplo, teríamos um nível de acesso A3 (A - Tipo de acesso | 3 - Nível de acesso)

Então, assim, você teria um campo nível de acesso na tabela do sistema onde estará o usuário e senha, e outro na entrada nos métodos, ou criar uma classe que verifica o acesso para os métodos.

Entendeu? Seria uma solução melhor?!

discorpio

Bom dia todos.

Wellington,

1º) Creio que a sua análise está um pouco equivocada, pois voce não teria nem que criar diferentes classes para instanciar diferentes tipos de profissões, sabe por quê :?: :?: :?: Porque todo profissional é um funcionário, então o que voce deveria fazer era simplesmente criar uma classe Funcionário acessando dados da tabela Funcionário, contendo todos os profissionais da Empresa (Médicos, Psicólogos e etc.), tabela esta com um campo chamado cargo, e nesse campo que voce vai armazenar a profissão de cada funcionário.

2º) Seguindo a dica do nosso amigo Riqueluz, nem todo Funcionário vai ser um usuário do sistema, pois o pessoal da limpeza, por exemplo, não vai acessar o sistema, vai :?: Não quero, e longe de mim querer discriminar o pessoal da limpeza, pois haverá também o pessoal de enfermagem, até mesmo médicos que possívelmente não terão acesso ao sistema, então deve-se criar uma tabela de Usuário. Além disso, existe outro fator que voce não levou em consideração, vá que a clínica que te contratou diga pra voce o seguinte: [color=red]"…Quero que cada profissional de saúde tenha acesso somente as fichas dos seus clientes…"[/color]. Mais um motivo para criar a tabela Usuário e a tabela Funcionário, e estas tabelas poderão estar relacionadas no tipo de relacionamento Um para Um.

3º) Seguindo a orientação do atendimento médico personalizado, voce pode criar a tabela Cliente com um atributo “fk_func”, onde irá armazer o id do funcionário que será um usuário, que o atende, fazendo um relacionamento entre as tabelas Funcionario (PK) - Cliente (FK), sendo o relacionamento de um (Funcionario) para vários (Clientes). Assim sendo, voce pode construir uma instrução SQL para acessar o cadastro de clientes da seguinte forma:

Select * from CadCliente Where fk_func = id_usuario

Lembra daquela diagramação que te passei sobre as tabelas “Membro”, “Grupo”, “Acesso” e “Funcionalidade” :?: 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:

select M.usu_id_usuario, F.fun_aplicacao from membro M inner join (
       grupo G inner join (
       acesso A inner join funcionalidade F on F.fun_codigo = A.fun_codigo)
       on A.gru_id_grupo = G.gru_id_grupo)
       on G.gru_id_grupo = M.gru_id_grupo
       where M.usu_id_usuario = id_usuario.

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:

// Classe usuario
   ...
   private static ArrayList<String> permissao;
   ...
   public static ArrayList<String> getPermissao() {
         // Evitando o NullPointer
        if (Usuario.permissao == null) Usuario.permissao = new ArrayList<String>();
        return Usuario.permissao;
   }

   /* Popular as permissões dentro da classe login.
       Após autenticar o usuário, usar a instrução sql acima
       e popular as permissões com o método get  */
       .....
       .....
   while (resultset.next()) {
        ...
        Usuario.getPermissao().add(resultset.getString("F.fun_aplicacao");
        ...
   }

   // Método de acesso que deverá ser criado dentro do DAO do usuário.  
   public boolean isAccessGranted(String funcionalidade) {
        if (Usuario.getPermissao().contains(funcionalidade) {
            return true;
        } else {
            return false;
        }
   }

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

UsuarioDAO usudao = new UsuarioDAO();
  if (usudao.isAccessGranted("Cadastrar Cliente")) {
      /* Acessa o banco com a instrução SQL do cliente personalizado
          fazenda as devidas conexões com uma classe conexao */

      Select * from CadCliente Where fk_func = usuario.getId();

É claro que eu não te passei a codificação toda, pois esta dica serve apenas para te orientar de como iniciar o procedimento correto, ficando a seu critério de como voce irá desenvolver, afinal de contas, voce também tem que estimular um pouco os seus neurônios. :wink: Não tem :?: :lol:

Um abraço.

Criado 16 de julho de 2011
Ultima resposta 18 de jul. de 2011
Respostas 7
Participantes 6