U N I V E R S I D A D E

UNIGRANRIO
Vá além da sala de aula !

Derivação do Projeto
Lógico de Banco de Dados
Núcleo de Educação a Distância U N I V E R S I D A D E
www.unigranrio.com.br UNIGRANRIO
Rua Prof. José de Souza Herdy, 1.160 Vá além da sala de aula !
25 de Agosto – Duque de Caxias - RJ

Reitor
Arody Cordeiro Herdy

Pró-Reitor de Administração Acadêmica

Carlos de Oliveira Varella

Pró-Reitor de Pesquisa e Pós-graduação

Emilio Antonio Francischetti
Pró-Reitora Comunitária
Sônia Regina Mendes

Direção geral: Jeferson Pandolfo Desenvolvimento do material: Anderson Nascimento

Revisão: Camila Andrade, Laís Sá e Mariana Baptista Desenvolvimento instrucional: Aline Cristina
Produção editoração gráfica: David Vieira Nunes

Copyright © 2018, Unigranrio

Nenhuma parte deste material poderá ser reproduzida, transmitida e gravada, por qualquer meio eletrônico,
mecânico, por fotocópia e outros, sem a prévia autorização, por escrito, da Unigranrio.
Sumário
Derivação do Projeto Lógico de Banco de Dados
Objetivos ........................................................................................... 04
Introdução ......................................................................................... 05
1. O Projeto de Banco de Dados no Contexto de Processo de Software ....... 06
1.1 Histórico - O Papel dos SIs nas Organizações ............................ 06
1.2 O Projeto de Banco de Dados no Ciclo de Vida dos SIs ............... 07
1.3 O Ciclo de Vida de um Sistema de Aplicação de Banco de Dados .... 09
1.4 Derivando Esquemas Relacionais a partir de Diagramas ER ......... 12
1.4.1 Entidade / Atributos ............................................................. 14
1.4.2 Relacionamentos .................................................................. 16
1.4.3 Especialização / Generalização .............................................. 19
1.5 Derivando Esquemas Relacionais a partir de Diagramas de Classes ..... 20
1.5.1 Entidades / Atributos ............................................................ 21
1.5.2 Relacionamentos .................................................................. 21
1.5.3 Especialização / Generalização .............................................. 24
1.5.4 Agregação / Composição ...................................................... 25
1.5.5 Classe Associativa ................................................................. 26
Síntese ............................................................................................. 27
Referências Bibliográficas .................................................................... 28
Objetivos
Ao final desta unidade de aprendizagem, você será capaz de:

▪▪ Entender os conceitos do projeto de banco de dados no contexto do

processo de software;
▪▪ Mapear esquemas conceituais para esquemas lógicos.

4 Projeto de Banco de Dados

Introdução
As tecnologias de bancos de dados representam um papel crítico em
quase todas as áreas em que os computadores são utilizados. Praticamente
todos os sistemas realizam leitura, processamento e armazenamento de
dados, fazendo com que atividades do dia a dia – das mais simples às mais
complexas –, sejam executadas por meio de sistemas de informação, tornando
imprescindìveis características como consistência e agilidade.

Para isso, é necessário que seja investido tempo no processo de

estruturação da arquitetura de dados de um sistema, como a tradução da
modelagem conceitual para o modelo lógico, além de questões como a
aplicação de recursos que possam aumentar o tempo de resposta de consultas
aos dados, garantindo que as transações realizadas mantenham o banco de
dados confiável e seguro.

Nesta unidade de aprendizagem, vamos apresentar o papel do banco

de dados nos sistemas de informação, além de técnicas que ajudam na sua
própria otimização, proporcionando um melhor desempenho e minimizando
problemas como redundância e anomalias dos dados.
1. O Projeto de Banco de Dados no Contexto de
Processo de Software
Os bancos de dados são cada vez mais essenciais para a garantia de
softwares que atendam, de maneira eficiente, às suas demandas. As aplicações
de médio e grande portes precisam de um método sistemático para a atividade
do projeto de banco de dados, para suportar aplicações que atendam centenas ou
milhares de usuários. Esses sistemas processam transações com grandes taxas
e volumes, servindo as atividades relacionadas aos bancos, hotéis, companhias
aéreas, venda de ingressos, além de serviços públicos e comércio eletrônico.
Esses sistemas atuam no regime 24x7, ou seja, 24 horas por dia, 7 dias na
semana, precisando, portanto, de um projeto de banco de dados meticuloso.

1.1 Histórico - O Papel dos SIs nas Organizações

O papel dos sistemas de informação nas empresas é de suma importância
para o seu desenvolvimento e para fins de competitividade no mercado. Ao longo
dos anos, os sistemas passaram por transformações e evoluções importantes,
conforme podemos observar na linha do tempo abaixo:

Anos 1960 Anos 1970 Anos 1980

▪▪Sistemas de Processamento
de Arquivos.
▪▪Mudança para Sistemas de Banco
de Dados.
▪▪Surgimento de departamentos e
papéis específicos para o banco
de dados.
▪▪Criação dos grandes repositórios de banco de
dados (SGBDs).
▪▪Percepção dos dados como recursos corporativos
essenciais para a organização.
▪▪Aumento do uso dos PCs motiva a criação de
bancos de dados.
▪▪Arquitetura Cliente-Servidor em BDs.

Anos 2010 Anos 2000 Anos 1990

▪▪Business Intelligence.
▪▪Data Science.
▪▪Popularização de redes sociais.
▪▪Bancos de dados NoSQL (Not
Only SQL).
▪▪Surgimento dos ERPs (Enterprise Resource Planning)
centraliza os dados em um único repositório.
▪▪Popularização da internet e aumento da necessidade
de um maior tempo de resposta.
▪▪Projetos de bancos de dados livres.

6 Projeto de Banco de Dados

1.2 O Projeto de Banco de Dados no Ciclo de Vida dos SIs
O ciclo de vida de construção do sistema de informação inclui o ciclo
de vida da construção do sistema de banco de dados, já que os processos de
leitura, processamento e armazenamento de dados são inerentes aos sistemas
de informação. Partindo desse princípio, podemos classificar estes ciclos de
vida como macro, no caso do sistema de informação, e micro, no caso dos
sistemas de banco de dados.

Vamos conhecer melhor esses ciclos?

O Ciclo de Vida Macro

Levando em consideração o ciclo de vida básico da construção de

sistemas, no ciclo de vida macro, podemos considerar os seguintes passos:

▪▪ Análise de viabilidade
▪▪ Realização de estudos preliminares sobre custo-benefício;
▪▪ Determinação da complexidade dos dados e processos;
▪▪ Levantamento e análise de requisitos;
▪▪ Interação com usuários potenciais e grupos de usuários para
identificar suas necessidades.

▪▪ Projeto
▪▪ Projeto do sistema de banco de dados;
▪▪ Projeto dos sistemas da aplicação que utilizam e processam o
banco de dados.

▪▪ Implementação
▪▪ O sistema de informações é implementado;
▪▪ O banco de dados é carregado.

▪▪ Validação e teste de aceitação

▪▪ Validação dos requisitos dos usuários;
▪▪ Validação do desempenho do sistema.

Projeto de Banco de Dados 7

 ▪▪ Implantação, operação e manutenção
▪▪ A fase operacional começa quando as funções do sistema são
validadas;
▪▪ O monitoramento do desempenho e manutenção do sistema são
importantes na fase operacional.

No ciclo de vida macro, ou seja, o ciclo de vida que envolve a produção

dos sistemas de informação, o projeto de banco de dados está inserido na fase
de projeto.

O Ciclo de Vida Micro

Esse ciclo de vida envolve o processo de criação do banco de dados de

um sistema. Suas fases podem ser alinhadas da seguinte forma:

▪▪ Definição de sistemas
▪▪ Definição do escopo do sistema, seus usuários, suas aplicações,
restrições de tempo de resposta e necessidades de armazenamento
e processamento.

▪▪ Projeto de banco de dados

▪▪ Definição de um projeto completo conceitual, lógico e físico do
sistema de banco de dados.

▪▪ Implementação do banco de dados

▪▪ Criação de arquivos vazios de bancos de dados;
▪▪ Implementação das aplicações do software.

▪▪ Carregamento ou conversão do banco de dados

▪▪ Povoamento do banco de dados por carga direta ou convertendo
arquivos existentes para o formato do sistema de banco de dados
(se não for um sistema novo);
▪▪ Conversão das aplicações de software;
▪▪ Conversão de aplicações de sistema anterior (se não for um
sistema novo).

8 Projeto de Banco de Dados

 ▪▪ Teste e validação
▪▪ O sistema é testado e validado.

▪▪ Operação
▪▪ O sistema de banco de dados e suas aplicações são postos em
operação.

▪▪ Monitoramento e manutenção
▪▪ Durante a fase operacional, o sistema é constantemente
monitorado e mantido.

1.3 O Ciclo de Vida de um Sistema de Aplicação de Banco de Dados

Levando em consideração o ciclo de vida micro, ou seja, o ciclo de
vida da construção do banco de dados, temos a fase chamada Projeto de Banco
de Dados, na qual esta disciplina visa se concentrar. Por sua vez, o projeto
de banco de dados poderá ser completamente desenvolvido em seis partes,
descritas a seguir:

Fase 1: Levantamento e Análise de Requisitos

Objetivo: Conhecer e analisar as expectativas dos usuários e suas

intenções de utilização do banco de dados no maior nível de detalhes possível.
É uma fase demorada, porém, crucial; um erro na definição de requisito é
sempre mais caro para corrigir do que um erro de implementação.

Tarefas: Identificação dos usuários do BD e quem terá seu trabalho

afetado por ele. Análise dos tipos de transação e sua frequência.

Artefatos: Documento de visão e minimundo.

Fase 2: Projeto Conceitual de Banco de Dados

Objetivo: Esta fase envolve as atividades de projeto conceitual e do

projeto de transações das aplicações, que ocorrem em paralelo. O objetivo

Projeto de Banco de Dados 9

dessa fase é examinar os requisitos de dados produzidos na Fase 1 e produzir
o esquema conceitual para o banco de dados. Essa fase não depende do SGBD
que será utilizado.

Tarefas: Produzir artefatos que funcionem como veículo de

comunicação entre usuários e analistas e identificar as principais transações
que farão parte do sistema. Geralmente, somente algumas transações do
banco de dados são conhecidas no momento do projeto. As transações mais
importantes são conhecidas antes da implementação do sistema e obedecem a
regra 80-20, ou seja, 80% do volume de operações são representadas por 20%
das transações mais utilizadas.

Artefatos: Diagrama Entidade Relacionamento (DER) ou

Diagrama de Classe da UML (Unified Modeling Language) e Lista de
Transações do Sistema.

Fase 3: Escolha de um SGBD

Objetivo: Escolher o banco de dados que será utilizado, observando

fatores técnicos, econômicos e outros correspondentes à política da organização.

▪▪ Fatores técnicos:
▪▪ Tipo do SGBD (relacional, objeto-relacional, objetos, não
relacional etc.);
▪▪ Estruturas de armazenamento e caminhos de acesso que o
SGBD suporta;
▪▪ Custos a serem considerados (aquisição do software, manutenção,
aquisição do hardware, pessoal, treinamento etc.).

▪▪ Fatores econômicos e organizacionais:

▪▪ Adoção de certa filosofia na organização;
▪▪ Familiaridade do pessoal com o sistema;
▪▪ Disponibilidade de serviços de venda;
▪▪ Disponibilidade de suporte;
▪▪ Portabilidade do SGBD também deve ser levado em consideração.

10 Projeto de Banco de Dados

 Tarefas: Análise comparativa
Saiba Mais
entre SGBDs para a escolha do que
melhor se adapta ao projeto. Para compreender melhor
o processo de escolha do
Artefatos: Não há nenhum SGBD, não deixe de ler
artefato em especial, mas cabe a este artigo disponível no
documentação da análise comparativa Portal DBA.
entre as opções de SGBDs e a
Leia mais
justificativa da escolha da ferramenta
que será adotada no projeto.

Fase 4: Mapeamento do Modelo de Dados (Projeto Lógico do

Banco de Dados)

Objetivo: Elaborar o projeto lógico do banco de dados com base no

modelo conceitual construído na Fase 2. Este mapeamento, normalmente, não
considera características específicas da implementação do modelo de dados,
mas poderá sofrer adaptações para se enquadrar às características específicas
de implementação de um modelo de dados.

Tarefas: Mapear o projeto lógico utilizando as regras definidas para

modelos conceituais construídos em Diagrama Entidade Relacionamento ou
Diagrama de Classe.

Artefatos: Projeto lógico de dados que pode ser representado de

maneira textual ou gráfica.

Fase 5: Projeto Físico do Banco de Dados

Objetivo: Alcançar um melhor desempenho para as aplicações do BD,

por meio da escolha adequada de estruturas de armazenamento e caminhos
de acesso para os arquivos do banco de dados. Nesta fase, alguns critérios são
considerados importantes, como o tempo de resposta, a utilização de espaço
em disco e a taxa de processamento de transações.

Tarefas: Determinar as estruturas de armazenamento e os índices para

os arquivos do banco de dados. É importante perceber que o resultado dessa

Projeto de Banco de Dados 11

fase quase sempre sofrerá modificações ao longo do projeto, pois toda vez
que alguma mudança é implementada, surgem novos códigos para serem
inseridos no banco de dados.

Artefatos: Projeto Físico com os códigos DDL e projeto de índices

do banco de dados.

Fase 6: Implementação do Banco de Dados

Objetivo: Criar os esquemas do banco de dados por meio de

declarações da DDL. Essa fase é realizada após os projetos conceitual, lógico
e físico estarem completos. O banco de dados pode então ser carregado com
os dados. Ao longo da vida do software, quando há alteração nos requisitos
do sistema, normalmente é necessário acrescentar ou retirar tabelas existentes,
reorganizar alguns arquivos, alterar índices, entre outros. O Tuning continua
acontecendo enquanto os problemas de desempenho são descobertos e
enquanto os requisitos continuam a se modificar.

Tarefas: Coletar e monitorar estatísticas de desempenho, utilizando

os utilitários que os SGBDs normalmente possuem.

Artefatos: Não há um artefato específico, mas relatórios com planos

de otimização e melhoria do banco de dados podem ser criados.

1.4 Derivando Esquemas Relacionais a partir de Diagramas ER

A Fase 4 do ciclo de vida do projeto de banco de dados, apresentado
anteriormente, constitui-se na construção do Projeto Lógico do Banco
de Dados que está em desenvolvimento. A elaboração do projeto lógico
visa mapear as tabelas e relacionamentos, por meio de suas chaves
primárias e estrangeiras.

Esse processo é um importante passo para que sejam evitados

retrabalhos no processo de construção do projeto físico de dados, já que o
projeto lógico ajuda na elaboração de estratégias de implementação do banco
de dados. O projeto lógico é uma derivação do projeto conceitual de dados.

12 Projeto de Banco de Dados

 A apresentação do resultado do projeto lógico pode ser feito de
maneira gráfica, conforme mostra o exemplo da Figura 1, ou textual, como
mostra a Figura 2. No caso da representação gráfica, é necessário o uso de
ferramentas, como o ERWin, BR Modelo ou DIA, que permitem a geração
desse diagrama. Nesta disciplina, vamos utilizar o modelo textual para a
representação do projeto lógico.

Empregado Cargo
Matrícula: int CodigoCargo: int
(0,n) (1,1)
Nome: varchar(20) NomeCargo: varchar(20)
CodigoCargo: int Salário: real

Figura 1: Representação Gráfica do Projeto Lógico. Fonte: Do autor.

Empregado (matrícula, nome, codigocargo)

Cargo (codigocargo, nomecargo, salário)

*As chaves primárias estão sublinhadas
*A chave estrangeira está cirulada

Figura 2: Representação Textual do Projeto Lógico. Fonte: Do autor.

Importante
Algumas ferramentas CASE (Computer Aided Software Engineering) permitem que seja
elaborada a engenharia reversa, ou seja, com base em um banco de dados já estabelecido,
a ferramenta produz, automaticamente, o projeto lógico. Embora o processo correto consista
em projetar o banco antes de sua implementação, a engenharia reversa pode ser útil quando
a documentação do banco de dados não for previamente produzida.

O mapeamento do modelo conceitual para o modelo relacional

obedece às regras aplicadas de acordo com o objeto de representação (entidade,

Projeto de Banco de Dados 13

relacionamento ou atributo). É importante esclarecer que as soluções para os
exemplos utilizados aqui não representam a única forma correta de solução.
Sempre caberá ao profissional adotar a melhor solução de acordo com a
situação em estudo.

1.4.1 Entidade / Atributos

Geralmente, as entidades viram tabelas, e os atributos viram colunas
nessas tabelas. Os atributos podem ter desdobramentos diferentes de acordo
com o seu tipo.

Atributo Identificador ou Chave e Atributo Simples ou Atômico

Observe a entidade representada na Figura 3. Neste caso, o Atributo

Identificador ou Chave vira chave primária, enquanto o Atributo Simples ou
Atômico vira coluna. Para fins de representação, as chaves primárias serão
representadas por um sublinhado e as chaves estrangeiras serão representadas
em itálico. Veja:

Matrícula
Nome
Empregado

Figura 3: Entidade Empregado. Fonte: Do autor.

Representação do Projeto Lógico:

▪▪ Empregado (matrícula, nome)

Atributos Multivalorados

Em casos de atributos multivalorados, normalmente devemos criar uma

nova tabela, principalmente, quando a cardinalidade for indefinida (n). Nesse
caso, a chave primária da entidade deverá ser utilizada como chave estrangeira
na nova tabela; além disso, devemos criar uma chave primária para a nova tabela,
chamada de idtelefone. A Figura 4 mostra um exemplo desse caso, observe:

14 Projeto de Banco de Dados

 Matrícula
Nome
Empregado telefone (0,n)

Figura 4: Atributo Multivalorado. Fonte: Do autor.

Representação do Projeto Lógico:

▪▪ Empregado (matrícula, nome)

▪▪ Telefone (idtelefone, numerotelefone, matricula)

Atributos Compostos

Em situações em que o projeto conceitual apresenta um atributo

composto, a solução mais indicada é decompô-lo em tantas colunas quantas
forem as partes do atributo original. A Figura 5 mostra um exemplo desse
caso. Veja:
telefone (0,n)
logradouro
numero
Matrícula complemento
Nome
Empregado endereço bairro
cidade
uf
cep

Figura 5: Atributo Composto. Fonte: Do autor.

Representação do Projeto Lógico:

▪▪ Empregado (matrícula, nome, logradouro, numero, complemento,

bairro, cidade, uf, cep)
▪▪ Telefone (idtelefone, numerotelefone, matricula)

Outra possibilidade é criar uma tabela específica para o atributo

endereço, utilizando o mesmo conceito do atributo multivalorado, ou seja,

Projeto de Banco de Dados 15

chave primária vira chave estrangeira na nova tabela criada. Essa situação
se aplica melhor quando o atributo endereço é, além de composto,
multivalorado, ou seja, o empregado pode ter mais de um endereço para
receber correspondências.

1.4.2 Relacionamentos

Os relacionamentos também poderão apresentar vários desdobramentos

no momento da derivação do modelo conceitual para o lógico. No caso dos
relacionamentos, deveremos observar a sua multiplicidade, ou seja, a sua
participação e a sua cardinalidade, dependendo do caso. Vejamos, a seguir, os
tipos de relacionamentos e as suas técnicas de transformação.

Relacionamento 1:N

Esse tipo de relacionamento ocorre quando a cardinalidade é mínima

de um lado (1) e indefinida no outro lado (N). Na Figura 6, vemos um exemplo
em que o funcionário, obrigatoriamente, deverá ter um cargo, enquanto o
cargo pode ou não ter empregados, ou poderá ter vários empregados ocupando
o mesmo. Exemplo: o funcionário André é Programador; Mário também é,
porém o cargo de Gerente de Projetos não possui empregados.

CodigoCargo
Matrícula (0,n) (1,1)
Empregado Possui Cargo NomeCargo
Nome Salário

Figura 6: Relacionamento 1:N ou N:1. Fonte: Do autor.

Nesse caso, o lado em que a cardinalidade é 1 (cargo) cede uma chave

estrangeira para o lado em que a cardinalidade é indefinida (empregado).

Representação do Projeto Lógico:

▪▪ Empregado (matrícula, nome, codigocargo)

▪▪ Cargo (codigocargo, nomecargo, salario)

16 Projeto de Banco de Dados

 Relacionamento 1:1

Esse é um relacionamento que não ocorre com muita frequência.

Nesse caso, temos duas opções: fundir as entidades ou manter as duas tabelas
e escolher um lado para receber a chave estrangeira. Se um dos lados possuir
a participação como opcional (0), a solução é migrar a chave estrangeira para
o lado do relacionamento opcional. A Figura 7 mostra um exemplo desse tipo
de relacionamento. Observe:

(1,1) (1,1)
Cliente Possui Cartão

nome validade
cpf numero

Figura 7: Relacionamento 1:1. Fonte: Do autor.

Representação do Projeto Lógico:

▪▪ Opção 1: fusão das tabelas

▪▪ Cliente (cpf, nome, número, validade)

▪▪ Opção 2: escolher uma das tabelas para receber a chave estrangeira

▪▪ Cliente (cpf, nome)
▪▪ Cartão (número, validade, cpf)

Relacionamento M:N

Esse relacionamento ocorre quando ambos os lados possuem

cardinalidade indefinida, ou seja N. Convencionou-se chamar esse
relacionamento de muitos para muitos ou M:N. Nesse caso, devemos,
obrigatoriamente, criar uma nova tabela.

A chave primária dessa tabela poderá ser composta pelas duas chaves
primárias das entidades participantes. Ou então, podemos criar uma nova chave

Projeto de Banco de Dados 17

primária, mantendo as duas chaves primárias das entidades participantes como
chaves estrangeiras na nova tabela. Observe a Figura 8 sobre o mapeamento
de relacionamentos desse tipo.

(0,n) (0,n)
funcionario Participa projeto

nome nomeprojeto
matricula codigoprojeto

Figura 8: Relacionamento M:N. Fonte: Do autor.

Representação do Projeto Lógico:

▪▪ Opção 1: Usando as chaves primárias das entidades participantes

como chave primária da nova tabela.
▪▪ funcionario (matricula, nome)
▪▪ projeto (codigoprojeto, nomeprojeto)
▪▪ func-proj (matricula, codigoprojeto)

Nessa solução, criamos uma nova tabela chamada func-proj e

utilizamos as chaves primárias de cada tabela como primárias e estrangeiras,
simultaneamente, na nova tabela.

▪▪ Opção 2: Criando uma chave primária própria.

▪▪ funcionario (matricula, nome)
▪▪ projeto (codigoprojeto, nomeprojeto)
▪▪ func-proj (codalocação, matricula, codigoprojeto)

Nessa solução, criamos uma chave primária própria chamada

codalocação e utilizamos as chaves primárias das entidades participantes como
estrangeiras na nova tabela.

18 Projeto de Banco de Dados

1.4.3 Especialização / Generalização
Esse é um tipo de relacionamento em que possuímos uma entidade
genérica (mãe) e entidades especializadas (filhas). Nesse caso, as entidades
especializadas herdam os atributos da entidade genérica. O mapeamento poderá
ser feito de diversas formas, porém, as mais utilizadas serão apresentadas e
explicadas a seguir. A Figura 9 mostra um exemplo desse caso.

matricula
aluno
nome

monitor bolsista

especialidade percentual
periodo validade

Figura 9: Especialização / Generalização. Fonte: Do autor.

Representação do Projeto Lógico:

▪▪ Opção 1: Criando chaves primárias específicas para as especializações.

▪▪ aluno (matricula, nome)
▪▪ monitor (idmonitor, especialidade, periodo, matricula)
▪▪ bolsista (idbolsista, percentual, validade, matricula)

Nessa primeira opção de resolução, criamos uma chave primária

independente para cada entidade especializada, e usamos a chave primária da
entidade genérica como estrangeira nas tabelas geradas para as especializações.

▪▪ Opção 2: Usando a chave primária da entidade genérica como

primária e estrangeira nas entidades especializadas.
▪▪ aluno (matricula, nome)

Projeto de Banco de Dados 19

 ▪▪ monitor (matricula, especialidade, periodo)
▪▪ bolsista (matricula, percentual, validade)

Importante
É importante não confundirmos os conceitos de uma entidade especializada com uma
entidade normal. Uma especialização sempre apresenta uma variação da entidade
genérica. Exemplo: Uma pessoa jurídica ou uma pessoa física representa tipos de clientes.
Apesar de clientes possuírem algumas características iguais (endereço e telefone) e outras
características distintas (CPF, CNPJ, nome, razão social), ambos são clientes.

1.5 Derivando Esquemas Relacionais a partir de Diagramas de Classes

Como já mencionamos, o projeto conceitual de banco de dados pode ser
representado por meio da utilização do Diagrama Entidade Relacionamento
ou o Diagrama de Classe da UML.

A UML (Unified Modeling Language) é uma linguagem de modelagem

padronizada para representação de sistemas. Ela surgiu, oficialmente, em
1996, e foi aprovada como padrão pela OMG (Object Management Group)
no ano 2000. A linguagem possui 14 diagramas que apoiam a modelagem de
sistemas sob aspectos estruturais e comportamentais.

O Diagrama de Classes é utilizado para a representação de modelos

conceituais de bancos de dados, sendo, atualmente, um dos modelos de
representação mais utilizados por profissionais da área.

A derivação do projeto
conceitual para o projeto lógico Saiba Mais
se aplica da mesma forma que a
utilizada nos projetos conceituais Para compreender melhor o
elaborados com o Diagrama Entidade Diagrama de Classes, leia o
Relacionamento, tendo como artigo indicado, disponível
distinção apenas as notações. Veja, a no site da International
seguir, as representações que utilizam Business Machines (IBM).
o diagrama de classes. Leia mais

20 Projeto de Banco de Dados

1.5.1 Entidades / Atributos

Nesse caso, aplicam-se as mesmas regras do DER. A Figura 10 mostra

a representação da classe empregado, e, na sequência, a representação do
projeto lógico.

Empregado
matrícula : int
nome : string
telefone : string[0..*]
endereco : string

Figura 10: Classe empregado. Fonte: Do autor.

Representação do Projeto Lógico:

▪▪ Empregado (matrícula, nome, logradouro, numero, complemento,

bairro, cidade, uf, cep)
▪▪ Telefone (idtelefone, numerotelefone, matricula)

1.5.2 Relacionamentos

No DER, o mapeamento dos relacionamentos em diagrama de classes

obedece à participação ou cardinalidade do relacionamento. A única mudança
é a representação gráfica do relacionamento. No caso do relacionamento 1: N,
ele é representado por um * (asterisco) em vez da letra N.

Relacionamento 1:*

A Figura 11 mostra o relacionamento 1:* e na sequência o seu

mapeamento.

Projeto de Banco de Dados 21

 Empregado Cargo
matrícula : int codigocargo : int
Possui nomecargo : string
0..* 1
nome : string salario : real

Figura 11: Relacionamento 1:*. Fonte: Do autor.

Representação do Projeto Lógico:

▪▪ Empregado (matrícula, nome, codigocargo)

▪▪ Cargo (codigocargo, nomecargo, salario)

Relacionamento 1:1

A Figura 12 mostra um exemplo de relacionamento 1:1 e o seu

respectivo projeto lógico. A solução é a mesma que aplicamos no projeto
conceitual elaborado com o DER.

Cliente Cartão
cpf : int numero : int
nome : string 1 1 validade : date

Figura 12: Relacionamento 1:1. Fonte: Do autor.

Representação do Projeto Lógico:

▪▪ Opção 1: Fusão das tabelas.

▪▪ Cliente (cpf, nome, número, validade)

▪▪ Opção 2: Escolha de uma das tabelas para receber a chave

estrangeira.
▪▪ Cliente (cpf, nome)
▪▪ Cartão (número, validade, cpf)

22 Projeto de Banco de Dados

 Relacionamento M:N

O relacionamento M:N (muitos para muitos) é representado aqui

com * (asterisco) nas duas extremidades. A resolução ocorre da mesma
maneira que fazemos no DER. A Figura 13 mostra um exemplo com o
diagrama de classes.

funcionario projeto
matricula : int codigoprojeto : int
nome : string * * nomeprojeto : string

Figura 13: Relacionamento M:N. Fonte: Do autor.

Representação do Projeto Lógico:

▪▪ Opção 1: Usando as chaves primárias das entidades participantes

como chave primária da nova tabela.
▪▪ funcionario (matricula, nome)
▪▪ projeto (codigoprojeto, nomeprojeto)
▪▪ func-proj (matricula, codigoprojeto)

Criamos uma nova tabela chamada func-proj e utilizamos as chaves

primárias de cada tabela como primárias e estrangeiras ao mesmo tempo na
nova tabela.

▪▪ Opção 2: Criando uma chave primária própria.

▪▪ funcionario (matricula, nome)
▪▪ projeto (codigoprojeto, nomeprojeto)
▪▪ func-proj (codalocação, matricula, codigoprojeto)

Criamos uma chave primária própria chamada codalocação e

utilizamos as chaves primárias das entidades participantes como estrangeiras
na nova tabela.

Projeto de Banco de Dados 23

1.5.3 Especialização / Generalização
Na especialização, aplicamos os mesmos conceitos utilizados no DER,
sendo que a única mudança é a representação gráfica do projeto conceitual. O
projeto lógico é elaborado da mesma forma. A Figura 14 mostra a generalização
e especialização representada conceitualmente com o diagrama de classes.

aluno
matricula : int
nome : string

monitor bolsista
especialidade : string percentual : int
periodo : date validade : date

Figura 14: Generalização / Especialização. Fonte: Do autor.

Representação do Projeto Lógico:

▪▪ Opção 1: Criando chaves primárias específicas para as especializações.

▪▪ aluno (matricula, nome)
▪▪ monitor (idmonitor, especialidade, periodo, matricula)
▪▪ bolsista (idbolsista, percentual, validade, matricula)

Nessa primeira opção de resolução, criamos uma chave primária

independente para cada entidade especializada e usamos a chave primária da
entidade genérica como estrangeira nas tabelas geradas para as especializações.

▪▪ Opção 2: Usando a chave primária da entidade genérica como

primária e estrangeira nas entidades especializadas.
▪▪ aluno (matricula, nome)
▪▪ monitor (matricula, especialidade, periodo)
▪▪ bolsista (matricula, percentual, validade)

24 Projeto de Banco de Dados

1.5.4 Agregação / Composição
São tipos especiais de relacionamentos. Na agregação, uma classe possui
um vínculo fraco com a outra, podendo existir de maneira independente. Já
a composição representa um vínculo obrigatório entre duas classes, de forma
que se um objeto de uma classe que utiliza uma composição deixar de existir,
o objeto da composição também deixará de existir.

O mapeamento da agregação ocorre da mesma maneira que nos

relacionamentos simples. Já no caso da agregação, a chave estrangeira sempre
será colocada na tabela que utiliza a referida composição. A Figura 15 mostra
o mapeamento de ambos os casos.

prédio sala
codpredio : char numero : int
localização : string * capacidade : int
1

0..*
Computador
numserie : int
configuração : string

Figura 15: Exemplo com Agregação e Composição. Fonte: Do autor.

Nesse exemplo hipotético, temos o relacionamento entre prédio e sala,

em que há uma composição de prédio para sala, ou seja, um prédio é composto
por salas. Caso um prédio seja excluído por algum motivo, as salas também
precisam ser excluídas. Do outro lado, temos uma agregação entre sala e
computador, em que entende-se que uma sala pode não ter computadores ou
ter vários deles, e todo computador deve pertencer obrigatoriamente a uma
sala. Veja como fica o mapeamento lógico:

Projeto de Banco de Dados 25

 Representação do Projeto Lógico:

▪▪ prédio (codpredio, localização)

▪▪ sala (numero, capacidade, codpredio)
▪▪ computador (numserie, configuração, sala)

Em resumo, a sala ganhou a chave estrangeira de prédio e o computador

recebeu a chave estrangeira da sala em que o computador está alocado.

1.5.5 Classe Associativa

Quando acontece um relacionamento de muitos para muitos (M:N),
esse relacionamento apresenta uma classe associativa com atributos gerados a
partir do relacionamento entre as entidades. O mapeamento desses atributos
ocorre dentro da nova tabela criada. A Figura 16 mostra um exemplo de
classe associativa e a sequência mostra o resultado do seu projeto lógico.

Funcionario Projeto
matricula : int codigoprojeto : int
participa
nome : string * * nomeprojeto : string
attribute30 : int
Participa
datainicio : date
datafim : date
horas : int

Figura 16: Classe associativa. Fonte: Do autor.

Representação do Projeto Lógico:

▪▪ funcionario (matricula, nome)

▪▪ projeto (codigoprojeto, nomeprojeto)
▪▪ func-proj (matricula, codigoprojeto, datainicio, datafim, horas)

26 Projeto de Banco de Dados

Síntese
Nesta unidade de aprendizagem, vimos a importância do projeto de
banco de dados, situando-o dentro do ciclo de vida do software. Também
foram exploradas as fases que compõem o ciclo de vida do projeto de banco
de dados, que nos ajuda a entender quais etapas devemos nos preocupar ao
longo da construção de um banco de dados.

Também vimos que, para o projeto de banco de dados, utilizamos as

representações conceituais elaboradas com base nos Diagramas de Entidade
Relacionamento ou de Diagramas de Classe, que representam aspectos do
mundo real, para a sua posterior derivação para o projeto lógico. Além disso,
aprendemos que o projeto lógico é um importante passo para a geração de um
projeto físico mais estruturado, em que o retrabalho é minimizado.

É importante ressaltarmos que muitas soluções aqui apresentadas

podem ser empregadas de maneira diferente no ambiente prático, com o
objetivo de favorecer questões como desempenho ou simplicidade do esquema
de banco de dados.

Projeto de Banco de Dados 27

Referências Bibliográficas
DATE, C. J. Introdução a Sistemas de Banco de Dados. 8 ed. Rio de
Janeiro: Campus, 2004.

ELMASRI, R. Sistemas de Banco de Dados. 4 ed. Rio de Janeiro: Pearson

Education do Brasil Ltda, 2005.

GREENWALD, Rick; STACKOWIAK, Robert; STERN, Jonathan. Oracle

Essencial: Banco de Dados Oracle 11g. Rio de Janeiro: Alta Books, 2009.

IBM. O Diagrama de Classes. Disponível em: https://www.ibm.com/

developerworks/br/rational/library/content/RationalEdge/sep04/bell/index.
html. Acesso em: 15 fev. 2018.

MANZANO, Jose A. N. G. PostgreSQL 8.3.0 Interativo: Guia de Orientação

e Desenvolvimento. São Paulo: Érica, 2008.

PORTAL DBA. Critérios para a escolha de um SGBD. Disponível em:

http://www.portaldba.com.br/criterios-para-a-escolha-de-um-sgbd/.
Acesso em: 15 fev. 2018.

ROB, P.; CORONEL, C. Sistemas de Banco de Dados: Projeto,

implementação e Administração. 8 ed. São Paulo: Cengage, 2010.

SCHWARTZ, Zaitsev; TKACHENKO, Zawod. Alto Desempenho em
MySQL. 2 ed. Rio de Janeiro: Alta Books, 2009.

28 Projeto de Banco de Dados