Desenho de entidades de domínio

Assuntos Gerais Agile
#1

Desculpem se estou tentando abrir um assunto que já tenha sido muito discutido e eu não saiba. Se esse for o caso, peço que uma alma caridosa me indique o link para a discussão, pois preciso muito estudar isso, urgente.

No meu ponto de vista esse é um assunto muito relevante para quem vai desenvolver um sistema, seja ele qual for. Quero falar sobre a estratégia utilizada para se criar entidades em um modelo de domínio. Pelo que eu saiba, salvo grotesco engano, devemos trabalhar para tirar o máximo de proveito dos recursos de OO para fazer com que as entidades representem o domínio do negócio de forma mais próxima da realidade possível. Pois bem, caso eu esteja enganado, peço que alguém me corrija. Mas se isso representa a verdade, vou apresentar o seguinte senário, onde tenho entidade Systemuser, que representa um usuário do sistema e tenho as entidades Employee, Customer e Vendor. No meu entendimento, todos essas entidades estenderiam direta ou indiretamente de uma entidade Person, pois no mundo real elas representam a entidade (pessoa), apenas com caracterísitcas a mais. Por exemplo, um cliente e um fornecedor são pessoas. O funcionário também, mas podemos considerar que o usuário do sistema, por sua vez, é um funcionário.

Acredito que nessas situações mencionadas acima, a herança representaria muito melhor o mundo real do que o encapsulamento e convido os amigos a pensarem comigo. É diferente dizer que um funcionário é uma pessoa e dizer que um carro tem um motor. O encapsulamento representa muito melhor o segundo cenário.

Quando a chave primária de uma tabela é uma chave estrangeira apontada para a chave primária de outra tabela, entende-se automaticamente que uma entidade é uma extensão da outra. E não consigo imaginar diferente, a menos que haja uma mudança de conseito que eu não esteja entendendo.

Todavia, ferramentas IDE de criação automática de entidades através de JPA, como Netbeans ou Eclipse, quando solicitado para gerar entidades automaticamente com base em um banco já existente, o mesmo não cria as entidades extendendo uma das outras. Ele cria como objetos encapsulados em atributos. Alguém saberia dizer porque?

E se meu raciocínio está errado, alguém poderia me ajudar a ver isso?

Grato.

#2

Boa noite,

Simplesmente ferramentas de engenharia reversa não conseguem criar heranças pois isso na está representando dessa forma no banco de dados já que isso não existe para o mesmo. O que as ferramentas poderiam fazer é permitir que usuário interagisse no momento da importação e permitisse informar as possíveis heranças.

Edson Martins

#3

Pois eh Edson. Eu imagino que seria isso também… Acho que isso deveria estar nas ferramentas porque imagino que pelo menos em 90% dos casos em que uma tabela tenha como sua chave primária uma chave estrangeira importada da chave primária de uma outra tabela, ela será extendida desta tabela… Não consigo imaginar outra hipotese. Então a ferramenta deveria detectar isso e dar essa opção para você escolher no momento da importação. Mas na minha visão isso é muito óbvio! Vc saberia dizer porque isso não está implementado? Ou se está, onde está?

#4

Porque ferramentas ORM foram feitas para outra coisa, gerar as tabelas automaticamente baseado no modelo de objetos.

#5

Mas desde que ela se propõe a fazer o inverso, deveria fazer de forma mais coerente, eu acho… Poderia ao menos dar opção no momento da importação para você interagir e indicar que no lugar de encapsular, você quer herança. Eu não vejo de outra forma. Uma tabela cuja sua PK é FK da PK de outra tabela… Não vejo outra alternativa coerente a não ser herança. Neste formato, desde que o banco esteja bem modelado, digo, seria até um desafio encontrar uma situação que não represente uma herança. Se alguém souber seria legal chutar a bola pra gente!

#6

[quote=MWAdriano]Mas desde que ela se propõe a fazer o inverso, deveria fazer de forma mais coerente, eu acho… Poderia ao menos dar opção no momento da importação para você interagir e indicar que no lugar de encapsular, você quer herança. Eu não vejo de outra forma. Uma tabela cuja sua PK é FK da PK de outra tabela… Não vejo outra alternativa coerente a não ser herança. Neste formato, desde que o banco esteja bem modelado, digo, seria até um desafio encontrar uma situação que não represente uma herança. Se alguém souber seria legal chutar a bola pra gente!
[/quote]

Sinceramente, nunca vi uma situação onde a chave primária de uma tabela é uma chave estrangeira apontada para a chave primária de outra tabela, nem acho que isso seja considerado boa modelagem relacional.

#7

[quote=MWAdriano]Mas desde que ela se propõe a fazer o inverso, deveria fazer de forma mais coerente, eu acho… Poderia ao menos dar opção no momento da importação para você interagir e indicar que no lugar de encapsular, você quer herança. Eu não vejo de outra forma. Uma tabela cuja sua PK é FK da PK de outra tabela… Não vejo outra alternativa coerente a não ser herança. Neste formato, desde que o banco esteja bem modelado, digo, seria até um desafio encontrar uma situação que não represente uma herança. Se alguém souber seria legal chutar a bola pra gente!
[/quote]

Muitas relacionamentos NxN não entram nesse caso?

Por exemplo: uma tabela Aluno, uma tabela Professor e a tabela Aluno_Professor de relacionamento.

Sem falar que isso ocorre em muitos casos de chave composta:

Por exemplo: tabela Pessoa, tabela Endereco, onde a pk de endereço é um sequencial + id da pessoa

Nestas situações não vejo que há herança.

#8

[quote=AbelBueno][quote=MWAdriano]Mas desde que ela se propõe a fazer o inverso, deveria fazer de forma mais coerente, eu acho… Poderia ao menos dar opção no momento da importação para você interagir e indicar que no lugar de encapsular, você quer herança. Eu não vejo de outra forma. Uma tabela cuja sua PK é FK da PK de outra tabela… Não vejo outra alternativa coerente a não ser herança. Neste formato, desde que o banco esteja bem modelado, digo, seria até um desafio encontrar uma situação que não represente uma herança. Se alguém souber seria legal chutar a bola pra gente!
[/quote]

Muitas relacionamentos NxN não entram nesse caso?

Por exemplo: uma tabela Aluno, uma tabela Professor e a tabela Aluno_Professor de relacionamento.

Sem falar que isso ocorre em muitos casos de chave composta:

Por exemplo: tabela Pessoa, tabela Endereco, onde a pk de endereço é um sequencial + id da pessoa

Nestas situações não vejo que há herança.

[/quote]

Abel, não se trata do mesmo caso! Pense bem: Na tabela Aluno_Professor, a PK é composta por 2 (duas) colunas (AlunoId e ProfessorId). Não é a mesma chave de nenhuma das outras tabelas. No caso da tabela Aluno a PK seria composta da coluna AlunoId (uma hipotese) e no caso da tabela Professor a PK seria composta pela coluna ProfessorId.

O segundo caso que você passou, no caso de endereço, Endereço tem em como parte de sua PK a coluna PessoaId. Mas não sua PK não é a mesma da tabela Pessoa, apenas é composta por uma FK que é PK da tabela pessoa. É diferente.

A herança só é identificada quando há uma relação de chaves PK-FK-PK direta. Ambas as PKs tem que serem chaves compatíveis e uma tem que ser FK da outra. Assim, não há erro para identificar uma herança.

Que achas?

[]s.

#9

[quote=moscoso.dev][quote=MWAdriano]Mas desde que ela se propõe a fazer o inverso, deveria fazer de forma mais coerente, eu acho… Poderia ao menos dar opção no momento da importação para você interagir e indicar que no lugar de encapsular, você quer herança. Eu não vejo de outra forma. Uma tabela cuja sua PK é FK da PK de outra tabela… Não vejo outra alternativa coerente a não ser herança. Neste formato, desde que o banco esteja bem modelado, digo, seria até um desafio encontrar uma situação que não represente uma herança. Se alguém souber seria legal chutar a bola pra gente!
[/quote]

Sinceramente, nunca vi uma situação onde a chave primária de uma tabela é uma chave estrangeira apontada para a chave primária de outra tabela, nem acho que isso seja considerado boa modelagem relacional.[/quote]

E como você modelaria um caso onde você tem Funcionários, Clientes, Fornecedores e Pessoas ? Cada um teria uma PK diferente? Você acha que isso seria uma boa abordagem para representar o mundo real ?

[]s.

#10

[quote=MWAdriano]Abel, não se trata do mesmo caso! Pense bem: Na tabela Aluno_Professor, a PK é composta por 2 (duas) colunas (AlunoId e ProfessorId). Não é a mesma chave de nenhuma das outras tabelas. No caso da tabela Aluno a PK seria composta da coluna AlunoId (uma hipotese) e no caso da tabela Professor a PK seria composta pela coluna ProfessorId.

O segundo caso que você passou, no caso de endereço, Endereço tem em como parte de sua PK a coluna PessoaId. Mas não sua PK não é a mesma da tabela Pessoa, apenas é composta por uma FK que é PK da tabela pessoa. É diferente.

A herança só é identificada quando há uma relação de chaves PK-FK-PK direta. Ambas as PKs tem que serem chaves compatíveis e uma tem que ser FK da outra. Assim, não há erro para identificar uma herança.

Que achas?

[]s.[/quote]

Ah, me desculpe…agora entendi o que você quis dizer.

Tem razão, nesta condição imagino que o relacionamento pode representar herança.

Porém, ainda assim, há situações onde isto pode falhar.

Já vi casos em que uma tabela é quebrada em mais de uma, para agrupar dados relacionados.

Por exemplo, uma tabela de pessoa pode ser quebrada em DadosPessoais, DadosMedicos, DadosProfissao e assim por diante…
Neste caso seria um caso de composição e não herança… (aliás…muitas vezes herança é um caso de composição)

#11

[quote=AbelBueno][quote=MWAdriano]Abel, não se trata do mesmo caso! Pense bem: Na tabela Aluno_Professor, a PK é composta por 2 (duas) colunas (AlunoId e ProfessorId). Não é a mesma chave de nenhuma das outras tabelas. No caso da tabela Aluno a PK seria composta da coluna AlunoId (uma hipotese) e no caso da tabela Professor a PK seria composta pela coluna ProfessorId.

O segundo caso que você passou, no caso de endereço, Endereço tem em como parte de sua PK a coluna PessoaId. Mas não sua PK não é a mesma da tabela Pessoa, apenas é composta por uma FK que é PK da tabela pessoa. É diferente.

A herança só é identificada quando há uma relação de chaves PK-FK-PK direta. Ambas as PKs tem que serem chaves compatíveis e uma tem que ser FK da outra. Assim, não há erro para identificar uma herança.

Que achas?

[]s.[/quote]

Ah, me desculpe…agora entendi o que você quis dizer.

Tem razão, nesta condição imagino que o relacionamento pode representar herança.

Porém, ainda assim, há situações onde isto pode falhar.

Já vi casos em que uma tabela é quebrada em mais de uma, para agrupar dados relacionados.

Por exemplo, uma tabela de pessoa pode ser quebrada em DadosPessoais, DadosMedicos, DadosProfissao e assim por diante…
Neste caso seria um caso de composição e não herança… (aliás…muitas vezes herança é um caso de composição)
[/quote]

Bom, eu acho que nesse caso há falta de normalização. Daí, sim, uma questão de estratégia de modelagem. Posso imaginar alguns motivos que levaria alguém a modelar assim, mas não considero o ideal, nem de longe.

Remetendo-me as aulinhas de DER e MER ainda em 94, a normalização extrema do domínio “seria” o melhor dos mundos para representar o mundo real em um modelo relacional, não fosse a limitação do hardware para conseguir tocar grandes bases em SGDBs. Mas lembrando denovo, essa limitação existia em 94, quando eu usava um 486DX 50Mhz com 8MB de RAM para tocar Windows 3.1 Será que essa limitação ainda é preocupação hoje ?? Acho que não… :wink:

[]s.

#12

[quote=MWAdriano][quote=AbelBueno][quote=MWAdriano]Abel, não se trata do mesmo caso! Pense bem: Na tabela Aluno_Professor, a PK é composta por 2 (duas) colunas (AlunoId e ProfessorId). Não é a mesma chave de nenhuma das outras tabelas. No caso da tabela Aluno a PK seria composta da coluna AlunoId (uma hipotese) e no caso da tabela Professor a PK seria composta pela coluna ProfessorId.

O segundo caso que você passou, no caso de endereço, Endereço tem em como parte de sua PK a coluna PessoaId. Mas não sua PK não é a mesma da tabela Pessoa, apenas é composta por uma FK que é PK da tabela pessoa. É diferente.

A herança só é identificada quando há uma relação de chaves PK-FK-PK direta. Ambas as PKs tem que serem chaves compatíveis e uma tem que ser FK da outra. Assim, não há erro para identificar uma herança.

Que achas?

[]s.[/quote]
Ah, me desculpe…agora entendi o que você quis dizer.

Tem razão, nesta condição imagino que o relacionamento pode representar herança.

Porém, ainda assim, há situações onde isto pode falhar.

Já vi casos em que uma tabela é quebrada em mais de uma, para agrupar dados relacionados.

Por exemplo, uma tabela de pessoa pode ser quebrada em DadosPessoais, DadosMedicos, DadosProfissao e assim por diante…
Neste caso seria um caso de composição e não herança… (aliás…muitas vezes herança é um caso de composição)
[/quote]

Bom, eu acho que nesse caso há falta de normalização. Daí, sim, uma questão de estratégia de modelagem. Posso imaginar alguns motivos que levaria alguém a modelar assim, mas não considero o ideal, nem de longe.

Remetendo-me as aulinhas de DER e MER ainda em 94, a normalização extrema do domínio “seria” o melhor dos mundos para representar o mundo real em um modelo relacional, não fosse a limitação do hardware para conseguir tocar grandes bases em SGDBs. Mas lembrando denovo, essa limitação existia em 94, quando eu usava um 486DX 50Mhz com 8MB de RAM para tocar Windows 3.1 Será que essa limitação ainda é preocupação hoje ?? Acho que não… :wink:

[]s.[/quote]

Nao vejo porque a ideia do Abel fere a normalizacao. Implementar tudo numa tabela enorme é que fere.

O caso que voce descreveu eh uma forma comum de implementacao de relacionamento um-para-um, muito mais comum do que heranca quando se trata do modelo relacional.

#13

O que você entende por normalizar o modelo relacional? Implementar tudo em uma tabela gigante realmente não é adequado, e eu não sugeri isso em momento algum. Sugeri a a normalização do modelo relacional e isso pressupõe entender o problema e dividir em entidades diferentes, implementando-o mais próximo do mundo real. O Modelo-Entidade-Relacionamento pressupõe desenhar como as entidades se relacionam, e isso pode ser quebrado aprofundando o problema e não simplesmente quebrando uma mesma tabela em três partes. Dados pessoais, você pode ter cada dado quebrado e relacionado com a pessoa, assim como dados médicos ou profissionais, em vez de uma tabela com tudo dentro ligada a outra tabela. Quando você para para reunir muitos dados em uma tabela você está limitando a normalização. Eu sugeri justamente o contrário disso.

Muita gente reclama sobre as limitações do modelo relacional, mas acho que se a gente procurar entender melhor o que propõe, vai perceber que existe possibilidade de implementar quase tudo que se pode fazer em um modelo OO. Só dá mais trabalho por não ter ferramentas prontas, e é isso que eu estou propondo.

[]s.

#14