Avaliação: | Publicado em: 06/01/2007

Modelagem de Dados 5 - Abordagem Relacional

Mauri Gonçalves é graduado em Análise de Sistemas pela Faculdade de Ciências Sociais Aplicadas de Cascavel (PR). Atua como Analista de Sistemas em São Paulo-SP.

Modelagem de Dados 5 - Abordagem Relacional

A grande maioria dos Sistemas Gerenciadores de Banco de Dados (ou simplesmente 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 possível 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, você deve considerar fatores como:
    - Diminuir o número de acessos a disco: A cada consulta á tabela, todos os campos da linha são carregados para a memória, mesmo que você utilize apenas 1 deles)
    - Evitar junções: Em muitas consultas a banco, são feitas junções de dados em várias linhas de tabelas. Utilize todos os dados necessários de preferência 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 você acabará juntado algumas tabelas que você dividiu durante a modelagem lógica. 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: Tecnicamente 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 já 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 seguintes 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 é razoavelmente 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 você deve fazer isso, vou mostrar um exemplo:
Tem-se a entidade Pessoa com os atributos: Código, 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:
Hipoteticamente 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 muito mais complexas que essa são feitas com muita freqüência.

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. Nos próximos artigos seguiremos com a próxima etapa da tradução: Relacionamentos e Atributos.. 

Grande abraço e até lá.

• Modelagem de Dados 4 - Validação do modelo ER
• Modelagem de Dados 3 - Os Relacionamentos
• Modelagem de Dados 2 - As Entidades
• Modelagem de Dados 1 - Visão Geral