Projeto Lógico

Segundo Silberschatz, Korth e Sudarshan (2006), na fase do projeto lógico, o projetista mapeia o esquema conceitual de alto nível para o modelo de dados de implementação do sistema de banco de dados que será usado.

Os modelos lógicos mais utilizados pertencem a três classes: relacional, redes e hierárquico. O modelo de dados de implementação normalmente usado é o modelo de dados relacional, que foi definido anteriormente. Ele é amplamente utilizado devido à sua simplicidade, o que facilita o trabalho do projetista.

Nesta etapa, o projetista, mapeia o esquema conceitual definido, usando o modelo entidade-relacionamento e o transforma em um esquema de relação.

Heuser (2009) possui a mesma visão ao afirmar que a abordagem ER é voltada à modelagem de dados de forma independente do SGBD (Sistema Gerenciador de Banco de Dados) considerado, sendo adequada para a construção do modelo conceitual. Já a abordagem relacional modela os dados no nível SGBD relacional.

2.6.2.1 Modelo Relacional

Um banco de dados relacional consiste em uma coleção de tabelas, cada uma com um nome único atribuído. Uma linha única em uma tabela representa uma relação entre um conjunto de valores (SILBERSCHATZ, KORTH E SUDARSHAN, 2006).

3.6.2.1.1 Tabelas e Chaves

Heuser (2009) define tabela como um conjunto não ordenado de linhas (ou tuplas). Cada linha é composta por uma serie de campos (valor de atributo) que reflete uma informação.

Cada campo é identificado por um nome de campo. Conforme apresentado no Quadro 1, os nomes de campo são representados no cabeçalho da tabela. O conjunto de campos homônimos de todas as linhas forma uma coluna (HEUSER, 2009).

Quadro 1 – Tabela Empregado

CodigoEmp Nome CodigoDepto CategFuncional

E5 Souza D1 C5

E3 Santos D2 C5

E2 Silva D1 C2

E1 Soares D1 -

Fonte: adaptado de Heuser, 2009.

As chaves identificam as linhas e estabelecem relações entre as linhas de tabelas em um banco de dados relacional. Silberschatz, Korth e Sudarshan (2006) declara que é preciso ter uma maneira de especificar como as tuplas dentro de uma determinada tabela são distinguidas, ou seja, nenhum par de tuplas em uma tabela pode ter exatamente o mesmo valor para todos os atributos.

Existem, pelo menos, três tipos de chaves em um banco de dados relacional: chave primária, chave alternativa e chave estrangeira.

Segundo Heuser (2009), a chave primária é uma coluna ou uma combinação de colunas cujos valores distinguem uma linha das demais dentro de uma tabela. No exemplo do Quadro 1, a chave primária é a coluna do CódigoEmp.

As chaves primárias devem ser escolhidas de modo que seja previsto que seus valores nunca, ou muito raramente, sejam modificados. (SILBERSCHATZ, KORTH E SUDARSHAN, 2006). O endereço de uma pessoa, por exemplo, não deve ser parte da chave primária, já que pode ser alterado. Por outro lado, o CPF ou RG oferecem a garantia de não mudar.

Uma chave estrangeira é uma coluna ou combinação de coluna, cujos valores sejam pertencentes necessariamente a uma chave primaria de outra tabela.

No Quadro 2, a coluna CodigoDepto da tabela Emp é uma chave estrangeira em relação à chave primária da tabela Dept (HEUSER, 2009).

Quadro 2 – Chave estrangeira

Fonte: adaptado de Heuser, 2009.

Quando mais de uma coluna ou combinações de colunas podem servir para distinguir uma linha das demais. Uma das colunas (ou combinação de colunas) é escolhida como chave primária, as demais são denominadas chaves alternativas (HEUSER, 2009).

No Quadro 2 – Chave estrangeira, na tabela Emp, mais de uma coluna pode ser escolhida como chave primária, CodEmp e CPF. Como a primeira foi escolhida como chave primária, chama-se a coluna CPF de chave alternativa.

2.6.2.1.2 Domínios e valores vazios

O domínio de atributos representa o conjunto de valores que ele pode apresentar, dependendo do tipo de dado que o define. Alguns atributos não geram dúvidas quanto aos dados que devem representá-los (MECENAS E OLIVEIRA, 2005). Por exemplo, não se pensaria em descrever um atributo responsável por armazenar o nome de uma pessoa como um tipo de dado inteiro.

Heuser (2009) afirma que além de descrever o tipo de dados, deve ser especificado se os campos das colunas podem estar vazios (null, em inglês) ou não. Estar vazio significa que o campo não recebeu valor de seu domínio.

Dept CodigoDepto NomeDepto D1 Compras D2 Engenharia D3 Vendas Emp

CodEmp Nome CodigoDepto CategFuncional CPF

E1 Soares D1 - 132.121.331-20

E2 Silva D1 C2 891.221.111-11

E3 Santos D2 C5 341.511.775-45

2.6.2.1.3 Restrições de integridade

Heuser (2009) afirma que um dos objetivos primordiais de um SGBD é a manutenção da integridade de dados sob seu controle. Dizer que os dados estão íntegros significa dizer que eles refletem corretamente a realidade e que são consistentes entre si.

“As restrições de integridade são o meio adequado de assegurar que as alterações realizadas no banco de dados não levem à perda da consistência dos dados.” (MECENAS E OLIVEIRA, 2005 p. 106). Costuma-se consideras as seguintes categorias:

a) Integridade de domínio: especificam que o valor de um campo deve obedecer a definições de valores admitidos para a coluna (domínio da coluna). Essa integridade impõe estradas válidas, restringindo o tipo, o formato ou os valores possíveis;

b) Integridade de vazio: uma restrição NOT NULL indica que uma coluna, em momento algum, poderá apresentar um valor desconhecido. Em contrapartida a restrição NULL oferece a coluna a condição de apresentar ou não algum valor. Campos que compõem a chave primária sempre devem ser diferentes de vazio;

c) Integridade de chave: trata-se da restrição que define que os valores da chave primária e alternativa devem ser únicos. A restrição PRIMARY KEY aplicada a uma coluna, a promove à condição de chave primária;

d) Integridade referencial: é a restrição que define que os valores dos campos que aparecem em uma chave estrangeira devem aparecer na chave primária da tabela referenciada. Em termos práticos, a integridade referencial (FOREING KEY) diz respeito ao conjunto de ações tomadas pelo SGBD para manter íntegros os relacionamentos existentes entre os dados.

2.6.2.1.4 Esquema do modelo relacional

Existem duas notações possíveis para esquematizar o modelo relacional de banco de dados. A primeira, a textual, é mais simples, entretanto incompleta, utiliza-se quando não se deseja entrar no maior nível de detalhe. A notação para as tabelas do Quadro 2 seria a seguinte:

Emp (CodEmp, Nome, CodigoDepto, CategFuncional, CPF) CodigoDepto referencia Dept

Dept (CodigoDepto, Nome)

Outra alternativa é o esquema diagramático que, segundo Heuser (2009), está organizado como descrito a seguir.

a) Cada tabela é representada por um retângulo;

b) As colunas que compõem a tabela são listadas dentro do retângulo representativo da tabela. Muitas vezes, notações adicionais indicam o domínio de cada domínio. Também é mostrada a indicação da coluna que compõe a chave primaria. As chaves primárias são representadas pela sigla pk (primary key – chave primária);

c) As setas representam as chaves estrangeiras. As colunas que compõem as chaves estrangeiras são indicadas pela sigla fk (de foreing key –chave estrangeira). A Figura 20 representa este modelo; d) Pode-se considerar também inserir integridade referencial e se o

campo pode ser nulo.

Figura 20 – Esquema diagramático do banco de dados do Quadro 2

Dept CodigoDepto INTEGER <pk> Nome VARCHAR(40) Emp CodEmp INTEGER <pk> CodigoDept INTEGER <fk> Nome VACHAR(40) CategFuncional INTEGER CPF VACHAR(40)

2.6.2.2 Transformação entre os modelos

A transformação de um modelo ER em um modelo relacional significa transformar um modelo mais abstrato para um modelo que contém mais detalhes de implementação. A Figura 21 resume os passos do projeto lógico.

Figura 21 – Visão geral do projeto lógico

transformação ER para relacional Modelo ER (nível conceitual) Modelo relacional (nível lógico) Refinamento do modelo relacional Conhecimento sobre a aplicação

Fonte: adaptado de Heuser, 2009.

Heuser (2009) define três princípios básicos que permitem uma boa performance de instruções de consulta e alteração do banco de dados, além de obter um banco de dados que simplifique o desenvolvimento e a manutenção de aplicações, são eles:

a) Evitar junções desnecessárias. As junções tendem a degradar a performance do sistema. Procurar ter os dados necessários a uma consulta em uma única linha.

b) Diminuir o tamanho das chaves primárias. Os índices ocupam espaço considerável no disco e muitos índices podem exigir diversos acessos ao disco.

c) Procurar evitar muitos campos opcionais que possam complicar o desenvolvimento de aplicações.

Segundo o autor, a transformação do modelo ER para o modelo relacional ocorre em três etapas: derivação das entidades e respectivos atributos, derivação dos relacionamentos e derivação de generalizações/especializações, esta última não será considerada.

2.6.2.2.1 Implementação inicial de entidades

Neste primeiro passo, as entidades são transformadas em tabelas e os atributos tornam-se os campos da tabela criada. Os atributos indicadores são traduzidos para as chaves primárias. A Figura 22 representa um exemplo de uma transformação.

Figura 22 – Transformação de entidade em tabela

PESSOA nome endereço código data de admissão data de nascimento

Esquema relacional correspondente:

Pessoa (CodigoPess, Nome, Endereço, DataNasc, DataAdm)

Fonte: adaptado de Heuser, 2009.

Convém, no modelo relacional, alterar os nomes dos atributos, mantendo os nomes das colunas curtos e não conter espaços em brancos ou hífens, isso diminuirá o trabalho dos programadores. Dessa forma, os nomes dos atributos data de nascimento e data de admissão foram alterados para os nomes das colunas DataNasc e DataAdm (Heuser, 2009).

2.6.2.2.2 Implementação de relacionamentos

A transformação dos relacionamentos pode ser realizada de três formas distintas: criando uma tabela própria para o relacionamento, fazendo adição de colunas em uma das tabelas de entidade que participam do relacionamento e fazendo a fusão de tabelas de entidades. A alternativa a ser escolhida depende da cardinalidade (máxima e mínima) do relacionamento.

Fusão de tabelas

a) O relacionamento é representado por uma única tabela;

b) Esta opção somente deve ser aplicada para relacionamentos com cardinalidade 1:1;

c) Todas as colunas de uma das tabelas são movidas para a outra tabela do relacionamento;

d) A tabela que cedeu às colunas deixa de existir;

e) A chave primária da tabela que cedeu às colunas pode deixar de existir em alguns casos;

f) Todas as colunas correspondentes aos atributos do relacionamento (se existirem) também são movidas para a tabela resultante;

g) A chave primária desta tabela permanece inalterada. A Figura 23 exemplifica essa transformação.

Figura 23 – Tradução de relacionamento através de fusão de tabelas

Fonte: adaptado de Heuser, 2009.

Adição de colunas em uma das tabelas

Nesta opção, o relacionamento é implementado através da inserção, em uma tabela correspondente a uma das entidades que participam do relacionamento, das seguintes colunas:

a) Colunas correspondentes ao identificador da entidade relacionada (chaves estrangeiras);

b) Colunas correspondentes aos atributos do relacionamento (se existirem);

c) As chaves primárias das tabelas que participam do relacionamento permanecem inalteradas. A Figura 24 descreve essa transformação.

Figura 24 – Tradução de relacionamento por adição de coluna

Fonte: adaptado de Heuser, 2009.

Tabela própria

É criada uma tabela para o relacionamento contendo:

a) Colunas correspondentes aos identificadores das tabelas relacionadas (chaves estrangeiras);

b) Colunas correspondentes aos atributos do relacionamento (se existirem);

c) A chave primária desta tabela será formada pela coluna correspondente a um dos identificadores da tabela relacionada (chave estrangeira);

d) Pelas colunas correspondentes aos identificadores das tabelas relacionadas (chaves estrangeiras);

e) A chave primária pode ser concatenada com colunas do relacionamento (se existirem).

Este último item, Heuser (2009) complementa afirmando que caso o relacionamento sendo traduzido tiver a cardinalidade n:n, a chave primária desta tabela é formada pelas colunas correspondentes aos identificadores das entidades relacionadas e pelas colunas correspondentes aos atributos identificadores do relacionamento caso eles existam. A Figura 25 exemplifica esse caso.

Figura 25 – Tradução de relacionamento por tabela própria

Fonte: adaptado de Heuser, 2009.

2.6.2.2.3 Implementação de generalização/especialização

Para implementação de generalização/especialização existem duas formas possíveis: uso de uma tabela para cada entidade e uso de uma única tabela para toda hierarquia de generalização/especialização.

Heuser (2009) explica que nos casos de tabela única, esta deve ser composta por:

a) Chave primária correspondente ao identificador da entidade mais genérica;

b) Caso, não exista, uma coluna Tipo, que identifica que tipo de entidade especializada está sendo representada por cada linha da tabela;

c) Uma coluna para cada atributo da entidade genérica;

d) Colunas referentes aos relacionamentos dos quais participa a entidade genérica e que sejam implementados através da alternativa de adicionar colunas à tabela da entidade genérica;

e) Uma coluna para cada atributo da entidade especializada (estas colunas devem ser definidas como opcionais, já que somente terão valores quando a linha for referente à entidade especializada em questão);

f) Colunas referentes aos relacionamentos dos quais participa cada entidade especializada e que sejam implementados através da alternativa de adicionar colunas à tabela da entidade.

A outra alternativa é criar uma tabela para cada entidade especializada, aplicando as regras de implementação de entidade e de relacionamentos vistas anteriormente.