A grande maioria dos Sistemas Gerenciadores de Banco de Dados (ou simplemente SGBD's) são Relacionais. Os bancos Relacionais são compostos por Tabelas ou Relações. Este termo "Relações" é mais usado na literatura original sobre abordagem relacional (daí a denominação "Relacional'), enquanto que "Tabela" é um termo mais prático e mais usado em produtos comerciais. Para não haver confusão de conceitos, vou me usar a terminologia "Tabela".

Uma Tabela é um conjunto não ordenado de linhas ou (tuplas - terminologia original) e cada linha possui campos (atributos). Cada campo é identificado por um nome de campo (ou nome de atributo) e o conjunto de linhas de uma tabela, que possuem o mesmo nome chama-se coluna. Para muitos, nada disso é novidade, mas não nos custa nada lembrar os conceitos.

Algumas características específicas de uma tabela de banco de dados:

- As linhas da tabela não são ordenadas. A recuperação de linhas em uma tabela acontece arbitrária, ou seja, a recuperação será da forma como está no banco e pronto, a não ser que a ordem seja especificada pelo programador na sua consulta.

- Os valores de campo de uma tabela de banco de dados são mono-valorados. Pode-se apenas ter 1 valor em um campo, não sendo possivel armazenar "coleções" como Arrays (ou Vetores) por exemplo.

- A linguagem de consulta ao banco de dados permite o acesso por qualquer critério envolvendo os campos de uma ou mais linhas. Em um arquivo de dados por exemplo é necessário um índice ou esquema de ponteiros para buscar algum valor. Na verdade índices também existem nos bancos de dados, mas isso não é considerado pelo programador nas consultas ás tabelas.

Um item primordial quando falamos entre relacionamento entre linhas de tabelas é a CHAVE.  A chave primária é formada por um ou mais campos de uma tabela e serve como identificador de uma linha. Porém a chave primária deve ser sempre mínima, ou seja, ser composta pelo menor número de campos possível (no mínimo 1). Veremos mais adiante o uso de chaves com mais de um campo, que recebem o nome de "chave composta".

Vistos os conceitos básicos de um banco relacional, temos que considerar alguns pontos antes de iniciarmos a transformação de um modelo ER em um modelo físico para o banco de dados:

- O modelo ER não considera implementação com nenhum SGBD. É muito comum, surgirem modificações no esquema lógico para possibilitar a criação do modelo físico e usar os recursos do SGBD.

- Ao construir o seu banco físico, voce deve considerar fatores como:

    - Diminuir o número de acessos a disco: A cada consulta á tabela, todas os campos da linha são carregados para a memória, mesmo que voce utilize apenas 1 deles)

    - Evitar junções: Em muitas consultar a banco, são feitas junções de dados em várias linhas de tabelas. Utilize todos os dados necessários de preferencia em uma única linha diminuindo o número de junções, pois uma junção acaba envolvendo vários acessos a disco.

    - Diminuir o número de chaves primárias: Fatalmente voce acabará juntado algumas tabelas que você dividiu durante a modelagem lógico. Isso porque a presença de chaves em locais diferentes, armazenando a mesma informação acaba virando mais espaço em disco utilizado e mais processamento.

    - Evitar campos opcionais: Técnicamente um campo vazio no banco de dados não ocupa espaço em disco, devido ás técnicas de compressão de dados existentes nos SGBDs de hoje. Mas o problema surge quando a obrigatoriedade ou não do preenchimento de um campo depende do valor de outro campo.

Este fator acaba sendo resolvido via programação, ou seja, pelo sistema que vai acessar aquele banco e isso deve ser evitado. Algumas medidas de integridade de dados podem ser tomadas ja no banco, deixando o mínimo de campos que podem assumir o valor NULL.

A transformação do modelo ER em um modelo relacional segue as seguinte etapas:

- Tradução de Entidades e Atributos
- Tradução de Relacionamentos e respectivos atributos
- Tradução de generalizações/especializações

Inicialmente, a tradução de entidades é razoávelmente obvia: uma entidade gera uma tabela. Cada atributo da entidade gera uma coluna e os atributos identificadores da entidade tornam-se chave primária. Essa é uma tradução inicial. No decorrer da transformação entre modelos, algumas tabelas ainda poderão ser fundidas ou divididas.

Mesmo assim, não recomendável apenas transcrever os nomes de atributos como nomes dos campos. Lembre que agora estamos falando de tabela física, de campos que serão acessados via programação ou seja, temos agora uma nova visão da situação. É nessa fase que, por questões de boa prática e organização no processo de modelagem deseja-se que sejam definidos alguns "padrões" para nomes de campos, abreviaturas e sempre primar por nomes curtos para os campos, ou seja das colunas da tabela.

Para deixar mais claro a forma como voce deve fazer isso, vou mostrar um exemplo:

Tem-se a entidade Pessoa com os atributos: Codigo, Nome, Endereço e Data de Nascimento. Código é o atributo identificador. Um exemplo de "tradução" dos campos seria:

Tabela: Pessoa - Campos: CodPessoa, NomePess, EnderecoPess, DataNascPess

Utilizei o seguinte padrão:

- Para a chave primária, utilizei o prefixo "Cod" + o nome da tabela.
- Para os demais campos utilizei o mesmo nome + o sufixo "Pess" em todos eles, identificando-os como sendo da tabela Pessoa.

Mas há uma boa justificativa para esse sufixo "Pess" nos nomes:
Ipotéticamente em uma instrução SQL pode haver uma junção da tabela Pessoa com a tabela Departamento. Departamento também possui um campo Nome. É recomendável não utilizar o mesmo nome de campo em tabelas diferentes para não gerar a seguinte situação:

SELECT Pessoa.Nome, Departamento.Nome FROM Pessoa, Departamento (...);

Na seleção SQL de campos o mesmo nome, deve-se especificar o nome da tabela de origem, o que pode tornar a cláusula muito longa, visto que consultas muitos mais complexas que essa são feitas com muita frequencia.

SELECT NomePess, NomeDept FROM Pessoa, Departamento (...); 
A utilização do sufixo para os mesmos campos de tabelas diferentes, nos poupa o trabalho de incluir o nome da tabela de origem, tornando a cláusula SQL mais limpa e legível, além de tornar o campo reconhecido em qualquer consulta: (Todos os campos com final "Pess" serão reconhecidos como sendo da tabela Pessoa)

Esse exemplo mostra que vários fatores estão envolvidos na transformação para o modelo relacional. No proximo artigos seguiremos com a proxima etapa da tradução: Relacionamentos e Atributos.. 

Grande abraço e até lá.