Duvida em Tabelas

SQL Server

03/04/2014

Olá.

Estou fazendo uma Base de Dados para guardar as Compras em uma Loja.
Um Cliente tem associado uma Ficha de Cliente com os seus dados.
Nessa Ficha são adicionadas todas as compras que esse Cliente faz, bem como outras informações sobre os interesses do Cliente.
Para cada Compra é especificado o Vendedor que atendeu o Cliente.

Devo criar as tabelas: Cliente, FichaCliente, Compra, Vendedor?

Criando as relações:
Cliente com FichaCliente.
FichaCliente com Compra.
Compra com Vendedor

Tenho ainda outra dúvida.
Cada Funcionário da loja deve fazer Login no sistema de vendas, mas cada funcionário tem permissão especifica para aceder aos dados, dependendo do seu tipo de cargo.

Pensei em criar a tabela Login com os atributos Login, Pass e TipoFunc.
TipoFunc é para distinguir os funcionários, para saber qual a sua permissão.
Mas como é que a partir posso controlar esse acesso?
Maria Araújo

Maria Araújo

Curtidas 0

Respostas

Roniere Almeida

Roniere Almeida

03/04/2014

fiquei sem entender essa "Ficha do Cliente", ja que o mesmo pega os dados do cliente.

sobre o login, pra mim está certo.
GOSTEI 0
Maria Araújo

Maria Araújo

03/04/2014

Eu imaginei uma Ficha de Cliente normal, em papel.
Do tipo, quando vamos ao médico pela 1ª vez é preenchida uma ficha para cada Pessoa.
Nessa ficha, além dos dados pessoais tem ainda a lista de todas as consultas desse paciente, os medicamentos que ele toma, etc.
A minha Ficha de Cliente de uma loja acaba por funcionar do mesmo jeito que a ficha de paciente.

Em relação ao Login, depois de alguem ter feito Login eu sei seu qual a sua função.
Para que um determinado User não possa ver certa informação devo criar Views para esse tipo de User?
E como faço para que não possa alterar informação na BD?

Obrigado
GOSTEI 0
Fabiano Carvalho

Fabiano Carvalho

03/04/2014

O tipo de acesso você pode criar uma classe com atributo estático (ficara salvo na memória) e toda vez que for mudar de form, verificar se ele possui essa permissão ou não.
Ao meu ver é necessário criar as tabelas: Vendedor, Cliente, FichaCliente, Compra e estoque (Se tiver.)
GOSTEI 0
Maria Araújo

Maria Araújo

03/04/2014

Eu concordo com as tabelas: Cliente, Ficha de Cliente, Vendedor, Compra.
Mas não fica muito dificil criar uma Procedure para inserir uma nova Compra à Ficha de Cliente?
Pois quando insiro uma nova Compra devo ter presente o cod_Cliente.
Passo esse cod_Cliente como parametro da Procedure e depois seleciono a Ficha de Cliente a partir desse codigo?
GOSTEI 0
Marisiana Battistella

Marisiana Battistella

03/04/2014

Olá pessoal!
Maria, você já tem o modelo ER definido?
Quais são as tabelas que constam nele?
Eu acho que ficou um pouco confuso pra te ajudar a sanar essas dúvidas, se vc postar a modelagem ou a estrutura das tabelas nos ajudaria a te ajudar.
Não precisa colocar todos os atributos, apenas a representação das ligações entre as tabelas (chaves estrangeiras e primárias).
GOSTEI 0
Marisiana Battistella

Marisiana Battistella

03/04/2014

Eu fiquei com a mesma dúvida do Roniere, não entendi o porque da tabela FichaCliente....
No meu ponto de vista, através do que falastes, você teria que ter as seguintes tabelas:

CLIENTE : contendo o cadastro de todas as informações pessoais do cliente.
VENDEDOR/FUNCIONARIO: contendo as informações (cadastro) dos vendedores e funcionários bem como as informações de login e senha de acesso ao sistema.
INTERESSES: contendo as informações de interesses do cliente para identificar, por exemplo, o tipo de compra.
MOVIMENTOS_COMPRAS: contendo as informações de compras ou movimentações realizadas e também terá chaves estrangeiras para identificar o cliente, o funcionário e o interesse.
GOSTEI 0
Maria Araújo

Maria Araújo

03/04/2014

Aqui esta. o IdFicha é o mesmo que o IdCliente, dai IdCompra estar associado ao IdCliente
[img]http://arquivo.devmedia.com.br/forum/imagem/365783-20140406-163012.png[/img]
GOSTEI 0
Ricardo

Ricardo

03/04/2014

E a tabela de produtos? outra coisa é quem uma compra(venda) pode ter muitos produtos, e nesse caso tem uma relação N para N já que o produto pode fazer parte de várias vendas. Então ainda teria que criar uma tabela temporária para manter a relação entre compra e produtos.
GOSTEI 0
Maria Araújo

Maria Araújo

03/04/2014

Ricardo, essa parte não coloquei, pois a minha duvida é mesmo na parte da Ficha de Cliente.
Não sei se fica confuso colocar essa tabela ou a deva remover e Cliente relacionar Compras, Questionário.
GOSTEI 0
Ricardo

Ricardo

03/04/2014

Ricardo, essa parte não coloquei, pois a minha duvida é mesmo na parte da Ficha de Cliente.
Não sei se fica confuso colocar essa tabela ou a deva remover e Cliente relacionar Compras, Questionário.



Eu não entendi qual a dúvida em relação ao cliente.
GOSTEI 0
Roniere Almeida

Roniere Almeida

03/04/2014

Maria, desculpa a demora e obrigado pelo retorno, acredito que essa parte de usuarios, no proprio banco, tem como restringir.
GOSTEI 0
Maria Araújo

Maria Araújo

03/04/2014

A dúvida é se devo incluir na Base de Dados a tabela Ficha de Cliente.

Cada Cliente tem a si associado uma única ficha, e uma determinada ficha é especifica para um determinado cliente.

A relação Ficha de Cliente -> Cliente é uma relação 1:1.

Se assim fizer, associo à Ficha de Cliente as Compras, o Questionário.

Devo fazer deste modo ou eliminar a tabela Ficha de Cliente e relacionar à tabela Cliente as suas Compras, Questionário.

A minha dúvida é somente esta, pois não sei até que ponto uma será melhor do que a outra, nomeadamente à inserção de valores nas tabelas.
GOSTEI 0
Marisiana Battistella

Marisiana Battistella

03/04/2014

Não vejo necessidade de vc ter essa tabela FICHACLIENTE, acredito que nem seja correto tê-la.
Exclui essa tabela e liga a tabela QUESTIONARIO a tabela COMPRA.
Assim, você manterá o cadastro do cliente na tabela CLIENTE e na tabela compra você terá as compras que ele fez.
A tabela QUESTIONARIO vc utilizará para realizar os cadastros de questionários, pois um questionário pode estar associado à várias compras realizadas por clientes diferentes.
GOSTEI 0
Roniere Almeida

Roniere Almeida

03/04/2014

pensando bem Marisiana, esse é o caminho mesmo, pq essa tabela seria praticamente uma copia da tabela clientes.
GOSTEI 0
Ricardo

Ricardo

03/04/2014

Então Maria é como os nossos colegas disseram. A tabela ficha cliente é desnecessária, ela seria uma "cópia" da tabela clientes, e em relação a cardinalidade ficaria bagunçado. Basta você imaginar que cada registro da tabela cliente é uma "ficha", talvez assim fique mais fácil a sua compreensão.

No caso você faria um formulário que vai ser a ficha do seu cliente, e nesse formulário você carrega as informações de todas as tabelas que você precisa.
GOSTEI 0
Maria Araújo

Maria Araújo

03/04/2014

Desculpe Ricardo, mas não entendi bem a parte do formulario.
Tou toda baralhada com esta parte.
Talvez não deva pensar como uma ficha em papel, está um pouco confuso.
GOSTEI 0
Ricardo

Ricardo

03/04/2014

Qualquer coisa manda um email / skype ricardo.cardosoti@gmail.com / ricardo.cardosoti que eu faço um programa de exemplo e te envio para ficar mais fácil de entender.

Mas a princípio se vc seguir os conselhos de todos aqui não tem como errar.
GOSTEI 0
Roniere Almeida

Roniere Almeida

03/04/2014

pessoal, caso cheguem a uma conclusão positiva, interessante postar a resposta. assim ajudaria bastante, pelo menos pra mim seria util.
GOSTEI 0
Marisiana Battistella

Marisiana Battistella

03/04/2014

Desculpe Ricardo, mas não entendi bem a parte do formulario.
Tou toda baralhada com esta parte.
Talvez não deva pensar como uma ficha em papel, está um pouco confuso.


Não pensa como uma ficha em papel, essa não é a forma correta de se pensar na hora de criar o modelo dos dados.
Você precisa criar uma forma de armazenar os dados baseada em todas as boas práticas que vc aprendeu em análise de sistemas e engenharia de software.
Você tem todos os requisitos em mãos?
Quais são as instâncias tabelas que vc precisa criar para armazenar esses dados?

GOSTEI 0
Marisiana Battistella

Marisiana Battistella

03/04/2014

Através das informações que você nos passou, poder perceber que será necessário:
1) Cadastrar dados do cliente
2) Cadastrar dados do funcionário
3) Cadastrar dados da loja.
4) Cadastrar dados do questionário de uma compra.
5) Cadastrar dados de uma compra, sendo que uma compra:
* É cadastrada por um funcionário
* É realizada por um cliente
* É efetuada em uma loja
* Possui um motivo em questão (questionário)

GOSTEI 0
Alex Lekao

Alex Lekao

03/04/2014

Ola Boa tarde!!!

Eu me metendo aqui...r srsr

Acredito que a Ficha de Cliente que ela esta se referindo se resumiria a uma view, que trara os dados necessarios para se utilizar no formulario conforme citado.

Dessa forma qdo o operador acessar o cadastro do Cliente ele tem acesso a essa "ficha", funcionaria como um historico de consulta rapida dos ultimos registros do cliente.

Tenho visto muito isso nos programas que trabalhei/utilizei para a parte de relacionamento com o cliente, sabendo assim qdo foi a ultima compra, qdo comprou, etc.

Mas acredito que as sugestoes estao boas, mas o plano de modelagem que foi citado acho que pela Marisiana, eh importante, pq vc vai conseguir visualizar ou ter uma ideia deste relacionamentos e corrigir alguma discrepancia antes de desenvolver.

Espero ter ajuado.

Abraco.

Alex - Lekao
GOSTEI 0
Marisiana Battistella

Marisiana Battistella

03/04/2014

Isso mesmo Alex, vc concluiu minha sugestão! Obrigada!
GOSTEI 0
Alex Lekao

Alex Lekao

03/04/2014

Disponha... rsrsr

Isso mesmo Alex, vc concluiu minha sugestão! Obrigada!
GOSTEI 0
Roniere Almeida

Roniere Almeida

03/04/2014

Marisiana, me fez lembrar dos bons tempos de modelagem de dados. hehehe
GOSTEI 0
Marisiana Battistella

Marisiana Battistella

03/04/2014

Que bom! Eu adoro fazer análises, principalmente de dados! =D
GOSTEI 0
Alex Lekao

Alex Lekao

03/04/2014

Eu tbm gosto...

mas nao tenho muita experiencia...

sou apaixonado por discutir os assuntos e tentar elaborar planos e estrategias e definir layouts... nooooossa muito bom...

pena que estou longe faz muito tempo, gostaria muito de estar envolvido novamente. =/
GOSTEI 0
Maria Araújo

Maria Araújo

03/04/2014



Não pensa como uma ficha em papel, essa não é a forma correta de se pensar na hora de criar o modelo dos dados.
Você precisa criar uma forma de armazenar os dados baseada em todas as boas práticas que vc aprendeu em análise de sistemas e engenharia de software.
Você tem todos os requisitos em mãos?
Quais são as instâncias tabelas que vc precisa criar para armazenar esses dados?



Logo vi que estava pensando mal.
Vou mudar a maneira de pensar.
Muito obrigado

O Questionario não e para relacionar com Compra.
É algo assim:
Onde compra seus produtos?
Quais produtos compra?

Questionario tem de se relacionar com Cliente
GOSTEI 0
Alex Lekao

Alex Lekao

03/04/2014

Eh basicamente uma pesquisa.

Entao acho que esteja correto o seu pensamento de ele ter relacao apenas com o cliente.
GOSTEI 0
Marisiana Battistella

Marisiana Battistella

03/04/2014

Mas nesse caso não tem necessidade de vc ter essa tabela questionário, essas questões você vai responder pro usuário através de SELECT filtrando os dados armazenados no banco.
Por exemplo:

* Onde o cliente compra seus produtos?
Você fará um select buscando em quais lojas o cliente realizou compras

* Quais são os produtos que o cliente comprou?
Você fará um select buscando os itens das compras realizadas pelo cliente.

Depois você mostrará esses dados para o cliente na aplicação, seja em forma de relatório, ou num grid,...
GOSTEI 0
Alex Lekao

Alex Lekao

03/04/2014

Oi Marisiana,

Acredito que sera isso mesmo que sera feito, mas no caso havera a necessidade da tabela questionario para armezenar a pesquisa que sera feita com o cliente, correto?

acho que foi esse o ponto. rsrsr
GOSTEI 0
Marisiana Battistella

Marisiana Battistella

03/04/2014

Oi!!
De acordo com as duas questões que a Maria apresentou, não tem necessidade de armazenar a questão no banco, pois ela tem os dados que respondem a essas questões.
Eu penso que essas questões são para ela responder em forma de relatórios.
GOSTEI 0
Alex Lekao

Alex Lekao

03/04/2014

Eu entendi diferente, que seria um questionario mesmo, como pesquisa de consumo/consumidor, essas coisas.

Imagino a necessidade de amazenar no banco para consultas futuras, se assim for a intencao deste questionario.

Estou entendendo que este questionario seja preenchido durante o atendimento pelo operador/vendedor e nao "preenchido" pelo cliente.

mas no caso sao suposicoes.

mais ai ja entro em um limite que a mim impede de proceguir que eh a experiencia necessaria com a analise e desenvolvimento de sistemas, projetos ou seja la o que for que tenha que se conhecer para elaborar isso. kkkkk

mas de uma forma ou de outra, as sugestoes estao muito boas, dadas por todos, e acho que tem sido bastante elucidativo para a Maria.

Eh isso ai. rsrsr

Abraco.

Alex - Lekao
GOSTEI 0
POSTAR