 |
ActiveDelphi
.: O site do programador Delphi! :.
|
| Exibir mensagem anterior :: Exibir próxima mensagem |
| Uma tabela para cada cadastro ou tabela única para todos (Cliente, Funcionário e Fornecedor)? |
| Primeira Opção |
|
100% |
[ 4 ] |
| Segunda Opção |
|
0% |
[ 0 ] |
|
| Total de Votos : 4 |
|
| Autor |
Mensagem |
raibarros
Novato
Registrado: Terça-Feira, 26 de Mai de 2009
Mensagens: 5
|
 Enviada: Ter Mai 26, 2009 10:54 pm Assunto: Uma tabela para cada cadastro ou tabela única para todos? |
 |
|
Olá, caros amigos! A minha pergunta é relativamente simples e peço a ajuda de todos. Na modelagem de banco de dados, qual das duas soluções é a mais viável:
1 - gerar uma única tabela para o cadastro de cliente, funcionário e fornecedor, criando também um campo para especificar o seu tipo;
2 - criar uma tabela para cada, como é usado de forma mais comum nos softwares?
Agradeço a ajuda! |
|
| Voltar ao Topo |
|
 |
pestana
Colaborador
Registrado: Sábado, 25 de Junho de 2005
Mensagens: 3147
Localização: Araras-SP
|
| Enviada: Qua Mai 27, 2009 11:04 am Assunto: |
|
|
Bom se é mais viável pra você eu não sei, mas pra mim seria mesclar as duas opções. Quando possível eu prefiro utilizar o conceito de "generalização/especialização".
| Citação: | Neste seu caso eu fazeria o seguinte:
1 - Depois de realizado o esboço inicial (identificação do problema) e logo em seguida o levantamento dos requisitos. Identifico todos os atributos (caracteristicas de uma entidade) e a entidade que representa estes atributos.
2 - Identifico todos os atributos que sejam comum para todas as entidades e desloco para a uma nova entidade que assumira o papel de entidade pai (generalização) e o restante das entidades que possuim suas caracteristicas especificas da própria entidade assumiria o papel de entidade filha (especialização).
ex.: todas as pessoas (cliente, funcionário, fornecedor....) tem nome, endereço, telefone, etc.
3 - Um básico exemplo para ilustrar o conceito:
Pessoa (id_pessoa, nome, endereço, telefone) - id_pessoa chave primaria.
Cliente (id_pessoa, limeteCredito, horarioFuncionamento) - id_pessoa chave primaria e referência a tabela Pessoa.
Funcionário (id_pessoa, cargo, departamento, funcionarioSupervisor) - id_pessoa chave primaria e referência a tabela Pessoa.
Fornecedor (id_pessoa, horarioFuncionamento, ramoAtividade) - id_pessoa chave primaria e referência a tabela Pessoa. |
Observe que a entidade Pessoa (assumindo o papel de entidade generalizada (generalização)) possui os atributos que é comum para as entidades Cliente, Funcionario e Fornecedor (que se identifica como entidade especializadas (especialização)).
Sempre que possível eu utilizo este conceito de generalização/especialização porque neste caso você reduz a possíbilidade de haver uma inconsistência de dados no seu banco. Explico: se você não utiliza este conceito e for criando as tabelas sem pensar como será a estrutura dos dados (armazenamento do dados), como na sua segunda opção, pode haver dados "diferente" de uma mesma pessoa entres as tabelas, porque no mundo real é possível que um cliente ou funcionario pode se tornar tambem um fornecedor ou um fornecedor que tambem é o seu cliente e nestes casos imagine quando você precisa atualizar um endereço ou um telefone...? se você atualizar os dados na tabela de cliente e esquecer de atualizar na tabela de fornecedor, o que vai acontecer? a mesma pessoa tem seus dados "diferentes" nas tabelas de cliente e fornecedor, ou seja, você tem uma inconsistência de dados.
Acredito que se você utiliza somente a segunda opção, você precisa criar uma lógica no sistema que faça a checagem de quando um usuario for cadastrar um cliente verificar se o mesmo código exista nas tabelas de fornecedor, funcionario em todas as tabelas de pessoa e tambem fazer esta alteração nestas tabelas, mas eu prefiro utilizar o próprio recurso que os bancos SGBD trazem a muito tempo (generalização/especialização).
Esta é a minha linha de raciocinio, não quer dizer que é a forma correta de se fazer ou a mais viavel, é somente a minha forma de se pensar!
Agora a questão da enquete eu não assinalei nenhuma opção porque não há um meio termo ai. 
_________________
Ao invés de ficar desanimado no que deu de errado, olhe para frente, aprenda com os erros e veja o que ainda pode ser feito. A determinação e a persistência é uma das etapas para o sucesso.
Editado pela última vez por pestana em Ter Jun 02, 2009 10:45 am, num total de 1 vez |
|
| Voltar ao Topo |
|
|
DonOctavioDelFlores
Colaborador
Registrado: Quarta-Feira, 12 de Setembro de 2007
Mensagens: 2630
Localização: Pra lá de Bagda
|
| Enviada: Qua Mai 27, 2009 11:16 am Assunto: |
|
|
| Citação: | | Esta é a minha linha de raciocinio, não quer dizer que é a forma correta de se fazer ou a mais viavel, é somente a minha forma de se pensar! |
mas é a forma mais correta! na teoria pelo menos.
O grande problema é o design da coisa, porque vc pode acabar se perdendo na propria "ideologia" do negocio. Fica meio parecido com modelagem de OO. Enfim, é facil exagerar e se perder.
E pra quem tem medo de joins, não é bom também (tem gente que morre de medo de joins).
_________________
“The problem with the world is that everyone is a few drinks behind.” Humphrey Bogart |
|
| Voltar ao Topo |
|
|
raibarros
Novato
Registrado: Terça-Feira, 26 de Mai de 2009
Mensagens: 5
|
| Enviada: Qua Mai 27, 2009 11:32 pm Assunto: Observações pertinentes. |
|
|
| Caros amigos. São pertinentes as respostas, sem dúvida. Mas daí surge ainda outra pergunta: no modelo intermediário, caso uma mesma pessoa seja funcionário e fornecedor ao mesmo tempo, dentro da organização, ainda assim não haveria a necessidade de cadastrá-los duas vezes (a primeira na entidade funcionário e a segunda na entidade fornecedor)? Continuaria havendo redundância de dados, estou correto? |
|
| Voltar ao Topo |
|
|
pestana
Colaborador
Registrado: Sábado, 25 de Junho de 2005
Mensagens: 3147
Localização: Araras-SP
|
| Enviada: Sex Mai 29, 2009 2:22 pm Assunto: |
|
|
| DonOctavioDelFlores escreveu: | | O grande problema é o design da coisa, porque vc pode acabar se perdendo na propria "ideologia" do negocio. Fica meio parecido com modelagem de OO. Enfim, é facil exagerar e se perder. |
tem razão! se não entender direito o conceito e exagerar na criação das tabelas (que não se torna forte candidata) é arriscado de se perder na ideologia do negocio.
| raibarros escreveu: | | caso uma mesma pessoa seja funcionário e fornecedor ao mesmo tempo, dentro da organização, ainda assim não haveria a necessidade de cadastrá-los duas vezes (a primeira na entidade funcionário e a segunda na entidade fornecedor)? |
Dados que são comuns para todos não! ou seja, os dados que estão cadastrados na tabela "Pessoa". O que você tem que cadastrar duas vezes são os dados "especificos" de funcionario e fornecedor, mas cada um em suas tabelas.
E antes de você querer cadastrar o funcionário e o fornecedor, obrigatoriamente este registro tem que estar cadastrado na tabela Pessoa. Seguindo o exemplo: As tabelas Funcionario e Fornecedor possuem a chave primaria que tambem é chave estrangeira do campo id_pessoa na tabela Pessoa, então por isso que eu digo que é necessariamente obrigado primeiro "cadastras os dados referente a pessoa" e com este código da pessoa você informa ao fazer o cadastro de funcionario e fornecedor. Você não vai adicionar todos os campos que se diz respeito a pessoa na tabela de funcionario e fornecedor.
ex.:
Pessoa
id_pessoa | nome | dtNascimento
01 | jose | 11/11/1111
02 | maria | 22/22/2222
03 | joão | 33/33/3333
id_pessoa: chave primária.
Funcionario
id_pessoa | id_cargo | id_depto | supervisor
01 | 01 | 02 | null
02 | 02 | 01 | null
03 | 01 | 02 | 01
id_pessoa: chave primária e chave estrangeira que referência o campo id_pessoa da tabela Pessoa.
id_cargo: chave estrangeira que referência o campo id_cargo da tabela Cargo.
id_depto: chave estrangeira que referência o campo id_depto da tabela Departamento.
Fornecedor
id_pessoa | ramoAtividade
03 | informatica
id_pessoa: chave primária e chave estrangeira que referência o campo id_pessoa da tabela Pessoa
Cargo
id_cargo | nome
01 | programador
02 | analista de sistemas
03 | engenheiro de software
Departamento
id_depto | nome
01 | suporte
02 | CPD
03 | administrativo
Observe que somente o "campo que identifica o registro" se repete nas tabelas Funcionario e Fornecedor e não os dados de outros campos pertencentes da tabela Pessoa. Por isso que a resposta para a sua dúvida é negativa.
entendeu? qualquer coisa de um grito ai!
_________________
Ao invés de ficar desanimado no que deu de errado, olhe para frente, aprenda com os erros e veja o que ainda pode ser feito. A determinação e a persistência é uma das etapas para o sucesso. |
|
| Voltar ao Topo |
|
|
raibarros
Novato
Registrado: Terça-Feira, 26 de Mai de 2009
Mensagens: 5
|
| Enviada: Seg Jun 01, 2009 10:24 pm Assunto: Agradeço as opiniões! |
|
|
| Caros amigos! Embora concorde em quase a totalidade do que foi exposto pelo 'pestana', sabemos que ainda haverá redundância de dados (reconhecendo que os principais dados não serão replicados). Agradeço muito a participação de vocês e tenham certeza que os comentários foram muito elucidativos! Obrigado! |
|
| Voltar ao Topo |
|
|
pestana
Colaborador
Registrado: Sábado, 25 de Junho de 2005
Mensagens: 3147
Localização: Araras-SP
|
| Enviada: Ter Jun 02, 2009 10:42 am Assunto: |
|
|
boa dia raibarros!
Gostaria de entender o que você citou:
| Citação: | | sabemos que ainda haverá redundância de dados (reconhecendo que os principais dados não serão replicados). |
De que maneira pode haver redundância?
_________________
Ao invés de ficar desanimado no que deu de errado, olhe para frente, aprenda com os erros e veja o que ainda pode ser feito. A determinação e a persistência é uma das etapas para o sucesso. |
|
| Voltar ao Topo |
|
|
raibarros
Novato
Registrado: Terça-Feira, 26 de Mai de 2009
Mensagens: 5
|
| Enviada: Sáb Jun 06, 2009 5:59 pm Assunto: Caro Pestana! Entendi a sua explicação! |
|
|
Estou testando na prática nesse momento e, de fato, parece ser uma boa solução! Você tem razão: não há redundância! Mas o que pode ocorrer é a utilização em demasia de subconsultas dentro da própria tabela. Ex.: quando é necessário, em uma pesquisa, listar o cliente e o funcionário que cadastrou o cliente (ambos estão na mesma tabela). Ou ainda podem existir casos mais complexos: Listar todas as movimentações financeiras de uma pessoa, sendo ela "cliente" e "fornecedor" ao mesmo tempo, além da pesquisa (na mesma select) do funcionário que realizou o cadastramento de cada tupla.
Aguardarei resposta! |
|
| Voltar ao Topo |
|
|
|
|
Enviar Mensagens Novas: Proibido.
Responder Tópicos Proibido
Editar Mensagens: Proibido.
Excluir Mensagens: Proibido.
Votar em Enquetes: Proibido.
|
|
FAQ
Pesquisar
Membros
Grupos
Registrar
Perfil
Entrar e ver Mensagens Particulares
Entrar
