DER para sistema advogado

Oi Andrei.

Qual a melhor forma de... ? Iniciar a elaboração do DER? Normalizar dados?

Segue meu DER ae..Minha duvida seria como seria o melhor modo de usa-la e sua implementacao em java

Exemplo

Advogado extends Pessoas

ja a classe pessoa fisica seria one to one pessoas

SOU MEIO RUIM NESTAS VISOES

Para facilitar.Seria mais ou menos assim.Como vc faria sua der para um sistema advogados?E como vc implantaria suas classes em java?
Seria mais ou menos assim.Eu já tenho tudo pronto mas não sei se estou fazendo da melhor forma ou se existe melhores..

Oi Andrei,

a primeira coisa que você deve ter em mente ao fazer este tipo de mapeamento é o seguinte: os dados armazenados em um banco de dados são o resultado de um processamento computacional, e não o contrário (este é um erro muito comum cometido por ai).

No entanto, a abordagem contrária também é muito adotada: a de se criar as classes a partir de uma estrutura de banco de dados pré-existente. Se este segundo caso for o seu, segue aqui algumas dicas ok?

* No que diz respeito ao mapeamento das pessoas, você já fez isto corretamente em seu chamado anterior, atendido inicialmente pelo Dyego e finalizado comigo. Realmente é aquela história: os atributos que são comuns à todos os tipos de pessoas (ou seja, os atributos presentes na classe abstrata Pessoa) ficam em uma mesma tabela, e aqueles atributos que são específicos de uma determinada subclasse em uma classe separada (releia aquela nossa conversa anterior sobre este tópico).


No que diz respeito à criação geral das classes, no entanto, seguem aqui alguns pontos para lhe auxiliar:

* Os campos de suas tabelas que não são chaves estrangeiras devem ser mapeados como campos primitivos em suas classes. Sendo assim, por exemplo: você pode criar uma classe chamada Usuario, cujos dados se encontram armazenados na tabela usuarios. Esta tabela possui os seguintes campos:

Usuarios:
idPessoas: int
usuario: varchar(50)
senha: varchar(30)
idSys_Perfil: int (trata-se de uma chave estrangeira aqui).

A sua classe poderia ser definida portanto tal como

class Usuario {
     private int id; // aponta para o seu campo idPessoas
     private String login; // aponta para o seu campo usuario
     private String senha; // aponta para o seu camop senha
     public Perfil perfil; // aponta para o tipo de perfil. Lembre-se: aqui estamos tratando de uma chave estrangeira naquela tabela
}

* Dica: ao trabalhar com seu mapeamento, comece criando as classes que possuam o menor número de dependências externas provenientes de outras tabelas quanto possível. Com base no seu DER, por exemplo, você deveria primeiro mapear a classe Perfil (que citei acima) relacionada à tabela Sys_Perfil, para depois trabalhar com a classe Usuario.

* Sobre o mapeamento usando JPA (as famigeradas anotações), a melhor fonte que conheço é a documentação oficial, cujo tópico pode ser acessado diretamente neste link: http://java.sun.com/javaee/5/docs/tutorial/doc/bnbpz.html

A propósito Andrei,

o seu diagrama já está bem bacana. O que você precisa agora é implementar as classes. Até agora, está indo corretamente, de acordo com o que vi neste e no chamado anterior.

Deixa eu ver se entendi...

No meu caso aqui. Fiz o seguinte nas classes

public class Advogados extends Pessoas implements Serializable {}

public class AdvogadosAdversos extends Advogados implements Serializable {}

public class Clientes extends Pessoas implements Serializable {}

public class ClientesAdversos extends Clientes implements Serializable {}

public class Usuarios implements Serializable {} //Observe que ela n é extendida, e sim uma relação one to one com pessoas.Mas o problema começa ae.
Eu preciso que APENAS o CLIENTE e o Advogado possa ser USUARIO, e nesta minha relação eu estou dizendo que  TODAS PESSOAS podem ser usuários.
Pela programação não seria dificil resolver meu problema.Usando JPA, ele insere em Clientes,depois pessoas e atravez de uma logica eu mando inserir em usuarios MANUALMENTE. Não sei se isto é correto.Utilizei o mesmo caso para resolver aquele caso da pessoa juridica e pessoa fisica utilizando join entre pessoas Ao invez de classe extendida por herança

Bom.Será que to fazendo correto?
Usuário esta na DER corretamente?
o MEU INSERT manualmente é correto? ou estou fugindo das regras do JTA?

Opa Andrei,

entendi o problema. Neste caso, é fácil de resolver. Basta que as pessoas do tipo Advogado ou Cliente possuam um atributo do tipo Usuario E que nas respectivas tabelas exista uma chave estrangeira para a tabela usuarios.

Com relação a heranças, minha sugestão é a seguinte: quanto menos herança, melhor.

É isto que vc ta falando?
Se for isto.Vai ter um problema....QUando inserir advogado adversos,obrigatoriamente o jpa por herança vai
dar um insert em advogados QUE obrigatoriamente vai precisar o idusuario para que o cadastro ocorra com sucesso.Bom.aguardo resposta.--<<é oq acho q vai ocorrer teoricamente.

Sim Andrei,

seria isto. No entanto, você pode fazer com que a referência a tabela usuarios seja opcional.Neste caso, a sua aplicação trataria disto, e não o banco de dados.

Se bem que você tem razão neste ponto. Talvez seja melhor manter como estava anteriormente, porém configurar o link com a tabela usuarios a partir da sua aplicação como lógica de negócios da mesma.

Ou então, você pode também tratar isto dentro do seu próprio banco de dados usando triggers por exemplo. Mas isto é apenas uma idéia.

Em relacao do problema la do sistema desktop usando ejb..Vc teria outra solução?O outro chamado atendido por vc.

Em relação este chamado..

Não posso criar trigger.Pois estou trabalhando em cima de 2 bancos.Mysql e Postgres.Usar uma trigger quebraria o padrão de criar regras de negócios no ejb e passaria a criar no banco, e assim quebraria a regra de MULTIBANCO que é abortado na minha apresentação.

Como informado precisaria de uma solução que apenas o cliente e advogado fosse usuário no sistema.
O esquema que te passei, até funciona.Porém esta abordagem não é legal.
O esquema que vc me passou até resolve, mas acaba dando problema na hora de inserção, pois minha classes advogados,advogadosadversos e até pessoas estao com herança.

Aguardo uma solução.Não é urgente isto.
O mais urgente é aquele do ejb desktop.Abraços

Oi Andrei,

com relação ao chamado sobre ejb, pedi à moderação que o transferisse para o Dyego, que possui muito mais experiência no assunto do que eu.

Com relação ao nosso problema aqui neste post, uma solução poderia ser você definir o método setUsuario da sua classe abstrata Usuario como abstrato também.

Assim, se uma classe pode ter um usuário relacionado, basta que você a implemente tal como no exemplo abaixo:

public void setUsuario(Usuario usr) {
   this.usuario = usr;
}

e caso não queira que determinado tipo de pessoa não tenha usuário, o definiria como

public void setUsuario(Usuario usr) {
      // nao faça nada
}

 
Nao entendi sua explicação.Vc  ta dizendo que Mantendo a abordagem do meu DER, devo criar minha classe usuario como abstrata
e sobrescrever meu metodo

public void setUsuario(Usuario usr) {
   this.usuario = usr;
}

para

public void setUsuario(Usuario usr) {
      // nao faça nada
}

 

?????????????????é isto? se sim vou precisar analisar e ver se funcionaria para meu caso...Porque mudar algo nas entidades pode ocasionar problemas nos meus SessionBean e manager beam das minhas telas..

Não não não! :)

Na realidade, pelo que pude entender, você possui uma classe básica chamada Pessoas, a partir da qual diversas outras são baseadas: Advogado, Cliente, etc.

Pelo que pude ver até agora, alguns subtipos da classe Pessoa apenas que podem ter um usuário relacionado. No entanto, nem todas o podem ter, e você não quer implementar por exemplo o atributo usuario em todos os tipos de Advogado, correto?

O que propus para você fazer foi o seguinte: esta classe (Pessoas), ser declarada como abstrata. E o método set responsável por definir o atributo usuario ser declarado como abstrato (setUsuario). Sendo assim, para cada tipo de pessoa você poderia definir uma lógica de negócio específica que define se aquele tipo em questão pode ou não possuir um usuário relacionado.

Não não não! :)
1>
Na realidade, pelo que pude entender, você possui uma classe básica chamada Pessoas, a partir da qual diversas outras são baseadas: Advogado, Cliente, etc.
2>
Pelo que pude ver até agora, alguns subtipos da classe Pessoa apenas que podem ter um usuário relacionado.
2.1>
No entanto, nem todas o podem ter, e você não quer implementar por exemplo o atributo usuario em todos os tipos de Advogado, correto?
3>
O que propus para você fazer foi o seguinte: esta classe (Pessoas), ser declarada como abstrata. E o método set responsável por definir o atributo usuario ser declarado como abstrato (setUsuario). Sendo assim, para cada tipo de pessoa você poderia definir uma lógica de negócio específica que define se aquele tipo em questão pode ou não possuir um usuário relacionado.


ANALISANDO
1>Sim.Tenho uma classe abstrata Pessoa e outras classes advogado,advogadocontraria,cliente,clienteContrario e todos sao herancas.ja informado como esta as classes.
2>Correto.Apenas Advogados e Clientes serao usuarios.Advogados contrarios e clientes contrarios jamais deve ser usuarios do sistema.
2.1>Quase isto.Apenas os advogados podem ser usuarios e os advogados adversos NAO PODEM
3>A classe pessoa j'a 'e abstrata,e vc ta falando para colocar o METODO SET USUARIO como abstrato?oq isto mudaria?E em relacao a esta logica de negocio que define se aquele tipo pode ou nao ser usuario como seria isto?


DEIXXA EU FALAR COMO ESTA MINHA REGRA DE INSERT EM MODIFICAR NADA ATE AGORA

Se inserir em advogado adverso, meu jta inseri em advogado e em pessoa automaticamente.Atravez de uma regra de insert eu verifico o check box se 'e fisica e juridica e do um insert manualmente em pessoa fisica ou pessoa juridica .E na tabela usuario meu inset na tabela usuario 'e ignorado.Veja que funciona....

Quando eu der em advogados, acontece a mesma coisa, mas 'e dado um insert em usuarios


BOM.esta 'e a explicacao..Eu nao estou entendendo sua solucao.Gostaria se pudesse agora passar um codigo exemplo aqui apenas para facilitar oq vc ta querendo me passar.abra'cos

Olá henrique.Poderia finalizar estas perguntas para que possamos finalizar este chamado?

Olá Andrei,

bom: famos lá. Com base no que você me explicou anteriormente, você não quer que seja registrado um usuário para qualquer tipo de pessoa, mas sim somente para Advogados e Clientes específicos do seu sistema, correto?

Neste caso, o que propus que você fizesse consiste em "enganar" o Hibernate sobrescrevendo o método setUsuario de todas as suas classes derivadas da classe Pessoa.

Sendo assim, seu código ficaria algo similar ao seguinte:

Classe Pessoa:

public abstract class Pessoa implements Serializable {

     protected Usuario usuario;
     public Usuario getUsuario() {
          return this.usuario;
     }


     /*
          Este é o pulo do gato:
          ao definir o método setUsuario como abstrato, e obrigar todas as classes descendentes a implementá-lo,
          você está obrigando as suas subclasses a implementar lógica de negócios dentro desta classe.
     */
     public abstract void setUsuario(Usuario usr);

   // restante da classe
}

Supondo agora que exista uma classe chamada AdvogadoParte, filha de Usuario, a sua implementação seria a seguinte:

public class AdvogadoParte extends Usuario {

          // Sou portanto obrigado a implementar o método setUsuario
          public void setUsuario(Usuario usr) {
                  // o método não faz coisa alguma, mantendo o atributo usuario como null
          }
}

Agora, vamos ver como seria a implementação da classe Advogado (que você quer que possua um usuário relacionado)

public class Advogado extends Usuario {
            // novamente, como extendo uma classe abstrata, e este método foi definido como abstrato na classe mãe...

           public void setUsuario(Usuario usr) {
                   this.usuario = usr; // aqui eu defino o valor do atributo usr sempre
           }
}

Com base na implementação destes métodos, o que você está fazendo aqui na realidade consiste em "enganar" o seu ORM, pois o funcionamento desta ferramenta é basicamente o descrito abaixo:

1. ORM "pensa": Tenho dados a serem salvos em uma classe. E esta possui um atributo chamada "usuario".
2. Defino o valor deste atributo a partir do método set relacionado. No caso, pela convenção Java beans, setUsuario
3. Vou passar para este método o valor que desejo

No passo 3, como o ORM não sabe que você está sobrescrevendo este método, ele o chamará de qualquer maneira, no caso, de acordo com a subclasse que você  estiver populando. Como esta subclasse está implementando alguma lógica de negócios dentro deste método (setUsuario), você pode então selecionar em quais casos uma subclasse de Pessoa pode ou não possuir um usuário relacionado.

Olá henrique.Não estou conseguindo captar oq vc esta me passando..Vou pedir um tempo para que possa analisar oq vc me passou e ver se poderei adaptar ao meu código.Como tenho outra dúvida, vou deixar este um pouco mais para frente e dar atençao para o outro..De qualquer forma acredito que já está quase resolvido,só falta eu dar uma mega lida com atenção para ver se consigo captar oq vc ta me passando>Grato

Ok Andrei,

precisando de qualquer coisa estou a disposição.

------------------------------------------------------------
OLA HENRIQUE.VAMOS RESOLVER ESTE PROBLEMA ASSIM LIBERO O CHAMADO.....

Antes,como informado, o problema daquele erro de inserção era o framework HIBERNATE.Após selecionar o toplink tundo funcionou legal.EU não sei o porq disto.Não sei porq com o hibernate não funcionou , e se vc souber a solução vc pode me dizer no outro chamado e assim eu aviso o administrador para colocar como RESOLVIDA.

Mas vamos resolver isto aqui então...

Veja as observações abaixo.Estou ainda tendo dificuldade para entender oq foi proposto..Poderia dar mais especificações?



------------------------------------------------------------------------------

Olá Andrei,

bom: famos lá. Com base no que você me explicou anteriormente, você não quer que seja registrado um usuário para qualquer tipo de pessoa, mas sim somente para Advogados e Clientes específicos do seu sistema, correto?

Neste caso, o que propus que você fizesse consiste em "enganar" o Hibernate sobrescrevendo o método setUsuario de todas as suas classes derivadas da classe Pessoa.

Sendo assim, seu código ficaria algo similar ao seguinte:

Classe Pessoa:

public abstract class Pessoa implements Serializable {

     protected Usuario usuario;
     public Usuario getUsuario() {
          return this.usuario;
     }

Nesta parte vc ta falando para eu colocar uma relação one to one entre pessoa e usuario?
 @OneToOne(cascade = CascadeType.ALL, mappedBy = "pessoas")
    private Usuarios usuarios; --<<< nesta parte devo colocar então PROTECT?


public Usuarios getUsuarios() {
        return usuarios; --<< aqui devo colocar this.Usuario?oq diferencia para o meu jeito?
    }

    public void setUsuarios(Usuarios usuarios) {
        this.usuarios = usuarios;
    }







     /*
          Este é o pulo do gato:
          ao definir o método setUsuario como abstrato, e obrigar todas as classes descendentes a implementá-lo,
          você está obrigando as suas subclasses a implementar lógica de negócios dentro desta classe.
     */
     public abstract void setUsuario(Usuario usr);
aqui vc ta falando para eu pegar meu metodo setUsuario acima e colocar ele como abstract?
   // restante da classe
}
------------------------PARTE DESCONSIDERADA POR NAO SER O MEU CASO------------------------
Supondo agora que exista uma classe chamada AdvogadoParte, filha de Usuario, a sua implementação seria a seguinte:

public class AdvogadoParte extends Usuario {

          // Sou portanto obrigado a implementar o método setUsuario
          public void setUsuario(Usuario usr) {
                  // o método não faz coisa alguma, mantendo o atributo usuario como null
          }
}
-----------------------------------------------------------------------------------
Agora, vamos ver como seria a implementação da classe Advogado (que você quer que possua um usuário relacionado)

VC acha melhor mesmo colocar a classe Advogado extendida de usuario?

public class Advogado extends Usuario {
            // novamente, como extendo uma classe abstrata, e este método foi definido como abstrato na classe mãe...

           public void setUsuario(Usuario usr) {
                   this.usuario = usr; // aqui eu defino o valor do atributo usr sempre
           }
}

Com base na implementação destes métodos, o que você está fazendo aqui na realidade consiste em "enganar" o seu ORM, pois o funcionamento desta ferramenta é basicamente o descrito abaixo:

1. ORM "pensa": Tenho dados a serem salvos em uma classe. E esta possui um atributo chamada "usuario".
2. Defino o valor deste atributo a partir do método set relacionado. No caso, pela convenção Java beans, setUsuario
3. Vou passar para este método o valor que desejo

No passo 3, como o ORM não sabe que você está sobrescrevendo este método, ele o chamará de qualquer maneira, no caso, de acordo com a subclasse que você  estiver populando. Como esta subclasse está implementando alguma lógica de negócios dentro deste método (setUsuario), você pode então selecionar em quais casos uma subclasse de Pessoa pode ou não possuir um usuário relacionado.