As secções seguintes mostram como as relações da tabela de base de dados foram concebidas. Os nomes dos objetos são fornecidos para que possa examiná-los facilmente na base de dados Northwind 2.0 Starter Edition.
Para abrir o Diagrama de Relações que mostra as seis tabelas e as relações entre elas, selecione Ferramentas de Base de Dados > Relações.
Este diagrama mostra as seis tabelas. No diagrama, as linhas entre tabelas identificam relações entre elas. O símbolo 1 e infinito (∞) nas extremidades das linhas representa o lado único de uma relação (por exemplo, um cliente) e o lado muitos de uma relação. Por exemplo, um cliente submete muitas encomendas. Para obter mais informações, consulte Guia para relações de tabelas.
Os seguintes princípios aplicam-se a tabelas na Northwind 2.0 Starter Edition, bem como a tabelas em geral.
Chaves primárias Identificar exclusivamente cada registo numa tabela. Todas as tabelas têm uma chave primária. No diagrama de relação, os símbolos de chave identificam essas chaves primárias. As convenções de nomenclatura de chaves primárias têm o nome da tabela em que se encontram, por exemplo, "TableNameID".
Eficiência Para um melhor desempenho e armazenamento mais eficiente, as chaves primárias devem ser numéricas. Além disso, é mais conveniente que o Access gere automaticamente o novo valor exclusivo para a chave primária de cada novo registo. O tipo de dados Numeração Automática tem ambas as características. Os Numerações Automáticas são, de outra forma, números não significativos e não servem outro propósito. Para obter mais informações, veja Adicionar um campo numeração automática como uma chave primária.
Chaves externas Uma tabela também pode ter uma ou mais chaves externas, consoante esteja relacionada com outras tabelas na base de dados. Uma chave externa contém valores que correspondem a valores na chave primária da tabela relacionada.
Índices exclusivos Outros campos em tabelas também podem ter os seus próprios índices exclusivos, por exemplo OrderStatus.StatusCode. É ilógico ter dois Estados de Encomenda na tabela OrderStatus com o mesmo código, embora StatusCode não seja a chave primária. Um índice exclusivo indica ao Access para impedir valores duplicados nesse campo.
Índices não exclusivos As tabelas também podem ter índices para acelerar as pesquisas e ordenações nesses campos, por exemplo Orders.OrderDate. Muitas encomendas podem ser feitas no mesmo dia e, muitas vezes, pretende procurar e ordenar datas de encomenda. Existe um índice não exclusivo nesse campo para acelerar a pesquisa e ordenação.
Nomes de tabelas e campos Pode atribuir um nome às coisas como quiser, mas a consistência é importante. Recomendamos que os nomes de tabelas e campos sejam uma ou mais palavras sem espaços entre elas e sem carateres especiais, como uma barra (/), um sinal de cardinal (#) ou uma percentagem (%). Por exemplo, utilize OrderDate, mas não Data da Encomenda; utilize OrderNumber ou OrderNo, mas não Order#.
CamelCase Escreva palavras em maiúsculas para realçar partes individuais do nome, por exemplo, DataDaEncomida, mas não DataDaEncomida ou DataDaEncomida.
Valor necessário Este princípio realça a importância das regras de negócio para uma aplicação. Algumas situações requerem valores ou até mesmo valores específicos em alguns campos. Por exemplo, de que serve uma Encomenda sem conhecer o Cliente que a colocou? Isto significa que CustomerID é um campo necessário para a tabela Encomendas.
Campos calculados O Access suporta campos calculados em tabelas, por exemplo, o campo Employees.FullName. Pode preferir criar campos calculados numa consulta e não numa tabela.
Campos de anexo O Access suporta campos de anexo, por exemplo Funcionários.Imagem, que contém uma imagem do funcionário. Os anexos podem armazenar imagens, documentos, e-mails e outras informações binárias. Os anexos ocupam muito espaço na base de dados. É mais eficiente armazenar anexos num servidor de ficheiros.
Campos de valores múltiplos Como o nome indica, os campos de valores múltiplos armazenam um ou mais valores num único campo, por exemplo, Employees.Title. Sugerimos que os utilize com moderação, especialmente se quiser aumentar o tamanho da base de dados. A maioria dos outros sistemas de bases de dados não os tem, o que requer muito trabalho.
Para obter mais informações sobre tipos de dados, veja Introdução aos tipos de dados e propriedades de campo.
Esta secção aborda as funcionalidades mais importantes de cada tabela. Para rever a estrutura de uma tabela, selecione-a no Painel de Navegação, clique com o botão direito do rato na mesma, selecione Vista estrutura ou selecione Ferramentas de Base de Dados > Relações e, em seguida, clique com o botão direito do rato num objeto de tabela. Para obter mais informações, consulte Introdução às tabelas.
Importante: Evite a utilização de palavras reservadas que possam causar conflitos de nomenclatura. Para obter mais informações, veja Saiba mais sobre palavras e símbolos reservados do Access.
Tabela Funcionários
Esta tabela armazena informações sobre os funcionários da Northwind.
|
Campos |
Descrição |
|
FirstName, LastName |
Ambos os nomes são necessários e, em Northwind, juntos têm de ser uma combinação única. Na estrutura da tabela, quando abre a caixa de diálogo Índices , pode ver que FirstName + LastName tem um índice exclusivo. Uma vez que FirstName e LastName estão indexados de forma exclusiva, a tabela Northwind não consegue armazenar dois colaboradores com o mesmo nome. Noutras situações, pode utilizar uma regra de negócio diferente. |
|
FullNameFNLN, |
Observe a propriedade expression dos campos calculados para ver como o Access combina valores em campos calculados. Para incluir uma inicial do meio, adicione-a à expressão existente com espaçamento adequado entre componentes. |
|
Campos de telefone |
A regra de negócio para telemóveis é que a preferência dos funcionários é mais relevante do que o tipo de serviço. Por conseguinte, os números de telefone principais e secundários são utilizados em vez de telemóvel, escritório, casa, etc. |
|
Saudação |
A saudação é um campo Texto Breve. Para ilustrar a funcionalidade de campos de valores múltiplos no Access, é uma caixa de combinação com uma lista editável de valores predefinidos. Listas curtas e estáticas como esta são frequentemente candidatas a campos de valores múltiplos porque não mudam muito, se é que alguma vez mudam. |
|
JobTitle |
JobTitle é outro campo obrigatório. |
Tabela Clientes
Esta tabela armazena informações sobre os clientes da Northwind.
|
Campos |
Descrição |
|
CustomerName |
Os clientes da Northwind são empresas e é necessário um nome de cliente. No entanto, ao contrário dos nomes dos colaboradores, não é indexado de forma exclusiva, permitindo que dois ou mais clientes tenham o mesmo nome. |
|
PrimaryContactFirstName, PrimaryContactLastName, |
Os nomes próprios e apelidos do contacto principal e o cargo não são necessários porque os clientes podem não ter um indivíduo como contacto principal. Os contactos podem não dar o cargo para uma encomenda. |
|
BusinessPhone |
A Northwind requer apenas um número de telefone para cada cliente, embora isto elimine a capacidade de capturar vários números de telefone para clientes ou para contactos de clientes. Em situações do mundo real, normalmente, as regras de negócio mais complexas aplicam-se às informações de contacto. |
|
Endereço, Cidade |
A Northwind precisa de um endereço para enviar encomendas aos clientes. Existe apenas um endereço genérico para um cliente. Em situações reais, os clientes têm frequentemente endereços de faturação, envio ou outros endereços separados. Uma regra de negócio diferente para a sua organização exigiria campos adicionais. |
|
Notas |
O campo Notas é um tipo de dados Texto Longo, que armazena até 1 GB de texto. Isto permite-lhe introduzir comentários detalhados sobre os clientes para utilização em situações de encomendas subsequentes. |
Tabela Encomendas
Esta tabela armazena informações sobre as encomendas da Northwind.
|
Campos |
Descrição |
|
OrderDate, ShippedDate, PaidDate |
As encomendas requerem três datas. São todos do tipo de dados Data/Hora, mas com dois formatos. OrderDate tem uma data e uma hora porque poderá estar interessado em analisar o volume de encomendas para diferentes partes do dia. Para as outras duas datas, só é necessária a data. Uma regra de validação de tabela para ShippedDate e PaidDate garante que essas datas não estão antes do OrderDate. |
|
OrderStatusID |
O estado da encomenda indica onde está a encomenda no fluxo de trabalho Northwind. As encomendas passam por quatro fases: Novo — > Faturado — > Enviado — > Fechado.A chave externa do OrderStatus atual utiliza OrderStatusID da tabela de referência orderStatus. A utilização de uma tabela de referência Estado garante que apenas os quatro estados predefinidos podem ser atribuídos a uma encomenda. |
Tabela de detalhes da encomenda
Esta tabela armazena informações sobre os detalhes da encomenda da Northwind.
|
Campos |
Descrição |
|
IDDaEnenção |
Cada item de linha na tabela OrderDetails tem de pertencer a uma Encomenda na tabela Encomendas. OrderID é uma chave externa que identifica essa encomenda. Conforme indicado anteriormente, uma ordem que contém um ou mais itens de linha ilustra uma relação um-para-muitos. |
|
IDdoProduto |
Cada registo na tabela OrderDetails inclui o ProductID para o Produto encomendado. ProductID é uma chave externa na tabela OrderDetails, identificando esse Produto nessa ordem. Esta é também uma relação um-para-muitos. |
|
OrderID+ ProductID |
Como viu na tabela Funcionários, vários campos podem ter um índice exclusivo. O índice exclusivo sobre OrderID+ProductID na tabela OrderDetails garante que cada encomenda contém um produto apenas uma vez. Quando abre a folha de propriedades Índices a partir do friso, pode ver este índice exclusivo. |
Tabela Produtos
Esta tabela armazena informações sobre os produtos da Northwind.
|
Campos |
Descrição |
|
CódigodoProduto |
Além da chave primária, os produtos ProductID e Northwind têm um código de produto exclusivo, exclusivo e amigável. Normalmente, os funcionários referem-se a códigos de produto e não a valores de chave primária. O código do produto é um valor composto que consiste numa designação de Categoria e num número, por exemplo, B-1 para "Bebida", produto 1. |
|
Nome do Produto, |
Além dos nomes de produtos de texto curto, aplica-se uma descrição de texto longo aos produtos. Este valor pode ser utilizado numa descrição do catálogo ou para responder a perguntas dos clientes. |
|
PreçoUnitário |
Todos os produtos são vendidos com um preço unitário para cada item que simplifica a base de dados como uma demonstração de funcionalidades. Na maioria das situações do mundo real, os preços são muitas vezes significativamente mais complexos. |
Consulte Também
