Se você encarar que um sócio é uma pessoa física você desenvolver algo do tipo:
public class Pessoa {//atributos e comportamentos}
public class PessoaFisica extends Pessoa {//atributos e comportamentos}
public class Socio extends PessoaFisica {//atributos e comportamentos}
No banco de dados seria algo assim:
create table pessoa { integer pessoa_key primary key, varchar(50) nome, etc… }
create table pessoa_fisica { integer pessoa_key primary key references pessoa(pessoa_key), number(12) cpf, etc… }
create table socio { integer pessoa_key primary key references pessoa_fisica(pessoa_key), number(4,2) participacao, etc… }
note que a chave primária de pessoa_fisica é a mesma de pessoa com um foreing key para a pessoa (indica que pessoa_fisica “é uma” pessoa, a chave primária de socio é a mesma de pessoa_fisica, indica que socio “é uma” pessoa física).
Você poderia ter um método no SocioDao, por exemplo, listarSocios em que você retornaria um lista de Socios com todos os dados de pessoa, pessoa_fisica e socio, algo do tipo
select *
from pessoa p
inner join pessoa_fisica pf on (p.pessoa_key = pf.pessoa_key)
inner join socio s on (s.pessoa_key = pf.pessoa_key)
para cada registro retornado popularia-se um objeto socio e adicionaria-se em uma lista (java.util.List), assim você teria uma lista com todos os Sócios, essa não é a única abordagem para esse problema, alguma pessoas prefeririam encarar que sócio é um papel que uma pessoa desenpenha e não que sócio é uma pessoa, e então utilizaria outra forma resolver isso… Essa é abordagem da UML em cores por exemplo, vale dar uma olhada. Pesquise por UML em Cores, de Peter Coad…
Espero ter ajudado um pouco…
Abraço,
André Faria