BANCO DE DADOS I (IL10327)_ebook

Prévia do material em texto

SISTEMA GERENCIADOR 
DE BANCO DE DADOS
SISTEMA GERENCIADOR 
DE BANCO DE DADOS
Copyright © UVA 2019
Nenhuma parte desta publicação pode ser reproduzida por qualquer 
meio sem a prévia autorização desta instituição.
Texto de acordo com as normas do Novo Acordo Ortográfico 
da Língua Portuguesa.
AUTORIA DO CONTEÚDO
Claudio Fico Fonseca
REVISÃO
Luiz Werneck
Clarissa Penna
Janaina Senna
Lydianna Lima
PROJETO GRÁFICO
UVA
DIAGRAMAÇÃO
UVA
SUMÁRIO
Apresentação
Autor
6
8
Modelo de Dados 36
• UML
• Levantamento de requisitos
• Modelagem de dados
UNIDADE 2
9
• Banco de dados
• Modelos de Banco de Dados
• Sistema Gerenciador de Banco de Dados – SGBD
Sistema de Gerenciamento de Banco de Dados
UNIDADE 1
SUMÁRIO
Normalização de dados 111
• Engenharia reversa
• As três formas normais
• Forma normal Boyce-Codd
UNIDADE 4
79
• Conceito
• Relacionamento entre as classes
• Modelando o diagrama de classes
Diagrama de classes
UNIDADE 3
6
A disciplina Sistema Gerenciador de Banco de Dados – SGBD visa ao entendimento da 
necessidade de aplicação e de implementação de um SGBD nas empresas. Ao longo 
das aulas, você vai perceber que o uso dessa tecnologia permite o fortalecimento e o 
engrandecimento do negócio junto ao mercado globalizado. Além disso, você vai ver 
que é importante ter um ou mais sistemas de informação conectados a uma excelente 
base de dados, para que os negócios possam ser geridos de forma plena e segura.
O SGBD consiste em um conjunto tecnológico de recursos utilizados para:
• Tratar a informação.
• Gerar segurança nos dados.
• Permitir eficiência e eficácia na comunicação, incluindo software, hardware e rede 
de comunicação de dados.
O SGBD vem se tornando cada vez mais importante no nosso contexto por conta da 
globalização, que permitiu, ao longo dos anos, que as empresas pudessem ter informa-
ções mais rápidas e precisas.
Além disso, o SGBD tem prospectado novas oportunidades de trabalho, crescimento de 
novos cenários de negócios, aumento do comércio e investimento de empresas inter-
nacionais. Entretanto, apesar dessas modificações positivas, os avanços em tecnologia 
estão gerando malefícios, como, por exemplo, os novos custos para os processos.
Nesta unidade, você verificará que os SGBDs são essenciais para as operações diárias 
das empresas, para que possam ter o controle sobre as suas informações e, a partir 
delas, criar estratégias para potencializar o negócio. 
APRESENTAÇÃO
7
As inovações tecnológicas permitirão que as empresas experimentem sempre um 
rápido crescimento, tendo em vista a qualificação oferecida a seus profissionais, 
bem como as oportunidades de aquisição de hardwares e softwares com maior po-
tência para o engrandecimento do negócio. Isso permitirá uma expansão até com o 
mercado internacional.
8
CLAUDIO FICO FONSECA
Graduado em Informática, especialista em Marketing, MBA em Gestão Empresarial, MBA 
em Gerenciamento de Projetos, mestre em Educação e doutor em Gestão Educacional. 
Exerce na Universidade Veiga de Almeida – UVA os cargos de diretor de Desenvolvimento 
Institucional, coordenador do curso de Sistemas da Informação (presencial e EAD), 
coordenador do curso de Análise e Desenvolvimento de Sistemas (EAD), coordenador 
do curso de Gestão da Tecnologia da Informação (EAD), coordenador do Núcleo de 
Certificação Profissional e Internacional, coordenador de MBA em Gestão Estratégica 
de TI. Exerceu o cargo de diretor da Escola de Tecnologia da Informação e Inovação 
das Faculdades Integradas de Jacarepaguá – FIJ; diretor de pós-graduação e extensão 
e consultor de Tecnologia da Informação na Master Educacional, pró-reitor acadêmico 
e diretor de tecnologia do Grupo Educacional Anglo-Americano, vice-reitor adjunto, 
diretor de Certificação Profissional e gerente de TI do Centro Universitário da Cidade 
do Rio de Janeiro. Atua como conselheiro de Educação e Novas Tecnologias, membro 
da Associação Brasileira de Educação, membro titular do Conselho Ibero-Americano, 
avaliador institucional e de cursos da área de informática e cursos superiores de tecnologia 
do Ministério da Educação/INEP, avaliador de cursos do Guia do Estudante e perito de 
Tecnologia da Informação da Justiça do Trabalho.
AUTOR
C. Lattes
http://lattes.cnpq.br/6387003742232768
Sistema de Gerenciamento 
de Banco de Dados
UNIDADE 1
10
Nesta unidade, você estudará o conceito e a importância do SGBD dentro uma pers-
pectiva teórica; conhecerá os diversos usos de um SGBD na empresa, bem como suas 
respectivas aplicações; saberá a importância dos princípios do gerenciamento da infor-
mação para a melhoria e a segurança do negócio. 
INTRODUÇÃO
Nesta unidade, você será capaz de:
• Conhecer os conceitos de banco de dados, seu papel na construção de um pro-
jeto de sistemas, especialmente o SGBD, para garantir a aplicação em um sistema 
computacional de informações e a importância da informação em um sistema, de 
acordo com a perspectiva de cada usuário ou grupo de usuários.
OBJETIVO
11
Banco de dados 
O que são bancos de dados?
Podemos trabalhar com duas nomenclaturas diferentes: bancos de dados e/ou bases 
de dados. Definir bancos de dados, por outro lado, não é tão simples. Observe, a seguir, 
algumas definições possíveis:
Bancos de dados são conjuntos de 
informações que se relacionam criando 
um sentido. São de grande importância 
para toda e qualquer empresa e, há duas 
décadas, tornaram-se peça-chave de 
todos os sistemas de informação.
Bancos de dados são conjuntos de 
arquivos que se comunicam entre si, 
proporcionando o armazenamento de 
uma grande quantidade de dados: nomes, 
telefones, documentos, pagamentos, 
endereços, clientes, serviços etc. 
Os bancos de dados precisam ser 
configurados e administrados por meio 
das linguagens de programação, como, por 
exemplo: JavaScript, SQL, PL/SQL etc.
De forma simples, um banco de dados nada mais é do que um ambiente de 
armazenamento de dados. Em um mundo cada vez mais digital, o controle, a 
necessidade e a gestão desses dados podem ser os diferenciais para conseguir 
sucesso no mercado.
Um banco de dados é, na verdade, 
uma estrutura de dados organizada, 
que possibilita a busca de informações 
direcionadas.
Bancos de dados são uma coleção
de dados interligados entre si e
organizados para fornecer informações
de grande importância.
Como um banco de dados é estruturado?
É importante frisarmos que um banco de dados pode possuir uma ou mais tabelas. Dentro 
da tabela, os dados são organizados em linhas e colunas e podem ser indexados ou
12
não (opção que a tabela oferece no momento de sua configuração), o que caracteriza 
uma grande facilidade para encontrar informações relevantes. Os dados, dentro de uma 
determinada tabela, podem ser incluídos, alterados e excluídos, conforme as informações 
são tratadas e em função das demandas. A tabela, em conjunto com o banco de dados, 
ajusta-se para criar e atualizar seu próprio volume, consultando os dados e executando 
aplicativos internos.
Nos dias de hoje, é possível encontrar diversos tipos de banco de dados, mas eles estão 
presentes na nossa vida há muito tempo. Como exemplo, podemos citar as antigas listas 
telefônicas, que, hoje, são os contatos dos respectivos smartphones. Podemos levar em 
consideração esse exemplo por se tratar de um conjunto de informações importantes 
com grande representatividade para o nosso dia a dia. Afinal, quem é que hoje memoriza 
um número de telefone?
No passado, era comum que as empresas 
armazenassem suas informações em arquivos 
físicos (folha de papel, cartão etc.), mas, com 
o surgimento e a evolução dos computadores 
portáteis e de grande porte, tornou-se possível o 
armazenamento de dados e informações de modo 
digital. Dessa forma, os bancos de dados passaram 
a evoluir em larga escala e começaram a se tornar 
o coração de vários sistemas de informação.
Dados versus informações
Muitos estudiosos consideram os termos dado e informação sinônimos, mas, na 
verdade,não são. Para que se possa entender, na íntegra, o que é um banco de dados é 
fundamental saber a diferença entre esses dois termos:
Dados são fatos brutos, não lapidados, 
em sua forma mais primária. Na maioria 
das vezes, os dados podem não fazer 
sentido quando estão sozinhos.
Informações consistem na união 
de dados bem organizados para 
que haja um sentido e, assim, gere o 
conhecimento necessário para uma ou 
mais demandas.
13
Exemplo
Observe o exemplo a seguir.
O número 2019 de forma isolada faz algum sentido? É claro que não! Isso é o 
que chamamos de “dado”. 
E se fosse dito que: “O ano do crescimento da economia é 2019”? Agora pode-
se dizer que há um sentido. Isso é o que chamamos de “informação”.
No exemplo anterior, do número 2019, o dado “o ano do crescimento da 
economia” pode ser considerado um metadado, pois ele é um dado relevante 
sobre o dado “2019”. 
Outro exemplo bem interessante em banco de dados é o campo “telefone” 
da tabela “FORNECEDOR”. Esse tipo de campo tem os seguintes metadados, 
entre outros: 
• Nome do campo (telefone).
• Tipo do campo (inteiro).
• Tamanho do campo (nove posições).
• Obrigatoriedade de preenchimento (não) etc.
Metadados
Todo dado que é pertinente a outro dado é denominado metadado. 
Exemplo
Um banco de dados é formado, obrigatoriamente, por dados e metadados. Sem a 
existência dos metadados não seria possível organizar e extrair informações pertinentes 
de um banco de dados e, assim, não seria possível atender às demandas.
14
A importância do banco de dados
O banco de dados armazena, controla e gerencia os bens mais valiosos que uma 
empresa, na atualidade, pode possuir. Isso se dá porque o mercado profissional está 
cada vez mais competitivo, acelerado e dinâmico, demandando das empresas respostas 
ágeis e assertivas, além da necessidade de estratégias bem estruturadas para uma 
determinada execução. O banco de dados armazena dados e, nessa gigantesca luta de 
competitividade, o dado preciso é sinal de poder.
Por meio dos processos de armazenamento, controle e gerenciamento de dados, toda a 
estrutura de funcionamento de uma empresa é galgada. Podemos afirmar que, em todo 
lugar, há um tipo de banco de dados. Por menor que seja o negócio, quando um gestor utiliza 
um aplicativo para organização financeira, por exemplo, está sendo utilizada uma espécie 
de banco de dados. Esse tipo de banco de dados pode ser classificado como simplificado 
e automatizado, que armazena, processa e fornece informações sobre finanças.
Por outro lado, quando se tem em seu negócio um banco de dados bem gerido e informações 
de qualidade, o resultado, na maior parte das vezes, é de total sucesso. Assim, é possível 
que o gestor possa analisar as informações e verificar em qual direção a sua empresa está 
caminhando, com isso poderá corrigir o caminho e/ou ampliar a sua atuação.
Outro ponto importante quanto ao uso de banco de dados é que é possível realizar uma 
série de levantamentos. Veja alguns exemplos: 
• O rendimento de um ou mais funcionários pode ser analisado. 
• Bem como a qualidade do atendimento desse funcionário. 
• O impacto das ações de marketing realizadas pela empresa. 
• O retorno obtido por ações empreendidas. 
• Outras inúmeras aplicações.
Para o cliente que também se utiliza do banco de dados, o efeito é rápido e objetivo. 
Acompanhe o exemplo a seguir:
15
Exemplo
Pense no cliente que compra um produto em um site e, depois, faz o 
acompanhamento do processo de pagamento, de preparação do produto e de 
todas as etapas da entrega. 
No dia a dia, quando se tem à disposição um banco de dados bem administrado, 
a relação cliente e empresa fica muito mais transparente e prazerosa, pois 
as necessidades do consumidor são reconhecidas de imediato e atendidas 
prontamente. Todos esses cuidados criam uma experiência mais salutar para 
o cliente.
Vantagens de um banco de dados
Você já percebeu que são muitas as vantagens do uso de bancos de dados. A seguir, 
listamos algumas:
Redução ou eliminação de redundâncias: faz com que haja a eliminação de dados 
repetidos entre cada sistema. Os dados, que serão os mesmos em mais de um sistema, 
possuem compartilhamento entre si, permitindo o acesso a uma mesma informação, 
sendo consultada por vários usuários em muitos sistemas.
Eliminação de inconsistências: a informação é armazenada em um só local, cujo 
acesso é descentralizado, e seu conteúdo é compartilhado com vários sistemas; isso 
permite que os usuários se utilizem de uma informação fidedigna. A inconsistência da 
informação ocorre quando um mesmo campo da tabela possui informações diferentes 
em sistemas diferentes. Veja o exemplo: o estado de moradia de uma pessoa é “SP” 
em um determinado sistema e “MG” em outro sistema da empresa. Isso ocorre porque 
a informação, de certa forma, foi atualizada em um campo da “Tabela A”, mas não foi 
atualizada no mesmo campo da “Tabela B”. Quando a informação é armazenada em um 
único local e compartilhada pelos devidos sistemas de forma integrada, esse problema 
certamente não ocorre.
Compartilhamento dos dados: faz com que ocorra o uso simultâneo e seguro de 
um dado de uma determinada tabela, utilizado por mais de um sistema ou usuário, 
independentemente da operação que esteja sendo realizada naquele momento. O 
importante é observar, apenas, o processo de atualização simultâneo da informação, 
16
para que não haja geração de erros no momento do processamento. Esse cuidado deve 
ser tomado uma vez que os aplicativos, nos dias de hoje, são, na sua maioria, sistemas 
multiusuários, ou seja, permitem que vários usuários tenham acesso simultâneo àquela 
informação.
Restrições de segurança: faz com que haja uma definição, deliberada por alguém de 
representatividade na empresa, para o nível de acesso ao sistema de cada usuário. Os 
níveis de acesso são: leitura, inclusão, alteração e exclusão. Dependendo do nível de acesso 
do usuário, ele será impedido de utilizar um ou outro recurso que possa impactar os dados 
da tabela do banco de dados. Um exemplo é o impedimento de excluir alguma informação.
Padronização dos dados: faz com que haja uma harmonização na forma como os dados 
são gravados nas respectivas tabelas. Por exemplo, para o campo “Sexo”, somente será 
permitido o armazenamento dos conteúdos “M” ou “F”. Assim, a tabela não aceitará 
nenhuma outra informação.
Manutenção da integridade: tem o objetivo de evitar que valores indevidos ou 
inconsistentes sejam gravados em uma respectiva tabela do banco de dados, como a 
inclusão do campo código ou da chave primária de uma tabela que não tenha correlação 
com outra tabela do banco de dados. Acompanhe um caso prático: a criação de um 
código de uma determinada disciplina na tabela “Histórico Escolar” sem que haja a 
existência desse código na tabela “Disciplina”.
Alguns importantes banco de dados utilizados no mercado
Mesmo com o crescimento dos bancos de dados no mercado corporativo, ainda é 
comum ouvir dos profissionais a pergunta: quais são os bancos de dados mais utilizados 
do mercado? 
Veja, a seguir, uma lista com os principais exemplos de banco de dados existentes no 
mercado profissional.
17
• O banco de dados Oracle foi lançado em 1980 e é o que temos de melhor no 
mercado. 
• É um banco de dados relacional que predomina no mercado há bastante 
tempo. 
• Sua linguagem de programação é o PL/SQL.
• Para os profissionais de TI, o domínio do SQL é algo fundamental. Mas ter o 
domínio do Oracle e PL/SQL é o segundo passo para se ter uma infinidade de 
oportunidades junto ao mercado de trabalho.
• Esse é o famoso banco de dados da empresa Microsoft e, no momento, é o 
terceiro colocado no ranking de preferências.
• Foi lançado em 1989 e também é um banco de dados relacional. 
• Com o crescimento das ferramentas de open source, depois de longos 27 
anos de mercado, a Microsoft lançou uma versão para o sistema operacional 
Linux.
• É um banco de dados bastante utilizado no mercado, mas devido ao fato 
deele, hoje, suportar linguagens do pacote .NET, além de a sua linguagem 
nativa ser o T-SQL, não é tão valorizado como o banco de dados Oracle. 
• É um banco de dados gratuito que tem sido muito utilizado em sistemas on-
line. Ele também pertence à família Oracle e foi lançado em 1996. 
• Também é considerado um banco de dados relacional.
• Os profissionais com conhecimentos em MySQL também são bem 
valorizados pelo mercado profissional, embora menos do que os profissionais 
com domínio do Oracle.
Oracle (pago)
SQL Server (pago)
MySQL (free)
18
• É um banco de dados relacional, com característica open source, da empresa 
PostgreSQL Global Development Group. Seu lançamento se deu em 1989.
• Pelo fato de ser open source, assim como o banco de dados MySQL da 
Oracle, é bastante utilizado para sistemas web.
PostgreSQL (free)
MIDIATECA
Acesse a midiateca da Unidade 1 e veja o conteúdo complementar indicado pelo 
professor sobre bancos de dados e sua importância no dia a dia das pessoas.
19
Modelos de Banco de Dados 
Neste tópico, você vai conhecer uma série de definições importantes para o 
desenvolvimento do trabalho com bancos de dados. Vamos lá?
Modelos de banco de dados
Um modelo de banco de dados demostra a sua estrutura lógica, inserindo e exibindo as 
relações e restrições que determinam como os respectivos dados poderão ser armazenados 
e acessados. Os modelos de banco de dados individuais são, na íntegra, projetados a 
partir das regras e dos conceitos do modelo de dados mais abrangente adotado pelos 
designers de banco de dados. A maior parte dos modelos de dados desenvolvidos pode 
ser representada por um determinado diagrama de banco de dados acompanhante.
Instâncias
É o conjunto de informações contidas em um banco de dados, em um dado momento.
Independência de dados
É a forma que se tem para a modificação e a respectiva definição dos esquemas existentes 
em determinado nível, sem que este afete de alguma forma o esquema do nível superior.
Existem dois tipos de independência. Conheça cada tipo, a seguir:
Permite que haja a possibilidade de 
modificação do esquema físico sem que 
qualquer programa utilizado no sistema precise 
ser refeito. As modificações oriundas no nível 
físico são deveras importantes, principalmente 
para que haja uma melhora significativa no 
desempenho do sistema e do banco de dados.
Faz com que se tenha uma capacidade de 
modificação do esquema lógico sem que 
qualquer programa desenvolvido na aplicação 
precise ser refeito. As modificações pertinentes 
no nível lógico são necessárias desde que uma 
referida estrutura lógica do banco de dados seja 
alterada por uma necessidade de adequação e/
ou melhoria de performance.
Física Lógica
20
Curiosidade
A independência lógica de dados é muito mais difícil de ser mensurada do que 
a independência física de dados. Isso porque os programas desenvolvidos no 
sistema são mais dependentes da estrutura lógica dos dados do que de seu 
acesso.
Os três níveis da arquitetura
A arquitetura ANSI/SPARC se divide em três níveis, conhecidos como nível interno, nível 
conceitual e nível externo. Entenda como cada um está organizado:
É conhecido, também, como nível físico. É o mais próximo do meio 
de armazenamento físico, ou seja, é aquele que se ocupa do modo 
como os dados são fisicamente armazenados.
Também conhecido como nível lógico do usuário. É o mais próximo 
dos usuários, ou seja, é aquele que se ocupa do modo como os 
dados são vistos por usuários individuais.
Esse nível, também conhecido como nível lógico comunitário, é um 
nível de simulação entre os dois níveis anteriores: interno e externo.
Nível interno
Nível externo
Nível conceitual
Tipos de modelos de bancos de dados
Temos vários tipos de modelos de dados utilizados no mercado profissional. Os mais 
comuns são:
21
• Hierárquico.
• Relacional.
• Rede.
• Entidade-relacionamento.
• Orientado para objetos.
• Entidade-atributo-valor.
• Modelo documental.
• Esquema em estrela.
• Relacional-objeto.
Com uma lista tão vasta de modelos de bancos de dados, você deve estar se perguntando: 
qual o melhor modelo a ser utilizado?
Nos dias de hoje, você poderá optar por desenvolver um banco de dados com qualquer 
um desses modelos. O fator diferenciador é se o sistema de gestão adotado pelo banco 
de dados que você usa suportará o modelo escolhido. A maior parte dos sistemas de 
gestão de banco de dados é construída com um modelo de dados particular e demanda 
que seus usuários adotem esse modelo, mesmo sabendo que alguns disponibilizam 
suporte a vários outros modelos.
Diante disso, diversos modelos de banco de dados aplicam-se para diferentes estágios 
do processo de criação de um banco de dados. Entenda que critérios colaboram para a 
escolha dos modelos de bancos de dados:
Os modelos de dados conceituais de 
alto nível são tidos como os melhores 
para coordenar as relações entre os 
dados de forma que os desenvolvedores 
percebam esses dados.
Os modelos lógicos, que são baseados 
em registros, refletem bem melhor 
as formas com que os dados são 
armazenados no servidor.
Importante
Definir qual o modelo de dados a ser usado é uma questão de definir suas 
prioridades para o banco de dados, tendo em vista os pontos fortes de um 
determinado modelo, independentemente de essas prioridades incluírem no 
seu contexto a questão da velocidade, da usabilidade e da redução de custos.
22
A seguir, saiba quais são os modelos de bancos de dados mais utilizados:
1. Modelo hierárquico
O modelo hierárquico foi muito utilizado, principalmente, pelos Sistemas de 
Gestão de Informações da IBM, entre os anos de 1960 e 1970. Hoje raramente 
são vistos devido a certas dificuldades operacionais.
Esse modelo organiza os dados em uma forma do tipo “árvore”, em que cada 
registro constituído tem um único “pai” ou uma raiz. Os registros caracterizados 
como “irmãos” são classificados em uma ordem específica. Essa ordenação é 
utilizada como a ordem física para armazenar o banco de dados. Esse modelo é 
bom para descrever muitas relações do mundo real.
2. Modelo relacional
O modelo relacional foi introduzido por E. F. Codd no ano de 1970. Os bancos de 
dados relacionais são escritos na linguagem SQL (Structured Query Language) 
e, atualmente, são considerados o modelo mais comum. Ele classifica os dados 
em tabelas, conhecidas como relações, e cada uma das tabelas é constituída de 
linhas e colunas:
• As colunas exibem atributos da entidade em questão, como data de nascimento, 
valor, CEP, entre outros. Unidos, os atributos em uma relação são denominados 
de domínio. Um atributo ou combinação de atributos específicos é determinado 
como uma chave primária que pode ser consultada em outras tabelas; quando 
isso acontece, existe a denominação de chave estrangeira.
• Cada linha da tabela, também denominada de tupla, inclui os dados sobre uma 
instância específica da entidade.
O modelo também ressalta os tipos de relações que há entre essas tabelas, 
incluindo as relações uma para uma, uma para muitas e muitas para muitas.
Dentro do banco de dados, é sabido que as tabelas podem ser normalizadas ou 
orientadas a seguir as regras de normalização que tornam o banco de dados 
adaptável, flexível e redimensionável. Quando normalizado, cada dado é atômico 
ou dividido em pequenos pedaços úteis.
23
3. Modelo de rede
Sua popularidade se deu nos anos de 1970, depois de ter sido validado pela 
Conferência sobre Linguagens de Sistemas de Dados ― CODASYL.
Esse modelo se caracteriza como o modelo hierárquico, permitindo que haja 
muitas possibilidades de relações entre os registros, formando vínculos. 
Isso implica a existência de vários registros do tipo “pai”. Com base na teoria 
dos conjuntos matemáticos, o modelo de rede é desenvolvido a partir de 
um conjunto de registros relacionados. Cada conjunto possui um registro 
proprietário, ou “pai”, e um ou mais registros membros, caracterizados como 
“filhos”. Um determinado registro pode ser caracterizadocomo membro ou 
como “filho”, em diversos conjuntos, permitindo, assim, que esse modelo seja 
capaz de transmitir relações complexas.
4. Modelo entidade-relacionamento
Esse modelo pega as relações entre as entidades do mundo real, de forma 
parecida com o modelo de rede, mas não está diretamente conectado com a 
estrutura física do banco de dados. Contudo, ele é constantemente utilizado 
para projetar um banco de dados de forma conceitual.
Temos definições de nomenclaturas como: pessoas; lugares; cidades. Essas 
definições serão armazenadas e referidas como “entidades”, cada uma 
possuirá determinados atributos que, em conjunto, compõem seu domínio. A 
cardinalidade, ou relação entre entidades, também é definida.
Uma forma bem comum do diagrama entidade-relacionamento é o uso do 
esquema em estrela, no qual uma tabela de fatos central se interliga a outras 
tabelas multidimensionais.
Modelos de banco de dados orientado para objetos
Esse modelo define o banco de dados como um conjunto de objetos, ou elementos 
reutilizáveis, com recursos e métodos associados. Existem dois tipos de bancos de 
dados orientados para objetos no mercado:
24
Saiba mais
O modelo de banco de dados orientado para objetos é tido como um modelo 
“pós-relacional”, tendo em vista que ele incorpora tabelas, mas não se limita a 
elas, necessariamente. 
Esse modelo de banco de dados também é tido como modelo híbrido. Um 
banco de dados híbrido faz a sinergia entre a simplicidade do modelo de banco 
de dados relacional com algumas das funcionalidades avançadas do modelo 
de banco de dados orientado para objetos. Na sua essência, ele flexibiliza para 
que os designers possam incorporar objetos na estrutura familiar da tabela.
As interfaces de linguagem de programação e chamadas incluem: linguagens 
de fornecedor; SQL3; JDBC; ODBC; interfaces proprietárias, cujas extensões 
permeiam as linguagens e interfaces usadas pelo modelo relacional.
Mais modelos de bancos de dados utilizados
Hoje temos uma gama de modelos de banco de dados que foram, ou ainda são, utilizados 
no mercado profissional para o desenvolvimento de softwares. Conheça esses modelos, 
a seguir:
• Plano: esse é o modelo mais simples a ser utilizado pelo desenvolvedor e também 
é o mais antigo. Permite a listagem de todos os dados em uma única tabela, que 
consiste em um conjunto de linhas e colunas.
• Arquivo invertido: esse modelo foi desenvolvido com base em uma estrutura 
de arquivo totalmente invertido. O objetivo desse desenvolvimento foi facilitar a 
agilidade em pesquisas e em textos com características mais complexas.
Multimídia
 
Faz a incorporação de mídias, como, por 
exemplo, as imagens, que não podem 
ser gravadas em um banco de dados do 
tipo relacional.
Hipertexto 
Possibilita que qualquer objeto seja ligado 
a qualquer outro objeto. É útil quando 
se tem a demanda de organizar lotes de 
dados diferentes, mas não é indicado 
para se trabalhar com análise numérica.
25
• Multidimensional: nada mais é do que uma variação do modelo relacional criado 
para facilitar o processamento analítico das informações. O modelo relacional é 
otimizado para o processamento de transações on-line – OLTP. Esse modelo, por 
sua vez, foi projetado para o processamento analítico on-line – OLAP.
• • Associativo: permite que haja a divisão de todos os dados com relação ao 
que eles representam em uma entidade (tabela) ou em uma associação entre as 
entidades (tabelas). Uma entidade pode existir de forma independente, enquanto 
uma determinada associação é um elo que só existirá quando houver um ponto de 
comunicação com uma outra entidade. É sabido que o modelo associativo permite 
a organização dos dados para que haja a existência de dois conjuntos:
• Conjunto de itens: fará com que haja um identificador exclusivo: nome e tipo.
• Conjunto de links: fará com que cada identificador exclusivo tenha uma fonte: 
verbo; destino. A informação armazenada tem relação com a fonte definida, e 
cada um dos dois identificadores poderá se conectar a um link ou a um item.
Modelos de bancos de dados denominados “não SQL”
Com a evolução dos modelos de banco de dados utilizados pelos desenvolvedores 
de softwares, tivemos a criação de modelos tidos como “não SQL”, que surgiram em 
comparação com o modelo de banco de dados relacional, são eles:
É ainda mais flexível do que um modelo de rede e permite 
que qualquer nó se conecte a qualquer outro.
Diferencia-se do modelo de banco de dados relacional, pois 
permite que os atributos contenham uma lista de dados em 
vez de um único ponto de dados.
É projetado para armazenar e gerenciar documentos ou 
dados semiestruturados, no lugar de dados atômicos, como 
a maioria dos modelos de banco de dados.
Gráfico
Multivalores
Documento
26
Bancos de dados usados na internet
A maioria dos sites desenvolvidos para 
empresas depende de algum tipo de 
banco de dados para armazenar, orga-
nizar, estruturar e apresentar resultados 
para os usuários. 
Cada vez que alguém acessa as funções 
de pesquisa contidas nesses sites, seus 
termos de pesquisa são transformados 
em consultas para um servidor de banco de dados processar e retornar com uma res-
posta. Geralmente, o “middleware” conecta o servidor da web com o banco de dados.
A grande presença dos bancos de dados nos sistemas desenvolvidos para os sites per-
mite que eles sejam usados em quase todas as áreas segmentadas, desde compras 
on-line até a microssegmentação de um determinado segmento.
MIDIATECA
Acesse a midiateca da Unidade 1 e veja o conteúdo complementar indicado pelo 
professor sobre a importância da modelagem dos bancos de dados utilizados 
na web.
27
Sistema Gerenciador de Banco de Dados – 
SGBD 
O que é um SGBD?
O SGBD é constituído por um conjunto de programas para acesso a todos os dados 
armazenados. O conjunto de dados, como você já sabe, é comumente chamado de banco 
de dados. O principal objetivo de um SGBD é proporcionar um ambiente tanto conveniente 
como eficiente para a recuperação e o armazenamento das informações do banco de 
dados. Esses sistemas são projetados para gerir grandes volumes de informações, o que 
implica:
• A definição de estruturas de armazenamento das informações. 
• A definição dos mecanismos para a manipulação dessas informações.
Além disso, um sistema de banco de dados deve garantir a segurança das informações 
armazenadas contra eventuais problemas com o sistema e impedir tentativas de acesso 
não autorizadas. Se os dados são compartilhados por diversos usuários, o sistema deve 
evitar a ocorrência de resultados anômalos.
Na sequência, você vai conhecer melhor os SGBDs e suas especificidades.
Componentes
Os componentes de um SGBD são:
• Ferramenta CASE.
• Gerador de relatórios.
• Linguagem de consulta.
• Planilhas eletrônicas.
• Pacotes estatísticos.
• Ferramentas para gerenciamento de cópias ou extração de dados.
28
Classificação quanto ao número de usuários
Como vimos anteriormente, o SGBD é um sistema de computador com um propósito 
geral de armazenar informações importantes e permitir aos usuários que tenham acesso 
para buscar e atualizar informações quando solicitado. Quanto ao número de usuários, 
os SGBDs podem ser classificados em dois tipos:
É um sistema em que no mínimo um 
usuário e no máximo um usuário poderá 
ter acesso à base de dados. 
Isso significa que somente um usuário 
poderá, por meio do sistema, acessar a 
base de dados.
É um sistema em que vários usuários, si-
multaneamente, poderão acessar o ban-
co de dados.
É a forma em que o mercado, nos dias 
de hoje, tem projetado seus bancos de 
dados.
Monousuário Multiusuário
Funcionalidades, requisitos e elementos
As funcionalidades, requisitos e elementos de um SGBD podem ser observados a seguir:
A diferenciação entre os SGBDs é feita 
pelo conjunto de funcionalidades e re-
quisitos que eles oferecem, tais como: 
• Controle de concorrência. 
• Integridade. 
• Recuperação/tolerância a falhas. 
• Segurança.
Os SGBDs também sãoidentificados por 
possuírem elementos como: 
• “Motor de arranque” da base de da-
dos. 
• Subsistema de manipulação de da-
dos. 
• Subsistema de definição dos dados. 
• Administração de dados. 
• Subsistema de geração das aplica-
ções.
É importante que os SGBDs abranjam as funcionalidades específicas necessárias para 
que as tabelas das bases de dados possam se relacionar plenamente e para que haja 
interação entre os dados constantes nos bancos de dados.
29
Características e funções
 
Veja, na lista abaixo, as características mais importantes que um SGBD precisa ter:
• Controle de redundância de dados.
• Representatividade de associações complexas.
• Disponibilidade de dados.
• Várias interfaces.
• Controle de acesso aos dados.
• Recuperação de falhas.
• Restrições de integridade.
Agora, responda: você sabe para que servem os bancos de dados? Veja, na lista abaixo, 
alguns exemplos de dados que podem ser geridos pelos SGBDs:
• Listas de discussão.
• Informação financeira.
• Informação contábil.
• Dados oriundos de pesquisas científicas.
• Informações sobre clientes.
• Registros de pessoas.
• Informações acadêmicas.
Vantagens
E quais são as vantagens de um SGBD? Confira, a seguir:
• Maior segurança: permite que múltiplos usuários acessem os mesmos dados 
de forma isolada ou simultânea. Essa característica é, geralmente, vista como um 
benefício para o sistema.
• Maior disponibilidade: uma das grandes vantagens existentes em um SGBD é 
que a mesma informação encontrada na base de dados pode ser liberada para 
utilizadores diferentes, ou seja: compartilhamento de informações.
• Redundância minimizada: os dados existentes em um SGBD são mais concisos, 
pois, como regra, a informação aparece apenas uma única vez. Isso faz com que 
haja diminuição da redundância de dados. Como consequência, haverá redução 
significativa do custo de armazenamento de informações em discos rígidos e 
outros dispositivos de armazenamento.
30
• Programa e arquivo de consistência: com o uso de um SGBD, os formatos das 
tabelas e os programas do sistema obedecem a um padrão. Isso permite que as 
tabelas de dados sejam mais fáceis de serem mantidas, pois as mesmas diretrizes 
e regras se aplicam a todos os tipos de dados. O nível de consistência entre as 
tabelas e os programas também torna mais fácil o gerenciamento de dados quando 
vários programadores estão envolvidos no desenvolvimento de uma aplicação.
• Precisão: dados consistentes são um bom sinal de que há integridade dos dados. 
Os SGBDs caracterizam a integridade dos dados, uma vez que as atualizações e 
alterações dos dados só precisam ser realizadas em um só lugar.
Finalidades 
Você consegue listar as finalidades de um SGBD? Faça sua lista mental e, depois, confira 
com as finalidades detalhadas a seguir: 
Segurança da informação
Talvez essa seja a principal funcionalidade de um SGBD. 
É importante que os sistemas de gerenciamento de bancos de dados possuam 
regras para restringir e garantir o acesso somente de pessoas autorizadas ao 
banco de dados. Além disso, é preciso definir qual o nível de acesso que cada 
usuário irá possuir: escrita; alteração; leitura; exclusão. 
Outros pontos importantes que estão no contexto da segurança são a cópia e 
a recuperação de dados em caso de falhas, permitindo que informações sejam 
recuperadas a partir de outro local qualquer.
Controle de redundância de dados
Imagine um sistema sendo executado em diversos computadores. Esse siste-
ma certamente possui os dados armazenados em um único local (o servidor). 
O controle de redundâncias irá organizar o fluxo de acesso à base de dados no 
servidor, para que os dados inconsistentes não sejam armazenados, a fim de 
que uma série de regras sejam criadas visando a que os dados sejam armaze-
nados corretamente e não aconteça duplicação de dados e/ou dados inválidos.
31
Integridade de dados
Esse é um item que pode ser considerado como parte da segurança. O controle 
da integridade de dados deve impedir que aplicações ou acessos que possam 
comprometer a integridade dos dados sejam feitos. Sendo assim, o acesso 
ao sistema será permitido somente a pessoas autorizadas e, ainda, de acordo 
com os níveis de acesso.
Compartilhamento de dados
Todo SGBD deve possuir um controle de concorrência de dados para garantir 
a leitura e a escrita dos dados sem erros. É comum que os dados estejam 
sendo disponibilizados a mais de um usuário, e não pode haver prejuízos para 
nenhum deles.
Acesso
O controle de acesso é tido como um fator bem importante, pois colabora com 
a integridade dos dados. Como isso acontece? Com o SGBD é possível configu-
rar níveis de autoridade para cada usuário. Alguns usuários poderão ter acesso 
total às informações, enquanto outros poderão ter acesso a apenas algumas 
das funcionalidades previstas, como, por exemplo: leitura, escrita e atualização.
Interfaceamento
Permite uma forma de acesso gráfico ao ambiente, desenvolvido em lingua-
gem natural, menus de acesso e em SQL. Dessa forma, o banco de dados pode 
ser acessado diretamente, não tendo a necessidade de passar pela aplicação 
que utiliza.
Esquematização
Em um banco de dados a ser trabalhado, as tabelas se relacionam entre si, e, 
dessa forma, um SGDB deve fornecer meios para que haja compreensão des-
ses relacionamentos. 
32
Backups
As cópias de segurança são imprescindíveis para a segurança de qualquer infor-
mação em uma empresa, pois hoje a informação é o coração da empresa e, em 
um SGBD, isso é mais evidenciado. É fato que estamos sujeitos a falhas, tanto no 
componente de hardware como no desenvolvimento do software, e, por intermé-
dio de mecanismos previamente estabelecidos e ajustados, é possível recuperar 
as informações, minimizando as perdas.
Quem gerencia o SGBD?
Para realizar o gerenciamento do SGBD entra a figura do administrador, que pode ser de 
dois tipos:
Administrador de banco de dados (database administrator – DBA)
É a pessoa que fornece o suporte técnico necessário para implementação de decisões, como:
• Definir o esquema conceitual.
• Definir o esquema interno.
• Ligação com o usuário.
• Definir restrições de segurança e integridade.
• Definir normas de descarga e recarga.
Administrador de dados (data administrator – DA)
Toma as decisões estratégicas e de normas com relação aos dados da empresa, a saber:
• Que dados devem ser armazenados.
• Tratamento desses dados.
MIDIATECA
Acesse a midiateca da Unidade 1 e veja o conteúdo complementar indicado pelo 
professor sobre a importância de um SGBD, suas características e suas vantagens.
33
NA PRÁTICA
A questão da dificuldade no acesso aos dados é uma questão bem interessante 
e preocupante.
Temos o caso do banco Cicle S.A., que ainda não modernizou sua estrutura de 
dados e trabalha com o modelo de arquivos que armazenam as informações. 
O diretor de marketing do banco necessita encontrar os nomes de todos os 
clientes que vivem em uma rua da cidade com CEP 78733-001 para que seja 
ofertada uma campanha de empréstimo pessoal a esses correntistas. O diretor, 
então, solicita ao departamento de processamento de dados (TI da empresa) 
que gere tal relação. O problema é que, caso esse tipo de solicitação não tenha 
sido antecipado quando o sistema original foi projetado, não haverá nenhum 
programa/aplicativo disponível para fazê-lo. O máximo que a equipe de TI 
consegue é gerar uma lista de todos os clientes do banco, e o respectivo diretor 
terá agora duas saídas: ou ele pega a lista de clientes e extrai a informação 
necessária manualmente, ou pede ao departamento de processamento de 
dados para que um programador escreva o programa aplicativo necessário 
(o que demandará bastante tempo). Ambas as alternativas são obviamente 
insatisfatórias, mas, devido à falta de investimento em um bom banco de 
dados, isso é o que terá de ser feito.
34
Resumo da Unidade 1
Nesta unidade, você estudou toda a importância de se trabalhar com o SGBD.
Os bancos de dados são conjuntos de arquivos quefalam entre si, proporcionando o 
armazenamento de uma grande quantidade de dados: nomes, telefones, documentos, 
pagamentos, endereços, clientes, serviços etc. Daí sua importância. Os bancos de dados 
precisam ser configurados e administrados por meio das linguagens de programação, 
como, por exemplo: JavaScript; SQL; PL/SQL, entre outros.
Os modelos de banco de dados também são muito importantes, pois, de acordo com 
suas variações, permitirão que os desenvolvedores escolham um padrão que se adapte 
mais à realidade da empresa e do negócio que serão atendidos.
Por último, temos o entendimento de que os SGBDs são constituídos por um conjunto de 
programas para acesso aos dados. O principal objetivo de um SGBD é proporcionar um 
ambiente tanto conveniente como eficiente para a recuperação e o armazenamento das 
informações no banco de dados.
Nesta unidade, destacaram-se os conceitos fundamentais do que é um banco 
de dados e qual a sua importância, os diversos modelos de banco de dados 
existentes e as suas atuações frente ao mercado de trabalho. Por último, mos-
trou-se a necessidade e a importância de se ter um SGBD para poder admi-
nistrar o acesso, com segurança, a uma base de dados disponibilizada pela 
empresa para seus clientes.
CONCEITO
35
Referências 
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. São Paulo: Pearson, 2005. 
Biblioteca Virtual.
VICCI, C. Banco de Dados. São Paulo: Pearson, 2015. Biblioteca Virtual.
Modelo de Dados
UNIDADE 2
37
Nesta unidade, você vai estudar o conceito e a importância do SGBD dentro da pers-
pectiva teórica dos diversos usos desse sistema na empresa, bem como as respectivas 
aplicações e importâncias de seus princípios no gerenciamento da informação para a 
melhoria e segurança do negócio.
INTRODUÇÃO
OBJETIVO
Nesta unidade, você será capaz de:
• Desenvolver um modelo de dados a partir de um problema que represente 
uma situação real de desenvolvimento de sistemas.
38
UML 
Introdução
Sabe-se que uma imagem pode representar muito mais do que muitas palavras. Por 
isso, a diagramação em linguagem de modelagem unificada – UML foi desenvolvida. 
Esse tipo de diagramação tem o objetivo de estabelecer relação e/ou uma linguagem 
visual comum no ambiente de desenvolvimento de softwares. Além disso, ela também 
poderia ser interpretada por todos os usuários do mundo dos negócios e/ou qualquer 
outra pessoa que queira entender mais sobre a aplicação desenvolvida.
A UML foi desenvolvida para criar uma relação da linguagem de modelagem visual 
comum, semanticamente, para a arquitetura, design e implementação dos softwares 
mais complexos, tanto de forma estrutural como em termos de comportamentos. 
Ela não é uma linguagem desenvolvida para a programação de aplicativos. Existem 
outras ferramentas que podem e devem ser usadas para gerar códigos de programas em 
várias linguagens por meio de diagramas UML. É sabido que a linguagem de modelagem 
unificada tem um elo direto com a análise para o desenvolvimento do software e com o 
design da orientação a objetos.
Existem diversos modelos para a resolução de problemas na informática, que é o estudo de 
algoritmos e de dados. Diante disso, temos quatro modelos para a resolução de problemas: 
1. Linguagens funcionais.
2. Linguagens declarativas. 
3. Linguagens imperativas. 
4. Linguagens orientadas a objetos. 
Nas linguagens orientadas a objetos, temos os algoritmos (sequência lógica e estruturada 
de ações) determinados com a definição de objetos (representarão, no futuro, a tabela 
no banco de dados), e por meio da ligação dos objetos entre si. Esses objetos serão 
manuseados, e eles fazem parte do nosso mundo.
As linguagens orientadas a objetos estão cada vez mais dominando o universo da 
programação, pois elas têm o poder de modelar os objetos pertencentes ao nosso 
mundo real. 
39
A UML é uma interseção de várias notações orientadas a objetos, que são:
• Técnica de modelagem de objetos.
• Design orientado a objetos.
• Engenharia de software orientada a objetos.
A UML usa todos os pontos fortes das abordagens citadas acima para caracterizar 
uma metodologia mais robusta e de fácil utilização. Ela visa a representar as melhores 
práticas para o desenvolvimento e para a documentação de aspectos diferenciados da 
modelagem de um software e dos sistemas corporativos.
Um ponto importante a ser observado nesse processo é que há um balizador para que a 
UML possa caminhar de forma sólida e respeitosa, ou seja, temos a Object Management 
Group – OMG, que supervisiona e controla a definição e a manutenção das especificações 
da UML. Todo esse controle é deveras importante, pois permite que os engenheiros e 
programadores utilizem uma única linguagem para muitas finalidades durante todas as 
fases do ciclo de vida do software.
Saiba mais
A UML em funcionamento com as bases da OMG visa:
• Fornecer aos desenvolvedores de sistemas, engenheiros de software 
e arquitetos de software as devidas ferramentas de análise e design do 
software e a implementação para sistemas baseados em software, bem 
como a oferta de recursos para a criteriosa modelagem dos processos de 
negócios que o software possa demandar.
• Desenvolver os caminhos e as condições necessárias da indústria ao permitir 
a união de ferramentas de modelagem visual de objetos existentes nesse 
contexto. Diante disso, para que haja a troca fundamental de informações 
dos modelos a serem utilizados entre as ferramentas, é importante que 
haja um acordo sobre o uso da semântica e da notação.
Requisitos
A UML visa atender aos seguintes requisitos:
• Estabelecer uma definição formal de um metamodelo – MOF, baseado em metaob-
jetos que são comuns e que especificam uma sintaxe abstrata da UML. A sintaxe 
40
abstrata estabelece um conjunto de conceitos da modelagem UML. Isso porque 
os seus devidos atributos e respectivos relacionamentos, bem como as regras que 
foram definidas para unir esses conceitos para a construção de modelos UML par-
ciais ou completos, tratam da relação entre os objetos.
• Oferecer uma explicação minuciosa da semântica de cada conceito aplicado na 
modelagem UML. A semântica tende a definir, de forma independente, como os 
conceitos aplicados na UML devem ser tratados pelos computadores.
• Determinar os elementos de notações legíveis, utilizados pelos seres humanos, 
com o intuito de representar os reais conceitos da modelagem UML individual. Da 
mesma forma, determinar as regras para combiná-los em uma determinada varie-
dade de tipos de diagramas, correspondentes a diferentes aspectos utilizados dos 
sistemas modelados.
• Estipular algumas maneiras para que as ferramentas UML possam entrar em con-
formidade com essa especificação. Tudo isso é suportado por uma outra especifi-
cação baseada em XML, cujos formatos de modelos e de intercâmbio correspon-
dentes devem ser realizados por ferramentas que sejam compatíveis.
Modelagem por meio da UML
O desenvolvimento dos sistemas está concentrado em três modelos gerais e diferentes. 
Conheça-os a seguir:
Diagrama de 
caso de uso, 
que descreve 
de que forma a 
funcionalidade do 
sistema irá partir 
sobre a visão do 
usuário.
Diagrama de 
classes, que 
descreve como 
a estrutura do 
sistema ficará 
no que tange 
aos objetos, aos 
atributos, às 
associações e 
às respectivas 
operações.
Temos o uso de 
três diagramas: 
diagramas de 
máquinas de 
estados, diagramas 
de interação e 
diagramas de 
atividade, que 
servem para 
descrever o 
comportamento 
interno do sistema.
FU
N
C
IO
N
A
L
O
B
JE
TO
D
IN
Â
M
IC
O
41
Esses três modelos de sistemas são visualizados a partir de dois tipos diferentes de 
diagramas: o diagrama estrutural e o diagrama comportamental. Você vai conhecer 
cada um desses tipos mais adiante.
Orientação a objetos na UML
Os objetos na UML são tidos como entidades do mundo real. No desenvolvimento de um 
determinado software, os objetos podem ser utilizados para descrever ou para modelar 
o sistema que estáem desenvolvimento. Os objetos também devem permitir que, no 
processo de decomposição de sistemas complexos em componentes compreensíveis, 
haja uma peça de cada vez que pode ser criada.
Existem alguns conceitos importantes referentes à orientação a objetos. Vamos conhe-
cê-los?
Objeto: é a representação de uma entidade e um componente básico essencial.
Abstração: é o devido comportamento de uma entidade.
Herança: é o mecanismo para criar novas classes a partir de uma já existente.
Classe: é o modelo de um objeto.
Encapsulamento: é o mecanismo para unir os dados e escondê-los do mundo exterior.
Polimorfismo: define o mecanismo de utilização em diferentes formatos.
Tipos definidos de diagramas UML
A linguagem de modelagem unificada utiliza elementos e os associa de diversas maneiras, 
com o objetivo de formar diagramas que tenham representatividade e aspectos estáticos 
ou estruturais de um sistema. Com isso formam diagramas comportamentais, que 
fazem o registro dos aspectos dinâmicos do sistema. Já os diagramas estruturais 
referem-se aos aspectos estáticos do sistema. 
Como visto anteriormente, os diagramas podem ser do tipo estrutural ou 
do tipo comportamental. Na sequência, entenda melhor cada tipo.
42
Diagrama Comportamental: é aquele em que há a necessidade de alguma alteração de 
comportamento das classes mapeadas.
Diagrama Estrutural: é utilizado nos casos em que há a necessidade para visualizar, 
especificar, construir e documentar os aspectos estáticos existentes em um sistema.
Os diagramas UML do tipo comportamental são:
DIAGRAMAS 
DE 
SEQUÊNCIA
Demonstram como os objetos interagem entre si e, da mesma forma, 
demonstram a ordem de ocorrência. Fazem a representatividade 
das interações para um cenário específico.
Conheça um exemplo:
43
DIAGRAMAS 
DE CASO DE 
USO
DIAGRAMAS 
DE 
ATIVIDADE
Representam uma funcionalidade específica de um determinado 
sistema. Foram elaborados para demonstrar a forma como as 
funcionalidades se relacionam e os respectivos controladores 
internos e externos (denominados de atores).
Observe o exemplo:
São os fluxos de trabalho de negócios ou operacionais, 
representados de forma gráfica, para a exibição de uma atividade 
de qualquer parte ou componente de um respectivo sistema.
Veja um exemplo:
44
DIAGRAMAS 
DA VISÃO 
GERAL DA 
INTERAÇÃO
DIAGRAMAS 
DE MÁQUINA 
DE ESTADOS
DIAGRAMAS 
DE TEMPO
DIAGRAMAS 
DE CLASSES
DIAGRAMAS 
DA 
COMUNICAÇÃO
Nesses diagramas, cujo objetivo é exibir uma sequência em que 
eles próprios atuam, temos determinados sete outros tipos de 
diagramas de interação.
Há uma semelhança com os diagramas de atividade, pois 
descrevem como o comportamento dos objetos irá ocorrer, mas 
de maneira diferente em seu estado atual.
Assim como o diagrama de sequência, esse diagrama representa 
o comportamento de objetos em um período de tempo específico. 
Havendo um único objeto, o diagrama é bem simples. Havendo 
mais de um objeto, as interações entre eles são exibidas durante o 
período de tempo determinado.
São os mais usados por serem considerados a principal base de 
qualquer solução orientada a objetos. Esses diagramas definem 
as classes dentro de um sistema, os atributos, as operações e a 
relação entre cada classe. As classes são agrupadas para criar 
diagramas de classes quando há uma diagramação de grandes 
sistemas.
Veja um exemplo do diagrama de classes:
São similares aos diagramas de sequência, mas focam as 
mensagens transmitidas entre os objetos utilizados. A mesma 
informação tratada pode ser representada no seu todo usando um 
diagrama de sequência e outros objetos em questão.
Os diagramas UML do tipo estrutural podem ser divididos em:
45
DIAGRAMAS
 DE 
COMPONENTES
Mostram a relação estrutural de elementos do sistema de software. 
Na maioria das vezes, são utilizados quando se trabalha com 
sistemas complexos com múltiplos componentes. Os componentes 
têm a sua comunicação por meio de interfaces.
Observe um exemplo:
DIAGRAMAS 
DE 
ESTRUTURA 
COMPOSTA
São utilizados para demonstrar a estrutura interna de uma classe 
utilizada no diagrama.
DIAGRAMAS
 DE 
IMPLEMENTAÇÃO
Exibem o hardware utilizado no sistema e o seu respectivo software. 
São importantes quando uma determinada solução de software é 
implantada em diversos computadores com configurações únicas.
Veja um exemplo:
46
DIAGRAMAS 
DE 
OBJETOS
DIAGRAMAS 
DE 
PACOTES
Demonstram a relação existente entre os objetos, usando 
exemplos do mundo real, e retratam um sistema em um momento 
específico. É sabido que os dados estão disponibilizados dentro 
dos objetos, e eles podem ser usados para esclarecer as relações 
existentes entre objetos.
Nesse cenário, existem dois tipos especiais de dependências 
definidas entre os respectivos pacotes: 
• A importação do pacote. 
• A mesclagem do pacote. 
Para que haja o apontamento da arquitetura utilizada, os pacotes 
irão representar os diferentes níveis de um sistema. As respectivas 
dependências de pacotes podem ser marcadas para demonstrar 
o real mecanismo de comunicação entre os respectivos níveis.
MIDIATECA
Acesse a midiateca da Unidade 2 e veja o conteúdo complementar indicado 
pelo professor sobre UML.
47
Levantamento de requisitos 
Introdução
Dentro do cenário do desenvolvimento de um excelente banco de dados é fundamental 
que o levantamento de requisitos seja muito bem executado pelo analista 
responsável pelo projeto, pois por meio dele toda a modelagem UML será executada. 
Importante
O levantamento de requisitos e/ou informações com um ou mais usuários 
permitirá que o analista responsável tenha uma visão clara e objetiva do 
negócio proposto. 
Sabe-se que o início do desenvolvimento de um novo software para uma 
empresa é marcado pelo levantamento de requisitos. Essa atividade deve ser 
repetida de forma constante, e realizada até por outros analistas responsáveis, 
nas demais etapas da engenharia de requisitos.
É importante que o processo de levantamento e análise de requisitos contenha as 
seguintes atividades:
Compreensão do domínio: os analistas de sistemas devem desenvolver sua 
compreensão do domínio com relação à aplicação a ser desenvolvida.
Coleta de requisitos: é o processo de interagir com os parceiros do sistema para 
determinar seus requisitos. O entendimento do domínio desenvolve-se fortemente 
durante essa atividade.
Classificação: a atividade executada leva em consideração o conjunto não estruturado 
dos requisitos e os organiza em respectivos grupos com a devida coerência.
48
Resolução de conflitos: quando há vários parceiros envolvidos, os requisitos deverão 
apresentar conflitos. Essa atividade visa à solução desses conflitos.
Definição das prioridades: nos conjuntos de requisitos teremos alguns mais importan-
tes do que outros. Nesse momento há envolvimento e interação com os parceiros para 
a definição dos requisitos mais importantes.
Verificação de requisitos: os requisitos serão checados para descobrir se estão consis-
tentes e se estarão em consonância com o que os parceiros desejam para o sistema.
O levantamento e análise de requisitos é um processo interativo, com uma contínua 
validação de uma atividade para outra.
REQUISITOS
Fonte Status
Grupo de importânciaPonto de vista
Tipo
Agora que você já sabe a importância da etapa de levantamento de requisitos para a 
construção de um sistema, conheça as dificuldades que podem ser encontradas ao 
longo desse processo.
Dificuldades encontradas no processo de levantamento de 
requisitos
Não saber especificar, claramente, o que o sistema deverá fazer e/ou produzir é uma 
questão que acontece de longa data. Na maior parte das vezes os usuários são temerosos
49
com esse processo, pois acreditam que, com a chegada do novo sistema, o seu cargo 
estará ameaçado. Isso faz com que, muitas vezes, os usuários omitam informações 
importantes. Além disso, é fato que também nossos analistas de sistemas podem pecar 
em alguns processos. 
Entre as razões para o baixo graude satisfação dos usuários com relação aos sistemas, 
destacam-se:
• A fase de levantamento de requisitos, quando não é usada uma técnica adequada 
para extrair os requisitos do sistema.
• Falha do analista de sistema em não descrever os requisitos do sistema de modo 
claro e efetivo, sem uma atuação ambígua, de forma concisa e coerente com todos 
os aspectos significativos para o sistema proposto.
Dentre as mais variadas dificuldades encontradas na fase de levantamento de requisitos 
temos: 
• O usuário responsável pelo sistema não sabe o que deseja e quer que ele faça e não 
consegue passar adiante as informações pertinentes para o analista de sistemas.
• Requisitos que são identificados, mas não são realistas nem identificam os 
requisitos similares informados por pessoas diferentes.
• Um parceiro equivocado no processo fará com que haja perda de tempo e de 
dinheiro para ambas as partes envolvidas no desenvolvimento do sistema.
Podemos verificar que o levantamento de requisitos deve ser adequado e coerente, feito a 
partir de uma ótima definição do projeto, visando à aquisição de informações pertinentes 
e necessárias para o diagnóstico das necessidades do sistema e à proposição de 
soluções inteligentes.
Quando o levantamento de requisitos é inadequado, o resultado será um diagnóstico 
ruim, com conclusões comprometedoras, não caracterização das causas dos problemas, 
custos altamente elevados, prazos vencidos e/ou comprometedores, além da omissão 
dos processos fundamentais.
Técnicas importantes para o levantamento de requisitos
As técnicas utilizadas para o levantamento de requisitos têm por objetivo superar as 
grandes dificuldades relativas a essa fase tão importante. Todas as técnicas possuem
50
um conceito definido, que caracteriza suas respectivas vantagens e desvantagens, e 
podem ser utilizadas em conjunto com outras técnicas pelo analista de sistemas.
Na sequência, conheça oito técnicas que podem ser utilizadas no levantamento de requisitos.
1. Prototipagem
Essa técnica tem como objetivo fazer análises dos aspectos críticos dos requisitos 
de um determinado produto, implementando, de forma rápida e objetiva, um pequeno 
subconjunto de funcionalidades do produto que está sendo tratado. 
O protótipo tem como indicação básica:
• Estudo de alternativas de interface para o bem-estar do usuário. 
• Problemas de comunicação com os demais produtos.
• Viabilidade para o atendimento dos requisitos de desempenho. 
As técnicas utilizadas na elaboração do protótipo são várias. Dentre elas, podemos citar: 
• Interface de usuário.
• Relatórios gráficos.
• Relatórios textuais.
2. Levantamento orientado a pontos de vista
No desenvolvimento de sistemas, seja no âmbito de médio ou de grande porte, na maior 
parte das vezes, há diferentes tipos de usuários finais. Muitos usuários que fazem uso 
de um ou de outro processo têm algum tipo de interesse nos requisitos do sistema a 
ser desenvolvido. Dessa forma, mesmo para um sistema mais simples, existem muitos 
pontos importantes que diferem dos que devem ser considerados. 
Os vários pontos de vista a respeito de um determinado problema podem ser enxergados 
de diversas formas. Diante disso, as suas perspectivas não serão independentes, mas, 
de um modo geral, podem apresentar alguma duplicidade, de forma que teremos 
requisitos comuns.
51
O método VORD (viewpoint-oriented requirements definition, ou “definição dos requisitos 
orientados para o ponto de vista”) teve na sua essência de concepção a estruturação 
como um framework orientado a serviço para o levantamento e análise de requisitos.
Ele é definido em quatro etapas, detalhadas a seguir:
• Primeira etapa: sua conexão é com o ponto de vista que tem como objetivo 
identificar os possíveis pontos importantes a serem observados. Nesse momento, 
os analistas de sistemas responsáveis pelo projeto se reúnem com os respectivos 
parceiros e utilizam a tradicional abordagem de brainstorming para elencar os 
devidos serviços em potencial e as entidades que interagem com o sistema em 
desenvolvimento.
• Segunda etapa: é a estruturação de pontos de vista, com o objetivo de envolver e de 
agrupar os pontos de vista relacionados, de acordo com uma hierarquia. Serviços 
comuns estão localizados nos níveis mais altos da hierarquia e são herdados por 
pontos de vista existentes no nível inferior.
• Etapa de documentação: tem como objetivo aprimorar a descrição dos pontos de 
vista e dos serviços identificados pelos analistas.
• Mapeamento de sistema: conforme o ponto de vista, há um envolvimento e uma 
identificação de objetos em um projeto orientado a objetos, que se utilizam das 
informações e dos serviços que estão encapsulados nos pontos de vista.
A seguir, veja, graficamente, a estruturação das etapas:
Identificação de 
ponto de vista
Documentação de 
ponto de vista
Estruturação de 
ponto de vista
Mapeamento de 
sistema de ponto de 
vista
3. Etnografia
Essa técnica visa ao desenvolvimento de um olhar atento para o entendimento dos 
requisitos, ou seja, tem como objetivo ajudar o analista a compreender como se dá a 
política organizacional, bem como a cultura dos trabalhos realizados para que ele se 
familiarize com o sistema e sua história.
Na prática, o analista de sistemas insere-se no ambiente dinâmico de trabalho em que o 
sistema será usado. O trabalho realizado diariamente é observado e as tarefas reais são
52
anotadas para identificar o ponto de atuação do sistema. O principal objetivo é ajudar a 
descobrir requisitos que estejam implícitos no sistema, que possam refletir os processos 
reais, no lugar dos processos formais, em que algumas pessoas estão envolvidas.
A etnografia é eficaz na descoberta de dois tipos de requisitos:
• Aqueles oriundos da forma como as pessoas realmente trabalham, em vez da 
forma pelas quais as definições de processo dizem como elas deveriam trabalhar.
• Os oriundos da conscientização das atividades de outras pessoas.
4. Questionários
O uso de questionário é sempre recomendado, sobretudo quando há vários grupos de 
usuários que podem estar em locais diferentes do país.
Dessa forma, elaboram-se pesquisas extremamente específicas de acompanhamento, 
com usuários selecionados no processo, cuja contribuição em potencial pareça mais 
importante. Essa seleção prévia tem como objetivo evitar um grande número de entrevistas, 
pois não seria nada prático ter que entrevistar todas as pessoas em todos os locais.
Existem diversos tipos de questionários que podem ser utilizados no processo. Entre 
eles podemos elencar: múltipla escolha, lista de verificação e questões com espaços em 
branco. O questionário deve sempre ser desenvolvido de maneira a minimizar o tempo 
gasto em sua resposta.
5. Workshops
Trata-se de uma técnica aplicada para um grupo em uma reunião estruturada. Os 
analistas de sistemas devem estar envolvidos e deve ser feita uma seleção dos parceiros 
que melhor representam a organização e o contexto em que o sistema será utilizado, 
angariando assim um conjunto de requisitos bem estruturados.
O workshop tem por objetivo o acionamento do trabalho em grupo. Nele, existe a figura 
do facilitador, cujo papel é conduzir a técnica aplicada e promover a discussão entre 
os diversos grupos. As tomadas de decisão feitas durante o evento são baseadas em 
processos extremamente definidos e com o real objetivo de obter um processo de 
negociação, mediado pelo facilitador.
53
Uma técnica bastante usada em workshops é o brainstorming, que será detalhado mais 
adiante. 
Após a realização dos workshops, serão produzidas documentações que reflitam os 
requisitos e as decisões tomadas sobre o sistema a ser desenvolvido.
Aspectos importantes que precisam ser levados em conta: 
• A postura que o facilitador deve adotar é de ser mediador e observador. 
• A convocação a ser realizada deve conter: dia, hora, local, horário de início e término, 
o assunto que será abordado e a documentação a ser tratada.
6. JAD
Técnica que visaa promover cooperação, entendimento, integração e trabalho em equipe 
entre os diversos usuários desenvolvedores do sistema.
O uso dessa técnica visa a facilitar a criação de uma visão que será compartilhada por 
todos com base no que o produto de software deve ser. Com isso, os desenvolvedores 
de sistemas ajudam os demais usuários na formulação de problemas e na exploração de 
soluções. Dessa forma, todos os usuários ganharão um determinado sentimento de pura 
sinergia e envolvimento, além do desenvolvimento do sentimento de responsabilidade 
com o sucesso do produto a ser desenvolvido.
Princípios básicos da técnica:
• Dinâmica de grupo.
• Uso de técnicas visuais.
• Manutenção do processo organizado e racional.
• Utilização de documentação padrão.
7. Entrevistas
Técnica bem tradicional e muito simples de ser utilizada. As entrevistas produzem bons 
resultados na fase inicial de obtenção de informações. 
É importante que o entrevistador permita ao entrevistado expor suas ideias. Para tanto, 
é necessário ter um bom plano de entrevista, que evite a dispersão do assunto principal
54
e impeça que ela se alongue além do necessário, fazendo com que o entrevistado fique 
exausto e não produza bons resultados.
Para elaborar perguntas detalhadas, o entrevistador deve:
• Explicar a relação entre o que se quer discutir e as demais partes do sistema.
• Descrever o ponto de vista dos demais usuários com base no ponto em discussão.
• Descrever as informações que o analista de sistemas deseja obter.
• Verificar, com o usuário, se o ponto em questão está ligado a outro item. Dessa forma, 
poderá ser juntado com os requisitos comuns do sistema em desenvolvimento, 
permitindo que haja um escopo conciso.
8. Brainstorming
Técnica desenvolvida para geração de ideias. Essa técnica consiste em uma sequência 
de reuniões que permitirão que as pessoas envolvidas possam sugerir e explorar diver-
sas ideias. 
As principais etapas de condução de uma brainstorming são:
• Seleção minuciosa dos seus participantes.
• Explicação da técnica a ser utilizada, bem como as regras a serem adotadas.
• Produção de muitas ideias.
MIDIATECA
Acesse a midiateca da Unidade 2 e veja o conteúdo complementar indicado 
pelo professor sobre modelagem de dados tutorial.
55
Modelagem de dados 
A seguir serão apresentados alguns conceitos importantes para o entendimento da 
modelagem de dados. 
Instâncias
São definidas como um conjunto de informações quaisquer que estão armazenadas em 
um determinado banco de dados.
Independência de dados
É a capacidade de transformar a definição dos esquemas desenvolvidos em um 
determinado nível, sem afetar o esquema do nível superior. Pode ser classificada em 
dois tipos:
Independência física: capacidade de 
modificar o esquema físico projetado 
sem que, com isso, qualquer 
programa de aplicação precise ser 
refeito. As modificações exercidas 
no nível físico são importantes, 
principalmente para melhorar o 
desempenho da aplicação.
Independência lógica: capacidade de 
transformar o esquema lógico sem 
que, com isso, qualquer programa 
de aplicação precise ser refeito. 
As modificações no nível lógico 
são importantes sempre que uma 
estrutura lógica do banco de dados é 
alterada para a melhoria da aplicação.
É sabido que a independência lógica de dados é mais difícil de ser mensurada do que a 
independência física, pois os programas de aplicação são mais fortemente dependentes 
da estrutura lógica dos dados do que particularmente o seu acesso.
Os três níveis da arquitetura
A arquitetura ANSI/SPARC se divide em três níveis, conhecidos como nível interno, nível 
conceitual e nível externo. Os níveis foram definidos na Unidade 1, abaixo você pode ver 
como eles se relacionam graficamente:
56
Nível externo
Nível conceitual
Nível físico
Agora que você já está a par dos principais conceitos, vamos avançar no estudo da 
modelagem dos dados.
Modelagem de dados
A modelagem de dados é definida como uma técnica utilizada para a especificação das 
regras de negócio e as estruturas de dados que um banco de dados precisa ter para 
ser definido e/ou criado. Essa técnica está em sintonia com o ciclo de desenvolvimento 
de um sistema de informação para uma empresa e é de suma importância para o bom 
resultado de um projeto. 
Modelar os dados consiste em conceber/desenhar o sistema de informações a ser utilizado, 
concentrando-se nas entidades e nas dependências lógicas entre essas entidades.
A modelagem de dados pode ser conceituada, ainda, como uma técnica que envolve um 
conjunto de aplicações teóricas e práticas, com o objetivo de construir um modelo de 
dados consistente, robusto, não redundante e aplicável em qualquer SGBD.
Para que esse objetivo seja atingido, devemos considerar a definição de um conjunto 
de conceitos para a representação de dados. Como exemplos, podemos citar: entidade, 
tabela, atributo etc.
Modelos de representação de dados
Existem modelos para diferentes níveis de abstração de representação de dados:
A. Modelos conceituais.
B. Modelos lógicos.
C. Modelos físicos.
57
Os modelos físicos têm como características:
• Organização dos arquivos de dados em disco rígido (organização sequencial, uso 
de índices hashing ou b-trees). 
• Os dados não são manipulados por intermédio de usuários ou de aplicações que 
acessam o banco de dados, mas diretamente pelas ferramentas do próprio banco 
de dados.
• A caracterização sobre a importância e as decisões de implementação de cada 
SGBD para a gestão do banco de dados.
Na sequência, conheça, detalhadamente, os modelos de representação de dados e suas 
particularidades.
A. Modelo conceitual
O modelo conceitual está caracterizado pelo mais alto nível, e é importante que seja 
usado para envolver o cliente, pois o foco fundamental é tratar dos aspectos do negócio 
do cliente, e não da tecnologia em si. 
Os diversos exemplos de modelagem de dados tratados pelo modelo conceitual são 
fáceis de compreender, já que não existem limitações ou aplicação de uma tecnologia 
específica. O diagrama de dados que deverá ser construído pelo analista responsável é 
tido como o diagrama de entidade e relacionamento – DER. É importante que nesses 
diagramas sejam identificados, diante da necessidade do cliente, todas as entidades e 
os relacionamentos entre elas. Esse diagrama é a mola mestra para a compreensão do 
modelo conceitual de dados.
Algumas características importantes do modelo conceitual são:
• Modelam de forma mais natural os fatos do mundo real, suas propriedades e seus 
relacionamentos.
• São independentes do banco de dados.
• Possuem preocupação com a semântica da aplicação.
58
Exemplo
Exemplo
Observe um exemplo de modelagem conceitual:
Observe um exemplo de modelagem lógica de dados:
Alunos AlunosCursam
B. Modelo lógico
O modelo lógico leva em consideração algumas limitações no mapeamento das 
necessidades do cliente e implementa recursos como adequação de padrão e 
nomenclatura, definição das chaves primárias e estrangeiras, normalização, integridade 
referencial, entre outras. 
É importante que o modelo lógico seja criado levando em consideração a modelagem de 
dados criada no modelo conceitual.
Conheça, a seguir, algumas características importantes do modelo lógico:
• Também são chamados de modelo de banco de dados.
• São dependentes do banco de dados.
Podemos citar como exemplos de utilizações:
• O modelo relacional (tabelas). 
• O modelo hierárquico e XML (árvore).
• O modelo orientado a objetos (classes - objetos - complexos).
59
Percebe-se a ligação das tabelas Alunos e Cursos por meio dos seus respectivos 
campos Curso e Cod_Curso.
Dessa forma, há um elo entre as tabelas: uma determinada matrícula possui 
um curso, e esse curso está referendado na tabela Cursos..
Como suporte aos métodos de acesso à base de dados, o modelo lógico possui:
• Especificação dos conceitos do modelo (DDL):
– Dados, seus domínios, relacionamentos e restrições existentes.
• Manipulação de conceitosmodelados (DML):
– Esquema (lógico) de um banco de dados.
• Resultado da especificação dos dados de um domínio de aplicação em um modelo 
de banco de dados, conforme mostrado no esquema a seguir:
Requisitos da aplicação Modelo de banco 
de dados
Esquema lógico
60
C. Modelo físico
É realizada a modelagem física do esquema criado para o novo banco de dados. Dessa 
forma, são levadas em consideração as limitações impostas pelo SGBD escolhido, 
devendo ser criado com base nas modelagens de dados produzidos no modelo lógico.
O modelo físico irá partir do modelo lógico e descreve as estruturas físicas de 
armazenamento de dados, tais como: tamanho de campos, índices, tipo de preenchimento 
desses campos etc.
Agora que você já sabe como são os modelos de representação de dados, 
conheça as gerações dos modelos de banco de dados.
Geração dos modelos de banco de dados
Pode-se dizer que os modelos de bancos de dados possuem três gerações.
Primeira geração: 
modelos pré-
relacionais. Dentre 
os modelos 
pré-relacionais 
destacam-se 
os modelos 
hierárquico e de 
rede.
Terceira geração: 
modelos pós-
relacionais. Dentre 
os modelos 
pós-relacionais, 
destacam-se 
os modelos 
orientados a 
objetos, objeto-
relacional, 
temporal, 
geográfico.
Segunda geração: 
modelo relacional.
Conheça cada geração com mais detalhe, a seguir.
61
Modelos pré-relacionais:
• Modelos com várias limitações: não há representatividade de forma 
adequada.
• Os relacionamentos dos objetos no mundo real são do tipo hierarquias 
(1-1 ou 1-N).
• Problema de performance: varredura em estruturas em grafo (rede).
• Inexistência de uma linguagem de consulta declarativa.
• As consultas exigem programação pela aplicação:
– Há manipulação de um registro por vez.
– Existência de baixa performance de acesso às informações.
Modelo relacional:
• Foi criado no ano de 1970. Seu criador foi E. Codd – IBM/Califórnia.
• Esse modelo de dados possui uma sólida base formal, baseada na teoria 
dos conjuntos.
• É um modelo simples: com estruturas tabulares e poucos conceitos.
• Utiliza linguagens declarativas para a manipulação de dados na base de 
dados:
– Uso de álgebra relacional e cálculo relacional.
– Linguagem SQL, de uso comercial.
Modelos pós-relacionais:
• Banco de dados orientado a objetos utilizado para a linguagem Python. 
• Alto grau de transparência dos processos.
• Objetos atualizados por meio das interações normais dos objetos.
• Alto desempenho para tratar as informações e uso eficiente da memória.
Saiba mais
O modelo relacional
O modelo relacional é um modelo de dados representativo ou um modelo de 
implementação, pois se trata de um modelo subjacente de um SGBD, que se baseia na 
concepção de que todos os dados estão armazenados em tabelas. Esse conceito foi 
criado por Edgar Frank Codd no ano de 1970.
62
No âmbito da gerência de bases de dados (SGBD), o modelo relacional é tido como um 
modelo de dados baseado em lógica e na teoria de conjuntos.
Esse modelo é amplamente utilizado. Por isso, você vai conhecê-lo em detalhes na 
sequência.
Características do modelo relacional
• Organização dos dados:
 – Conceitos do modelo de dados:
 > Atributo, relação, chave.
• Integridade de dados:
 – Restrições básicas para dados e relacionamentos entre as tabelas.
• Manipulação de dados:
 – Linguagens formais e SQL.
Organização do modelo relacional
• O modelo apresenta cinco conceitos:
 – Domínio.
 – Atributo.
 – Tupla.
 – Relação.
 – Chave.
Entenda cada um desses conceitos, na tabela abaixo:
63
Conceito
Domínio
Atributo
Tupla
Relação
Detalhamento
• Conjunto de valores permitidos para um dado:
 – Tipos de dados:
 > Tipo inteiro, tipo string (domínios básicos).
 > Tipo data e hora (domínios compostos).
 > [0, 120], (‘M’, ‘F’) (domínios definidos).
• Em um domínio existem operações válidas:
 – Tipo inteiro (somar, dividir, i1 maior que i2).
 – Tipo data (obter o dia, obter o mês, d1 anterior a d2).
• Definição de domínios de dados:
 – DDL (indicação de tipos de dados).
• Um conjunto de pares (atributo, valor).
• Define uma ocorrência de um fato do mundo real ou de um 
relacionamento entre fatos.
• Valor de um atributo:
 – Deve ser definido no momento da criação de uma tupla.
 – Precisa ser:
 > Compatível com o domínio OU NULL (valor inexistente 
ou indeterminado).
 > Atômico (indivisível: não estruturado e monovalorado).
• Vejamos um exemplo: 
 – Tupla de aluno: {(nome, ‘João’), (idade, 34), (matrícula, 
03167034)}.
• Composto por um cabeçalho e um corpo.
• Cabeçalho:
 – Número fixo de atributos (grau da relação).
 – Atributos não ambíguos.
• Corpo:
 – Número variável de tuplas (cardinalidade existente na 
relação).
• Definição formal:
 – Subconjunto do produto cartesiano de todos os domínios 
(D1 X D2 X... X Dn) de atributos.
• Relação é um conjunto.
• Na prática, uma relação em um banco de dados é chamada 
de tabela, e uma tabela definida no banco de dados admite 
uma coleção de tuplas.
• Um item de dado do banco de dados.
• Possui um nome e um domínio:
 – Nome: string (tipo definido para o atributo).
 – Idade: [0,100] (intervalo de valores do atributo idade).
64
Chave
• Conjunto de um ou mais atributos de uma relação.
• Tipos de chaves:
 – Chave primária (primary key – pk).
 – Atributo(s) cujo (conjunto de) valor(es) identifica 
unicamente uma tupla em uma relação.
 – Notação para a pk de uma relação R: pk(R).
• Conceitos associados:
 – Chaves candidatas e chaves alternativas.
• Veja alguns exemplos:
 – Alunos: matrícula.
 – Cidades: (nome, estado).
A seguir, conheça outro tipo de modelo: o modelo entidade-relacionamento. Na sequên-
cia serão detalhados o modelo entidade-relacionamento, os tipos de entidades, os seus 
atributos e o que é relacionamento.
Modelo entidade-relacionamento
Consiste em mapear o mundo real do sistema em um modelo gráfico que irá representar 
o modelo e o relacionamento existente entre os dados. Hoje, sabemos que várias empre-
sas usam esse modelo por meio de conceitos de UML e do diagrama de classe.
A seguir, você vai conhecer as características que envolvem o modelo entidade-relacio-
namento para que todo o seu mapeamento seja criado da forma correta e atenda à de-
manda do usuário.
Tipos de entidades
No que diz respeito a entidades, ainda podemos classificá-las de duas formas: entidade 
forte e entidade fraca.
Entidade Fraca Entidade Forte
É uma entidade dependente da 
existência de alguma outra entidade, 
no sentido que ela não pode existir se a 
outra entidade também não existir.
É uma entidade que não é dependente 
da existência de alguma outra entidade.
65
Atributos
Todo objeto, para ser uma entidade, possui propriedades que são descritas por seus 
atributos e valores. Atributos e valores, juntos, descrevem as instâncias de uma entidade.
Os atributos podem ser:
Simples ou 
compostos
Chave
Chave 
primária
Chave 
estrangeira
Chave 
secundária
Chave 
candidata
Índice
Univalorado ou 
multivalorado
O atributo simples é único, já o atributo composto pode ser 
desmembrado em vários atributos (mais de um).
Designa o conceito de item de busca, ou seja, um dado que será 
empregado nas consultas à base de dados.
É o atributo da tabela que identifica univocamente uma tupla.
É o elo entre as tabelas.
Serve para definir uma segunda chave primária.
Uma tabela pode possuir alternativas de identificador único, ou seja, 
várias colunas ou concatenações diferentes de colunas podem ter 
essa propriedade.
É o recurso físico que visa a otimizar a recuperação de uma 
informação, via método de acesso. Seu objetivo principal está 
relacionado com a performance de um sistema.
Um atributo univalorado possui um único valor. Por sua vez, um 
atributo multivalorado possui vários valores.
Relacionamentos
As entidades envolvidas em um dado relacionamento são ditas participantes desse re-
lacionamento. O número de participantes em um dado relacionamento é chamado de 
cardinalidademáxima. O relacionamento é representado pelo losango.
66
O relacionamento é igual ao conjunto de associações que podem ser feitas entre as 
entidades. Observe o relacionamento abaixo:
Um relacionamento pode ser de três tipos diferentes:
• Um para um.
• Um para muitos. 
• Muitos para muitos.
A seguir, entenda melhor o conceito de cardinalidade.
Cardinalidade de relacionamentos
Uma propriedade importante de um relacionamento é quantas ocorrências de uma 
entidade podem estar associadas a uma determinada ocorrência por meio de um 
relacionamento. Essa propriedade é chamada de cardinalidade. Há duas cardinalidades 
a considerar: máxima e mínima.
Exemplo
Para exemplificar a cardinalidade máxima, considere a cardinalidade máxima 1 
e muitos, representada pela letra N.
Esse relacionamento expressa que uma ocorrência de disciplina pode estar 
associada a muitas ocorrências de nota. Além disso, expressa que uma 
ocorrência de nota pode estar associada a uma ocorrência de disciplina.
Alunos AlunosCursam
Matricula
Nome
Cod_Disciplina
Descricao
Disciplina NotaPossui1 N
Cod_disciplina
Descrição
Cod_Disciplina
Matricula
Nota
67
Agora, vamos conhecer mais detalhadamente os tipos de relacionamentos existentes.
Relacionamento binário (1:1)
Nesse grau de relacionamento, cada elemento de uma entidade relaciona-se com um e 
somente um elemento da outra entidade.
Exemplo
João é casado com a Maria.
Em que:
• João: elemento do conjunto de valores do atributo Nome da entidade Homem.
• Maria: elemento do conjunto de valores do atributo Nome da entidade Mulher.
• Casado: ligação entre um homem e uma mulher, sendo que um homem pode 
ser casado com uma e apenas uma mulher, assim como uma mulher pode 
ser casada com um e apenas um homem.
Graficamente, esse relacionamento pode ser expresso por:
Homem MulherCasado1 1
Faz-se necessário salientar que lemos o diagrama somente em um sentido, e 
isso está incorreto dentro do conceito de relacionamentos, pois eles não são 
unidirecionais. Devemos ler nos dois sentidos. Dessa forma:
Importante
Homem MulherCasado1 1
Homem MulherCasado1 1
68
Relacionamento de um para muitos (1:N)
Esse grau de relacionamento é o mais comum no mundo. É também chamado de 
relacionamento básico entre entidades. Esse tipo de relacionamento possui características 
específicas quanto ao sentido de leitura dos fatos e quanto à sua interpretação.
Exemplo
Pedro trabalha no Departamento Pessoal.
Em que:
• Pedro: elemento do conjunto de valores do atributo Nome da entidade 
Funcionário.
• Departamento Pessoal: elemento do conjunto de valores do atributo Nome 
do departamento da entidade Departamento.
• Trabalha: ligação entre um Funcionário e um Departamento, em que um 
funcionário pode trabalhar em um e somente um departamento e um 
departamento pode ter vários funcionários.
Graficamente, esse relacionamento pode ser expresso por:
Funcionário DepartamentoLotadoN 1
Importante
Devemos ter como regra geral que um relacionamento é do tipo um para muitos 
quando um sentido de leitura dos fatos nos apresenta esse grau de um para 
muitos e o sentido oposto apresenta obrigatoriamente o grau um para um.
69
Relacionamento de muitos para muitos (N:M)
Identifica-se essa cardinalidade pelo fato de que, em ambos os sentidos de leitura, são 
encontrados graus de um para muitos. Isso caracteriza um contexto geral de muitos para 
muitos. Quando isso ocorrer será criada uma nova entidade.
Exemplo
Antônio está inscrito na disciplina Banco de Dados.
Em que:
• Antônio: elemento do conjunto de valores do atributo Nome da entidade 
Aluno.
• Banco de dados: elemento do conjunto de valores do atributo Nome da 
disciplina da entidade Disciplina.
• Inscrito: ligação existente entre um aluno e uma disciplina, em que um 
aluno pode estar matriculado em várias disciplinas e cada disciplina pode 
ter vários alunos matriculados.
Graficamente, esse relacionamento pode ser expresso por:
Aluno DisciplinaInscritoN M
Agora que você já conhece os tipos de relacionamentos, entenda o que são seus atributos 
e conheça outras características dos relacionamentos.
Atributos do relacionamento
Quando um determinado relacionamento possui atributos, ele também é conhecido 
como relacionamento valorado. Essa situação ocorre apenas em relacionamento do 
tipo N:M. 
70
Exemplo
Pedro atua no projeto Alfa durante 30 horas.
Em que:
• Pedro: elemento do conjunto de valores do atributo Nome da entidade 
Funcionário.
• Alfa: elemento do conjunto de valores do atributo Nome do Projeto da 
entidade Projeto.
• Atua: ligação existente entre um funcionário e um projeto. Nesse caso, esse 
funcionário trabalha durante 30 horas nesse projeto, porém esse mesmo 
funcionário poderá trabalhar outro número de horas em outro projeto. 
Da mesma forma, outro funcionário trabalha outro número de horas no 
mesmo projeto Alfa. Portanto, podemos concluir que 30 horas é o atributo 
que pertence a Pedro no projeto Alfa.
Graficamente, esse relacionamento pode ser expresso por:
Funcionário ProjetoAtua
Horas
N M
Relacionamento ternário
Os relacionamentos entre múltiplas entidades expressam o fato de que todas as 
entidades que ocorrem simultaneamente, ou seja, todas as ocorrências envolvidas no 
relacionamento, possuem, sempre, ligações com todas as entidades envolvidas no 
relacionamento. Não pode existir um relacionamento triplo que, em um dado momento, 
transforme-se em duplo.
Observe o relacionamento a seguir:
71
Id_Aluno
Nome_Aluno
Dt_Matricula
Id_Disciplina
Nome_Disciplina
Id_Professor
Nome_Professor
Alunos
Professor
DisciplinaCursam
Na tabela abaixo, conheça os atributos de cada entidade:
Entidades
Relacionamento
Atributos
Atributos
Id Aluno
Id Aluno
Nome Aluno
Id Professor
Aluno
Cursam
Disciplina
Professor
Dt Matricula
Id Disciplina
Id Disciplina
Nome Disciplina
Id Professor
Nome Professor
Cardinalidade mínima
É o número mínimo de ocorrências de entidades que são associadas a uma ocorrência de 
uma entidade por meio de um relacionamento. Para fins de projeto de bancos de dados, 
consideram-se apenas duas cardinalidades mínimas: a cardinalidade mínima 0 e 1.
A cardinalidade mínima é anotada junto à cardinalidade máxima.
Veja no gráfico: 
72
Id_Pai
Nome
Id_Pessoa
Aluno
0:N 0:N
1:N
1:N
Professor
DisciplinaCursa
Leciona
Autorrelacionamento
Ocorre quando uma entidade possui um relacionamento com ela mesma. São, na verdade, 
representações de estruturas de hierarquia, como você pode observar no gráfico abaixo:
Pessoa
1
N
Tem pai
Na tabela abaixo, conheça os atributos de cada entidade:
Entidade Atributos
NomeId Pessoa Id Pai
Id Pessoa
PedroI-01
Nome
CarlosI-02 I-01
Pessoa
Id Pai
JoãoI-03 I-01
73
Exemplo
Observe um exemplo de autorrelacionamento.
Na tabela abaixo, conheça os atributos de cada entidade:
Funcionário
Produto
Composto
Gera
N
M
Entidade
Relacionamento
Atributos
Atributos
Id Pessoa
Cod Produto
Nome
Cod Produto composto
Pessoa
Compõe
Id Pai
Quantidade
Agregação
São relacionamentos dependentes de outros relacionamentos, ou seja, toda vez que 
existir um relacionamento do tipo muitos para muitos, ele irá gerar uma nova entidade 
que estará relacionada a outra entidade. Veja nos gráficos abaixo:
Meliante
Arma
VítimaAssassina
Usa
Nova entidade (retângulo cinza)
Cod_Arma
Local
Cod_Meliante CPF
74
Restrições para uso de agregação
Só podemos utilizar agregação quando temos um relacionamento de muitos para muitos. 
Observe no gráfico abaixo:
Meliante
Arma
VítimaAssassina
Usa
N
M
Generalização/especialização
Além de relacionamentos e atributos, propriedades podem ser atribuídas a entidades 
por meio do conceito de generalização/especialização. Com ele é possível atribuir 
propriedades particulares a um subconjunto de ocorrências (especializadas) de uma 
entidade genérica. 
A especialização é caracterizada pelo símbolo:
Observe o gráfico abaixo:
Conta Bancária
Pessoa física Pessoa jurídica
A generalização/especializaçãopode ser classificada em dois tipos, parcial ou total, 
de acordo com a obrigatoriedade ou não de cada ocorrência da entidade genérica 
corresponder a uma ocorrência da entidade especializada. Veja os casos a seguir:
Id_Conta Id_Conta
CPF CNPJ
Id_Conta
75
Conta Bancária
Pessoa física Pessoa jurídica
Funcionário
Motorista Secretária
Total
Indica que toda ocorrência da entidade cliente tem uma ocorrência em uma das 
especializações.
Parcial
Indica que nem todo funcionário é motorista e/ou secretária.
MIDIATECA
Acesse a midiateca da Unidade 2 e veja o conteúdo complementar indicado 
pelo professor sobre normalização de dados.
76
NA PRÁTICA
Uma empresa na área de metalurgia tem trabalhado com um sistema que opera 
suas funções com base em arquivos. Com o passar do tempo, a empresa veio 
perdendo informações e verificou que a consistência dos dados apresentados 
não era significativa. Assim, sua diretoria percebeu a necessidade de realizar 
a implantação de um banco de dados para trabalhar com o sistema existente 
e melhorar a performance do seu negócio. Diante disso, um database 
administrator – DBA foi contratado para apresentar algumas características e 
também exemplificar por que o banco de dados traria diferenciais significativos 
para o negócio.
As colocações feitas pelo DBA contratado foram:
• Eliminação de inconsistências – O armazenamento da informação é feito 
em um único local do banco de dados, com acesso descentralizado, e é 
compartilhado com vários outros sistemas. Dessa forma, os usuários estarão 
utilizando uma informação de confiança. A inconsistência de dados ocorre 
quando um mesmo campo possui valores diferentes em sistemas diferentes. 
Vejamos um exemplo: o estado civil de uma pessoa é solteiro em um sistema e 
casado em outro. Isso ocorre porque a pessoa em questão atualizou o campo 
em um sistema e não o atualizou em outro. Quando o dado é armazenado em 
um único local e compartilhado pelos sistemas, esse problema não ocorre.
• Restrições de segurança – Cada usuário possui um nível de acesso que 
permite:
 – Leitura.
 – Leitura e gravação.
 – Sem acesso ao registro ao arquivo e/ou campo.
Esse recurso impedirá que pessoas não autorizadas utilizem ou atualizem um
determinado arquivo ou campo.
• Compartilhamento dos dados – Permite que simultaneamente, e de forma 
segura, um dado seja acessado por mais de uma aplicação ou usuário, 
independentemente da operação que seja realizada. É importante observar, 
apenas, o processo de atualização concorrente, para que não haja geração 
de erros de processamento (atualizar simultaneamente o mesmo campo do 
mesmo registro). Os aplicativos são por natureza multiusuário, acessados por 
mais de um usuário ao mesmo tempo.
77
Resumo da Unidade 2
Nessa unidade, você estudou a importância de se utilizar a UML no desenvolvimento 
de soluções de software que estão ligadas à construção de uma ótima base de dados. 
Além disso, você verificou a importância de se trabalhar com afinco no levantamento de 
requisitos, etapa extremamente necessária para a criação do banco de dados, bem como 
para o futuro desenvolvimento das soluções sistêmicas. Para que você tenha condições 
de realizar essa tarefa, foram apresentadas as diversas técnicas de levantamento de 
requisitos existentes.
Por último, você conheceu, em detalhes, a etapa de modelagem de dados que está 
atrelada à construção do banco de dados e vislumbrou as representações gráficas que 
caracterizam a forma de criação de banco de dados. 
CONCEITO
Ao longo do estudo desta unidade, você teve contato com os conceitos 
fundamentais da UML, a necessidade do levantamento de requisitos para a 
construção do modelo de dados, os tipos de modelos de dados existentes no 
mercado e os mais empregados pelas grandes empresas de TI.
78
Referências 
MACHADO, F. N. R. Projeto e implementação de banco de dados. 3. ed. São Paulo: Érica, 
2014. Minha Biblioteca.
RAMARKRISHNAN, R. Sistemas de gerenciamento de banco de dados. 3. ed. Porto 
Alegre: AMGH, 2011. Minha Biblioteca.
Diagrama de classes
UNIDADE 3
80
Nesta unidade você vai estudar o conceito e a importância da UML na utilização de uma 
de suas representações, que é o diagrama de classe. Esse diagrama servirá para a reali-
zação da modelagem conceitual de um banco de dados.
INTRODUÇÃO
OBJETIVO
Nesta unidade você será capaz de:
• Construir um projeto lógico de banco de dados.
81
Conceito 
Introdução
Os diagramas de classe utilizados nos processos de modelagem de banco de dados estão 
entre os tipos mais úteis de diagramas UML (unified modeling language, ou “linguagem de 
modelagem unificada”), pois permitem o mapeamento de um determinado sistema de 
forma objetiva e clara, definido pela necessidade da empresa ao modelar suas classes, 
seus atributos, suas operações e suas relações entre objetos. 
Atualmente existem no mercado diversos softwares que permitirão criar esse tipo de 
diagrama e cada empresa seguirá uma tendência com relação a eles. Alguns exemplos 
de softwares de modelagem gratuitos são:
• Astha.
• Draw.io.
• Lucidchart.
• Gliffy.
• yUML.
• Creately.
Diagrama de classes em UML
É sabido que a linguagem de modelagem unificada – UML tem como objetivo ajudar na 
modelagem dos sistemas de diversas formas. Um dos tipos mais difundidos desse tipo 
de linguagem é o diagrama de classes. Ele é extremamente utilizado por engenheiros de 
software e analistas de sistemas para realizar a documentação da arquitetura do software 
a ser desenvolvido. Os diagramas de classe, na verdade, são um tipo de diagrama de 
estrutura, porque descrevem o que, especificamente, deve estar contido no sistema a ser 
modelado. 
A linguagem de modelagem unificada – UML teve seu desenvolvimento baseado em um 
modelo padronizado para descrever e tratar, de forma direcionada, uma abordagem para 
a programação orientada ao objeto, que, cada vez mais, vem se expandindo no mercado 
corporativo entre os desenvolvedores de soluções tecnológicas. Temos, nos dias de hoje, 
os próprios aplicativos para smartphone como um bom exemplo desse cenário. 
82
Os diagramas de classe são os componentes essenciais da linguagem de modelagem 
unificada, da mesma forma que as classes são os componentes básicos dos objetos. 
Nesse sentido, os diversos componentes de um diagrama de classe vão, na íntegra, 
representar as classes que serão realmente programadas, pois os principais objetos ou as 
interações entre classes e objetos caracterizam essa representatividade perante o modelo. 
A forma geométrica dada para a diagramação de classe em si consiste na figura de 
um retângulo com três linhas verticais. A linha superior define o nome da classe, a linha 
do meio representa os atributos da classe e a linha inferior expressa os métodos ou 
operações que a classe pode utilizar. As classes e as subclasses existentes no modelo 
serão sempre agrupadas, com o objetivo de mostrar a relação estática entre cada objeto.
Sobre os diagramas de classe, você precisa conhecer: a perspectiva a 
partir da qual eles devem ser construídos, seus componentes, se existe 
herança entre as classes e quais são os seus atributos de visibilidade. 
Entenda melhor cada uma dessas categorias na sequência.
Perspectivas
Os diagramas de classe podem ser construídos a partir de duas perspectivas, a saber:
Conceitual Implementação
É a forma abstrata de observação 
dos objetos a serem modelados. Isso 
independe da linguagem de programação 
a ser utilizada.
Nesse momento, o foco é para a reflexão 
de detalhes de implementação para a 
definição das classes e dos objetos.
Representa uma entidade, processo ou 
conceito do mundo real: 
Identidade: valor de uma característica que o 
identifica.
Atributo: qualidade e características.
Comportamento: habilidade para 
processamento.
Representa um módulo que recebe e produz 
dados:
Identidade: identificador para a linguagem a 
ser implementada.
Atributo: variáveis e seus respectivos tipos 
de dados.
Comportamento: funções ouprocedimentos. 
É sabido que os resultados obtidos 
determinam o comportamento do objeto.
83
Componentes de um diagrama de classe
O diagrama de classes, dentro do seu formato padrão estabelecido, é composto de três 
partes:
Nome da classe
Atributos
(caracte-
rísticas)
Operações
(compor-
tamentos)
Parte superior: vem com a informação do nome da classe. Essa parte é fun-
damental, pois terá a referência do classificador ou de um respectivo objeto.
Parte do meio: vem com a informação dos atributos da respectiva classe. 
Essa parte é utilizada para descrever com clareza as qualidades da classe. 
É fundamental para se descrever uma instância específica de uma determi-
nada classe.
Parte inferior: vem com a informação que incluirá as respectivas opera-
ções da classe (os métodos). Será mostrado em formato de lista. Cada ope-
ração terá a sua própria linha. As operações irão descrever como a classe 
interagirá com os demais dados.
Componentes adicionais dos diagramas de classes
Diante das tendências de modelagem, é sabido que as classes pertencentes a um 
respectivo diagrama de classes representarão os principais objetos do modelo, bem como 
as interações no aplicativo a ser desenvolvido ou as classes a serem programadas. Para 
isso, é preciso entender a composição básica e necessária de um diagrama de classes. 
No quadro a seguir estão detalhados os componentes de um diagrama de classes:
Classes
São caracterizadas por um template a ser definido para que haja a criação 
de objetos e a implementação de um comportamento em um referido sis-
tema. No cenário da UML, uma classe deverá representar um determinado 
objeto ou um conjunto de objetos que compartilham uma estrutura e um 
comportamento comum.
As classes são representadas graficamente pela figura de um retângulo, 
que inclui linhas referentes ao seu nome, seus respectivos atributos e suas 
operações. Quando for desenhar a classe em um diagrama de classes, é 
importante que fique claro que somente a primeira linha deve ser preenchi-
da com informações; as outras linhas são opcionais, caso queira fornecer 
mais detalhes para aquela classe.
84
Sinais
Tipos de dados
Pacotes
Interfaces
Enumerações
Objetos
Artefatos
São caracterizados pelos símbolos que trazem, em sua representatividade, 
as comunicações de forma unidirecional e assíncrona entre objetos ativos 
no modelo.
São denominados de classificadores e têm por objetivo definir os valores 
dos dados a serem utilizados. Os tipos de dados definidos modelarão os 
tipos primitivos e também as enumerações necessárias.
São vistos como formas projetadas para estruturar os classificadores rela-
cionados em um determinado diagrama de classes. Sua simbologia é de-
terminada por uma grande forma de retângulo com abas.
São estabelecidas por uma coleção de assinaturas de operações e/ou de-
finições de atributos que definem um conjunto íntegro e ajustado de com-
portamentos. Têm características semelhantes às classes, exceto que uma 
classe pode conter uma instância de seu tipo e uma interface precisa ter, 
pelo menos, uma classe para implementá-la.
São caracterizadas por representações dos tipos de dados definidos pelo 
usuário no processo de levantamento de requisitos. Uma enumeração, no 
seu processo de definição, incluirá os grupos de identificadores que repre-
sentam os valores da respectiva enumeração.
São caracterizados pelas instâncias definidas de uma determinada classe 
ou classes. Os objetos poderão ser inseridos em um diagrama de classes 
para representar instâncias concretas ou prototípicas.
São caracterizados pelos elementos do modelo que representarão as res-
pectivas entidades concretas em um sistema de informação.
85
A seguir, veja exemplos de diagramas de classe.
Observe os exemplos de diagramas de classe e suas aplicações:
Exemplo 1
ALUNO
nome: TipoNome
ra: TipoCodigo -nome [30]: char
+ra: int
<Entidade>
Alunos
DePacoteCadastro
CalculaMedia: TipoNota
+CalculaMedia(): double 
 Visão conceitual
Visão implementação
Observe o diagrama de classes para a classe voo e seus desdobramentos:
Lista de atributos da classe voo
A seção de atributos de uma classe tem, por definição, listar cada um dos 
atributos da classe em uma linha específica. A seção de atributos é uma opção, 
mas, se for usada, é preciso que contenha cada atributo da classe exibido na 
forma de lista, de acordo com o seguinte modelo: nome: tipo de atributo. Veja 
uma aplicação prática: numerovoo: numero inteiro (tipo de dado).
Exemplo 2
VOO
numerovoo: inteiro
datapartida: data
duracaovoo: minutos
atrasovoo (numero de minutos: inteiro) : data
horaaterrizagem () : data
Diagrama de classes – Classe voo
Nome da classe
Atributos
(características)
Operações
(comportamentos)
86
Dando sequência ao exemplo, podemos descrever os atributos de classe com 
as informações do tipo de atributo. Os nomes dos atributos da classe voo e 
seus respectivos tipos associados podem ser organizados da seguinte forma:
Lista de operações da classe voo
As operações das respectivas classes estarão devidamente documentadas 
no terceiro compartimento do retângulo do diagrama de classes, que, como 
já citado anteriormente, poderá ser opcional. Com os devidos atributos 
estabelecidos, as operações de uma respectiva classe são exibidas no modelo 
de lista, com cada operação definida em sua própria linha, de acordo com o 
seguinte modelo:
• Nome (lista de parâmetros): tipo de valor retornado.
A tabela acima informa que a operação atrasovoo tem um parâmetro de entra-
da, que é o numerodeminutos, do tipo minutos. Contudo, a operação atrasovoo 
não tem um valor de retorno. 
É importante ressaltar, ainda, que a operação atrasovoo não tem um valor de 
retorno, porque essa decisão foi tomada no momento de sua criação. Quan-
do em uma determinada operação houver parâmetros, eles serão colocados 
dentro dos parênteses da operação. Cada parâmetro usa o seguinte formato: 
nome do parâmetro : tipo de parâmetro.
Nome do atributo Tipo de atributo
numerovoo Número inteiro
datapartida Data
duracaovoo Minutos
Nome da operação Retorno de parâmetros Tipo de valor
atrasovoo N/A
horaaterrizagem N/A
Nome
numerodeminutos
Digite
minutos
Data
87
O código gerado a partir de um diagrama de classes precisa de classes cujos 
tipos de atributo sejam limitados aos tipos de atributos já existentes nas 
linguagens de programação que são tradicionais no mercado ou aos tipos 
incluídos no modelo que também serão implementados no sistema.
É sabido que, em alguns casos, faz-se necessária a atribuição de um valor 
padrão para um ou mais atributos.
A especificação contida na UML permite que a utilização da identificação do 
valor padrão do atributo seja feita na seção de atributos de acordo com a 
notação abaixo:
• nome: tipo de atributo = valor padrão
Exemplo:
saldoconta : real = 1000
Importante
Herança
Um conceito importante é o de herança entre as classes, que deriva a superclasse e a 
classe-filha. 
A herança trata da capacidade de uma classe (classe-filha) de herdar uma funcionalidade 
idêntica de outra classe (superclasse) e, na sequência, incluir uma nova funcionalidade 
própria. 
Para modelar a herança no respectivo diagrama de classes, é preciso usar a simbologia 
de uma linha sólida que é desenhada a partir da classe-filha (a classe que herda o 
comportamento da superclasse), com uma ponta de seta (ou um triângulo) fechada, não 
preenchida, apontando para a superclasse. 
Considere a figura abaixo. Ela demonstra como as classes-filha Professor e Coordenador 
herdam as funcionalidades da superclasse Funcionário.
88
Funcionário
Professor Coordenador
Atributos de visibilidade
Todas as classes mapeadas em um diagrama terão diferentes níveis de acesso, 
dependendo do modificador de acesso (visibilidade).
Entenda os níveis de acesso com sua respectiva simbologia:
• Público (+) – Indica que o atributo tem visibilidade liberada, sem restrições, para 
qualquer classe.
• Privado (-) – Indica que o atributo éacessado somente pela própria classe.
• Protegido (#) – Indica que o atributo é acessado por qualquer classe derivada.
• Pacote (~) – O atributo é acessado pelo relacionamento da classe com a classe que 
é externa.
MIDIATECA
Acesse a midiateca da Unidade 3 e veja o conteúdo complementar indicado 
pelo professor na mídia 1.
89
Relacionamento entre as classes 
Relacionamento
O relacionamento permite compartilhar informações e colaborar com a execução dos 
processos do sistema que foi modelado para atender a uma demanda. Ele descreve, 
de forma clara, o vínculo que ocorre, na sua essência, entre os objetos de uma ou mais 
classes que foram contemplados no diagrama de classes.
 
Observe o gráfico abaixo. Note que existem três tipos de relacionamento, com suas 
respectivas subdivisões internas:
Unidirecional
Bidirecional
Reflexiva
Classe de associação
Básica
Normal
Ternária
De composição
Restrita
Associação
AgregaçãoRelacionamentos
Generalização
90
A seguir, conheça cada um dos tipos de relacionamento.
Associações
Ao realizar a modelagem em um sistema, determinados objetos estarão relacionados 
entre si. Os relacionamentos entre esses objetos, por sua vez, também precisam ser 
modelados para que haja mais clareza e entendimento sobre todos os tipos de relação 
entre as classes.
Existem cinco tipos de associações que podemos modelar. Nesta unidade, no entanto, 
só trataremos das duas mais importantes, que são as associações unidirecionais e as 
bidirecionais. 
a. Associação unidirecional
Em uma associação unidirecional, duas classes são relacionadas, mas somente uma 
classe reconhece que o relacionamento existe entre elas.
Símbolo da associação unidirecional
Uma associação unidirecional é desenhada com base em uma linha sólida, 
com uma ponta da seta aberta. Note, no símbolo de associação unidirecional 
acima, que não pode ser utilizada uma ponta de seta fechada nem um triângulo. 
A ponta da seta sempre aponta para a classe reconhecida. 
Importante
Para a composição da associação, é importante que haja um nome da função e um valor 
de multiplicidade, que valem somente para a classe que é reconhecida.
91
Observe os exemplos de diagramas de classe e suas aplicações:
Repare que o nome da função vem escrito abaixo do símbolo da associação 
unidirecional (possui) e o valor de multiplicidade vem escrito logo acima (0..*).
Exemplo
Funcionário Dependente
numemat: int
nomefunc: string
salario: double
grauparentesco: string
manterfunc(): void
0..*
Possui
b. Associação bidirecional (padrão)
Uma associação bidirecional será uma ligação entre duas classes mapeadas no diagrama 
de classes. Nesses casos, ambas as classes estarão cientes de que pertencem ao 
relacionamento, a menos que você qualifique a associação como algum outro tipo.
Símbolo da associação bidirecional: 
Uma associação bidirecional é caracterizada por uma linha sólida que faz 
a ligação entre as duas classes. Repare que não existem setas nem outros 
símbolos na ponta da linha.
Em ambas as extremidades da linha, você colocará um nome para a função e 
um valor de multiplicidade.
Importante
92
Observe o exemplo abaixo. Nesse caso, ambas as classes se enxergam.
Repare que o nome da função vem escrito abaixo do símbolo da associação 
bidirecional (possui), e os valores de multiplicidade vêm escritos logo acima (1 
e 0..*).
Exemplo
Funcionário Dependente
numemat: int
nomefunc: string
salario: double
nome: string
grauparentesco: string
manterfunc(): void
1 0..*
Possui
Saiba mais
Valores de multiplicidade e seus indicadores
Indicador Significado
0..1 Zero ou um
0..* Zero ou mais
1..* Um ou mais
0..5 Zero a cinco
1 Somente um
* Zero ou mais
3 Somente três
5..15 Cinco a quinze
93
Além dessas duas, você vai conhecer também as associações reflexivas, 
as classes de associação e as associações ternárias.
c. Associação reflexiva
Até aqui você verificou que todos os nossos exemplos demostraram um relacionamento 
entre duas classes distintas. Também é provável que uma determinada classe se associe 
com ela própria, a partir da associação reflexiva. Isso pode até soar de forma estranha, 
mas é importante lembrar que as classes são, na verdade, abstrações. Quando uma 
determinada classe se associa com ela própria, isso não quer dizer que uma instância da 
classe esteja relacionada com ela própria, mas sim que uma determinada instância da 
classe está relacionada a outra instância da classe.
Veja o exemplo a seguir.
No relacionamento representado graficamente acima, uma instância da classe 
Funcionário pode ser o gerente de outra instância da classe Funcionário. Por 
outro lado, como a função de relacionamento “gerencia” tem uma multiplicidade 
de 0..*, pode acontecer de um Funcionário não ter nenhum outro Funcionário 
para gerenciar. 
Exemplo
Funcionário
codigo: int
nome: string
manterfunc(): void
1 
0..*
Gerência
d. Classe de associação
Na modelagem das associações, algumas vezes é necessário incluir outra classe (terceira 
classe), porque ela inclui informações de suma importância sobre o relacionamento em 
questão. Para isso, é necessário usar a chamada classe de associação a ser vinculada à 
associação primária. 
94
Uma classe de associação tem a sua representatividade no formato de uma classe normal. 
A única diferença existente é que a linha de associação entre as classes primárias faz 
uma interseção com uma nova linha pontilhada que se conecta à classe de associação.
Veja o exemplo abaixo:
Exemplo
Funcionário
Fornecimento
Produto
cnpj: int
nome: string
data: date
valor: double
codigo: int
tipo: string
valor: double
manterfunc(): void manterfunc(): void
Classe de associação
e. Associação ternária
A associação ternária permite a associação entre três classes. 
Esse tipo de associação é representada por um losango (diamante) e, ainda, suporta uma 
associação de classe ligada a ela. Nesse caso, desenha-se uma linha tracejada a partir 
do losango para a classe em que será feita a associação ternária.
95
Exemplo
Funcionário
Funcionário
Produto0..* 
1..* 
1..* 
Agregação
A atuação da agregação no diagrama condiz com um tipo especial de associação, usado 
para modelar um determinado relacionamento do “todo com as suas respectivas partes 
integrantes”. 
Nos relacionamentos denominados básicos, que possuem a necessidade do uso de 
agregação, o ciclo de vida de uma respectiva classe mapeada como “parte” é independente 
do ciclo de vida da classe mapeada como “todo”.
Vamos analisar um exemplo.
Considere um carro como uma entidade inteira e a porta do carro como uma 
parte do carro como um todo. A criação da porta pode ser realizada na fábrica 
semanas antes da construção do carro como um todo e pode ser estocada 
em um armazém e/ou galpão até ser colocada no carro durante o processo de 
montagem final do veículo. 
Dessa forma, poderemos verificar que a instância da classe “porta” tem um 
ciclo de vida totalmente independente da instância da classe “carro”. Contudo 
existem momentos em que o ciclo de vida da classe “parte” não é indepen-
dente do ciclo de vida da classe “todo”. Isso é o que denominamos de agre-
gação de composição.
Exemplo A
96
Imagine o relacionamento de uma empresa com seus respectivos 
departamentos. A empresa e os departamentos serão modelados como 
classes. Entretanto um departamento não poderá existir sem que, antes, a 
empresa exista. Nese caso, a instância da classe “departamento” depende da 
existência da instância da classe “empresa”.
Exemplo B
Na sequência, vamos explorar a agregação básica e a agregação de composição.
a. Agregação básica
A agregação básica existente em um modelo tem a finalidade de indicar que uma 
determinada classe fará parte de outra. Quando há esse tipo de relacionamento, a classe-
filha poderá ter uma vida maior do que a classe-pai (superclasse). 
Símbolo de agregação básica: 
Uma agregação básica é caracterizada por uma linha sólida que parte da classe-
pai (superclasse) para a classe-filha.Um losango não preenchido (vazio) deve 
ser desenhado na extremidade da associação da classe-pai (superclasse).
Importante
Exemplo
Funcionário Produto
cnpj: int
nome: string
codigo: int
tipo: string
valor: double
manterfunc(): void manterfunc(): void
97
b. Agregação de composição
O relacionamento de agregação de composição é mais uma forma de relacionamento de 
composição, mas, nesses casos, o ciclo de vida da instância da classe-filha depende do 
ciclo de vida da instância da classe-pai (superclasse).
Símbolo de agregação de composição: 
Uma agregação de composição é caracterizada por uma linha sólida que parte 
da classe-pai (superclasse) para a classe-filha. Um losango preenchido (cheio) 
deve ser desenhado na extremidade da associação da classe-pai (superclasse).
Importante
Veja o exemplo abaixo.
No relacionamento modelado no diagrama de classe acima, uma instância da 
classe Empresa sempre terá pelo menos uma instância da classe Departamento. 
Como o relacionamento em questão é um relacionamento de composição, se 
a instância de Empresa for excluída/removida, a instância de Departamento 
também será, de forma automática, excluída/removida.
Outro recurso de suma importância da agregação de composição é que a 
classe da parte somente pode estar relacionada a uma instância da classe-pai 
(como a classe Empresa citada no exemplo acima).
Exemplo
Empresa Departamento
cnpj: int
nome: string
codigo: int
tipo: string
manteremp(): void
98
Generalização 
A generalização é tida como um relacionamento entre um elemento geral e um outro 
mais específico. O elemento que se entende por mais específico possui todas as 
características do elemento geral e contém ainda mais algumas particularidades. 
Um objeto mais específico pode ser usado como uma instância do elemento mais 
geral. A generalização, também chamada de herança, permite a criação de elementos 
especializados em outros.
Existem dois tipos de generalização, que podem variar em sua utilização, a partir da 
situação em que serão empregadas: normal e restrita. Conheça cada uma delas, na 
sequência.
a. Generalização normal
Na generalização normal, a classe mais específica, chamada de subclasse, herda tudo 
da classe mais geral, a superclasse. Os atributos, as operações e todas as associações 
são herdados.
Símbolo de generalização normal: 
Exemplo
Conta Corrente Poupança
b. Generalização restrita
A generalização restrita se divide em: 
• Generalização de sobreposição – Quando as subclasses herdam de uma 
superclasse por sobreposição. 
99
• Generalização disjuntiva – Quando um objeto pertence a apenas um tipo de classe. 
Quaisquer outras subclasses criadas posteriormente poderão herdar de somente 
uma subclasse. 
• Generalização completa – Quando todas as subclasses possíveis foram enumeradas 
na hierarquia. 
• Generalização incompleta – Quando nem todas as subclasses foram enumeradas 
na hierarquia.
Veja os exemplos de generalização a seguir. 
Exemplo
Veículo
Sobreposição
Anfíbio
Carro Barco
100
Pessoa
Completa/Disjunta
Homem Mulher
Veículo
Incompleta
Carro Barco
MIDIATECA
Acesse a midiateca da Unidade 3 e veja o conteúdo complementar indicado pelo 
professor na mídia 2.
101
Modelando o diagrama de classes 
Os benefícios dos diagramas de classes
É sabido que a maior parte das organizações, no processo de desenvolvimento de seus 
bancos de dados, para atender a uma demanda de software, trabalhará fortemente 
com sua equipe no processo dos diagramas de classe, pois eles oferecem uma série de 
benefícios.
Conheça os benefícios trazidos pelos diagramas de classes UML:
• Ilustrar de forma clara os modelos de dados utilizados para a criação dos sistemas 
de informação, não importa o quanto são simples ou complexos.
• Entender de forma mais eficaz a visão geral dos esquemas de uma aplicação a ser 
desenvolvida.
• Expressar visualmente as referidas necessidades que devem ser tratadas em um 
sistema e também divulgar claramente essas informações para toda a empresa.
• Criar gráficos específicos, com detalhamentos que gerem destaque para qualquer 
código específico necessário para ser programado e implementado.
Agilidade x UML
A agilidade não está relacionada com a velocidade de produção de um software. Pelo 
contrário, ela se refere a produzi-lo com uma determinada velocidade, entregando-o no 
menor tempo possível e melhorando o processo de produção de forma contínua. Para 
ser ágil, é fundamental que haja eficiência. Não se pode falar em agilidade sem a devida 
eficiência. Além disso, não pode haver desperdício de tempo.
Nos projetos de softwares, desenvolvidos no âmbito das empresas, por equipe de analistas, 
temos que um dos maiores desafios é sempre a boa comunicação entre os participantes 
do projeto. Para que a dupla agilidade — eficiência funcione, é necessário que:
• Esteja claro o que se deseja.
• Todos na empresa saibam o que será entregue.
• Esteja claro como a produção do software vai acontecer. 
102
Todos sabem da complexidade da produção de um diagrama de classes, mas ele é uma 
ferramenta fundamental, pois, quando se entende um “requisito” da forma errada, há um 
custo para fazer errado, desfazer e refazer da forma como se deve. Esse tipo de erro 
custará muito mais caro do que se tivesse sido evitado da primeira vez.
Dessa forma, temos que o uso racional e coerente dos diagramas de 
classe com a perspectiva de transmitir ideias entre membros de um 
mesmo grupo é uma ferramenta que favorecerá muito a agilidade de 
produção e minimizará as possibilidades de erro.
Objetivo da utilização do diagrama
O diagrama de classes, como já citado, tem como objetivo principal a especificação dos 
componentes que farão parte da construção do sistema de informação e como esses 
componentes se interligam do ponto de vista estrutural.
Quando é necessário utilizar o diagrama de classes?
De acordo com Ventura (2018), o diagrama é uma ferramenta bem versátil quanto às 
possibilidades de aplicação prática para o desenvolvimento do software.
Temos desde os modelos estruturais mais simples até os modelos mais complexos, 
com arquiteturas que envolvem padrões de projetos diversos, modelos objeto-relacional, 
APIs de microsserviços e mil e uma outras coisas.
Diante do cenário, o importante é entender o contexto no qual o diagrama será aplicado, 
para então usá-lo da melhor forma possível e atender à devida demanda.
Ainda de acordo com Ventura (2018), levando-se em consideração as possibilidades de 
aplicação do diagrama de classes, ele poderá ser utilizado para diferentes finalidades no 
contexto de produção de software. Em destaque, temos:
• Design: será necessária a definição de um modelo a ser seguido para um software 
que ainda não foi concebido, assim especificando um modelo antes de efetivamente 
construir o software executável (diminuindo o desperdício).
103
• Engenharia reversa: é importante que haja uma reflexão na estrutura que já existe 
de um software, em que, a partir do código-fonte, faz-se uma leitura automática (ou 
não) das classes e das suas relações e se produz o diagrama (para entendimento 
da estrutura do software executável).
• Esboço de ideias: é importante que se desenhem modelos estruturais para troca de 
ideias e alinhamento entre os analistas de sistemas envolvidos no projeto.
Mapeando o diagrama de classes
O mapeamento do diagrama de classes envolve algumas etapas importantes. Veja o 
esquema abaixo com o passo a passo:
Regras úteis Como fazer a identificação?
Identificando 
as associações
Identificando 
as agregações
Identificando 
os atributos
Identificando 
os métodos
Identificando 
as 
generalizações
Agora veja detalhadamente cada uma das etapas.
Regras úteis
• É melhor mapear demais do que de menos.
• Não exclua entidades simplesmente porque os requisitos não indicam necessidade 
de guardar requisitos sobre elas.
• Comece fazendo uma relação das entidades candidatas.
• Considere os substantivos e frases nominais nas descrições textuaisdo domínio do 
problema como possíveis candidatos a entidades e/ou atributos.
Como fazer a identificação?
• Existem informações que devem ser analisadas e/ou informadas.
• Existem sistemas externos ao modelado?
 – Se existirem, eles deverão ser tratados como classe pelo sistema para que possa 
interagir com outros meios externos.
• Qual o papel dos atores no sistema?
 – Talvez o papel deles possa ver visto como uma classe.
104
Identificando as associações
• Foque nas associações cujos conhecimentos devem ser mantidos.
• Use nomes e expressões verbais que façam sentido quando forem lidas no contexto 
do modelo desenvolvido.
• Evite demonstrar o uso de associações deriváveis e restritas.
• É muito mais importante que haja a identificação dos conceitos do que das 
associações.
• Muitas associações tendem a gerar confusão no modelo em vez de torná-lo 
inteligível.
Identificando as generalizações
• A subclasse terá atributos adicionais de interesse?
• A subclasse terá associações adicionais de interesse?
• A subclasse se comportará de forma diferenciada da superclasse ou das outras 
subclasses?
• Criando superclasses:
– As subclasses com potencial representarão variações de um conceito similar?
– As subclasses satisfarão 100% da regra estabelecida?
– Todas as subclasses possuirão um atributo comum definido na superclasse?
– Todas as subclasses possuirão uma associação comum que se relacionará com 
a superclasse?
Identificando as agregações
• Verifique se algumas classes podem se agrupar em algum composto:
– Elas geralmente são criadas/destruídas no mesmo momento?
– Elas possuem relacionamentos comuns?
• Verifique se alguma classe pode ser subdividida em partes:
• As partes possuem tempo de vida limitado ao tempo de vida do composto?
• Elas possuem relacionamentos particulares e de interesse?
Identificando os atributos
• Atributos devem representar, preferencialmente, tipos primitivos de dados ou de 
valores simples.
• Atributos não podem ser usados para:
– Representar um conceito complexo.
– Relacionar conceitos (chaves estrangeiras).
105
Identificando os métodos
• Os métodos são acrescentados na perspectiva de implementação e são derivados a 
partir do diagrama de interação.
• É importante que haja distinção da operação de método.
• Operação é uma coisa que se evoca (chamada do procedimento). Para realizar uma 
operação, a classe implementa um método (corpo do procedimento).
• É fundamental identificar operações que alteram ou não o estado (os atributos) de 
uma classe.
• Não modificam: query, métodos e obtenção e getting methods.
• Modificam: modificadores, métodos de atribuição ou fixação, setting methods.
Uma classe que será definida no diagrama de classe da UML possuirá três 
compartimentos, sendo um para cada um dos itens a seguir: 
• Nome (primeiro).
• Atributos (segundo). 
• Operações (terceiro).
Quando fazemos o uso de diagramas de classe no dia a dia do desenvolvimento 
de um software, nem sempre é necessário e/ou relevante fazer a representação 
de cada classe no menor nível de detalhe, ou seja, com os três compartimentos, 
e com todo rigor nas especificações dos atributos e operações.
Saiba mais
Cozinha
PortaCozinha PortaQuarto
Quarto
Porta
Sala PortaSala
Modelo de um diagrama de classes
106
No diagrama acima, detalhado na obra de Ventura (2018), temos a definição dos 
relacionamentos de associação, agregação, composição e generalização (também 
vistos como herança). 
Explicação da construção do modelo:
• Cozinha pode ter ou não uma PortaCozinha, podendo existir se não tiver (agregação).
• PortaCozinha generaliza Porta, possuindo todas as características que Porta tem, 
além das suas específicas (generalização).
• Quarto deve ter PortaQuarto, não podendo existir se não tiver (composição).
• PortaQuarto generaliza Porta, que tem todas as características que Porta tem, além 
das suas específicas (generalização).
• Sala deve ter PortaSala, não podendo existir se não tiver (composição).
• PortaSala generaliza Porta, que tem todas as características que Porta tem, além 
das suas específicas (generalização).
• Sala pode ter ou não uma Porta que não seja uma PortaSala, mas, se tiver ou não, 
isso não fará diferença, pois Porta pode existir sem Sala, e Sala pode existir sem 
Porta (associação). 
MIDIATECA
Acesse a midiateca da Unidade 3 e veja o conteúdo complementar indicado 
pelo professor na mídia 3.
107
NA PRÁTICA
O senhor Paulo Freitas de Mello, há cinco anos, resolveu investir suas aplicações 
na criação de uma empresa que organiza festas infantis. Ele estabeleceu 
que o limite da idade a ser atendida seria de 13 anos. Com os investimentos 
realizados, Paulo conseguiu produzir uma boa quantidade de temas para a 
locação (em torno de 20 temas). Agora, com o crescimento do negócio, ele 
tem a necessidade de controlar com maior afinco os aluguéis das festas, pois 
está com um novo sócio. Para isso, Paulo demandará uma nova aplicação que 
lhe permita cadastrar: 
• Nome e telefone do cliente.
• Endereço completo da festa.
• Tema escolhido.
• Data da festa.
• Hora de início e de término da festa. 
Também há um detalhe que, para os clientes mais antigos (três anos de 
locação), Paulo vai proporcionar: uma política de descontos para potencializar 
ainda mais o negócio. Sendo assim, é preciso saber o valor realmente cobrado 
em um determinado aluguel de festa.
Dessa maneira, Paulo demandará da equipe de desenvolvimento contratada a 
representação de um diagrama de classes que atenda a essa nova necessidade. 
Veja o resultado a seguir.
108
Tema
Aluguel
Cliente
Endereco
Itemtema
nome: string
valor: double
data: date
horarioinicio: time
horariofim: time
valor: double
codigo: int
nome: string
logradouro: string
numero: int
complemento: string
bairro: string
nome: string
descricao: string
1..*
1..*
1
1
1
0..*
109
Resumo da Unidade 3
Nesta unidade você estudou a importância dos conceitos ligados ao desenvolvimento 
do diagrama de classes. Você viu, a partir de uma abordagem sucinta, a definição de 
classes e como se dá a sua representação dentro do modelo.
Você conheceu o conceito de relacionamento, estudou como ocorrem os relacionamentos 
entre as classes e as variações existentes: associação, agregação e generalização. 
Por fim, você foi apresentado a possíveis cenários importantes para a criação de um 
diagrama de classes, levando em consideração os questionamentos necessários para 
que haja um mapeamento correto com relação às necessidades levantadas.
CONCEITO
Ao longo do estudo desta unidade você teve contato com os conceitos funda-
mentais da UML, conceitos distintos sobre as classes, bem como as relações 
pertinentes aos relacionamentos estabelecidos entre as classes.
110
Referências 
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. São Paulo: Pearson, 2005. 
Biblioteca Virtual.
OLIVEIRA, A. J. F. de. Método para avaliação de risco operacional em banco de dados. 
São Paulo: Blucker, 2017. Biblioteca Virtual.
VENTURA, P. Entendendo o diagrama de classes da UML: modelo de classes com UML. 
Até o Momento. Belo Horizonte, 16 jul. 2018. Disponível em: https://www.ateomomento.
com.br/uml-diagrama-de-classes/. Acesso em: 23 mar. 2019.
VICCI, C. Banco de dados. São Paulo: Pearson, 2015. Biblioteca Virtual.
https://www.ateomomento.com.br/uml-diagrama-de-classes/
https://www.ateomomento.com.br/uml-diagrama-de-classes/
Normalização de dados
UNIDADE 4
112
Nesta unidade, você vai estudar o conceito e a importância do uso do processo de nor-
malização para que o banco de dados a ser utilizado na empresa esteja o mais correto e 
íntegro possível. Serão tratadas cinco formas de normalização que garantirão total inte-
gridade ao processo. 
INTRODUÇÃO
OBJETIVO
Nesta unidade, você será capaz de:
Construir um projeto de banco de dados por meio da aplicação das formas 
normais, otimizando os atributos de um modelo de dados.
113
Engenharia reversa 
Introdução
A engenharia reversa tem como missãoa realização de uma atividade que trabalhe com 
demandas de produtos que já estejam sendo executados (softwares, tabelas, periféricos, 
placas de computador etc.), em que o seu desafio será entender como esse software/
produto tem o seu mecanismo de funcionamento, o que ele exerce e como ele se comporta. 
A engenharia reversa se faz necessária quando temos o desejo de trocar ou de modificar 
uma peça/software/tabela por outro, com as mesmas características. Ela também é 
utilizada quando precisamos entender como uma peça/software/tabela executa as suas 
responsabilidades e não temos acesso, de alguma forma, à sua documentação, que trata 
de todas essas características.
É preciso entender que há uma diferença entre a engenharia reversa e a reengenharia. Veja:
Engenharia reversa Reengenharia
Consiste em apenas analisar 
o sistema de informação ou a 
ferramenta a ser utilizada para 
criar uma representação dela.
Esta vai mais além. Faz a análise do 
projeto, na sequência cria uma repre-
sentação dele e, diante dessa repre-
sentação, monta uma nova estrutura 
que funcione da mesma forma que a 
primeira, mas que não seja meramente 
cópia dela. É preciso que haja alguns 
diferenciais de modernização.
Por que a necessidade da engenharia reversa na informática?
As empresas trabalham com sistemas de informação que podem apresentar fragilidades, 
como:
• O sistema pode ser muito antigo (15 anos).
114
• O sistema tem muito pouco material em termos de documentação.
• A documentação existente não foi atualizada.
• Os analistas responsáveis pelo sistema deixaram a empresa e a nova equipe não 
sabe dar informações.
• Os processos decisórios que foram tratados não foram registrados.
• Surgimento da necessidade de migração de um sistema que trabalhe com tabelas 
para um banco de dados.
• Existência de vários programas que acessam as mesmas tabelas. Daí a necessi-
dade de criar um banco de dados integrado.
• O sistema é implementado em uma linguagem de programação antiga (Dbase, Ba-
sic, Cobol, Fortran, APL) para a qual não existem muitos mecanismos de atualização.
É sabido que o sistema de informação precisa evoluir conforme a necessidade de 
mercado:
• Ser adequado imediatamente às novas tendências e tecnologias.
• Ser reestruturado aos novos softwares (bibliotecas, APPs, novas linguagem de 
programação, novas ferramentas).
• Seguir novas regras regionais (por exemplo, o uso de nova moeda em todos os 
países da Europa).
• Disponibilizar, de forma imediata, novas funcionalidades que as empresas tendem 
a usar para serem mais competitivas.
Agora que você já sabe o que é engenharia reversa e como surge a ne-
cessidade de empregá-la, conheça os seus diferentes tipos.
Tipos de engenharia reversa
São três os tipos de engenharia reversa. Veja no gráfico abaixo:
Tipos de engenharia reversa
de software para o banco 
de dados
para o banco 
de dados de BI 
115
A seguir, conheça cada tipo de engenharia reversa.
1. Engenharia reversa de software
A engenharia reversa utilizada para o padrão de software está balizada em fazer a análise 
do sistema de informação para criar a representação do próprio sistema em um nível 
mais elevado de abstração.
Em alguns casos, essa atividade pode ser vista como “dar um passo atrás no ciclo de 
desenvolvimento do software”.
De forma prática, há dois tipos de engenharia reversa para o software:
A. Para o primeiro caso, temos o código-fonte (programa) disponível. Por outro lado, 
outros documentos mais formais não estão disponíveis: falta a documentação ou a 
documentação não está atualizada. Daí a necessidade de desvendar esses dados.
B. Para o segundo caso, o código-fonte (programa) do software não está disponível. 
Só existe o arquivo executável. Nesses casos, todos os esforços realizados 
pela equipe para desvendar um possível código-fonte para esse software são 
considerados uma forma de engenharia reversa.
2. Engenharia reversa para o banco de dados
O processo adotado para a engenharia reversa em banco de dados é considerado uma 
técnica por meio da qual a partir de um banco de dados já implementado (em pleno 
funcionamento na empresa) é criado o seu modelo de forma conceitual (modelo entidade-
relacionamento e/ou diagrama de classes). 
A engenharia reversa em banco de dados é um processo que possui quatro etapas. São elas:
116
A etapa 1 é dividida com base em três regras fundamentais: 
I. Chave primária da tabela composta por mais de uma chave 
estrangeira: isso se dá quando uma chave primária da tabela é 
composta por mais de uma chave estrangeira. Assim, podere-
mos caracterizar a necessidade do relacionamento n:n.
II. Chave primária completa da tabela forma uma chave estran-
geira: isso se dá quando todas as colunas de chave primária da 
tabela formam uma única chave estrangeira. Assim, teremos a 
especialização da referida entidade (tabela).
III. Outros casos: se dão no momento em que as regras 1 e 2 
não necessitam ser implementadas, e, assim, a tabela é consi-
derada uma entidade.
Na etapa 2, será realizado o tratamento para as chaves estran-
geiras que não se enquadrarem nas regras 1 e 2 referentes à 
etapa 1. O tratamento se dará da seguinte maneira:
• As que possuírem colunas que não fazem parte da chave pri-
mária.
• Também aquelas que façam parte de uma determinada chave 
primária e a referida chave primária não possua outras chaves 
estrangeiras, e sim colunas que não são chaves estrangeiras.
A etapa 3 faz referência à coluna que não é uma chave estran-
geira. Dessa forma, é definido um respectivo atributo na enti-
dade e/ou relacionamento na tabela “responsável” da coluna. 
Temos a divisão nos seguintes moldes:
• A coluna da chave primária que não é uma chave estrangei-
ra: é considerada como um atributo identificador da entidade 
(tabela) e/ou relacionamento a coluna que fizer parte da chave 
primária e que não seja uma chave estrangeira.
• A coluna da chave primária que é uma chave estrangeira: é 
considerada como um atributo identificador externo da enti-
dade (tabela) a coluna que fizer parte da chave primária e que 
seja também a chave estrangeira.
Na etapa 4, já se entende que o modelo conceitual abrange a 
conformidade das relações existentes entre as entidades ma-
peadas. Sempre haverá a relação entre as entidades, e os rela-
cionamentos serão o elo de ligação entre elas.
Identificação do 
modelo entidade-
relacionamento 
correspondente a 
cada tabela existente.
Mapeamento real dos 
relacionamentos 1:n e 
1:1 que se darão entre 
as tabelas.
 Mapeamento 
assertivo dos atributos 
de cada tabela.
Definição assertiva 
dos identificadores 
de entidades e de 
relacionamentos. 
117
A engenharia reversa em banco de dados traz uma série de vantagens: 
• Tende a facilitar a criação/manutenção da documentação do banco de dados. 
• Irá permitir a análise do sistema de informação. 
• Ajudará na manutenção do banco de dados.
• Permitirá o melhor entendimento do funcionamento do banco de dados.
• É possível recuperar as informações do banco de dados que tenham se perdido ao 
longo do tempo por falta da devida documentação.
3. Engenharia reversa para o banco de dados de BI (business 
inteligence)
Nos dias de hoje, com o grande volume de dados armazenados e a necessidade de se 
trabalhar fortemente com a mineração de dados por conta do crescimento do negócio, 
muitos bancos de dados de BI são criados dentro de um conceito e percebe-se, após 
algum tempo, que o seu crescimento orgânico não permite mais a modelagem correta. 
Como consequência, tem-se um banco de dados gigantesco sem a documentação 
adequada para a implementação dos relatórios necessários para os gestores, sejam eles 
novos ou não.
Uma solução para esse tipo de problema é o uso de repositórios de dados de BI. 
Esses repositórios são responsáveis por guardar os dados que serão necessários para 
as organizações apoiarem as tomadas de decisões pelos líderes dos negócios. Os 
repositórios de dados podem ser de quatro tipos:
• Big data.
• Data mart.
• ODS.• Data lake.
A criação dos repositórios de dados é incremental, isto é, o aumento de informações 
na base de dados é orgânico, acompanhando o crescimento da empresa e as diversas 
modificações de rumo conforme o negócio avança. Por outro lado, há um ponto de 
atenção. Modificações no planejamento estratégico da empresa ou modificações na 
equipe de analistas de BI, embora sejam ocorrências triviais, podem, de alguma forma, 
prejudicar a passagem de conhecimento da estrutura do repositório de dados de BI.
118
A complexidade do processo de ETL (tipo de integração de dados que se dá em três 
etapas — extração, transformação, carregamento — e é utilizado para combinar dados de 
diversas fontes, sendo muito usado para a construção de data warehouse), da modelagem 
dos dados e das constantes melhorias necessárias para o processo de BI faz com que, na 
maior parte das vezes, a documentação necessária seja deixada de lado e a transmissão 
do conhecimento ocorra na realização de workshops periódicos ou, simplesmente, em 
uma conversa.
Abaixo, algumas dicas para tratar a questão da engenharia reversa no BI:
• Separe os referidos assuntos dentro do seu banco de dados, assim você irá 
conseguir enxergar o relacionamento existente entre as tabelas e poderá trabalhar 
com minimodelos.
• É preciso identificar as tabelas que são corporativas, isto é, as tabelas que são 
utilizadas para cadastros e que são utilizadas em vários minimodelos.
• Saber fazer o aproveitamento da modelagem para identificar as melhorias no seu 
processo de ETL e fazer a documentação do ETL, assim podendo incluir a tabela de 
origem, a de transformação realizada e, por fim, a tabela de destino.
• Não permitir que a documentação pare. É preciso que haja uma atualização 
constante, isto é, o que irá mantê-la ativa e sempre pronta para a equipe e para os 
novos membros.
Existem ferramentas que facilitam o processo da engenharia reversa. O uso 
desse tipo de ferramenta é fundamental, pois tentar realizar tudo de forma 
manual, com prazo e qualidade, é humanamente impossível.
Dica
A seguir, entenda os aspectos legais que perpassam a engenharia reversa.
Aspectos legais
É preciso ter atenção com relação às questões legais, pois a engenharia reversa pode 
também trazer problemas de legalidade. Imagine uma empresa que tenha o desejo de 
criar uma cópia de um produto que tem muita aceitação no mercado, como, por exemplo, 
o Sistema SAP. Isso certamente, é um problema.
119
No entanto, a questão da legalidade irá variar de país para país. É sabido que há países 
que não fomentam nenhum ato de regulação sobre esse assunto.
O Digital Millennium Copyright Act dos Estados Unidos, que obteve sua aprovação no ano 
de 1998, trata, entre diversas medidas, da proteção dos direitos autorais na informática, 
e também faz algumas restrições no que tange à temática da engenharia reversa. A lei 
trata da permissão só para fins de análise de compatibilidade com outros softwares e/
ou hardwares.
Infelizmente, no Brasil, não há uma lei específica sobre a engenharia reversa. Caso haja a 
ocorrência da engenharia reversa, o padrão brasileiro trata o caso de duas formas: 
• Se a engenharia reversa não tiver como especificidade a questão da pirataria ou 
infração de algum direito autoral, não será considerado um crime. 
• Caso contrário, a Lei de Software e também a Lei dos Direitos Autorais protegerão 
seus autores.
MIDIATECA
Acesse a midiateca da Unidade 4 e veja o conteúdo complementar indicado 
pelo professor na mídia 1 sobre esse tema.
120
As três formas normais 
Introdução
A normalização de um banco de dados é muito importante para a construção do modelo 
físico do banco de dados. Veja um exemplo:
Imagine que um SGBD é construído com base no modelo relacional, tal como: 
Oracle e SQL Server. 
Isso significa que esse banco de dados obedece às regras definidas por Edgar 
Frank Codd, que foi o responsável pelo desenvolvimento do modelo de banco 
de dados relacional.
Exemplo
Na sua essência, a normalização dos dados é definida a partir de um conjunto de regras 
que determina a organização do banco de dados com o intuito de:
• Reduzir a redundância de dados.
• Garantir a integridade dos dados.
• Aprimorar o desempenho do banco de dados. 
Para que haja o processo de normalização do banco de dados, é preciso que sejam 
examinadas as colunas (atributos) de uma entidade e as relações existentes entre as 
entidades (tabelas), com o propósito de evitar irregularidades na inclusão, na exclusão e 
na alteração de registros em uma tabela.
Mesmo nos dias de hoje, ainda há muitos sistemas de informação rodando em empresas 
que ainda não utilizam banco de dados relacionais, esses sistemas são denominados de 
sistemas legados. Os dados oriundos desses sistemas são armazenados em arquivos 
e utilizam linguagens de terceira geração, como COBOL, PASCAL ou BASIC, ou, então, 
são armazenados em bancos de dados cujas características classificam-no como pré-
relacional.
121
Para que haja uma melhor adequação do banco de dados a ser projetado, é importante 
avaliar as cinco regras existentes, que são denominadas de formas normais. As formas 
normais são um conjunto de regras fundamentais para a simplificação e a adequação 
das tabelas a serem criadas no banco de dados. É dito que uma determinada tabela 
do banco de dados relacional está em uma certa forma normal quando ela satisfaz às 
condições exigentes. 
O trabalho original realizado por Edgar Frank Codd definiu três dessas formas, mas, 
atualmente, existem outras formas normais geralmente aceitas pelos desenvolvedores e 
pelos pesquisadores da área. 
Trataremos agora das três formas normais, em que cada uma delas representará uma 
condição mais forte das que a precedem na lista. Para a prática de mercado, considera-
se que, se as bases de dados estiverem normalizadas de forma adequada até a terceira 
forma normal, tem-se um cenário muito positivo para a utilização do banco de dados de 
forma íntegra.
A seguir, serão apresentadas as três primeiras formas normais.
Primeira forma normal - 1FN
A tabela na 1FN não pode conter tabelas aninhadas. Os atributos definidos na tabela 
precisam ser atômicos, ou seja, a tabela não pode conter valores repetidos nem atributos 
definidos que possuam mais de um valor. 
TABELA CLIENTE
ID + NOME + ENDEREÇO + BAIRRO + TELEFONES → São os atributos existentes 
da tabela CLIENTE.
CLIENTE = {ID + NOME + ENDEREÇO + BAIRRO + TELEFONES}. 
Porém, sabemos que uma pessoa qualquer poderá ter mais de um número 
de telefone (seja residencial, comercial e/ou celular), dessa forma o atributo 
“TELEFONES” é tido como “multivalorado” (possui mais de uma informação).
Para normalizar a tabela CLIENTE, é preciso:
Exemplo
122
CLIENTE
ID
ID
ID_TEL
1
1
1
2
3
1
1
Nome
Nome
CLIENTE_ID
Pedro
Pedro
1
1
1
Pedro
Pedro
Endereço
Endereço
TELEFONES
Rua Salvador, 36
Rua Salvador, 36
34788709
24789032
988764510
Rua Salvador, 36
Rua Salvador, 36
Bairro
Bairro
Méier
Méier
Méier
Méier
Telefones
34788709
24789032
988764510
TELEFONEPossui
1. Identificar qual é a chave primária da tabela e também qual coluna possui os 
dados repetidos (nesse caso é o atributo “TELEFONES”) e remover o atributo 
“TELEFONES” da tabela CLIENTE.
2. Construir uma nova tabela levando para ela o atributo em questão, 
“TELEFONES”. Mas não podemos nos esquecer que é preciso que haja uma 
relação entre a tabela CLIENTE e a nova tabela que está sendo criada. Para 
isso, o atributo ID da tabela CLIENTE será criado também na nova tabela e será 
considerado uma chave estrangeira.
Definição das duas tabelas: 
CLIENTE = {ID (chave primária) + ENDEREÇO} e 
TELEFONE (nova tabela) = {ID_TEL (chave primária) + CLIENTE_ID (chave 
estrangeira) + TELEFONE}.
TABELA CLIENTE (não normalizada)
Tabelas normalizadas na 1FN
CLIENTE
CLIENTE
123
Segunda forma normal - 2FN
Para que haja a segunda forma normal é fundamental que as regras da primeira 
forma normal estejam dentro do padrão. Nãoé possível ter a 2FN sem que haja 
a 1FN. 
Importante
A 2FN determina que os atributos normais da tabela, ou seja, aqueles que não são chaves, 
devem depender exclusivamente da chave primária da tabela. Dessa forma, as colunas 
que não são dependentes da chave primária devem ser imediatamente removidas da 
tabela principal. Além disso, é preciso criar uma nova tabela para realocar esses dados. 
Veja o exemplo abaixo:
TABELA PROFESSOR
ID_PROF + ID_CURSO + SALARIO + DESCRICAO_CURSO → São os atributos 
existentes da tabela PROFESSOR.
PROFESSOR = {ID_PROF + CURSO_ID + SALARIO + DESCRICAO_CURSO}
Fazendo uma análise da tabela, é possível constatar que o atributo “DESCRICAO_
CURSO” não depende unicamente da chave primária “ID_PROF” da tabela 
PROFESSOR, mas pertence somente ao conteúdo da chave “CURSO_ID”.
Para normalizar a tabela PROFESSOR, é preciso:
1. Identificar os dados que não são dependentes da chave primária da tabela 
PROFESSOR (nesse caso é o atributo “DESCRICAO_CURSO”) e remover da 
tabela PROFESSOR.
2. Criar uma nova tabela de nome CURSO e reorganizar os atributos nas duas 
tabelas com os referidos dados: 
a. PROFESSOR = {ID_PROF (chave primária) + CURSO_ID (chave estrangeira) 
+ SALARIO}.
b. CURSOS (nova tabela) = {CURSO_ID (chave primária) + DESCRICAO_CURSO}.
Exemplo
124
PROFESSOR
ID_PROF
CURSO_ID
ID_PROF
847
1
847
2
847
3
847
847
847
CURSO_ID
DESCRIÇÃO_CURSO
CURSO_ID
01
Ciência da Computação
01
Sistemas de Informação
02
Gestão da Tecnologia da Informação
03
02
02
SALÁRIO
SALÁRIO
400,00
400,00
1.100,00
2.689,99
1.100,00
2.689,99
DESCRIÇÃO_CURSO
Ciência da Computação
Sistemas de Informação
Gestão da Tecnologia da 
Informação
CURSOLeciona
TABELA PROFESSOR (não normalizada)
Tabelas normalizadas na 2FN
TABELA PROFESSOR
TABELA CURSO
125
Para que haja a 3FN é preciso que, antes, a 2FN tenha sido atendida na sua 
plenitude de acordo com as regras de normalização.
Importante
Terceira forma normal - 3FN
A 3FN tem por definição que todos os atributos da tabela devem ser mutuamente 
independentes uns dos outros, ao mesmo tempo eles precisam ser dependentes 
exclusivamente da chave primária da tabela. A 3NF foi projetada com o objetivo de 
melhorar o desempenho de processamento dos dados no referido banco de dados e 
assim minimizar os custos do armazenamento de informações. Veja dois exemplos de 
aplicação dessa regra:
TABELA FUNCIONARIO
ID + NOME + VALOR_SALARIO + VALOR_FGTS → São os atributos existentes 
da tabela FUNCIONARIO.
FUNCIONARIO = {ID + NOME + VALOR_SALARIO + VALOR_FGTS}
Na análise do cenário, podemos constatar que o valor do FGTS (atributo VALOR_
FGTS) é proporcional ao salário, logo esse atributo normal caracterizado de 
“VALOR_FGTS” é dependente do também atributo normal “VALOR_SALARIO”. 
Podemos constatar, ainda, que o valor do FGTS (calculado com base no salário) 
é um campo que depende do valor do SALARIO e não há qualquer ligação com 
a chave ID da tabela FUNCIONARIO.
Um outro ponto também a ser visto é se não há a existência de dependências 
transitivas ou indiretas. Uma dependência funcional transitiva ou indireta 
acontece quando uma determinada coluna, que não é chave primária, depende 
funcionalmente de outra coluna ou combinação de colunas que não sejam 
chaves primárias.
Para normalizar a tabela FUNCIONARIO, é preciso:
Exemplo 1
126
ID
ID
84716
84716
84717
84718
84717
84718
NOME
NOME
Carlos Augusto
Carlos Augusto
João Pedro
Marcos Paulo
João Pedro
Marcos Paulo
VALOR_SALÁRIO
VALOR_SALÁRIO
3.400,00
3.400,00
7.100,00
2.479,00
7.100,00
2.479,00
VALOR_FGTS
456,10
893,62
507,84
TABELA FUNCIONÁRIO (não normalizada)
Tabelas normalizadas na 2FN
1. Fazer a identificação dos dados dependentes de outros (nesse caso o 
atributo é o “VALOR_FGTS”).
2. Remover esse atributo da tabela FUNCIONARIO. O atributo “VALOR_FGTS” 
poderia ser definitivamente excluído e poderia ser deixado para a camada de 
negócio a responsabilidade pela execução de seu cálculo ou, quem sabe, ser 
direcionado para uma nova tabela e referenciar a principal (FUNCIONARIO).
Exemplo 2
COD_EMP
84716
84717
84718
NOME
Carlos Augusto
João Pedro
Marcos Paulo
CATEGORIA
01
02
03
SALARIO
5.900,00
3.200,00
6.679,00
TABELA EMPREGADO (já na 2FN)
127
COD_CAT
COD_EMP
01
84716
02
84717
03
84718
SALÁRIO
NOME
5.900,00
01
3.200,00
02
6.679,00
03
CATEGORIA SALARIO
01 5.900,00
02 3.200,00
03 6.679,00
Tabelas normalizadas na 3FN
TABELA EMPREGADO (já está na 2FN)
TABELA CATEGORIA
Observe que o atributo categoria passa a ser uma chave estrangeira.
MIDIATECA
Acesse a midiateca da Unidade 4 e veja o conteúdo complementar indicado 
pelo professor na mídia 2 sobre esse tema.
128
Forma normal Boyce-Codd 
Forma normal Boyce-Codd - FNBC
Para que essa forma normal seja atingida será necessário que não exista 
nenhuma dependência funcional não trivial de atributos em algo mais do que 
um superconjunto de uma chave candidata. Nessa fase, todos os atributos são 
dependentes de uma determinada chave, de uma chave inteira e de nada mais 
que uma chave.
É também considerada uma forma mais rígida da 3FN, pois trata de um tipo de 
atributo não considerado em outras formas normais: a chave candidata.
Importante
A chave candidata é aquela que é um atributo ou um conjunto de atributos de 
uma determinada tabela que identifica uma única linha na referida tabela. A chave 
primária é extraída a partir do conjunto de chaves candidatas de uma tabela.
Dica
Considerando o que foi exposto, é lógico ter a linha de pensamento em FNBC, quando:
• Uma determinada tabela tem várias chaves candidatas.
• Chaves candidatas serão compostas.
• Chaves candidatas se sobrepõem.
129
Outra definição de chave candidata é um identificador único que garante que nenhuma 
tupla (linha da tabela com informações dos dados referentes aos atributos) seja duplicada. 
Isso permitirá que seja criado um relacionamento em algo denominado multiconjunto, 
porque viola a definição básica de um conjunto. Já sabemos que uma chave pode ser 
composta, ou seja, formada por vários atributos. As chaves compostas ocorrem quando, 
em uma relação, existe mais de uma combinação de atributos para a identificação única 
do registro. Veja um exemplo:
Considere os seguintes dados: matrícula, CPF, RG, título de eleitor.
TABELA AULA
{Aluno, Curso} → Docente
Docente → Curso
Observe que não há dependência funcional transitiva, mas há uma 
dependência funcional em que os atributos da chave candidata {Aluno, Curso} 
não são determinantes.
Verificamos no contexto acima que:
• Há duas chaves candidatas: (Aluno, Curso), (Aluno, Docente).
• Se a chave primária escolhida for (Aluno, Curso), a tabela está na 3FN.
• Se a chave primária escolhida for (Aluno, Docente), a tabela está na 3FN.
• Contudo, tem-se uma DF que não possui chave candidata: 
 > Docente – Curso.
Exemplo 
João Pedro
Marco Cesar
Carlos Souto
Marcelo Pereira
Carla Cristina
Banco de Dados
Algoritmos
Banco de Dados
Estrutura de Dados
Banco de Dados
Carlos Rosa
Marcelo Sereno
Carlos Rosa
Maria Paula
Carlos Rosa
Aluno Curso Docente
130
• Se uma tabela estiver na FNBC, também estará na 3FN, mas o inverso 
não necessariamente poderá ser verdadeiro.
Algumas anomalias podem ser percebidas:
• Como se dá a inserção de um novo docente na tabela anterior?
• Se Marcelo Sereno deixa de ser professor é provável que qualquer menção 
a Algoritmos seja perdida.
A solução pode ser decompor as tabelas, criando-se tabelas que mantenham 
as chaves candidatas isoladas de alguma forma. Acompanhe:
Temos duas chaves candidatas definidas: (Aluno, Curso), (Aluno, Docente)
Se a chave primária for (Aluno, Curso), a relação está em 3FN. Se a chave 
primária for (Aluno, Docente), a relação também está em 3FN. Em ambos os 
casos, a relação não está em FNBC porque o determinante “Docente” não é 
uma chave candidata.
Esse cenário poderá gerar anomalias no momento da relação entre as tabelas:
• (Aluno,Docente) e (Aluno, Curso)
• (Curso, Docente) e (Curso, Aluno)
A melhor solução seria:
• (Docente, Curso) e (Docente, Aluno)
Violou a FNBC
Chave Candidata escolhida
Agora, veja como é o processo para obtenção da FNBC:
1. Identificar as dependências funcionais que violem a FNBC.
2. Para cada dependência funcional encontrada em 1, criar uma relação com a 
chave primária igual ao determinante.
3. As colunas que possuem seu valor determinado em 1 são excluídas da 
relação original.
131
TABELA AULA - ORIGINAL
Tabela normalizada na FNBC
TABELA ENSINO
TABELA LECIONA
Aluno
Aluno Docente
João Pedro
João Pedro
Marco Cesar
Marco Cesar
Carlos Souto
Carlos Souto
Marcelo Pereira
Marcelo Pereira
Carla Cristina
Carla Cristina
Curso
Banco de Dados
Algoritmos
Banco de Dados
Estrutura de Dados
Banco de Dados
Docente
Carlos Rosa
Carlos Rosa
Marcelo Sereno
Marcelo Sereno
Carlos Rosa
Carlos Rosa
Maria Paula
Maria Paula
Carlos Rosa
Carlos Rosa
Curso
Banco de Dados
Algoritmos
Banco de Dados
Estrutura de Dados
Banco de Dados
Docente
Carlos Rosa
Marcelo Sereno
Carlos Rosa
Maria Paula
Carlos Rosa
132
Na sequência, conheça mais duas formas normais.
Quarta forma normal - 4FN
Para que a quarta forma normal seja atingida é necessário que não exista 
nenhuma dependência multivalorada não trivial de conjuntos de atributo em 
algo mais do que um superconjunto de uma chave candidata.
A dependência multivalorada ocorre quando:
Um determinado atributo B tem múltiplas dependências de outro atributo A, 
se um valor do atributo A é associado a uma coleção de valores do atributo B.
Assim, podemos dizer que B é multidependente de A, representado dessa 
forma: (A→→B).
Importante
Uma relação estará na 4FN se não houver dependências multivaloradas nessa tabela.
Porém, o que é uma dependência multivalorada? Saiba mais a seguir.
Na sequência, acompanhe um exemplo de aplicação da 4FN.
Saiba mais
133
TABELA RELACAO_VENDA
ID_Vendedor → → {ID_Cliente, Nome_Cliente}
ID_Vendedor → → {Nome_Parente, Parentesco}
Para que uma tabela atenda à 4FN, é importante seguir as seguintes regras:
• Para cada grupo de repetição separado, gera-se uma nova relação 
correspondente contendo esse grupo de repetição e a chave primária da 
relação original.
• Determinar a chave primária da nova relação, a qual será a concatenação 
da chave primária da relação original com a chave para o grupo de 
repetição.
Observe as tabelas abaixo e suas relações:
Exemplo 
ID_VENDEDOR
1 100
1 100
2 101
3 102
ID_CLIENTE NOME CLIENTE NOME 
PARENTE
PARENTESCO
Carlos Lopes João Carlos Irmão
Carlos Lopes Marta Ceara Prima
Pedro Paulo Cesar Pires Irmão
Carla Souto Paulo Alcantara Pai
ID_VENDEDOR NOME_VENDEDOR
1
2
3
Cezar Rabelo
Roberto Ramos
Bruno Prado
TABELA VENDEDOR
134
ID_VENDEDOR
1 100
1 100
2 101
3 102
ID_CLIENTE NOME CLIENTE
Carlos Lopes
Carlos Lopes
Pedro Paulo
Carla Souto
TABELA VENDA
TABELA PARENTESCO
Se uma relação está na 4FN, então necessariamente está na FNBC.
ID_VENDEDOR
1
1
2
3
NOME PARENTE PARENTESCO
João Carlos Irmão
Marta Ceara Prima
Cesar Pires Irmão
Paulo Alcantara Pai
MIDIATECA
Acesse a midiateca da Unidade 4 e veja o conteúdo complementar indicado 
pelo professor na mídia 3 sobre esse tema.
135
NA PRÁTICA
Uma empresa da área de transporte aéreo recém-adquirida ainda trabalhava 
com um sistema antigo e com uma estrutura de arquivo que dificultava sua 
situação. Até em função da falta de tecnologia empregada, a empresa foi 
vendida para uma companhia aérea muito maior. 
A empresa compradora solicitou a presença do seu analista de TI para que 
verificasse a questão e pudesse apresentar um cenário melhor da estrutura de 
arquivo. O analista responsável prontamente fez uma análise e já desmembrou 
a tabela principal aplicando a primeira forma normal para poder entender melhor 
o que tinha em mãos e para que pudesse mais à frente fazer a integração com 
sua base de dados.
Como resultado de sua análise, ele apresentou:
folha¬_¬voo (num, data, destino, hora¬_saída, data_chegada, id_tripulante, 
cargo) 
Aplicando a 1FN:
folha¬_¬voo (num, data, destino, hora¬_saída, data¬_chegada)
tripulantes_voo (num_¬folha¬voo, id_tripulante, cargo)
136
Resumo da Unidade 4
Nesta unidade, você estudou a importância dos conceitos existentes em um processo de 
normalização de banco de dados.
Além do processo de criação do diagrama de classes e/ou modelo entidade-relacionamento, 
o processo de normalização, dentro do âmbito do modelo físico, proporciona a completa 
integridade e relação entre as tabelas existentes. Dessa forma, é possível garantir mais 
velocidade e integridade dos dados no processo de relacionamento das informações. 
Assim, tem-se a convicção de que as informações atenderão na íntegra o que se espera 
de um excelente banco de dados modelado.
Bons estudos!
CONCEITO
Ao longo desta unidade foram trabalhados três importantes conceitos, 
conforme descrito a seguir:
A engenharia reversa tem como missão a realização de uma atividade que 
trabalhe com demandas de produtos que já estejam sendo executados 
(softwares, tabelas, periféricos, placas de computador etc.), em que o grande 
desafio será entender como esse software/produto tem o seu mecanismo de 
funcionamento, o que ele exerce e como ele se comporta. 
A normalização de um banco de dados é muito importante para a construção 
do modelo físico do banco de dados. Na sua essência, a normalização dos 
dados é definida a partir de um conjunto de regras que determina a organização 
do banco de dados com o intuito de:
• Reduzir a redundância de dados.
• Garantir a integridade dos dados.
• Aprimorar o desempenho do banco de dados. 
137
As formas normais são um conjunto de regras fundamentais para a 
simplificação e a adequação das tabelas a serem criadas no banco de dados. 
É dito que uma determinada tabela do banco de dados relacional está em uma 
certa forma normal quando ela satisfaz às condições exigentes.
138
Referências 
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. São Paulo: Pearson, 2005. 
Biblioteca Virtual.
MACHADO, F. N. R. Projeto e Implementação de banco de dados. 3. ed. São Paulo: Éri-
ca, 2014. Minha Biblioteca.
MEDEIROS, L. F. de. Banco de Dados: princípios e prática. Curitiba: Intersaberes, 2013. 
Biblioteca Virtual.
VICCI, C. Banco de Dados. São Paulo: Pearson, 2015. Biblioteca Virtual.