Criando os relacionamentos de tabela
Agora que as informações estão divididas em tabelas, há necessidade de uma forma de reunir as informações novamente, com um sentido. Por exemplo, o formulário a seguir engloba informações de várias tabelas.
As informações desse formulário são originárias da tabela Clientes...
Criando uma relação um-para-muitos
Examine este exemplo: as tabelas Fornecedores e Produtos do banco de dados de pedidos de produto. Um fornecedor pode fornecer qualquer número de produtos. Consequentemente, para qualquer fornecedor representado na tabela Fornecedores pode haver vários produtos representados na tabela Produtos. A relação entre a tabela Fornecedores e a tabela Produtos é, portanto, uma relação um-para-muitos.
Para representar uma relação um-para-muitos em um design de banco de dados, tome a chave primária do lado "um" da relação e adicione-a como coluna ou colunas adicionais à tabela do lado "muitos" da relação. Nesse caso, por exemplo, a coluna Código do Fornecedor da tabela Fornecedores é adicionada à tabela Produtos. O Access pode, em seguida, usar o número do código do fornecedor da tabela Produtos para localizar o fornecedor correto de todos os produtos.
A coluna Código do Fornecedor da tabela Produtos é denominada chave estrangeira. A chave estrangeira é uma chave primária de outra tabela. A coluna Código do Fornecedor da tabela Produtos é uma chave estrangeira porque é também a chave primária da tabela Fornecedores.
As bases para a junção de tabelas relacionadas são fornecidas pelo estabelecimento da união de chaves primárias com chaves estrangeiras. Quando não se está certo sobre quais tabelas devem compartilhar uma coluna comum, identificar uma relação um-para-muitos assegura que as duas tabelas envolvidas exigirão verdadeiramente uma coluna compartilhada.
Criando uma relação muitos-para-muitos
Examine a relação entre a tabela Produtos e a Tabela Pedido.Um único pedido pode incluir mais de um produto. Por outro lado, um único produto pode constar em vários pedidos. Assim, para todos os registros da tabela Pedidos pode haver vários registros na tabela Produtos. E para cada registro na tabela Produtos pode haver registros na tabela Pedidos. Esse tipo de relação é denominado relação muitos-para-muitos porque com relação a todos os produtos pode haver vários pedidos, e para todos os pedidos pode haver vários produtos. Observe que para detectar relações muitos-para-muitos entre as tabelas é importante considerar ambos os lados da relação.
Os tópicos das duas tabelas — pedidos e produtos — têm uma relação muitos-para-muitos. Isso representa um problema. Para entender o problema, imagine o que aconteceria se você tentasse criar a relação entre duas tabelas adicionando o campo Código do Produto à tabela Pedidos. Para ter mais de um produto por pedido, é necessário mais de um registro na tabela Pedidos por pedido. Você repetiria as informações do pedido em cada uma das linhas relativas a um único pedido — o que resultaria em um design ineficaz que poderia resultar em dados imprecisos. O mesmo problema é enfrentado quando se coloca o campo Código do Pedido na tabela Produtos — haveria mais de um registro na tabela Produtos para cada produto. Como resolver esse problema?
A solução é criar uma terceira tabela, em geral denominada tabela de junção, que divide as diversas relações muitos-para-muitos em duas relações um-para-muitos. Insira a chave primária de cada uma das duas tabelas em uma terceira tabela. Consequentemente, a terceira tabela registra todas as ocorrências ou instâncias da relação.
Cada registro da tabela de Detalhes do Pedido representa um item de linha do pedido. A chave primária da tabela Detalhes do Pedido consiste em dois campos — as chaves estrangeiras das tabelas Pedidos e Produtos. Usar somente o campo Código do Pedido não funciona como chave primária dessa tabela, porque um único pedido pode conter vários itens de linha. O Código do Pedido repete-se em cada item de linha em um pedido, de modo que o campo não possa conter valores únicos. Usar apenas o campo Código do Produto não funciona também, porque um mesmo produto pode surgir em diversos pedidos diferentes. Em conjunto, porém, os dois campos podem sempre produzir um valor único para cada registro.
No banco de dados de vendas de produto a tabela Pedidos e a tabela Produtos não estão relacionadas entre si de forma direta. Em vez disso, são relacionadas indiretamente através da tabela Detalhes do Pedido. A relação muitos-para-muitos entre pedidos e produtos é representada no banco de dados por meio de duas relações um-para-muito:
· A tabela Pedidos e a tabela Detalhes tem uma relação um-para-muitos. Todos os pedidos podem ter mais de um item de linha, porém todo item de linha é conectado a apenas um pedido.
· A tabela Produtos e a tabela Pedidos tem uma relação um-para-muitos. Cada produto pode ter vários itens de linha associados a ele, mas cada item de linha se refere a apenas um produto.
Da tabela de Detalhes do Pedido, é possível determinar todos os produtos em um pedido particular. É possível também determinar que todos os pedidos de um produto particular.Após incorporar a tabela de Detalhes do Pedido, a lista de tabelas e campos pode ter a seguinte aparência:
Criando uma relação um-para-um
Um outro tipo de relação é a relação um-para-um. Por exemplo, suponhamos que haja necessidade de registrar algumas informações especiais e complementares de um produto, que serão raramente usadas ou que se só aplicam a uns poucos produtos. Como essas informações não são exigidas com frequência, e como armazenar informações na tabela Produtos resultaria em espaço vazio para todos os produtos aos quais elas não se aplicam, coloque essas informações em uma tabela distinta. Assim como a tabela Produtos, utilize o CódigoDoProduto como chave primária. A relação entre essa tabela complementar e a tabela Produto é uma relação um-para-um. Para cada registro da tabela Produto, existe apenas um registro correspondente na tabela complementar. Quando essa relação é identificada, ambas as tabelas devem compartilhar um campo comum.Quando a necessidade de uma relação um-para-um é detectada no banco de dados, considere colocar as informações das duas tabelas juntas em uma só tabela. Se houver um motivo para não o fazer, talvez porque isso resulte em uma série de espaços vazios, a lista a seguir mostra como representar a relação no design:
· Se as duas tabelas tiverem o mesmo tópico, você poderá provavelmente configurar a relação por meio da mesma chave primária em ambas as tabelas.
· Se as duas tabelas tiverem tópicos diferentes com chaves primárias diversas, escolha uma das tabelas (qualquer uma) e insira a chave primária na outra tabela como chave estrangeira.
A determinação das relações entre tabelas ajuda a assegurar que se tenham as tabelas e colunas corretas. Quando existe uma relação um-para-um ou um-para-muitos, as tabelas envolvidas exigem o compartilhamento de uma coluna ou colunas comuns. Quando existe uma relação muitos-a-muitos, uma terceira tabela é necessária para representar a relação.
Nenhum comentário:
Postar um comentário