Jump to content

Base De Dados Acess


nmoa
 Share

Recommended Posts

Boas

necessito de uma ajuda,ando aqui a 3 semanas de volta do acess ,mas nada !!!

pretendo ajudar uma pessoa amiga e também aprender, estou a tentar fazer uma base de dados em acess ,que segundo me disseram o que pretendo é simples ,mas para mim, com os meus niveis de conhecimento (nenhuns) é complicado !!

já consegui fazer as 2 tabelas mas depois as ligações é que se tornam complicadas,imaginem tabela 1 -nome,morada,contacto,nif etc.etc.(no fundo uma ficha de cliente) e a tabela 2 nif,produto,data de validade stock etc.etc.

o que pretendo :

empresa A vende o produto B,C,D,F etc etc

empresa B vende o produto Z,X,W,L etc etc

Nas 2 tabelas eu tenho 1 elemento em comum o Nif , porque como disse cada nif pode vender vários produtos, e é aqui que começa a confusão , quando repito o nif ele não permite,ja estive a ler qualquer coisa sobre a relação de um para N ,mas não consegui perceber (chamem-me burro , mas não percebi mesmo como fazer!!!) e penso eu que esta seja a solução para o meu problema.

desculpem este testamento mas se me puderem explicar como se faz agradecia !!!

obrigado

Link to comment
Share on other sites

A estas horas da noite já é tramado, mas cá vai.

Primeiro o conceito:

Queres ter um conjunto de clientes que faz compras as quais ficam registadas numa base de dados. Cada produto é único e cada cliente também, no entanto cada cliente pode comprar vários produtos, incluindo até a possibilidade de comprar por várias vezes o mesmo produto.

Pois bem, o melhor que tens a fazer é uma base de dados com 3 tabelas.

A 1ª tabela regista os dados de cliente. São dados únicos.

A 2ª tabela regista os dados dos produtos. Cada produto também é único.

A 3ª tabela vai servir para registar as compras feitas pelos clientes.

1ª Tabela (Clientes)

IDCliente

Nome

Morada

NIF

etc...

2ªTabela (Produtos)

IDProduto

Designacao

Validade

Preco

QuantidadeStock

etc....

3ª Tabela (Compras)

IDCompra

IDProduto

IDCliente

DataHora...

Explicando:

Na tabela clientes, o campo IDCliente será o campo de identificação de cada cliente. É um valor numérico (1, 2, 3, 4...) e identifica o número de cada cliente. Por esse motivo este campo terá que ser uma Chave Primária (Primary Key). A chave primária indica que este campo não pode conter valores repetidos. Não pode portanto existir dois clientes com o mesmo IDCliente.

Na tabela de Produtos acontece a mesma coisa com o campo IDProduto. Terá que ser definido como chave primária (Primary Key) e, por conseguinte, cada produto terá um número de identificação único.

A tabela 3 não necessita de ter uma chave primária. Aliás, o campo IDCompra pode até nem existir, mas é boa prática que exista e que sirva de índice nas transacções. É mais rápido ordenar pesquisas com a presença deste campo, mas adiante.

O que vai acontecer na prática é que, em cada compra vai ser criada uma entrada na tabela Compras. O IDcliente será o id do cliente que está a comprar. O IDProduto é o id do produto que o cliente está a adquirir. Uma vez que não estes campos na tabela Compras não são chaves primárias (até porque só poderia haver uma) são denominados Foreign Keys (chaves estrangeiras LOL).

Na prática, se o cliente com IDCliente=12 comprar o produto com IDProduto=342, a entrada na tabela Compras será:

IDCompra=1

IDCLiente=12

IDproduto=342

Data=23/23/2323

etc...

Quando se constroi a base de dados, na área onde é possível criar as ligações entre as tabelas, vamos ter que criar uma ligação entre a tabela Clientes e a tabela Compras e outra ligação da tabela Produtos para a tabela Compras. Compras assume o papel central.

Que tipo de ligações?

Bom. Da tabela Cliente para a Compras, a ligação terá que ser de um-para-muitos. Isto é, um cliente poderá ter muitas compras.

Da tabela Produtos para a Compras, a ligação também será de um-para-muitos. Isto é, um produto poderá ser vendido a muitos clientes. (atenção que o conceito de produto não é a unidade do produto mas sim a designação do produto em si. A quantidade poderá ser controlada por um campo Stock na tabela de Produtos)

É importante sublinhar que no momento da criação destas ligações, é importante defini-las como ligações com Integridade Referencial. Isto quer dizer que, por exemplo, se um produto for retirado da tabela Produtos, automaticamente serão eliminados todos os registos de compras desse produto. O mesmo acontece com os clientes. Se algum for eliminado, automaticamente serão eliminados todos os registos de compras na tabela de Compras.

Espero não ter sido muito complicado na explicação.

Link to comment
Share on other sites

JLDR desde já obrigado pela ajuda , mas acho que me expliquei mal, no entanto com as tuas dicas já consegui avançar mais um passo !!

Não necessito de uma coisa tão complicada com estás a dizer (se calhar estou a dizer alguma asneira !!)

o que necessito e já criei foram 2 tabelas -

tabela 1

empresa

nif

contacto

telefone

telemóvel

email

morada

condigo postal

tabela 2

nif

nome do produto

código do produto

validade do produto

ja liguei as 2 tabelas pelo nif , mas como estou a tentar importar de excell porque já tenho esses dados numa folha , quando importo a informação da tabela 2 ele diz me que tenho o nif duplicado, porque como podes imaginar no excell tenho varias linhas desse nif com vários produtos diferentes e alguns iguais mas com datas de validade diferentes !!!

Link to comment
Share on other sites

Se o NIF repete-se para mais do que uma linha, não podes definir esse campo como chave primária. Na melhor das hipóteses, retira a chave primária da 2ª tabela. Pelo menos, ele não te vai dar erro de nif duplicado.

Link to comment
Share on other sites

Boas!

Este tópico por acaso vem mesmo a calhar pois estive recentemente em "contacto" com uma base de dados em Acess, programa do qual não percebo nada nem nunca trabalhei com.

Acontece que o bacano que mexia nisso foi dispensado e mesmo não tendo eu nada a ver com o assunto nem com a area fiquei a desenrascar. A BD era essencialmente mexida por um armazém que inseria nela tudo o que era devoluções de produtos ao mesmo. Ou seja várias pessoas (que percebiam do assunto ainda menos que eu) diariamente a dar entrada de linhas e linhas... a minha função era simples: apagar linhas quando me pediam - aquilo tinha uma query para o efeito era só corre-la e tava feito - e acrescentar outras ocasionalmente.

Agora a minha questão é (e só por curiosidade porque acho que desistiram mesmo da ideia da BD em Acess) a base de dados simplesmente estourou, uma base de dados em Acess não é fiavel? Quantas entradas aquilo aguenta? Aquela tinha umas 3000! O que para mim naõ é nada, qualquer ficheiro excel leva vezes e vezes isso!

Cumpts

Link to comment
Share on other sites

Enquanto houver espaço em disco, registos podem continuar a ser inseridos. Não acredito que o mdb tenha "estoirado" (perdeu-se os dados, o ficheiro ficou corrompido, o que aconteceu?) porque tinha 3000 registos.

Link to comment
Share on other sites

Pois esse é o meu problema é que necessito da duplicação do nif na tabela 2 para poder identificar a quem pertence,mas diz me uma coisa a chave primaria não é o que liga as duas tabelas ???

Link to comment
Share on other sites

Não propriamente. A chave primária é um campo de uma tabela que identifica um registo. Isto implica que esse valor seja único.

Portanto, eis o que eu faria:

Colocava o NIF da 1ª tabela como chave primária, isto claro, se cada empresa têm um NIF único.

Adicionava um ID à 2ª tabela para identificar cada linha. Dá sempre jeito ter um identificador em cada tabela.

O NIF na 2ª tabela seria a chave estrangeira do NIF da 1ª, ou seja, criava uma referência. Assim, estabelecia uma relação "1 para N", em que uma empresa pode ter vários produtos.

No Access, uma maneira rápida de fazer isto será no modelo relacional (deve ter outro nome, já não me lembro, é onde está o esquema das tabelas). Arrastas o NIF duma tabela para a outra e o próprio Access cria-te a relação.

Se tiveres dúvidas, comunica B)

Link to comment
Share on other sites

Eh lá... discussão em torno da bases de dados parece ser um assunto chato, mas eu acho interessante :-..

Vamos lá por partes.

Para os programadores, as bases de dados do Access são consideradas como parentes pobres na gestão de dados. Isto porque têm um conjunto de limitações que as tornam pouco interessantes para trabalhar, nomeadamente quando se trabalha em ambiente de rede ou em aplicações com necessidade de uma grande ginástica de dados e muitos milhares de linhas.

As limitações das BDs do access podem ser clarificadas no seguinte artigo: Access 2007 Limits

A questão dos 3000 registos darem direito a estouro é uma falsa questão. Tenho algumas aplicações com umas dezenas de milhar de entradas a funcionar sem grandes problemas.

Em relação ao problema apresentado no tópico, há dois caminhos a equacionar: Pretende-se resolver um problema com dados ou a ideia é criar um sistema de registo de dados?

É que são duas coisas completamente distintas.

@nmoa, o problema do "teu sistema" de dados é que, sempre que quiseres registar mais uma compra, vais ter que introduzir os dados completos do produto. Se tiveres uma tabela com os clientes, outra com os produtos e uma terceira que regista as compras, é muito mais simples e muito mais eficiente.

Tal como atrás foi dito, na tua situação o NIF pode ser chave-primária na tabela de clientes, uma vez que cada cliente é único e não existem dois clientes com o mesmo NIF. No entanto, como cada cliente pode fazer mais do que uma compra, o NIF da tabela das vendas não pode ser chave-primária. Ele recebe uma ligação de um-para-muitos proveniente dos Clientes (um cliente-para-muitas vendas).

Link to comment
Share on other sites

Enquanto houver espaço em disco, registos podem continuar a ser inseridos. Não acredito que o mdb tenha "estoirado" (perdeu-se os dados, o ficheiro ficou corrompido, o que aconteceu?) porque tinha 3000 registos.

Pois a grande questão e talvez tenha a ver com isso é que havia muita gente a inserir informação, os computadores são super lentos, antigos e com pouca memoria, o que fazia com que a propria rede fosse lenta. Aquilo dava muitos erros de rede, de gravação tipo "disk is full", tavam sempre a queixar-se q tava muito lento e o catano.

E sim o "estouro" foi que se perdeu toda a informação do mês de Setembro, quando se entra dá para consultar mas só de Julho (quando foi feita, a terceira já) a Setembro!

Mas pronto pelo que dizem foi então mesmo mau manuseamento da BD!

Link to comment
Share on other sites

Enquanto houver espaço em disco, registos podem continuar a ser inseridos. Não acredito que o mdb tenha "estoirado" (perdeu-se os dados, o ficheiro ficou corrompido, o que aconteceu?) porque tinha 3000 registos.

Pois a grande questão e talvez tenha a ver com isso é que havia muita gente a inserir informação, os computadores são super lentos, antigos e com pouca memoria, o que fazia com que a propria rede fosse lenta. Aquilo dava muitos erros de rede, de gravação tipo "disk is full", tavam sempre a queixar-se q tava muito lento e o catano.

E sim o "estouro" foi que se perdeu toda a informação do mês de Setembro, quando se entra dá para consultar mas só de Julho (quando foi feita, a terceira já) a Setembro!

Mas pronto pelo que dizem foi então mesmo mau manuseamento da BD!

Pronto, já tens ai várias razões para que isso tenha acontecido B)

@Mini0n, Static: Vocês sabem que, de qualquer forma, é necessário garantir a o-bri-ga-to-riê-da-de.

:-..

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.