Duvida em um relacionamento de tabelas [RESOLVIDO]

paulocamboim
(usa Slackware)

Enviado em 03/09/2009 - 23:35h

Ola pessoal,

Estou fazendo um pequeno projeto onde tenho algumas tabelas que compartilham algumas informacoes. Segue minhas tabelas:

usuario = o usuario cadastrado pode acessar uma area restrita. Para isso deve ser cadastrado com varios dados: login, senha, email, endereco, cep, cidade ...

cliente = O usuario uma vez logado, podera cadastrar diversos clientes. Que por sua vez tera alguns campos: nome, email, endereco, cep, cidade ...


Da pra observar que tanto cliente e usuario tem os mesmos campos (endereco, cep, cidade).

Como eu faria para utilizar uma terceira tabela apenas com os dados de endereco e fazer o relaciomento?

Porque na tabela de "endereco" eu teria que fornecer o id_usuario ou o id_cliente, dependendo para qual tabela o dado se refere ...

obrigado
Paulo

juliofsn
(usa Fedora)

Enviado em 04/09/2009 - 10:55h

Melhor nesse seu caso, seria ter o id_endereco nas tabelas cliente e usuario.

Recomendo você ler sobre normalização: http://pt.wikipedia.org/wiki/Banco_de_dados_relacional#Normaliza.C3.A7.C3.A3o

paulocamboim
(usa Slackware)

Enviado em 06/09/2009 - 15:55h

Ola Julio, obrigado pela resposta.

Nessa caso eu teria um problema,

"usuario" poderia apenas ter um endereco, mas ja a tabela "cliente" poderia ter N enderecos...

gedalinux
(usa Slackware)

Enviado em 08/09/2009 - 22:54h

A analise dos dados lava-nos a devaneios, rsrsr....

A Solucao para algo assim é separar cada entidade individualmente e interpretá-las, afinal no mundo real cada uma delas vive individualmente, isto é, elas não dependem exatamente umas das outras. Logo voce terá tres tabelas

Usuario
Cliente
Endereco

em seguida vc percebe que o mundo não é perfeito e um usuario poderia ser ao mesmo tempo apenas um cliente, ou um vendedor ou este ainda poderia ser alguém que acessa os dados em diferentes niveis, daí a melhor maneira é partir pro devaneio, também conhecido por abstraçao de dados, agora surgem novas entidades no seu plano. Afinal todos os individuos são pessoas e portanto os dados sobre usuarios são na verdade melhorias de informações sobre pessoas, vulgamente conhecida por especialização.
então teriamos agora a tabela pessoas. Na pratica gosto de nome de tabelas sempre no plural para indicar que tenho coleções de dados, uma mania OOP.

Um dos grandes problemas na ER é que não temos o comportamento, mas felizmente podemos representar tal comportamento na forma de relacioamento de dados e obvio se CLIENTE "É UMA" PESSOA e USUARIO "É UMA" e VENDEDOR "É UMA" PESSOA nada mais justo representa tal relacionamento na forma mais tradicional de um SGBD mais uma tabela
algo como :

PESSOA_ENDERECOS

contendo dois campos apenas

id_pessoa e id_endereco

sendo que estes campos são pk e fk respectivamente
PK na tabela local e FK de PESSOA e ENDERECOS

agora tudo seria quatro tabelas, EX:

NOME _____ PK _____ FK

PESSOA = ID_PESSOA
CLIENTE = ID_PESSOA _____ ID_PESSOA DE PESSOA
USUARIO = ID_PESSOA _____ ID_PESSOA DE PESSOA

ENDERECOS= ID_ENDERECO

PESSOAS_ENDERECOS = ID_PESSOA _____ ID_PESSOA DE PESSOA
ID_ENDERECO ID_ENDERECO DE ENDERECOS


E portanto pode-se ter um usuario morando em varios lugares.
Filho de pais separados e que mora com os avós e sem duplicata de
enderecos em usuarios
nem em clientes
nem em funcionarios
nem em alunos
nem em professores

tudo por causa da abstracao de dados (generalizacao)...

isto é como penso....
claro no mundo computacao somos livres para agir
se arrepender e refatorar sempre.....


lamento pela formatação mas isso é cois VOL

VIVA O SOFTWARE LIVRE
VIA O CONHECIMENTO E O LIVRE ARBÍTRIO


QUE DEUS TE GUIE

CONHECEREIS A VERDADE E ELA VOS LIBERTARÁ

paulocamboim
(usa Slackware)

Enviado em 12/09/2009 - 01:54h

Obrigado pela resposta :)