Modelagem de dados - entrem ... boa thread!

Programação Arquitetura
#1

Boa noite senhores,

Modelando um sistema de pedidos, envolvendo “compra” de serviços, me deparei com uma situação inusitada ao mapear os meus objetos no hibernate …

o contexto é o seguinte.

Eventualmente, fui designado para criar um sistema de pedidos … porém os itens inclusos no pedido não são do tipo material, são serviços, que o cliente contrata. Portanto, o cliente pode ter um pedido com a seguinte composição:

Pedido 1:
40 horas de planejamento / R$ 1.000,00;
10 horas de criação / R$ 500,00;
20 horas de desenvolvimento / R$ 200,00;

e etc.

De acordo com as informações acima, pensei em 3 entidades:

Pedido

  • pedidoID (PK)
  • clienteID (FK)
  • autorID (FK)
  • data

ServiçosPedido

  • pedidoID (FK)
  • serviçoID (FK)
  • preço
  • horas

Serviços

  • serviçoID (PK)
  • descrição

Esta modelagem atende … porém, na hora de mapear os objetos, eu me perdi !
Criei a classe Order (sempre em ingles - padrão da empresa), a classe Service, mas não sei como representar essa relação na modelagem das classes …

alguem pode me ajudar ?

Grato
Filipe

#2

Peraí…
Usando essas 3 entidades, você tem relacionamento muitos-para-muitos entre pedidos e serviços. É isso que você quer? Estranho. De acordo com esse Pedido 1 que você postou, UM pedido tem VÁRIOS serviços, mas cada serviço só pertence a UM pedido. Nesse caso, você não teria três, e sim, duas entidades.
Ou seja:

[code]public class Order {
private List<Service> services;
}

public class Service {
// Opcional: referência para a ordem de serviço (mais difícil de manter)
private Order order;
}[/code]Outra coisa: use um framework de persistência (por exemplo, Hibernate) e modele seu sistema através de classes Java. Deixe o framework gerar o banco para você.
Abraços

#3

Cara, primeira coisa…
Se vamos falar de OO, esqueça essas pk fk ou qualquer coisa dessas.

Pense em objetos, lembre-se disso sempre…

Pense em cada objeto, como eles se relacionam e o comportamento de cada um.

Abstraia banco de dados…
Depois em um segundo momento você se preocupa com isso.

#4

Ok, jah deu para clarear um pouco …

Pensando em objetos, eu teria um pedido que contem uma listagem de serviços.

Então, teríamos 2 classes, a classe Pedido e a classe Serviço.

Um serviço possui atributos “fixos”, porem um serviço em um pedido pode possuir caracteristicas mutáveis, variáveis. (ficou dificil ?)

Tipo, como eu vou conseguir representar a seguinte situação em OO:

[code]Pedido
ID | Data | AuthorID | Descrição
1 23/10/2007 1 Pedido Teste

PedidoServiços
PedidoID | ServiçoID | Horas | Preço
1 1 100 5000,00

Serviços
ServiçoID | Descrição
1 Criação de HTML
[/code]
Tipo, como havia informado anteriormente, teriamos então uma classe Pedido, e uma classe Serviço.

Abaixo, a classe pedido:

public class Pedido
{
       private int id;
       private IList&lt;Servico&gt; servicos ;
}

public class Servico
{
       private int id;
       private string descricao;       
}

Aonde eu colocaria os atributos preço e horas !?
Precisarei criar mais uma classe para representar essa associação ?

Nesse caso eu tenho mesmo uma relação de muitos pra muitos, um serviço pode aparecer em vários pedidos, assim como um pedido pode conter vários serviços

Toda essa bosta, pq o banco de dados é relacional …

Obrigado desde jah !

abraços

#5

Caros,

A solução que tomei foi a seguinte, criei 3 classes:

ItemType

  • id
  • description

ProposalItem

  • id
  • Proposal
  • ItemType

Proposal

  • id
  • IList<ProposalItem> items

oque acham ?

#6

OK, entendi. Ao meu ver, sua última solução está boa.

Bom, isso não implica em complicar as coisas. Se você está programando orientado a OBJETOS, não faça o banco primeiro. O ideal é você modelar as suas classes, esquecendo da persistência por um momento (como se tudo estivesse na memória), e usar uma ferramenta ORM (Hibernate, por exemplo) para gerar o banco pra você a partir das classes do seu modelo.

E uma última coisa: não é recomendável, no caso do Java, usar a letra I para iniciar nomes de interfaces.

#7