PBD livro capitulo02 ProjetoConceitual

Prévia do material em texto

Unidade 2. Projeto Conceitual 
 
2.1 Primeiras Palavras 
Os objetivos deste capítulo são: 
 Apresentar conceitos avançados do Projeto Conceitual, envolvendo: 
 Projeto de Visão; 
 Integração de Visões; 
 Transformações de um Esquema para Melhorar a Qualidade do Mesmo; 
 
A meta na fase de projeto conceitual é obter um esquema conceitual do banco de 
dados que seja tão completo e expressivo quanto possível. Esse esquema deve 
procurar expressar o máximo da semântica envolvida na informação. Mecanismos de 
representação de alto nível são empregados, tais como representação de hierarquias 
de subconjunto e de generalização, representação de restrições de cardinalidade e de 
atributos compostos e multivalorados. Para a representação do esquema conceitual 
geralmente utiliza-se uma extensão do modelo Entidade-Relacionamento. 
 
2.2 Problematizando o tema 
O que é projeto conceitual? Quais suas etapas? Como refinar desenvolver um projeto 
de banco de dados? Como dividir o trabalho? 
 
2.3 Meta do Projeto Conceitual 
A meta de desenvolvimento de um esquema conceitual é chegar a um esquema: 
 Completo: atende todos os requisitos do usuário; 
 Correto: sem erros de modelagem; 
 Fácil de entender: os dados e seus relacionamentos devem ser claros e 
expressivos; 
 Livre de redundâncias e replicações (de dados e conceitos); 
 Simples: o esquema deve ser o mais simples possível, mas que atenda todos 
os requisitos do usuário; 
 
O desenvolvimento do esquema conceitual deve levar em consideração o tempo. Um 
dos problemas a ser considerado é o que fazer com dados antigos, por exemplo, 
registros com mais de 5 anos. Além disso, o projeto deve incorporar as necessidades 
futuras previsíveis do cliente. Por exemplo: o usuário pode não necessitar cadastrar o 
celular de clientes. No entanto, é possível que no futuro ele necessite dessa 
informação, portanto, a informação deve ser adicionada no esquema. 
 
Para atingir a meta é necessário fazer uso do recurso de usar vários níveis de 
abstrações para captar o máximo de semântica possível: partindo das abstrações de 
níveis mais altos para aquelas de níveis mais baixo. Além disso, devemos usar a 
estratégia de dividir para conquistar, usando todos os recursos de semânticos e de 
abstração e restrições presentes no modelo Entidade-Relacionamento Estendido 
descritos no capítulo anterior. 
 
 
 
 1
2.4 Visões 
Uma visão é o que um determinado indivíduo enxerga de uma determinada realidade. 
Aqui, conceitos da abordagem Top-Down se misturam com a abordagem Bottom-Up 
(Engenharia Reversa) para podermos modelar as visões de um usuário. A Engenharia 
Reversa é o que chamamos de abordagem Bottom-Up: parte de dados ou produto 
anterior já existente. 
 
Quando as aplicações são complexas e usualmente diferentes analistas estão 
envolvidos no processo de projeto do banco de dados, a aplicação pode ser 
particionada em atividades menores, representando visões de grupos de usuários. 
Visão, na fase de projeto conceitual, é a parte de um banco de dados ou dos requisitos 
de dados de uma aplicação que é vista por um usuário ou grupo de usuários. 
 
 
2.5 Projeto de Visão 
O objetivo do projeto de visões é decompor aplicações complexas em problemas 
menores. Refere-se à modelagem da parte do banco de dados de interesse de um 
usuário ou grupo de usuários, com base nos requisitos de dados, usando os conceitos de 
um modelo de dados. Os requisitos podem estar expressos através de: 
 
 Descrições em linguagem natural, através da qual os usuários expõem suas 
necessidades; 
 Formulários impressos em papel, que são utilizados para coletar dados. Se já 
houver um sistema preexistente, esses formulários podem ser telas formatadas 
para entrada de dados; 
 Declarações de registros pertencentes a aplicações preexistentes. 
 
 
2.6 Projeto de Visão com base em Linguagem Natural 
Geralmente os requisitos são colhidos em linguagem natural na estratégia top-down 
do projeto de banco de dados. O projeto de visão nessa etapa compreende em: 
 Análise de requisitos; 
 Desenvolvimento de esquema da visão ; 
 Refinamento do esquema; 
A etapa de análise de requisitos pode ainda ser dividida nos seguintes passos: 
 Identificar as entidades envolvidas; 
 Identificar ambigüidades; 
 Eliminar ambigüidades; 
 Determinar relacionamento entre as entidades. 
 
Um dos primeiros passos na análise de requisitos é eliminar os termos ambíguos ou 
genéricos, re-escrevendo os requisitos. Para isso é necessário identificar os: 
 Sinônimos: 
o Palavras diferentes com o mesmo significado (referenciam o mesmo 
elemento); 
 Homônimos: 
o Palavras iguais com significados diferentes (referenciam elementos 
diferentes. 
 
 2
Exemplo 2.1 Identifique as ambigüidades na especificação abaixo: 
 
“Um comprador ao efetuar a compra de um produto, deve fornecer seu número de 
cliente. O cliente deve conseguir visualizar os itens que possuem desconto.” 
 
É possível identificar as ambigüidades em negrito na frase anterior: 
“Um comprador ao efetuar a compra de um produto, deve fornecer seu número de 
cliente. O cliente deve conseguir visualizar os itens que possuem desconto.” 
 
Observe que o cliente e comprador são usados como sinônimos, assim como produto 
e itens. 
 
 
Exemplo 2.2 Elaborar o esquema conceitual da especificação da Figura seguindo as 
seguintes etapas: identificação das entidades evidentes; identificação das 
ambigüidades; eliminação das ambigüidades; determinação das demais entidades e 
relacionamento entre as entidades envolvidas. Os atributos das entidades serão 
omitidos no esquema conceitual deste neste exemplo, fica como exercício adicioná-
los. 
 
Especificação. Em um banco de dados de uma companhia de cartão de créditos é 
necessário guardar informações sobre clientes e funcionários. Para clientes são 
armazenados nome, idade, sexo, rua, nro, cidade e estado de residência, telefone, 
local e estado de origem, com o período de residência e renda atual. É necessário 
para cada usuário do cartão de crédito determinar o valor de seu limite de cartão, valor 
disponível e dívida. O sistema deve guardar dados da fatura feita com o cartão, como 
o nome da loja onde os clientes compraram, valor compra, data da compra e 
vencimento da fatura. De cada estabelecimento comercial, onde o cliente realiza 
transação com o cartão deve-se armazenar o nome, cnpj, endereço e telefone. Sobre 
os funcionários se armazenam, nome, data nascimento, local, estado, data de 
contratação e a renda que recebem da companhia. Os funcionários são encarregados 
de vender cartões e cancelar os mesmos, além de registrar reclamações dos usuários. 
 
Passo 1: Identificação das entidades evidentes 
Observe que a especificação acima pode ser dividida conforme mostra a Figura 2.1, 
onde cada trecho entre colchetes é relacionado a uma entidade evidente. 
 
 3
 
Figura 2.1. Identificação das entidades evidentes a partir da especificação do 
Exemplo 2.2. 
Da separação apresentada na Figura 2.1 é possível identificar as seguintes entidades: 
 Cliente; 
 Compra; 
 Funcionário; 
 Estabelecimento Comercial; 
 Fatura. 
 
 
Passo 2. Identificar as ambigüidades. 
 
A Figura 2.2 mostra os termos com sinônimos e homônimos do texto. 
 4
 
 
Figura 2.2 Identificação das ambiguidades a partir da especificação do Exemplo 
2.2. 
Passo 3. Tratar as ambigüidades. 
 
Observe o passo dos tratamentos das ambigüidades da especificação do Exemplo 2.2: 
 
1. Substituir o termo genérico por um mais específico para evitar interpretações 
duvidosas; 
 Exemplo: Local é genérico, substituir por Cidade; 
2. Substituir termos ambíguos: 
 Usuário é ambíguo. É o usuário do sistema (funcionário) ou usuário do 
cartão (cliente)? Substituir no item 3 para cliente. 
3. Eliminartermos distorcidos: 
 Renda no item 6 significa salário que o funcionário recebe da 
companhia e não a renda mensal (que pode envolver outras 
remunerações de fora da companhia, como outro emprego). Substituir 
por salário. 
4. Trocar termo específico para genérico mais adequado: 
 Loja no item 6, significa estabelecimento comercial, sendo mais 
genérico, englobando além de lojas, sorveterias, açougues. Nesse 
caso, o termo mais genérico, estabelecimento comercial é mais 
adequado. 
5. Em alguns casos deve-se escolher um entre dois sinônimos, o mais adequado 
para o contexto específico: 
 Trocar guardar por armazenar (item 1) 
 Trocar Realiza transação por Compra (item 5) 
 Cuidado: Compra e fatura não são sinônimos: manter distinção! 
 
 
 
 
 
 5
 
Figura 2.3. Especificação do Exemplo 2.2 com as ambigüidades tratadas. 
 
Passo 4. Identificar as entidades envolvidas. 
Uma vez com as ambigüidades tratadas, a especificação deve ser usada para determinar 
as entidades envolvidas no diagrama ER. As entidades envolvidas no Exemplo 2.2 são: 
 Cartão; 
 Pessoa; 
 Funcionário; 
 Cliente; 
 Fatura; 
 Compra; 
 Estabelecimento Comercial; 
 Reclamações 
 
Passo 5. Identificar os relacionamentos 
 
Uma vez as entidades identificadas, a especificação corrigida deve ser usada para 
identificar os relacionamentos entre as entidades e também para a identificação dos 
atributos. A Figura 2.4 mostra o diagrama ER produzido para a especificação do 
Exemplo 2.2. 
 
 6
 
 
Figura 2.4 Diagrama ER do Exemplo 2.2 com os atributos omitidos. 
 
 
 
2.7 Projeto de Visão com base em Formulários 
 
Um formulário possui: 
 Partes que não apresentam informações relevantes a serem armazenadas 
(assinaturas, data de emissão, cabeçalho, etc.). 
 Partes que são pré-impressas e que se referem a nomes de campos; 
 Partes que devem ser preenchidas pelos usuários e que serão armazenadas no 
sistema; 
 Partes descritivas referentes às instruções que devem ser seguidas para 
preencher os campos do formulário. 
 
O formulário deve ser avaliado de maneira a ter seus campos agrupados por assuntos 
que podem ser posteriormente mapeados para entidades. Após isso, o diagrama ER 
correspondente deve então ser desenvolvido. 
 
A Figura 2.5 apresenta um exemplo de formulário. 
 7
 
 
Figura 2.5 Exemplo de formulário a ser usado no levantamento de requisitos de 
um projeto de visão. 
 
Observe que é possível agrupar o assunto dos dados apresentados no formulário, 
como mostra Figura 2.6. 
 
 
Figura 2.6 Agrupamento dos dados apresentados no formulário por assunto. 
 
Após o agrupamento dos dados do formulário é possível apresentar um esboço do 
diagrama ER. Um diagrama ER gerado a partir do formulário da Figura 2.5 é ilustrado 
na Figura 2.7. 
 
 
 8
 
 
Figura 2.7 Diagrama ER gerado a partir do formulário da Figura 2.5. 
 
Exercícios. 
 
1. Faça o Diagrama ER gerado a partir do formulário da Figura 2.8. 
 
 
Figura 2.8 Formulário de informação de docentes de Ensino à Distância 
 
 
2. Altere o formulário anterior adicionando as informações de tutores apresentadas na 
Tabela 2.1. Além disso, para os professores acrescente campos para assinalar as 
opções: 
 Ministra aula de pós-graduação; 
 Professor contrato (tempo integral, tempo parcial); 
Após essas alterações no formulário, faça o diagrama ER com base no formulário 
modificado. 
Tabela 2.1 Dados de tutores 
Formação Bolsista Disciplinas de 
Interesse 
 
 
 
 
 9
 
 
2.8 Projeto de Visão com base em Declarações de Registro em Cobol 
 
A seguir são tratados alguns aspectos relativos à estrutura de declaração de arquivos 
como guia para a modelagem de esquemas conceituais utilizando o diagrama ER. 
 
As aplicações comerciais geralmente utilizam arquivos compostos de registros que 
são armazenados na memória secundária. Esses arquivos são acessados, 
consultados e/ou alterados de acordo com as funções executadas pelo sistema. Os 
registros são compostos de campos. Os campos por sua vez podem ser compostos de 
sub-campos. Como conseqüência, geralmente têm uma estrutura hierárquica, e cada 
campo se coloca numa posição desta hierarquia. Em Cobol, a declaração dos arquivos 
que irão fazer parte do sistema é realizada em uma estrutura chamada DATA 
DIVISION. 
 
Observe o exemplo apresentado na Figura 2.9 de declaração de registros em Cobol. 
Observe que a partir dessa declaração é possível diretamente diferenciar campos 
simples, compostos e multivalorados. A partir dessa declaração é possível fazer o 
diagrama ER apresentado na Figura 2.10. 
 
 
 
Figura 2.9 Exemplo de declaração de registro em Cobol. 
 
 
 
Figura 2.10 Diagrama ER construído a partir da declaração de registro 
apresentada na Figura 2.9. 
 
. 
 
 10
Requisitos com base em documentos XML (eXtensible Markup Language) 
 
Os requisitos também podem ser colhidos a partir de documentos XML, que possuem 
os dados organizados e separados através de tags. O documento apresentado na 
Figura 2.11 apresenta um exemplo de documento XML que pode ser usado para a 
coleta de requisitos. A Figura 2.12 mostra um diagrama ER gerado a partir do 
documento XML da Figura 2.11. 
 
 
Figura 2.11 Exemplo de documento XML que pode ser usado para coleta de 
requisitos. 
 
 
Figura 2.12 Diagrama ER gerado gerado a partir do XML apresentado na Figura 
2.11 
 
 
2.9 Integração de Visões 
 
A integração de visões corresponde ao processo de fusão de vários esquemas 
conceituais em um esquema conceitual global que representa todos os requisitos da 
aplicação. 
Aconselha-se o uso do processo de integração principalmente para aplicações 
complexas, onde o volume de informações é grande, podendo haver vários analistas 
envolvidos no processo de projeto. O projetista estabelece uma prioridade entre os 
esquemas com base em sua importância, confiabilidade e completitude. 
 
A integração de visões se dá aos pares, conforme ilustrado na Figura 2.13: 
 as duas visões com maior quantidade de conceitos em comum são integradas; 
 11
 a visão resultante será integrada com a próxima que possui a maior quantidade 
de conceitos em comum e assim por diante... 
 
 
Figura 2.13 Integração de Visões. 
 
O processo de Integração de Visões também é conhecido como processo de 
Integração de Esquemas. A integração de visões também é utilizada na abordagem 
Bottom-Up (Engenharia Reversa). Os atributos de uma mesma entidade ou 
relacionamento após a integração são reunidos em uma única tabela. Além disso, 
redundâncias de dados devem ser eliminadas na integração. 
 
Análise de Conflitos 
Realiza-se uma análise nos esquemas a serem integrados, para verificar se há algum 
conflito entre informações de diferentes esquemas. Os tipos de conflitos que podem 
ocorrer são discutidos a seguir. 
 
Conflitos de nome: 
 Sinônimos: nomes diferentes para a mesma informação em diferentes 
esquemas: 
o Solução: Escolher um nome e renomear os demais com esse nome; 
 Homônimos: nomes iguais para informações diferentes em diferentes 
esquemas: 
o Solução: Renomear para diferenciar as informações 
 
Conflitos estruturais: 
Após realizada a eliminação dos conflitos de nomes, tem-se que dois conceitos de 
diferentes esquemas com mesmo nome representam o mesmo conceito. Esses 
conceitos com mesmo nome são agora comparados para verificar se podem ser 
fundidos num único. Os conceitos homônimos de diferentes esquemas podem ser: 
 Idênticos: 
 Mesmos atributos; 
 Mesmos relacionamentos; 
 Se resumem no mesmo. 
 Compatíveis: 
 Esquema 1 Esquema 2
 Esquema parcial
 integrado Esquema 3 
 Esquema n
 Esquema global
correção dos 
conflitos 
 . . .
 12
 Estruturalmente diferentes, masrepresentam conceitos 
semelhantes; 
 A solução para esse conflito é fazer uma representação 
comum que satisfaça ambas as restrições; 
 Incompatíveis: 
 Apresenta restrições diferentes (chaves, cardinalidade, etc...): 
 Fazer uma representação comum que satisfaça a 
restrição mais genérica; 
 
 
A Figura 2.14 apresenta exemplos de conceitos compatíveis. Nesse caso, como os 
conceitos possuem diferentes representações não contraditórias, muda-se uma 
das representações. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 2.14 Exemplos de conceitos compatíveis. Esquemas 1 e 2 são compatíveis 
entre si, assim como Esquemas 3 e 4. 
 
Se os conceitos forem incompatíveis, como, diferentes cardinalidades para o mesmo 
atributo ou relacionamento, diferentes identificadores, etc., deve-se selecionar ou 
desenvolver uma representação comum satisfazendo as restrições dos dois 
esquemas. A Figura 2.15 apresenta dois esquemas incompatíveis devidos a 
cardinalidade do relacionamento Tem com a entidade Cliente. Nesse caso, a 
cardinalidade mais genérica (0,N) deve ser empregada. 
 
 
 
 Livro título nome_editora Livro 
 Editora 
título 
nome_editora 
Esquema 1 Esquema 2 
Pessoa nome sexo
Pessoa nome 
Homem Mulher 
Esquema 3 Esquema 4
 13
 
 
Figura 2.15 Exemplo de conceitos incompatíveis devido a cardinalidade do 
relacionamento Tem com a entidade Cliente. 
 
 
2.10 Estudo de Caso: Gerenciamento de uma Biblioteca 
 
Projeto de Visões – Biblioteca particular de pesquisadores 
 
Considere os esquemas conceituas a seguir que têm por finalidade armazenar 
informações sobre publicações (livros, revistas, etc) de uma biblioteca. 
 
O esquema 1 (apresentado na Figura 2.16) representa informações de interesse de 
pesquisadores em suas bibliotecas particulares. Nesse esquema tem-se: 
 
Publicação: publicações (artigos) mantidas pelos pesquisadores em seus gabinetes 
particulares. Elas são geralmente obtidas pelos pesquisadores através de contatos 
com os autores. 
 
Tópico: refere-se às áreas de pesquisa de interesse dos autores. 
 
Solicitado-por: relaciona artigos que foram enviados por autores, aos pesquisadores 
que os solicitaram. 
 
 
O esquema 2 (apresentado na Figura 2.17) representa as informações a serem 
mantidas na biblioteca do Departamento desses pesquisadores: 
 
Publicação: publicações presentemente mantidas na biblioteca. 
 
Artigo: artigos publicados em revistas ou anais mantidos na biblioteca. 
 
Comprado-pelo: indica que o pesquisador é responsável pelo recurso usado para 
comprar a publicação. 
 14
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 2.16 Biblioteca Particular - Esquema 1 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 2.17 Biblioteca do Departamento - Esquema 2 
 
 
 
nome 
nome 
editor 
 
Solicitado
-por 
Tópico 
Autor 
Pertence
Grupo_ 
Pesquisa 
de_interesse 
Publicação 
Publ-de-
interesse 
Pesquisador 
Escreve 
(0,n) 
(1,n) 
(1,n) 
(1,n) 
nome 
endereço 
 
Série 
Livro interesse 
 Possui 
ultimo-nome 
idade 
estado-nasceu
Editora 
 tem 
Nome 
endereço 
Último-nome 
endereço 
(1,n) 
(1,n) 
(1,n) 
(1,n) 
(1,n) 
(1,n) 
(1,1) 
(1,1) 
(1,n) (1,n) 
número 
título 
ano 
 
Enviado-
por 
(0,n) 
(0,n) 
(0,n) 
(0,n) 
(0,n) 
(0,n) 
título 
palavra-chave 
ano 
Último-nome 
posição 
grau 
cidade-nasceu 
 
Tópico 
Publicação 
Anais 
Referente-a 
Pesquisador 
Editora 
Publicado
-por 
Comprada-pelo 
cód-tópico 
nome
(1,n)
(1,n)
(0,n) 
(0,n)
nome 
endereço 
 
trata 
(1,n) 
Título 
estante 
Empresta
dia-emprestimo 
Revista Livro 
(1,1)
Autor 
Artigo 
pertence
-rev 
pertence
-anais 
Título 
autor 
(1,n) 
(0,1) 
(0,1) 
(0,n) 
(0,n) 
(0,1)
(0,n) 
(1,1)
 15
Na Etapa 1 são analisados os esquemas das Figura 2.16 e Figura 2.17, quanto a: 
 conflito de nomes 
 conflitos estruturais 
Os esquemas são então refeitos com os conflitos resolvidos. Na etapa 2 é feita a 
integração dos esquemas. A Figura 2.18 e Figura 2.19 mostram, respectivamente os 
esquemas das Figura 2.16 e Figura 2.17 após a resolução dos conflitos. 
 16
nome
ultimo-nome 
idade 
estado-nasceu 
nome 
editor 
 
Nome 
endereço 
Área_ 
pesquisa 
Autor 
Pertence
Grupo_ 
Pesquisa 
de_interesse 
 Artigo 
Artigo-de-
interesse 
Pesquisador 
Escreve 
(0,n) 
nome 
(1,n) 
(1,n) 
(1,n)
nome 
endereço 
 
Série 
Livro interesse 
 Possui 
Editora 
 tem 
Último-nome 
endereço 
(1,n) 
(1,n) 
(1,n) 
(1,n) 
(1,n) 
(0,n)
(1,1) 
(1,1) 
(1,n)(1,n)
número 
título 
ano 
 
Solicitado
-por 
Enviado-
por 
(0,n) 
(0,n) 
(0,n) 
(0,n)
(0,n) 
(0,n) 
título 
 
ano Tópico 
A-T 
 
(1,n)
(1,n)
Figura 2.19 - Biblioteca Particular - Esquema 1(após a resolução de 
conflitos) 
nome 
endereço 
 
Último-nome 
posição 
grau 
cidade-nasceu 
 
dia-emprestimo 
cód-tópico 
nome
Título 
estante 
Figura 2.18 Biblioteca do Departamento - Esquema 2 (após a resolução de 
conflitos) 
Tópico 
Publicação 
Anais 
Referente-a 
Pesquisador 
Editora 
Publicado
-por 
Comprada-pelo 
(1,n) 
(1,n) 
(0,n) 
(0,n) 
trata 
(1,n) 
Empresta
Revista Livro 
(1,1)
Artigo 
pertence
-rev 
pertence
-anais 
Título 
 
(1,n) 
(0,1) 
(0,1) 
(0,n) 
(0,n) 
(0,1) 
(0,n) 
(1,1) 
Autor escreve- livro
escrito_ 
 por 
 livro 
(0,n) (0,n)
(1,n)
(1,n) 
nome 
 17
 
Na etapa 2 deve ser feito então a integração dos esquemas. O esquema global após 
fusão dos esquemas: Biblioteca Particular e Biblioteca do Departamento é 
apresentado na Figura 2.20. 
 
 
 
 
Figura 2.20 Esquema global após fusão dos esquemas Biblioteca 
Particular e Biblioteca do Departamento (Figura 2.18 e Figura 2.19). 
trata 
dia-emprestimo 
Publicação 
(1,n) 
título estante 
Tópico 
Referente-a 
cód-tópico 
nome 
(1,n) 
(1,n) 
(1,1)
Pesquisador 
Comprada-pelo
(0,n) 
último-nome 
posição 
grau 
cidade-nasceu 
estado-nasceu 
idade 
 
Empresta
(0,n) 
(0,1) 
Anais Livro Revista 
Artigo 
 título 
 ano 
 
(1,n)
(0,1)
pertence
-rev 
pertence
-anais
(0,1) 
(0,n) (0,n) 
Editora 
Publicado
-por 
(0,n) 
nome endereço 
 
(1,1) 
 Série 
Possui 
 de 
(1,n) 
(0,n) 
(1,1) 
(1,1) 
(1,n) 
 número 
 ano 
 
nome editor 
de-
interesse
Autor 
Escrito_por
Escreve
-livro 
(0,n) 
Área-
Pesquisa 
de_interesse 
(1,n) (1,n) 
nome-area 
Último-nome 
endereço
(1,n) 
(1,n)
(0,n) 
(1,n) 
artigo-de-
interesse 
(1,n) 
(1,n) 
Solicitado-
por 
(0,n)
(0,n) 
(0,n) 
Enviado-
por 
(0,n) 
(0,n) 
(0,n) 
Pertence Grupo_ 
Pesquisa 
(0,n)
(1,n)
nome 
endereço 
 
 18
 
2.11 Melhorando a Qualidade de um Esquema de Banco de Dados 
Após a fusão dos esquemas deve-se aplicar sucessivos refinamentos no esquema 
conceitual gerado, para melhorar a qualidade do mesmo. A meta para melhorar a 
qualidade do esquema conceitual é aplicar transformações para reestruturar o 
esquema, produzindo uma versão melhor em termos das seguintes qualidades: 
 
a. Ser completo 
b. Ser correto 
c. Ser mínimo 
d. Ser expressivo e auto-explicativo 
e. Ser Legível 
f. Estar normalizado 
 
2.12 Qualidades de um esquema de BD 
 
a. Ser completo 
 esquema completo comrelação aos requisitos: se todos os requisitos do 
domínio da aplicação estiverem representados no esquema; 
 requisitos completos com relação ao esquema: se cada conceito no esquema é 
mencionado nos requisitos. 
 
b. Ser correto 
 Um esquema é correto quando usa adequadamente os conceitos do modelo 
ER. Os erros semânticos mais freqüentes são: 
 Usar um atributo no lugar de uma entidade; 
 Esquecer de representar uma generalização; 
 Esquecer a propriedade de herança das generalizações; 
 Usar um relacionamento com um número errado de entidades (por 
exemplo, usar um relacionamento binário no lugar de um 
relacionamento ternário); 
 Usar uma entidade ao invés de um relacionamento; 
 Esquecer algum identificador de entidade, especialmente identificadores 
compostos externos; 
 Omitir alguma especificação de cardinalidade mínima ou máxima. 
 
c. Ser mínimo 
 
Um esquema é mínimo se não for possível eliminar qualquer conceito do esquema 
sem perder informação. Um exemplo de conceito que pode ser eliminado são os 
atributos derivados que podem ser calculados a partir de outras informações da base 
de dados. Pode-se permitir alguma redundância no esquema, desde que a mesma 
seja devidamente documentada. 
 
d. Ser expressivo e auto-explicativo 
 
Um esquema é expressivo quando pode ser entendido através dos construtores do 
esquema E-R, sem a necessidade de explicação adicional. 
 
Por exemplo, considere o esquema da Figura 2.21, suponha que cada aluno tem, no 
máximo, um orientador de mestrado e um orientador de doutorado e um mesmo aluno 
 19
pode ser um aluno de mestrado e de doutorado (em momentos diferentes). Essa 
informação não está totalmente representada no esquema. 
 
 
 
 
Figura 2.21 Exemplo de esquema não auto-explicativo 
 
e. Ser legível 
 
Respeitar critérios de estética que tornam o diagrama agradável. 
- evitar cruzamento de ligações dos relacionamentos; 
- evitar curvas; 
- hierarquias: pai deve ser colocado acima dos filhos. 
A Figura 2.22 mostra um exemplo de diagrama não legível e a maneira de ajustá-lo. 
 
 
 
 
Figura 2.22 Exemplo de diagrama com problemas de legibilidade e a maneira de 
ajustá-lo. 
 
2.13 Transformações de Esquema para conseguir a Minimalidade 
 
O objetivo desta etapa é realizar transformações no esquema objetivando obter um 
esquema mínimo: 
 
 Esquema E1 transformações Esquema E2 
 
Para alcançarmos o esquema mínimo devem ser eliminadas as situações que 
apresentam redundância na modelagem. Essas situações são discutidas a seguir. 
 
A 
D
C 
B 
C A D
B 
mudar para 
 20
 
a) Ciclos de Relacionamentos 
Observe o Diagrama ER da Figura 2.23. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 2.23 Exemplo de ciclos de relacionamento 
 
Na Figura 2.23 o relacionamento : 
 Trab-no é redundante? 
 Trab-com é redundante? 
 Dirige é redundante? 
 
Nessa figura o relacionamento trab-com pode ser removido, sem perda da informação 
semântica, pois sabendo o diretor de um departamento e os funcionários de um 
departamento é possível saber o diretor que trabalha com os funcionários. 
Alternativamente pode-se remover o relacionamento Dirige, sem perda de informação. 
 
b) Atributos Derivados 
 
 Atributos derivados podem ser omitidos de um esquema ER, porém podem ser 
úteis para melhorar a eficiência do banco de dados. 
 
(1,1)
Empregado 
trab-com 
 Diretor 
Dirige 
Departamento 
Trab-no 
(1,1) 
(1,1) 
(1,n)
(1,n) 
(1,n) 
 21
 
c) Subconjuntos Implícitos 
 
Um exemplo de redundância implícita é mostrado na Figura 2.24. Observe que para ser 
gerente a pessoa precisa ser primeiro um funcionário. 
 
 
 
 
 
 
 
 
 
 
2.14 
 
Figura 2.24 Exemplo de subconjunto implícito. 
 
2.15 Transformações para conseguir Expressividade 
A expressividade é melhorada quando se simplifica o esquema. Transformações 
típicas para melhorar a expressividade: 
 
a) Eliminar Sub-entidades "Inexpressivas" em Hierarquias de Generalização: 
 
 As sub-entidades inexpressivas, que são aquelas sem atributos ou com poucos 
atributos, devem ser eliminadas da hierarquia de generalização. Um exemplo dessa 
ocorrência é mostrado na Figura 2.25. 
 
Figura 2.25 Exemplo de sub-entidades inexpressivas. 
 
Membro 
Ensino 
Professor Instrutor Estudante 
Graduado
Membro 
Ensino 
categoria
Pessoa 
Funcionário 
 Gerente 
Pessoa 
Gerente 
integração
Pessoa 
Funcionário 
 Gerente 
 22
 
 
b) Eliminar Entidades "Inexpressivas" 
 
As entidades que não trazem ganho semântico devem ser eliminadas. Na Figura 2.26 
é mostrado um exemplo de entidade inexpressiva (Tipo Sanguíneo). 
 
 
 
Figura 2.26 Exemplo de entidade inexpressiva (Tipo Sanguíneo). 
 
c) Criar uma Generalização 
Quando se tem entidades com propriedades semelhantes. No exemplo da Figura 2.27, 
Professor e Instrutor têm propriedades semelhantes. A expressividade desse exemplo 
é melhorada com a criação de hierarquias de generalização, conforme ilustrado na 
Figura 2.28. 
 
Figura 2.27 Exemplo de entidades com propriedades semelhantes. 
 
 
 Figura 2.28. Melhorando a expressividade do exemplo da Figura 2.27 com a 
criação de generalizações. 
Professor dá Seminário 
Instrutor ensina Curso 
ensina 
 dá 
auxilia 
Assistente 
Ensino
Membro 
Docente ensina Atividade 
Seminário Curso 
Instrutor Professor 
auxilia
Assistente 
Ensino 
 23
 
d) Criar um Subconjunto 
 
Quando for significativo para o projeto, pode-se criar um novo subconjunto quando a 
entidade possui cardinalidade mínima zero em um relacionamento. Isso enfatiza o 
papel da entidade. Um exemplo de aumento da ênfase no papel da entidade com a 
criação de um subconjunto é mostrado na Figura 2.29. 
 
 
Figura 2.29 Exemplo de aumento da ênfase no papel da entidade com a criação de 
um subconjunto. 
 
 
2.16 Transformações para obter Normalização 
Quando devemos pensar na Normalização do banco? 
Os passos de desenvolvimento do projeto conceitual segundo a abordagem Bottom-UP 
(engenharia reversa) são: 
1. coleta de fontes de dados; 
2. representação em tabelas não-normalizadas;  
3. normalização; 
4. integração de esquemas relacionais; 
5. engenharia reversa do esquema relacional; 
Os passos de desenvolvimento do projeto conceitual segundo a abordagem Top-Down 
(abordagem tradicional) são: 
1. coleta de requisitos de diferentes visões 
2. Desenvolvimento de um esquema conceitual para cada visão 
3. Integração de visões 
4. Transformação do esquema conceitual visando atender as qualidades: 
• Completo; 
• Apropriado; 
• Válido; 
• Mínimo; 
• Significativo; 
• Normalizado. 
• Legível; 
 
 
Assim podemos perceber que a normalização é um passo intermediário da abordagem 
Bottom-up (Engenharia Reversa) do Projeto Conceitual. E a verificação da 
 24
normalização deve ser feita no passo final da abordagem Top-Down (abordagem 
tradicional). 
 
O material de normalização de projeto de banco de dados deve ser consultado para 
uma revisão de normalização. Possíveis mudanças no esquema durante o 
desenvolvimento conceitual devem considerar no máximo até a Terceira Forma 
Normal (3FN). A 4FN e a 5FN devem ser consideradas em etapas posteriores do 
desenvolvimento de um projeto de banco de dados. 
 
O ESQUEMA DA ULTIMA PAGINA NAO DEVERIA VIR AQUI? 
 
2.17 Exercícios 
 
1. Construa um esquema conceitual para a seguinte descrição em linguagem natural: 
Projete o banco de dados para um ambiente de suporte de programação. Nesse 
ambiente os programadores produzem programas, que são escritos em determinadas 
linguagens de programação. Cada programa é escrito por um certo programador, pode 
chamaroutros programas e pode ser usado por determinados usuários. Os usuários 
são reconhecidos por seu nome de log-in e por seu código; os programas têm nomes 
compostos que incluem o nome do programa, a extensão e o código do programador. 
Os programas têm um número de versão, uma data e uma breve descrição; alguns 
programas interagem com SGBDs. Cada SGBD mantém dados armazenados na 
forma de relações, com vários atributos e uma chave primária. Cada banco de dados é 
definido por um administrador de banco de dados, que é um programador 
especializado em gerenciamento de dados. 
 
2. Transcreva as definições de arquivo em COBOL a seguir para um esquema ER. A 
aplicação lida com o controle distribuído de um processo industrial. O arquivo DADOS-
EMPREGADO indica que cada empregado pode controlar comandos e alarmes. O 
arquivo SISTEMA-COMANDOS lida com comandos disponíveis para controle de 
processos e os locais onde cada comando pode ser executado. O arquivo SISTEMA-
ALARMES lida com os mesmos dados para alarmes. Finalmente, o arquivo 
COMUNICAÇÕES descreve dados sobre subsistemas de comunicação, sua 
tecnologia, os dispositivos conectados, locais dos dispositivos, etc. A transmissão de 
dados pode ser através de microondas ou cabos. 
 
01 DADOS-EMPREGADO. 
 02 NRO-ID PIC 9(6). 
 02 NOME PIC X(20). 
 02 SUPERVISOR-EMPREGADO PIC 9(6). 
 02 SISTEMA-COMANDO-CONTROLADO PIC X(5) OCCURS 10 TIMES. 
 02 SISTEMA-ALARME-CONTROLADO PIC X(5) OCCURS 10 TIMES. 
 
01 SISTEMA-COMANDOS. 
 02 TIPO PIC X(5). 
 02 DATA PIC 9(6). 
 02 HORARIO. 
 03 HORA PIC 99. 
 03 MINUTO PIC 99. 
 03 SEGUNDO PIC 99. 
 02 POSIÇÃO. 
 03 NOME PIC X(20). 
 03 LOCAL PIC X(20). 
 25
 03 TIPO PIC X(5). 
 
01 SISTEMA.ALARMES. 
 02 TIPO PIC X(5) 
 02 DATA PIC 9(6). 
 02 VALOR PIC 9(8). 
 02 HORARIO. 
 03 HORA PIC 99. 
 03 MINUTO PIC 99. 
 03 SEGUNDO PIC 99. 
 02 POSIÇÃO. 
 03 NOME PIC X(20). 
 03 LOCAL PIC X(20). 
 03 TIPO PIC X(5). 
 
 
01 COMUNICAÇÕES. 
 02 TECNOLOGIA PIC X(8). 
 02 VELOCIDADE PIC 9(6). 
 
 02 DISPOSITIVO-REMOTO OCCURS 10 TIMES. 
 03 NOME PIC X(10). 
 03 TIPO PIC X(5). 
 03 LOCAL PIC X(20). 
 
 02 DADOS-CABO. 
 O3 MODEM. 
 04 TIPO PIC X(10). 
 04 TAXA-TRANSMISSÃO PIC 9(6). 
 
 02 DADOS-MICROONDAS REDEFINES DADOS-CABO. 
 03 RADIO. 
 04 RADIO PIC X(5). 
 04 MODO-TRANSMISSÃO PIC X(5). 
 04 FREQUENCIA PIC X(10). 
04 NTENA PIC X(5). 
 
3. Determine as etapas de um Projeto Conceitual de um banco de dados, usando a 
estratégia Top-Down. 
4. Quais são as etapas de produção de um Projeto Conceitual usando a estratégia 
Bottom-Up? 
 
2.18 Estudos complementares 
Ler Capítulos 3 e 4 do Livro: R. Elmarsi, S. B. Navathe, Fundamentals of 
Database Systems, Editora Pearson, 5a. Edição, 2009. 
 
2.19 Referências 
Heuser, C.A. Projeto De Banco De Dados Editora Bookman, Porto Alegre, 6a. Edição, 
2009. 
 26
Elmasri, R. & Navathe, S.B. Sistemas De Banco De Dados. Pearson Addison Wesley, 
4ª Edição, 2005. 
Livro Virtual de Sistemas de Banco de Dados, Profa. Marilde 
 27