Ajuda-me a ligar conceitos de herança e relacionais

votos
7

Eu estava conversando com um amigo programador meu sobre herança e seu uso na elaboração de modelos. Ele é um grande defensor e eu sou um pouco mais morna. Principalmente porque eu tendem a projetar sistemas de baixo para cima: Banco de Dados -> Aplicativos -> Apresentação (honestamente, eu não sou muito de um cara front-end, então eu muitas vezes deixam apresentação inteiramente a outra pessoa). Acho que os sistemas de banco de dados relacional não suporta herança sem um monte de 1-a-1 relacionamentos com outras tabelas.

Se eu estou projetando a partir de um ponto de vista conceitual, um administrador é um usuário é uma pessoa. A partir do banco de dados para cima, um administrador é um usuário com UserType = Administrador. Conciliar essas abordagens parece difícil para mim, e, portanto, eu só usar a herança com objetos não persistiu.

O que há de errado com o meu pensamento? Porque é que a herança um aspecto tão freqüentemente célebre de OO se ele tem essas incompatibilidades inerentes com estruturas relacionais tradicionais? Ou, é-me que não está mapeando herança corretamente para dados relacionais? Existe alguma orientação lá fora, que pode esclarecer isso para mim?

Desculpem a pergunta e graças divagar antecipadamente por suas respostas. Se você incluir o código em sua resposta, C # é a minha língua nativa.

Publicado 26/08/2009 em 22:59
fonte usuário
Em outras línguas...                            


11 respostas

votos
5

Este tem sido popularmente chamado de diferença de impedância objeto-relacional :

Herança esquema - A maioria dos bancos de dados relacionais não suportam herança esquema. Embora uma característica tal poderia ser adicionado em teoria reduzir o conflito com OOP, os proponentes relacionais são menos propensos a acreditar no utilitário de taxionomias hierárquicos e sub-tipagem porque eles tendem a exibir taxionomias baseada em conjunto ou sistemas de classificação quanto mais potente e flexível do que as árvores. OO defende salientar que os modelos de herança / subtipagem não precisa ser limitado a árvores (embora esta é uma limitação em muitas linguagens OO populares como Java), mas as soluções OO não-árvore são vistos como mais difícil a formulação de variation- baseada em conjunto on-a-theme técnicas de gestão preferido por relacional. No mínimo, elas diferem das técnicas comumente usadas em álgebra relacional.

Veja também: Agile dados , C2 Wiki

Respondeu 26/08/2009 em 23:06
fonte usuário

votos
3

Eu diria que o modelo de herança na questão é falho. É muito literal, ou baseado no mundo real. Sim, pode-se argumentar que eu sou um administrador no mundo real e, portanto, um administrador é uma Pessoa. No entanto, o projeto de objetos e herança deve ser baseada mais fora de comportamentos expressos e compartilhados no espaço de código. Eu iria mais a rota que um usuário tem um papel. Administrador é um papel, ou um uma instância de uma função definida para um determinado estado. Um usuário não é uma pessoa (o seu trabalho em lotes pode precisar de uma conta de usuário, por exemplo).

Eu recomendo a leitura Pensamento objeto por David West para uma boa introdução ao objeto de design. Ele não cobre o Incompatibilidade de relação de objeto no entanto, mas as pessoas já deram muitos links para recursos sobre o assunto.

Respondeu 26/08/2009 em 23:27
fonte usuário

votos
3

O abismo entre o paradigma relacional e o paradigma OO é frequentemente discutido.

Basicamente, para fornecer um mapeamento entre RDBMS e OO, é necessário sacrificar algumas capacidades de ambos os sistemas. Você tem que decidir de que lado o seu compromisso é mais fortemente ponderada direção.

Ambos os paradigmas são muito poderosas e úteis. Mas tentando mapear entre eles perfeitamente é um problema não resolvido.

Respondeu 26/08/2009 em 23:10
fonte usuário

votos
3

Você deve ler os padrões de arquitetura de aplicações corporativas . Ela vai mostrar como os padrões de herança pode e deve ser expresso estruturas relacionais.

A coisa importante a lembrar é a herança é coisa modelagem conceitual. estruturas relacionais e código OO são apenas materializações desses modelos conceituais, e não deve ser considerado o princípio eo fim de tudo da orientação a objetos.

Há um tutorial sobre este tipo de coisa aqui.

Respondeu 26/08/2009 em 23:08
fonte usuário

votos
1

Porque é que a herança um aspecto tão freqüentemente célebre de OO se ele tem essas incompatibilidades inerentes com estruturas relacionais tradicionais?

Esta é uma citação curiosa - por que você diz que as estruturas relacionais são "tradicional"? Eles são a norma em um RDBMS, por natureza, mas eu vi muito poucas bibliotecas relacionais no contexto de uma linguagem não-DB.

A razão OO é popular é porque ele foi uma melhoria significativa em relação ao modelo processual dominante. Usando herança, código poderia ser feita mais confiável (através do tipo de controlo), mais facilmente modificáveis (por meio de especializações método) e mais testável (através fácil primordial de comportamentos). Em comparação com um modelo processual, OO é muito mais fácil desenvolver software de alta qualidade com.

Há, é claro, dificuldade de mapeamento entre o OO e modelos relacionais. Isso é chamado de "incompatibilidade objeto-relacional", e foi nomeado "o Vietnam da ciência da computação" . Existem várias estratégias para armazenar dados OO em um banco de dados relacional, mas nenhum é perfeito - o mais popular no uso moderno são estruturas com base no Active Record .

Respondeu 26/08/2009 em 23:11
fonte usuário

votos
1

Existem vários tipos de herança. Os desenvolvedores podem pensar em termos de interfaces e comportamento.

Em seu mundo, o que significa ter um um "userType" do administrador?

A semântica você mnight ser implicando são de que algum código em algum lugar vê que userType e autoriza ações para os usuários com esse tipo. Então, talvez, um administrador pode criar outros usuários?

No caso em que um desenvolvedor pode ter uma classe de usuário

class User() { viewData(){ ...} ; signReport() {...} }

e uma Adminstrator classe com uma capacidade adicional

class Administrator()  extends User {  createUser() {...}; approvePurchase() {...} }

Um objeto do tipo Administrator pode ser usado em todos os lugares que um usuário pode. Este comportamento polimórfico pode ser útil quando implmenting. Agora, o seu banco de dados suporta bastante plausível nesse caso. No entanto o que você vai fazer quando administradores precisam apenas um pouco de dados extra bits para realizar a sua tarefa específica? Por exemplo, purchaseApproval () é até um certo limite, precisamos esse limite como um novo campo, mas ele só se aplica a administradores.

Eu acredito que os aspectos comportamentais implícitos por seu conceito de "tipo" muitas vezes são associados com dados extra.

Respondeu 26/08/2009 em 23:06
fonte usuário

votos
1

Há muitas maneiras de expressar esse tipo de relacionamento em C #. Bancos de dados relacionais são simplesmente mais limitada (que pode ser uma vantagem, bem como um inconveniente). Quando você está projetando uma hierarquia de objeto que vai ser mantido em um banco de dados, eu acho que é geralmente mais fácil começar com um esquema de banco de dados em primeiro lugar, uma vez que praticamente qualquer esquema de banco de dados pode ser facilmente mapeada para objeto relacionamentos, enquanto o oposto não é necessariamente O caso.

Neste caso particular, você pode modelar o Administrador com composição. Sua mesa Administradores iria fornecer qualquer estado administrador adicional além da chave do usuário apropriado. Usuários FK também seria o seu Administradores PK.

Respondeu 26/08/2009 em 23:06
fonte usuário

votos
0

Hibernação simplifica herança. Exemplo

Respondeu 27/08/2009 em 01:32
fonte usuário

votos
0

O seu exemplo específico de um Admininstrator ser um usuário com um UserType de "Administrador" é um excelente exemplo da "Single Table Inheritance" padrão. Isso é implementado em alguns dos principais ORMs lá fora. Particularmente "Rails ActiveRecord" e Hibernate.

Respondeu 26/08/2009 em 23:16
fonte usuário

votos
0

esquemas de banco de dados relacionais normalizados realmente não apoiar polimorfismo menos que você vá fora do que são geralmente consideradas como as "melhores práticas" no mundo da DBA. Isto não é uma questão nova, por qualquer meio eo próprio problema foi resolvido mil vezes de várias maneiras diferentes.

A verdadeira questão vem no lugar quando você começar a trabalhar com os dados - se você estiver trabalhando com conjuntos de dados, você vai continuar a ter desafios tentando implementar qualquer tipo de polimorfismo. Se, no entanto você está mapeando um conjunto de entidades de domínio para o seu modelo relacional, você vai descobrir que há muitas ferramentas para ajudá-lo a superar as limitações do esquema de banco de dados relacional.

Desde que você é um desenvolvedor C #, você provavelmente deve começar por olhar para os 2 projectos seguintes, uma das quais vem com o serviço .NET pack mais recente.

ADO.NET Entity Framework:

http://msdn.microsoft.com/en-us/library/bb386876.aspx

NHibernate:

http://nhforge.org/Default.aspx

Respondeu 26/08/2009 em 23:13
fonte usuário

votos
0

Sim, herança não é provavelmente a ferramenta certa quando você está mapeando de e para o banco de dados.

A herança é muito mais útil quando a construção de estruturas, onde você tem diferentes tipos de objetos que se comportam de forma diferente, mas ainda assim eles têm peças em comum.

Por exemplo, você poderia ter diferentes "mensagens" transmitidas entre um servidor e outro. Cada mensagem tem sua própria lógica, então você precisa classes diferentes (para evitar uma declaração enorme switch ()), mas há partes comuns, como o fato de que cada mensagem precisa saber como serializar / desserializar-se em um fluxo (que é um método de todas as subclasses de mensagem deve substituir). Além disso, com todas as mensagens herdar mensagem vai deixar você tem uma lista, e ir um por um e chamar seu método Serialize, por exemplo.

Mas se tudo que você está fazendo é típico de negócios / lógica DB, herança provavelmente irá ficar no seu caminho.

Respondeu 26/08/2009 em 23:11
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more