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á.