21-Banco de Dados I PDF

BANCO DE DADOS I
BANCO DE DADOS I
FACULDADE CAPIXABA DA SERRA/EAD

Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
SUMÁRIO 1
BANCO DE DADOS I
GRUPO A Faculdade Multivix está presente de norte a sul

do Estado do Espírito Santo, com unidades em
MULTIVIX Cachoeiro de Itapemirim, Cariacica, Castelo, Nova
Venécia, São Mateus, Serra, Vila Velha e Vitória.
Desde 1999 atua no mercado capixaba, des-
tacando-se pela oferta de cursos de gradua-
ção, técnico, pós-graduação e extensão, com
qualidade nas quatro áreas do conhecimen-
to: Agrárias, Exatas, Humanas e Saúde, sem-
pre primando pela qualidade de seu ensino
e pela formação de profissionais com cons-
ciência cidadã para o mercado de trabalho.
Atualmente, a Multivix está entre o seleto

grupo de Instituições de Ensino Superior que
possuem conceito de excelência junto ao
Ministério da Educação (MEC). Das 2109 institui-
ções avaliadas no Brasil, apenas 15% conquistaram
notas 4 e 5, que são consideradas conceitos
de excelência em ensino.
Estes resultados acadêmicos colocam

todas as unidades da Multivix entre as
melhores do Estado do Espírito Santo e
entre as 50 melhores do país.
MISSÃO
Formar profissionais com consciência cida-

dã para o mercado de trabalho, com ele-
vado padrão de qualidade, sempre mantendo a
credibilidade, segurança e modernidade, visando
à satisfação dos clientes e colaboradores.
VISÃO
Ser uma Instituição de Ensino Superior reconheci-

da nacionalmente como referência em qualidade
educacional.

2 SUMÁRIO
BANCO DE DADOS I
EDITORIAL
FACULDADE CAPIXABA DA SERRA • MULTIVIX
Diretor Executivo Revisão de Língua Portuguesa

Tadeu Antônio de Oliveira Penina Leandro Siqueira Lima
Diretora Acadêmica Revisão Técnica

Eliene Maria Gava Ferrão Penina Alexandra Oliveira
Alessandro Ventorin
Diretor Administrativo Financeiro Graziela Vieira Carneiro
Fernando Bom Costalonga
Design Editorial e Controle de Produção de Conteúdo
Diretor Geral Carina Sabadim Veloso
Helber Barcellos da Costa Maico Pagani Roncatto
Ednilson José Roncatto
Diretor da Educação a Distância Aline Ximenes Fragoso
Pedro Cunha Genivaldo Félix Soares
Conselho Editorial Multivix Educação a Distância

Eliene Maria Gava Ferrão Penina (presidente Gestão Acadêmica - Coord. Didático Pedagógico
do Conselho Editorial) Gestão Acadêmica - Coord. Didático Semipresencial
Kessya Penitente Fabiano Costalonga Gestão de Materiais Pedagógicos e Metodologia
Carina Sabadim Veloso Direção EaD
Patrícia de Oliveira Penina Coordenação Acadêmica EaD
Roberta Caldas Simões
BIBLIOTECA MULTIVIX (Dados de publicação na fonte)
Costa, Charles Edward.

Banco de Dados I /Charles Edward Costa. – Serra: Multivix, 2018.
Catalogação: Biblioteca Central Anisio Teixeira – Multivix Serra

2018 • Proibida a reprodução total ou parcial. Os infratores serão processados na forma da lei.
As imagens e ilustrações utilizadas nesta apostila foram obtidas no site: http://br.freepik.com

SUMÁRIO 3
BANCO DE DADOS I
APRESENTAÇÃO Aluno (a) Multivix,
DA DIREÇÃO Estamos muito felizes por você agora fazer parte

do maior grupo educacional de Ensino Superior do
EXECUTIVA Espírito Santo e principalmente por ter escolhido a

Multivix para fazer parte da sua trajetória profissional.
A Faculdade Multivix possui unidades em Cachoei-

ro de Itapemirim, Cariacica, Castelo, Nova Venécia,
São Mateus, Serra, Vila Velha e Vitória. Desde 1999,
no mercado capixaba, destaca-se pela oferta de
cursos de graduação, pós-graduação e extensão
de qualidade nas quatro áreas do conhecimento:
Agrárias, Exatas, Humanas e Saúde, tanto na mo-
dalidade presencial quanto a distância.
Além da qualidade de ensino já comprova-

da pelo MEC, que coloca todas as unidades do
Grupo Multivix como parte do seleto grupo das
Instituições de Ensino Superior de excelência no
Brasil, contando com sete unidades do Grupo en-
tre as 100 melhores do País, a Multivix preocupa-
-se bastante com o contexto da realidade local e
com o desenvolvimento do país. E para isso, pro-
cura fazer a sua parte, investindo em projetos so-
ciais, ambientais e na promoção de oportunida-
des para os que sonham em fazer uma faculdade
de qualidade mas que precisam superar alguns
obstáculos.
Prof. Tadeu Antônio de Oliveira Penina
Diretor Executivo do Grupo Multivix Buscamos a cada dia cumprir nossa missão que é:
“Formar profissionais com consciência cidadã para o
mercado de trabalho, com elevado padrão de quali-
dade, sempre mantendo a credibilidade, segurança
e modernidade, visando à satisfação dos clientes e
colaboradores.”
Entendemos que a educação de qualidade sempre

foi a melhor resposta para um país crescer. Para a
Multivix, educar é mais que ensinar. É transformar o
mundo à sua volta.
Seja bem-vindo!

4 SUMÁRIO
BANCO DE DADOS I
APRESENTAÇÃO DA DISCIPLINA
Caro (a) aluno (a) seja bem-vindo(a) a disciplina Banco de Dados.
Ao lado da programação e desenvolvimento de sistemas, o banco de dados é uma

peça essencial de qualquer aplicação/programa. Atualmente, vivemos em um ce-
nário de constante troca e compartilhamento de informação, que acontece por
meio dos mais diferentes tipos de dispositivos de hardware. Podemos citar aplica-
ções desktop operando em computadores pessoais e também aplicações diversas
em nosso cotidiano com a utilização de smartphones e tablets. O profissional de
tecnologia, membro de uma equipe de desenvolvimento, precisa demonstrar do-
mínio em assuntos diversos ligados a banco de dados. Na disciplina de banco de
dados I é proposto o primeiro contato com essa maravilhosa tecnologia e espera-se
a absorção de conceitos básicos como: a arquitetura de banco de dados, introdução
e práticas em um SGBD relacional como o mundialmente consagrado MySQL. Nas
unidades mais avançadas deste material introduziremos como se dá a modelagem
de dados em diversos níveis, como são realizados os procedimentos de criação e
manipulação de banco de dados utilizando para isso o padrão SQL. Veremos de
forma objetiva questões de normalização, visões, transações e na última unidade de
estudo, faremos uma introdução de banco de dados distribuídos. É importante que
você sempre consulte a bibliografia deste material, além da participação ativa nos
fóruns de discussão. Bons estudos!
Ao final desta disciplina, esperamos que você:
• Descreva conceitos básicos de banco de dados como a arquitetura de um sistema

de banco de Dados e usuário de Banco de Dados.
• Narre a modelagem de Dados e os modelos: relacional, hierárquicos e de redes.
• Aplique o básico de SQL - linguagem de definição e manipulação de dados.
• Descreva sobre projeto de banco de dados Relacional, dependência Funcional e

chaves.
• Discuta a normalização, visões e integração de visões.
• Descreva o que são transações em banco de dados.
• Esclareça o que são banco de dados distribuídos.

SUMÁRIO 5
BANCO DE DADOS I
LISTA DE FIGURAS
>>FIGURA 1 - Palavras 15
>>FIGURA 2 - Representação de um sistema de banco de dados 17
>>FIGURA 3 - Entidades e atributos 20
>>FIGURA 4 - Tipos diferentes de atributos 21
>>FIGURA 5 - Tipos diferentes de atributos 22
>>FIGURA 6 - Relacionamento entre duas entidades 22
>>FIGURA 7 - Relacionamento UM para UM 23
>>FIGURA 8 - Relacionamento UM para N 24
>>FIGURA 9 - Explicação do relacionamento UM para N 24
>>FIGURA 10 - Relacionamento N para N 25
>>FIGURA 11 - Exemplo de modelo entidade-relacionamento (MER) 26
>>FIGURA 12 - Administrador de banco de dados 26
>>FIGURA 13 - Modelo de rede 32
>>FIGURA 14 - Modelo hierárquico 33
>>FIGURA 15 - Tabela no modelo relacional 36
>>FIGURA 16 - Tabela populada 36
>>FIGURA 17 - Tabela populada 38
>>FIGURA 18 - Evidenciando a chave estrangeira 39
>>FIGURA 19 - MER com cardinalidade 1 para 1 40
>>FIGURA 20 - MR com cardinalidade (1 para 1), apresentando dois casos 40
>>FIGURA 21 - Tabelas populadas do MR (1 para 1), apresentando dois casos 40
>>FIGURA 22 - MR (1 para N) e tabela populada 41
>>FIGURA 23 - Mapeando N para N cria-se nova tabela (Professores-Disciplinas) 42
>>FIGURA 24 - Tabelas populadas em cardinalidade N para N 42
>>FIGURA 25 - Ana (uma professora) leciona várias disciplinas 43
>>FIGURA 26 - Música (uma disciplina) é lecionada por vários professores 44
>>FIGURA 27 - Exemplo de MR representado de forma padronizada 45
>>FIGURA 28 - Comando CREATE TABLE explicado 51
>>FIGURA 29 - Comando CREATE TABLE com FK 52

6 SUMÁRIO
BANCO DE DADOS I
>>FIGURA 30 - Tabela Alunos sem normalização 65
>>FIGURA 31 - Alunos em 1FN 65
>>FIGURA 32 - Exemplo de instância da relação Alunos 68
>>FIGURA 33 - Tabela Aluno-Cursos 69
>>FIGURA 34 - Atendendo 2FN 70
>>FIGURA 35 - Tabela Alunos violando a 3FN 71
>>FIGURA 36 - Atendendo a 3FN 72
>>FIGURA 37 - Diagrama ER banco de dados didático - Ordem de serviço 84
>>FIGURA 38 - Dados populados nas tabelas físicas 85
>>FIGURA 39 - Exemplo de visão atualizável em somente uma tabela 88
>>FIGURA 40 - Exemplo de visão somente leitura 89
>>FIGURA 41 - Inserção em Visão 89
>>FIGURA 42 - Alteração de dados em Visão 89
>>FIGURA 43 - Removendo dados através de Visão 90
>>FIGURA 44 - Verificando engine da tabela cliente no MySQLWorkbench 99
>>FIGURA 45 - Abstração de banco de dados distribuídos 100

SUMÁRIO 7
BANCO DE DADOS I
LISTA DE TABELAS
>>QUADRO 1 - Principais problemas na utilização de sistemas de arquivos 18
>>QUADRO 2 - Comando CREATE TABLE explicado 51
>>QUADRO 3 - Tabela para exemplo de DF 67
>>QUADRO 4 - Exemplo de transação em pseudocódigo 96
>>QUADRO 5 - Formas de armazenamento de banco de dados distribuídos 101

8 SUMÁRIO
BANCO DE DADOS I
SUMÁRIO
UNIDADE 1 1 CONCEITOS BÁSICOS DE BANCO DE DADOS, ARQUITETURA E USUÁRIO 14

1.1 CONCEITOS BÁSICOS 14
1.1.1 DADO E INFORMAÇÃO 15
1.1.2 ARQUITETURA DE SISTEMA DE BANCO DE DADOS 16
1.1.3 SISTEMA GERENCIADOR DE BANCO DE DADOS 17
1.1.3.1 EXEMPLOS DE SGBD 19
1.2 ENTIDADE E ATRIBUTO 19
1.2.1 O QUE É ENTIDADE 20
1.2.2 O QUE É ATRIBUTO 20
1.2.3 TIPOS BÁSICOS DE ATRIBUTOS 21
1.3 RELACIONAMENTO E MER 22
1.3.1 CARDINALIDADE 23
1.4 USUÁRIOS DE BANCOS DE DADOS 26
CONCLUSÃO 28
UNIDADE 2 2 MODELOS DE DADOS: DE REDES, HIERÁRQUICO E RELACIONAL 31

2.1 MODELOS DE DADOS 31
2.1.1 MODELO DE REDE 32
2.1.2 MODELO DE DADOS HIERÁRQUICO 33
2.2 MODELO DE DADOS RELACIONAL 34
2.2.1 TABELAS 35
2.2.2 CHAVE PRIMÁRIA 37
2.2.3 CHAVE ESTRANGEIRA 38
2.3 MAPEAMENTO MER PARA MR 39
2.3.1 MAPEAMENTO 1 PARA 1 39
2.3.2 MAPEAMENTO 1 PARA N 41
2.3.3 MAPEAMENTO N PARA N 42
2.4 NOTAÇÕES PRÁTICAS 44
CONCLUSÃO 45

SUMÁRIO 9
BANCO DE DADOS I
UNIDADE 3 3 LINGUAGENS DE DEFINIÇÃO E

MANIPULAÇÃO DE DADOS. 47
3.1 LINGUAGENS DE DEFINIÇÃO E MANIPULAÇÃO 47
3.2 DEFINIÇÃO DE DADOS 48
3.2.1 CRIE PARA MIM SGBD! 49
3.2.2 ELIMINE O BANCO INTEIRO! 50
3.2.3 CRIE UMA TABELA! 50
3.2.4 ALTERE MINHA TABELA, POR GENTILEZA. 53
3.2.5 ELIMINE UMA TABELA 54
3.3 MANIPULAÇÃO DE DADOS 55
3.3.1 OPERADORES LÓGICOS 55
3.3.2 INSERIR NA TABELA! 56
3.3.3 SELECIONAR DE UMA TABELA! 57
3.3.4 ALTERAR DADOS DA TABELA! 58
3.3.5 APAGAR DADOS DA TABELA! 60
UNIDADE 4 4 NORMALIZAÇÃO EM PROJETOS DE BANCO DE DADOS 62

4.1 NORMALIZAÇÃO EM BANCO DE DADOS 62
4.1.1 A PRIMEIRA FORMA NORMAL 64
4.1.2 DEPENDÊNCIA FUNCIONAL 66
4.1.3 A SEGUNDA FORMA NORMAL 69
4.1.4 A TERCEIRA FORMA NORMAL 71
4.1.5 OUTRAS FORMAS NORMAIS 73
4.2 VISÃO GERAL DE UM PROJETO DE BANCO DE DADOS 74
CONCLUSÃO 76
UNIDADE 5 5 VISÕES EM BANCO DE DADOS 78

5.1 VISÕES 78
5.2 VANTAGENS DA UTILIZAÇÃO DE VIEWS 80
5.3 INTRODUÇÃO À CRIAÇÃO DE VIEWS 82
5.4 EXEMPLO DE CRIAÇÃO E UTILIZAÇÃO DE VIEWS 83
5.5 ATUALIZAÇÃO DE DADOS ATRAVÉS DE VIEWS 87
CONCLUSÃO 91

10 SUMÁRIO
BANCO DE DADOS I
UNIDADE 6 6 TRANSAÇÕES E BANCO DE DADOS DISTRIBUÍDOS 93

6.1 TRANSAÇÕES 93
6.1.1 PROPRIEDADES 94
6.1.2 SERVIÇOS DE TRANSPARÊNCIA 95
6.1.3 EXEMPLOS DE TRANSAÇÃO EM BANCO DE DADOS 96
6.2 BANCO DE DADOS DISTRIBUÍDOS 100
CONCLUSÃO 102
REFERÊNCIAS BIBLIOGRÁFICAS 103

SUMÁRIO 11
BANCO DE DADOS I
ICONOGRAFIA
ATENÇÃO ATIVIDADES DE
APRENDIZAGEM
PARA SABER
SAIBA MAIS
ONDE PESQUISAR CURIOSIDADES
LEITURA COMPLEMENTAR
DICAS
GLOSSÁRIO QUESTÕES
MÍDIAS
ÁUDIOS
INTEGRADAS
ANOTAÇÕES CITAÇÕES
EXEMPLOS DOWNLOADS

12 SUMÁRIO
BANCO DE DADOS I
UNIDADE 1
OBJETIVO
Ao final desta
unidade,
esperamos
que possa:
> Descrever a diferenciação

de dado e informação.
> Explicar a arquitetura de

um sistema de banco de
dados.
> Expressar o que é um SGBD

e conheça dois exemplos.
> Apontar o que é entidade,

atributo e relacionamento
em banco de dados.
> Relatar como se dá a

construção do modelo
entidade-relacionamento.
> Analisar quem são os

usuários de bancos de
dados.

SUMÁRIO 13
BANCO DE DADOS I
1 CONCEITOS BÁSICOS
DE BANCO DE DADOS,
ARQUITETURA E USUÁRIO
Nesta unidade, serão apresentados os conceitos básicos de dados, tais como, a arqui-
tetura de um sistema de banco de dados, SGBD e exemplos, conceitos importantes
de entidades, atributos, além da introdução de como acontece o relacionamento em
um banco de dados, sendo exemplificado com modelos simples de MER. Ao final será
abordado quem são os usuários em um banco de dados e seus papéis. Esperamos
que essa seja a base fundamental para guiar seus estudos nas próximas unidades.
1.1 CONCEITOS BÁSICOS
Realizar o armazenamento de dados se tornou uma necessidade essencial desde

o surgimento do homem. As informações devem ser armazenadas proporcionando
fácil acesso e, podemos dizer que os livros são exemplos de destaque como uma das
formas mais antigas de se realizar armazenamento de informações. A partir do avan-
ço tecnológico e da crescente necessidade de se armazenar grandes quantidades
de informações, houve o surgimento do arquivo em computadores. Nesse momento
também se levou em consideração formas de acesso às informações, além obvia-
mente de como armazená-las.
A forma como as informações eram armazenadas neste início foi denominada como
sistema de arquivos. Em sua concepção o acesso às informações era eficiente, mas a
partir do momento que houve um crescimento no número de informações, surgiram
problemas relacionados com a separação de dados e isolamento. Tais problemas
aconteciam na consulta de dados relacionados e na inserção deles, pois eram feitas
duplicidades, o que fazia com que as informações tivessem um crescimento signifi-
cativo. Neste cenário ocorria muita redundância, inconsistência de dados e também
problemas relacionados à segurança da informação.

14 SUMÁRIO
BANCO DE DADOS I
Podemos então pressupor que era necessário desenvolver uma forma mais inteligen-
te para realizar o armazenamento de dados, certo? Pois bem, foram pensadas formas
de se criar um banco que fizesse o armazenamento de dados, mas estruturado de
forma predefinida. Essa ideia tinha como premissa que os dados tivessem proprieda-
des definidas, apresentando lógica e coerência e acima de tudo que fossem criados
com propósitos determinados.
Surgiu então o que se entende como banco de dados. Nos próximos tópicos iremos
detalhar o significado de conceitos importantes na busca da melhor assimilação des-
se conhecimento.
1.1.1 DADO E INFORMAÇÃO
No cotidiano existe uma percepção equivocada em relação a dados significarem o

mesmo que informações. Existe uma diferença importante entre estes conceitos e
iremos exemplifica-lo de forma simples, veja o exemplo na figura 1.
FIGURA 1 - PALAVRAS
Fonte: Elaborado pelo autor
Analisando as palavras da figura 1, não conseguimos obter informações concretas a

não ser o significado de cada uma delas. Começou a entender a diferença entre dado
e informação? Podemos até imaginar que existe uma informação fazendo uma jun-

SUMÁRIO 15
BANCO DE DADOS I
ção dessas palavras: “a manga verde é uma fruta grande”. Mas podemos pensar tam-
bém que “na manga de uma camisa verde, existem estampas de frutas grandes”. Veja
que a mudança é o nível da abstração. O menor nível de abstração da informação é
um dado, sendo assim um fato apresentado em sua forma primária. Os dados geram
informação, que por sua vez fornecem o conhecimento.
Um dado isolado não tem significado relevante e não nos leva

a uma compreensão para gerar algum conhecimento ou nos
fazer tomar decisões. A informação por sua vez é uma forma
ordenada e organizada de dados com objetivo de transmissão
de significado, em um contexto.
Como são denominados os dados que descrevem um dado?

Estes são chamados metadados! Pesquise a respeito.
1.1.2 ARQUITETURA DE SISTEMA DE BANCO DE

DADOS
O armazenamento elaborado de informações existindo formas de consultas define o

que é um banco de dados. A estrutura de um banco de dados é constituída por um
modelo de dados e une recursos para armazenar e recuperá-los.
Um sistema de banco de dados é composto pelo banco da-

dos, um sistema de software para operá-lo (SGBD) e as aplica-
ções que fazem sua manipulação. Conforme figura 2.

16 SUMÁRIO
BANCO DE DADOS I
FIGURA 2 - REPRESENTAÇÃO DE UM SISTEMA DE BANCO DE DADOS
Fonte: CARDOSO, 2008.
No contexto de sistema de banco de dados, o sistema gerenciador de banco de da-

dos é um ator muito importante. Através dele são operacionalizadas diversas ações
do banco e também são organizadas as formas como os dados são armazenados. No
próximo tópico iremos detalhar o essencial sobre o SGBD – Sistema Gerenciador de
Banco de Dados.
1.1.3 SISTEMA GERENCIADOR DE BANCO DE DADOS
Antes de falarmos do SGBD iremos abordar rapidamente a diferença entre se utilizar

um sistema de banco de dados (como visto anteriormente) ou utilizar um sistema de
arquivos. Conforme quadro 1, a utilização de um sistema de arquivos traz vários pro-
blemas em comparação com o uso de sistemas gerenciadores de banco de dados.

SUMÁRIO 17
BANCO DE DADOS I
QUADRO 1 - PRINCIPAIS PROBLEMAS NA UTILIZAÇÃO DE SISTEMAS DE ARQUIVOS
CRITÉRIOS NO USO DE
PROBLEMAS IDENTIFICADOS
SISTEMAS DE ARQUIVOS
Ela quem manipula os dados e deve conter as
Quanto à aplicação desenvolvida informações do sistema de arquivos, existindo
com isso restrições.
É incorporada ao programa de acesso. Mudança
Quanto à estrutura dos dados na estrutura dos arquivos implica alterações no
código dos programas.
Não são garantidas propriedades corretas no
Quanto à redundância de dados gerenciamento dos dados. Ocorre redundância.
Mesma informação em arquivos distintos.
Existe dificuldade de acesso. Em cada consulta
Quanto ao acesso aos dados
de informação, é preciso escrever um programa.
Não fornece recursos para lidar com dados de
Quanto ao tipo de dado formatos diferentes incluídos em arquivos dife-
rentes.
Ocorrem problemas de consultas com resulta-
Quanto à integridade dos dados dos enganosos, nas relações entre informações
em arquivos distintos.
Fonte: Elaborado pelo autor. Adaptado de CARDOSO, 2008.
Um SGBD é um pacote de programas que compõe um sistema de banco de dados.

Sua utilização no gerenciamento de dados traz ao SBD (Sistema de banco de dados),
várias vantagens.
Um SBD é diferente de um SGBD, caso isso não tenha ficado

claro, revise os tópicos que estudamos anteriormente. Vamos
listar algumas vantagens da utilização de um SGBD em rela-
ção ao uso de sistemas de arquivos, veja:
• Um SGBD multiusuário permite que vários usuários acessem o banco

de dados simultaneamente.
• Prover formas complexas de relacionamento de dados
• Mantem o controle de concorrência.
• Fornece recursos para: recuperação de falhas (software e hardware).

sua manipulação. Conforme figura 2.

18 SUMÁRIO
BANCO DE DADOS I
1.1.3.1 EXEMPLOS DE SGBD
Até aqui já conseguimos absorver vários conceitos básicos, de forma ainda não apro-
fundada das premissas de banco de dados. Nas próximas unidades da disciplina serão
aprofundados os diversos conceitos de forma específica e exemplifica na prática. Va-
mos agora informar dois dos principais SGBD’s utilizados no mercado da computação.
• MySQL: É um sistema gerenciador de banco de dados (SGBD) adquirido em 2009

pela empresa Oracle. É mundialmente utilizado e considerado o mais popular en-
tre todos. Segundo do site do Mysql, na página “Why Mysql?” (Acesso em junho de
2018), aplicações como Facebook, Twitter e até o YouTube fazem uso do MySQL
em algum momento, em seus sistemas. O MySQL é um banco de dados relacional
e é operado utilizando a linguagem de SQL. Não se preocupe neste momento em
entender o que é bando de dados relacional e o que é a linguagem SQL.
Complete seus estudos entendendo mais a respeito do SQL

Server através do seu site oficial. Existem carreiras específicas
de desenvolvedores com certificações que envolvem o conhe-
cimento específico neste SGBD.
1.2 ENTIDADE E ATRIBUTO
É importante nesse momento de estudo, introduzir o que são os termos entidade e

atributo. Nas próximas unidades de estudo, trataremos da modelagem de dados e
será uma premissa a compreensão desses conceitos.

SUMÁRIO 19
BANCO DE DADOS I
1.2.1 O QUE É ENTIDADE
Em banco de dados, uma entidade é uma representação de

um objeto ou conceito do mundo que vivemos – mundo real.
Veja a conceituação na percepção da autora Virgínia Cardoso,
em seu livro Sistemas de Banco de Dados:
Para a conceituação de entidade, entende-se como

coisa ou objeto do mundo real que pode ser separada
ou distinguível de outro objeto. Nesse contexto, exem-
plificamos com uma entidade Livro, Carro e Pessoa
como entidade concreta, mas podemos encontrar en-
tidades abstratas como Viagens ou um Aluguel, Com-
pra ou um Empréstimo. Mesmo com essa classificação,
a representação é a mesma. (CARDOSO, 2008 p. 28)
1.2.2 O QUE É ATRIBUTO
Um atributo como o próprio nome nos remete é o termo formal das qualidades que
descrevem uma entidade, sendo estes específicos de cada entidade. Veja na figura 3,
a representação de duas entidades e alguns atributos.
FIGURA 3 - ENTIDADES E ATRIBUTOS

20 SUMÁRIO
BANCO DE DADOS I
Na representação da figura 3 existem duas entidades: alunos e viagem. Para cada

uma delas existem vários atributos, como o nome na entidade aluno e data de saída
na entidade viagem. Nota-se que podemos representar os atributos de duas formas,
utilizando elipses ou a representação pelo ícone de um ponto e seu nome. Quando
chegarmos ao estudo de modelos e a modelagem de banco de dados, essas duas
formas de notação podem ser apresentadas, mas a forma de elipse é sempre a mais
utilizada. Em relação à representação de entidades, por padrão sempre é utilizado
um retângulo contendo seu nome.
1.2.3 TIPOS BÁSICOS DE ATRIBUTOS
Existe uma particularidade em relação aos atributos. Eles podem ser representados
de acordo com seu tipo. Perceba na figura 3 atributos de diferentes tipos, tais como:
• Atributo simples.
• Atributo multivalorado.
• Atributo composto.
FIGURA 4 - TIPOS DIFERENTES DE ATRIBUTOS
Os atributos simples representam apenas um valor para cada elemento na entida-

de. O atributo multivalorado é a representação para elementos que possuem mais

SUMÁRIO 21
BANCO DE DADOS I
de um valor. O telefone é um exemplo: residencial, comercial etc. Neste caso, usa-se

apenas uma representação do atributo telefone, mas constando duas elipses na re-
presentação. Um atributo composto representa uma divisão entre outros atributos.
Sua representação é como uma árvore, assim como mostrado na figura 3.
Existe também o atributo-chave. Veja na figura 4 como ele é representado. O atribu-

to-chave informa que se trata de um atributo que não se repete na entidade. Perceba
que a matrícula na figura 4 é o atributo-chave da entidade alunos, onde ela é repre-
sentada de forma sublinhada. Ou seja, a matrícula é um dado único de cada registro
de aluno que temos nessa entidade.
FIGURA 5 - TIPOS DIFERENTES DE ATRIBUTOS
1.3 RELACIONAMENTO E MER
O relacionamento é a ligação estabelecida entre as entidades de um banco de da-

dos. Veja a figura 5 como é feita essa representação.
FIGURA 6 - RELACIONAMENTO ENTRE DUAS ENTIDADES

22 SUMÁRIO
BANCO DE DADOS I
Percebe-se no modelo da figura 5, que as entidades aluno e cursos se relacionam

com a representação de um losango entre eles, contendo o termo cursar interna-
mente a ele.
As representações de relacionamento sempre utilizam um

verbo, como falamos neste exemplo, o verbo cursar.ua mani-
pulação. Conforme figura 2.
1.3.1 CARDINALIDADE
Os relacionamentos possuem também a chamada cardinalidade. Isso significa o nú-

mero de vezes que uma entidade toma parte no relacionamento, e também expres-
sa possibilidades e restrições entre as entidades.
De forma prática: Quantas ocorrências em uma entidade podem estar associadas a

uma determinada ocorrência de outra.
Vamos entender como é representada a cardinalidade na prática. Entendemos a car-

dinalidade da seguinte forma:
• Um para Um.
• Um para N.
• N para Um.
Veja na figura 6 um exemplo de relacionamento de cardinalidade: um para um.
FIGURA 7 - RELACIONAMENTO UM PARA UM

SUMÁRIO 23
BANCO DE DADOS I
Perceba que o modelo ganhou números entre as ligações na figura 6. Nessa especi-
ficação, um professor ministra apenas uma disciplina. E não menos importante, uma
disciplina é ministrada apenas por um professor.
Em outra especificação, podemos ter que um professor que pode ministrar várias
matérias, e cada disciplina pode ser ministrada por um único professor. Veja o exem-
plo na figura 7.
FIGURA 8 - RELACIONAMENTO UM PARA N
Agora a letra N está ao lado da entidade disciplinas na figura 7. Ela informa que um
professor leciona várias disciplinas. É importante entender que a letra N ao lado da
entidade disciplinas remete a entidade professores, perceba isso na figura 8.
FIGURA 9 - EXPLICAÇÃO DO RELACIONAMENTO UM PARA N
Fonte: Adaptado de CARDOSO, 2008.

24 SUMÁRIO
BANCO DE DADOS I
As cores verde e azul foram inseridas na explicação da figura 8, para ajudar a você
associar como deve ser lido/entendido o relacionamento. Visualizando da esquerda
para direita (azul), estamos falando de professores em relação à disciplina, logo, da di-
reita para esquerda (verde), estamos falando de disciplinas em relação à professores.
Assimilar esse “movimento” pode facilitar sua compreensão entre entidades que tem
um contexto de relacionamento mais complexo.
Continuando nesse mesmo exemplo de relação entre professores e disciplinas, pode-

mos imaginar que cada professor ministra várias disciplinas e cada disciplina é minis-
trada por N professores. Um exemplo: a disciplina de banco de dados pode possuir
os professores João e José, e, além disso, João e José lecionarem outras disciplinas.
Perfeito, vamos representá-la na figura 9.
FIGURA 10 - RELACIONAMENTO N PARA N
Percebemos então, a representação de relacionamentos e cardinalidade. Com isso

conseguimos introduzir o que é o modelo entidade-relacionamento. Este modelo é
conhecido através da sigla MER. (A pronúncia é realizada soletrando as letras “M-E-R”
e não falando: “Mér”).
Segundo CARDOSO (2008), a denominação Diagrama de Entidade e Relacionamen-

to (DER), comumente remete ao diagrama que é usado para ilustrar sua representa-
ção gráfica.
Para solidificar este aprendizado, vamos exemplificar um MER envolvendo várias en-
tidades e relacionamentos. Perceba na figura 10.

SUMÁRIO 25
BANCO DE DADOS I
FIGURA 11 - EXEMPLO DE MODELO ENTIDADE-RELACIONAMENTO (MER)
Na representação da figura 9 podemos perceber diversas entidades se relacionando

umas com as outras, além de que cada entidade possui diversos atributos. Faça uma
reflexão no contexto desse exemplo de banco de dados. Exercite por exemplo dizen-
do para você mesmo: no relacionamento entre usuários e livros, um usuário reserva
um livro e um livro só pode ser reservado por um usuário. Assim por diante.
1.4 USUÁRIOS DE BANCOS DE DADOS

FIGURA 12 - ADMINISTRADOR DE BANCO DE DADOS
Fonte: SHUTTERSTOCK, 2018.

26 SUMÁRIO
BANCO DE DADOS I
Vários são os atores no contexto de manipulação de banco de dados. Os profissionais

que atuam diretamente com o banco de dados e diretamente com o sistema geren-
ciador de banco de dados (SGBD) se dividem entre:
• Administrador de banco de dados (DBA): Responsável pela administração de

recursos ligados ao banco de dados, como os dados em si e também o SGBD,
além de ser responsável por autorizar acessos e por coordenar e monitorar o uso
do banco de dados.
• Projetista de banco de dados: Responsável por identificar os dados que serão

armazenados no banco de dados, definindo estruturas corretas para realizar o
armazenamento. Também é responsabilidade do projetista, avaliar o que é neces-
sário para os grupos de usuários, fazendo com que o banco de dados seja capaz
de atender os requisitos de usuários.
• Analista de sistemas: O analista de sistema faz a determinação dos requisitos

dos usuários que esperam pelo serviço, e fazem também o desenvolvimento de
especificações para as transações atenderem a estes requisitos. Precisam ter co-
nhecimento sobre recursos do SGBD.
• Programadores: Desenvolvem as especificações realizadas pelo analista através

de programas. São responsáveis muitas vezes pelos testes, depuração, documen-
tação e manutenção. Assim como os analistas, precisam ter conhecimento sobre
recursos do SGBD.
Temos também os usuários finais no contexto de usuários de banco de dados. Este

não tem relação com as pessoas que atuam com a estrutura do banco de dados. Para
eles existem a formalização de três classificações:
• Usuários casuais: Estes realizam o acesso no banco de dados ocasionalmente,

mas podem também necessitar de diferentes tipos de informações a cada aces-
so que realizam. Para isso, utilizam linguagens de consulta para especificar suas
necessidades.
• Usuários novatos: Diferentemente dos usuários casuais, estes fazem uso de partes
predefinidas do banco de dados e consultas estabelecidas que já foram testadas.
• Usuários sofisticados: São familiarizados com o SGBD e realizam consultas complexas.

SUMÁRIO 27
BANCO DE DADOS I
A partir dessa divisão e classificação entre as pessoas que manipulam um banco de

dados, podemos perceber de forma clara que um sistema de banco de dados é um
fator fundamental dentro de uma aplicação, não somente a aplicação em si contra-
tada para desenvolvimento.
Uma curiosidade de carreira: Em relação aos usuários envol-

vidos no desenvolvimento das aplicações (e não usuários fi-
nais), muitas vezes nos deparamos com situações em que um
profissional desenvolve mais de uma função. Isso acontece co-
mumente entre analistas e desenvolvedores, onde na maioria das vezes
um mesmo profissional exerce ambos papéis. Isso deve ser encarado com
naturalidade (em perspectiva de mercado) quando se participa de equi-
pes de pequeno porte, pois diversos fatores externos a uma equipe de
desenvolvimento constituem essa realidade, podendo ser citado: o porte
da solução em questão, a maturidade de gestão empresarial da organiza-
ção que você trabalha e também os recursos financeiros que envolvem a
contratação de vários profissionais para atuar em um mesmo projeto. Ob-
serva-se também nesse sentido que muitos projetos podem ser contrata-
dos com premissa de investimento partindo do cliente que está contra-
tando a solução. Ou seja, um profissional técnico sempre precisa ter uma
visão mais abrangente do seu ambiente de trabalho, não só entre seus
pares diretos, mas também em relação aos seus gestores e o ambiente
macro que envolve a organização e o cliente. Visualize sempre outras pers-
pectivas, outros lados de uma mesma moeda. “Pense fora da caixa”!
CONCLUSÃO
Nesta unidade, você teve contato com os principais assuntos relacionados à introdu-
ção de banco de dados. Foi apresentada a diferenciação de dados e informação, o
que compõe um SBD, detalhando o sistema gerenciador de banco de dados. Vimos
como o banco de dados se apresenta e também foi apresentado o que é um modelo
entidade-relacionamento - MER e como ele é constituído. Detalhamos entidades,
atributos e seus tipos, além da abordagem objetiva de cardinalidade. Ao final foi visto

28 SUMÁRIO
BANCO DE DADOS I
também de forma breve os usuários envolvidos a cerca de um banco de dados.
Recomenda-se que seus estudos em banco de dados, sejam aprofundados com a

leitura dos livros da bibliografia básica e complementar deste material.
Na próxima unidade, trataremos da modelagem de dados e os modelos de dados:

relacional, hierárquicos e de Redes. Bons estudos!

SUMÁRIO 29
BANCO DE DADOS I
UNIDADE 2
OBJETIVO
Ao final desta
unidade,
esperamos
que possa:
> Analisar o modelo de

dados de rede.
> Analisar o modelo de

dados hierárquico.
> Definir o modelo

relacional.
> Identificar o que são

tabelas e chaves no
modelo relacional.
> Aplicar o
mapeamento entre
MER e MR.
> Apontar notações do

modelo relacional.

30 SUMÁRIO
BANCO DE DADOS I
2 MODELOS DE DADOS: DE
REDES, HIERÁRQUICO E
RELACIONAL
Caro aluno, seja bem-vindo à unidade que apresentará os modelos de dados, tais
como o modelo de rede e hierárquico, além do consagrado modelo relacional. Iremos
aprofundar no modelo relacional, apresentando diferenças entre o modelo entidade-
-relacionamento, e também como é realizado o mapeamento entre os dois modelos.
Ao final, serão abordadas, de forma objetiva, as notações básicas de representação
do modelo relacional. Esperamos que essa seja a base fundamental para guiar seus
estudos em conceitos do uso do modelo relacional, ao qual será amplamente tratado
até o final desta disciplina.
2.1 MODELOS DE DADOS
Anteriormente, já fizemos uma abordagem, inclusive prática, do modelo de entida-

de-relacionamento, e nesta unidade iremos abordar os modelos de rede, hierárquico
e o também o consagrado modelo relacional.
O modelo de dados é um conjunto de ferramentas que representa conceitos e des-

creve a estrutura lógica e física de um sistema de banco de dados.
O modelo tem por objetivo fornecer representação usando conceitos como objetos,
juntamente às suas propriedades. O modelo de dados tem uma classificação defini-
da conforme a seguir:
• Modelo classificado como alto nível.
• Modelo classificado como baixo nível.
No modelo de alto nível, temos uma proximidade maior do modo como o usuário
enxerga os dados em suas visões, conceitualmente. Já o modelo de baixo nível, é
denominado de modelo físico, pois expressa a forma mais detalhada em como os

SUMÁRIO 31
BANCO DE DADOS I
dados são armazenados realmente na máquina.
De acordo com os modelos já criados, até então no mercado de tecnologia, temos

modelos conceituais baseados em objetos, e os modelos conceituais baseados em
registros.
Como vimos, o modelo entidade-relacionamento é baseado em objetos. Diferente

do modelo entidade-relacionamento, os modelos de rede, hierárquico e relacional
são baseados em registros. O modelo relacional, como será focado bastante nos nos-
sos esforços daqui em diante, é um destaque na utilização para criação de banco de
dados corporativos em todos os níveis, atualmente.
Os modelos com base em registros são utilizados na descrição de dados e disponibi-

lizam recursos flexíveis.
Vamos entender a seguir dois modelos pouco utilizados no mercado atualmente:

modelo de dados de rede e depois o modelo hierárquico. Após, iremos entrar no es-
tudo do que realmente é usual nos dias de hoje, o modelo relacional.
2.1.1 MODELO DE REDE
O modelo de rede apresenta os dados como registros, como já informado diferente-

mente do modelo entidade-relacionamento. Conforme podemos perceber na Figura
1, nele os dados são relacionados através de links ou também chamados ponteiros.
FIGURA 13 - MODELO DE REDE
Fonte: Cardoso (2008, p. 22)

32 SUMÁRIO
BANCO DE DADOS I
Dessa forma, os dados são representados em conjuntos arbitrários de gráficos. Por ser
um modelo não tanto usual na realidade de análise e desenvolvimento comumente
empregado nas empresas atualmente, não iremos aprofundar em sua modelagem
ou conceituação mais avançada.
Você pode pesquisar mais a respeito deste modelo aces-

sando o site DevMedia, inserindo o termo: a história dos
bancos de dados.
2.1.2 MODELO DE DADOS HIERÁRQUICO
O modelo hierárquico teve sua utilização originalmente focada em mainframes. Nes-

se modelo, os registros são conectados através de uma estruturação em árvore. A
diferença entre o modelo de rede é que não são arbitrários conforme Figura 2.
FIGURA 14 - MODELO HIERÁRQUICO
Perceba que o modelo hierárquico parte de uma raiz, formando uma árvore. Da mes-
ma forma que o modelo de rede, apresenta registros na representação de dados e
links para demonstrar relacionamento.

SUMÁRIO 33
BANCO DE DADOS I
O sistema SABRE foi considerado o maior sucesso de uso desse

modelo, criado pela empresa IBM juntamente à American Air-
lines. O sistema SABRE foi implementado para reservas de pas-
sagens aéreas e permitiu que diversas pessoas fizessem acesso
os mesmos dados através de uma rede. É interessante notar que, atualmen-
te, o mesmo sistema SABRE é usado para disponibilizar serviços populares
de viagens baseados em ambiente Web. Podemos citar o Travelocity.
Assim como o modelo de rede, não iremos aprofundar nosso estudo nesse modelo
ou em sua forma de modelagem e aplicação. A seguir, você irá conhecer o modelo
que mudou a forma como os bancos de dados são organizados e desenvolvidos.
2.2 MODELO DE DADOS RELACIONAL
O modelo relacional, conhecido também apenas pela sigla MR, deu sequência ao
modelo hierárquico. Foi proposto, em 1970, por Edgar Codd, na IBM. Este modelo
se consolidou a partir de então como um marco na história de como os sistemas de
banco de dados deveriam ser desenvolvidos. O sucesso foi tanto que Codd ganhou,
em 1981, o prêmio Turing por originalidade em seu trabalho.
O modelo relacional é utilizado nos dias atuais e daqui em diante nosso estudo será
focado nele, em sua modelagem, forma de implementação lógica e meios de realizar
consultas através da linguagem SQL através de um SGBD MySQL.
Apesar de ser um modelo simples, com poucos conceitos, o modelo relacional é uma
ferramenta muito eficiente. Vimos que o modelo entidade-relacionamento apresenta
uma diagramação voltada a objetos do mundo real, utilizado em uma primeira fase
de concepção de um banco de dados, ou seja, uma primeira modelagem do projeto.
É importante entender que nada é perdido realizando uma modelagem entidade-

-relacionamento (MER) para então se fazer uma modelagem relacional (MR). O que
acontece é uma migração de um modelo para outro. Essa migração entre modelo
entidade-relacionamento e modelo relacional é denominada mapeamento.

34 SUMÁRIO
BANCO DE DADOS I
Apesar de estarmos apresentando a forma teórica de se traba-

lhar entre MER e MR, na prática corporativa de desenvolvi-
mento de softwares, muitas empresas adotam a modelagem
diretamente através do modelo relacional. É muito comum
no mercado, que equipes de desenvolvimento já realizem a criação de um
banco de dados diretamente no modelo relacional, utilizando, para isso
ferramentas CASE para modelagem de dados. Para isso usando fortemen-
te uma extensão da linguagem UML. Fique tranquilo! Você será iniciado
nessas ferramentas no decorrer desta disciplina.
Continuando com o modelo relacional, veja que se trata de um modelo com estru-
turas de tabelas.
O modelo relacional tem esse nome devido a relações mate-

máticas, especificamente relacionado à álgebra/cálculo rela-
cional e teoria de conjuntos, e não aos relacionamentos pro-
priamente ditos.
2.2.1 TABELAS
As tabelas em banco de dados relacionais são expressas assim como as conhecemos

no cotidiano, linhas na horizontal e colunas na vertical. A definição teórica, no entan-
to, nos informa que o modelo é composto por estruturação sintática.
Essa estruturação sintática significa que as tabelas também chamadas por relação,
possuem valores que são os dados do mundo real. Além dos valores, possuem linhas
denominadas como tuplas ou registros. As colunas são chamadas de campos ou atri-
butos. O conjunto dos atributos se chama esquema. Veja a seguir na Figura 3.
Observação: Tenho certeza que você está se lembrando do modelo entidade-relacio-

namento e visualizando o quanto mais simples é representar os dados no modelo
relacional, dessa forma.

SUMÁRIO 35
BANCO DE DADOS I
FIGURA 15 - TABELA NO MODELO RELACIONAL
Fonte: Elaborado pelo autor, adaptado de Cardoso (2008, p. 56)
As tabelas do modelo relacional apresentam valores atômicos. Não estamos falando

de química, apesar de significar que os valores devem ser indivisíveis. Dessa forma,
um valor de uma tupla não pode ser dividido internamente a ele mesmo. Um exem-
plo: O nome João Alberto é um valor da coluna Nome. Esse valor, nessa coluna, não
se divide. Caso for necessário dividir, cria-se colunas diferentes. Por exemplo, ter em
uma tabela uma coluna para DDD e outra coluna o campo telefone. A divisão se faz
necessária quando precisamos realizar consultas específicas, como: a quantidade de
telefones do DDD 11 da tabela de clientes.
Dizemos que uma tabela está populada quando ela se apresenta preenchida. Veja
na Figura 4.
FIGURA 16 - TABELA POPULADA
Fonte: Cardoso (2008 p. 57)

36 SUMÁRIO
BANCO DE DADOS I
Perceba que cada linha (tupla) na figura 4 corresponde a uma pessoa. Para cada pes-
soa, temos três atributos, matrícula, nome e endereço respectivamente.
Dessa forma, são representados os registros no modelo relacional. Conjuntos de valo-

res atômicos com atribuições. A tabela da Figura 4 “está presente” em todos os siste-
mas que você possa imaginar, pois reúne dados de pessoas.
Entre um sistema e outro, o que muda é o contexto dessas pessoas. Há pessoas que
são clientes, pessoas que são alunos, pessoas que são usuários e entre outros.
2.2.2 CHAVE PRIMÁRIA
As chaves de modo geral no modelo relacional são conhecidas como keys. Compa-
rando com o modelo entidade-relacionamento, a chave primária no modelo relacio-
nal é o mesmo que o atributo chave naquele modelo. Na Figura 4, você percebeu a
coluna Matrícula sublinhada?
As chaves primárias não se repetem e não aceitam valores nu-

los! Elas identificam o registro para que seja possível criar os
relacionamentos de conjuntos de dados no modelo relacional.
Perceba na Figura 5 duas tabelas contendo registros de alunos em uma tabela e cur-
sos em outra tabela. Na tabela Cursos, é possível observar a presença de um campo
Matrícula fazendo referência à chave primária da tabela Alunos. Vemos claramente
uma relação onde, por exemplo, o aluno José, residente no endereço Av. Das Flo-
res 25, cursa a disciplina de Redes. Identifica-se isso vendo que a matrícula do José
(1085123) está presente na tabela Cursos na primeira tupla da tabela Cursos.

SUMÁRIO 37
BANCO DE DADOS I
FIGURA 17 - TABELA POPULADA
A falta de relação também nos entrega informações. Você percebeu que Maria não
está cursando nenhuma disciplina? Isso é comum em banco de dados, da mesma
forma que um aluno não está matriculado em todas as disciplinas de uma faculdade
inteira, no mundo real. Correto?
2.2.3 CHAVE ESTRANGEIRA
A chave estrangeira é denominada dessa forma para identificar um atributo de outra

tabela. Conforme vimos no tópico anterior, a matrícula da tabela alunos está contida
na tabela cursos. Essa existência dela na tabela cursos informa que ela é uma chave
estrangeira, pois se trata de um campo que veio de fora, de outra tabela. Para não
restar dúvidas quanto a isso, veja a Figura 6.

38 SUMÁRIO
BANCO DE DADOS I
FIGURA 18 - EVIDENCIANDO A CHAVE ESTRANGEIRA
Fonte: Elaborado pelo autor, adaptado de Cardoso (2008, p. 58)
Perceba na Figura 6 que a matrícula que consta na tabela Cursos é uma chave estran-
geira da tabela Alunos. Repete-se o número da matrícula.
2.3 MAPEAMENTO MER PARA MR
Como já foi falado, é possível realizar o chamado mapeamento entre o modelo enti-
dade-relacionamento (MER) para o modelo relacional (MR). Através do mapeamen-
to, podemos migrar a modelagem, mas precisamos que o modelo entidade-rela-
cionamento tenha basicamente a determinação de cardinalidade. Vamos ver nos
próximos tópicos como acontecem os três tipos de mapeamentos, de acordo com a
cardinalidade: 1 para 1, 1 para N e N para N.
2.3.1 MAPEAMENTO 1 PARA 1
Conforme Figura 7, temos um MER envolvendo duas entidades: alunos e professores.

Observe os atributos de cada entidade, incluindo o atributo-chave e também note a
representação de cardinalidade 1 para 1.

SUMÁRIO 39
BANCO DE DADOS I
FIGURA 19 - MER COM CARDINALIDADE 1 PARA 1
Já na Figura 8, temos a migração para o modelo relacional envolvendo agora duas

tabelas, constando: duas tabelas, o esquema (cabeçalho de atributos) e o relaciona-
mento entre a chave primária e chave estrangeira. A representação é feita de dois
casos diferentes. No caso 1, há o CPF do professor (chave primária em professores)
presente na tabela Disciplina como chave estrangeira. Já no caso 2, há o código da
Disciplina (chave primária em disciplinas) presente na tabela Professores.
FIGURA 20 - MR COM CARDINALIDADE (1 PARA 1), APRESENTANDO DOIS CASOS
Fonte: Elaborador pelo autor, adaptado de Cardoso (2008, p. 61-63)
Veja na Figura 9, com os dados populados, que ambas as formas se apresentam cor-
retas.
FIGURA 21 - TABELAS POPULADAS DO MR (1 PARA 1), APRESENTANDO DOIS CASOS
Fonte: Elaborador pelo autor, adaptado de Cardoso (2008, p. 63)

40 SUMÁRIO
BANCO DE DADOS I
Analisando a diferença entre os casos de cardinalidade 1 para 1, temos uma diferen-

ça interessante. Você percebeu no caso 2 que a professora Joana está com o campo
código (da disciplina) vazio? Isso demonstra que Joana não leciona nenhuma disci-
plina. Da mesma forma que, analisando o caso 1, não há o CPF da Joana relacionado
na tabela disciplina.
Qual forma escolher? Isso depende de qual forma é melhor ao

projeto como um todo. Na prática, procura-se não ter tabelas
com espaços em brancos ou, caso exista tal necessidade, que
se tenham menos possíveis. Mas, não se preocupe com isso,
que é extremamente normal, e você terá uma equipe para discutir sobre
isso em sua carreira, avaliando sempre o melhor ao projeto. Adquirindo
experiência, você verá também facilmente qual usar em cada caso prático.
2.3.2 MAPEAMENTO 1 PARA N
Para o mapeamento 1 para N, segue-se o mesmo raciocínio. Porém, essa cardinalida-

de possui somente um caso, onde a chave primária da tabela do lado de cardinalida-
de 1 deve sempre ser chave estrangeira do lado N. A figura 10 mostra a representação
do relacionamento e, ao lado, a tabela populada, para ficar fácil compreender.
FIGURA 22 - MR (1 PARA N) E TABELA POPULADA
Fonte: Elaborador pelo autor, adaptado de Cardoso (2008, p. 64)
Ora, se trata da mesma representação do modelo relacional 1 para 1! Sim, e o que irá
mudar são os valores contidos na tabela. Veja na tabela populada da figura 10 que a
professora Ana ministra as disciplinas de artes e música. Isso é percebido, pois o seu
CPF, que é chave estrangeira na tabela Disciplina, repete-se nos registros de ambas
as disciplinas. O CPF da Ana é 231.654.007-22.

SUMÁRIO 41
BANCO DE DADOS I
2.3.3 MAPEAMENTO N PARA N
O mapeamento N para N se difere dos demais, pois nesse caso, na representação em

um modelo relacional, é necessário criar uma terceira tabela. Veja isso na Figura 11.
FIGURA 23 - MAPEANDO N PARA N CRIA-SE NOVA TABELA (PROFESSORES-DISCIPLINAS)
Perceba que agora há uma tabela denominada Professores-Disciplinas. É interessante

notar que ela é composta por dois campos: CPF e Código. Estes, logicamente, são as
chaves estrangeiras das tabelas Professores e Disciplinas, respectivamente. Ambos são
representados de forma sublinhada nessa nova tabela, o que quer dizer se tratar de
uma chave primária composta, ou seja, composta por dois campos distintos das tabe-
las que tem relacionamento. Veja na agora na figura 12 essas três tabelas populadas.
FIGURA 24 - TABELAS POPULADAS EM CARDINALIDADE N PARA N

42 SUMÁRIO
BANCO DE DADOS I
Perceba através do código da disciplina de música (268) que ela é ministrada por dois
professores distintos: Ana, que tem o CPF: 231.654.007-22, e também pelo professor
Pedro, de CPF: 405.900.765-12. Nota-se também que a Ana, além de ministrar mú-
sica, também leciona artes, visto que o seu CPF também está atrelado ao código da
disciplina 111. Essa percepção se dá na nova tabela Professores-Disciplinas.
Temos então professores lecionando várias disciplinas e uma disciplina sendo lecio-
nada por vários professores. Relacionamento N para N.
Para não restar dúvidas nessa questão, observe a evidenciação do relacionamento

nas figuras 13 e 14. Perceba a associação representada pelas cores: azul/vermelho.
FIGURA 25 - ANA (UMA PROFESSORA) LECIONA VÁRIAS DISCIPLINAS

SUMÁRIO 43
BANCO DE DADOS I
FIGURA 26 - MÚSICA (UMA DISCIPLINA) É LECIONADA POR VÁRIOS PROFESSORES
2.4 NOTAÇÕES PRÁTICAS
Existem notações importantes a serem citadas na modelagem relacional. As chaves

primárias são conhecidas também por primary key, uma tradução direta do inglês ou
apenas pela sua sigla: PK. Dessa forma, é comum se referir a uma chave primária ape-
nas pelas letras PK, como, por exemplo, o CPF é a PK da tabela Funcionários. Em rela-
ção à chave estrangeira, também existe isso, pode-se referir a ela como foreign key, ou
apenas FK, como, por exemplo, o campo CPF-Funcionários é uma FK na tabela Livros.
Em relação à representação de tabelas, diferentemente da forma didática como

apresentamos nos tópicos deste material, na prática, a modelagem não é realizada
utilizando papel e caneta (ou tabelas de Excel!). Usa-se ferramentas de modelagem
como, por exemplo, a ferramenta MySQL Workbench que, além de várias funções,

44 SUMÁRIO
BANCO DE DADOS I
possibilita realizar modelagem relacional de um sistema de banco de dados. Perceba

na Figura 15, um exemplo de representação simples, ao qual qualquer profissional
ligado ao desenvolvimento de softwares consegue entender de forma padronizada.
FIGURA 27 - EXEMPLO DE MR REPRESENTADO DE FORMA PADRONIZADA
Fonte: Cardoso, (2008, p. 71)
Veja também que, ao lado da PK em cada tabela, existe um pequeno ícone de chave,
que visualmente já nos informa que se trata de uma chave primária. Mas, atenção!
Existem outros ícones de chaves, não somente da PK. Entretanto, nesse momento,
não iremos entrar nessas questões, pois na continuidade do estudo desta disciplina
isso será evidenciado.
CONCLUSÃO
Nesta unidade, você teve contato os principais tópicos relacionados a modelos de
dados. Vimos de forma mais aprofundada o modelo relacional, por ser um modelo
amplamente utilizado no mercado de computação. Também foi apresentado como
se pode fazer o mapeamento do modelo entidade-relacionamento para o modelo
relacional, apresentando exemplos de mapeamentos entre cardinalidades distintas.
Recomenda-se que seus estudos em banco de dados sejam aprofundados com a

Na próxima unidade, serão analisadas as linguagens de definição e manipulação de

dados. Bons estudos!

SUMÁRIO 45
BANCO DE DADOS I
UNIDADE 3
OBJETIVO
Ao final desta
unidade,
esperamos
que possa:
> Apontar o que é SQL em banco de

dados.
> Analisar comandos DDL para

definição de dados.
> Definir e aplique comandos DDL.
> Identificar comandos DML para

manipular dados.
> Aplicar comandos DML em banco

de dados relacionais.
> Identificar e aplique operadores

lógicos em comandos SQL.

46 SUMÁRIO
BANCO DE DADOS I
3 LINGUAGENS DE
DEFINIÇÃO E
MANIPULAÇÃO DE DADOS.
Como um administrador de banco de dados ou uma aplicação de software pode
conversar com o SGBD a fim de existir um modelo físico de banco de dados? Pode-
mos escrever de forma lógica utilizando alguma linguagem específica para manipu-
lar dados diretamente em um SGBD, independentemente da linguagem de progra-
mação utilizada para criação de aplicações? Essa será a base para discutir assuntos de
projetos de bancos de dados, que será visto mais adiante na disciplina. Aproveite esta
unidade para realizar treinos e pesquisar mais a respeito da linguagem de definição
e manipulação de dados, utilizada em sistemas de banco de dados relacionais.
3.1 LINGUAGENS DE DEFINIÇÃO E MANIPULAÇÃO
A partir da modelagem de um banco de dados relacional se faz necessário algo que

crie o banco de dados fisicamente, para que seja possível uma aplicação interagir
com os dados armazenados através de consultas padronizadas.
Nessa questão, temos desde 1970 a chamada Structured Query Language, co-
nhecida por sua sigla SQL. A SQL é uma linguagem declarativa padronizada para
banco de dados relacionais. No início era chamada de Structured English Query
Language – SEQUEL.
A linguagem SQL se tornou padrão a partir de 1986 através

de reconhecimento da American National Standards Institu-
te - ANSI e no ano posterior da International Organization for
Standardization – ISO.

SUMÁRIO 47
BANCO DE DADOS I
A linguagem SQL formalmente se apresenta de forma dividida. Sendo:
• Partes que permitem definir dados.
• Partes que manipulam dados.
• Partes que definem comandos para a segurança e integridade dos dados.
É importante entender que a SQL é utilizada amplamente

no mercado atual sendo uma premissa essencial para pro-
fissionais ligados à análise e desenvolvimento de softwares a
compreenda em suas formas mais básicas.
Iremos tratar aqui das partes da linguagem que definem dados e das partes que ma-
nipulam dados. Quando se fala linguagem, entenda simplesmente como um meio
de comunicação, afinal precisamos “conversar” com o SGBD informando a ele como
criar nossa estrutura de dados e posteriormente como inserir os registros, além de
como alterá-los e como os excluirmos da base. Ah! Precisamos saber “perguntar” tam-
bém, ou seja, consultar os dados. Ficou mais clara a questão de linguagem?
3.2 DEFINIÇÃO DE DADOS
Vamos pensar brevemente o que é definir dados. Pesquisar em um livro é definir o

livro? Obviamente que não! Definir um livro é, por exemplo, estabelecer suas divisões,
estruturar como serão os capítulos, como eles se relacionam entre os temas do livro
como um todo.
Em banco de dados segue-se essa mesma lógica, definir os dados é informar como
será a estruturação de tabelas, atributos e relacionamento de tabelas. Para isso te-
mos comandos específicos da linguagem SQL que traduzem a modelagem relacio-
nal para uma estrutura física do banco de dados. É realmente simples assim, acredite.
Para formalizar, vamos chamar essa parte da SQL de Data Definition Language – DDL,
ou seja, linguagem de definição de dados.

48 SUMÁRIO
BANCO DE DADOS I
Comandos de DDL são responsáveis por definir os cha-

mados metadados de uma base de dados. Lembrando
que metadados são dados de outro dado. Exemplo prá-
tico: “O valor de um registro da tabela ABC deve ser um
número inteiro de até X posições”.
Vamos então compreender como podemos conversar com o SGBD para que ele crie
as estruturas, para que ele exclua estruturas e também para que ele modifique as
estruturas. Para facilitar a compreensão, temos que utilizar verbos simples nessa lin-
guagem de comunicação padronizada:
• CREATE – Para criar estruturas.
• ALTER – Para alterar estruturas.
• DROP – Para excluir estruturas.
3.2.1 CRIE PARA MIM SGBD!
Dentro da DDL, tudo se inicia pelo comando CREATE. Ora, precisamos criar nossas
tabelas! Mas antes disso precisa-se existir o banco de dados propriamente dito. Para
isso realizamos a seguinte declaração:
CREATE DATABASE <nome do banco de dados>;
Se queremos criar um banco de dados chamado MeuBanco, temos que declarar:
CREATE DATABASE MeuBanco;
Perceba que ao final da declaração usa-se um ponto e vír-

gula. Ele informa ao SGBD que essa declaração terminou
e que, posteriormente a ela poderá existir outra.

SUMÁRIO 49
BANCO DE DADOS I
3.2.2 ELIMINE O BANCO INTEIRO!
Da mesma forma que criamos uma nova base de dados, precisamos saber como eli-
miná-la, quando isso se fizer necessário:
DROP DATABASE MeuBanco;
Para verificar a remoção de um banco de dados, você pode utilizar o comando: SHOW
DATABASES;
Em alguns SGBDs do mercado, não é disponibilizado o

comando DROP DATABASE.
3.2.3 CRIE UMA TABELA!
Para informar ao SGBD que precisamos criar uma tabela utilizamos também o co-
mando CREATE, mas, além disso, já informamos os tipos de dados dos nossos cam-
pos, ou seja, caso um campo CPF deverá aceitar apenas números ou se poderá aceitar
números, ponto e traço. Compreendeu? O SGBD precisa saber de tudo detalhada-
mente para conseguir operar as consultas posteriormente. Além disso, o comando de
criação de tabela já informa as chaves primárias e estrangeiras da tabela em questão.
Veja como é estruturado um comando de criação de tabela:
CREATE TABLE <nome da tabela> (<nome do atributo> <tipo de dado> [NOT NULL],...,
PRIMARY KEY (<nome do atributo1>, <nome do atributo2>,...) FOREIGN KEY (<nome
do atributo>) REFERENCES (<nome da tabela>);
Vendo dessa forma pode até ser difícil compreender, vamos detalhar utilizando
exemplos que já tratamos nessa disciplina, por exemplo, uma tabela de alunos.

50 SUMÁRIO
BANCO DE DADOS I
FIGURA 28 - COMANDO CREATE TABLE EXPLICADO
Fonte: Elaborado pelo autor, adaptado de CARDOSO, 2008.
Perceba na figura 28 que criamos um único comando utilizando várias linhas, mas
informamos que ele termina no ponto e vírgula da última linha.
Visualizando linha a linha temos um detalhamento completo que você pode perce-
ber lendo o quadro 1. Por mais que pareça algo desnecessário, leia linha a linha do
quadro associando os detalhes inerentes de cada linha do comando.
QUADRO 2 - COMANDO CREATE TABLE EXPLICADO
COMANDO LINHA A LINHA EXPLICAÇÃO DETALHADA
Inicia o comando de criar a tabela Alunos e abre o

Linha 1 CREATE TABLE Alunos
parêntese para definição de campos.
Informa o atributo matrícula sendo do tipo inteiro
Linha 2 matricula int(11),
aceitando 11 caracteres.
Informa o atributo nome sendo do tipo char aceitan-
Linha 3 nome char(20) NOT NULL, do 20 caracteres. E definindo que nele não pode acei-
tar valor nulo.
Informa o atributo endereço sendo do tipo char acei-

Linha 4 endereço char(30),
tando 30 caracteres.
Informa que o atributo PK é a matrícula. Perceba que

matrícula está contida entre parênteses e existe um
Linha 5 PRIMARY KEY (matricula)); parênteses fechando depois, se trata do fechamento
do parênteses aberto na linha 1. Finaliza o comando
com ponto e vírgula.
Fonte: Elaborado pelo autor, 2018.

SUMÁRIO 51
BANCO DE DADOS I
Nesse momento você pode se perguntar: É necessário atentar para cada caractere de
um comando SQL? A resposta cruel é que sim! A falta de uma vírgula, uma abertura
de parênteses sem fechamento, ou declarações específicas da linguagem escritas
de forma errada resultam em um comando ao qual o SGBD não irá conseguir inter-
pretar. Tenha atenção aos detalhes e sempre crie comandos organizados em linhas,
formatado para melhor leitura tanto de você como os membros da sua equipe.
É muito comum existirem query’s SQL (outra forma de se fa-

lar comandos SQL) extensas e ser gasto um tempo precioso
de trabalho as escrevendo sem formatação adequada, ge-
rando erros que deverão ser tratados, e com isso ainda mais
desperdício de esforços.
Vamos agora demonstrar uma criação de tabela que precise uma chave estrangeira
(FK). Para isso iremos utilizar a tabela Cursos, que se relaciona com a tabela Alunos ao
qual já abordamos.
Temos que ter em mente que nesse exemplo, a matrícula do aluno (PK da tabela
Alunos) deverá constar na tabela Cursos como uma chave estrangeira (FK). Esses con-
ceitos nós já tratamos anteriormente nessa disciplina e caso não tenha ficado claro é
primordial que você retorne a esses tópicos para continuar a partir daqui.
FIGURA 29 - COMANDO CREATE TABLE COM FK
Fonte: Elaborado pelo autor, adaptado de CARDOSO, 2008.

52 SUMÁRIO
BANCO DE DADOS I
Conforme percebemos na figura 2, temos a mesma estrutura de criação de tabela, mas

agora acrescentamos a linha que informa a nossa FK. Lembre-se que independente da
declaração da FK a linha acima está tratando da PK da tabela Cursos, correto?
3.2.4 ALTERE MINHA TABELA, POR GENTILEZA.
Podemos solicitar ao SGBD que realize alterações na estrutura de uma tabela. Para
isso utilizamos o ALTER TABLE. Sua sintaxe é definida por:
ALTER TABLE <nome da tabela> [ ADD <nome do atributo> <tipo de dado>; | CHANGE
<nome do atributo> <tipo de dado>;| RENAME <nome novo da tabela >| DROP < nome
do atributo>; ]
Acima informamos a sintaxe constando diferentes formas de utilizar o comando AL-

TER. Vamos explicar detalhadamente a seguir, não se desespere.
• ALTER TABLE usando cláusula ADD: É utilizado quando precisamos, por

exemplo, adicionar um atributo na tabela, veja um exemplo.
ALTER TABLE Alunos
ADD cidade VARCHAR(20) not null;
• ALTER TABLE usando cláusula CHANGE: É utilizado quando precisamos, por

exemplo, modificar um atributo na tabela, veja um exemplo.
ALTER TABLE Alunos
CHANGE nome nomeAluno VARCHAR(40) not null;
Perceba que após CHANGE, temos primeiramente a repre-

sentação do atributo a ser alterado (nome) e após o novo (no-
meAluno). Evidenciado de vermelho. Ou seja, nessa tabela o
atributo nome passará se chamar nomeAluno, além de ser
agora um VARCHAR aceitando até 40 caracteres não nulos.

SUMÁRIO 53
BANCO DE DADOS I
• ALTER TABLE usando cláusula DROP: É utilizado quando precisamos, por

exemplo, excluir um atributo na tabela. Veja um exemplo da exclusão de um
possível atributo cidade da tabela alunos.
ALTER TABLE Alunos
DROP cidade;
• ALTER TABLE usando cláusula RENAME: É utilizado quando precisamos, por

exemplo, renomear a tabela.
ALTER TABLE Cursos
RENAME CursosEAD;
• ALTER TABLE usando cláusula ADD PRIMARY KEY ou ADD FOREIGN KEY:
É utilizado quando precisamos adicionar chaves na tabela caso não as tenha-
mos feito no momento de criação da tabela.
ALTER TABLE Alunos ALTER TABLE Cursos
ADD PRIMARY KEY(matricula); ADD FOREIGN KEY(matricula)
REFERENCES Alunos(matricula);
3.2.5 ELIMINE UMA TABELA
Os comandos DDL chegam ao fim com a utilização do comando DROP TABLE. É sim-
ples compreende-lo, veja:
DROP TABLE Cursos

54 SUMÁRIO
BANCO DE DADOS I
3.3 MANIPULAÇÃO DE DADOS
Os comandos responsáveis pela manipulação de dados são a parte da SQL denomi-

nada como Data Manipulation Language – DML. A manipulação dos dados se dá por:
• Inserção de dados de tabelas.
• Atualização de dados de tabelas.
• Exclusão de dados em uma tabela.
• Seleção de dados de uma tabela.
Vamos ver detalhadamente como são compostos estes comandos dentro da lin-
guagem SQL a seguir, mas antes disso precisamos entender os conceitos de opera-
dores lógicos.
3.3.1 OPERADORES LÓGICOS
Através dos operadores lógicos é possível criar query’s SQL que nos permitem usar mais
de uma única condição em uma mesma cláusula. Dessa forma podem-se produzir re-
sultados únicos utilizando esses operadores. A linguagem SQL faz uso de três operadores:
• AND: Com a utilização do operador AND teremos como retorno nas consultas
se as duas condições forem atendidas.
Exemplo: “Alunos do estado de São-Paulo AND DDD_telefone = 11”
Explicação: Não haverá no retorno dessa consulta alunos de Minas-Gerais,

como também não haverá retorno de alunos de São-Paulo com telefone dife-
rente do DDD 11. Serão exibidos somente alunos de São-Paulo que seu tele-
fone tenha DDD 11.
• OR: Com a utilização do operador OR teremos como retorno nas consultas se

umas das duas condições forem atendidas.
Exemplo: “Alunos do estado de São-Paulo OR DDD_telefone = 11”
Explicação: Aqui serão exibidos alunos de São-Paulo ou qualquer aluno que tenha
DDD do telefone = 11 em seu registro.

SUMÁRIO 55
BANCO DE DADOS I
• NOT: Com a utilização do operador NOT teremos como retorno nas consultas
se não for atendida uma condição em sequência, por exemplo.
Exemplo: “Alunos com DDD_telefone NOT BETWEEN 11 AND 21”
Explicação: Aqui serão exibidos alunos que tenham DDD do telefone que não
estão entre 11 e 21. Por exemplo, serão retornados alunos com DDD = 31.
Os exemplos acima foram didáticos, mesclando “português com SQL” para conseguir
transmitir a você o funcionamento dos operadores lógicos. Adiante veremos como se
dão as consultas propriamente ditas, somente em SQL.
3.3.2 INSERIR NA TABELA!
Agora sim iremos começar a popular os registros em nosso banco de dados. O co-
mando de inserção de registros acontece com a utilização do comando INSERT, veja
a sua sintaxe:
INSERT INTO <nome da tabela> [(<nome dos atributos>)]
VALUES (<valores dos atributos>);
Imagine uma tabela que contém os dados de pilotos de corrida, e nela temos sete
campos: código, nome, pais, idade, equipe, motor, pontos. O comando de inserção
seria:
INSERT INTO Pilotos (código, nome, pais, idade, equipe, motor, pontos)
VALUES (140, ‘Carlos Almeida’, ‘Brasil’, 26, ‘Hispania’, ‘Cosworth’,0);
Perceba que dizemos ao SGBD para inserir na tabela pilotos (INSERT INTO Pilotos),
nos campos (código, nome, pais, idade, equipe, motor, pontos) os seguintes VALUES
(140, ‘Carlos Almeida’, ‘Brasil’, 26, ‘Hispania’, ‘Cosworth’,0);
Para cada atributo dentro do primeiro parênteses, temos o seu valor correspondente
no segundo parênteses do comando, de forma sequencial.

56 SUMÁRIO
BANCO DE DADOS I
Explicando de forma simples: o código será 140, o nome do piloto é Carlos Almeida,
o país é o Brasil etc. Cada atributo e valor devem estar sequenciado e separado por
vírgula dentro dos parênteses.
Um erro será retornado caso você informe campos a

mais e não estipule seus valores corretamente. Exemplo:
Solicitar inserção em sete campos nos parênteses INTO
Pilotos(), apresentando apenas cinco valores dentro dos
parênteses VALUES().
3.3.3 SELECIONAR DE UMA TABELA!
Agora a proposta fica interessante. Um sistema de banco de dados passa a ter total
sentido quando conseguimos nos beneficiar de consultas de dados para atender o
que o usuário final necessita, concorda?
O comando da linguagem SQL necessário para isso é o SELECT. Conforme abaixo

realizamos uma seleção simples envolvendo apenas uma tabela, veja:
SELECT nome FROM Pilotos
Essa consulta irá retornar todos os nomes de pilotos. O FROM é essencial para infor-
mar de qual tabela se trata a consulta. Vamos agora restringir um pouco os resultados
utilizando um operador lógico, acompanhe:
SELECT nome FROM Pilotos WHERE idade = 26 AND pontos = 0;
Segue-se o mesmo raciocínio, mas agora teremos a listagem dos nomes de pilotos que
tem idade = 26 e pontos = 0. Percebeu o WHERE? Onde idade = 26 e pontos = 0. Vamos
continuar, agora simplesmente acrescentando mais campos a serem retornados.
SELECT nome, pais, equipe FROM Pilotos WHERE idade = 26 AND pontos = 0;

SUMÁRIO 57
BANCO DE DADOS I
A diferença agora é que queremos que seja retornado além do nome, também o país e a
equipe de pilos que tenham idade = 26 e pontos = 0. Mas e seu quiser todos os campos?
SELECT * FROM Pilotos WHERE idade = 26 AND pontos = 0;
OK, podemos utilizar o asterisco entre o SELECT e o FROM, conforme acima. Dessa
forma serão exibidos todos os atributos de pilotos, atendendo o que foi pedido no
WHERE. (Idade = 26 e pontos = 0).
Através do SELECT pode-se também relacionar campos de

diferentes tabelas. Veremos isso de forma prática utilizando
o SGBD MySQL através de aula interativa que acompanha
essa unidade de estudo. Um exemplo disso seria retornar
os nomes de pilotos, juntamente com dados do carro que
eles pilotam (que estão relacionados em outra tabela) de
um possível banco de dados de um campeonato de corrida.
Além de ver isso de forma prática aqui na disciplina, aconse-
lha-se que você pesquise mais a respeito das diversas formas
de utilizar o SELECT através de consultas SQL, por exemplo,
acessando os livros disponíveis no sistema Minha Biblioteca.
Comandos SELECT possuem grande variação de utilização e
é fundamental se aprofundar em suas formas de utilização.
3.3.4 ALTERAR DADOS DA TABELA!
Para alterar os dados em tabelas, fazemos uso do UPDATE, conforme sintaxe:
UPDATE <nome da tabela> SET <alteração> [WHERE <condição>];
Vamos seguir apresentando exemplos práticos. Imagine que precisamos alterar o

atributo país de todos os pilotos para Brasil. Veja como seria o comando:
UPDATE Pilotos
SET pais = ‘Brasil’;

58 SUMÁRIO
BANCO DE DADOS I
Dessa forma todos os registros da tabela Pilotos teriam agora o valor Brasil no atributo
pais. Pois através da cláusula SET informamos que o valor para país deve ser = Brasil.
Vamos agora alterar mais atributos:
UPDATE Pilotos SET equipe = ‘Ferrari’, pontos = 0;
Agora alteramos todos os registros da tabela Piloto informando que todos eles são da
equipe Ferrari e estão com 0 pontos.
Poderíamos ser demitidos nesse momento, pois simples-

mente alteramos todos os registros de pilotos. É altamente
recomendável que comandos UPDATE possuam restrições
utilizando WHERE. Veja abaixo:
UPDATE Pilotos SET equipe = ‘Williams’ WHERE idade > 25;
Agora estamos restringindo a alteração para apenas os pilotos com idade maior que
25 anos. Percebeu o WHERE?
Uma dica de carreira! Aprendemos que podemos usar o

WHERE em comandos SELECT, correto? Para não corrermos
risco de realizar operações UPDATE erradas, pode-se pri-
meiramente realizar um SELECT para averiguar os registros
que serão retornados, e sabendo que através do SELECT, por
exemplo, somente cinco registros foram retornados, enten-
demos logicamente que um UPDATE com mesma definição
WHERE irá alterar somente cinco registros.
Perceba: SELECT * FROM Pilotos WHERE idade > 25

SUMÁRIO 59
BANCO DE DADOS I
Supondo o SELECT acima retornou apenas cinco registros, sabemos que um UPDATE
que se utilize de mesmo WHERE, logicamente terá que alterar somente cinco regis-
tros, ao solicitar que o UPDATE abaixo seja executado:
UPDATE Pilotos SET equipe = ‘Williams’ WHERE idade > 25;
Em resumo, antes de realizar um comando UPDATE, você pode realizar um comando

SELECT para garantir que sua alteração irá acontecer somente com os registros que
você espera que ocorra. Evite o conhecido “UPDATE sem WHERE”!
3.3.5 APAGAR DADOS DA TABELA!
Antes de apresentar esse último comando da DML da linguagem SQL, o que acaba-
mos de perceber na dica do “UPDATE sem WHERE”, também é válido para o coman-
do de remover registros. Vamos a sua sintaxe:
DELETE FROM <nome da tabela> [WHERE <condição>];
Exemplo prático:
DELETE FROM Pilotos;
É isso mesmo que você imaginou. Todos os dados de Pilotos foram apagados.
Já aqui teríamos um comando de DELETE de forma mais restrita:
DELETE FROM Pilotos WHERE idade > 24 AND pais = ‘Brasil’;
Somente seriam apagadas as duplas (registros) de pilotos com idade acima de 24

anos e do país Brasil.
Podemos e devemos utilizar operadores lógicos principalmente com comandos DE-

LETE através da cláusula WHERE, assim como vimos com o comando de UPDATE.

60 SUMÁRIO
BANCO DE DADOS I
UNIDADE 4
OBJETIVO
Ao final desta
unidade,
esperamos
que possa:
> Apontar o que é normalização em banco de

dados.
> Analisar tabelas básicas em 1FN, 2FN e 3FN.
> Identificar outras formas normais como a

FNBC e a 4FN.
> Definir o que é dependência funcional

visualizando exemplos práticos.
> Aplicar normalização 1FN, 2FN e 3FN em

tabelas relacionais.
> Definir o motivo de normalizar tabelas em

um projeto de banco de dados.
> Definir em qual parte de um projeto de

banco de dados podemos normalizar.
> Definir até que ponto a normalização é

benéfica na prática de um projeto de banco
de dados.

SUMÁRIO 61
BANCO DE DADOS I
4 NORMALIZAÇÃO EM
PROJETOS DE BANCO DE
DADOS
Estamos preparados para grandes aplicações a partir de uma modelagem de banco
de dados simplificada? Conseguimos usar alguma lógica para refinar nossas tabelas
a fim de evitar redundâncias? Essas preocupações nos levam a questão de normali-
zação de tabelas em banco de dados. Nessa unidade iremos introduzir o que é nor-
malizar e quais são as formas normais às quais podemos aplicar em nossas tabelas de
banco de dados. Faremos também uma abordagem geral do processo que envolve a
criação de um projeto de banco de dados, para com isso conseguirmos compreender
quando podemos pensar na normalização do banco de dados.
4.1 NORMALIZAÇÃO EM BANCO DE DADOS
Partindo do princípio que já se conhece os modelos de dados para um sistema de

banco de dados, a forma de criar um modelo entidade-relacionamento (MER), como
transforma-lo em um modelo lógico relacional através de tabelas, atributos, definição
de chaves e relacionamentos entre tabelas, além também de já possuir uma base só-
lida na linguagem declarativa SQL para definir e manipular os dados fisicamente em
tabelas, o que mais precisamos para criar um projeto de banco de dados?
Até aqui se construiu um conhecimento bastante prático que já pode te levar a gran-
des voos em uma carreira de tecnologia da informação, bastando obviamente que se
pratique o que foi discutido até então. Para responder a pergunta anterior, faremos
outro questionamento: eu já sei o básico necessário para transformar uma situação
do mundo real em um banco de dados relacional, mas esse básico necessário está
otimizado da melhor forma?
A normalização de banco de dados entra justamente nessa questão e é importante

entender o que ela traz de benefício em um projeto como um todo, não somente em
relação à tecnologia, mas principalmente a questão de esforço futuro e tempo. Esfor-
ço (em todos os âmbitos como: manutenção; retrabalho; mais membros na equipe;
etc.) e tempo são dois recursos de extrema complexidade no desenvolvimento pro-

62 SUMÁRIO
BANCO DE DADOS I
jetos. Proponha-se a uma reflexão prática: Um sistema cresceu “da noite para o dia”
através do sucesso de uma organização envolvendo diversos departamentos e o ban-
co de dados sendo o coração da aplicação não está desde seu início organizado de
forma inteligente para tal evolução. As tabelas não foram definidas de forma correta,
o sistema já está em produção e será preciso refazer sua programação para atender
um novo modelo relacional. Fomos agora ao futuro e voltamos para te alertar que
pequenos detalhes fazem muita diferença.
A normalização então nos trás os seguintes benefícios:
• Facilidade e agilidade em manutenção, principalmente para ações DML.
• Não desperdício de espaço em disco e tempo do usuário/equipe do projeto.
Para atingir o objetivo de um banco de dados normalizado, é necessário:
• Boa modelagem usando MER
• Seguir regras lógicas no desenvolvimento do MR
Seguir regras lógicas para criação do modelo relacional – MR é o que temos como
normalização.
A normalização é definida como um procedimento que se-

gue um raciocínio matemático com fundamentos na teoria
de conjuntos e indica o nível de qualidade das tabelas do
banco de dados.
A normalização procura minimizar redundâncias, minimizar inserções erradas, além

também de minimizar irregularidades em exclusões e atualizações de tabelas rela-
cionais populadas. Para isso, a normalização propõe a decomposição de tabelas que
não foram bem projetadas em tabelas de menor tamanho.
Com intuito do resultado de um projeto de banco de dados que apresente alta qua-
lidade, existem regras de normalização denominadas como formas normais. As for-
mas normais impõem restrições às tabelas e elas se apresentam em níveis, ao qual
CARDOSO (2008) informa:
Para que a tabela passe para um nível superior, ela precisa atender aos níveis
inferiores primeiro, ou seja, é preciso seguir uma sequencia, pois uma forma
normal inferior é pré-requisito para o nível posterior. Quando a tabela aten-
de à ultima regra, ou forma normal imposta, está implícito que ela atenderá
também às formas normais anteriores à imposta. (Virgínia Cardoso, 2008 p.98)

SUMÁRIO 63
BANCO DE DADOS I
As formas normais são então classificadas nos seguintes níveis:
• Primeira forma normal
• Segunda forma normal
• Terceira forma normal
• Forma normal Boyce-Codd;
• Quarta e quinta forma normal
Explicando a citação de Virgínia Cardoso, temos que se uma tabela está formalizada
na terceira formal normal, por consequência ela atende a segunda e primeira forma
normal. De forma resumida é uma evolução, se atingiu a forma normal Boyce-Codd,
por exemplo, consequentemente atende a todas as formas normais anteriores.
Iremos agora detalhar cada uma das principais formas normais.
4.1.1 A PRIMEIRA FORMA NORMAL
Conhecida como 1FN, a primeira forma normal é a mais simples, pois pede apenas
que os atributos possuam domínio atômico, ou seja, que seus valores sejam indivisí-
veis.
Vamos melhorar o entendimento da 1FN através de uma tabela de um dado banco

de dados que tenha por finalidade armazenar os dados de pessoas, vamos usar uma
tabela simples de alunos. Nessa tabela precisamos ter mais de um endereço desses
alunos, por exemplo, endereço residencial e comercial. Nesse momento você já tem
uma abstração física dessa tabela, sendo, por exemplo: a matrícula do aluno como
PK, o nome do aluno em outro atributo e mais um atributo como endereços (perce-
ba que usamos plural). Conforme figura 1, temos então a tabela alunos populada e
se percebe que o aluno José na primeira tupla da tabela, possui dois endereços em
um mesmo atributo e também o aluno Paulo na última tupla também possui dois
endereços.

64 SUMÁRIO
BANCO DE DADOS I
FIGURA 30 - TABELA ALUNOS SEM NORMALIZAÇÃO
Fonte: Elaborado pelo autor, adaptado de Cardoso 2008 p.99
A figura 1 viola a regra 1FN, pois existem vários endereços em um mesmo atributo.
Você pode imaginar que então podemos criar um atributo separado para endereço
comercial. Correto, dessa forma já atendemos a 1FN desse exemplo de tabela, con-
forme figura 2.
FIGURA 31 - ALUNOS EM 1FN
Fonte: CARDOSO, 2008 p.101
Na figura 31 temos então duas tabelas, onde podemos notar os endereços de José
nas duas primeiras tuplas da tabela Alunos-Endereços e nas ultimas duas tuplas os
endereços do aluno Paulo.

SUMÁRIO 65
BANCO DE DADOS I
Como vimos a primeira formal normal – 1FN não permite valores não atômi-
cos para os atributos. Devem ser valores únicos. Entenda que não estamos
abordando a repetição de valores entre linhas diferentes da tabela! Dentro do
atributo matricula existe apenas uma matrícula de aluno. Não existem duas
matrículas de um mesmo aluno. A matrícula se repete na relação Alunos-en-
dereços, mas em tuplas diferentes. O que queremos dizer é que não existem
duas matriculas “em um mesmo campo” do registro. Assim como não existem
dois endereços “em um mesmo campo” do registro.
4.1.2 DEPENDÊNCIA FUNCIONAL
Para entendermos a segunda forma normal temos que compreender o que vem a
ser dependência funcional, ou também conhecida como regras de integridade.
Atenção! Essa parte do conteúdo demanda uma atenção um pouco maior e

dessa forma não prossiga para o entendimento das demais formas normais
caso não tenha assimilado perfeitamente o que é dependência funcional.
Também chamada pela sigla DF, a dependência funcional define como os atributos
das relações (tabelas) se inter-relacionam com seus valores, considerando todas as tu-
plas. Na aplicação de DF a teoria nos informa formalmente que um atributo depende
funcionalmente de outro atributo se para valor do atributo A sempre existir um
valor único no atributo B. Dessa forma temos a notação:
A→B

66 SUMÁRIO
BANCO DE DADOS I
A notação pode ser lida das seguintes formas (uma delas):
• A realiza em B
• A leva a B
• A determina funcionalmente B
• B é dependente de A funcionalmente
Vamos agora melhorar esse entendimento enxergando a instância de uma relação

de um esquema simples. Em outras palavras, vamos analisar uma tabela populada
com dados, apresentando poucos atributos.
QUADRO 3 - TABELA PARA EXEMPLO DE DF
A B C D
a1 b1 c1 d1
a1 b2 c2 d2
a2 b2 c2 d3
a3 b3 c2 d3
Na tabela apresentada no quadro 3, temos quatro tuplas com valores para os atri-
butos A, B, C e D. (Representado em azul). Para essa tabela o projetista definiu a DF
sendo B → C. Ou seja, foi definido que nessa tabela sempre que um valor do atributo
B existir, um único valor no atributo C deverá ser correspondente a ele.
Perceba que essa DF está sendo atendida, pois temos nas tuplas 2 e 3 da instância o
valor b2 e respectivamente o valor c2, em ambas as tuplas. (representado em verde).
Temos então validado que B determina funcionalmente C.
Mas o contrário é verdadeiro? C → B? Não, pois como podemos perceber, apesar de

C levar a B nas tuplas 2 e 3, isso não é verdadeiro na tupla quatro. (representado em
vermelho). Explicando detalhadamente:
Temos c2 como valor do atributo C, mas temos o valor b2 e b3 na coluna B. Ou seja,

temos valores diferentes em B analisando C como determinante da DF.
A teoria apresentada de dependência funcional é entendida de imediato quanto

SUMÁRIO 67
BANCO DE DADOS I
pensamos em alunos e matriculas. Uma matrícula é única de um aluno, indepen-

dente se dentro de uma dada tabela, o registro de matricula se repita. Perceba isso
na figura 32.
FIGURA 32 - EXEMPLO DE INSTÂNCIA DA RELAÇÃO ALUNOS
Para cada matricula temos um nome específico. Dessa forma, temos a DF informan-
do: matricula → nome.
A matrícula 1085123 aparece nas linhas 1 e 2 apresentando o nome José Silva Reis.
Essa matrícula é única dessa pessoa. O mesmo acontece nas linhas 4 e 5 em relação
a Maria do Carmo Silva. Além disso, nenhum outro registro da tabela está desobe-
decendo a essa restrição. Dessa forma, nessa tabela foi definido que em todos os re-
gistros de alunos, uma matricula não pode levar a nomes diferentes. Uma matricula
sempre leva a um nome específico de um aluno. Esse exemplo é obviamente o mais
simples de ser assimilado, pois se trata de uma PK envolvida, nesse caso a matrícula.
A dependência funcional é uma definição do projetista, e o que garante essa restri-

ção imposta por ele são:
1. Estabelecimento de um bom projeto: modelando o banco de dados de forma

organizada com relações e chaves corretamente.
2. Utilização de funções: através funções de SQL (avançado) declaradas direta-

mente no SGBD ou através de funções de programação da aplicação.

68 SUMÁRIO
BANCO DE DADOS I
Com isso, enxergamos que as dependências funcionais são restrições arquitetadas,

pensadas de forma inteligente pelo projetista, mas o banco de dados “de forma crua”
não irá garantir que os dados que estão sendo manipulados nas tabelas, irão atender
a(s) DF(s) por natureza própria.
4.1.3 A SEGUNDA FORMA NORMAL
Como abordamos anteriormente no inicio desta unidade, a premissa para a segunda

forma normal – 2FN é que a tabela atenda a 1FN. O segundo atendimento a 2FN é se
a tabela possui chave primária composta, conforme CARDOSO (2008) informa:
Na sequencia (após atender 1FN) verificaremos se a tabela possui chave pri-

mária composta, pois a forma normal só se aplica a tabelas que a possuam.
Se isso não ocorrer, devemos desprezá-la e continuar o processo. (Virgínia Car-
doso, 2008 p.98)
Partindo desses princípios, iremos verificar a dependência funcional total, ou seja,

caso cada tupla possua uma PK e se cada atributo não pertencente à chave primária
dependa inteiramente dela, e também de todos os atributos que fazem sua com-
posição. Vamos analisar isso de forma prática através de uma tabela Alunos-Cursos,
conforme figura 33.
FIGURA 33 - TABELA ALUNO-CURSOS
Notamos primeiramente que a tabela está em 1FN e apresenta RA-aluno e núme-

ro-curso como uma chave composta. Temos agora que analisar os outros atributos
em relação a essa chave. Agora temos que pensar logicamente diante da situação

SUMÁRIO 69
BANCO DE DADOS I
número-horas e local-curso. Diante dessa tabela o número de horas está diretamente

ligado à questão de qual aluno está fazendo um curso, ou seja, número-horas depen-
de inteiramente da PK composta.
Analisando agora a questão do local do curso, temos uma ligação direta somente
com cursos, concorda? Pois pensando no mundo real, um local de curso independe
de alunos. Logo, esse atributo não está inteiramente ligado a PK composta e somente
a uma parte dela. Além disso, gerou-se redundância na tabela (valor LCC1 repetindo
nas duas primeiras tuplas). Assim sendo, a tabela apresentada na figura 5 não está
atendendo a 2FN.
Conseguimos identificar o causador do problema sendo o atributo local-curso e para

resolver a violação da segunda forma normal, devemos retira-lo dessa tabela.
FIGURA 34 - ATENDENDO 2FN
Fonte: CARDOSO, 2008 p. 107
A figura 34 agora nos mostra como adequar a tabela Alunos-Cursos a 2FN. Para isso
criamos a tabela Local-Cursos separadamente, sendo a PK dessa nova tabela o nú-
mero-curso. Perceba que agora não existe também a redundância do valor LCC1,
pois conforme evidenciado em cinza na nova tabela Local-Cursos, temos o atributo
local-curso presente nessa tabela.

70 SUMÁRIO
BANCO DE DADOS I
4.1.4 A TERCEIRA FORMA NORMAL
A 3FN deve atender obrigatoriamente as regras da 2FN que consequentemente aten-

dem as regras 1FN. Sabendo dessa premissa, vamos conhecer o que deve ser atendi-
do de fato nessa forma normal.
Uma tabela na 3FN solicita que os atributos não chave dependam da PK da tabela,
além também de atender a regra de serem mutuamente independentes.
Para normalizar uma tabela nessa forma, devemos remover redundâncias levando
em consideração o atributo que tem uma dependência funcional transitiva. Tal de-
pendência é classificada como transitiva quando um atributo depende de outro atri-
buto que não é chave da tabela.
Como fizemos anteriormente para compreensão das demais formas normais, vamos
exemplificar em um caso prático de uma tabela, conforme figura 7.
FIGURA 35 - TABELA ALUNOS VIOLANDO A 3FN
A figura 35 nos mostra uma tabela de alunos contendo os atributos matrícula, nome,
disciplina e crédito. A tabela está atendendo 1FN, pois apresenta valores atômicos, e
atende a 2FN devido à existência de chave primária simples com atributos que de-
pendem dela.
Validando para 3FN, temos que nome dependente diretamente da matrícula do alu-
no. A disciplina também está diretamente atrelada à matrícula. Agora analisando o

SUMÁRIO 71
BANCO DE DADOS I
atributo crédito, percebemos que ele está ligado na verdade a questão de disciplina
e não diretamente a matricula. Nota-se então uma dependência transitiva, pois cré-
dito está ligado a disciplina que por sua vez está ligado a questão de matrícula do
aluno. Percebe-se uma ligação indireta, não existindo DF total em relação ao crédito
e a matrícula.
Como se pode imaginar, devemos então “separar” o crédito da tabela de alunos. Per-
ceba na figura 8 como então devemos proceder para atender a 3FN nesse caso.
FIGURA 36 - ATENDENDO A 3FN
Foi criada uma tabela Créditos separadamente fazendo referência ao atributo disci-
plina, dessa forma a tabela Alunos permanece apenas com os atributos que possuem
DF total a chave primária da tabela Alunos (nome e disciplina).

72 SUMÁRIO
BANCO DE DADOS I
4.1.5 OUTRAS FORMAS NORMAIS
Existe também a forma normal denominada como Boyce-Codd, conhecida pela sigla
FNBC. Trata-se de uma 3FN apresentando melhorias. CARDOSO (2008) informa que:
Formalmente, diz-se que uma tabela R atende à FNBC quando para todas
as dependências de R não triviais X → a e X for uma superchave de R. A 3FN
analisa dependências funcionais transitivas ou indiretas de atributos fora da
chave, mas, quando o atributo em questão faz parte da chave, ele não é ve-
rificado pelas 2FN e 3FN. Na FNBC, verificam-se as dependências funcionais
também como nas 2FN e 3FN que se baseiam nas chaves. Para estar na FNBC
uma tabela deve possuir atributos que são somente chaves candidatas. (Virgí-
nia Cardoso, 2008 p.109)
Partindo desse entendimento teórico, temos que a tabela atendendo a FNBC tem o
determinante sendo uma chave candidata da tabela.
Uma chave candidata se trata de um atributo que não neces-

sariamente é chave primária, aos quais os valores são únicos.
Imagine por exemplo uma tabela Clientes, sendo a PK um
atributo id_cliente e outro atributo sendo o CPF, como chave
candidata, pois um CPF é único para cada cliente.
Ainda em normalização de tabelas em banco de dados, temos a 4FN que impõe que
não existam dependências multivaloradas. Nessa unidade iremos nos ater somente
até a 3FN como foco de estudo de normalização na disciplina. Trata-se de um co-
nhecimento bastante amplo e dependente da leitura de muitas referências, além de
prática com banco de dados relacionais.
Você poderá realizar a leitura complementar a respeito de

normalização consultando o livro Sistemas de gerenciamen-
to de banco de dados, 2008 onde o autor explorar com mais
detalhes todas as formas normais, incluindo refinamentos e
sintonização, a partir da página 506 do livro.

SUMÁRIO 73
BANCO DE DADOS I
4.2 VISÃO GERAL DE UM PROJETO DE BANCO DE

DADOS
A partir de todos os conceitos já estudados na disciplina, vamos aqui fazer uma abor-
dagem geral de um projeto de banco de dados.
Um projeto de banco de dados é constituído a partir da modelagem conceitual, para

identificar de forma mais abstrata como será o banco de dados. Nesse ponto como já
sabemos não nos importa com qual sistema de gerenciamento de banco de dados
(SGBD) o projeto final irá operar. Para isso utilizamos o modelo entidade-relaciona-
mento (MER) criando um diagrama conceitual que envolve as entidades, atributos, e
a cardinalidade imposta entre as entidades.
Nesse ponto temos a primeira “tradução” do mundo real para o projeto. Detalhamos
os processos envolvidos na análise de requisitos em questão. Com o MER pronto, po-
demos identificar e validar informações com o cliente final que irá operar a aplicação
e também conseguimos “conversar” dentro de uma equipe técnica.
Após a definição correta do MER, partimos para o modelo lógico que podemos obter
fazendo o chamado mapeamento entre MER e o modelo relacional (MR). Como vi-
mos o modelo relacional é expresso utilizando tabelas de fato.
As tabelas em um MR especificam mais o projeto para o modelo físico, que se trata

do banco de dados prontamente arquitetado para ser definido e manipulado. Nesse
momento utiliza-se ferramentas como o MYSQL WorkBench para realizar essa tarefa
de forma diretamente auxiliada por essa ferramenta de software. O diagrama gerado
pela ferramenta é denominado como um diagrama entidade-relacionamento esten-
dido (EER).
Com nosso diagrama entidade-relacionamento em modelo lógico, partimos então

para criação física do banco de dados, utilizando a linguagem declarativa SQL. Atra-
vés da SQL, podemos definir dados através de declarações DDL a fim de criar nossos
objetos físicos, como o próprio esquema de banco de dados, todas as nossas tabelas
contendo também seu esquema de atributos e tipos.
Nesse ponto você pode se perguntar: onde entra a normalização?

74 SUMÁRIO
BANCO DE DADOS I
Justamente nesse momento entre criar inicialmente o diagrama lógico e a imple-

mentação física do banco de dados, podemos pensar na normalização de tabelas.
Mas é importante entender que a normalização não deve ser encarada como uma
regra de ouro ao qual é necessário a todo custo chegar até a quarta ou quinta forma
normal. A normalização é utilizada com intuito de refinar o banco de dados da forma
mais inteligível possível, para evitar problemas principalmente relacionados à redun-
dância de informação.
Nada impede também que a normalização seja aplicada em banco de dados já em

produção, mas o grande problema prático é normalizar um banco de dados com bai-
xíssima qualidade estrutural visando chegar a um banco de dados de alta qualidade.
Para isso não acontecer, a recomendação prática é normalizar tabelas inicialmente
na medida certa, (pense em 1FN, 2FN e alguns casos específicos 3FN) antes de se
iniciar o desenvolvimento da aplicação. Deve-se sempre levar em consideração o
porte da solução e sua visão futura. Um banco de dados altamente normalizado
também traz problemas, como por exemplo, de desempenho, sendo necessário rea-
lizar a chamada desnormalização.
O projeto de banco de dados está altamente alinhado com um projeto de desenvol-

vimento de aplicação. Uma aplicação que manipulam dados e informações úteis às
pessoas não é nada sem um banco de dados, e um banco de dados também não é
nada sem uma aplicação para fazer a interface com os usuários, concorda?
Ficaremos por aqui nos conceitos de projetos de banco de dados e normalização,

mas isso não quer dizer que você só deve ler essa simples introdução teórica. Qual-
quer assunto relacionado à tecnologia da informação requer extensa leitura de mui-
tas fontes como livros que estão a sua disposição no sistema Minha Biblioteca e bons
sites da internet.

SUMÁRIO 75
BANCO DE DADOS I
CONCLUSÃO
Nesta unidade você teve contato com os principais tópicos relacionados à normaliza-
ção de tabelas em banco de dados relacionais. Vimos de forma mais aprofundada as
três primeiras formas normais, e também foi apresentada a visão geral de um projeto
de banco de dados.

Bons estudos!

76 SUMÁRIO
BANCO DE DADOS I
UNIDADE 5
OBJETIVO
Ao final desta
unidade,
esperamos
que possa:
> Apontar o que é uma

visão em banco de dados
relacionais.
> Identificar vantagens na

utilização de visões.
> Aplicar comando de

criação de uma view
visualizando um exemplo.
> Apontar o que é uma visão

somente leitura e uma
visão atualizável.
> Aplicar comando de

inserção, alteração e
remoção em view.

SUMÁRIO 77
BANCO DE DADOS I
5 VISÕES EM BANCO DE
DADOS
Nessa unidade iremos introduzir o que são views, como podemos implementa-las
fisicamente em um banco de dados e quais são regras e declarações para operar IN-
SERT, UPDATE e DELETE através de visões. Faremos também uma abordagem geral
das principais vantagens da utilização de visões em banco de dados relacionais, para
com isso conseguirmos compreender quando podemos pensar nesse mecanismo
para construção e manutenção de aplicações que utilizam banco de dados.
5.1 VISÕES
Em banco de dados já em modelagem física, ou seja, constando tabelas e seus dados

já sendo relacionadas entre si através de chaves primárias e estrangeiras, podemos
criar consultas através do uso de Structured Query Language (SQL).
Com a linguagem SQL podemos criar as tabelas, popular dados e realizar consultas.
Tais consultas podem ser realizadas diretamente no sistema gerenciador de banco
de dados (SGBD) com uso de softwares clientes como o MySQLWorkBench que já
tivemos contato ou também através de linguagem de programação como em PHP,
por exemplo, onde a aplicação realiza as consultas de forma programada para fins
específicos dentro de um sistema final.
As visões em banco de dados, também chamada de Database View, proporcionam

a forma com que as consultas em SQL fiquem salvas, dessa forma criando resultados
virtuais das tabelas. Uma visão é uma apresentação personalizada dos dados que
estão armazenados em uma tabela ou mais de uma tabela.
Uma view pode ser entendida como uma maneira alternativa de observar os dados
de uma ou mais tabelas. De forma prática como iremos perceber no decorrer deste
conteúdo, uma view faz um encapsulamento de declarações SELECT da linguagem
SQL.

78 SUMÁRIO
BANCO DE DADOS I
Para que seja mais simples entender o funcionamento das views em banco de da-
dos, vamos abstrair um cenário de um banco de dados contendo alunos, professores,
disciplinas e notas dos alunos. Nesse banco de dados já temos dados populados tais
como: vários registros de professores, várias disciplinas e também os dados de diver-
sos alunos relacionados às disciplinas e suas notas.
Imagine que nesse cenário simples precisássemos consultar as notas de alunos, mas
que o resultado retornasse também o nome das disciplinas e nome dos professores.
Percebe-se que teríamos um SELECT fazendo uso de vários JOIN’s para relacionar os
dados dessas tabelas envolvidas nesse contexto.
A cada vez que se executar a declaração SELECT em SQL, teríamos o retorno dos
dados contendo as notas dos alunos, mas sempre teríamos que criar a mesma de-
claração SQL. Ou seja, se hoje eu preciso consultar as notas teria que escrever toda
a declaração SQL necessária para trazer esse retorno. Não seria mais inteligente essa
consulta ficar salva e quando eu precisar acessa-la basta que eu a chame de alguma
forma?
É isso que view nos proporciona. Criamos uma view e posteriormente sempre que
precisarmos daquele mesmo retorno, basta acessa-la. Obviamente o exemplo acima
foi um cenário para explicar como é uma view, mas elas possuem características mais
interessantes quanto a sua aplicação. Abaixo iremos exemplificar alguma delas.
Podemos aplicar restrições usando views, por exemplo, abstraindo que um dado de-
partamento de vendas dentro de uma empresa não precisa saber o salário do desen-
volvedor de sistemas que atua na empresa. Ou seja, podemos pensar nas views para
impor restrição versus dados.
Outro exemplo seria impor restrição de domínio, onde podemos restringir acesso de
certo usuário em um sistema, apresentando a ele apenas as colunas (domínios) ne-
cessárias, de certas tabelas do banco de dados.
Como vimos anteriormente, podemos também associar várias colunas usando JOIN
criando então uma “tabela virtual” com colunas de diversas tabelas distintas. Como
falamos: nome do professor de uma tabela, nome do aluno de outra, disciplina e nota
de outra (a) tabela(s).

SUMÁRIO 79
BANCO DE DADOS I
As views também podem ser usadas com a finalidade de agregação. Isso quer dizer
que podemos, por exemplo, criar uma visão para mostrar uma soma de gastos de
um setor de uma dada empresa, em relação a um determinado usuário dentro do
sistema. Usuário João do setor Y teve um gasto total de X.
De modo geral a utilização de views pode beneficiar muito uma aplicação criada, ou
seja, um sistema para uma empresa ou para usuários finais. É uma maneira inteligen-
te de organizar as consultas e tê-las armazenada afim de não repetir sempre mesmas
consultas ou restringir os dados de acordo com as especificações do software para
que atenda o esperado pelos usuários.
É importante ter em mente que as views exibem dados das

tabelas, mas não fazem armazenamento de dados. Além de
que as visões de dados somente existem no modelo físico, e
as suas colunas podem ser: colunas de tabelas, colunas de
outras visões ou declarações em SQL.
Segundo MACHADO (2014), temos que as visões em bancos de dados podem:
Incluir um subconjunto de colunas de uma tabela do banco. Incluir colunas

de múltiplas tabelas do banco. Ser baseada em outras visões em vez das tabe-
las do banco. Ser consultada, atualizada, inserida e apagada. Todas estas ações
afetam os dados armazenados nas tabelas do banco, com algumas restrições,
(...). Pode ser frequentemente alterada para se adequar às necessidades de
alteração sem exigir uma mudança para a tabela do banco subjacente. (Felipe
Nery Rodrigues Machado, 2014 p.222).
Antes de informamos como criar as visões, vamos listar algumas de suas vantagens
nos próximos tópicos.
5.2 VANTAGENS DA UTILIZAÇÃO DE VIEWS
Em banco de dados arquitetados de forma inteligível, com otimização de relações e

projetados para armazenar dados sem redundâncias, as views são ferramentas pode-
rosas principalmente quanto a tempo de retrabalho.

80 SUMÁRIO
BANCO DE DADOS I
Vamos listar abaixo diversos exemplos da utilização de views em projetos

físicos de banco de dados. Dessa forma, você conseguirá compreender as
formas como elas podem ser utilizadas em beneficio geral da solução que
envolve a necessidade de existir um banco de dados.
• Em softwares que precisam sempre recuperar dados em diversas par-

tes, é comum que tenhamos sempre as mesmas consultas. Criando
views escrevemos as consultas somente uma vez e as armazenamos
para acesso sempre que precisar, e logo, quando necessário realizar
manutenções nas consultas as fazemos somente em um local. A apli-
cação, ou seja, o sistema criado que utiliza o banco de dados acessa
as views da mesma maneira que faz através de consultas SELECT. Em
resumo, não é necessário sempre reescrever grandes consultas SQL
a todo o momento. Fazemos uma única vez e a armazenamos para
utilização quando se fizer necessário, dentro do software ou direta-
mente manipulando o SGBD.
• A velocidade de acesso é outra vantagem de usar visões em banco
de dados. A partir do momento que temos uma view compilada, o
conjunto de dados resultante da consulta, também conhecido como
recordset é mantido em uma tabela virtual, uma tabela temporária.
• As views também tem o benefício de mascarar a complexidade de
um banco de dados, pois consegue isolar do usuário essa complexi-
dade do usuário. Atributos, ou seja, as colunas das tabelas podem ter
referências fazendo com que os desenvolvedores consigam realizar
alterações em estruturas sem que se afete a interação do usuário de
banco de dados.
• Podemos também ter os benefícios de organização de dados para ex-
portação de dados para manipulação de outros softwares. De manei-
ra prática isso quer dizer, por exemplo, que você pode ter uma view de
uma consulta que relaciona vinte tabelas e o seu resultado poder ser
exportado facilmente para o Excel. Ou seja, podemos ter o chamado
dump automaticamente usando views.

SUMÁRIO 81
BANCO DE DADOS I
• Não menos importante, um administrador de banco de dados pode

definir que tais usuários acessem somente views específicas e não as
tabelas bases, diretamente. Dessa forma, as views também propor-
cionam a vantagem de gerenciar permissão de usuários de banco de
dados.
5.3 INTRODUÇÃO À CRIAÇÃO DE VIEWS
Da mesma forma que utilizamos a declaração CREATE utilizando DDL em SQL na

criação de tabelas físicas de banco de dados, o fazemos para criar views. Aqui se pres-
supõe que tal conceito de criação de tabelas já tenha sido assimilado.
Entendemos que nossas tabelas no modelo físico têm existência física e como já
abordamos precisamos criar tabelas que não façam uso de espaço físico, mas ao
mesmo que possam ser usadas como tabelas normais, como já conhecemos.
Assim como nas tabelas físicas, ou seja, em nossas tabelas reais em banco de dados
fazemos a criação das views através de SQL.
A sintaxe básica de criação de uma view é:
CREATE VIEW <nome da VIEW> (<nome da(s) coluna(s)>) AS
SELECT <nome da(s) coluna(s)> FROM <nome da tabela>
WHERE <condição> [WITH CHECK OPTION];
Dessa forma, temos uma visão particular da consulta SELECT, não sendo necessário
utilizar todo o conjunto das tabelas envolvidas.
Nos próximos tópicos vamos explorar os conceitos com exemplos práticos.

82 SUMÁRIO
BANCO DE DADOS I
5.4 EXEMPLO DE CRIAÇÃO E UTILIZAÇÃO DE

VIEWS
Vamos partir com um exemplo básico de um banco de dados de ordem de serviço

que possui as tabelas:
• OrdemServico
• Cliente
• Tecnico
• Os_Servico
• Servico
Para facilitar a compreensão, o diagrama da figura 37 exibe a estrutura lógica das

tabelas. Temos no diagrama o relacionamento entre cinco tabelas, sendo a tabela
Técnico para armazenar dados dos técnicos que realizam manutenção em equipa-
mentos, a tabela cliente para guardar dados básicos dos clientes, a tabela serviço que
informa, por exemplo, que a empresa realiza o serviço de manutenção de compu-
tadores e também a tabela os_servico que cria um relacionamento de muitos para
muitos (N para N) entre a tabela ordemservico e a tabela serviço, pois uma ordem de
serviço pode ter vários serviços e cada serviço pode ser executado para várias ordens.
Estamos mostrando iniciando a estrutura do banco de dados para você assimilar

mais a frente à questão da view que iremos demonstrar. Aqui não iremos tratar de
conceituação de chaves e relacionamentos. Estes conceitos você já teve acesso em
conteúdos passados nessa disciplina, inclusive utilizando este mesmo diagrama.
Para facilitar a compreensão, o diagrama da figura 1 exibe a estrutura lógica das tabe-
las. Temos no diagrama o relacionamento entre cinco tabelas, sendo a tabela Técnico
para armazenar dados dos técnicos que realizam manutenção em equipamentos, a
tabela cliente para guardar dados básicos dos clientes, a tabela serviço que informa,
por exemplo, que a empresa realiza o serviço de manutenção de computadores e
também a tabela os_servico que cria um relacionamento de muitos para muitos (N

SUMÁRIO 83
BANCO DE DADOS I
para N) entre a tabela ordemservico e a tabela serviço, pois uma ordem de serviço
pode ter vários serviços e cada serviço pode ser executado para várias ordens.
Estamos mostrando iniciando a estrutura do banco de dados para você assimilar

mais a frente à questão da view que iremos demonstrar. Aqui não iremos tratar de
conceituação de chaves e relacionamentos. Estes conceitos você já teve acesso em
conteúdos passados nessa disciplina, inclusive utilizando este mesmo diagrama.
FIGURA 37 - DIAGRAMA ER BANCO DE DADOS DIDÁTICO - ORDEM DE SERVIÇO
Fonte: Elaborado pelo autor via ferramenta MySQLWorkBench.
Após a implementação física do modelo conforme figura 37, utilizando para isso de-
clarações DDL em SQL, temos conforme figura na figura 38 os dados populados.

84 SUMÁRIO
BANCO DE DADOS I
FIGURA 38 - DADOS POPULADOS NAS TABELAS FÍSICAS
Fonte: Elaborado pelo autor via ferramenta MySQLWorkBench.
Agora, sabendo da estrutura desse banco de dados e enxergando os dados populdos

em suas tabelas podemos pensar em uma consulta que nos retorne:
O nome do cliente e seu telefone, a descrição do equipamento que deixou para

manutenção, o diagnóstico que o técnico identificou no equipamento e o nome
do técnico que está tratando desse equipamento do cliente.
Ou seja, podemos pensar que esse retorno seria um relatório tabelado para o pro-
prietário desta empresa identificar dados relacionados afim de trazer algum benefí-
cio de controle para seu negócio. Perceba que conforme marcamos em negrito são
especificados campos (colunas) de mais de uma tabela, pois sabemos que em cada
tabela temos apenas os dados do contexto dela própria. Não temos, por exemplo, o
nome do cliente e telefone, juntamente com os dados de descrição de equipamento
e nome do técnico, em apenas uma única tabela.

SUMÁRIO 85
BANCO DE DADOS I
Para essa consulta é necessário criar uma declaração SELECT utilizando JOIN, relacio-
nando então todas as tabelas desse caso. Chegamos então na seguinte declaração:
SELECT cli.nome as ‘Cliente’, cli.telefone,
os.desc_equipamento, os.desc_diagnostico,
tec.nome as ‘Técnico’
FROM ordemservico as os
JOIN cliente as cli on cli.idcliente = os.cliente_idcliente
JOIN tecnico as tec on tec.idtecnico = os.tecnico_idtecnico;
Ao processar essa consulta teremos exatamente o que precisamos, mas agora imagi-
ne como seria mais simples sempre que quiséssemos essa informação, apenas cha-
mássemos uma view, ao invés de criar toda essa consulta. Para isso fazemos a criação
conforme a seguinte declaração:
CREATE VIEW lista_os AS
SELECT cli.nome as ‘Cliente’, cli.telefone,
os.desc_equipamento, os.desc_diagnostico,
tec.nome as ‘Técnico’
FROM ordemservico as os
JOIN cliente as cli on cli.idcliente = os.cliente_idcliente
JOIN tecnico as tec on tec.idtecnico = os.tecnico_idtecnico;
O que mudou foi que na primeira linha temos: CREATE VIEW lista_os AS
Dessa forma informamos ao SGBD que estamos criando uma view chamada lista_os
que sempre que for chamada irá retornar os dados conforme o SELECT. Fazendo isso,
quando for necessário retornar esses dados, precisamos apenas da simples declara-
ção SQL:
SELECT * FROM lista_os;

86 SUMÁRIO
BANCO DE DADOS I
Perceba que o lista_os passa a ter um “sentimento” de tabela física, assim como te-
mos a tabela cliente e poderíamos lista-la, através de: SELECT * FROM cliente;
A grande diferença é que temos uma tabela montada com diversos campos (colu-
nas) de diferentes tabelas, para nos auxiliar mais facilmente dentro de um software
ou também manipulando diretamente o SGBD. Temos então uma tabela virtual.
Como sendo uma tabela virtual, baseada em outra(a) tabela(s), uma view
passa a não ser processada corretamente caso a estrutura da(s) tabela(s)
base(s) for(em) alterada(s). Ficou curioso? Implementando esse banco de
dados fisicamente e, por exemplo, removendo a coluna telefone da tabela
cliente, ao ser processada a view lista_os, teremos um erro número 1356 no
Mysql, pois a view está fazendo referencia a uma coluna que não pode usar.
Obviamente, pois na declaração da view informamos que precisamos do
retorno do telefone do cliente.
5.5 ATUALIZAÇÃO DE DADOS ATRAVÉS DE VIEWS
Antes de exemplificar o uso de views para atualização de dados em tabelas bases,

primeiramente temos que entender que as visões podem ser:
1. Atualizáveis
2. Somente leitura
Visões somente leitura permitem apenas que seja utilizada em declarações SELECT
e dessa forma uma visão somente leitura não aceita que seja utilizada declarações de
INSERT, de UPDATE e de DELETE.
Já uma visão que permite serem usadas tais instruções de modificação de dados é
denominada como visão atualizável. Vale lembrar que qualquer visão é no mínimo

SUMÁRIO 87
BANCO DE DADOS I
somente leitura.
Nas visões atualizáveis podemos então inserir, alterar e excluir registros em tabelas
bases e para isso é necessário operarmos tais comandos de modificação na visão.
Assim, sempre que uma linha é atualizada na visão, uma operação que corresponde
à atualização da tabela base é executada.
Em uma visão que envolva somente uma tabela, para que seja atualizável temos as
seguintes regras:
1. A visão deve incluir a chave primária (PK) da tabela base.
2. Todos os campos que são requeridos, ou seja, definidos como NOT NULL da ta-
bela base sem que haja um valor padrão devem estar presentes na visão.
3. Ao consultar a visão não existir palavras-chave GROUP BY ou também DISTINCT
Conforme figura 39 temos um exemplo de uma visão atualizável constando somente

uma tabela. Perceba que a figura 39 mostra o CREATE da view e também o retorno
da execução da mesma.
FIGURA 39 - EXEMPLO DE VISÃO ATUALIZÁVEL EM SOMENTE UMA TABELA
Fonte: MANNINO, Michael V. 2014 p.347
Uma visão somente leitura da mesma tabela Professor conforme exemplificado na

figura 3, seria conforme figura 4. Note a ausência da chave primária da tabela. Figura

88 SUMÁRIO
BANCO DE DADOS I
FIGURA 40 - EXEMPLO DE VISÃO SOMENTE LEITURA
Partindo do entendimento de visões atualizáveis e somente leitura, podemos então

entender como proceder para alterar registros utilizando as visões.
Conforme figura 41, temos um INSERT de dados nas tabelas bases que compõe a
view. Perceba:
FIGURA 41 - INSERÇÃO EM VISÃO
Conforme declaração INSERT da figura 41, temos a inserção de uma nova linha de
professor dentro do depto denominado como ADM.
Em visões atualizáveis, podemos também operar declarações UPDATE e também de

DELETE, conforme exemplo presente na figura 42 e 43 respectivamente.
FIGURA 42 - ALTERAÇÃO DE DADOS EM VISÃO

SUMÁRIO 89
BANCO DE DADOS I
FIGURA 43 - REMOVENDO DADOS ATRAVÉS DE VISÃO
Na figura 42 estamos alterando registros concedendo a professores que são assisten-

tes 10 por cento de aumento em seus salários. (Salario * 1,1). Já na figura 43 estamos
operando um delete, excluindo um professor através de seu CPF.
É importante saber que certas modificações de visões tem

efeitos que podem não ser desejáveis, causando problemas,
pois pode alterar linhas correspondentes da tabela base.
Segundo MANNINO (2014), temos tais efeitos colaterais:
Algumas modificações feitas em visões atualizáveis podem ser problemáticas,

assim como mostra o Exemplo 10.17 (...). A instrução de atualização mostrada
no Exemplo 10.17 altera o departamento da última linha (Victoria Emmanuel)
na visão e na linha correspondente na tabela base. Depois de gerada nova-
mente a visão, no entanto, a linha alterada desaparece. A atualização provoca
o efeito colateral de fazer a linha desaparecer da visão. Esse tipo de efeito co-
lateral pode ocorrer sempre que uma coluna na cláusula WHERE da definição
de visão for alterada por uma instrução UPDATE. O Exemplo 10.17 atualiza a
coluna DeptoProf, coluna utilizada na cláusula WHERE da definição da visão
Visao1_Prof. (Michael V. MANNINO, 2014 p.348)
Você poderá realizar a leitura complementar a respeito do

exemplo 10.17 informado pelo autor, consultando o livro Pro-
jeto, Desenvolvimento de Aplicações e Administração de ban-
co de dados. Este livro está disponível no sistema minha bi-
blioteca ao qual você tem acesso.

90 SUMÁRIO
BANCO DE DADOS I
CONCLUSÃO
Nesta unidade você teve contato com os principais tópicos relacionados a visões em
banco de dados relacionais. Abordamos diversas vantagens no uso de visões e vimos
o que são as visões de modo prático, aplicando exemplo de criação e utilização de
uma view. Além disso, foram apresentadas a você formas básicas de atualização de
registros utilizando views, através de declarações INSERT, UPDATE e DELETE.

Bons estudos!

SUMÁRIO 91
BANCO DE DADOS I
UNIDADE 6
OBJETIVO
Ao final desta
unidade,
esperamos
que possa:
> Apontar o que é uma transação

em banco de dados relacionais.
> Narrar o que são propriedades

ACID em transações.
> Identificar o que é o serviço de

recuperação e transparência em
SGBD
> Aplicar declarações de transação

visualizando um exemplo básico.
> Narrar o que é um banco de

dados distribuído.

92 SUMÁRIO
BANCO DE DADOS I
6 TRANSAÇÕES E BANCO DE
DADOS DISTRIBUÍDOS
Nessa unidade iremos introduzir o que são transactions em banco de dados, como
podemos implementa-las. Faremos também uma abordagem geral da conceituação
de banco de dados distribuídos, para com isso conseguirmos compreender quando
podemos pensar nesse mecanismo para construção e manutenção de aplicações
que utilizam banco de dados.
6.1 TRANSAÇÕES
Comumente transações são entendidas como forma de interação na condução de

negócios, como por exemplo, adquirir uma motocicleta em uma concessionária de
veículos. Dessa forma é fácil associar a palavra transação a questões financeiras, uma
transação de compra ou venda de algo.
Em se tratando de banco de dados, transação pode ser defini-

da como um conjunto/grupo de procedimentos, para serem
executados, ao qual o usuário tem percepção como sendo
uma única ação.
Diversos autores explicam esse mesmo conceito, como podemos perceber através da
visão de Michael Mannino (2008):
Uma transação de banco de dados envolve um conjunto de operações que

devem ser processadas como uma unidade de trabalho. As transações devem
ser processadas confiavelmente, para que nenhum dado se perca em decor-
rência de múltiplos usuários e falhas de sistema. (Michael V. Mannino, 2008
p.523).
Para completar a conceituação, temos também o papel essencial dos SGBDs em for-
necer serviços de recuperação e também de controle de concorrência para processar
transações de forma eficiente.

SUMÁRIO 93
BANCO DE DADOS I
6.1.1 PROPRIEDADES
Para fornecer os serviços de recuperação e controle, os sistemas gerenciadores de

banco de dados precisam assegurar que as transações obedeçam a propriedades.
São essas propriedades denominadas pela sigla ACID onde cada letra significa res-
pectivamente: atomicidade, consistência, isolamento e durabilidade.
Abaixo temos o detalhamento de cada uma dessas propriedades:
1. Propriedade de atomicidade: A transação não pode ser subdividida. Isso quer

dizer que toda a transação deve ser executada ou nada dela deverá executada.
Trazendo essa propriedade para o mundo real, um sistema

bancário em um caixa eletrônico não debitará de uma conta
de um cliente sem que também realize o crédito em uma con-
ta correspondente, em um caso de uma transferência de valo-
res. Caso algum problema ocorra, nada é realizado. Ou seja, o
valor não pode sair da conta do remetente. Mudanças parciais
realizadas devem ser desfeitas em caso de problemas.
2. Propriedade de consistência: Essa propriedade diz que caso restrições forem ver-
dadeiras antes do início da transação, elas serão verdadeiras após for concluída.
Segundo Mannino (2008), podemos exemplificar também com

um cenário financeiro envolvendo transação na conta de um
cliente, onde caso antes de uma transação a conta de um clien-
te estiver com o saldo equilibrado (positivo), o saldo da conta
estará equilibrado (não negativo) após a transação. Caso contrá-
rio, a transação será rejeitada e nenhuma alteração terá efeito.
3. Propriedade de isolamento: Uma transação não faz interferência com ou-

tras transações, somente se permitida. Dessa maneira, uma transação não

94 SUMÁRIO
BANCO DE DADOS I
deve sobrescrever alterações realizadas por outra. Além do que se pode

restringir uma transação de maneira a não interferir em outros aspec-
tos, como enxergar mudanças de caráter temporário de outras transações.
Ainda utilizando um exemplo do mundo real em um cenário

bancário para exemplificar essa propriedade, temos que um
cônjuge (marido/esposa) de um correntista ligado à conta ban-
cária não deverá saber que seu parceiro está realizando uma
retirada de valores da conta enquanto o caixa eletrônico em
questão não terminar a transação.
4. Propriedade de durabilidade: Impõe que qualquer resultado de alteração de

uma transação deverá ser permanente. Assim, depois que a transação for reali-
zada, nenhuma falha irá apagar a alteração realizada.
Seguindo o raciocínio de contas bancárias, podemos exemplifi-

car essa propriedade com o fato de que caso o ambiente com-
putacional do banco falhar, por exemplo, dez minutos após a
transação ser realizada, os efeitos da transação estarão registra-
dos no banco de dados.
6.1.2 SERVIÇOS DE TRANSPARÊNCIA
É importante compreender que para os SGBD’s assegurarem as propriedades ACID,

conforme detalhamos anteriormente, é necessário existir dois serviços transparentes
aos programadores e analistas de tecnologia.
Transparência nesse contexto quer dizer que se pode enxer-

gar através de um dado objeto, colocando detalhes internos
invisíveis. Logo, no SGBD os detalhes internos dos serviços de
transação serão invisíveis, melhorando a produtividade de
programadores, por exemplo.

SUMÁRIO 95
BANCO DE DADOS I
Assim, os SGBDs operam com os serviços de transparência a recuperação e transpa-

rência de concorrência, conforme será detalhado a seguir.
1. Transparência de recuperação: O SGBD restaura o banco de dados ao estado

anterior ao momento da falha, caso ocorra.
2. Transparência de concorrência: Os usuários utilizam um mesmo banco de da-

dos como sendo um sistema exclusivo para somente ele próprio, ainda que exis-
tam usuários simultâneos utilizando o mesmo banco de dados. Isso quer dizer
que, por exemplo, em um cenário de reserva de um voo que seja concorrido
em uma determinada companhia aérea, o SGBD garante que os usuários não
sobrescrevam o trabalho um do outro.
6.1.3 EXEMPLOS DE TRANSAÇÃO EM BANCO DE

DADOS
Vamos perceber como se cria as transações em banco de dados utilizando exemplos

simples para você compreender como acontece a composição desse mecanismo.
Veja abaixo o quadro 1, apresentando um pseudocódigo de uma transação. Poste-

riormente ao quadro você terá um detalhamento das principais declarações contidas
nesse exemplo.
QUADRO 4 - EXEMPLO DE TRANSAÇÃO EM PSEUDOCÓDIGO
LINHA DECLARAÇÃO/COMANDO DA TRANSAÇÃO

1 START TRANSACTION
2 EXIBIR saudações
OBTER número da conta, número de identifica-
3
ção pessoal, tipo e quantia.
4 SELECT número da conta, tipo, balance saldo.
5 SE o saldo é suficiente ENTÃO
6 UPDATE conta lançando o débito
7 UPDATE conta lançando o crédito
8 INSERT registro de lançamento
9 EXIBIR mensagem final e liberar o dinheiro
10 SENÃO
11 ESCREVER mensagem de erro

96 SUMÁRIO
BANCO DE DADOS I
LINHA DECLARAÇÃO/COMANDO DA TRANSAÇÃO

12 FIM SE
13 ERROR: ROLLBACK
14 COMMIT
Fonte: Elaborado pelo autor, adaptado de MANNINO (2008 p.571).
Como se percebe no quadro 1, a transação envolve instruções em SQL de SELECT,

INSERT, UPDATE e quando necessário também de DELETE. Nas linhas 4,6,7, e temos
declarações SQL utilizando SELECT, UPDATE e INSERT.
Percebe-se também além dos comandos de START TRANSACTION e COMMIT, a

instrução ROLLBACK, operando para desfazer as ações em casos de erros, mas não
apenas uma a uma e sim a uma sequencia de ações. Portanto, essa instrução faz com
que todos os efeitos de uma transação sejam removidos, e dessa maneira o banco de
dados é restaurado ao estado anterior da transação ser realizada.
Segundo MANNINO (2008), temos que:
As instruções de manipulação de exceções fazem parte das linguagens de

programação, como Java e Visual Basic. A manipulação de exceções permite
que erros não previstos – por exemplo, erros de comunicação – sejam proces-
sados separadamente da lógica normal da transação. (Michael V. Mannino,
2008 p.517)
Para completar a absorção desse conhecimento tomando como base o exemplo do

quadro 1, temos também as declarações START TRANSACTION e COMMIT que defi-
nem as instruções em uma transação.
Vale ressaltar que alguns tipos SGBDs usam a palavra- chave

BEGIN, em vez de START e também que alguns deles, como
o Oracle, não utilizam declaração para iniciar uma transação.
Uma nova transação inicia com o comando SQL subsequente
a uma instrução COMMIT.
Para aproximar mais esse conhecimento iremos demonstrar um exemplo prático uti-
lizando MySQL ao qual já estamos habituados dentro dessa disciplina.

SUMÁRIO 97
BANCO DE DADOS I
Imagine que em um dado banco de dados, já implementado fisicamente, temos

uma tabela cliente. Nessa tabela temos os atributos:
• idcliente, nome, empresa e telefone.
Vamos imaginar que precisamos alterar o atributo empresa em todos os registros,

alterando todos os registros que tiverem o valor ABC Advocacia, para JC Advocacia.
É fácil imaginar que precisamos apenas de uma declaração UPDATE, conforme abai-
xo:
UPDATE cliente SET empresa = ‘JC Advocacia’ WHERE empresa = ‘ABC Advocacia’;
Mas vamos supor que nessa tabela existem registros de dez mil clientes e você gos-
taria de perceber essa alteração utilizando ROLLBACK a partir da criação de uma
simples transação. Dessa forma teríamos:
START TRANSACTION;
UPDATE cliente SET empresa = ‘JC Advocacia’
WHERE empresa = ‘ABC Advocacia’;
SELECT * FROM cliente;
ROLLBACK;
Ao executar essa transaction o SGBD irá operar o UPDATE e em sequência exibir to-
dos os clientes apresentando a alteração de nome da empresa (devido ao SELECT
também dentro da transação), mas como temos ROLLBACK na implementação da
transação o banco realmente não armazenou a alteração.
Caso quiséssemos que a alteração fosse realizada, bastava alterar ROOLBACK para
COMMIT. Esse foi um exemplo básico e didático para te aproximar mais do conceito
de transações em banco de dados. Conforme você já tem conhecimento, poderá
testar e implementar essa e outras formas de transações em seu próprio banco de
dados, utilizando o XAMPP e a ferramenta MySQLWorkBench.

98 SUMÁRIO
BANCO DE DADOS I
Caso o MySQL apresente o erro 1175 na execução da sua

transação, significa que o safe update mode (modo seguro
de alterações) está ativo, sendo permitido operar alterações
somente se a chave-primária estiver informada na clausula
WHERE. Conforme o exemplo que apresentamos, não te-
mos a chave-primária da tabela cliente na cláusula WHERE
e dessa forma o erro acontece. Para desabilitar o safe update
mode, você poderá operar a declaração: SET SQL_SAFE_UP-
DATES = 0;
Outra questão relativa a transações em banco de dados MySQL é o fato do tipo de

engine das tabelas. Não iremos entrar em detalhes nesse ponto aqui neste conteú-
do, apenas iremos informar que uma engine que permite a utilização de transações
em MySQL é a InnoDB. A figura abaixo mostra como podemos verificar a engine da
tabela.
FIGURA 44 - VERIFICANDO ENGINE DA TABELA CLIENTE NO MYSQLWORKBENCH
Fonte: Elaborado pelo autor.
Com o MySQLWorkBench aberto e já conectado na base de dados, clicamos com

o botão da direita (1) na tabela cliente, e posteriormente clicamos na opção Table
Inspector do menu (2). Feito isso será apresentada diversas informações da tabela,
incluindo a engine (3).

SUMÁRIO 99
BANCO DE DADOS I
Você poderá pesquisar mais a respeito de diferenças de engine’s consultando os li-

vros disponíveis na bibliografia deste material, ou também através de sites confiáveis
na internet.
6.2 BANCO DE DADOS DISTRIBUÍDOS
Para finalizar nosso estudo nessa disciplina iremos fazer uma abordagem introdutó-
ria sobre banco de dados distribuídos.
Trata-se de um conjunto de bases de dados que se interligam, sendo distribuídas em

uma rede de computadores que por sua vez, pode ter nós distantes geograficamente.
Em um sistema de banco de dados distribuído é imposto que o sistema deve tornar o

impacto da distribuição dos dados transparente. Dessa forma os usuários continuam
enxergando o banco de maneira integral.
São implementados com a utilização de um SGBDD, ou seja, um sistema gerencia-

dor de banco de dados distribuído, que em resumo estendem as funções/facilidades
resultando em um armazenamento de dados que possa ser dividido em nós, ou seja,
diversos locais físicos.
Através dessa técnica temos conseguimos que o sistema adote um crescimento mo-
dular, aumentando com isso a confiabilidade com a replicação de partes críticas do
banco.
FIGURA 45 - ABSTRAÇÃO DE BANCO DE DADOS DISTRIBUÍDOS
Fonte: SHUTTERSTOCK, 2018

100 SUMÁRIO
BANCO DE DADOS I
Em relação aos tipos de banco de dados distribuídos existen-

tes, temos duas classificações: homogêneos e heterogêneos.
Sendo o homogêneo compostos pelos mesmos bancos de
dados, e os heterogêneos compostos por mais de um tipo de
banco de dados.
De forma prática, temos SGBD’s locais apresentando ligação com um SGBD global.
Conforme quadro 5, temos as formas de armazenamento em banco de dados distri-

buídos.
QUADRO 5 - FORMAS DE ARMAZENAMENTO DE BANCO DE DADOS DISTRIBUÍDOS
FORMA DESCRIÇÃO
Cada réplica é armazenada em local diferente,
com isso se resulta na replicação dos dados. O
Replicação
sistema por sua vez, alimenta réplicas idênticas
da relação.
Cópias de uma relação alterada, ou seja, seus
fragmentos devem ser atualizados antes da tran-
Replicação síncrona sação que realizou modificação realizar uma de-
claração commit. Assim, a distribuição dos da-
dos se apresenta transparente para os usuários.
Cópias de uma relação modificada só são atuali-
zadas a cada X tempo definido, ou seja, apresen-
Replicação assíncrona tando periodicidade. Assim as réplicas podem
se apresentar inconsistentes por algum intervalo
de tempo.
A relação é dividida em diversos fragmentos,
onde cada um deles é mantido em um local di-
Fragmentação
ferente. Existem duas maneiras de realizar a frag-
mentação: fragmentação horizontal e vertical.
A relação é dividida em várias partes, e o sistema
Replicação e fragmentação por sua vez mantém diversas réplicas de cada
um dos fragmentos.
Existem diversas vantagens na adoção de banco de dados distribuídos, as quais po-

dem citar:
1. Reflexão da estrutura organizacional;
2. Autonomia Local;

SUMÁRIO 101
BANCO DE DADOS I
3. Disponibilidade maior;
4. Desempenho melhorado;
5. Economia;
6. Modularidade;
Mas em contra partida, temos as seguintes desvantagens:
1. Complexidade do trabalho desenvolvido pelo administrador de banco de da-

dos.
2. Implantação mais cara com custo extra de trabalho;
3. Segurança dos fragmentos de banco de dados remotos;
4. Difícil de manter a integridade
5. Inexperiência de equipe relacionada a dificuldades no gerenciamento.
6. Relativa falta de padrões;
7. Design complexo do banco
CONCLUSÃO
Nesta unidade você teve contato com os principais tópicos relacionados a transações
em banco de dados relacionais. Abordamos as propriedades de transações, os ser-
viços necessários de um SGBD para operar tal mecanismo de forma transparente e
também vimos um exemplo básico de transaction utilizando o MySQL. Além disso,
foi apresentada a você a introdução a respeito de banco de dados distribuídos.

Um grande abraço!

102 SUMÁRIO
BANCO DE DADOS I
REFERÊNCIAS
ALVES, William Pereira. Banco de dados. São Paulo: Editora Saraiva, 2014.
CARDOSO, Virgínia M. Sistemas de banco de dados. 1. ed. São Paulo: Saraiva, 2008.
HEUSER, Carlos Alberto. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2011.
MACHADO, Felipe Nery Rodrigues. Banco de dados: projeto e implementação. São Pau-
lo: Érica, 2014.
MANNINO, Michael V. Projeto, desenvolvimento de aplicações e administração de ban-

co de dados. Porto Alegre: AMGH, 2008.
RAMAKRISHNAN, Raghu; GEHRKE, Johannes. Sistemas de gerenciamento de banco de

dados. Porto Alegre: Grupo A, 2008.
SOARES, Walace. PHP 5 - conceitos, programação e integração com banco de dados.

São Paulo: Érica, 2013.
SOFFNER, Renato. Algoritmos e programação em linguagem C. 1. ed. São Paulo: Saraiva,

2013.

SUMÁRIO 103
BANCO DE DADOS I
CONHEÇA TAMBÉM NOSSOS CURSOS DE PÓS-GRADUAÇÃO A DISTÂNCIA NAS ÁREAS DE:
SAÚDE • EDUCAÇÃO • DIREITO • GESTÃO E NEGÓCIOS
EAD.MU LTIVIX.EDU.BR
104 SUMÁRIO

21-Banco de Dados I PDF

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

21-Banco de Dados I PDF

Enviado por

Direitos autorais:

Formatos disponíveis

BANCO DE DADOS I

FACULDADE CAPIXABA DA SERRA/EAD

GRUPO A Faculdade Multivix está presente de norte a sul

Atualmente, a Multivix está entre o seleto

Estes resultados acadêmicos colocam

Formar profissionais com consciência cida-

Ser uma Instituição de Ensino Superior reconheci-

FACULDADE CAPIXABA DA SERRA/EAD

FACULDADE CAPIXABA DA SERRA • MULTIVIX

Diretor Executivo Revisão de Língua Portuguesa

Diretora Acadêmica Revisão Técnica

Conselho Editorial Multivix Educação a Distância

BIBLIOTECA MULTIVIX (Dados de publicação na fonte)

Costa, Charles Edward.

Catalogação: Biblioteca Central Anisio Teixeira – Multivix Serra

As imagens e ilustrações utilizadas nesta apostila foram obtidas no site: http://br.freepik.com

FACULDADE CAPIXABA DA SERRA/EAD

APRESENTAÇÃO Aluno (a) Multivix,

DA DIREÇÃO Estamos muito felizes por você agora fazer parte

EXECUTIVA Espírito Santo e principalmente por ter escolhido a

A Faculdade Multivix possui unidades em Cachoei-

Além da qualidade de ensino já comprova-

Entendemos que a educação de qualidade sempre

FACULDADE CAPIXABA DA SERRA/EAD

Caro (a) aluno (a) seja bem-vindo(a) a disciplina Banco de Dados.

Ao lado da programação e desenvolvimento de sistemas, o banco de dados é uma

Ao final desta disciplina, esperamos que você:

• Descreva conceitos básicos de banco de dados como a arquitetura de um sistema

• Narre a modelagem de Dados e os modelos: relacional, hierárquicos e de redes.

• Aplique o básico de SQL - linguagem de definição e manipulação de dados.

• Descreva sobre projeto de banco de dados Relacional, dependência Funcional e

• Discuta a normalização, visões e integração de visões.

• Descreva o que são transações em banco de dados.

• Esclareça o que são banco de dados distribuídos.

FACULDADE CAPIXABA DA SERRA/EAD

>>FIGURA 2 - Representação de um sistema de banco de dados 17

>>FIGURA 3 - Entidades e atributos 20

>>FIGURA 4 - Tipos diferentes de atributos 21

>>FIGURA 5 - Tipos diferentes de atributos 22

>>FIGURA 6 - Relacionamento entre duas entidades 22

>>FIGURA 7 - Relacionamento UM para UM 23

>>FIGURA 8 - Relacionamento UM para N 24

>>FIGURA 9 - Explicação do relacionamento UM para N 24

>>FIGURA 10 - Relacionamento N para N 25

>>FIGURA 11 - Exemplo de modelo entidade-relacionamento (MER) 26

>>FIGURA 12 - Administrador de banco de dados 26

>>FIGURA 13 - Modelo de rede 32

>>FIGURA 14 - Modelo hierárquico 33

>>FIGURA 15 - Tabela no modelo relacional 36

>>FIGURA 16 - Tabela populada 36

>>FIGURA 17 - Tabela populada 38

>>FIGURA 18 - Evidenciando a chave estrangeira 39

>>FIGURA 19 - MER com cardinalidade 1 para 1 40

>>FIGURA 20 - MR com cardinalidade (1 para 1), apresentando dois casos 40

>>FIGURA 21 - Tabelas populadas do MR (1 para 1), apresentando dois casos 40

>>FIGURA 22 - MR (1 para N) e tabela populada 41

>>FIGURA 23 - Mapeando N para N cria-se nova tabela (Professores-Disciplinas) 42

>>FIGURA 24 - Tabelas populadas em cardinalidade N para N 42

>>FIGURA 25 - Ana (uma professora) leciona várias disciplinas 43

>>FIGURA 26 - Música (uma disciplina) é lecionada por vários professores 44

>>FIGURA 27 - Exemplo de MR representado de forma padronizada 45

>>FIGURA 28 - Comando CREATE TABLE explicado 51