Chave Primária

Chaves primárias (em inglês Primary Keys ou PK) sob o ponto de vista de um banco de dados relacional, referem-se às tuplas (conjuntos) de um ou mais campos, cujos valores, considerando a combinação de valores de todos os campos da tupla, nunca se repetem e que podem ser usadas como um índice para os demais campos da tabela do banco de dados. Em chaves primárias, não pode haver valores nulos nem repetição de tuplas.
Simplificando, quando a chave primária é simples, ou seja, é formada por um único campo da tabela, esse campo não pode ter dois ou mais registros de mesmo valor, e também não pode conter nenhum registro nulo. Se a chave primária é composta, ou seja, formada por mais de um campo, os valores de cada campo podem se repetir, mas não a combinação desses valores. Exemplo: a tabela 'Livros_Autores' tem como chave primária (cod_livro, cod_autor). Podem existir nessa tabela os registros:

(5, 9), (5, 10), (4, 9), (9, 5)

Mas não podem existir dois registros (5, 9).

Ao criarmos uma chave primária, criamos automaticamente um índice do tipo aglomerado (CLUSTERED). Este é o tipo criado por padrão, mas caso já exista um índice desse tipo em sua tabela, então é necessário ser criado um índice do tipo não-aglomerado (NONCLUSTERED).
Podemos inserir uma chave primária durante ou após a criação da tabela. Com a tabela já criada, o campo que escolhermos para ser a chave primária deve ter a opção NOT NULL adicionada. Para inserirmos durante a criação usamos a seguinte sintaxe:

CREATE TABLE nome_tabela
(
Codigo int CONSTRAINT nome_constraint PRIMARY KEY CLUSTERED,
Nome nvarchar(17)
)

Nessa estrutura escolhemos um índice do tipo CLUSTERED e resolvemos nomear com algum nome desejado a constraint de primary key. O índice poderia ser do tipo Nonclustered e poderíamos deixar o próprio SQL Server nomear a constraint, da seguinte forma:

CREATE TABLE nome_tabela
(
Codigo int PRIMARY KEY NONCLUSTERED,
Nome nvarchar(17)
)

Além disso, pode-se definir a chave primária após a declaração dos campos, como segue:

CREATE TABLE nome_tabela
(
campo1 NOT NULL,
campo2 NOT NULL,
campoX ,
PRIMARY KEY (campo1, campo2)
)

Na definição de chave primária, usamos o comando ALTER TABLE para inserirmos e excluirmos uma primary key. As sintaxes respectivamente são:

ALTER TABLE nome_tabela
ADD CONSTRAINT nome_constraint PRIMARY KEY NONCLUSTERED(nome_campo)
ALTER TABLE nome_tabela
DROP CONSTRAINT nome_constraint

Uma chave candidata consiste em um atributo ou grupo de atributos cujo valor identifica unicamente cada tupla em uma relação e para o qual nenhum dos atributos pode ser removido sem destruir a identificação única.
Chaves primárias (em inglês Primary Keys ou PK) sob o ponto de vista de um banco de dados relacional, referem-se às tuplas (conjuntos) de um ou mais campos, cujos valores, considerando a combinação de valores de todos os campos da tupla, nunca se repetem e que podem ser usadas como um índice para os demais campos da tabela do banco de dados. Em chaves primárias, não pode haver valores nulos nem repetição de tuplas.
Simplificando, quando a chave primária é simples, ou seja, é formada por um único campo da tabela, esse campo não pode ter dois ou mais registros de mesmo valor, e também não pode conter nenhum registro nulo. Se a chave primária é composta, ou seja, formada por mais de um campo, os valores de cada campo podem se repetir, mas não a combinação desses valores. Exemplo: a tabela 'Livros_Autores' tem como chave primária (cod_livro, cod_autor). Podem existir nessa tabela os registros:

(5, 9), (5, 10), (4, 9), (9, 5)

Mas não podem existir dois registros (5, 9).

Ao criarmos uma chave primária, criamos automaticamente um índice do tipo aglomerado (CLUSTERED). Este é o tipo criado por padrão, mas caso já exista um índice desse tipo em sua tabela, então é necessário ser criado um índice do tipo não-aglomerado (NONCLUSTERED).
Podemos inserir uma chave primária durante ou após a criação da tabela. Com a tabela já criada, o campo que escolhermos para ser a chave primária deve ter a opção NOT NULL adicionada. Para inserirmos durante a criação usamos a seguinte sintaxe:

CREATE TABLE nome_tabela
(
Codigo int CONSTRAINT nome_constraint PRIMARY KEY CLUSTERED,
Nome nvarchar(17)
)

Nessa estrutura escolhemos um índice do tipo CLUSTERED e resolvemos nomear com algum nome desejado a constraint de primary key. O índice poderia ser do tipo Nonclustered e poderíamos deixar o próprio SQL Server nomear a constraint, da seguinte forma:

CREATE TABLE nome_tabela
(
Codigo int PRIMARY KEY NONCLUSTERED,
Nome nvarchar(17)
)

Além disso, pode-se definir a chave primária após a declaração dos campos, como segue:

CREATE TABLE nome_tabela
(
campo1 NOT NULL,
campo2 NOT NULL,
campoX ,
PRIMARY KEY (campo1, campo2)
)

Na definição de chave primária, usamos o comando ALTER TABLE para inserirmos e excluirmos uma primary key. As sintaxes respectivamente são:

ALTER TABLE nome_tabela
ADD CONSTRAINT nome_constraint PRIMARY KEY NONCLUSTERED(nome_campo)
ALTER TABLE nome_tabela
DROP CONSTRAINT nome_constraint

Uma chave candidata consiste em um atributo ou grupo de atributos cujo valor identifica unicamente cada tupla em uma relação e para o qual nenhum dos atributos pode ser removido sem destruir a identificação única.

Modelagem de Dados - Final (Normalização)

Normalização é um processo baseado nas chamadas formais normais. Uma forma normal é uma regra de deve ser aplicada na construção das tabelas do banco de dados para que estas fiquem bem projetadas. Segundo autores, existem 4 formas normais. Neste artigo vou falar sobre as 3 primeiras, sendo as principais.
Com o banco de dados construído, devem-se aplicar as 3 formas normais em cada tabela, ou grupo de tabelas relacionadas. As formas têm uma ordem e são dependentes, isto é, para se aplicar a segunda norma, deve-se obrigatoriamente ter aplicado a primeira e assim por diante. Então, vamos às normas:

1 Forma Normal: Verificação de Tabelas Aninhadas.
Para uma tabela estar na primeira forma normal ela não deve conter tabelas aninhadas. Um jeito fácil de verificar esta norma é fazer uma leitura dos campos das tabelas fazendo a pergunta: Este campo depende de qual?.

Vamos exemplificar, com a tabela Venda. Este é o esquema relacional da tabela:

Venda(Codvenda, Cliente, Endereco, Cep, Cidade, Estado, Telefone, Produto, Quantidade, Valorunitario, Valorfinal).

O raciocínio é o seguinte: A tabela Venda, deve armazenar informações da venda. Pois bem, verificando o campo Cliente, sabemos que ele depende de CodVenda, afinal para cada Venda há um cliente. Vendo o campo Endereço, podemos concluir que ele não depende de Codvenda, e sim de Cliente, pois é uma informação referente particularmente ao cliente. Não existe um endereço de venda, existe sim um endereço do cliente para qual se fez a venda. Nisso podemos ver uma tabela aninhada. Os campos entre colchetes, são referentes ao cliente e não á venda.

Venda (Codvenda, [Cliente, Endereço, Cep, Cidade, Estado, Telefone, Produto, Quantidade, Valorunitario, Valorfinal).

A solução é extrair estes campos para uma nova tabela, adicionar uma chave-primária à nova tabela e relaciona-la com a tabela Venda criando uma chave-estrangeira.Ficaria desta forma:

Cliente (Codcliente, Nome, Endereço, Cep, Cidade, Estado, Telefone).
Venda (Codvenda, Codcliente, Produto, Quantidade, Valorunitario, Valorfinal).

Agora aplicamos novamente á primeira forma normal as 2 tabelas geradas. Uma situação comum em tabelas de cadastro é o caso Cidade-Estado. Analisando friamente pela forma normal, o Estado na tabela Cliente, depende de Cidade. No entanto Cidade, também depende de Estado, pois no caso de a cidade ser Curitiba o estado sempre deverá ser Paraná, porém se o Estado for Paraná, a cidade também poderá ser Londrina. Isso é o que chamamos de Dependência funcional: é onde aparentemente, uma informação depende da outra. No caso Cidade-Estado a solução é simples:
Extraímos Cidade e Estado, de Cliente e geramos uma nova tabela. Em seguida, o mesmo processo feito anteriormente: adicionar uma chave-primária à nova tabela e relaciona-la criando uma chave-estrangeira na antiga tabela.

Cidade (Codcidade, Nome, Estado).
Cliente (Codcliente, Codcidade, Nome, Endereço, Cep, Telefone).
Venda (Codvenda, Codcliente, Codcidade, Produto, Quantidade, Valorunitario, Valorfinal).

Seguindo com o exemplo, a tabela Cliente encontra-se na 1 forma normal, pois não há mais tabelas aninhadas. Verificando Venda, podemos enxergar mais uma tabela aninhada. Os campos entre colchetes são referente á mesma coisa: Produto de Venda

Venda (Codvenda, Codcliente, Codcidade, [Produto Quantidade, [Valorunitario, Valorfinal).

Na maioria das situações, produtos têm um valor previamente especificado. O Valorunitário depende de Produto. Já a Quantidade (campo entre Produto e Valorunitario) não depende do produto e sim da Venda.

Cidade (Codcidade, Nome, Estado).
Cliente (Codcliente, Codcidade, Nome, Endereço, Cep, Telefone).
Produto (Codproduto, Nome, Valorunitario).
Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, Valorfinal).

Passando a tabela Venda pela primeira forma normal, obtivemos 3 tabelas. Vamos á próxima forma

2 Forma Normal: Verificação de Dependências Parciais
Para uma tabela estar na segunda formal, além de estar na primeira forma ela não deve conter dependências parciais. Um jeito de verificar esta norma é refazer a leitura dos campos fazendo a pergunta: Este campo depende de toda a chave? Se não, temos uma dependência parcial...
Vimos antes o caso Cidade-Estado que gerava uma dependência funcional. É preciso entender este conceito para que você entenda o que é Dependência Parcial.Após a normalização da tabela Venda, acabamos com uma chave composta de 4 campos:

Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, Valorfinal).

A questão agora é verificar se cada campo não-chave depende destas 4 chaves. O raciocínio seria assim:

O primeiro campo não-chave é Quantidade.
Quantidade depende de Codvenda, pois para cada venda há uma quantidade específica de itens.
Quantidade depende de Codvenda e Codcliente, pois para um cliente podem ser feitas várias vendas, com quantidades diferentes.
Quantidade não depende de Cidade. Quem depende de Cidade é Cliente. Aqui está uma dependência parcial.
Quantidade depende de Codproduto, pois para cada produto da Venda á uma quantidade certa.
Quantidade depende de 3 campos, dos 4 que compõe a chave de Venda. Quem sobrou nessa história foi Codcidade. A tabela Cidade já está ligada com Cliente, que já está ligado com Venda. A chave Codcidade em Venda é redundante, portanto podemos eliminá-la.

Venda (Codvenda, Codcliente, Codproduto, Quantidade, Valorfinal).

O próximo campo não-chave é Valorfinal. Verificando Valorfinal, da mesma forma que Quantidade, ele depende de toda a chave de Venda. Portanto vamos á próxima norma.

3 Forma Normal: Verificação de Dependências Transitivas
Para uma tabela estar na segunda formal, além de estar na segunda forma ela não deve conter dependências transitivas. Um jeito de verificar esta norma é refazer a leitura dos campos fazendo a pergunta: Este campo depende de outro que não seja a chave? Se Sim, temos uma dependência transitiva..

No exemplo de Venda, temos um caso de dependência transitiva:

Na tabela Venda, temos Valorfinal. Este campo é o resultado do valor unitário do produto multiplicado pela quantidade, isto é, para um valor final existir ele DEPENDE de valor unitário e quantidade. O Valorunitário está na tabela Produto, relacionada à Venda e Quantidade está na própria Venda. Valorfinal depende destes 2 campos e eles não são campos-chave, o que nos leva a pensar: Se temos valor unitário e quantidade, porque teremos valor final? O valor final nada mais é que o resultado de um cálculo de dados que já está estão no banco, o que o torna um campo redundante.Quando for necessário ao sistema obter o valor final, basta selecionar o valor unitário e multiplicar pela quantidade. Não há porque guardar o valor final em outro campo. Aqui a solução é eliminar o campo Valorfinal.

Cidade (Codcidade, Nome, Estado).
Cliente (Codcliente, Codcidade, Nome, Endereco, Cep, Telefone).
Produto (Codproduto, Nome, Valorunitario).
Venda (Codvenda, Codcliente, Codproduto, Quantidade).

Em tese, agora temos todas as tabelas normalizadas. Ainda restou o caso do campo Estado na tabela Cidade, mas eu deixarei para uma outra ocasião, pois o objetivo aqui é mostrar conceitualmente o processo de normalização do banco de dados.
É muito comum, no processo de normalização enxergamos todas as formas normais ao mesmo tempo. Enquanto separamos as tabelas aninhadas, já conseguimos ver as dependências transitivas e logo mais encontramos uma dependência parcial, tudo assim, ao mesmo tempo. Isso é normal. Só tome cuidado, para não deixar nada passar batido.
Reforçando o recado do artigo anterior: tem muito mais a ser visto sobre as etapas que eu mostrei nessa série. Aqui foi só uma demonstração do que se deve levar em conta ao modelar e construir um banco de dados íntegro, correto e que aproveita os dados da forma mais eficiente possível.

O Modelo Relacional de Dados

Introdução

Objetivo: Na primeira parte deste artigo falei sobre Entidades (tabelas), Atributos (campos) e sobre o conceito de Chave Primária. na segunda parte falei sobre Relacionamentos e tipos de relacionamentos. Nesta terceira parte vamos aprender sobre um dos conceitos mais importantes do modelo relacional de dados: Integridade Referencial. Também mostrarei um exemplo prático de como configurar Relacionamentos e Integridade Referencial no Microsoft Access.

Nota: Os exemplos apresentados utilizarão telas do Microsoft Access e o arquivo de exemplos Northwind.mdb, o qual é instalado juntamente com o Microsoft Access. Este arquivo está disponível, por padrão, no seguinte caminho:
C:\Arquivos de programas\Microsoft Office\Office\Samples

Porém os princípios básicos do modelo relacional aplicam-se a qualquer banco de dados baseado no modelo relacional de dados. Estes bancos de dados são algumas vezes denominados: SGBDR - Sistemas Gerenciadores de Banco de Dados Relacionais.

Integridade Referencial

A Integridade Referencial é utilizada para garantir a Integridade dos dados entre as tabelas relacionadas. Por exemplo, considere um relacionamento do tipo Um-para- Vários entre a tabela Clientes e a tabela Pedidos (um cliente pode fazer vários pedidos). Com a Integridade Referencial, o banco de dados não permite que seja cadastrado um pedido para um cliente que ainda não foi cadastrado. Em outras palavras, ao cadastrar um pedido, o banco de dados verifica se o código do cliente que foi digitado já existe na tabela Clientes. Se não existir, o cadastro do pedido não será aceito. Com o uso da Integridade Referencial é possível ter as seguintes garantias (ainda usando o exemplo entre as tabelas Clientes e Pedidos):
Quando o Código de um cliente for alterado na Tabela Clientes, podemos configurar para o banco de dados atualizar, automaticamente, todos os Códigos do Cliente na Tabela Pedidos, de tal maneira que não fiquem Registros Órfãos, isto é , registros de Pedidos com um Código de Cliente para o qual não existe mais um correspondente na Tabela Clientes. Essa ação é conhecida como "Propagar atualização dos campos relacionados".
Quando um Cliente for excluído da Tabela Clientes, podemos configurar para que o banco de dados exclua, automaticamente, na tabela Pedidos, todos os Pedidos para o Cliente que está sendo Excluído. Essa opção é conhecida como "Propagar exclusão dos registros relacionados".
Essas opções, conforme mostrarei logo em seguida, podem ser configuradas quando da Definição dos Relacionamentos (no exemplo prático mais adiante utilizarei o Microsoft Access, mas estes conceitos são válidos para qualquer banco de dados). Estas opções não são obrigatórias, isto é, podemos optar por não Atualizar ou não Excluir em cascata. A Opção de "Propagar atualização dos campos relacionados" é utilizada na maioria das situações, já a opção de "Propagar exclusão dos registros relacionados" deve ser estudada caso a caso. Por exemplo, se nos quiséssemos manter um histórico com os Pedidos de cada Cliente, não utilizaríamos a opção "Propagar exclusão dos registros relacionados"; caso não nos interessasse manter um histórico dos pedidos, poderíamos utilizar esta opção.
Exemplo prático: Como Criar e Configurar Relacionamentos no Microsoft Access:
Para Definir Relacionamentos no Microsoft Access siga os passos indicados a seguir:
Abra o banco de dados onde estão as tabelas nas quais serão definidos os relacionamentos.
Selecione o comando Ferramentas -> Relacionamentos.
Surgirá a Janela indicada na próxima Figura. Nesta Janela você adicionará as Tabelas que farão parte de algum dos relacionamentos. Para Adicionar uma Tabela, basta marcá-la e dar um clique no botão "Adicionar". Você pode adicionar todas as tabelas de uma única vez. Para isto dê um clique na primeira, libere o mouse, pressione a tecla SHIFT e fique segurando SHIFT pressionado e dê um clique na última tabela. Com isso todas serão selecionadas, agora ao dar um clique no botão Adicionar, todas as tabelas selecionadas serão adicionadas. Caso não queira adicionar todas mas somente algumas e de uma maneira intercalada, ao invés de usar a tecla SHIFT, utilize a tecla CTRL. Com a tecla CTRL uma tabela é selecionada a medida que você vai clicando com o mouse sobre o nome da tabela.

Dê um clique para marcar a Tabela e depois dê um clique no botão Adicionar.

Observe também que os campos Chave Primária aparecem em Negrito no Diagrama dos Relacionamentos.
Este diagrama que exibe as Tabelas e os Relacionamentos entre as tabelas é conhecido como "Diagrama Entidades x Relacionamentos (DER)".
Antes de fechar o Diagrama Entidades x Relacionamentos, dê um clique no botão com o desenhdo do disquete para salvar as alterações que foram feitas. A qualquer momento você pode acessar o Diagrama Entidades x Relacionamentos para fazer alterações ou para revisar os relacionamentos, para isto basta ir no menu Ferramentas e clicar em Relacionamentos.
Observe que, por padrão, o campo "Impor Integridade Referencial" não está marcado. Ao marcá-lo serão habilitadas as Opções de "Propagar atualização dos campos relacionados" e "Propagar exclusão dos registros relacionados".


Observe, também, que o Microsoft Access já definiu este relacionamento como sendo do tipo Um-para-Vários. Isso acontece porque o Microsoft Access identifica o campo CódigoDoCliente na tabela Clientes como sendo do tipo chave primária e na tabela Pedidos como não sendo chave primária, o que automaticamente transforma o Relacionamento como sendo do tipo Um para Vários. Se em ambas as tabelas o campo CódigoDoCliente fosse definido como Chave Primária, o relacionamento, automaticamente, seria do tipo Um-para-Um.

Após marcar as Opções desejadas, basta dar um clique no botão "Criar" e pronto, o Microsoft Access cria o Relacionamento, o qual é indicado através de uma linha entre as duas tabelas (Clientes e Pedidos), com o número 1 no lado da Chave Primária e o Sinal de infinito no lado Vários. Caso você precise alterar as características de um determinado relacionamento, basta dar um duplo clique sobre a linha do relacionamento, que o Microsoft Access abrirá a janela indicada na figura anterior, para que você possa fazer as alterações desejadas. Na Figura a seguir indico o relacionamento já criado entre as tabelas Pedidos e Clientes:

Observe também que os campos Chave Primária aparecem em Negrito no Diagrama dos Relacionamentos.

Este diagrama que exibe as Tabelas e os Relacionamentos entre as tabelas é conhecido como "Diagrama Entidades x Relacionamentos (DER)".

Antes de fechar o Diagrama Entidades x Relacionamentos, dê um clique no botão com o desenhdo do disquete para salvar as alterações que foram feitas. A qualquer momento você pode acessar o Diagrama Entidades x Relacionamentos para fazer alterações ou para revisar os relacionamentos, para isto basta ir no menu Ferramentas e clicar em Relacionamentos.

Conclusão:
Neste terceiro artigo da série, você aprendeu sobre o conceitos de Integridade Referencial, sem dúvidas um dos conceitos mais importantes do Modelo Relacional, juntamente com os conceitos de Relacionamentos, abordados na Parte 2. Na Parte 4 falarei sobre os princípios básicos de normalização de tabelas. Até lá.

O Modelo Relacional de Dados

Introdução

Objetivo: Na primeira parte deste artigo falei sobre Entidades (tabelas), Atributos (campos) e sobre o conceito de Chave Primária. Nesta segunda parte vou abordar os seguintes tópicos:
Relacionamentos entre entidades (tabelas) - conceito


Relacionamentos entre entidades (tabelas) - tipos
Nota: Os exemplos apresentados utilizarão telas do Microsoft Access e o arquivo de exemplos Northwind.mdb, o qual é instalado juntamente com o Microsoft Access. Este arquivo está disponível, por padrão, no seguinte caminho:

C:\Arquivos de programas\Microsoft Office\Office\Samples

Porém os princípios básicos do modelo relacional aplicam-se a qualquer banco de dados baseado no modelo relacional de dados. Estes bancos de dados são algumas vezes denominados: SGBDR - Sistemas Gerenciadores de Banco de Dados Relacionais.

Relacionamentos entre Tabelas

Neste item vou apresentar o conceito de relacionamento entre tabelas, este um conceito fundamental para o Modelo Relacional de Dados. Também falarei sobre os diferentes tipos de relacionamentos existentes. Serão apresentados exemplos práticos.

Conforme descrito na Parte 1, um banco de dados é composto por diversas tabelas, como por exemplo: Clientes, Produtos, Pedidos, Detalhes do Pedido, etc. Embora as informações estejam separadas em cada uma das Tabelas, na prática devem existir relacionamentos entre as tabelas. Por exemplo: Um Pedido é feito por um Cliente e neste Pedido podem existir diversos itens, itens que são gravados na tabela Detalhes do Pedido. Além disso cada Pedido possui um número único (Código do pedido), mas um mesmo Cliente pode fazer diversos pedidos e assim por diante.

Em um banco de dados, precisamos de alguma maneira para representar estes relacionamentos da vida Real, em termos das tabelas e de seus atributos. Isto é possível com a utilização de "Relacionamentos entre tabelas", os quais podem ser de três tipos:
Um para Um

Um para Vários

Vários para Vários
Relacionamento do Tipo Um para Um:

Esta relação existe quando os campos que se relacionam são ambos do tipo Chave Primária, em suas respectivas tabelas. Cada um dos campos não apresenta valores repetidos. Na prática existem poucas situações onde utilizaremos um relacionamento deste tipo. Um exemplo poderia ser o seguinte: Imagine uma escola com um Cadastro de Alunos na tabela Alunos, destes apenas uma pequena parte participa da Banda da Escola. Por questões de projeto do Banco de Dados, podemos criar uma Segunda Tabela "Alunos da Banda", a qual se relaciona com a tabela Alunos através de um relacionamento do tipo Um para Um. Cada aluno somente é cadastrada uma vez na Tabela Alunos e uma única vez na tabela Alunos da Banda. Poderíamos utilizar o Campo Matrícula do Aluno como o Campo que relaciona as duas Tabelas.

Importante: O campo que relaciona duas tabelas deve fazer parte, ter sido definido, na estrutura das duas tabelas.

Na tabela Alunos da Banda poderíamos colocar apenas o Número da Matrícula do aluno, além das informações a respeito do Instrumento que ele toca, tempo de banda, etc. Quando fosse necessário buscar as informações tais como nome, endereço, etc, estas podem ser recuperadas através do relacionamento existente entre as duas tabelas, evitando, com isso, que a mesma informação (Nome, Endereço, etc) tenha que ser duplicada nas duas tabelas, inclusive aumentando a probabilidade de erros de digitação.

Na Figura a seguir vemos o exemplo de um Relacionamento do tipo Um para Um entre as tabelas Alunos e Alunos da Banda.

                     Figura 1: Relacionamento Um para Um entre as Tabelas Alunos e Alunos da Banda.

Com a criação deste relacionamento estamos evitando a repetição desnecessária de informações em diferentes tabelas.

Relacionamento do Tipo Um para Vários:

Este é, com certeza, o tipo de relacionamento mais comum entre duas tabelas. Uma das tabelas (o lado um do relacionamento) possui um campo que é a Chave Primária e a outra tabela (o lado vários) se relaciona através de um campo cujos valores relacionados podem se repetir várias vezes.
Considere o exemplo entre a tabela Clientes e Pedidos. Cada Cliente somente é cadastrado uma única vez na tabela de Clientes (por isso o campo Código do Cliente, na tabela Clientes, é uma chave primária, indicando que não podem ser cadastrados dois clientes com o mesmo código), portanto a tabela Clientes será o lado um do relacionamento. Ao mesmo tempo cada cliente pode fazer diversos pedidos, por isso que o mesmo Código de Cliente poderá aparecer várias vezes na tabela Pedidos: tantas vezes quantos forem os pedidos que o Cliente tiver feito. Por isso que temos um relacionamento do tipo Um para Vários entre a tabela Clientes e Pedidos, através do campo Código do Cliente, indicando que um mesmo Cliente pode realizar diversos (vários) pedidos.
Na próxima figura vemos um exemplo de um Relacionamento Um para Vários entre as Tabelas Clientes e Pedidos do banco de dados Pedidos.mdb, através do campo código do cliente:

Observe que o lado Vários do relacionamento é representado pelo símbolo do infinito (¥). Esta é a representação utilizada no Microsoft Access. Diferentes representações poderão ser utilizadas por outros bancos de dados.
No lado Um do relacionamento o campo é definido como uma Chave Primária (Campo CódigoDoCliente na tabela Clientes) e no lado Vários não (campo CódigoDoCliente na tabela Pedidos), indicando que no lado vários o Código do Cliente pode se repetir várias vezes, o que faz sentido, uma vez que um mesmo cliente pode fazer diversos pedidos.

IMPORTANTE: Observe que o campo que é o lado vários do relacionamento não pode ser definido como chave primária. Lembrando do conceito de Chave Primária, apresentado na Parte 1: Chave Primária é o campo no qual não podem haver valores repetidos. Ora, se o campo está no lado "vários", significa que ele poderá ter o seu valor repetido em vários registros. Por exemplo, na tabela pedidos, poderá haver vários registros para o mesmo cliente. Se o campo terá que ter valores repetidos, então ele não pode ser definido como chave primária.
No Banco de Dados NorthWind.mdb, Northwind.mdb, o qual é instalado juntamente com o Microsoft Access. Este arquivo está disponível, por padrão, no seguinte caminho:
C:\Arquivos de programas\Microsoft Office\Office\Samples
Existem diversos outros exemplos de relacionamentos do tipo Um para Vários, conforme descrito na Próxima Tabela:

       Tipo                               Lado Um                                                         Lado Vários
Um para Vários CódigoDoFornecedor na tabela Fornecedores CódigoDoFornecedor na tabela Produtos
Um para Vários CódigoDaCategoria na tabela Categorias CódigoDaCategoria na tabela Produtos
Um para Vários CódigoDoProduto na tabela Produtos CódigoDoProduto na tabela Detalhes do Pedido
Um para Vários CódigoDoFuncionário na tabela Funcionários CódigoDoFuncionário na tabela Pedidos
Um para Vários NúmeroDoPedido na tabela Pedidos NúmeroDoPedido na tabela Detalhes do Pedido
Um para Vários CódigoDaTransportadora na tabela Transportadoras Via na tabela Pedidos
Um para Vários CódigoDoCliente na tabela Clientes CódigoDoCliente na tabela Pedidos

Em um dos próximos artigos mostrarei como implementar, na prática, estes relacionamentos. Algumas observações importantes sobre relacionamentos:
O Nome dos Campos envolvidos no Relacionamento, não precisa ser, necessariamente, o mesmo, conforme indicado pelo relacionamento entre os campos CódigoDaTransportadora e Via, na tabela anterior. O tipo dos campos é que precisa ser o mesmo, por exemplo, se um dos campos for do tipo Texto, o outro também deverá ser do tipo Texto.
Sempre o Lado um do Relacionamento deve ser uma chave primária, já o lado vários não pode ser uma chave Primária.
De Preferência, antes de Criar os Relacionamentos verifique se o tipo dos campos a serem relacionados é o mesmo, além de características como máscaras de entrada e formato.
Relacionamento do tipo Vários para Vários:
Este tipo de relacionamento "aconteceria" em uma situação onde em ambos os lados do relacionamento os valores poderiam se repetir. Vamos considerar o caso entre Produtos e Pedidos. Posso ter Vários Pedidos nos quais aparece um determinado produto, além disso vários Produtos podem aparecer no mesmo Pedido. Esta é uma situação em que temos um Relacionamento do Tipo Vários para Vários.
Na prática não é possível implementar um relacionamento deste tipo, devido a uma série de problemas que seriam introduzidos no modelo do banco de dados. Por exemplo, na tabela Pedidos teríamos que repetir o Número do Pedido, Nome do Cliente, Nome do Funcionário, Data do Pedido, etc para cada item do Pedido.
Para evitar este tipo de problema é bastante comum "quebrarmos" um relacionamento do tipo Vários para Vários em dois relacionamento do tipo Um para Vários. Isso é feito através da criação de uma nova tabela, a qual fica com o lado Vários dos relacionamentos. No nosso exemplo vamos criar a tabela Detalhes do Pedido, onde ficam armazenadas as informações sobre os diversos itens de cada pedido, aí ao invés de termos um relacionamento do tipo Vários para Vários, teremos dois relacionamentos do tipo um para vários, conforme descrito pela próxima tabela:

       Tipo                                Lado Um                                                  Lado Vários
Um para Vários CódigoDoProduto na tabela Produtos CódigoDoProduto na tabela Detalhes do Pedido
Um para Vários NúmeroDoPedido na tabela Pedidos NúmeroDoPedido na tabela Detalhes do Pedido

Na figura abaixo temos a representação dos dois relacionamentos Um para Vários, resultantes da quebra do relacionamento vários-para-vários:

Tabela Detalhes do Pedido ficou com o lado Vários dos Relacionamentos.

Esta situação em que um relacionamento um para Vários é "quebrado" em dois Relacionamentos do tipo Um para Vários é bastante comum. Diversas vezes utilizamos esta técnica para eliminar uma série de problemas no Banco de Dados, tais como informação repetida e inconsistência de Dados.Agora que já conhecemos os Tipos de Relacionamentos existentes, na próxima Parte 3, falarei sobre o conceito de Integridade Referencial como uma maneira de Garantir a Consistência dos Dados.

Conclusão:

Neste segundo artigo da série, você aprendeu sobre os conceitos de relacionamentos, sem dúvidas um dos conceitos mais importantes do Modelo Relacional. Implementar um banco de dados sem se preocupar com um projeto cuidados dos relacionamentos, é garantia certa de "encrenca" mais adiantes. São consultas que retornam dados inesperados, são relatórios que retornam valores "absurdos" e por aí vai. É fundamental que os profissionais de desenvolvimento e de administração de banco de dados entendem o quão impotante é planejar o banco de dados, cuidadosamente, definindo quais tabelas farão parte do banco de dados, quais os campos de cada tabela, quais campos serão chave primária e qual o relacionamento entre as tabelas. Muitos acham que esta é uma "perda de tempo", que o bom mesmo é sentar e começar a implementar o banco de dados, depois "a gente vê o que dá". Ledo engano. Não é perda de tempo, muito pelo contrário, é um ganho de tempo e principalmente de qualidade no produto final. Quanto tempo é perdido depois, tentando corrigir erros e incosistências que muitas vezes são decorrentes de um banco de dados mal projetado? Uma boa leitura a todos e até a Parte 3.

O Modelo Relacional de Dados

Introdução

Objetivo: Em uma série de cinco artigos, apresentarei alguns conceitos básicos sobre Bancos de Dados, mais especificamente sobre o Modelo Relacional de Dados. Para a melhor utilização, ou seja, para uma utilização eficiente de bancos de dados como o Microsoft Access, SQL Server, ORACLE, DB2 ou qualquer outro banco de dados relacional, é importante o conhecimento e correto entendimento dos conceitos apresentados nesta série de artigos. Vou abordar os seguintes Conceitos:

Entidades e atributos

Chave primária

Relacionamentos entre entidades (tabelas)

Integridade Referencial

Normalização de tabelas

Um Problema Proposto

Arquitetura do Microsoft Access.

Nota: Os exemplos apresentados utilizarão telas do Microsoft Access. Porém os princípios básicos do modelo relacional aplicam-se a qualquer banco de dados baseado no modelo relacional de dados. Estes bancos de dados são algumas vezes denominados: SGBDR - Sistemas Gerenciadores de Banco de Dados Realacionais.

Entidades e Atributos:

Toda a Informação de um banco de dados relacional é armazenada em Tabelas, que na linguagem do modelo relaciona, também são chamadas de Entidades. Por exemplo, posso ter uma Tabela "Clientes", onde seriam armazenadas informações sobre os diversos clientes.

Sobre cada um dos clientes podem ser armazenadas diversas informações tais como:

Nome
RG
CPF
Rua
Bairro
Telefone
CEP
Data de Nascimento

Essas diversas características de cada Cliente são os "Atributos" da entidade Cliente, também chamados de campos da tabela Cliente.
"O Conjunto de todos os Atributos de um cliente e os valores dos atributos é o que forma o Registro do Cliente".
Com isso temos uma Tabela que é constituída por um conjunto de Registros (uma linha completa com informações sobre o cliente) e cada Registro formado por um conjunto de atributos (Nome, Endereço, etc).

Resumindo:
Entidade ou Tabela: Um conjunto de Registros.
Campos ou Atributos: Características Individuais da tabela.
Considere o Exemplo da figura abaixo, mostro uma tabela com cadastro de Clientes com os seus diversos Campos (atributos):
  
                              
Figura 1: Tabela Cliente e seus Campos - CódigoDoCliente, NomeDaEmpresa e assim por diante.

No exemplo da figura anterior temos entidade: "Clientes" e seus diversos atributos: "Código do Cliente", "Nome da Empresa", "Nome do Contato", "Cargo do Contato", "Endereço", etc. Em cada linha temos um conjunto de atributos e seus valores. Cada linha forma um Registro. Cada Coluna é um atributo da Tabela Clientes.
Um dos grandes desafios em se projetar um Banco de Dados com sucesso é a correta Determinação das Entidades que existirão no Banco de Dados, bem como dos Atributos de Cada Entidade.

Chave Primária
Objetivo: Neste item falarei sobre o conceito de Chave Primária e a sua importância no Modelo Relacional de dados.

Chave Primária
O Conceito de "Chave Primária" é fundamental para o correto entendimento de como funciona um Banco de Dados baseado no modelo relacional. Vamos entender o que significa um campo ser a Chave Primária de uma Tabela e como tornar um Campo a Chave Primária de uma Tabela.

"Ao Definirmos um Campo como sendo uma Chave Primária, estamos informando ao Microsoft Access que não podem existir dois registros com o mesmo valor no campo que é a Chave Primária, ou seja, os valores no campo Chave Primária precisam ser únicos".
Por exemplo, se defino um campo "Número da Identidade", da tabela Clientes, como sendo um campo do tipo Chave Primária, estou dizendo que não podem ser cadastrados dois clientes com o mesmo valor no campo "Número da Identidade". Na prática estou garantindo que não possam ser cadastrados dois clientes com o mesmo Número de Identidade".
Em outras palavras poderíamos dizer que o Campo Chave Primária identifica de Maneira Única cada Registro de uma Tabela, isto é, de posse do valor da Chave Primária somente localizaremos um registro com aquele valor no campo Chave Primária. Outros exemplos de campos que podem ser definidos como chaves primária:
Campo CPF em uma tabela de cadastro de clientes.
Campo CNPJ em uma tabela de cadastro de fornecedores.
Matrícula do aluno em uma tabela de cadastro de alunos.
Código da Peça em uma tabela de cadastro de peças.
Matrícula do funcionário em uma tabela de cadastro de funcionários.
Número do pedido em uma tabela de cadastro de pedidos

Este é um conceito muito importante, pois conforme veremos mais adiante os conceitos de Integridade Referencial e Normalização estão diretamente ligados ao conceito de Chave Primária. Na próxima figura apresento um exemplo da tabela Cliente onde o Campo "Código do Cliente" é definido como uma Chave Primária. Observe que não existem dois clientes com o Mesmo Código.

Após ter definido um campo como sendo a Chave Primária da tabela, o próprio banco de dados (quer seja Access, SQL Server, ORACLE ou qualquer outro), garante que não sejam inseridos dados duplicados no campo que é a chave primária. Por exemplo, se o usuário tentar cadastrar um pedido com o mesmo número de um pedido já existente, o registro não será cadastrado e uma mensagem de erro será emitida.

Um último detalhe importante para lembrarmos é que a Chave Primária pode ser formada pela combinação de Mais de Um Campo. Podem existir casos em que um único campo não é capaz de atuar como chave primária, pelo fato deste apresentar valores repetidos. Nestes casos podemos definir uma combinação de 2 ou mais campos para ser a nossa chave primária.

Além disso, uma tabela somente pode ter uma Chave Primária, seja ela simples ou composta. Ou seja, não posse definir dois ou mais campos de uma tabela para serem cada um, uma chave primária separada. Não confundir com o caso de uma chave primária composta, onde a união de dois ou mais campos é que forma a única chave primária da tabela. Ou seja, cada tabela pode ter uma única chave primária.

Conclusão:

Neste primeiro artigo da série, você aprendeu sobre os conceitos de entidades (tabelas), atributos (campos) e registros. Estes são os elementos básicos do modelo relacional de dados. Em seguida falei sobre o conceito de Chave Primária. Falei sobre as características do campo chave primária e da possiblidade de existir uma chave primária composta por dois ou mais campos. No próximo artigo da séria você aprenderá sobre "Relacionamentos entre Tabelas".

Conceitos Básicos

Segundo Korth, um banco de dados “é uma coleção de dados inter-relacionados, representando informações sobre um domínio específico”, ou seja, sempre que for possível agrupar informações que se relacionam e tratam de um mesmo assunto, posso dizer que tenho um banco de dados.
Podemos exemplificar situações clássicas como uma lista telefônica, um catálogo de CDs ou um sistema de controle de RH de uma empresa.
Já um sistema de gerenciamento de banco de dados (SGBD) é um software que possui recursos capazes de manipular as informações do banco de dados e interagir com o usuário. Exemplos de SGBDs são: Oracle, SQL Server, DB2, PostgreSQL, MySQL, o próprio Access ou Paradox, entre outros.
Por último, temos que conceituar um sistema de banco de dados como o conjunto de quatro componentes básicos: dados, hardware, software e usuários. Date conceituou que “sistema de bancos de dados pode ser considerado como uma sala de arquivos eletrônica”. A Figura 1 ilustra os componentes de um sistema de banco de dados.

Os objetivos de um sistema de banco de dados são o de isolar o usuário dos detalhes internos do banco de dados (promover a abstração de dados) e promover a independência dos dados em relação às aplicações, ou seja, tornar independente da aplicação, a estratégia de acesso e a forma de armazenamento.

Abstração de dados

O sistema de banco de dados deve garantir uma visão totalmente abstrata do banco de dados para o usuário, ou seja, para o usuário do banco de dados pouco importa qual unidade de armazenamento está sendo usada para guardar seus dados, contanto que os mesmos estejam disponíveis no momento necessário.

Esta abstração se dá em três níveis (Figura 2):

Nível de visão do usuário: as partes do banco de dados que o usuário tem acesso de acordo com a necessidade individual de cada usuário ou grupo de usuários;
Nível conceitual: define quais os dados que estão armazenados e qual o relacionamento entre eles;
Nível físico: é o nível mais baixo de abstração, em que define efetivamente de que maneira os dados estão armazenados.

Projeto de banco de dados

Todo bom sistema de banco de dados deve apresentar um projeto, que visa a organização das informações e utilização de técnicas para que o futuro sistema obtenha boa performance e também facilite infinitamente as manutenções que venham a acontecer.

O projeto de banco de dados se dá em duas fases:

Modelagem conceitual;
Projeto lógico.
Estas duas etapas se referem a um sistema de banco de dados ainda não implementado, ou seja, que ainda não exista, um novo projeto. Para os casos em que o banco de dados já exista, mas é um sistema legado, por exemplo, ou um sistema muito antigo sem documentação, o processo de projeto de banco de dados se dará através da utilização de uma técnica chamada de Engenharia Reversa, que será visto em outra oportunidade.

Modelo conceitual;

É a descrição do BD de maneira independente ao SGBD, ou seja, define quais os dados que aparecerão no BD, mas sem se importar com a implementação que se dará ao BD. Desta forma, há uma abstração em nível de SGBD.
Uma das técnicas mais utilizadas dentre os profissionais da área é a abordagem entidade-relacionamento (ER), onde o modelo é representado graficamente através do diagrama entidade-relacionamento (DER) (Figura 3).
                             

O modelo acima, entre outras coisas, nos traz informações sobre Alunos e Turmas. Para cada Aluno, será armazenado seu número de matrícula, seu nome e endereço, enquanto para cada turma, teremos a informação de seu código, a sala utilizada e o período.

Modelo Lógico

Descreve o BD no nível do SGBD, ou seja, depende do tipo particular de SGBD que será usado. Não podemos confundir com o Software que será usado. O tipo de SGBD que o modelo lógico trata é se o mesmo é relacional, orientado a objetos, hierárquico, etc.

Abordaremos o SGBD relacional, por serem os mais difundidos. Nele, os dados são organizados em tabelas (Quadro 1).

Aluno
mat_aluno nome endereco
1 Cecília Ortiz Rezende Rua dos Ipês, 37
2 Abílio José Dias Avenida Presidente Jânio Quadros, 357
3 Renata Oliveira Franco Rua Nove de Julho, 45

Turma
cod_turma sala periodo
1 8 Manhã
2 5 Noite

Quadro 1. Exemplo de tabelas em um SGBD relacional.

O modelo lógico do BD relacional deve definir quais as tabelas e o nome das colunas que compõem estas tabelas.Para o nosso exemplo, poderíamos definir nosso modelo lógico conforme o seguinte:

Aluno(mat_aluno, nome, endereco)
Turma (cod_turma, sala, periodo)

É importante salientar que os detalhes internos de armazenamento, por exemplo, não são descritos no modelo lógico, pois estas informações fazem parte do modelo físico, que nada mais é que a tradução do modelo lógico para a linguagem do software escolhido para implementar o sistema.