Access
 sql >> Base de Dados >  >> RDS >> Access

Dicas da Tabela do Microsoft Access - Truques e Diretrizes Parte 5


Continuando nossa série de Dicas – Truques e Diretrizes com o Microsoft Access, compartilhamos alguns itens adicionais. Os artigos em andamento continuarão a se concentrar em tabelas em um banco de dados do Access.

Tabelas de banco de dados e relacionamentos de tabela

O que exatamente são relacionamentos de tabelas de banco de dados e por que você deseja usá-los? Projetar um banco de dados com várias tabelas pode ser particularmente desafiador. Você não apenas precisa determinar todas as tabelas do banco de dados, mas entender o conceito de um banco de dados no que diz respeito a várias tabelas é uma tarefa difícil.

Algumas pessoas simplesmente desistem de tentar fazer isso e rapidamente migram para o MS Excel. Em pouco tempo, eles se encontram em um pesadelo de planilhas de ter várias planilhas vinculadas pelo grande abismo de uma rede compartilhada. Os indivíduos navegam para o Excel porque não têm tempo ou conhecimento para criar um banco de dados do Access.

Portanto, supondo que você queira criar um banco de dados no Access, a janela de relacionamento de tabela no Access pode ser extremamente útil. Minha opinião profissional é não criar nada em seu banco de dados até que você possa mapear todos os relacionamentos usando esse recurso. Na figura abaixo, vemos um relacionamento padrão entre um cliente e um pedido.



Este artigo se concentrará no relacionamento “um para muitos”. O que significa essa relação e como é usada? No exemplo acima, as informações do cliente são armazenadas como “um ” e os pedidos são armazenados como “muitos " relação. Por que você deseja armazenar as informações do cliente mais de uma vez? Os pedidos ou muitos lados só armazenarão o CustomerID mais de uma vez porque um cliente pode fazer o pedido mais de uma vez.

Por exemplo, se uma empresa de lacres de garagem bloquear sua entrada de automóveis. Neste caso, o cliente é armazenado na tabela de clientes e todos os detalhes do pedido de vedação/pedido serão armazenados na tabela de pedidos.

Dois anos a partir do primeiro selo, a entrada de automóveis precisará ser vedada novamente. O cliente já está no banco de dados, portanto, um novo pedido é criado para o mesmo cliente. Na visualização do formulário abaixo dos pedidos mostra o desenvolvimento final uma vez que as tabelas são criadas.



No exemplo acima, as informações do trabalho do cliente são o componente principal do relacionamento um-para-muitos. Se for necessário um novo trabalho para o mesmo cliente, tudo o que o usuário faz é selecionar o botão novo trabalho no diagrama abaixo.



Depois que o novo trabalho é adicionado, a tela de resumo do cliente muda para refletir o 2º trabalho para o mesmo cliente. Veja o diagrama abaixo.



Então, isso nos leva de volta aos relacionamentos de tabela, mas também preenche a lacuna do motivo pelo qual você configura os relacionamentos em primeiro lugar.

A figura acima é o resultado da criação das tabelas e formulários. A figura abaixo é onde começou quando você está configurando os relacionamentos de tabela para começar. O CustomerID na tabela de clientes corresponde a um pedido na tabela de pedidos.



Dica – Nunca comece a criar formulários de entrada de banco de dados em um banco de dados do Access antes de mapear toda a estrutura da tabela primeiro.

Os itens secundários no diagrama abaixo incluem o seguinte:
  • Aplicar integridade referencial – Um pedido não pode ser inserido na tabela de pedidos até que esse cliente seja criado primeiro. Isso evita que pedidos "perdidos" sejam criados sem um cliente.
  • Campos relacionados atualizados em cascata – Se o valor do campo ID do cliente for alterado na tabela de clientes, todos os valores de ID do cliente associados também serão alterados na tabela de pedidos. Isso é mais comum em um banco de dados que tem números de produtos ou valores de ID de funcionários alterados.
  • Excluir registros relacionados em cascata – Se você excluir um cliente, todos os pedidos associados também serão excluídos. Novamente, isso evita que registros “perdidos” ou “órfãos” sejam deixados sozinhos nas tabelas downstream.

Em resumo, projetar um banco de dados com várias tabelas não é uma tarefa fácil. No entanto, é possível com muita pesquisa e trabalho duro, pode ser feito. É realmente um quebra-cabeça que você resolve, e todas as peças estão bem na sua frente quando se trata de rastrear os dados em seus processos do dia-a-dia.



Se você está tendo problemas para saber como começar a usar o Microsoft Access, entre em contato com a Arkware hoje para qualquer necessidade de banco de dados.