Banco Dados I

Universidade do Sul de Santa Catarina
Banco de Dados I
Disciplina na modalidade a distância
Palhoça
UnisulVirtual
2011
Créditos
Universidade do Sul de Santa Catarina – Campus UnisulVirtual – Educação Superior a Distância
Avenida dos Lagos, 41 – Cidade Universitária Pedra Branca | Palhoça – SC | 88137-900 | Fone/fax: (48) 3279-1242 e 3279-1271 | E-mail: cursovirtual@unisul.br | Site: www.unisul.br/unisulvirtual
Reitor Unisul Assistente e Auxiliar de Luana Borges da Silva Gerência de Desenho Jeferson Pandolfo
Ailton Nazareno Soares Coordenação Luana Tarsila Hellmann e Desenvolvimento de Karine Augusta Zanoni
Maria de Fátima Martins (Assistente) Luíza Koing Zumblick Materiais Didáticos Marcia Luz de Oliveira
Vice-Reitor Fabiana Lange Patricio Maria José Rossetti Márcia Loch (Gerente)
Tânia Regina Goularte Waltemann Marilene de Fátima Capeleto Assuntos Jurídicos
Sebastião Salésio Heerdt Ana Denise Goularte de Souza Bruno Lucion Roso
Patricia A. Pereira de Carvalho Desenho Educacional
Chefe de Gabinete da Paulo Lisboa Cordeiro Cristina Klipp de Oliveira (Coord. Grad./DAD) Marketing Estratégico
Coordenadores Graduação Silvana Souza da Cruz (Coord. Pós/Ext.)
Reitoria Adriano Sérgio da Cunha Paulo Mauricio Silveira Bubalo Rafael Bavaresco Bongiolo
Rosângela Mara Siegel Aline Cassol Daga
Willian Máximo Aloísio José Rodrigues Ana Cláudia Taú Portal e Comunicação
Ana Luísa Mülbert Simone Torres de Oliveira
Vanessa Pereira Santos Metzker Carmelita Schulze Catia Melissa Silveira Rodrigues
Pró-Reitora Acadêmica Ana Paula R. Pacheco Carolina Hoeller da Silva Boeing Andreia Drewes
Arthur Beck Neto Vanilda Liordina Heerdt
Miriam de Fátima Bora Rosa Eloísa Machado Seemann Luiz Felipe Buchmann Figueiredo
Bernardino José da Silva Gestão Documental Flavia Lumi Matuzawa Marcelo Barcelos
Pró-Reitor de Administração Catia Melissa S. Rodrigues Lamuniê Souza (Coord.) Gislaine Martins Rafael Pessi
Fabian Martins de Castro Charles Cesconetto Clair Maria Cardoso Isabel Zoldan da Veiga Rambo
Diva Marília Flemming Daniel Lucas de Medeiros Jaqueline de Souza Tartari Gerência de Produção
Pró-Reitor de Ensino Fabiano Ceretta Eduardo Rodrigues João Marcos de Souza Alves Arthur Emmanuel F. Silveira (Gerente)
José Carlos da Silva Junior Guilherme Henrique Koerich Francini Ferreira Dias
Mauri Luiz Heerdt Horácio Dutra Mello Josiane Leal
Leandro Romanó Bamberg
Letícia Laurindo de Bonfim Design Visual
Itamar Pedro Bevilaqua Marília Locks Fernandes
Campus Universitário de Jairo Afonso Henkes
Lygia Pereira Pedro Paulo Alves Teixeira (Coord.)
Tubarão Lis Airê Fogolari Adriana Ferreira dos Santos
Janaína Baeta Neves Gerência Administrativa e Luiz Henrique Milani Queriquelli
Diretora Jardel Mendes Vieira Financeira Alex Sandro Xavier
Milene Pacheco Kindermann Marina Melhado Gomes da Silva Alice Demaria Silva
Joel Irineu Lohn Renato André Luz (Gerente) Marina Cabeda Egger Moellwald
Jorge Alexandre N. Cardoso Ana Luise Wehrle Anne Cristyne Pereira
Campus Universitário da Melina de La Barrera Ayres Cristiano Neri Gonçalves Ribeiro
José Carlos N. Oliveira Anderson Zandré Prudêncio Michele Antunes Corrêa
Grande Florianópolis José Gabriel da Silva Daniel Contessa Lisboa Daiana Ferreira Cassanego
Nágila Hinckel Diogo Rafael da Silva
Diretor José Humberto D. Toledo Naiara Jeremias da Rocha Pâmella Rocha Flores da Silva
Hércules Nunes de Araújo Joseane Borges de Miranda Rafael Bourdot Back Edison Rodrigo Valim
Rafael Araújo Saldanha Frederico Trilha
Luciana Manfroi Thais Helena Bonetti Roberta de Fátima Martins
Campus Universitário Luiz G. Buchmann Figueiredo Valmir Venício Inácio Higor Ghisi Luciano
Roseli Aparecida Rocha Moterle Jordana Paula Schulka
UnisulVirtual Marciel Evangelista Catâneo Sabrina Bleicher
Maria Cristina S. Veit Gerência de Ensino, Pesquisa Marcelo Neri da Silva
Diretora Sabrina Paula Soares Scaranto Nelson Rosa
Maria da Graça Poyer e Extensão Viviane Bastos
Jucimara Roesler Mauro Faccioni Filho Oberdan Porto Leal Piantino
Moacir Heerdt (Gerente) Patrícia Fragnani de Morais
Moacir Fogaça Aracelli Araldi Acessibilidade
Nélio Herzmann Vanessa de Andrade Manoel (Coord.) Multimídia
Equipe UnisulVirtual Onei Tadeu Dutra Elaboração de Projeto e Letícia Regiane Da Silva Tobal
Reconhecimento de Curso Sérgio Giron (Coord.)
Patrícia Fontanella Mariella Gloria Rodrigues Dandara Lemos Reynaldo
Diretora Adjunta Rogério Santos da Costa Diane Dal Mago
Patrícia Alberton Vanderlei Brasil Avaliação da aprendizagem Cleber Magri
Rosa Beatriz M. Pinheiro Fernando Gustav Soares Lima
Tatiana Lee Marques Francielle Arruda Rampelotte Geovania Japiassu Martins (Coord.)
Secretaria Executiva e Cerimonial Gabriella Araújo Souza Esteves
Jackson Schuelter Wiggers (Coord.) Valnei Carlos Denardin Extensão Conferência (e-OLA)
Roberto Iunskovski Jaqueline Cardozo Polla Carla Fabiana Feltrin Raimundo (Coord.)
Marcelo Fraiberg Machado Maria Cristina Veit (Coord.) Thayanny Aparecida B.da Conceição
Tenille Catarina Rose Clér Beche Bruno Augusto Zunino
Rodrigo Nunes Lunardelli Pesquisa
Assessoria de Assuntos Sergio Sell Daniela E. M. Will (Coord. PUIP, PUIC, PIBIC) Gerência de Logística Produção Industrial
Internacionais Mauro Faccioni Filho(Coord. Nuvem) Jeferson Cassiano A. da Costa (Gerente) Marcelo Bittencourt (Coord.)
Murilo Matos Mendonça Coordenadores Pós-Graduação
Aloisio Rodrigues Pós-Graduação Logísitca de Materiais Gerência Serviço de Atenção
Assessoria de Relação com Poder Bernardino José da Silva Anelise Leal Vieira Cubas (Coord.) Carlos Eduardo D. da Silva (Coord.)
Público e Forças Armadas Abraao do Nascimento Germano Integral ao Acadêmico
Carmen Maria Cipriani Pandini Maria Isabel Aragon (Gerente)
Adenir Siqueira Viana Daniela Ernani Monteiro Will Biblioteca Bruna Maciel
Walter Félix Cardoso Junior Salete Cecília e Souza (Coord.) Fernando Sardão da Silva André Luiz Portes
Giovani de Paula Carolina Dias Damasceno
Karla Leonora Nunes Paula Sanhudo da Silva Fylippy Margino dos Santos
Assessoria DAD - Disciplinas a Renan Felipe Cascaes Cleide Inácio Goulart Seeman
Distância Leticia Cristina Barbosa Guilherme Lentz
Marlon Eliseu Pereira Francielle Fernandes
Patrícia da Silva Meneghel (Coord.) Luiz Otávio Botelho Lento Holdrin Milet Brandão
Carlos Alberto Areias Rogério Santos da Costa Gestão Docente e Discente Pablo Varela da Silveira
Enzo de Oliveira Moreira (Coord.) Rubens Amorim Jenniffer Camargo
Cláudia Berh V. da Silva Roberto Iunskovski Juliana Cardoso da Silva
Conceição Aparecida Kindermann Thiago Coelho Soares Yslann David Melo Cordeiro
Capacitação e Assessoria ao Jonatas Collaço de Souza
Luiz Fernando Meneghel Vera Regina N. Schuhmacher Docente Avaliações Presenciais Juliana Elen Tizian
Renata Souza de A. Subtil Simone Zigunovas (Capacitação) Graciele M. Lindenmayr (Coord.) Kamilla Rosa
Gerência Administração Alessandra de Oliveira (Assessoria)
Assessoria de Inovação e Acadêmica Ana Paula de Andrade Maurício dos Santos Augusto
Qualidade de EAD Adriana Silveira Angelica Cristina Gollo Maycon de Sousa Candido
Angelita Marçal Flores (Gerente) Alexandre Wagner da Rocha
Denia Falcão de Bittencourt (Coord) Fernanda Farias Cristilaine Medeiros Monique Napoli Ribeiro
Andrea Ouriques Balbinot Elaine Cristiane Surian Daiana Cristina Bortolotti Nidia de Jesus Moraes
Carmen Maria Cipriani Pandini Secretaria de Ensino a Distância Juliana Cardoso Esmeraldino Delano Pinheiro Gomes Orivaldo Carli da Silva Junior
Iris de Sousa Barros Samara Josten Flores (Secretária de Ensino) Maria Lina Moratelli Prado Edson Martins Rosa Junior Priscilla Geovana Pagani
Giane dos Passos (Secretária Acadêmica) Fabiana Pereira Fernando Steimbach Sabrina Mari Kawano Gonçalves
Assessoria de Tecnologia Adenir Soares Júnior Fernando Oliveira Santos Scheila Cristina Martins
Osmar de Oliveira Braz Júnior (Coord.) Tutoria e Suporte
Alessandro Alves da Silva Claudia Noemi Nascimento (Líder) Lisdeise Nunes Felipe Taize Muller
Felipe Jacson de Freitas Andréa Luci Mandira Marcelo Ramos Tatiane Crestani Trentin
Jefferson Amorin Oliveira Anderson da Silveira (Líder)
Cristina Mara Schauffert Ednéia Araujo Alberto (Líder) Marcio Ventura Vanessa Trindade
Phelipe Luiz Winter da Silva Djeime Sammer Bortolotti Osni Jose Seidler Junior
Priscila da Silva Maria Eugênia F. Celeghin (Líder)
Douglas Silveira Andreza Talles Cascais Thais Bortolotti
Rodrigo Battistotti Pimpão Evilym Melo Livramento
Tamara Bruna Ferreira da Silva Daniela Cassol Peres
Fabiano Silva Michels Débora Cristina Silveira Gerência de Marketing
Fabricio Botelho Espíndola Francine Cardoso da Silva Fabiano Ceretta (Gerente)
Coordenação Cursos Felipe Wronski Henrique Joice de Castro Peres Relacionamento com o Mercado
Coordenadores de UNA Gisele Terezinha Cardoso Ferreira Karla F. Wisniewski Desengrini
Indyanara Ramos Eliza Bianchini Dallanhol Locks
Diva Marília Flemming Maria Aparecida Teixeira
Marciel Evangelista Catâneo Janaina Conceição Mayara de Oliveira Bastos Relacionamento com Polos
Roberto Iunskovski Jorge Luiz Vilhar Malaquias Patrícia de Souza Amorim Presenciais
Juliana Broering Martins Schenon Souza Preto Alex Fabiano Wehrle (Coord.)
Marcelo Medeiros
Luciano José Sávio
Banco de Dados I
Livro didático
Revisão e atualização de conteúdo

Tatiane dos Santos Leal
Design instrucional
Viviane Bastos
4ª edição
Palhoça
UnisulVirtual
2011
Copyright © UnisulVirtual 2011
Nenhuma parte desta publicação pode ser reproduzida por qualquer meio sem a prévia autorização desta instituição.
Edição – Livro Didático

Professor Conteudista
Marcelo Medeiros
Luciano José Sávio
Revisão e atualização de conteúdo

Tatiane dos Santos Leal
Design Instrucional
Viviane Bastos
Assistente Acadêmico
Roberta de Fatima Martins
Projeto Gráfico e Capa

Equipe UnisulVirtual
Diagramação
Rafael Pessi
Anne Cristyne Pereira (4ª edição)
Revisão
Simone Rejane Martins
Diane Dal Mago (4ª edição)
005.74
M43 Medeiros, Marcelo
Banco de dados I : livro didático / Marcelo Medeiros, Luciano José
Sávio ; revisão e atualização de conteúdo Tatiane dos Santos Leal ; design
instrucional Viviane Bastos. – 4. ed. – Palhoça : UnisulVirtual, 2011.
241 p. : il. ; 28 cm.
Inclui bibliografia.
1. Banco de dados. 2. Engenharia de software. 3. Tecnologia da

informação. I. Sávio, Luciano José. II. Leal, Tatiane dos Santos. III. Bastos,
Viviane. IV. Título.
Ficha catalográfica elaborada pela Biblioteca Universitária da Unisul

Sumário
Apresentação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Palavras dos professores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Plano de estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
UNIDADE 1 - Banco de dados e a tecnologia da informação. . . . . . . . . . . . . 15

UNIDADE 2 - Conceitos de bancos de dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
UNIDADE 3 - Modelagem de dados e projeto de banco de dados . . . . . . . 63
UNIDADE 4 - Produtos de Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
UNIDADE 5 - Implementação do projeto de banco de dados. . . . . . . . . . . 111
UNIDADE 6 - Ferramentas case para apoio ao
projeto de banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
UNIDADE 7 - Acesso e manipulação de dados. . . . . . . . . . . . . . . . . . . . . . . . . 155
UNIDADE 8 - Recuperação de informações do banco de dados . . . . . . . . 173
UNIDADE 9 - Recuperação de informações por meio de tabelas. . . . . . . . 201
Para concluir o estudo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Referências. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Sobre os professores conteudistas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Respostas e comentários das
atividades de autoavaliação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Biblioteca Virtual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Apresentação
Este livro didático corresponde à disciplina Banco de Dados I.
O material foi elaborado visando a uma aprendizagem autônoma

e aborda conteúdos especialmente selecionados e relacionados
à sua área de formação. Ao adotar uma linguagem didática
e dialógica, objetivamos facilitar seu estudo a distância,
proporcionando condições favoráveis às múltiplas interações e a
um aprendizado contextualizado e eficaz.
Lembre-se que sua caminhada, nesta disciplina, será

acompanhada e monitorada constantemente pelo Sistema
Tutorial da UnisulVirtual, por isso a “distância” fica
caracterizada somente na modalidade de ensino que você optou
para sua formação, pois na relação de aprendizagem professores
e instituição estarão sempre conectados com você.
Então, sempre que sentir necessidade entre em contato; você tem

à disposição diversas ferramentas e canais de acesso tais como:
telefone, e-mail e o Espaço Unisul Virtual de Aprendizagem,
que é o canal mais recomendado, pois tudo o que for enviado e
recebido fica registrado para seu maior controle e comodidade.
Nossa equipe técnica e pedagógica terá o maior prazer em lhe
atender, pois sua aprendizagem é o nosso principal objetivo.
Bom estudo e sucesso!
Equipe UnisulVirtual.
7
Palavras dos professores
Olá, você está iniciando o estudo da disciplina Banco de

Dados I.
Se você parar um pouco para avaliar o seu dia a dia, notará

que convive com um mundo de informações, que são usadas
nas suas atividades diárias, por mais simples que sejam.
Ao fazer uma ligação telefônica, realizar uma compra ou

simplesmente utilizar o seu meio de transporte até o trabalho,
um conjunto de informações são necessárias para que cada
uma dessas atividades seja realizada de forma rápida e
eficiente.
Nesta disciplina você conhecerá as formas de armazenamento

e acesso aos dados gravados no computador e algumas
ferramentas existentes no mercado de trabalho que permitirão
organizar suas informações de forma confiável. Verá também
que o ambiente de banco de dados utiliza uma linguagem
padrão para manipulação dos dados, chamada de SQL.
Enfim, você poderá entender melhor o funcionamento

das principais ferramentas de banco de dados, criar alguns
modelos deles e e manipulá-los de forma prática.
Espero que você possa aproveitar ao máximo o conteúdo desta

disciplina.
Bom estudo!
Profs. Marcelo Medeiros e Luciano Sávio

Plano de estudo
O plano de estudos visa a orientá-lo no desenvolvimento da

disciplina. Ele possui elementos que o ajudarão a conhecer o
contexto da disciplina e a organizar o seu tempo de estudos.
O processo de ensino e aprendizagem na UnisulVirtual leva

em conta instrumentos que se articulam e se complementam,
portanto, a construção de competências se dá sobre a
articulação de metodologias e por meio das diversas formas de
ação/mediação.
São elementos desse processo:
o livro didático;
o Espaço UnisulVirtual de Aprendizagem (EVA);
as atividades de avaliação (a distância, presenciais e de

autoavaliação);
o Sistema Tutorial.
Ementa
Origens de um sistema de banco de dados. Características
de um sistema de banco de dados. Modelo de dados. Bancos
de dados relacionais e orientados a objetos. Linguagens de
definição e manipulação de dados. Modelos de entidade/
relacionamento.
Ferramentas computacionais para implementação de bancos de

dados. Perfil do profissional de banco de dados.
Objetivos
Geral:
Propiciar o desenvolvimento e a utilização de sistemas de banco
de dados, por meio dos conceitos fundamentais sobre eles, os
seus sistemas de gerenciamento, formas de modelagem de dados
e as características da linguagem de programação para banco de
dados.
Específicos:
Conhecer os conceitos básicos sobre banco de dados,
origem e a sua forma de funcionamento.
Apresentar as principais ferramentas de sistema de banco

de dados.
Apresentar os conceitos de banco de dados relacional e

orientado ao objeto.
Conhecer como instalar e praticar em um sistema

gerenciador de banco de dados relacional.
Conhecer a linguagem de programação para banco de

dados relacional.
Possibilitar a criação e manipulação de um modelo de

banco de dados.
Refletir sobre as tendências de ferramentas e profissionais

para área de banco de dados.
Carga Horária
A carga horária total da disciplina é de 60 horas-aula.
12
Banco de Dados I
Conteúdo programático/objetivos
Veja, a seguir, as unidades que compõem o livro didático desta
disciplina e os seus respectivos objetivos. Estes se referem aos
resultados que você deverá alcançar ao final de uma etapa de
estudo. Os objetivos de cada unidade definem o conjunto de
conhecimentos que você deverá possuir para o desenvolvimento
de habilidades e competências necessárias à sua formação.
Unidades de estudo: 9
Unidade 1 - Banco de dados e a tecnologia da informação

Nesta unidade será abordado sobre a área de banco de dados nas
organizações, sua importância e um pouco da história acerca
da evolução e consolidação dos bancos de dados no mercado. O
conteúdo desta unidade centrar-se-á na análise de dois aspectos:
a informática como meio de produção ou a informática como
produto final.
Unidade 2 – Conceitos de bancos de dados

Com o estudo desta unidade, você vai conhecer os conceitos de
banco de dados e os tipos de sistemas de gerenciamento de banco
de dados. Além disso, vai conhecer os modelos de banco de
dados à disposição do profissional desta área.
Unidade 3 – Modelagem de dados e projeto de banco de dados

Nesta unidade, serão apresentados os processos para se projetar
um banco de dados bem como o conceito de modelagem de
dados. Serão apresentados, também, os tipos de cardinalidades
nas relações entre os elementos do modelo de dados.
13
Unidade 4 – Produtos de banco de dados

Esta unidade apresentará os conceitos de Software Livre e de
software de tecnologia proprietária. Vai abordar sobre alguns
produtos de banco de dados construídos sob o âmbito de software
proprietário e sob o âmbito de software livre. Com isso, este
estudo permitirá compreender o impacto do Software Livre nos
produtos de banco de dados.
Unidade 5 – Implementação do projeto de banco de dados

Esta unidade abordará a origem da linguagem SQL, os tipos de
dados da linguagem SQL e os comandos de definição de dados
(DDL). Será abordado, também, a funcionalidade das chaves
primárias e estrangeiras em um banco de dados e os elementos de
um projeto de banco de dados numa ferramenta de SGBD.
Unidade 6 –Ferramentas Case para apoio ao projeto de banco de

dados
Nesta unidade, será abordada a importância das ferramentas
Case e as vantagens do uso dessas ferramentas como apoio à
modelagem de dados.
Unidade 7 – Acesso e manipulação de dados

Esta unidade aborda os comandos de manipulação de dados
(DML), mostra como e o que fazer para inserir dados em uma
tabela e para alterar e remover os dados cadastrados.
Unidade 8 – Recuperação de informações do banco de dados

Nesta unidade, serão apresentados os passos para selecionar
dados em SQL, usando a DML e as funções agregadas em
SQL. Será apresentado, também, como se gera consultas com
agrupamento em SQL.
14
Banco de Dados I
Unidade 9 – Recuperação de informações por meio de tabelas

Esta unidade apresenta como selecionar dados em SQL usando
mais de uma tabela como referência. Apresenta, também, os
tipos de junções em SQL e como se gera consultas em SQL mais
eficientes.
Agenda de atividades/ Cronograma
Verifique com atenção o EVA, organize-se para acessar

periodicamente a sala da disciplina. O sucesso nos seus
estudos depende da priorização do tempo para a leitura, da
realização de análises e sínteses do conteúdo e da interação
com os seus colegas e tutor.
Não perca os prazos das atividades. Registre no espaço

a seguir as datas com base no cronograma da disciplina
disponibilizado no EVA.
Use o quadro para agendar e programar as atividades relativas

ao desenvolvimento da disciplina.
15
Atividades obrigatórias
Demais atividades (registro pessoal)
16
1
unidade 1
Banco de dados e a tecnologia

da informação
Objetivos de aprendizagem
Compreender a importância dos bancos de dados na
área de tecnologia da informação.
Entender a evolução dos sistemas de armazenamento

para sistemas gerenciadores de banco de dados.
Compreender o papel dos profissionais de banco de

dados.
Seções de estudo
Seção 1 Banco de dados e a área de tecnologia da
informação
Seção 2 De sistemas de arquivos a sistemas

gerenciadores de banco de dados
Seção 3 O mercado de trabalho e seus profissionais

Para início de estudo

Nesta unidade será contextualizada a área de banco de dados nas
organizações, sua importância, bem como os profissionais que
nela atuam e também como os bancos de dados evoluíram e se
consolidaram no mercado.
Porém, para compreender melhor o mercado de informática

voltado para área de banco de dados, é preciso analisá-lo a partir
de dois importantes aspectos, que são: a informática como meio
de produção ou a informática como produto final.
Mas o que significa analisar estes aspectos dos bancos

de dados?
Quando uma empresa utiliza a informática como complemento

à sua produção, ou à criação do seu produto final, não está
vendendo um serviço de informática, mas sim utilizando-se
desse serviço para alcançar os seus objetivos. Essa empresa usa a
informática como um processo complementar às suas atividades,
por isso é referida como empresa que utiliza a informática como
meio.
Um exemplo disso são os supermercados. Eles utilizam a

informática, os sistemas de banco de dados e softwares para
permitir que seus clientes realizem os serviços desejados.
Entretanto, esse serviço não está sendo diretamente vendido
ao cliente, que muitas vezes nem se dá conta da quantidade de
recursos de informática que foram necessários para a realização
de determinada tarefa.
Há também no mercado as empresas que têm a informática como

seu principal produto, criando softwares, realizando consultorias
na área da computação, instalando e montando equipamentos.
Essas empresas têm a informática como seu produto final.
Por exemplo, a MicroSoft é uma empresa que tem

na criação de produtos de informática, nesse caso,
softwares, o seu principal recurso financeiro. A
informática é o produto final da sua linha de produção
e seus produtos serão utilizados como meio de
produção em muitas empresas de todo o mundo.
16
Banco de Dados I
Você deve estar se perguntando: “e daí”? Bem, como temos cenários

diferentes para o uso da informática, temos também necessidades
de profissionais diferentes para desenvolver as tarefas do dia a dia.
E é nesse escopo que esta unidade será inserida, de forma a

apresentar a você o contexto da área de banco de dados dentro da
Tecnologia da Informação das empresas, o papel dos profissionais que
estão envolvidos com a informática, seja ela produto meio ou fim.
Além disso, você vai conhecer como ocorreu a evolução dos

sistemas de armazenamento de dados até o advento dos Sistemas
Gerenciadores de Banco de dados ou SGBDs.
Seção 1 – Banco de dados e a área de tecnologia da

informação
A tecnologia da informação, ou simplesmente TI, está em constante
evolução, assim como tudo na área da informática. A cada dia
surgem novos conceitos e jargões utilizados pelo mercado, a fim
de representar uma nova tecnologia, técnica ou mesmo um novo
produto. Se vocês fizerem uma pesquisa pela rede mundial poderão
se deparar com termos já não mais utilizados, ou em desuso no
mercado da informática, como por exemplo, downsizing, rightsizing,
mainframe, dentre outros, mas que em algum momento da
história estiveram presentes e indicavam algum tipo de técnica ou
tecnologia utilizada.
Atualmente, banco de dados está posicionada nas áreas de TI das

empresas junto às áreas de redes, telecomunicações e hardware,
formando a infra estrutura base da área de informática dessas
empresas. Ter uma infra estrutura consolidada e robusta é
indispensável para qualquer organização, pois representa segurança
nas operações fundamentais para o fluxo das informações na
empresa.
Dentre essas operações fundamentais destacam-se o fornecimento

de informações e os mecanismos que permitem com que essas
informações circulem pela organização.
Unidade 1 17
Os elementos formadores da área de infra estrutura são ditos de

funções críticas, ou seja, muito importantes para que toda a área
de TI funcione adequadamente. Imagine você em uma empresa
com 500 pontos de redes interconectados, utilizando-se de 25
tipos de softwares. Todo esse pessoal depende exclusivamente
das redes de comunicações, para que consiga trocar e armazenar
informações, e também do banco de dados, onde as informações
utilizadas por esses usuários são registradas por meio dos sistemas
de informação e processadas.
Seguindo essa lógica, qualquer problema envolvendo algum

elemento da área de infra estrutura pode causar uma paralização
das atividades de grande parte da empresa, inviabilizando
o trabalho de muitas pessoas. Daí, atualmente, a grande
importância atribuída a essa área e, consequentemente, ao banco
de dados das organizações.
O elemento principal responsável pelo fornecimento das

informações na área de TI é, sem dúvida, o banco de dados,
ou melhor, o Sistema Gerenciador de Banco de Dados. Ele é o
responsável por toda a manutenção da informação que é mantida
pela empresa, conforme apresentado na próxima seção.
Seção 2 – De sistemas de arquivos a sistemas

gerenciadores de banco de dados
O armazenamento de dados passou por algumas transformações
e adaptações ao longo do tempo. Essas mudanças se deram em
função da evolução da tecnologia, com novos equipamentos e
soluções para o armazenamento de dados, e também pela própria
evolução das novas necessidades de armazená-los, dentre elas,os
volumes cada vez maiores de informação, além da recuperação e
armazenamento mais rápidos e eficientes, com maior segurança.
Até 30 anos atrás, o foco principal da área de informática

estava no processamento dos dados e no aprimoramento
da tecnologia para que este processamento tivesse melhor
performance. Trabalhou-se muito para que os processadores, a
memória e o conjunto de componentes internos evoluíssem e
18
Banco de Dados I
se tornassem cada vez mais performáticos e seguros nas suas

operações. Uma vez que se adquiriu uma qualidade significativa
com esses elementos, uma necessidade pelo armazenamento
mais seguro das informações começou a ser delineada, já que,
com muita capacidade de processamento à disposição, deveria
haver mecanismos para que se armazenasse o resultado desse
processamento ou que servisse de fonte de informações para
serem processadas.
A necessidade de armazenar mais e mais informações levou a

área de informática a desenvolver novas tecnologias para que
pudesse suportar maiores capacidades de armazenamento e que
essas informações estivessem com um mínimo de segurança e
confiabilidade.
Com o aumento da capacidade de armazenamento e recuperação

das informações, e também com o desenvolvimento de novas
metodologias de desenvolvimento de softwares, tornou viável
o processamento de grandes volumes de informações, e as
organizações passaram a se informatizar num ritmo mais
acelerado, vislumbrando maior agilidade e, consequentemente,
maior competitividade no mercado em que estavam inseridas.
A arquitetura utilizada pelos sistemas de informação era bastante

simples, conforme mostra a figura a seguir.
SISTEMAS
Contabilidade Estoque RH
Arq 1 Arq 2 Arq 3
ARQUIVOS DE DADOS
Figura 1.1 – Arquitetura de sistemas de informação
Fonte: Elaboração do Autor.
Unidade 1 19
De acordo com a Figura 1.1, nesta arquitetura, cada sistema

de informação é proprietário, detentor da sua própria base de
dados. Isso significa que cada sistema de informação detém
o conhecimento, quero dizer, código de como manipular os
dados mantidos e quais as regras que devem ser seguidas para
que se insira, altere ou elimine cada uma das informações ali
armazenadas.
Nesse tipo de arquitetura, fica evidente algumas limitações, como

por exemplo, a necessidade de redundância das informações, ou
seja, informações idênticas cadastradas em mais de um sistema.
Um exemplo claro dessa limitação é o fato de que existem
informações que são de uso de vários departamentos da empresa,
sendo denominadas de informações corporativas.
Como nesta arquitetura cada sistema mantém seu próprio

arquivo de dados, se o sistema X necessita do endereço do cliente
e o sistema Y também necessita dessa informação, essa será
registrada em duplicidade. Ao longo do tempo, essa redundância
pode acarretar problemas, pois caso o cliente atualize o endereço
no departamento X, eventualmente o departamento Y pode
não ser informado dessa atualização, gerando dados inexatos na
organização.
Outra limitação que pode ser identificada é no que diz respeito

ao compartilhamento das informações. Como cada sistema
mantém o controle de como acessar e manipular as informações
nos seus arquivos de dados, os demais sistemas estão limitados
a trabalharem apenas com as informações de seus próprios
arquivos, por não possuírem conhecimento da estrutura de
organização dos arquivos de dados dos outros sistemas, não sendo
possível efetuar o seu acesso. Mas apesar das limitações, essa
arquitetura cumpria com o seu papel, uma vez que a consolidação
das informações e o compartilhamento dos dados não era uma
necessidade premente, pois as empresas estavam organizadas
departamentalmente.
Houve, porém, uma mudança significativa na forma como

as empresas estavam sendo administradas. Por uma nova
necessidade de mais agilidade, as organizações começaram a
ter o estilo de administração por processos, ao invés do estilo
departamental. Nesse tipo de administração, uma ação ocorrida
num departamento, pode ecoar em alterações em diversos outros
setores da empresa. Veja um exemplo prático.
20
Banco de Dados I
Caso o setor de almoxarifado pretenda contratar um

novo funcionário, esse deve comunicar ao setor de
RH, o qual deve informar ao pessoal de recrutamento
e seleção, além de comunicar ao setor financeiro que
a folha de pagamento vai passar a ter gastos extras.
A área de finanças, por sua vez, deve comunicar ao
pessoal de vendas que elas devem aumentar, pois os
gastos aumentaram. O pessoal de vendas se comunica
com a produção, que deve ser incrementada, a fim de
suprir as novas vendas.
Um novo desafio foi lançado: como prover tamanha integração

entre os sistemas de forma a suportar essa nova necessidade
administrativa?
Um dos reflexos imediatos foi que essa arquitetura, na qual

estavam arquitetados os sistemas de informação, logo começou
a apresentar dificuldades para se manter, uma vez que uma nova
necessidade passou a ser cobrada por parte das organizações, o
compartilhamento das informações entre os diversos sistemas.
Isso decorre das práticas administrativas das empresas que
estavam em franca evolução e à troca de informações entre os
diversos departamentos passou a ser elemento fundamental para
que as empresas pudessem ter maior agilidade nos seus processos
e consequentemente adquirir maior competitividade no mercado.
A partir dessa necessidade, a arquitetura para a implementação

de sistemas de informação passou a ter que vencer um grande
obstáculo: permitir o compartilhamento de informações entre
os diversos sistemas existentes. Cabe citar aqui, há 20, 30 anos
não havia tecnologias tão avançadas para interoperabilidade e
interconectividade entre as tecnologias existentes, dessa forma,
não era trivial encontrar sistemas operacionais conversando
entre si, nem tampouco sistemas de informação compartilhando
informações.
Nesse momento, você pode perguntar: mas não basta apenas

o Sistema X acessar a base de dados do Sistema Y para que se
compartilhem as informações?
Realmente, é apenas esse o desafio, e por que está sendo tratado

como desafio? Por duas razões principais:
Unidade 1 21
1. O sistema de informação X não tem conhecimento

de como o sistema Y trabalha os seus dados, pois
toda a estrutura e as regras de manipulação dos dados
armazenados estão codificadas dentro do sistema
Y. Como exemplo, imagine que o sistema X precise
armazenar uma nova informação na base de dados
do sistema Y. Como ele vai conseguir isso se não tem
conhecimento de quais as regras estabelecidas para que se
faça a inserção desta nova informação? Assim sendo, fica
muito difícil um sistema compartilhar uma informação
de outro sistema, inclusive tendo que manter informações
duplicadas em vários sistemas, incorrendo na
redundância de dados, causando mais dificuldades para
a manutenção e o seu controle. Novamente, você pode
concluir: simples, basta que um sistema conheça como o
outro sistema trabalha os seus dados!!! Isso mesmo, mas
para que isso ocorra implica numa questão de mercado,
de concorrência, apresentada no próximo item.
2. O mercado de algum tempo atrás era muito segmentado

e com atuações pontuais. Dessa forma, a empresa A
fornecia o software para RH e Finanças, por exemplo.
A empresa B fornecia o software para Vendas e Estoque,
assim por diante. Como as organizações estavam
orientadas a trabalhar de forma departamental, ou
seja, cada departamento resolvia os seus problemas
internamente, normalmente cada departamento
também escolhia no mercado o software que mais
se adaptava às suas necessidades e o adquiria, sem a
preocupação com o compartilhamento das informações
com outros departamentos e outros sistemas.
Com a nova necessidade de compartilhamento de
informações, passou-se a ter grandes dificuldades, pois
os softwares adquiridos pelos diversos departamentos
não conversavam entre si, e por duas razões principais:
ou a tecnologia utilizada era incompatível entre
si, dificultando a interoperabilidade, ou o próprio
fabricante do software não tinha o menor interesse em
abrir a estrutura dos dados do seu software para outro
fabricante, que inclusive poderia ser seu concorrente em
outros softwares.
22
Banco de Dados I
Como pode ser percebido, a arquitetura para os sistemas de

informação apresentada na figura 1.1 já não era a mais adequada
para as necessidades atuais das organizações. Então, começaram
a ser trabalhadas novas alternativas para a problemática do
compartilhamento das informações e para a diminuição da
redundância dos dados.
A alternativa que obteve mais êxito e aceitação foi a de que os

sistemas de informação se tornassem clientes das bases de dados,
e não mais proprietários, a fim de proporcionar um método
de acesso único a essas bases de dados, de forma que qualquer
sistema de informação pudesse se conectar a qualquer base de
dados e dela compartilhar as informações de seu interesse.
Para que os sistemas de informação pudessem se tornar clientes

de bases de dados, alguém deveria prover um método único e
padronizado para o acesso a bases de dados e também armazenar
as regras de manipulação dos dados mantidos por ela.
Começava a nascer um novo tipo de aplicação, o gerente para

as bases de dados, ou mais propriamente falando, o Sistema
Gerenciador de Banco de Dados - SGBD.
Para que o SGBD pudesse ser contemplado, uma nova

arquitetura para a construção de sistemas de informação deveria
ser definida conforme a figura 1.2.
SISTEMAS
Contabilidade Estoque RH
SGBD
BD 1 BD 2 BD 3 BD 4
Figura 1.2 – Arquitetura de sistemas de informação com SGBD

Fonte: Elaboração do Autor.
Unidade 1 23
O SGBD atua como um elemento intermediário entre os

sistemas de informação e a base de dados, padronizando a
forma de acesso às informações ali mantidas, proporcionando o
compartilhamento das informações entre os sistemas e atuando
fortemente no controle da redundância dos dados, uma vez que
vários sistemas podem acessar uma mesma informação, não
necessitando armazená-la novamente, com duplicação.
Mas afinal, o que é SGBD?
O SGBD nada mais é do que um sistema intermediário

que atua entre os sistemas de informação e a base
de dados, provendo aos sistemas as informações
armazenadas por meio de mecanismos eficientes e
seguros, a fim de proporcionar maior performance no
armazenamento e recuperação das informações, além
de garantir integridade e consistência aos dados.
O SGBD então assume a responsabilidade pela manutenção

das informações, retirando essa responsabilidade dos sistemas
de informação. Portanto, se uma data é inválida, ou se uma
informação depende de uma outra para poder ser armazenada,
o sistema de informação não precisa mais se preocupar com isso,
pois essas questões ficam a cargo do SGBD.
Assim sendo, os sistemas de informação puderam se preocupar

muito mais e dedicar mais esforços em ergonomia e apresentação
das informações ao usuário, deixando a tarefa de tratamento das
informações com os SGBDs.
Agora que está mais claro o surgimento e a consolidação dos

SGBDs no mercado da informática, veja, na próxima seção, a
importância e o papel dos profissionais que atuam nesta área.
24
Banco de Dados I
Seção 3 – O mercado de trabalho e seus profissionais

Dentro de uma análise em que a informática é tida como
produto fim, de forma resumida, o mercado de trabalho na
área de informática pode ser dividido em três grandes linhas
profissionais:
desenvolvimento de software - programadores;

análise de sistemas.
Na primeira opção tem-se o especialista em linguagens e técnicas
de programação de computadores, que é aquele profissional que
domina algumas linguagens de programação, tendo como sua
principal base de conhecimento, os algoritmos.
Já na segunda, tem-se o profissional com alta capacidade

analítica, que domina metodologias de modelagem e
desenvolvimento de sistemas.
Então, qual é a terceira linha profissional na área da

informática?
Nesse caso, é que entra o profissional de banco de dados. Ele

não está em uma única categoria dentro das áreas citadas. Talvez
esteja aí a grande complexidade nas atividades desse profissional.
Um programador de computador é responsável por transformar

as tarefas executadas pelo ser humano em um conjunto de
comandos que serão executados pelo computador. Porém, quando
essas atividades envolvem armazenamento de dados, passa a ser
necessário um especialista para projetar e manipular o modelo de
banco de dados criado.
O mesmo tipo de problema pode ocorrer quando um analista de

sistemas precisa modelar um sistema que envolva banco de dados.
Será necessário que ele tenha um especialista em banco de dados
para auxiliá-lo nesse processo de modelagem.
Unidade 1 25
É importante que se distinga a tarefa de modelar um sistema de a

tarefa de modelar um banco de dados:
quando o analista está modelando um sistema, ele está

definindo todas as atividades de interação do usuário
para com o sistema que será implementado;
já a modelagem do banco de dados representa a forma
como os dados que são manipulados pelo sistema serão
armazenados.
Modelar sistema - define as regras de interação do

usuário com o sistema.
Modelar banco de dados - define as regras de
armazenamento dos dados que serão manipulados
pelo sistema.
O profissional de banco de dados interage com o programador

e com o analista de sistemas, formando uma equipe de
desenvolvimento.
A não ser em casos muito específicos, essa interação pode ser

realizada. Se a interação do profissional de banco de dados na
área de informática é alta, quando se analisa as empresas em que
a informática é o meio de produção, ela se torna maior ainda, pois
na maioria das vezes esse profissional interage com profissionais
das mais diversas áreas.
Dentro de um ambiente desses, o profissional de banco de dados

possui as mais diversas tarefas, que são de grande importância
para o funcionamento da empresa, pois todos os processos da
empresa estão baseados no seu desempenho.
Conheça algumas atividades executadas por esse profissional:
População das tabelas dos bancos de dados –

atualização de dados.
Modelagem do banco de dados – definição das regras
para armazenamento dos dados que serão manipulados
pelo sistema.
26
Banco de Dados I
Manutenção do banco de dados – garantir que ele não

pare de funcionar.
Backup dos dados – realizar a cópia de segurança dos
dados para garantir a fidelidade dos mesmos.
Gerenciar o banco de dados – definir senhas e
prioridades de acesso ao sistema, evitando que acessos
indevidos sejam realizados.
Manter o contato com o fabricante da ferramenta
de banco de dados – para realização de atualizações e
instalações de novos recursos.
Observe que essas atividades são fundamentais para que a

empresa se mantenha em funcionamento. A maioria das
atividades de produção é dependente do sistema de banco de
dados, por isso é grande a responsabilidade desse profissional, ou
da equipe que ele gerencia.
Em pequenas organizações é comum encontrar o analista de

sistemas atuando como programador, modelando banco de dados
e gerenciando os projetos de informática. Agora, quanto maior a
organização, maior a complexidade do sistema de banco de dados
e, consequentemente, maior deve ser a equipe envolvida. Assim,
pode-se identificar mais alguns papéis para a divisão das tarefas
de um especialista em banco de dados:
Administrador de banco de dados (DBA)

Em uma organização onde muitas pessoas utilizam os mesmos
recursos, existe a necessidade de um administrador para
gerenciar esses recursos. Em ambiente de banco de dados, o
recurso primário é o banco de dados propriamente dito e o
recurso secundário é o SGBD, ambos sobre a supervisão do
administrador desse banco (DBA). O DBA é responsável
pela autorização de acesso ao banco de dados, monitoração e
coordenação de seu uso, e está envolvido com os seus aspectos
físicos (estruturas de armazenamento, métodos de acesso etc).
Unidade 1 27
Projetistas de banco de dados

Projetistas de banco de dados são responsáveis pela identificação
dos dados e pela escolha de estruturas apropriadas para
representar e gravar tais dados. Essas tarefas são executadas antes
da implementação desse banco. É necessária uma comunicação
com os usuários do banco de dados e analistas de sistemas para
entender seus requisitos, de modo que o projeto possa atendê-los.
A visão de cada grupo de usuários deve ser entendida, e o projeto
final deverá suportar os requisitos de todos os grupos de usuários.
Usuário final
Usuário final é a pessoa cujo trabalho requer acessar o banco de
dados para consulta e atualizar os dados; um banco de dados
existe primariamente para seu uso. A maioria dos usuários
finais utiliza programas voltados ao desempenho de suas
funções profissionais, interagindo com tais programas em seu
dia a dia. Nessa classe, pode-se citar caixa bancário, caixa de
supermercado, agente de turismo, vendedores de varejo etc.
Alguns usuários mais sofisticados, como engenheiros e cientistas,
estão mais familiarizados com as facilidades de um SGBD e são
capazes de utilizar ferramentas para elaborar suas consultas.
Síntese
Nesta unidade, você pôde observar que a área de banco de dados

é essencial para que se consiga uma área de TI consolidada e
robusta, pois essas ferramentas propiciam maior agilidade e
garantia no armazenamento das informações, essenciais para
qualquer organização na sociedade em que vivemos. Essa agilidade
e garantia no armazenamento serão melhor discutidas nas
próximas unidades desta disciplina, onde poderão ser constatados
diversos mecanismos presentes nos SGBDs que proporcionem
essas características com relação ao armazenamento dos dados.
Os SGBDs são fruto de uma evolução nos sistemas de

armazenamento, inicialmente constituídos apenas num sistema
28
Banco de Dados I
de arquivos de dados onde os sistemas de informação os

manipulavam diretamente, evoluindo para um modelo onde
há uma padronização na forma de acesso aos dados, por meio
da figura do gerente dos dados, ou Sistemas Gerenciadores de
Banco de Dados. Isto proporcionou um compartilhamento mais
eficiente das informações armazenadas, bem como na diminuição
da redundância dos dados armazenados.
Foi apresentado também, nessa unidade, o papel do profissional

de banco de dados e como está organizado o mercado de trabalho
para esses profissionais.
Esse profissional tem tido importante posição no mercado de

trabalho, principalmente pelo grande fluxo de informações que
trafegam nesse mundo globalizado. É praticamente inadmissível
que nos dias atuais alguém utilize papel ou algo similar como
forma de organizar e armazenar informações para suas atividades
do dia a dia.
E é junto a essa quantidade de informações que o profissional de

tecnologia da informação executará as suas tarefas de projetar,
criar e manipular um conjunto de sistemas de banco de dados,
essenciais ao funcionamento de uma empresa que tenha a
informática como produto final, ou como meio de produção.
Nesse mercado, esse profissional deve estar atento às diversas

tendências, avaliando novas ferramentas e novas tecnologias,
mantendo-se sempre atualizado, sem nunca esquecer que sua
ferramenta de trabalho é o seu cérebro, seus conhecimentos
adquiridos, tendo o computador como a ferramenta que irá
auxiliá-lo nas tarefas diárias.
Unidade 1 29
Atividades de autoavaliação
Ao final de cada unidade, você realizará atividades de autoavaliação. O
gabarito está disponível no final do livro didático. Esforce-se para resolver
as atividades sem ajuda do gabarito, pois, assim, você estará promovendo
(estimulando) a sua aprendizagem.
1) Por que a área de banco de dados é considerada crítica numa empresa?
2) Programador, analista de sistemas e especialista em banco de dados

são os profissionais envolvidos com banco de dados. Para as grandes
empresas, o especialista nessa área possui diferentes papéis. Descreva
as responsabilidades dos 5 profissionais envolvidos em todo o processo
de um banco de dados nas grandes empresas.
30
Banco de Dados I
3) Quais os principais benefícios proporcionados pelo surgimento do

SGBD para as empresas?
Saiba mais
Para conhecer mais detalhes sobre os conteúdos desta unidade,

há sugestões para a pesquisa dos seguintes títulos:
DATE, C.J. Introdução a sistemas de bancos de dados. Rio de

Janeiro: Campus, 1991.
KORTH, H.F.; Silberschatz, A. Sistema de banco de dados. 3.

ed. São Paulo: Makron Books, 1999.
31
2
unidade 2
Conceitos de bancos de dados
Compreender o conceito de banco de dados.
Conhecer os diferentes tipos de banco de dados.
Entender a arquitetura que compõe um banco de dados.
Seções de estudo
Seção 1 Conceitos de banco de dados
Seção 2 Tipos de sistemas de gerenciamento de

banco de dados
Seção 3 Modelos de banco de dados


O computador é uma máquina e como tal deve ser sempre assim
referenciado. Essa máquina possui algumas características que
a distingue das demais, como a velocidade de processamento
e a capacidade de armazenamento. É considerado um
equipamento, que com o passar dos anos se tornou de uso pessoal
e profissional, podendo ser usado no lazer e no dia a dia, nas mais
variadas tarefas e de complexidades mais diversas.
Olhando por um prisma mais direto, o computador possui três

tarefas básicas, que são: entrada de dados, processamento de
dados e saída de dados.
A entrada de dados é responsável pela importação das

informações para o computador e está diretamente relacionada
à interação com o usuário, pois na maioria das vezes depende da
informação digitada por ele, na forma mais simples de interação,
o teclado.
Já a saída de dados representa os dados informados na entrada,

mas que de alguma forma foram transformados, atendendo às
expectativas do usuário, sendo apresentados por meio de algum
dispositivo de saída, como impressora ou monitor.
A essa transformação dos dados da entrada até dados

da saída chama-se processamento.
Até aqui, se fosse apenas isso, seria muito mais simples

compreender o ambiente em volta de um computador, porém,
com o passar dos anos, uma nova propriedade foi adicionada
a essas três tarefas, e não sendo menos importante: o
armazenamento dos dados.
Tão importante quanto informar os dados, processá-los e
apresentá-los à organização, o armazenamento desses dados passou
a ser uma tarefa essencial, principalmente pelo grande número de
usuários que interagem com o equipamento ao mesmo tempo.
Com passar dos anos, o número de dados processados por

um computador cresceu de forma assustadora, e de forma
32
Banco de Dados I
inversamente proporcional o computador tem diminuído de

dimensões físicas e também aumentando a sua capacidade de
armazenamento e processamento de dados, tornando-se cada vez
mais pessoal.
Gerenciar e armazenar dados tornou-se uma tarefa complexa,

que envolve muitas ferramentas e tecnologias de armazenamento
e acesso aos dados. Com a grande evolução da computação em
geral, ou da informática em geral, os equipamentos têm evoluído
muito, deixando seu custo mais acessível.
Com isso, o uso dos computadores tem atingido os mais variados

perfis de usuários, dos mais experientes – que o usam sem
nenhuma dificuldade–, aos mais novatos – que o veem como uma
“máquina do outro mundo”. Dessa forma, o parque tecnológico
em todo o mundo tem atingido números expressivos.
Fazendo uma matemática simples, imagine que a principal

finalidade do computador é armazenar dados que possam ser
acessados a qualquer momento e em qualquer lugar do mundo;
quanto maior o número de computadores, maior o número de
dados para serem gerenciados e processados. Como a tendência é
que esse número deva aumentar a cada ano, a complexidade dos
dados armazenados deverá ser um grande problema da área de
informática.
Seria possível resumir em: mais computadores

significam mais problemas?
Em paralelo ao grande número de novos usuários de

computadores, bem como a expansão na facilidade de acesso
aos computadores e às novas tecnologias em hardware, há
também o surgimento de novas ferramentas computacionais para
gerenciamento e integridade dos dados. Essa demanda gera uma
nova expectativa ao profissional da informática quanto ao seu
envolvimento com as tecnologias de banco de dados.
Além de ser um especialista em banco de dados, o profissional
deve ter capacidade de compreender as diferentes tecnologias
do mercado, de escolher aquela que melhor atenda às suas
necessidades e deve propor e modelar soluções aos diversos
problemas que farão parte das suas atividades profissionais.
Unidade 2 33
A esse conjunto que envolve ferramentas

computacionais, gerenciamento de dados,
armazenamento e integridade aos dados, chama-
se sistema de gerenciamento de banco de dados.
E é nesse mundo que você embarca, a partir de agora,

interagindo com um mundo de armazenamento e manipulação
de dados.
Seção 1 – Conceitos de banco de dados

Quando nos referimos ao computador como uma máquina, temos
como foco a sua capacidade de gerenciamento e armazenamento
de informações. Vale salientar que as outras propriedades,
como velocidade de processamento e fácil interação com
usuário, são também muito importantes, porém, como o escopo
desta disciplina é banco de dados, será dada maior ênfase ao
armazenamento dos dados.
De forma simplificada, pode-se conceituar banco de

dados como sendo um sistema de armazenamento
de dados baseado em computador, cujo objetivo
é registrar e manter informações consideradas
significativas a qualquer organização ou a um único
usuário. (DATE, 1990)
É importante que você se atenha aos seguintes aspectos:
Um banco de dados é um sistema de armazenamento

de dados baseado nos relacionamentos entre
elementos de dados, buscando a não redundância
deles. (SALEMI, 1983)
O banco de dados possui uma estrutura física que representa

os dados que estão armazenados, com estruturas e regras de
manipulação bem definidas. No caso da computação, o banco
de dados representa o arquivo físico de dados armazenados em
34
Banco de Dados I
dispositivos periféricos, nos quais estão os dados de diversos

sistemas para consulta e atualização pelo usuário.
Sendo assim, a partir dos conceitos anteriormente citados, pode-se

chegar a um conceito mais amplo de banco de dados:
Banco de dados é um sistema que possui um

arquivo físico de dados armazenados em dispositivos
periféricos, nos quais estão armazenados aqueles
relacionados entre si, de diversos sistemas, para
consulta e atualização pelo usuário.
Definindo “dado” e “informação”

Uma vez que você teve o primeiro contato com o conceito de banco
de dados, é importante que se defina um aspecto importante, a
diferença entre dado e informação. A princípio parecem ter o
mesmo significado, mas quando se refere a esse tema no escopo de
banco de dados, existe uma significativa diferença.
O dado é o valor cadastrado no banco de dados, que será

exportado para o usuário por meio das consultas realizadas. Cada
conjunto de informações exportadas, ou listadas, está diretamente
relacionado à forma pela qual foi definida a regra de seleção
dos dados. Nesse contexto, um dado pode ser representado pelo
nome de um cliente, pela rua onde mora, número da casa, enfim,
ele representa um elemento de informação.
A informação diz respeito a um conjunto de dados que,

devidamente contextualizados, representa algo para o usuário.
Por exemplo, rua, número da casa, bairro, CEP, cidade,
estado (UF) podem ser encarados como dados cadastrais de
um cliente, porém, o conjunto desses dados compõe uma
informação, representando o endereço completo do cliente.
Os dados abrangem uma grande e variada forma de representação.

Como qualquer informação armazenada no banco de dados é um
dado, eles podem representar qualquer tipo de informação, como
uma data, uma hora, um nome, uma idade, etc.
Unidade 2 35
Assim sendo, os dados serão armazenados num banco sob um

determinado padrão pré-estabelecido, visando a delimitar o que
pode ser armazenado como um valor para o dado. Esses padrões
são denominados Tipos de Dado, em que cada dado definido
como elemento componente de um SGBD deve estar associado
ao seu tipo de dado correspondente.
Seguindo esse raciocínio, podemos encontrar num banco de

dados um tipo de dado que só armazena números inteiros,
utilizados, por exemplo, para armazenar o número de uma nota
fiscal, ou o código do DDD de um número de telefone.
Já para armazenar uma data de nascimento, o tipo inteiro não

consegue representá-la, pois as regras que regem as datas são
mais complexas, por exemplo, se tentarmos armazenar a data de
11/01/2011 em um tipo data, certamente o SGBD não aceitará
esse valor, uma vez que a data é inválida.
As regras de definição dos dados são essenciais para mantê-los

dentro de um padrão esperado e de fácil compreensão.
Não faz muito sentido utilizar um dado do tipo inteiro

para se armazenar o nome de uma pessoa, pois,
dessa forma, o armazenamento dos dados não estará
representando fielmente a realidade.
Sistemas de gerenciamento de banco de dados (SGBD)

Dentro da informática em geral, principalmente quando se refere
ao desenvolvimento de softwares, o banco de dados recebe uma
nomenclatura bem mais ampla: sistema gerenciador de banco de
dados, ou simplesmente SGBD.
O SGBD é o software responsável pelo gerenciamento,

armazenamento e recuperação dos dados no banco
de dados.
36
Banco de Dados I
Os sistemas gerenciadores de banco de dados surgiram no

início da década de 70, com a finalidade de promover maior
performance e segurança na tarefa de armazenamento,
recuperação e manutenção dos dados, impactando também numa
maior padronização no acesso a eles por parte das aplicações.
Os primeiros produtos de SGBDs tinham um custo elevado,
pois eram desenvolvidos sob uma tecnologia que necessitava de
um alto grau de especialização para serem operados. Na medida
em que novos investimentos foram aplicados na área e novas
pesquisas desenvolvidas, os SGBDs evoluíram consideravelmente,
tornando a sua utilização muito mais simplificada e os seus
recursos mais avançados. Atualmente, encontra-se como padrão
no mercado o banco de dados relacional, que opera sob o
enfoque de relacionamento entre os dados armazenados.
A partir da década de 80, com o barateamento na produção de
equipamentos e a produção em grande escala de computadores,
esse sistema de banco de dados passou a dominar o mercado,
tornando-se um padrão internacional.
Entretanto, as pesquisas não pararam por aí. Com a evolução

tecnológica dos equipamentos, o mercado passou a investir
na pesquisa de novas metodologias, técnicas e padrões para a
modelagem de bancos de dados, ou projeto deles.
Sendo assim, até hoje são várias as metodologias ou técnicas que

surgem com a finalidade de auxiliar os profissionais na árdua
tarefa de projetar banco de dados.
Pode-se dizer, então, que um sistema gerenciador de

banco de dados é uma ferramenta computacional em
constante atualização e evolução.
Uma ferramenta de banco de dados exige do seu usuário um

largo conhecimento de projetos sobre isso, que serão amplamente
testados e implementados.
Unidade 2 37
Fundamentos de um sistema gerenciador de banco de dados

Algumas características importantes dos sistemas de banco de
dados os diferenciam dos sistemas de arquivos tradicionais,
que também são formas de armazenamento de dados. Essas
características são:
a separação entre programas e dados;
o compartilhamento de dados e processamento

multiusuário;
o armazenamento no próprio banco de dados da sua

estrutura ou esquema.
Você poderá ler a seguir uma breve explicação de cada um

desses itens, a fim de facilitar a sua compreensão sobre o que há
de diferente em um sistema de banco de dados que o torna tão
especial.
Separação entre “programas” e “dados”

Esse tópico refere-se a uma propriedade fundamental para o
bom desempenho de um sistema de banco de dados. Planejar
um banco de dados não é tarefa simples, ou fácil. O projeto deve
representar fielmente as tarefas executadas diariamente fora do
computador e que, por algum motivo, foram implementadas nele.
Ou seja, um projeto de banco de dados deve

representar o mundo real, de forma eficiente e íntegra.
Porém, quando se refere à computação, principalmente à área de

desenvolvimento de softwares, o projeto de um banco de dados
envolve duas tarefas distintas:
a criação do modelo de banco de dados – realizada por
meio de uma ferramenta computacional;
38
Banco de Dados I
a implementação de um programa de computador –

que será responsável por interagir com esse banco de
dados. A criação do programa de computador se faz por
meio das linguagens de programação.
A criação do modelo de dados e sua implementação num SGBD

é tarefa geralmente designada a um especialista da área, o qual
deve ter conhecimentos específicos de como desenvolver e
implementar o projeto do banco de dados, de forma a obter maior
performance da ferramenta.
Já o desenvolvedor ou analista de sistemas deve implementar o

programa de computador de forma que consiga interagir com
o SGBD de modo eficiente e com toda a performance nas
operações realizadas no banco de dados. Esse é um dos pontos
cruciais de um projeto de um sistema de informação.
Por vezes, porém, tanto o projeto do banco de dados quanto

o programa em si podem ser desenvolvidos pelo mesmo
profissional, desde que tenha as qualificações adequadas às
funções.
As ferramentas de banco de dados têm como principal

propriedade a abstração dos dados. Isso significa dizer que o
programador de uma linguagem de programação não precisa
implementar o funcionamento das estruturas que compõem
o banco de dados, muito menos saber como elas funcionam e
foram criadas.
Cabe ao programador usar os recursos que a

ferramenta de banco de dados disponibiliza,
independente da linguagem de programação usada.
Veja a figura a seguir, ela ilustra um esquema de desenvolvimento

de software com acesso a banco de dados:
Unidade 2 39

Figura 2.1 – Esquema de desenvolvimento de Software com acesso a banco de dados.

Fonte: Elaboração do autor.
O programador é responsável por criar o programa de

computador que fará a integração da interface gráfica com os
dados do banco. Será por meio dessa aplicação que eles serão
cadastrados e manipulados pelo usuário.
As regras de funcionamento, ou de negócio, dessa aplicação

serão criadas pela linguagem de programação utilizada pelo
programador, sem ele saber como é o funcionamento interno do
gerenciador de banco de dados.
O banco de dados representa as tabelas que foram criadas para

o armazenamento e relacionamento dos dados. Esse esquema
segue as regras definidas pelo sistema gerenciador de banco de
dados. Esse banco é uma estrutura física armazenada em algum
dispositivo de armazenamento, como um hard disk (HD).
O sistema gerenciador de banco de dados é a ferramenta

computacional utilizada pelo especialista da área para modelar e
projetar o banco de dados físico, que deverá representar as tarefas
executadas pelo mundo real.
O especialista em banco de dados, que em alguns casos é

também o programador, é responsável por modelar esse banco,
identificando junto ao cliente final quais são as suas reais
necessidades.
40
Banco de Dados I
É importante salientar que a aplicação desenvolvida possui

regras separadas das implantadas no banco de dados. A aplicação
desenvolvida ou o programa de computador representa as regras
de utilização do sistema, chamadas de regras de negócio.
Os dados armazenados estão em uma outra camada que

representa a forma pela qual os dados serão manipulados e
armazenados. Uma camada não precisa saber detalhes de como a
outra foi desenvolvida, que linguagem usou ou como os dados são
fisicamente armazenados no computador. Isso é abstração.
Veja a próxima figura. Ela representa essa separação entre

programa e dados, e ainda acrescenta uma camada que representa
a interface gráfica de interação entre usuário e programa de
computador.
Figura 2.2 – Separação entre programas e dados.

O compartilhamento de dados e o processamento multiusuário

Tão importante quanto a definição de uma solução em
camadas, na qual há um grande nível de abstração como
visto anteriormente, o compartilhamento de dados é uma
característica predominante em soluções que utilizam banco
de dados.
Essa característica é fundamental para que dados cadastrados em

um sistema possam ser acessados por vários usuários ao mesmo
tempo, de lugares distintos.
Unidade 2 41
Além de permitir que os dados sejam acessados por vários usuários,

evita-se o cadastro repetido da mesma informação em banco de
dados diferentes, o que acarretará uma redundância de informações
e imprecisão dos dados.
Cabe salientar que aqui se tem mais um exemplo da separação

entre dados e programa, pois ao programador da aplicação
computacional não é necessário que saiba como esse multiacesso
funciona, mas é essencial que ele possa utilizar-se desses recursos
do sistema gerenciador de banco de dados.
Na representação a seguir, temos uma solução em que cada

usuário acessa uma única base de dados, idênticas, porém sem
integração. Em cada base de dados estão os produtos vendidos
pela filial, gerando, dessa forma, um controle de estoque essencial
ao funcionamento da empresa.

Figura 2.3 – Acesso a dados em bancos independentes.

Além de ter um único acesso à base de dados idênticas – o que

pode gerar dados incorretos e redundância das informações –, não
há uma distribuição de equipamentos, pois tanto a filial A como a
B terão um computador dedicado ao armazenamento dos dados,
bem como um computador para cada usuário, pois o acesso aos
dados é local.
O que significa afirmar que para cada usuário haverá

um computador com acesso a uma base de dados local e,
consequentemente, mais uma réplica dos dados armazenados,
o que, com certeza, resultará em uma grande redundância de
42
Banco de Dados I
informações e dados incorretos. Além disso, há o custo mais alto

para se manter essa solução que parece ser a mais simples.
Alguns problemas são comuns de acontecerem quando se utiliza

uma solução não compartilhada. Veja a seguir:
entrada repetida da mesma informação;

inconsistência dos dados;
excesso de dados;
falta de padrão dos dados cadastrados.
Para resolver esse problema é primordial que se utilize o aspecto

de compartilhamento de dados que um sistema gerenciador de
banco de dados disponibiliza. Além de uma base mais confiável,
o custo de manutenção e instalação da solução será mais barato,
pois será um computador dedicado ao armazenamento de dados
e a vários terminais de acesso, que não necessariamente precisam
ser computadores de alto valor no mercado.
Veja essa solução no diagrama:

Figura 2.4 – Acesso a banco de dados centralizado.
Unidade 2 43
O armazenamento no próprio banco de dados da sua estrutura ou esquema
De forma sucinta, um banco de dados pode ser visto

como sendo uma estrutura formada pelos dados
armazenados e pelas regras que criam as tabelas do
modelo projetado.
Assim como os dados são armazenados fisicamente no banco

de dados, no dispositivo de armazenamento disponibilizado
para o mesmo, como o hard disk (HD), o esquema que define
quais são as tabelas do banco, o relacionamento entre elas e o
tipo de dado de cada coluna também são armazenados junto
ao banco de dados.
Assim sendo, os dados e as regras de manipulação e
armazenamento dos dados não precisam ser tratados de forma
diferente pelo especialista em banco de dados que utiliza a
ferramenta, na verdade, é mais um nível de abstração, pois para
ele é indiferente a forma pela qual a ferramenta computacional
armazena essas regras.
Veja a figura a seguir:
SGBD

Figura 2.5 – Base de dados.

Arquitetura lógica de SGBD

Três características importantes da abordagem de banco de dados
são: isolamento entre dados e programas, suporte a múltiplas
visões do usuário e uso de um catálogo para gravar a descrição do
banco de dados (esquema).
44
Banco de Dados I
A figura a seguir ilustra uma arquitetura em níveis:
Usuários Finais
Visão VIsão
Externa Interna
Nível Externo
Nível Conceitual Esquema Conceitual
Esquema Interno
Nível Interno
Banco de Dados Armazenado
Figura 2.6 – Arquitetura lógica de SGBD em níveis.

O nível interno tem um esquema interno, que descreve a

estrutura de armazenamento físico do banco de dados. O
esquema interno usa um modelo de dados físico e descreve
detalhes de armazenamento de dados e caminhos de acesso para
esse banco.
O nível conceitual tem um esquema conceitual, que descreve

o banco de dados para a comunidade de usuários. O esquema
conceitual é a descrição global do banco de dados que esconde os
detalhes da estrutura física de armazenamento e concentra-se em
descrever entidades, tipos de dados, relacionamentos e restrições.
Um modelo de dados de alto nível ou um modelo de dados de
implementação podem ser usados nesse nível.
O nível externo ou visão inclui um número de esquemas

externos ou visões do usuário. Cada esquema externo envolve
a visão do banco de dados de um grupo de usuários. Cada
Unidade 2 45
visão tipicamente descreve a parte do banco de dados que um

particular grupo de usuários está interessada e esconde o resto
do banco daquele grupo. Um modelo de dados de alto nível ou
um modelo de dados de implementação podem ser usados neste
nível.
Independência de dados
A arquitetura lógica em 3 níveis pode ser usada para esclarecer
o conceito de independência de dados, que pode ser definida
como a capacidade de alterar o esquema em um nível sem alterar
o esquema do nível imediatamente superior. Apresentam-se 2
níveis de independência de dados:
Independência de dados lógica - é a capacidade de

alterar o esquema conceitual sem alterar o esquema
externo ou programas de aplicação. Pode-se alterar o
esquema conceitual pela adição de um novo tipo de
registro ou item de dado, pela remoção de um tipo de
registro ou item de dado. No último caso, esquemas
externos que se referem aos dados restantes não seriam
afetados.
Independência de dados física - é a capacidade de
alterar o esquema interno sem alterar o esquema
conceitual. Alterações no esquema interno podem
ser necessárias, pois alguns arquivos físicos são
reorganizados – por exemplo, pela criação de estruturas
de acesso adicionais – para melhorar a performance de
consulta ou atualização.
Arquiteturas de acesso de banco de dados

Plataformas centralizadas - na arquitetura centralizada,
existe um computador com grande capacidade de
processamento, o qual é o hospedeiro do SGBD e o
emulador para os vários aplicativos. Essa arquitetura
tem como principal vantagem a de permitir que muitos
usuários manipulem grande volume de dados. Sua
principal desvantagem está no seu alto custo, pois
exige ambiente especial para mainframes e soluções
centralizadas.
46
Banco de Dados I
Minicomputador
ou Mainframe
Terminais Locais
Modem
Terminal
Modem Remoto
Figura 2.7 – Arquitetura centralizada.

Sistemas de computador pessoal /PC - os

computadores pessoais trabalham em sistema stand-
alone, ou seja, fazem seus processamentos sozinhos.
No começo, esse processamento era bastante limitado,
porém, com a evolução do hardware, tem-se hoje PCs
com grande capacidade de processamento. Eles utilizam
o padrão Xbase e, quando se trata de SGBDs, funcionam
como hospedeiros e terminais. Dessa maneira, possuem
um único aplicativo a ser executado na máquina. A
principal vantagem desta arquitetura é a simplicidade.
Banco de dados cliente-servidor - na arquitetura
cliente-servidor, o cliente (front_end) executa as tarefas
do aplicativo, ou seja, fornece a interface do usuário
(tela, e processamento de entrada e saída). O servidor
(back_end) executa as consultas no SGBD e retorna
os resultados ao cliente. Apesar de ser uma arquitetura
bastante popular, são necessárias soluções sofisticadas de
software que possibilitem: o tratamento de transações,
as confirmações de transações (commits), desfazer
transações (rollbacks), linguagens de consultas (stored
procedures) e gatilhos (triggers). A principal vantagem
desta arquitetura é a divisão do processamento entre dois
sistemas, o que reduz o tráfego de dados na rede.
Unidade 2 47
Consulta Servidor de
Banco de Dados
Resultado da consulta
pc pc
cabo de Rede
pc
Figura 2.8 – Arquitetura cliente-servidor.

Banco de dados distribuídos (N camadas) - nesta

arquitetura, a informação está distribuída em diversos
servidores. Como exemplo, observe a Figura a seguir.
Cada servidor atua como no sistema cliente-servidor,
porém, as consultas oriundas dos aplicativos são
feitas para qualquer servidor indistintamente. Caso a
informação solicitada seja mantida por outro servidor ou
servidores, o sistema encarrega-se de obter a informação
necessária, de maneira transparente para o aplicativo,
que passa a atuar consultando a rede, independente de
conhecer seus servidores. Exemplos típicos são as bases
de dados corporativas, em que o volume de informação
é muito grande e, por isso, deve ser distribuído em
diversos servidores. Porém, não é dependente de aspectos
lógicos de carga de acesso aos dados, ou base de dados
fracamente acopladas, em que uma informação solicitada
vai sendo coletada numa propagação da consulta, em
uma cadeia de servidores. A característica básica é a
existência de diversos programas aplicativos consultando
a rede para acessar os dados necessários, porém, sem
o conhecimento explícito de quais servidores dispõem
desses dados.
48
Banco de Dados I
Figura 2.9 – Arquitetura distribuída (N camadas).

Nesta primeira seção, você teve um contato inicial com os conceitos

do sistema gerenciador de banco de dados, ou simplesmente
SGBD. Você deve ter percebido que em alguns momentos nos
referimos aos dados armazenados como sendo tabelas.
Entretanto, essa é uma notação normalmente utilizada quando

se interage com banco de dados, mas que não reflete a realidade
de mercado atual. Quando nos referimos a um SGBD, ele pode
ter duas formas básicas de representação dos dados, as tabelas,
base de um SGBD relacional, e as classes, que são a base de um
SGBD orientado a objetos.
Unidade 2 49
Seção 2 – Tipos de sistemas de gerenciamento de

banco de dados
Dentro das características de cada ferramenta computacional
de banco de dados, ou SGBD, os bancos podem ser divididos
em duas formas de representação dos dados: banco de dados
relacional e banco de dados orientado a objetos.
Alguns autores poderiam ampliar essa definição, porém ela está

voltada para as ferramentas de gerenciamento de banco de dados
existentes no mercado atual, ou seja, para o escopo de ferramenta
computacional e a forma pela qual os dados são armazenados e
gerenciados pelo sistema.
a) Banco de dados relacional

Em um banco de dados relacional, os dados são armazenados em
estruturas físicas que possuem relacionamentos entre si. Essas
estruturas recebem o nome de tabelas relacionais.
Uma tabela relacional é uma simples estrutura

de linhas e colunas. Cada linha contém um mesmo
conjunto de colunas ou campos, porém, as linhas
seguem um determinado tipo de ordem.
Cada linha da tabela, formada por um conjunto de colunas,

representa um registro (ou tupla). Os registros não precisam
necessariamente conter dados em todas as colunas, ocorrendo
a ausência de informação, caracterizando o que denominamos
valor nulo, a ser melhor apresentado na seção 2 da Unidade 5.
As colunas de uma tabela também são chamadas de campos.
Os campos possuem características que definem o dado que será
Cada coluna é identificada
por um nome e um tipo de armazenado na tabela. Os sistemas de banco de dados possuem
dado. regras para consistir os dados que serão armazenados.
Em um banco de dados relacional podem existir uma ou centenas
de tabelas. O limitador é imposto exclusivamente pela ferramenta
computacional, ou o SGBD utilizado.
50
Banco de Dados I
Comparando uma tabela relacional com um arquivo tradicional,

do sistema de arquivos de um computador, identificam-se as
seguintes diferenças:
TABELA RELACIONAL ARQUIVOS
As linhas de uma tabela não possuem Os registros podem ser armazenados de

nenhum tipo de ordenação. forma ordenada, por meio da aplicação de
algortimos de ordenação.
A busca a um desejado dado na tabela não
pode ser feita por indexação.
Não é possível acessar uma linha da tabela

com base na posição da mesma dentro da
estrutura.
Um campo da tabela é monovalorado, ou seja, Cada registro do arquivo pode ser

formado por um único valor. representado por vários valores de tipos
diferentes.
O acesso aos dados de uma tabela pode O acesso ao arquivo pode ser randômico,
obedecer aos mais variados critérios, sem que seqüencial ou indexado.
novas estruturas precisem ser criadas.
As tabelas são formadas por linhas e colunas. Os arquivos são formados por registros.
Quadro 2.1 - Diferença entre tabela relacional e arquivos.

Para ilustrar melhor uma tabela relacional, veja a representação

abaixo:
Colunas /Campos
Linhas / Registros
Cada coluna de uma tabela obedece às regras definidas na

criação da tabela, recebendo um tipo de dado, que representa o
conjunto de valores que podem ser armazenados.
Unidade 2 51
Uma coluna do tipo numérico só poderá armazenar

dados do tipo numérico. Ao se tentar inserir dados
que não sejam numéricos, o SGBD recusará o cadastro,
da forma pela qual a ferramenta executa essa tarefa.
Cada ferramenta pode executar essa tarefa de forma
diferente, porém, todas elas evitaram o cadastro
indevido dos dados.
Basicamente, cada coluna representa o tipo de cada dado,

ou seja, as regras de entrada dos dados, de modo a evitar a
incompatibilidade deles. Já as linhas representam todos os dados
cadastrados, ou seja, um conjunto de colunas ou campos.
Imagine o cadastro de alunos de uma escola. Os dados ou
colunas que representam um aluno poderiam ser nomeados como:
Matricula, Nome, Idade e Sexo entre outros.
As linhas da tabela representam um registro único, ou seja, os

dados de um único aluno, com os valores cadastrados:
Lembre-se de que as
linhas representam o
CodigoAluno Nome Idade Sexo
número de registros
1 Fulano de Tal 35 M
cadastrados na tabela e
as colunas representam
campos que compõem a
estrutura. Alguns campos da tabela, além do tipo de dados e do nome de
identificação, possuem uma propriedade adicional. Esses campos
recebem o nome de chave.
Chaves
O conceito básico para identificar linhas e estabelecer relações
entre linhas de tabelas de um banco de dados relacional é o de
chave.Em um banco de dados relacional há ao menos dois tipos
de chaves a considerar: a chave primária e a estrangeira.
As chaves são restrições de integridades impostas ao

banco de dados.
52
Banco de Dados I
Chave primária
A chave primária é a chave que identifica cada registro, dando-lhe
unicidade. Essa chave primária nunca se repetirá dentro da
estrutura da tabela. Ela pode ser formada por um único campo
ou coluna, ou por vários campos.
A chave primária é uma coluna ou conjunto de

colunas cujos valores distinguem uma linha das demais
dentro de uma mesma tabela.
Assim, duas entidades (de mesmo tipo) não podem ter o mesmo
valor para o atributo chave. Essa não é uma propriedade de uma
extensão particular, mas é uma restrição para todas extensões do
tipo de entidade. Por exemplo, o atributo CodigoAluno do tipo
de entidade Aluno possui um valor diferente para cada entidade
aluno (dois alunos não podem ter o mesmo código).
Quando uma chave é formada por vários campos, diz-se que ela é
uma chave primária composta.
Uma tabela não pode
ter mais de uma chave
Na tabela Alunos, apresentada anteriormente, o campo
primária. Porém, em se
CodigoAluno é uma coluna sujeita a ser uma chave
tratando de uma chave
primária, uma vez que não poderão ser cadastrados
primária composta, ela
vários alunos com o mesmo código. Entretanto, os
terá mais de uma coluna
campos Idade, Nome e Sexo podem ser repetidos
(atributo).
durante o cadastro de alunos, pois podemos ter alunos
com o mesmo nome, idade e sexo, dessa forma, não
podem ser de forma alguma chave primária.
Você verá a forma de criar e definir essas chaves nas próximas

unidades. Por isso, não se preocupe, por enquanto, com a forma
de como se fazer isso em um sistema gerenciador de banco de
dados, mas sim com a finalidade de cada uma dessas estruturas
dentro de um banco de dados relacional.
Unidade 2 53
Chave estrangeira
A chave estrangeira corresponde aos campos, ou campo,

de uma tabela, cujos valores cadastrados aparecem
necessariamente na chave primária de outra tabela.
A chave estrangeira é o mecanismo que permite a implementação

de relacionamentos em um banco de dados relacional.
Uma chave estrangeira impõe algumas restrições ao banco de
dados modelado, são elas:
Quando há a inclusão de uma linha na tabela que contém

a chave estrangeira, é necessário que o valor inserido
exista na tabela principal, caso contrário, a inclusão não
poderá ser realizada.
Observe a figura a seguir. Os valores inseridos na tabela

“pai” ou principal estão todos cadastrados na tabela
“filho” ou secundária. Caso tentássemos inserir uma
cidade não cadastrada na tabela aluno, o SGBD emitiria
uma mensagem de erro.
Figura 2.10 – Exemplo de inclusão de uma linha na tabela.

Quando da alteração de valores da chave estrangeira,

é necessário que o novo valor cadastrado exista na
chave primária da tabela secundária, caso contrário a
alteração não será realizada.
54
Banco de Dados I
Observe na figura a seguir, que a cidade do aluno 3 foi

alterada. Essa alteração só foi possível porque a cidade
cadastrada existia na tabela secundária.
Figura 2.11 – Exemplo de alteração de valores da chave estrangeira.

Quando da exclusão de um dado da tabela principal, cujo

valor exista em alguma tabela relacionada, a exclusão
deve ser cancelada ou o registro na tabela relacionada
também deverá ser excluído.
No momento da criação da chave estrangeira, temos

a opção de criar, permitindo a exclusão dos dados
envolvidos ou não. Não permitindo a exclusão, o SGBD
emitirá uma mensagem de erro, acusando que existem
dados relacionados. Permitindo a exclusão, todos os
dados relacionados serão excluídos.
Figura 2.12 – Exemplo de exclusão de um dado da tabela.

Unidade 2 55
Quando da alteração de um campo de chave primária

que é chave estrangeira para outra tabela, a alteração
deve se refletir a todas as tabelas relacionais, contendo
o novo valor do campo.
Exemplo: observe que foi alterado o código da cidade

de Brasília para 30, essa alteração se estendeu a todos
os registros relacionados.
Figura 2.13 – Exemplo de alteração de um campo de chave.

Continuando no estudo da estrutura de uma banco de dados

relacional, a definição de uma chave estrangeira é essencial ao
sistema de tabelas relacionais.
A chave estrangeira é fundamental na criação de um

relacionamento entre tabelas.
56
Banco de Dados I
Imagine um sistema computacional para o

cadastramento de cursos e matrículas de alunos. As
tabelas de Alunos e Cursos representam diretamente
os dados cadastrados. A entrada de dados acontece
diretamente nas tabelas.
Já na tabela de Matrículas, as linhas ou registros
devem representar o aluno e o curso no qual ele se
matriculou. Diferente das tabelas anteriores, a tabela
de Matrícula tem dois relacionamentos diretos: um
com o aluno que está cadastrado na tabela de Alunos
e outro com o curso que está cadastrado na tabela de
Cursos.
Sendo assim, diz-se que a tabela de matrículas está
relacionada com a de alunos e com a tabela de cursos.
Isso é possível porque a tabela de Matrículas possui
uma chave estrangeira para tabela de Alunos, que
se relaciona com o campo Matricula dessa tabela, e
outra chave estrangeira para tabela de cursos, que se
relaciona com o campo Codigo dessa tabela.
Veja a seguir uma representação da chave estrangeira:
Figura 2.14 – Representação de chaves estrangeiras.

Sempre que se for cadastrar uma matrícula de aluno, não é

necessário recadastrar os dados do aluno e nem mesmo do curso.
A tabela matrícula cadastrará como aluno o CodigoAluno
Unidade 2 57
do estudante desejado na tabela de alunos e, em curso, o

CodigoCurso, originário da tabela de cursos.
Isso garante uma propriedade importante de um SGBD: a

integridade dos dados. Como os campos estão relacionados, não
será possível cadastrar numa matrícula um aluno inexistente ou
um curso inexistente.
b) Banco de dados orientado a objetos

Hoje, o banco de dados orientado a objetos é um fator emergente
que integra o banco de dados e a tecnologia de orientação a
objetos.
Os bancos de dados orientados a objetos iniciaram-se,

primeiramente, em projetos de pesquisa nas universidades e
centros de pesquisa. Em meados dos anos 80, eles começaram
a se tornar produtos comercialmente viáveis e se mantêm em
constante evolução até os dias atuais.
O desenvolvimento dos sistemas de gerenciamento

de banco de dados orientado a objetos (SGBDOO)
teve origem na combinação de ideias dos modelos
de dados tradicionais, SGBD, e de linguagens de
programação orientada a objetos, LPOO.
Os modelos de dados orientados a objetos têm um papel

adicional nos SGBDs, pois são mais adequados para o tratamento
de objetos complexos, como: textos, gráficos e imagens.
Modelos de dados orientados a objetos

Resumidamente, pode-se dizer que orientação a objetos
corresponde à organização de sistemas como uma coleção de
objetos que integram estruturas de dados e comportamentos.
Dessa forma, um banco de dados orientado a objetos não possui

a sua arquitetura baseada em tabelas, como no sistema relacional,
mas sim em objetos. Afinal, o que são esses objetos?
58
Banco de Dados I
Objeto
Os objetos são abstrações de dados do mundo real,

com um estado descrito por atributos que podem
apenas ser acessados ou modificados por meio de
operações definidas pelo criador do objeto. Um objeto
individual é chamado de instância ou ocorrência de
objeto.
A parte estrutural de um objeto é similar à noção de tabelas no

modelo relacionamento. Ou seja, fazendo uma correlação com o
banco de dados relacional, a sua estrutura é formada por tabelas,
que são a junção de linhas e colunas. As informações de cada
tabela são definidas pelas estruturas de cada campo ou coluna.
Em um objeto não há a figura de uma tabela, mas sim um
conjunto de atributos ou propriedades que definem as suas
características e a forma pela qual ele pode ser acessado. A forma
de acesso acontece por meio dos métodos que foram atribuídos a
ele, caso contrário, seus valores não podem ser modificados.
Para quem cria as regras dos objetos, é importantíssimo que

sejam avaliadas todas as possibilidades de uso desse objeto. Já
para quem o usa, há um alto grau de abstração, pois ele não
precisa saber como essas regras foram implementadas, mas é
essencial que saiba como utilizá-las.
Importante: vale destacar que, em alguns casos, a

mesma pessoa responsável pela definição do objeto
pode ser o seu usuário final.
De forma sucinta, pode-se imaginar que o criador do objeto

define as suas propriedades e as regras de uso. Já o usuário do
objeto é o responsável por aplicá-lo nas resoluções dos seus
problemas.
Em uma solução orientada a objetos, podem ser utilizados vários
deles, como se fossem as tabelas de um modelo relacional. A esse
Unidade 2 59
conjunto de objetos chamamos de classe. Cada classe segue as

regras implementadas nos objetos que a compõem.
O objeto pode ser visto como a descrição ou

especificação de objetos. Esse objeto possui duas
partes: a interface, que é visível para o usuário, e a
implementação, visível só para o usuário construtor
do objeto.
Representação do objeto
Em um modelo relacional, cada tabela representa unicamente
a estrutura dos dados que serão armazenados ali e as regras de
integridade, como chaves primárias e estrangeiras.
Em um modelo orientado a objetos, essa representação é

alterada significativamente, pois além dos dados armazenados,
também são armazenadas as regras de uso do objeto, com as
operações e validações que serão permitidas.
Veja a figura a seguir, que representa um objeto Aluno:
Os métodos representam
a forma de acesso ao Figura 2.15 – Representação do objeto aluno.
objeto. É pelos métodos Fonte: Elaboração do autor.
que se executa uma
determinada tarefa do
objeto ou se alteram as
Observe que não há mais a representação em forma de tabelas,
suas propriedades. Os com linhas e colunas. O que temos é um único objeto Aluno que
métodos podem ser do tipo possui como propriedades o codigoaluno, o nome, a idade e o sexo.
construtor, recuperador
ou modificador. O objeto Aluno deve conter as regras de uso desse objeto.
As propriedades dele só podem ser alteradas pelos métodos
implementados pelo seu criador. Assim, o objeto Aluno passa a
ter uma estrutura mais complexa, como a seguir:
60
Banco de Dados I
Figura 2.16 – Objeto aluno e seus métodos.

Para cada atributo de Alunos, há um método para alterar o seu

valor e um método para visualizar o seu valor atual. Essas são
as únicas formas de se alterar e visualizar os dados de um aluno
cadastrado.
Além dos métodos modificadores e recuperadores, há um

outro para cadastrar todos os dados do aluno (LerDados)
e um outro para listar os dados de um determinado aluno
(VisualizarDados).
Muitos outros métodos poderão ser agregados a esse objeto, com

as mais variadas finalidades. O usuário que for interagir com esse
objeto não precisa saber como essas regras foram implementadas
ou criadas, porém, precisa saber usá-las de forma a alcançar os
resultados esperados.
Para o cadastramento de vários alunos, não há uma estrutura

como tabela, mas sim um conjunto de instâncias (criações) de
objetos Alunos, conforme pode ser visto na figura a seguir:
Unidade 2 61
Figura 2.17 – Instâncias de aluno.

Para efeito didático, para o nosso estudo será adotado o modelo

relacional, por se tratar ainda do modelo mais usado no mercado
de trabalho. Entretanto, os conhecimentos adquiridos poderão
ser aplicados a quaisquer tipos de banco de dados, independente
de ferramenta, tipo ou fabricante.
Seção 3 – Modelos de banco de dados
Um modelo de banco de dados é uma descrição dos

tipos de informações que estão armazenadas em um
banco de dados.
No caso da tabela de alunos, apresentada na Seção anterior,

o modelo de dados poderia informar que o banco de dados
armazena informações de alunos e que, para cada um, são
armazenados seu codigoaluno, nome, idade e sexo.
Em um modelo de dados não são informados os valores dos
campos cadastrados para cada tabela, mas sim a estrutura que
compõe a tabela de maneira formal e padronizada.
A criação de um modelo de dados deve seguir algumas regras

para que qualquer pessoa possa compreender a sua finalidade.
Para tanto, é necessária a utilização de uma metodologia de
62
Banco de Dados I
modelagem de dados. Existem, basicamente, duas formas de se

representar um modelo de banco de dados: textuais e gráficas.
O modelo criado para um banco de dados é

denominado esquema de banco de dados.
Para que você possa compreender melhor as definições

apresentadas, veja a figura a seguir:

Figura 2.18 – Esquema de banco de dados.

Em um modelo de banco de dados, normalmente são

considerados dois níveis de representação: o modelo conceitual e
o modelo lógico.
Modelo conceitual
O modelo conceitual
pode ser facilmente
Um modelo de dados conceitual é uma descrição encontrado nas referências
do banco de dados que será projetado de forma bibliográficas como
independente da ferramenta computacional de SGBD. modelo de entidade
relacionamento, ou
simplesmente MER.
Esse modelo representa os dados de cada tabela sem se preocupar
com a forma pela qual esses serão registrados no SGBD
utilizado. A estrutura de cada tabela passa a ser referenciada
como entidade, que compõe o esquema de banco de dados,
porém, de forma independente do SGBD a ser utilizado.
Para essa representação é adotada uma técnica

chamada de entidade-relacionamento, cuja
principal finalidade é descrever as entidades, seus
atributos e relacionamentos.
Unidade 2 63
A partir deste momento usaremos a mesma representação para

o modelo conceitual. Acompanhe: na seção 2, foi feita uma
representação da tabela Alunos da seguinte forma:
CodigoAluno Nome Idade Sexo
1 Fulano de Tal 35 M
Vamos, então, representá-la a partir de um modelo de entidade

relacionamento, MER, por se tratar de um modelo mundial.
Este modelo constitui uma forma de representação gráfica para
os conceitos atribuídos ao Modelo Entidade Relacionamento.
Podem-se observar diversas notações adotadas por estudiosos na
área. A seguinte notação será adotada:
Tipo de entidade
Tipo de entidade fraca
Tipo de relacionamento
Tipo de relacionamento de identificação
Atributo
Atributo chave
Atributo multivalorado
Atributo derivado
Atributo composto
E1 R E2 Participação total de E2 em R
E1 R E2 Cardinalidade 1 : N para E1 : E2 em R
(min, max)
R E Restrição (min, max) de E em R
64
Banco de Dados I
Assim, a tabela Alunos será representada como:
CódigoAluno
Figura 2.19 – Representação do MER.

Nesse modelo estão descritos os campos da entidade Alunos, com

uma informação adicional de que o campo CodigoAluno trata-se
de uma chave primária (única), por isso a representação .
Como o modelo pode e normalmente representa várias tabelas do

esquema de banco de dados, vamos incluir mais algumas tabelas
a esse modelo para que você tenha uma visão mais ampla desse
tipo de representação:
Figura 2.20 – MER de duas entidades.

De acordo com o modelo anterior, tem-se o relacionamento entre

as entidades Alunos e Cursos. Os atributos da entidade Alunos
continuam os mesmos, sendo que cada aluno é identificado
unicamente pelo seu CodigoAluno. Na entidade Cursos,
que possui os atributos CodigoCurso, Descricao e Vagas, a
identificação de unicidade é realizada pelo atributo CodigoCurso.
Note que forçadamente não foram acentuados os nomes de

atributos. Isso é uma regra que deve ser mantida, uma vez que na
Unidade 2 65
criação formal deste modelo as ferramentas computacionais não

aceitam acentuação.
Voltando ao modelo: surgiu uma nova entidade, representada por

um losango que representa uma entidade associativa e indica que
a relação de Alunos para Curso é de 1 e de Cursos para Alunos é
de “N”, ou seja:
Cada aluno pode se matricular em apenas um curso.

Cada curso pode receber “N” alunos matriculados.
Modelo lógico
O modelo lógico é uma representação do esquema

de banco de dados que leva em consideração a
ferramenta computacional que será utilizada para o
projeto do banco de dados.
Dessa forma, se o SGBD for relacional, ele terá um tipo de

representação. Caso seja orientado a objetos, ele terá outra
representação. Em outras palavras, o modelo torna-se dependente
direto do SGBD utilizado.
Como esta disciplina se baseia no modelo relacional, adotaremos
o modelo lógico para SGBD relacional, que se estrutura a partir
de tabelas de banco de dados. Essas tabelas compõem o esquema
de banco de dados e, para cada uma há os nomes das colunas.
O modelo lógico tem como principal finalidade

descrever as tabelas que compõem o banco de
dados e as suas respectivas colunas, resolvendo o
relacionamento entre elas, ou seja, mostrando os
campos que passam pelo relacionamento.
Veja o mesmo modelo conceitual apresentado anteriormente,

agora em uma representação de modelo lógico:
66
Banco de Dados I
Perceba que o nível

de detalhamento das
informações deste nível é
bem maior. São indicadas
as colunas que são chaves
primárias (PK), as que
pertencem como chaves
estrangeiras (FK), as que
são chave estrangeira
Figura 2.21 – MER nível lógico. e também pertencem à
Fonte: Elaboração do autor. chave primária (PFK), tipos
de dados, dentre outras
Cabe observar que um modelo não exclui o outro, ou seja, em informações.
um projeto de banco de dados pode-se adotar ambos os modelos,
dependendo do grau de representação que o especialista deseja
implantar. Para cada um dos modelos utilizados há um conjunto
de regras para auxiliar na definição dos relacionamentos entre as
tabelas, que recebem o nome de cardinalidade.
Síntese
Você teve a oportunidade, nesta unidade, de se familiarizar

com alguns conceitos importantes banco de dados. De forma
simplificada, quando se fala em banco de dados, fala-se em
gerenciamento de informações ou dados.
Um banco de dados é um sistema complexo, que envolve

recursos humanos e materiais, que vão além do computador.
Na computação, o gerenciamento de dados é representado pelo
SGBD, que pode utilizar duas formas de armazenamento de
dados: o Relacional e o Orientado a Objetos.
No modelo relacional os dados são armazenados em Tabelas,

representadas por meio de linhas e colunas. Cada coluna possui
um tipo de dado que define as regras de entrada dos valores que
serão armazenados. Já as linhas representam os registros (ou
conjunto de colunas) armazenados na tabela.
As tabelas possuem regras para garantir a integridade dos dados.

As principais regras são: definição do campo que não pode
Unidade 2 67
repetir (chave primária) e a definição dos campos que dependem

de outra tabela (chave estrangeira).
Já no modelo orientado a objetos, os dados são armazenados em

objetos, que são definidos por meio de classes. Essas representam
a estrutura do objeto e as regras de manipulação dos objetos.
As características de cada objeto são definidas por meio de

atributos da classe, que define as regras de entrada dos valores no
objeto.

1) Se lhe fosse apresentado um conjunto de ferramentas computacionais
para o gerenciamento de dados, quais requisitos você utilizaria para
avaliar a melhor ferramenta?
68
Banco de Dados I
2) A utilização de uma ferramenta computacional do tipo SGBD significa

garantia de que o banco de dados modelado atenderá a todas as
necessidades do usuário?
Saiba mais
Para aprofundar as questões abordadas nesta unidade, você

poderá pesquisar em:
CHU, S. Y. Banco de dados: organização, sistemas e

administração. São Paulo: Atlas, 1983.
CHEN, P. Modelagem de dados: a abordagem entidade-

relacionamento para projeto lógico. São Paulo: Makron Books,
1990.
DATE, C. J. Bancos de dados: fundamentos. Rio de Janeiro:

Campus, 1985.
. Introdução a sistemas de banco de dados. 8. ed.

Rio de Janeiro: Campus, 1990.
Unidade 2 69
3
unidade 3
Modelagem de dados e projeto

de banco de dados
n Compreender os processos para se projetar um banco
de dados.
n Entender o conceito de modelagem de dados.
n Identificar os tipos de cardinalidades nas relações entre

os elementos do modelo de dados.
Seções de estudo
Seção 1 Projetando um banco de dados
Seção 2 Entendendo e definindo as cardinalidades


Como você observou na unidade anterior, um banco de
dados é formado por muitas tabelas, cuja principal finalidade
é proporcionar um acesso rápido aos dados e garantir a sua
integridade.
O ato de projetar uma solução de banco de dados é uma tarefa

árdua, pois deve representar todas as informações manipuladas
por uma determinada organização no seu dia a dia. Junto a essas
informações há um conjunto de regras que são realizadas por
cada usuário no manuseio com os dados. Essas regras, na maioria
das vezes, são de conhecimento e domínio de cada programador
a respeito das tarefas executadas.
Transcrever essas tarefas, informações, dados e regras de

utilização consiste em um processo demorado, que deve ser
realizado de forma consciente, e que exige um forte padrão de
análise e documentação das metodologias utilizadas.
Dessa forma, nesta unidade você estudará algumas regras que

devem ser adotadas ao se modelar um projeto de banco de dados e
quais as formas de se representar o relacionamento entre os dados.
Seção 1 – Projetando um banco de dados

Projetar um banco de dados significa estruturar a solução que
será implementada mais tarde em um SGBD. Ou seja, define-se
o que será feito e como será feito antes de se começar a trabalhar
realmente.
O SGBD é uma ferramenta computacional que

apenas formalizará as regras definidas no projeto
da solução de banco de dados. Regras definidas de
forma inconsistente serão criadas pelo SGBD de forma
inadequada. E é aí que está o perigo.
64
Banco de Dados I
A ação de projetar o esquema de banco de dados objetiva

especificar as tabelas que serão criadas, que campos essa tabela
terá, quais os tipos de cada campo. Essa tarefa deve ser analisada
de forma a se evitar, ao máximo, constantes alterações, pois, no
modelo de banco de dados, elas significam trabalho redobrado e
alto custo de produção.
Sendo assim, algumas regras devem ser seguidas para a definição

do modelo de banco de dados:
Determinar qual a finalidade do banco que está sendo

modelado: isso é importante para definição de quais
dados serão armazenados.
Dividir o problema em várias tabelas: dividir em

quantas tabelas forem necessárias, de forma que
representem um conjunto de dados semelhantes ao
mundo real, gerando regras específicas para cada uma
delas e definindo um formato para cada campo.
Determinar os relacionamentos: gerar as chaves

primárias e estrangeiras de cada tabela, de forma que a
integridade dos dados seja mantida.
Refinar o modelo criado: validar e comparar os

resultados obtidos com os valores do mundo real.
Assim como você teve acesso a um conjunto de regras para se

alcançar o objetivo desejado, veja os problemas mais comuns em
um projeto de banco de dados.
Número excessivo de campos nas tabelas: certifique-se

de que os campos definidos, para uma tabela, dizem
realmente respeito ao assunto.
Campos que normalmente não são cadastrados: isso

é um grande indício de que essas informações estão no
lugar errado e que devem ser melhor estruturadas.
Várias tabelas com os mesmos campos: isso gera

redundância de informação.
Unidade 3 65
Tabelas sem chaves primárias e estrangeiras: conforme

abordado na unidade 2, as chaves primárias e estrangeiras
são elementos muito importantes no banco de dados.
Durante o projeto do banco de dados deve-se analisar
individualmente cada dado, identificando claramente
a função de cada um deles, elegendo-os membros
participantes de chaves primárias e/ou estrangeiras.
Durante a etapa de projeto de um banco de dados é

imprescindível que você tenha seu foco nos dados e na sua
função dentro das atividades que estão sendo informatizadas,
sem se preocupar ou se deixar influenciar por aspectos relativos
ao software que vai acessar esses dados. Com o advento dos
SGBDs, conseguiu-se a independência entre programas e dados,
Um determinado dado pode ser
acessado por diversas aplicações. dessa forma, o endereço de um cliente, por exemplo, não pertence
mais exclusivamente a um determinado setor ou software da
empresa, mas poderá ser acessado pelo software de mala direta,
pelo software de cobrança, de crediário, e tantos quantos
necessitarem da informação.
É muito importante que você se atenha ao escopo de um

profissional de banco de dados, principalmente aquele que
vai modelar o projeto. Quando esse profissional executar as
suas tarefas, partirá de um modelo real de processos, que são
executados no dia a dia por várias pessoas e que, por algum
motivo, deseja-se automatizar essas tarefas por meio do
computador.
As informações que fazem parte do escopo

do problema a ser resolvido precisam ser bem
compreendidas por quem vai projetar o banco
de dados, pois a solução deve refletir o mesmo
funcionamento atual, de forma mais rápida, precisa e
automática.
Basicamente, a solução esperada pelo cliente tem que ser

transformada em um conjunto de tabelas relacionais que
representem fielmente o processo atual e que, de preferência,
agilizem as tarefas executadas diariamente e garantam a
integridade dos dados.
66
Banco de Dados I
Conceitos e modelagem de dados

Se você pretende desenvolver um projeto de banco de dados
deverá possuir os conceitos básicos sobre modelagem de
dados. Não importa se sua aplicação é simples ou não: a correta
modelagem dos dados tornará a sua aplicação mais robusta e de
mais fácil manutenção.
Para efeito didático, apresentamos os conceitos básicos sobre

modelagem de dados, pois esse assunto é muito abrangente e
extenso. Aqui, você o conhece de forma mais objetiva, tendo em
vista a aplicabilidade, imediata, dos conceitos aprendidos.
As finalidades de se projetar um problema são as mais variadas.

Com a modelagem pode-se:
Vale a pena lembrar que
uma das finalidades de
representar formalmente o ambiente observado; se projetar é representar
as tabelas e os seus
documentar e formalizar; relacionamentos, de forma
a se verificar se atendem
fornecer processos de validação. ou não à solução desejada.
Ao se construir um modelo de dados, estamos projetando um

ambiente real para um ambiente informatizado, isso implica
em transformar o mundo real em representações formais
aceitas por um SGBD. Num modelo de dados estaremos nos
utilizando de entidades, as quais manterão as informações do
mundo real por meio de seus campos (ou colunas), e através de
especificações de como esses dados se relacionam entre si, ou seja,
os relacionamentos entre as entidades.
Para que um relacionamento seja definido, temos que determinar

algumas de suas propriedades, que vão refletir no comportamento
das informações quando este banco de dados estiver em operação,
a essas propriedades damos o nome de cardinalidade.
Unidade 3 67
Seção 2 – Entendendo e definindo as cardinalidades

As tabelas presentes num banco de dados interagem entre si, por
meio dos relacionamentos existentes entre as informações, por
exemplo, na tabela de alunos há a informação de qual curso cada
um pertence; na tabela de venda há a informação de qual produto
está sendo vendido.
Ao se estabelecer essa interação, devemos estar atentos à forma

como essa interatividade acontece, e projetarmos adequadamente
o modelo de dados de forma a representar fielmente o
ambiente que está sendo informatizado. Nesta seção, estaremos
abordando as formas de interação entre as tabelas, denominadas
cardinalidades.
Tipos de cardinalidade
As cardinalidades classificam-se em mínima e máxima. Veja a
seguir as características de cada uma delas.
Cardinalidade mínima
A cardinalidade mínima define se o relacionamento

entre duas tabelas é obrigatório ou não.
Para que você compreenda melhor a cardinalidade mínima entre

as tabelas, observe o exemplo a seguir, que representa a relação
entre País e Unidades Federativas (UF).
68
Banco de Dados I

Figura 3.1: Exemplo de cardinalidade mínima
Analisando a figura, é possível perceber que um país

pode ser cadastrado sem que haja uma unidade
federativa para ele. Por isso, a representação de um
zero (0) na cardinalidade mínima da entidade País para
entidade UF.
Por outro lado, na cardinalidade mínima de UF para
País há uma cardinalidade mínima de 1 ( representada
por |). Ou seja, uma unidade federativa deve
pertencer a um único país.
Dessa forma, o diagrama acima pode ser lido como:
Cardinalidade mínima:
cada País pode ou não possuir UF;
cada UF deve pertencer a um único País.
Uma abordagem prática do comportamento dos países com

relação a suas Unidades Federativas e vice-versa, abordado na
figura 3.1, pode ser observada na figura a seguir.
■P1 ■P2 ■P3 PAÍSES

■P4 ■P5
O P1,U3 O P2,U4
O P1,U1 OP5,U2 O P3,U5
Relacionamentos de Países e UFs
■U1 ■U2 UF
■U3 ■U4 ■U5
Figura 3.2 – Representação dos relacionamentos entre os elementos de duas tabelas.

Unidade 3 69
Perceba que cada país pode ou não estar associado a UF. No caso
do país 4, não está associado a nenhuma UF. Já cada UF deve
obrigatoriamente estar associada a um PAÍS, portanto, não há a
possibilidade de encontrarmos uma UF sem estar atrelada a um
PAÍS.
Cardinalidade máxima
A cardinalidade máxima define a quantidade

máxima de ocorrências entre as entidades que
participam de um relacionamento.
Observe, a seguir, as mesmas entidades País e UF, porém

representadas pela cardinalidade máxima.

Figura 3.3 - Exemplo de cardinalidade máxima.

Analisando a figura, é possível perceber que um

país pode ter várias unidades federativas. Por isso a
representação por meio do símbolo .
Por outro lado, a cardinalidade máxima de UF para
País continua com a cardinalidade máxima de 1 (
representada por | ). Ou seja, uma unidade federativa
deve pertencer a um único país.
Dessa forma, o diagrama acima pode ser lido como:
Cardinalidade máxima:
cada País pode não possuir ou possuir uma ou
várias UF;
cada UF deve pertencer a um único País.
Como pode ser percebido na figura 3.2 que explana de maneira

prática o estabelecimento dos relacionamentos, o país P4 não está
70
Banco de Dados I
ligado a nenhuma UF, já o país P3 está ligado a apenas uma UF,

a UF5, e o país P1 está ligado a duas UFs, a UF1 e a UF3..
Juntando a cardinalidade máxima e mínima desse modelo, tem-

se o seguinte diagrama:

Figura 3.4 - Exemplo de cardinalidade máxima e mínima.Fonte:

Elaboração do autor.
Neste diagrama, um país pode ou não ter unidades federativas e

uma unidade federativa obrigatoriamente deve pertencer a uma
entidade país.
Além da cardinalidade máxima e mínima, uma cardinalidade

pode ainda representar outros relacionamentos.
a. Cardinalidade um para um (1:1)

Na cardinalidade um para um, o relacionamento entre as tabelas
sempre ocorre de um para um, ou seja:
Para cada registro de uma tabela, só existe uma única

ocorrência relacionada em outra tabela.
Observe a figura a seguir:

Figura 3.5 - Exemplo de cardinalidade um para um.

Unidade 3 71
Na representação da Figura 3.5, a entidade UF possui uma única

Capital e a entidade Capital pertence a uma única UF.
Na grande maioria dos casos, as duas entidades que estão

envolvidas num relacionamento um para um se fundem numa
única entidade, e o motivo é bastante simples, veja:
Suponha que a entidade UF possua dois campos: COD_UF

e NOME_UF, e a entidade CAPITAL possua também dois
campos COD_CAP e NOME_CAP. Agora cadastre duas UFs e
suas respectivas capitais. Vamos lá?
UF
UF CAPITAL
CAPITAL
COD_UF NOME_UF COD_CAP NOME_CAP
COD_UF NOME_UF COD_CAP NOME_CAP
11 SC
SC 11 FLORIANÓPOLIS
FLORIANOPOLIS
22 SP
SP 22 SÃO PAULO
SÃO PAULO
Temos, então, que cada UF está associada a sua CAPITAL e a

leitura inversa também é válida.
Neste modelo de dados, conforme visto na figura 3.3, temos

duas entidades e um relacionamento entre elas. Mas reflita sobre
o seguinte: se cada UF se relaciona com uma e somente uma
CAPITAL e, por conseguinte, cada CAPITAL se relaciona com
uma e somente uma UF, não seria mais simples se fosse incluída
o nome da capital diretamente na entidade UF??
Vamos ver como ficaria a entidade UF sob esta nova abordagem.
UF
COD_UF NOME_UF NOME_CAP
1 SC FLORIANÓPOLIS
2 SP SÃO PAULO
Perceba que conseguimos representar as UFs e suas respectivas

CAPITAIS simplesmente com uma entidade. Com isso,
foi eliminada muita complexidade do modelo de dados e,
consequentemente, o banco de dados está com menos entidades e
relacionamentos, o que deve permitir mais performance à ferramenta.
72
Banco de Dados I
Esta abordagem deve ser levada em consideração sempre que for

estabelecido um relacionamento um para um, a fim de verificar a
viabilidade de se reduzir a situação a apenas uma entidade. Caso
existam implicações em função do restante do modelo de dados,
então deve ser mantido o relacionamento e as duas entidades.
Para efeito de uma utilização didática do relacionamento um para
um, continue o estudo mantendo nos exemplos as duas entidades
com o relacionamento.
b. Cardinalidade um para N (1:N)

Nesse segundo tipo de cardinalidade já é possível que um registro
de uma determinada tabela se relacione com vários registros de
outra tabela.
Observe a figura a seguir:

Figura 3.6 - Exemplo de cardinalidade um para N.

A entidade Continente possui vários países. Já a entidade País

pertence a um único Continente.
Assim como foi demonstrada a possibilidade de redução de

um modelo de dados a apenas uma entidade onde existir um
relacionamento um para um entre duas entidades, veja, a seguir,
por que não é possível a mesma operação quando houver um
relacionamento um para N.
Suponha que a entidade CONTINENTE possua dois campos:

COD_CON e NOME_CON e a entidade PAÍS possua
também dois campos COD_PAIS e NOME_PAIS. Agora
Unidade 3 73
vamos cadastrar um continente e três países, que em tese estão

associados àquele continente.
CONTINENTE PAÍS
COD_PAIS NOME_PAIS
COD_CON NOME_CON
1 ALEMANHA
1 EUROPA
2 ITÁLIA
3 FRANÇA
Ao reduzir o modelo com o relacionamento um para N

para apenas uma entidade, veja como ficaria a entidade
CONTINENTE:
CONTINENTE
COD_CON NOME_COM NOME_PAÍS
1 EUROPA ALEMANHA, ITÁLIA, FRANÇA
É possível perceber claramente que podem existir situações em

que vários países pertençam a um mesmo continente, acarretando
o registro de todos eles num mesmo campo, NOME_PAIS.
Você pode então indagar: mas que problemas isso pode acarretar?
Uma das dificuldades mais óbvias a apresentar se refere à
impossibilidade de se definir, a priori, com grau suficiente de
certeza, quantos países poderão pertencer a um continente, a fim
de que possamos definir qual o número máximo de caracteres
(letras) que precisaremos reservar para registrar os países.
Outra dificuldade diz respeito à necessidade, por exemplo, de

se extrair desse banco de dados o nome do continente do país
chamado ITÁLIA. Para conseguirmos essa informação, teremos
que pesquisar no valor do campo NOME_PAIS por parte
do seu conteúdo. Essa atividade irá acarretar dificuldades de
implementação além de prejudicar o desempenho do SGBD.
74
Banco de Dados I
c. Cardinalidade N para N (N:N)

Bem, agora você chegou ao último tipo de cardinalidade,
que representa um modelo em que vários registros de uma
determinada tabela se relacionam com vários registros de outra
tabela. Veja o diagrama a seguir:

Figura 3.7 - Exemplo de cardinalidade N para N.

Nesse caso, a entidade Habitantes pode pertencer a várias

unidades federativas. Já a entidade UF possui vários habitantes.
Em um projeto de banco de dados, em termos conceituais, é

possível aceitar o estabelecimento de um relacionamento N
para N, conforme visto na figura 3.7, porém, ao refinarmos este
projeto para um modelo no nível lógico, ou ao implementarmos
esse modelo num SGBD, não será possível implementar um
relacionamento deste tipo. Veja o porquê.
Suponha que as referidas entidades UF e HABITANTES

apresentadas na figura 3.7 possuam, respectivamente, os
seguintes campos e que existam cadastrados, em ambas as
entidades, o exposto a seguir:
Unidade 3 75
UF HABITANTES
COD_UF(PK) NOME_UF COD_HAB(PK) NOME _HAB
1 SC 1 JOAO BIS
2 SP 2 MARIA HOFF
3 TECO TROTSK
Segundo o exposto no quadro, o UF SC possui como habitantes

JOAO BIS E MARIA HOFF. Mas MARIA HOFF, por sua
vez, é considerada habitante de duas UFs: SC e SP.
Além disso, o relacionamento está demonstrado através dos

traços entre os habitantes e suas UFs. Para que se estabeleça o
relacionamento entre duas entidades, deve ser criada uma chave
estrangeira(FK - Foreign key), relacionando-a com a chave
primária(PK – Primary key) da entidade principal.
Como neste caso temos uma chave estrangeira em UF e outra em

HABITANTES, estão apresentadas abaixo as duas entidades,
agora contendo as colunas que serão referência para as chaves
estrangeiras.
UF
UF HABITANTES
HABITANTES
COD_UF NOME_UF
COD_UF(PK) NOME_UFHABIT(FK)
HABIT COD_HAB NOME_HAB
COD_HAB(PK) NOME_HAB UF
UF(FK)
(PK) (FK) (FK) (FK)
1 1 SC
SC 1,21,2 11 JOÃO BIS
JOAO BIS 1 1
2 2 SP
SP 2,32,3 22 MARIA HOFF
MARIA HOFF 1,21,2
33 TECO TROSTSK
TECO TROTSK 2 2
Neste quadro, você pode notar que ocorre a mesma situação

ocorrida com a entidade continente, ao tentarmos incluir todos
os países num único campo. Como as colunas, HABIT e UF,
possuem a indicação de que são chaves estrangeiras (FK), elas
somente podem aceitar os valores das colunas que são chaves
primárias (PK) das entidades das quais dependem. Portanto, a
coluna HABIT só pode assumir valores que existam na coluna
COD_HAB e a coluna UF só pode receber valores que existam
na coluna COD_UF.
76
Banco de Dados I
Mas atenção para um detalhe: quantos valores existem para cada

coluna HABIT e UF? Para algumas UF, existem dois habitantes,
já para alguns habitantes existem 1 ou 2 UFs, mas poderiam
existir N habitantes para cada UF, assim como poderiam existir
N UF para cada habitante, afinal, este é um relacionamento N
para N.
Nessa situação, estamos novamente com várias informações numa

mesma coluna, assim como ocorreu na coluna NOME_PAIS da
entidade continente. Já ficou claro que vai ser impossível, a priori,
definir um número máximo de habitantes na entidade UF e um
número máximo de UF na entidade HABITANTES.
Para que seja resolvido o impasse, ou seja, para que consigamos

claramente identificar quais são os habitantes de cada UF e quais
são as UFS de cada habitante, é implementado uma terceira
entidade, denominada entidade associativa, que vai resolver a
problemática do relacionamento N para N.
A entidade que relaciona duas entidades de um

relacionamento N para N chama-se entidade
associativa.
No caso representado pela Figura 3.7, o relacionamento entre as

entidades UF e Habitantes ficaria da seguinte forma:
Figura 3.8 - Exemplo de entidade associativa.

Dessa forma, transforma-se um relacionamento N para N em um

relacionamento um para N, pois a tabela associativa sempre se
Unidade 3 77
relaciona com as tabelas externas por meio de uma cardinalidade

mínima de um.
Figura 3.9 - Exemplo de entidade associativa resultante de uma cardinalidade N para N.

Toda vez que tivermos um relacionamento N para

N, precisamos resolvê-lo, criando uma entidade
associativa.
Toda entidade associativa vai ter na composição da sua chave

primária, no mínimo, as colunas das chaves primárias das
tabelas que a originaram, no caso da tabela UF_ Habitantes, sua
estrutura seria a seguinte:
Toda entidade associativa vai ter na composição da sua chave

primária, no mínimo, as colunas das chaves primárias das
tabelas que a originaram, no caso da tabela UF_Habitantes, sua
estrutura seria a seguinte:
A chave primária da entidade UF_HABITANTES é

composta (chave primária composta) por duas colunas,
que são chaves estrangeiras. Não esqueça, que toda
entidade só poderá ter uma chave primária e ser
composta por N colunas.
78
Banco de Dados I
Agora fica fácil identificar quem é quem entre UF e

HABITANTES, por exemplo, o UF de código 1 (SC) possui
os habitantes de código 1 e 2, o HABITANTE de código 3
pertence ao UF 2.
Com o uso da tabela associativa UF_HABITANTES, o modelo

passa a ter para cada UF um grupo único de habitantes. E cada
habitante pertence a um único grupo de UFs.
Bem, depois dessas representações todas você deve estar se

perguntando: terei que fazer esses desenhos para modelar um
banco de dados?
Essa é uma forma padrão para representação de relacionamento

entre entidades, e mais do que isso, essa representação é o
primeiro passo para que a solução implementada venha a atender
as necessidades do usuário final.
Sendo assim, é necessário que você desenhe essas representações,

porém não é preciso que você faça isso à mão. A informática
disponibiliza algumas ferramentas que permitem a você desenhar
e analisar o modelo de dados proposto, permitindo inclusive a
conversão para alguns tipos de SGBD.
Síntese
Você estudou nesta unidade que o processo de modelar um banco

de dados é uma tarefa exaustiva, que exige muita concentração
e dedicação do profissional. Modelar um banco de dados
significa representar um mundo real por meio de entidades e seus
relacionamentos.
A relação entre as entidades é representada pelas cardinalidades,

que podem ser máximas e mínimas. Essa relação pode ser
representada por meio de três tipos de relacionamentos, que são:
um para um (1:1), um para N (1:N) e N para N (N:N).
Nos relacionamentos N para N, ou também denominados

muitos-para-muitos, é necessária a utilização de uma entidade
chamada associativa, responsável por agrupar os dados das
entidades correlacionadas. Sempre que o modelo apresentar
Unidade 3 79
um relacionamento N para N, ele deve ser alterado para

um relacionamento N para um, por intermédio da entidade
associativa.
A empresa Pare Aqui deseja implantar um sistema para controle dos seus
clientes. A empresa possui vários pátios de estacionamento na cidade,
porém, o controle é realizado por meio de anotações em caderno, e isso
tem gerado uma perda muito grande de recursos financeiros e até mesmo
de clientes.
A empresa adota as seguintes regras:
no caderno de clientes são cadastrados: o nome do cliente, a

sua data de nascimento e o seu CPF;
no caderno de veículos são cadastrados: a placa, a cor e o

modelo;
no caderno de estacionamento são cadastrados: a data de

entrada e saída, a hora de entrada e saída e a placa do veículo;
o mesmo cliente pode ter mais de um carro estacionado no

pátio.
1. Com base nessa descrição, desenhe a cardinalidade que liga as tabelas

do modelo criado a seguir.

80
Banco de Dados I
2. Identifique na tabela de Clientes o campo sujeito à chave primária.
3. Identifique na tabela de Veículos o campo sujeito à chave primária.
4. Identifique na tabela de Estacionados os campos sujeitos à chave

primária e às chaves estrangeiras.
Saiba mais

poderá pesquisar em:

1990.
COUGO, P. Modelagem conceitual e projeto de banco de

dados. 7. Reimp. Rio de Janeiro: Campus, 2001.
LIMA, A. da S. ERwin 4.0: modelagem de dados. 2. ed. São

Paulo: Érica, 2002.
Unidade 3 81
OLIVEIRA, A. R de. Modelagem de dados. São Paulo: Senac,

2004.
SOARES, S. P. de M. Dominando o ERwin: modelagem de

dados para banco oracle. São Paulo: Ciência Moderna, 2004.
82
4
unidade 4
Produtos de Banco de Dados
Entender os conceitos de software livre e de software de
tecnologia proprietária.
Conhecer alguns produtos de banco de dados construídos

sob o âmbito de software proprietário e sob o âmbito de
software livre.
Compreender o impacto do Software Livre nos produtos de

banco de dados.
Realizar a instalação de um banco de dados..
Seções de estudo
Seção 1 O mercado de software livre e de software
proprietário
Seção 2 As novas metodologias de banco de dados
Seção 3 As ferramentas de SGBD
Seção 4 A instalação de um SGBD
Seção 5 O acesso ao banco de dados MySQL


Existem aspectos de modelagem de dados para o projeto de
um banco de dados. assim como técnicas para mapear as
necessidades de um ambiente do mundo real para um modelo
de dados. Tal processo permite que este modelo de dados,
quando implementado num produto de banco de dados, possa
corresponder e atender a essas necessidades.
Passado este passo, o próximo é o da implementação do modelo

de dados num produto de banco de dados. Porém, é necessário
conhecer esses produtos de banco de dados para compreender
como o mercado está organizado no fornecimento desses
softwares.
Para isso, nesta unidade, será abordado e consolidado o mercado

de softwares, ditos proprietários, e uma nova tendência: a do
mercado de softwares livres. Além disso, serão apresentados os
conceitos de software proprietário e livre, bem como algumas
ferramentas de banco de dados e o mercado ao qual estão
relacionados.
Seção 1 – O mercado de software livre e de software

proprietário
A tecnologia de banco de dados, assim como a informática
de modo geral, sofre atualizações constantes. Como todo
profissional, o especialista em banco de dados tem também
o desafio de manter-se informado sobre as atualizações do
mercado, no que se refere aos novos produtos.
Nos últimos anos, a área de banco de dados sofreu uma grande

modificação com a chegada das ferramentas gratuitas, ou de
uso livre, como normalmente são chamadas. Tão importante
quanto o fato de elas serem gratuitas, foi o fato das ferramentas
se apresentarem robustas e confiáveis, o que agradou o mercado
de trabalho.
84
Banco de Dados I
As ferramentas gratuitas estão baseadas na idéia de Software

Livre, que tem como princípio:
Software Livre é uma questão de liberdade, não de

preço.
Refere-se à liberdade dos usuários executarem, copiarem,

distribuírem, estudarem, modificarem e aperfeiçoarem o
software. Mais precisamente, refere-se a quatro liberdades para
os usuários do software:
a liberdade de executar o programa, para qualquer

propósito;
a liberdade de estudar como o programa funciona e
adaptá-lo para as suas necessidades. Acesso ao código-
fonte, é um pré-requisito para essa liberdade;
a liberdade de redistribuir cópias de modo que você possa
ajudar ao seu próximo;
a liberdade de aperfeiçoar o programa e liberar os seus
aperfeiçoamentos, de modo que toda a comunidade se
beneficie.
Bem, como você pode ter notado, o software livre é uma

tendência de mercado. As ferramentas atuais, como: MySQL,
PostgreSQL, FireBird e outros, têm apresentado a cada
ano versões mais confiáveis e amigáveis, que permitem ao
usuário realizar as mesmas rotinas de outros bancos de dados
proprietários, com a mesma qualidade.
Essa é uma tendência de mercado e caberá a você, como gestor
da área de tecnologia da informação, escolher a ferramenta que
melhor agrade e atenda as suas necessidades.
Já o mercado de softwares proprietários apresenta as seguintes
características:
Unidade 4 85
Normalmente é cobrado um valor pelo uso do software,

a tão conhecida licença de uso. Esse valor pode ser
cobrado por meio da venda do direito do uso por tempo
ilimitado, ou ainda outra modalidade de comercialização
é a venda do direito de uso por um determinado período
de tempo.
Há a figura do proprietário do software, ou seja, de
quem o construiu e que responde pelo seu adequado
funcionamento.
O proprietário é quem fornece possíveis correções
no produto comercializado. Isso representa um certo
nível de garantia ao consumidor, uma vez que se
tem identificado a quem recorrer no caso de alguma
anormalidade no funcionamento do software.
Geralmente, o software proprietário possui uma política
de atualização e/ou evolução, onde estão contempladas
as inovações a serem incorporadas ao software, num
determinado período de tempo.
As ferramentas proprietárias existentes no mercado, como
Oracle, Ms-SQLServer, IBM-DB2, também têm a sua grande
contribuição no mercado de trabalho, pois são robustas, confiáveis
e de grande utilização no mercado atual, principalmente pelas
empresas de grande porte.
O mercado de banco de dados está em constante atualização e,
dessa forma, abre espaço para todos os tipos de ferramentas, o
que é bom, pois abre as portas para os profissionais da área de
tecnologia da informação, em especial aos com conhecimento em
banco de dados.
Lembre-se de que um especialista em tecnologia da informação
não é um especialista em ferramentas, mas em soluções, ele
não deve se prender a fabricantes ou produtos, mas precisa estar
preparado para as constantes mudanças que o mercado deverá
sofrer.
Independente das mudanças, as ferramentas de banco de dados
tendem a facilitar a vida do profissional de informática, tornando
a sua produtividade maior e mais eficiente, evitando que ele
tenha que editar comandos na mão, ou criar tabelas por meio de
comandos extensos.
86
Banco de Dados I
As novas ferramentas apresentam uma interface amigável de

maneira que o usuário cria e testa seus modelos de banco de
dados sem a necessidade de escrever comandos, com apenas um
clique do mouse.
Seção 2 – As novas metodologias de banco de dados

Assim como as ferramentas de desenvolvimento de banco de
dados têm evoluído, novas metodologias de implementação
também têm sido apresentadas ao mercado de trabalho. A
metodologia de banco de dados orientado a objetos tem obtido
grande aceitação no mercado de trabalho.
Mas o que é um banco de dados orientado a objetos?
Trata-se basicamente de um sistema em que a unidade de

armazenamento é tida como um objeto e, dessa forma, passa a ter
propriedades e não campos.
A principal característica desse tipo de banco de dados é a

abstração dos dados, que significa:
esconder os detalhes da implementação de seus módulos;

atrelar a manipulação dos dados a métodos previamente
programados no banco de dados;
compartilhar objetos;
expandir seus sistemas por meio de outros módulos já
existentes.
O banco de dados orientado a objetos combina os benefícios

e conceitos da programação orientada a objetos, com a
funcionalidade dos bancos de dados.
Unidade 4 87
Mas qual a diferença entre os dois tipos de banco de

dados apresentados nessa disciplina?
A diferença é simples.
Os bancos de dados relacionais usam uma arquitetura tabular

ou matricial, em que os dados são referenciados por meio de
linhas e colunas. Já os bancos de dados orientados a objetos
podem ser inteligentes, combinando a lógica e dados.
No que se refere aos bancos de dados relacionais:
As tabelas são definidas tendo como base a teoria da

normalização, evitando a redundância dos dados e
facilitando a pesquisa e atualizações.
O mercado hoje é dominado pelos relacionais.
São descritos em duas dimensões, por meio de linhas e
colunas.
A linguagem SQL (Structure Query Language) é um

padrão aberto para consulta e manipulação dos
bancos de dados relacionais de todos os fornecedores.
O SQL permite que os sistemas relacionais
desenvolvidos por muitos fornecedores possam se
comunicar entre si e acessar banco de dados comuns.
No que se refere aos bancos de dados orientado a objetos:
Não possuem uma linguagem padrão, dificultando

a conexão entre os bancos de dados de diferentes
fornecedores.
Com o crescimento do mercado de multimídia, video
games e aplicações Web que utilizam a linguagem
orientada a objetos Java, o uso de bancos orientados a
objetos está crescendo. Para atender a essa demanda,
os fornecedores de bancos de dados relacionais estão
introduzindo facilidades de armazenamento de objetos
em seus bancos de dados, chamando-os de banco de
dados relacional por objetos.
88
Banco de Dados I
A vantagem do banco de dados orientado a Objetos

é a lógica contida no objeto e a possibilidade de ser
reutilizado várias vezes em diversas aplicações.
São exemplos de ferramentas de banco de dados
orientados a objetos, banco de dados Caché e banco de
dados Oracle.
É importante salientar que os bancos de dados comuns,

tradicionais, foram desenvolvidos para empresas relativamente
estáveis, com grandes volumes de dados de baixa complexidade.
O mercado atual é liderado pela tecnologia relacional. Mas qual

o motivo desta liderança, uma vez que a tecnologia orientada a
objetos já é realidade para o desenvolvimento de software?
Para responder a essa questão, é preciso observar, não apenas

a tecnologia puramente empregada, mas também em como o
mercado de banco de dados encara essa mudança de tecnologia,
da relacional para a orientada a objetos.
Com relação à questão da tecnologia, está claro que a orientada a

objetos possui vantagens significativas, principalmente no que diz
respeito à reutilização de código e manipulação dos elementos do
software, tratados como objetos, possuindo os dados atrelados a
seus métodos de manipulação.
O grande e principal obstáculo da tecnologia orientada a objetos,

como padrão para ferramentas de banco de dados, está no fato
da sua padronização, principalmente na linguagem de acesso aos
objetos, e também numa questão de mercado, ou seja, no custo
da migração de uma base de dados relacional para uma base
orientada a objetos e seu impacto nos softwares que se utilizam
desta base de dados.
Este elemento de mercado merece especial atenção devido ao fato

de que os bancos de dados com tecnologia relacional possuem
atualmente características muito importantes para o mercado:
Padronização
Performance
Unidade 4 89
Compatibilidade entre os produtos com a mesma

tecnologia
Assim sendo, sob o ponto de vista tecnológico, fica relativamente
claro as vantagens que se têm ao utilizar-se de produtos
orientados a objetos. Porém, sob o ponto de vista empresarial,
do consumidor que paga pela mudança, por vezes, fica difícil
argumentar ou justificar os custos envolvidos numa mudança
de tecnologia em banco de dados, em que será modificada a
tecnologia mas os resultados continuarão sendo os mesmos,
ou seja, o banco de dados orientado a objetos vai continuar
fornecendo os dados aos aplicativos, como os que operam sob
a tecnologia relacional o fazem hoje, e já estão devidamente
instalados na empresa e com pessoas devidamente qualificadas a
operar com essa tecnologia.
Um aspecto que deve ser levado em consideração é de que o

banco de dados concentra importância crítica no ambiente de
tecnologia da informação, uma vez que fornece dados para
inúmeros departamentos das empresas e. Qualquer problema
envolvendo essa área vai ecoar para os softwares que atendem a
esses departamentos.
Qualquer modificação na área de banco de dados

é sempre questionada e deve ser muito bem
dimensionada, avaliando-se os riscos e os benefícios
que serão acarretados com a mudança.
Isso não significa afirmar que a área de banco de dados é

estanque e que a tecnologia relacional vai se perpetuar. Mas sim,
que a mudança de padrão, de relacional para orientado a objetos,
está em curso, acontece de modo mais cauteloso. Provavelmente,
daqui a algum tempo estará se consolidando definitivamente
como um padrão para a área.
90
Banco de Dados I
Seção 3 – As ferramentas de SGBD

O objetivo desta seção não é avaliar critérios para definir qual
ferramenta é a mais eficiente, mas sim apresentar as diferentes
plataformas existentes no mercado e quais as suas principais
características.
a) MySQL
O aplicativo MySQL é um sistema de gerenciamento de banco Acesso direto em: <http://
de dados relacionais baseado em comandos SQL (Structured www.mysql.com>.
Query Language - Linguagem Estruturada para Pesquisas), que

vem ganhando grande popularidade, sendo, atualmente, um dos
bancos de dados mais populares.
O MySQL foi criado na Suécia por dois suecos e um finlandês:

David Axmark, Allan Larsson e Michael Widenius, que
trabalham juntos desde a década de 80.
O sucesso do aplicativo deve-se em grande parte à fácil

integração com linguagens de programação para web, como
o PHP, e principalmente por se tratar de um banco de dados
gratuito, ou seja, o usuário não tem custo algum para adquirir o
produto, que pode ser baixado diretamente da internet.
Em 2008, o MySQL foi comprado pela Sun, que, em 2009, foi

comprada pela Oracle, a qual recebeu no portfólio de produtos o
MySQL.
b) PostgreSQL
O aplicativo PostgreSQL é um sistema de gestão de bases de Acesso direto em: <http://
www.postgresql.org>.
dados relacionais, desenvolvido como projeto de software livre.
Sua origem PostgreSQL está de certo modo ligada ao projeto
Ingres, desenvolvido na Universidade de Berkeley, Califórnia.
O líder do projeto, Michael Stonebraker, um dos pioneiros das
bases de dados relacionais, deixou a universidade em 1982 para
comercializar o Ingres, acabando por regressar a Berkeley.
Unidade 4 91
Em 1985, Stonebraker inicio um novo projeto pós-Ingres com

o objetivo de responder a muitos dos problemas que surgiam
relacionados a bases de dados relacionais. Esse novo projeto receberia
o nome de Postgres e, apesar do parentesco, não partilhou o código
base com o Ingres, seguindo sempre caminhos separados.
Em 1993 o projeto Postgres foi oficialmente abandonado pela

Universidade de Berkeley, mas devido ao fato do seu código-
fonte estar sob uma licença gratuita, foi possível manter o
desenvolvimento pela comunidade BSD.
Em 1995 foi adicionado um interpretador SQL, para substituir

a linguagem QUEL (desenvolvida para o Ingres) e o projeto
foi renomeado, primeiro para Postgres95 e mais tarde para
PostgreSQL.
c) InterBase
Acesso direto em: <http:// O aplicativo InterBase é um gerenciador de banco de dados
www.borland.com.br>.
relacionais da Borland, mesmo fabricante das linguagens de
programação Delphi, Borland C++ e Borland Java.
Ele é uma opção alternativa aos bancos de dados tradicionais

como o SQL Server da Microsoft e tem as vantagens de ser
grátis e código aberto, o que significa que seu código pode ser
modificado e melhorado por qualquer usuário. Dessa forma a
ferramenta se mantém em constante evolução, sem custo algum
aos seus usuários.
d) SQLite
Acesso direto em: <http://www. O aplicativo SQLite é uma biblioteca em linguagem C que
sqlite.org>.
implementa um banco de dados SQL embutido. Programas que
usam a biblioteca SQLite podem ter acesso a banco de dados
SQL sem executar um processo separado.
O SQLite é um servidor de banco de dados. A biblioteca SQLite

lê e escreve diretamente no arquivo do banco de dados.
Algumas características do SQLite:
92
Banco de Dados I
software livre/domínio público e multiplataforma;
não necessita de instalação, configuração ou

administração;
implementa a maioria do padrão SQL;
o banco de dados é guardado em um único arquivo;
suporta bases de dados acima de dois terabytes;
sem dependências externas.
e) MS SQL Server
Acesso direto em: <http://
www.microsoft.com/
O aplicativo MS SQL Server é um gerenciador de banco de sqlserver>.
dados fabricado pela Microsoft. É um banco de dados muito
robusto e usado em empresas e por grandes sistemas corporativos.
f) Oracle
O aplicativo é um sistema de banco de dados que surgiu no final Acesso direto em:
dos anos 70, quando Larry Ellison vislumbrou uma oportunidade <http://www.oracle.
com.br>.
que outras companhias não haviam percebido, quando encontrou
uma descrição de um protótipo funcional de um banco de
dados relacional e descobriu que nenhuma empresa tinha se
empenhado em comercializar essa tecnologia. Então, Ellison e os
co-fundadores da Oracle Corporation, Bob Miner e Ed Oates,
perceberam que havia um tremendo potencial de negócios no
modelo de banco de dados relacional, tornando-os assim a maior
empresa de software empresarial do mundo.
A empresa oferece seus produtos de bancos de dados, ferramentas

e aplicativos, bem como serviços relacionados de consultoria,
treinamento e suporte. A tecnologia Oracle pode ser encontrada
em quase todos os setores do mundo inteiro e nos escritórios de
98 das empresas citadas na lista da Fortune 100.
Unidade 4 93
Constitui-se atualmente de um dos softwares de banco de dados

mais confiáveis e estáveis do mercado.
f) Caché
Acesso direto em: <http:// O banco de dados Caché é considerado um banco de dados pós-
www.intersystems.com.br>. relacional. A sua arquitetura unificada de dados constrói uma
camada de descrição para objetos e tabelas relacionais e tem como
uma das características importantes, permitir uma integração
entre dois mundos: SQL (Relacional) e Objetos.
As tecnologias de desenvolvimento para a Web, como por

exemplo, Java, tendem a ser orientadas a objetos. Com isso,
muitos desenvolvedores perceberam que faz sentido aliar o
desenvolvimento com um banco de dados com orientação a
objetos. Além disso, os objetos promovem o desenvolvimento
rápido, não só pela sua modularidade, mas também por
oferecerem uma modelagem mais próxima da realidade.
Um problema dos bancos de dados que trabalham com objetos foi

a falta de uma linguagem de consulta rápida e simples, já que os
bancos relacionais possuem o SQL.
Seção 4 – A instalação de um SGBD

A ferramenta base de SGBD que será usada para estudo nesta
disciplina é a ferramenta MySQL, onde serão implementados os
modelos de dados e sob a qual serão desenvolvidos os exercícios e
exemplos práticos da disciplina.
Mas, por que utilizar o MySQL?
Veja os motivos.
94
Banco de Dados I
É uma ferramenta que possui como linguagem de acesso

a linguagem padrão SQL.
Permite portabilidade entre várias plataformas, dentre as
quais a Windows e Linux.
Possui todos os mecanismos básicos necessários a uma
ferramenta de SGBD.
É uma ferramenta amplamente de código aberto, grátis e
muito difundida atualmente no mercado de trabalho.
De instalação fácil e rápida, conforme poderá ser
observado no decorrer desta unidade.
Com muito pouco consumo de recursos dos
equipamentos computacionais, permite que seja instalada
em equipamentos não muito sofisticados.
A instalação e uso do MySQL
A partir de agora, você vai conhecer os passos para a instalação e

como usar a ferramenta de SGBD MySQL.
Em primeiro lugar, para promover a instalação do MySQL, é

preciso ter acesso ao programa instalador do banco de dados.
Crie uma pasta chamada Install na pasta C:\ do seu computador,
e baixe a versão do instalador.
A versão do instalador está
Como essas ferramentas estão em constante evolução, disponível na Midiateca
você pode encontrar versões mais recentes do banco da sala virtual desta
MySQL. Normalmente, essas versões são compatíveis disciplina.
com as anteriores, portanto, senão quiser utilizar
a versão da midiateca, você poderá baixar a mais
recente que encontrar. Vamos utilizar a versão da
midiateca por padronização.
Uma vez de posse do instalador do banco de dados, agora é hora

de realizar a instalação do produto em nosso equipamento. Então
mãos à obra e siga os passos descritos a seguir.
Unidade 4 95
Instalação do MySQL
Passos para a instalação do MySQL. Veja a descrição.
1. Localize o arquivo instalador do MySQL no seu

computador. Descompacte o arquivo, ficando, então, com
os seguintes arquivos na pasta C:\Install:
Figura 4.1 – Passo 1 para instalação do MySQL.

Fonte: Microsoft Office.
2. Execute o arquivo Instalador, dando um duplo clique
no arquivo mysql-essencial-5.1.37-win32.exe. Caso seja
mostrado um aviso de segurança na forma de uma janela
que se abrirá em seguida, clique no botão executar.
Está iniciado o processo de instalação do produto. A seguir, serão

apresentadas passo a passo as telas, bem como as informações
necessárias para que a instalação seja completada com sucesso.
1. A figura a seguir, mostra a tela de apresentação.

Simplesmente clique no botão Next.

96 Fonte: MYSQL Server 5.1.
Banco de Dados I
2. Tela de configuração do tipo de instalação. Clique no

botão Typical para realizar uma instalação padrão.

Fonte: MYSQL Server 5.1.
3. A figura a seguir apresenta a tela de início da instalação

do produto no seu equipamento. Também contém
as informações da sua instalação: tipo de instalação
selecionada, local onde será instalada a ferramenta e onde
serão instalados os arquivos do banco de dados. Clique
no botão install para iniciar a instalação e aguarde alguns
minutos.

Unidade 4 97
4. A seguir, aparecerá a tela indicando as vantagens em

se cadastrar junto ao fabricante e ferramentas para
monitorar o MySQL. Clique no botão Next.

5. A seguir, você tem a tela que indica o final da instalação
do produto.

Deixe a opção “Configure the MySQL Server now” selecionada

e clique no botão Finish.
A partir desse momento, a instalação do banco de dados está

terminada, e será automaticamente executado o programa de
configuração do banco de dados.
98
Banco de Dados I
6. A figura a seguir apresenta a tela de início da

configuração do banco de dados, clique no botão Next.
Figura 4.7 – Tela de início de configuração do banco de dados.

7. Na tela em que questiona o tipo de configuração

necessária, selecione a opção Standard Configuration e
clique no botão Next.
Figura 4.8 – Tela que apresenta o tipo de configuração desejada.

8. Selecione a opção Install as Windows Service, como

Service Name deixe a informação padrão “MySQL” e
selecione também a opção Launch the MySQL Server
automatically, para que o banco de dados sempre esteja a
sua disposição para utilizá-lo. Selecione a opção Include
Unidade 4 99
Bin Directory in Windows PATH, assim, de qualquer

lugar da linha de comando você poderá iniciar o cliente
MySQL,, clique em Next.
Figura 4.9 – Tela que apresenta o nome do serviço a ser criado no Windows.
9. Na próxima tela a ser apresentada, conforme mostra a

figura a seguir, deve ser informada uma senha na opção
New root password, a qual deve ser confirmada na opção
Confirm.
A título de sugestão e como padronização para os acessos

posteriores, sugerimos a senha “virtual” para a atual instalação.
Após digitar a senha e confirmá-la, clique em Next.
Figura 4.10 – Tela de configuração da senha de acesso.

100
Banco de Dados I
10. Tela de execução das configurações selecionadas. Clique

no botão Execute para que as configurações sejam
aplicadas ao banco de dados.
Figura 4.11 – Tela que define a execução do MySQL.

11. A figura a seguir mostra a tela indicando que as

operações de configuração foram executadas com
sucesso. Clique no botão Finish.
Figura 4.12 – Finalização da instalação.
Pronto! Está concluída a instalação do MySQL em seu

computador. Agora, a próxima etapa é conhecer os passos para
acessar o banco de dados que você acabou de instalar.
Unidade 4 101
Seção 5 – O acesso ao banco de dados MySQL

Nesta seção será realizado um acesso ao banco de dados que foi
instalado, conforme você estudou anteriormente.
O acesso ao banco de dados pode ser realizado por meio de

vários aplicativos, entretanto, para este estudo, será utilizado um
acesso considerado simples, que é instalado durante a instalação
do banco MySQL: o aplicativo MySQL Command Line Client.
Para executá-lo, vá ao menu Iniciar e abra o grupo de programas
MySQL.
Figura 4.13 – Aplicativo MySQL Command Line Client.

Execute o aplicativo MySQL Command Line Client (conforme

mostra a figura) e confirme a senha que foi informada durante a
instalação (a sugestão repassada foi a palavra “virtual”)
102
Banco de Dados I
Figura 4.14 – Solicitação de senha de acesso.

Este aplicativo é bastante simples e será utilizado sempre que

necessitar executar alguma tarefa no banco de dados. Uma nova
tela aparecerá e você estará apto a digitar os comandos para
interagir com o banco de dados.
Síntese
Nesta unidade você conheceu alguns produtos de SGBD, bem

como o mercado de software livre e de software proprietário.
No que tange ao mercado envolvendo os produtos de banco

de dados, o software livre, apesar de ainda não consolidado,
apresenta-se como uma opção interessante ao usuário que não
quer ficar na dependência de um fabricante ou proprietário do
produto. Porém, esse também deve medir os riscos de não ter
à disposição a figura do responsável direto pela confecção do
produto, que por muitas vezes pode representar alguma garantia
de continuidade no desenvolvimento e atualização do produto.
Com relação aos produtos de banco de dados, você conheceu

alguns dos mais conhecidos e utilizados atualmente, o que
proporciona uma visão dos principais atuantes no mercado atual,
sem a intenção de avaliar produtos, o que exigiria uma avaliação
profunda, inclusive com relação à área da sua aplicação.
Unidade 4 103

1) Qual a diferença entre banco de dados relacional e banco de dados

orientado a objetos?
2) Caso uma empresa lhe questionasse sobre as vantagens e

desvantagens de se ter ferramentas de uso livre, que tipo de
informação você passaria?
104
Banco de Dados I
Saiba mais
Para aprofundar as questões abordadas nesta unidade você poderá

pesquisar os seguintes livros:
GUIMARÃES, Célio Cardoso. Fundamentos de bancos de

dados. São Paulo: Editora Unicamp, 2008.
NASSU, Eugênio A.; SETZER, Valdemar W. Banco de dados

orientado a objetos. São Paulo: Edgard Blucher, 1999.
Unidade 4 105
5
unidade 5
Implementação do projeto de
banco de dados
n Conhecer a origem da linguagem SQL.
n Compreender os tipos de dados da linguagem SQL.
n Identificar os comandos de definição de dados (DDL).
n Entender a funcionalidade das chaves primárias e

estrangeiras em um banco de dados.
n Implementar os elementos de um projeto de banco de

dados numa ferramenta de SGBD.
n Saber como criar, alterar e remover tabelas de banco de

dados.
Seções de estudo
Seção 1 A estrutura da Linguagem SQL
Seção 2 Como criar tabelas
Seção 3 Como definir tabelas relacionais em SQL
Seção 4 Como remover as tabelas do banco de

dados

A linguagem SQL (Structured Query Language) surgiu no início
dos anos 70 como resultado de um projeto da IBM para o
desenvolvimento de uma linguagem que se adequasse ao modelo
relacional. O primeiro sistema de banco de dados baseado em
SQL ficou disponível, comercialmente, no final dos anos 70,
junto a outros sistemas de banco de dados relacionais.
Por volta da década de 80 foi publicada a primeira versão

padronizada da Linguagem SQL, seguindo a padronização
ANSI e ISO.
Desde então, a linguagem vem evoluindo, gerando novas versões

padronizadas, como: SQL-92 e SQL-99, assim chamadas em
referência aos anos em que foram publicadas.
Com suas seguidas evoluções, a linguagem tornou-se a mais

poderosa ferramenta de definição e manipulação de bancos
de dados relacionais, e é hoje utilizada na grande maioria dos
sistemas de bancos de dados.
A linguagem SQL é basicamente uma linguagem de definição

e manipulação do banco de dados, diferente das linguagens
comuns de programação, por não ser uma linguagem procedural.
procedural. É uma linguagem relacional, isto é, ela é ideal para
o tratamento de dados relacionados, aqueles que podem ser
Linguagem procedural é aquela na
qual os comandos são agrupados
arranjados em uma tabela, na qual cada linha forma uma unidade
em procedimentos ou funções. lógica de dados.
Essa linguagem funciona tanto para definição como manipulação

de dados, isto é, usando SQL pode-se criar tabelas e também
acessar os dados ali cadastrados.
Sendo assim, nesta unidade, vamos fazer parte deste seleto grupo
de programadores que usam a linguagem SQL para manipulação
e definição de dados. Bom estudo!
112
Banco de Dados I
Seção 1 – A estrutura da linguagem SQL

A linguagem de programação SQL é formada por um grupo
muito grande de comandos que podem ser executados para os
mais diversos objetivos.
Para facilitar o entendimento e o uso dessa poderosa

linguagem de banco de dados, os comandos são
divididos em linguagem de definição de dados (DDL)
e linguagem de manipulação de dados (DML).
a) Linguagem de definição de dados (data definition

language – DDL): fornece comandos para criação e
modificação das tabelas do modelo de banco de dados,
bem como a remoção de tabelas e criação de índices.
Os principais comandos que fazem parte da DDL são:
Create table, Drop table, Alter table.
b) Linguagem de manipulação de dados (data

manipulation language – DML): inclui uma linguagem
de consulta aos dados das tabelas. Compreende os
comandos para inserir, remover e modificar informações
em um banco de dados. Os comandos básicos da DML
são: Select, Insert, Update, Delete.
Os comandos da linguagem de definição de dados (DDL)

O principal objetivo dos comandos da linguagem de definição de
dados (DDL) é possibilitar ao usuário criar as tabelas do seu modelo
de banco de dados, bem como os relacionamentos entre elas.
Antes de iniciar o estudo dos comandos de criação de

tabelas, é importante que você fique por dentro dos
tipos de dados em um banco de dados, pois esse
item é essencial para especificação dos valores que
podem ser aceitos em cada campo, ou coluna, de uma
tabela.
Unidade 5 113
Os tipos de dados em SQL
O padrão SQL-92 aceita uma variedade de tipos de dados,

incluindo os seguintes:
Varchar (n) – é uma cadeia de caracteres de tamanho

variável, com o tamanho “n” máximo definido pelo
usuário. Por exemplo: um campo do Tipo Varchar(30)
significa que ali podem ser cadastrados, no máximo, 30
símbolos quaisquer, como número e letras. String de
tamanho flexível entre 1 e 255 caracteres.
Int ou Integer – define um tipo inteiro entre 0 e
4294967295 (sem sinal).
Numeric(p,d) – é um número de ponto fixo cuja precisão
é definida pelo usuário. O número consiste de “p” dígitos
e “d” casas decimais. Por exemplo, um campo do tipo
Numeric (9,2) tem a seguinte representação: 9999999.99,
ou seja, 7 dígitos antes da vírgula e 2 após a vírgula,
totalizando os 9.
Real - é um número com ponto flutuante, ou seja, a
representação de número real pode mudar de acordo com
a representação atual. Como por exemplo: 100.0 é igual a
10.0 E+2.
Float(n) – é um número com ponto flutuante. A precisão
é definida pelo usuário, em pelo menos “n” dígitos.
Date – representa uma data que contém um ano (com
quatro dígitos), mês e dia do mês. Por exemplo, a data
23/01/1998 será representada no MySQL como sendo
1998-01-23. O formato padrão é YYYY-MM-DD.
Char (n) – strings de tamanho fixo entre 1 e 255
caracteres.
Text, Blob – strings de tamanho indefinido. A diferença
entre TEXT e BLOB é que o primeiro armazena o texto
como caractere e o segundo como objeto binário.
Bool ou boolean – tipo boleano (true/false), em que no
valor igual a zero temos false e diferente de zero, então,
temos true.
Time – representa horário, em horas, minutos e
segundos. O formato padrão é HH:MM:SS.
114
Banco de Dados I
É importante salientar que outros tipos de dados podem existir,

dependendo da tecnologia e do grau de sofisticação da ferramenta
de SGBD.
Bem, agora que você já conhece os tipos de dados existentes

para linguagem SQL, eles serão úteis quando você for definir as
tabelas que farão parte de seu banco de dados.
Seção 2 – Como criar tabelas

Antes da criação das tabelas no banco de dados é preciso criar
uma área para receber estas tabelas. Essa área no MySQL é
chamada de database.
O database é considerado um agrupador de tabelas.

Podemos criar um database para cada modelo lógico,
ou seja, para cada conjunto de tabelas que serão
utilizadas num sistema.
Sua sintaxe é:
create database nome_do_database; <enter>
Para o modelo lógico, representado na figura 5.1, a seguir, vamos

criar o seguinte database:
mysql> create database escola; <enter>
Após criar o database, é preciso informar ao MySQL qual

database que ele deverá utilizar. Para isso, utilizamos o seguinte
comando:
mysql> use escola; <enter>
Uma vez criado um database, ao sair do MySQL e

retornar, você não precisará criar novamente, apenas
utilize o comando Use nome_database para continuar
o seu trabalho.
Unidade 5 115
Para remover um database e todas as tabelas contidas nele, utilize

a seguinte sintaxe:
mysql> drop database escola; <enter>
Para visualizar os databases existentes no banco de dados utilize:
mysql> show databases; <enter>
Observe na figura a seguir como ficaram os comandos na

ferramenta MySQL Command Line Client:
Figura 5.1 – Resultado dos comandos de criação e manipulação de database.

Fonte: MySQL Server 5.1.
Há outras variações de comandos para criação e manipulação

de database, mas por enquanto, a variação aqui apresentada é
suficiente para você continuar os estudos. Vamos, então, à criação
das tabelas.
A tarefa de criar uma tabela significa especificar seu nome, o

nome de cada coluna e o tipo de dados que será armazenado em
cada coluna.
Porém, esse processo pode ser mais amplo. A tabela é um

conjunto de dados e com isso pode-se especificar as regras de
acesso e uso, as quais recebem o nome de regras de integridade.
Uma tabela em SQL é definida usando o comando Create Table,

que possui como sintaxe:
116
Banco de Dados I
create table nome da tabela (

Atributo1 Tipo1,
Atributo2 Tipo2,
..,
AtributoN TipoN,
<regras de integridade 1>,
<regras de integridade 2>,
...,
<regras de integridade n>
);
Normalmente, um banco de dados abrange um conjunto de

tabelas. Para cada uma delas deve ser executado um comando
Create Table para sua definição.
A esse conjunto de tabelas chama-se Modelo Lógico

de Dados, que representa graficamente as tabelas do
banco de dados.
Para facilitar sua compreensão, veja o Modelo Lógico a seguir:
Figura 5.2 – Modelo relacional com as tabelas alunos, matriculas e cursos.
Os comandos a seguir descrevem os passos para implementação

deste modelo, criando cada uma das tabelas, por meio do
comando Create Table.
Inicialmente, descreva o comando para criação física no

computador da tabela Alunos:
Unidade 5 117
Create table Alunos (

Codigo_Aluno Integer,
Nome_Aluno Varchar(30),
Idade Integer,
Sexo Char
); <enter>
Após a execução do comando, as tabelas podem ser manipuladas

das mais diversas formas, como: inserção de dados, alteração de
Na execução de comandos maiores,
procure fazê-los mais divididos em dados etc.
linhas, como no exemplo. Assim, se
ocorrer um erro, o MySQL mostrará Para visualizar a estrutura da tabela criada usa-se o comando
melhor onde ele está. Describe.
Comando Describe: representa de forma estrutural os

campos da tabela e seus respectivos tipos de dados.
Subentende-se por campos, as
colunas da tabela.
O comando Describe possui a seguinte sintaxe:
Describe Nome_Da_Tabela; <enter>
Nesse caso, após a execução do comando Describe Alunos, a

seguinte estrutura será apresentada:
Campos - Field Tipo - Type Primary Key – Key Null

Codigo_Aluno Integer Sim
Nome_Aluno Varchar (30) Sim
Idade Integer Sim
Sexo Char Sim
Quadro 5.1 – Resultado da execução do comando describe alunos.

O comando Describe pode ser abreviado por Desc, ficando

assim:
Desc Nome_Da_Tabela; <enter>
118
Banco de Dados I
Observe que a tabela de alunos possui os campos Codigo_Aluno,

do tipo de dado Inteiro, Nome_Aluno do tipo Varchar, Idade do
tipo Inteiro e Sexo do tipo Char.
Essas regras, até o momento, definem apenas o escopo de cada

coluna, ou seja, nas colunas Codigo_Aluno e Idade só podem
ser cadastrados números, de no máximo 11 dígitos. Já o campo
Nome_Aluno aceita um conjunto de caracteres de tamanho
máximo 30, e, por fim, o campo Sexo, que aceita apenas um
caractere (F ou M, por exemplo).
O que significa a expressão Null?
Todas as colunas da tabela Alunos possuem como valor

para coluna null um “Sim”. Essa configuração determina ao
banco de dados que todas as colunas da tabela Alunos podem
ser cadastradas com valores nulos, ou seja, não são campos
obrigatórios.
Toda vez que criamos uma tabela, as colunas por padronização

sempre começam com o status de Null, ou seja, não obrigatórias.
Como definir para que o campo seja

“obrigatoriamente cadastrado”?
Você estudou anteriormente que toda vez que se cria as colunas

de uma tabela, por padrão, são cadastradas com Null, certo?
Para definir que o campo de uma tabela é obrigatório, deve-se

colocar a expressão Not Null na sua definição do mesmo, da
seguinte forma:
Nome da Coluna Tipo de Dado Not Null.
Vamos criar a tabela de Alunos novamente, mas desta vez

obrigando o cadastramento do código do aluno e do nome, ok?
Unidade 5 119
Observe como ficaria o comando SQL:
Create table Alunos (

Codigo_Aluno Integer not null,
Nome_Aluno Varchar(30) not null,
Idade Integer,
Sexo Char
); <enter>
A definição dos campos obrigatórios vale apenas para os campos

definidos como not null (não nulos). Caso seja necessário
especificar todos os campos como obrigatórios, deverá ser
colocada a cláusula not null ao lado de cada campo. Após a
execução desse comando, a estrutura do quadro passará a ter a
seguinte formatação:
Campos - Field Tipo - Type Primary Key – Null

Key
Codigo_Aluno Integer Sim
Idade Integer Sim
Sexo Char Sim
Quadro 5.2 – Resultado do comando describe alunos.

Outras regras de integridade dos dados

As regras de integridade são importantíssimas para que um
banco de dados evite redundância nos dados e garanta a sua
integridade.
A obrigatoriedade de informação dos dados de uma tabela é uma

regra de integridade do banco de dados, e existem muitas outras
que podem ser associadas a uma tabela, as regras de integridade
permitidas englobam:
primary key(Atributo1, Atributo2, ..., AtributoN);

check (P);
foreign key(Atributo1, Atributo2, ..., AtributoN) references Nome da Tabela.
120
Banco de Dados I
Sobre a sintaxe apresentada, considere:
A especificação Primary Key diz que os atributos

Atributo1, Atributo2, ..., AtributoN formam a chave
primária da tabela. A chave primária corresponde ao
campo, ou campos, que não pode, de forma alguma,
ter valores repetidos dentro da tabela. No caso da
chave primária ser composta por mais de uma coluna,
a combinação dessas colunas não poderá ter valores
repetidos.
A cláusula check impõe um domínio a um determinado

campo da tabela, forçando-o a aceitar apenas as opções
pertencentes ao domínio estabelecido. Por exemplo, para
a coluna Sexo pode ser estabelecido o domínio (‘M’,’F’).
Isso é implementado por meio da seguinte cláusula
check, ao se implementar uma tabela: ...check Sexo in
(‘M’,’F’)... Dessa forma, o SGBD fará uma verificação
sempre que um valor for inserido ou alterado na coluna
Sexo, a fim de averiguar se seu valor encontra-se dentro
do domínio estabelecido.
A cláusula foreing key inclui a relação dos atributos que

constituem a chave estrangeira (Atributo1, Atributo2, ...,
AtributoN) e em quais tabelas esses campos fazem
referência aos campos formadores da chave primária em
outra tabela.
Todos os atributos de uma chave primária são

declarados implicitamente como not null.
Agora que já temos a tabela Alunos criada, vamos definir um

campo do tipo chave primária para essa estrutura. Como o Nome
do Aluno, Idade e Sexo são campos que podem ter o mesmo
valor, adotarei o Código do Aluno como chave primária.
Chave Primária é aquele
campo que não pode, de
Como alterar a estrutura da tabela? forma alguma, repetir-se
dentro da tabela.
Unidade 5 121
A alteração da estrutura de uma tabela do banco de dados pode

ser realizada de duas formas: ou se acrescenta um campo novo
ou se altera a estrutura do campo desejado.
A alteração realizada se refere sempre à estrutura da tabela e

nunca aos campos cadastrados na mesma. A alteração dos dados
cadastrados é realizada por meio de outro comando.
Retomando o exemplo da nossa tabela...
Como a tabela Alunos já existe no nosso banco de dados, a tarefa

que será executada representa uma alteração na estrutura da
tabela. Será então adicionada a regra de chave primária ao campo
Codigo_Aluno.
Para isso, será necessária a utilização do comando em SQL:

Alter Table, que possui a seguinte sintaxe:
Alter Table Nome_ da_Tabela Operação Nome_ do_ Campo Nova Regra;
A operação pode ser:
Operação Funcionalidade
ADD Adiciona um novo campo.
MODIFY Altera a estrutura de um campo.
Tabela 5.3 – Formas de uso do comando Alter Table.

Ao alterar o campo Codigo_Aluno para ser uma chave primária,

sua sintaxe será:
Alter Table Alunos Add Primary Key(Codigo_Aluno);
Observe se a alteração foi realizada. Para tanto, o comando

Describe deve ser novamente executado, com a finalidade de
descrever a estrutura da tabela.
122
Banco de Dados I
Campos - Field Tipo – Type Primary Key – Null

Key
Codigo_Aluno Integer Sim Não
Idade Integer Sim
Sexo Char Sim
Quadro 5.3– Estrutura da tabela de alunos após a execução do comando describe alunos.
Importante notar que a coluna Null para o campo Codigo_

Aluno possui o valor Não, pois toda chave primária,
obrigatoriamente, deve ser cadastrada. Caso você tenha esquecido
de colocar o campo Codigo_Aluno como not null, por se tratar
de uma chave primária, ele receberia automaticamente o not null.
Antes de continuar a criar as tabelas Cursos e Matrículas que

fazem parte do modelo proposto nesta seção, realizaremos outras
alterações na tabela Alunos, para exemplificar a sintaxe do
comando Alter Table.
Como alterar o tamanho do campo Nome_Aluno?
O comando a ser utilizado será:
Alter Table Alunos MODIFY Nome_Aluno Varchar(40);
Observe que nesse exemplo, ao invés de utilizar a cláusula Add,

foi utilizada a cláusula Modify, pois o campo Nome_Aluno já
existia, porém, com outro tamanho. Por isso, o campo foi apenas
modificado.
Acompanhe outras aplicações de comandos:
Unidade 5 123
Adicionando o campo Endereco, do tipo varchar(30);
Alter Table Alunos ADD Endereco Varchar(3);
Adicionando o Campo Cidade, do tipo Varchar(25):
Alter Table Alunos ADD Cidade Varchar(25);
Adicionando o Campo UF, do tipo Varchar(02):
Alter Table Alunos ADD UF Varchar(02);
Adicionando um domínio no campo Sexo, para isso

vamos utilizar a cláusula check:
Alter Table Alunos ADD check (sexo in (“M”,”F”));
Tem-se, então, a seguinte estrutura:

Key
Codigo_Aluno Integer Sim Não
Idade Integer Sim
Sexo Char Sim
Endereço Varchar(30) Sim
Cidade Varchar(25) Sim
UF Varchar(2) Sim
Quadro 5.4 – Resultado do comando describe alunos após as alterações.

Como criar a estrutura da tabela em um Grupo Único

de Comandos?
124
Banco de Dados I
No item acima, na criação da tabela de Alunos, realizamos

vários comandos para definição da tabela. Basicamente, uma
tabela é um conjunto de campos, chaves primárias e campos
obrigatórios, sendo assim, podemos criar todas essas regras num
único passo, como será feito a seguir, na criação da tabela de
Cursos, observe:
Create Table Cursos(

Codigo_Curso Integer,
Descricao Varchar(30) not null,
Numero_Vagas Integer not null,
Periodo Char,
Primary Key(Codigo_Curso)
);
Executando o comando Describe para visualizar a estrutura da

tabela, tem-se:

Key
Codigo_Curso Integer Sim Não
Descricao Varchar (30) Não
Numero_Vagas Integer Não
Periodo Char Sim
Quadro 5.5 - Visualizando a estrutura da tabela Cursos.

Como característica desta tabela, observe que os campos

Codigo_Curso, Descricao e Numero_Vagas são obrigatórios, e
o campo Codigo_Curso ainda é uma chave primária. O único
campo que pode ser cadastrado sem valores é o campo Período.
Unidade 5 125
Seção 3 – Como definir tabelas relacionadas em SQL

Até aqui você criou um conjunto de tabelas que não estavam
relacionadas e cuja principal finalidade era cadastrar diretamente
os dados.
Figura 5.3 – Modelo relacional com as tabelas alunos, matriculas e cursos.

Porém, no modelo de dados do início desta unidade, foi

apresentada uma tabela associativa chamada Matriculas, que
deverá conter o Aluno que fez a matrícula, o Curso no qual ele se
matriculou e a data em que efetuou isso.
Note que com essa tabela associativa, não há necessidade de

recadastrar os dados do aluno e do curso, mas sim, fazer uma
referência das tabelas Alunos e Cursos na tabela Matriculas.
A referência entre tabelas chama-se de chave

estrangeira.
A tabela Matrícula terá duas chaves estrangeiras, os campos

cod_alu_mat e cod_curso_mat, que referenciam a tabela
Alunos pelo campo Codigo_Aluno e a tabela Cursos pelo campo
Codigo_Curso, respectivamente.
Em outras palavras, pode-se dizer que o código identificador do
aluno matriculado na tabela Matriculas, que estará armazenado
no campo cod_alu_mat, deverá vir da tabela de Alunos,
originário do campo Codigo_Aluno. Já o Código do curso, na
126
Banco de Dados I
tabela Matriculas, que será armazenado no campo cod_curso_

mat, deverá vir da tabela Cursos, pelo campo Codigo_Curso.

Figura 5.4 – Origem dos valores das colunas COD_ALU_MAT E COD_CURSO_MAT

Essas referências possuem a seguinte regra e são feitas na

seguinte sintaxe:
Para o campo cod_alu_mat, da tabela de Matriculas, que

os dados vêm da tabela de Alunos, pelo campo Codigo_
Aluno, o comando em SQL é:
Foreign Key (cod_alu_mat) references Alunos (Codigo_Aluno);
Para o campo cod_curso_mat, da tabela de Matriculas,

que os dados vêm da tabela de Cursos, pelo campo
Codigo_Curso, o comando em SQL é:
Foreign Key (cod_curso_mat) references Cursos (Codigo_Curso);
Como definir os tipos de dados das chaves

estrangeiras?
O que é e como referenciar uma chave estrangeira você aprendeu

no item anterior, porém, qual o tipo de dados de um campo cujos
seus dados vêm de outra tabela?
Unidade 5 127
Como o campo cod_alu_mat da tabela de Matriculas vem do

campo Codigo_Aluno em Alunos, os dois campos devem ter o
mesmo tipo, sendo assim, o campo cod_alu_mat será do tipo: Int
ou Integer (inteiro).
A mesma regra deve ser aplicada ao campo cod_curso_mat.

Como o campo Codigo_Curso na tabela de Cursos é Integer,
o campo cod_curso_mat deverá ser inteiro (Int ou Integer)
também.
Como o campo Data_Matricula não é um campo chave

estrangeira, ele será do tipo Date.
Como um aluno não pode se matricular no mesmo

curso, na mesma data, todos os campos da tabela
Matriculas serão chaves primárias.
Dessa forma, a tabela Matrículas seria criada pelo comando SQL

a seguir:
Create table Matriculas (

Cod_Alu_Mat Integer,
Cod_Curso_Mat Integer,
Data_Matricula Date,
Primary Key (Cod_Alu_Mat, Cod_Curso_Mat, Data_Matricula),
Foreign Key (Cod_Alu_Mat) references Alunos (Codigo_Aluno),
Foreign Key (Cod_Curso_Mat) references Cursos (Codigo_Curso)
);
A representação da tabela Matrículas a partir do comando

Describe::
Campos - Field Tipo - Type Primary Key Null

– Key
Cod_Alu_Mat Integer Sim Não
Cod_Curso_Mat Integer Sim Não
Data_Matricula Date Sim Não
Quadro 5.6 - Representação da tabela Matriculas a partir do comando Describe.

128
Banco de Dados I
Note que todos os campos são marcados com Primary Key igual
a SIM, em uma referência à chave primária.
Após criar uma tabela, se você quiser verificar o

comando que a originou, utilize a sintaxe:
mysql> show create table nome_da_tabela; <enter>
Bem, com isso você finalizou o processo de transformar o modelo

lógico do início desta unidade num modelo físico, ou seja, você
transformou um modelo lógico num banco de dados de verdade.
Seção 4 – Como remover as tabelas do banco de dados

Assim como você pode criar novas tabelas para um banco de
dados, poderá também removê-las por meio do comando Drop
Table.
Sua sintaxe é:
Drop Table Nome_da_tabela; <enter>
Porém, algumas regras devem ser respeitadas para que uma

tabela seja removida, ou “dropada”, no jargão de banco de dados.
Essas regras são:
uma tabela só pode ser removida se ela não possuir

campos considerados como sendo chave estrangeira para
outra tabela;
se uma tabela possui como referência uma chave

estrangeira para outra tabela, será preciso primeiro
remover as tabelas para as quais são feitas as referências;
uma tabela só pode ser removida se não possuir nenhum

dado cadastrado, caso contrário, primeiro ela deverá ser
esvaziada para depois ser removida.
Unidade 5 129
Para remover a tabela Alunos do banco de dados criado

anteriormente, utilize o comando Drop Table, com a seguinte
sintaxe:
Drop Table Alunos
Porém, ao se excluir a tabela de Alunos, será criada uma

inconsistência no esquema do banco de dados, pois a tabela
Matriculas estará fazendo referência a uma tabela que não existe
mais, dessa forma os dados não refletem a realidade esperada.
Para que esse problema não ocorra, o SGDB não permitirá que
a tabela Alunos seja removida, pois há alguma outra no esquema
que depende dela.
Veja o diagrama a seguir:

Figura 5.5 – Representação da remoção de uma tabela com campos que são foreign key para outra
tabela.
Para se excluir a tabela de Alunos, é necessário que se

exclua antes a tabela de Matriculas, para que a ligação
entre as mesmas não exista mais.
Note que o processo de exclusão de tabelas pode resultar em
130
Banco de Dados I
problemas graves de inconsistência de dados, gerando uma

necessidade de exclusão de várias tabelas do banco de dados
devido ao número de relacionamento entre elas.
Portanto, é fundamental que ao se modelar um banco de dados
sejam previstos todos os relacionamentos possíveis e as tabelas
que são realmente necessárias, a fim de se evitar o trabalho
redobrado.
Nesse casso, para excluir a tabela Alunos é necessário dois

comandos Drop Table, com as seguintes sintaxes:
Drop Table Matriculas;

Figura 5.6 – Remoção da tabela Matricula

Drop Table Alunos;

Figura 5.7 – Tabelas restantes após as remoções.

Após esses dois comandos, o modelo de banco de dados ficará

assim:

Figura 5.8 – Tabelas restantes após as remoções.

O próximo passo é compreender os comandos que permitam

manipular os dados desse banco de dados, fazendo inserções,
Unidade 5 131
alterações, exclusões e consultas nas tabelas, os chamados

comandos de DML (Linguagem de Manipulação de Dados).
Síntese
A programação em banco de dados utiliza uma linguagem de

programação própria, chamada de linguagem estruturada de
pesquisa, ou simplesmente SQL. A linguagem SQL segue um
padrão para qualquer ferramenta de banco de dados, sendo assim,
ela é independente do ambiente no qual será utilizada.
A linguagem SQL é dividida basicamente em duas formas, os

comandos de Definição de Dados (DDL) e os de Manipulação
de Dados (DML).
Dentro do conjunto dos comandos de DDL estão: Create Table,

Alter Table e Drop Table. O comando Create Table permite ao
programador a criação das tabelas do modelo físico, definindo a
descrição de cada coluna e o seu tipo de dado.
As restrições da tabela são chamadas de constraints e podem

ser de dois tipos, basicamente: chaves primárias e chaves
estrangeiras. As chaves primárias são sempre do tipo not null,
ou seja, seus dados devem ser preenchidos obrigatoriamente. Os
campos do tipo Null têm seu preenchimento opcional.
Qualquer alteração na estrutura da tabela é realizada pelo

comando Alter Table, e possui duas formas de uso, ADD
quando se deseja incluir um novo campo na tabela e Modify
quando se deseja alterar um campo já existente.
Para se remover uma tabela do banco de dados, existe o comando

Drop Table.
Para que uma tabela seja removida, ela não pode ter dados
cadastrados e nem ser uma tabela estrangeira para outra tabela.
Para visualizar a estrutura de uma tabela do banco de dados

utiliza-se o comando Describe, seguido do nome da tabela. Esse
comando mostra na tela os nomes das colunas da tabela e o tipo
132
Banco de Dados I
de cada uma dessas colunas. Pode-se abreviar o comando usando

simplesmente Desc.
Nesta atividade você revisará os comandos de definição de dados por
meio da criação de um banco de dados físico, a partir de um modelo
conceitual.
Com base no modelo de dados a seguir, escreva os comandos em SQL que
realizam cada uma das tarefas solicitadas.
LEGENDA
Símbolo Significado
PK Chave Primária
NN Not Null
Chave Primária e
PFK
Chave Estrangeira
FK Chave Estrangeira
1. Comando em SQL para a criação da tabela Tipo_Produto.
Unidade 5 133
2. Comando em SQL para criação da tabela Produtos.
3. Comando em SQL para criação da tabela Nota_Fiscal.
4. Altere o campo Descricao_Produto da tabela Produtos para o tipo

Varchar(50).
5. Altere a tabela Nota_Fiscal, adicionando o campo ICMS do tipo Float.
134
Banco de Dados I
6. Altere a tabela Produtos, adicionando o campo Peso do tipo Float.
7. Altere a tabela Produtos, adicionando o campo Data_Validade do tipo

Date.
8. Escreva o comando em SQL, que apresenta a estrutura da tabela

Produtos.
9. Escreva o comando em SQL que apresenta a estrutura da tabela Nota_

Fiscal.
Unidade 5 135
10. Remova a tabela Itens do modelo de banco de dados.
Saiba mais

poderá pesquisar os seguintes livros:
HERNANDEZ, M. J. Aprenda a projetar seu próprio banco

de dados. São Paulo: Pearson Education do Brasil Ltda., 1999.
JESUS, João Batista de. ANSI: SQL 89/92. São Paulo: Axcel
Books do Brasil Ltda., 2004.
SETZER, V. W.; SILVA, F. S. da. Banco de dados. São Paulo:

Edgard Blucher, 2005.
SOARES, Walace. MySQL: conceitos e aplicações. São Paulo:

Erica, 2003.
No que se refere aos tipos de tabelas, leia o recorte do artigo

de Eber Duarte, o qual aborda esse assunto de forma bem
esclarecedora.
136
Banco de Dados I
Tipos de tabelas para o MySQL

O MySQL possui uma característica um pouco diferente dos outros sistemas
gerenciadores de banco de dados, uma vez que no MySQL é possível escolher
o tipo da tabela no momento de sua criação. O formato de armazenamento
dos dados e alguns recursos do banco de dados são dependentes do tipo de
tabela escolhido.
1. MyISAM: As tabelas MyISAM são armazenadas em 3 arquivos: .FRM, que
armazena a definição da tabela, o arquivo .MYD que contém os dados e o
.MYI, contendo os índices. Estas tabelas são de grande importância para a
leitura, uma vez que os seus índices são armazenados em árvores binárias
balanceadas, o que provê um ganho para o acesso às informações. O
MyISAM não provê controle de transações (commit ou rollback) e também
não possui integridade referencial, isto é, ao incluir uma chave estrangeira
com alguns constraints, essa servirá apenas como documentação, mas as
restrições não serão respeitadas pelo banco.
2. HEAP: Tabelas HEAP são armazenadas em memória, por isso são
extremamente rápidas, por outro lado, o seu conteúdo é volátil, uma vez
que não são gravadas em disco. Caso haja uma queda do SGBD, os dados
dessas tabelas serão perdidos. Além disso, é necessário um processo
para dar a carga inicial nos dados quando o servidor de banco iniciar e
sua execução. A principal aplicação das tabelas HEAP seria para tabelas
que são consultadas com muita frequência, mas que não sofrem muitas
alterações (lookup tables).
3. MERGE: As tabelas MERGE são coleções de tabelas MyISAM idênticas. Esse
recurso permite a divisão de uma tabela grande em várias partes menores,
ainda assim permite acesso ao conteúdo de todas elas, como se fossem
uma única tabela.
4. BDB: O tipo de tabela BDB vem de BerkeleyDB, e é desenvolvido
pela Sleepycat (http://www.sleepycat.com). O BDB provê ao MySQL
um manipulador de tabelas com controle de transação, isto é, você
poderá utilizar os comandos COMMIT e ROLLBACK, além de fornecer a
recuperação automática de dados, em caso de queda do sistema. O BDB
apresenta um mecanismo de lock em nível de página, onde apenas os
dados de uma mesma página ficarão bloqueados durante um período de
lock. Além disso, você poderá ter vários locks ativos numa única tabela
BDB, uma vez que a tabela poderá ser constituída de várias páginas.
5. InnoDB: O tipo de tabela padrão para o MySQL 5.1 que estamos utilizando
é o InnoDB. Ao utilizar o comando show create table nome_da_tabela,
você poderá perceber, no final do comando, que o MySQL colocou
automaticamente o tipo de tabela que foi utilizada para criação.
InnoDB funciona mais rápido que MyISAM, quando há mo
dificações constantes nos dados, uma vez que esse tipo de armazenagem usa
Unidade 5 137
a proteção por registros (row locking) e não por tabelas (table locking), como o
faz o MyISAM. Contudo, em várias situações, innoDB é mais lento que MyISAM,
devido ao fato de que innoDB funciona com transações.
Outro ponto interessante são as restrições de chaves estrangeiras (foreign key
constraints) e transações. Esses recursos estão disponíveis apenas no InnoDB.
MyISAM é apropriado para tabelas cujos dados não mudam com frequência. Um
exemplo disso é uma tabela de cidades e estados. Como geralmente este tipo de
tabela é usado apenas como consulta, não há necessidade do uso de InnoDB.
MyISAM tem a vantagem de ser um arquivo simples, se comparado com o
innodb. Mesmo na opção para criar dentro do contexto, o arquivo fica instável
em volumes grandes, perfomace de cache é sempre importante.
O MyISAM foi implementado a partir do código da tabela ISAM., introduzindo
diversas melhorias, como:
os arquivos de tabela são transportáveis entre diferentes sistemas
operacionais;
campos BLOB e TEXT podem ser indexados;
os Arquivos índices e de dados podem ser armazenados em dispositivos
diferentes (aumento de performance);
algoritmos de distribuição de dados e gerenciamento de índices
melhorados.
Com relação ao InnoDB, pode-se afirmar que:
rodam sob um engine, desenvolvido pelo Innobase, que acrescenta ao
mysql o suporte a transações e a constraints de chave estrangeira;
para obter o máximo de performance com tabelas innoDB, é necessário
configurar o arquivo my.conf (ou my.ini no Windows), de acordo com as
características de hardware do servidor onde o mysql está rodando. Os
Detalhes dessa configuração podem ser obtidos no manual do InnoDB.
• para a versão do MySQL, que estamos utilizando esta configuração, já
vem na instalação padrão.
A vantagem da utilização de tipos de tabela é que você poderá optar por utilizar
um determinado tipo ou outro, dependendo dos requisitos exigidos pela sua
aplicação. Por exemplo, se a sua aplicação é apenas de consulta, você pode
optar pelo tipo MyISAM, em vez do InnoDB, com isso você evita o overhead da
transação, obtendo um maior desempenho. É importante lembrar que você
poderá utilizar vários tipos de tabelas em um mesmo banco de dados. Nesse caso,
deve-se tomar cuidado com a utilização de determinados recursos, por exemplo,
se você tiver uma transação envolvendo tabelas InnoDB e MyISAM e submeter um
comando ROLLBACK, apenas os comandos executados no InnoDB serão desfeitos,
enquanto que os executados no MyISAM persistirão. A utilização do tipo de tabela
correto é um fator chave para determinar o desempenho da sua aplicação.
Fonte: Adaptado de: DUARTE, Eber M. Trabalhando com os vários tipos de tabelas do MySQL. Publicado em: 08
nov 2006. Disponível em: <http://www.criarweb.com/artigos/674.php>. Acesso em: 28 fev 2011.
138
6
unidade 6
Ferramentas case para apoio ao

projeto de banco de dados
n Compreender a importância das ferramentas Case.
n Identificar as vantagens no uso de uma ferramenta Case

como apoio à modelagem de dados.
n Conhecer algumas ferramentas Case para modelagem

de dados.
Seções de estudo
Seção 1 Ferramentas Case
Seção 2 Ferramenta Case Studio – Toad Data Modeler

Seção 1 Ferramenta MySQL Workbench
Seção 2 Ferramenta ERWin

Um SGBD é uma ferramenta relativamente complexa, onde
existem uma série de mecanismos implementados, bem como
algumas regras a serem seguidas para a sua utilização, todas
visando a preservar e manter os dados de maneira íntegra.
O projeto de um banco de dados demanda muito mais esforço

do que a sua implementação ou implantação. Isso se deve ao
fato de que se, ao ser projetado o banco de dados, for omitido
ou registrado de forma equivocada alguma informação, esse não
contemplará adequadamente as necessidades do ambiente de
negócio que estiver sendo informatizado, refletindo diretamente
em problemas na sua utilização.
Para que um projeto de banco de dados seja bem sucedido é

imprescindível que se construa um modelo de dados, ou seja, que
sejam expostos os elementos que fazem parte do banco de dados.
Um modelo de dados relacional é composto, principalmente,

pelas tabelas que compõem este banco de dados e seus
relacionamentos, e indicam como as informações se comportam
e como estão inter-relacionadas. Para se construir um modelo de
dados com poucos elementos, devidamente documentado, não é
tarefa das mais desafiadoras.
Você já se imaginou projetando um banco de dados e tendo que

construir um modelo de dados com centenas de tabelas e outras
centenas de relacionamentos, tudo manualmente? Parece ser um
pouco mais complicado, não é mesmo? Ainda mais se pensarmos
na manutenção desse modelo durante o seu tempo de vida.
Para que esses modelos possam ser mais facilmente construídos

e mantidos, entram em cena as ferramentas Case, ferramentas
que possuem funcionalidades específicas para a construção de
modelos de dados, e é o que será apresentado nesta unidade.
Bons estudos!
136
Banco de Dados I
Seção 1 – Ferramentas Case

As ferramentas Case (Computer Aided Software Engineering) estão
para a Engenharia de Software assim como o CAD (Computer
Aided Design) está para a Engenharia Civil.
Ambas as ferramentas são programas que auxiliam o analista

na construção do sistema, prevendo, ainda na etapa de
estudos, como será sua estrutura, quais serão suas entidades e
relacionamentos. Para tanto, são elaborados vários diagramas que
em conjunto constituem praticamente uma “planta” do sistema a
ser desenvolvido.
Cabe ressaltar que as ferramentas Case disponíveis no mercado

têm abrangências distintas, implicando no seu grau de utilização
e envolvimento durante um projeto de um sistema informatizado.
Algumas dessas ferramentas limitam-se ao auxílio no projeto
do banco de dados, gerando apenas uma visualização gráfica do
seu projeto, outras possibilitam também a geração do código
para a implementação do banco de dados, outras são ainda mais
abrangentes e complexas, possibilitando também o projeto do
software (telas, relatórios...), gerando, inclusive, o código de
implementação em alguma linguagem de programação.
As ferramentas Case também se distinguem pelo nível de

modelagem e documentação que proporcionam. Algumas
delas se limitam ao projeto nível lógico, em que são definidas
as tabelas, suas colunas e seus relacionamentos. Outras já são
mais abrangentes, permitindo uma modelagem inicial em
termos conceituais, dando uma visão de negócio ao modelo de
dados, uma vez que o modelo lógico é bastante técnico. Essa
posição auxilia na definição dos elementos do modelo junto ao
usuário final, que geralmente não é um especialista na área de
informática.
Encontramos ainda no mercado ferramentas que proporcionam

desde uma visão da modelagem de processos, em que são
mapeados os processos de negócio do ambiente que se está
informatizando, até a implementação do banco de dados. Isso
permite um maior controle na obtenção das informações de
quais elementos estão envolvidos no ambiente a informatizar,
Unidade 6 137
reduzindo a possibilidade de erros no mapeamento do mundo real

para o modelo de dados, aumentando, porém, a complexidade da
ferramenta e o volume de trabalho a ser realizado.
Outra característica importante nesse tipo de ferramenta é a

possibilidade de se executar o que denominamos “engenharia
reversa”. Apesar do nome imponente, essa atividade se resume a
realizar o processo inverso da criação de um banco de dados, ou
seja, ao invés de criá-lo a partir do modelo de dados, é criado o
modelo de dados a partir de um banco de dados já existente. Isso
se torna interessante quando encontramos uma determinada base
de dados já em operação, que necessita de manutenção, porém,
não existe um modelo de dados documentado sobre aquela base.
Nesse caso, primeiro é realizada a engenharia reserva, na qual
a ferramenta Case pesquisa, na base de dados, quais tabelas
existem e traça um mapeamento desses elementos, construindo
um modelo de dados em termos lógico, identificando cada tabela,
suas colunas, chaves primárias e estrangeiras. A partir desse
modelo de dados, podemos ter uma visão completa do banco de
dados que está sendo implementado, assim se pode trabalhar com
mais precisão nas alterações a serem realizadas.
As ferramentas Case suportam notações advindas da Técnica

Estruturada – Análise Estruturada, surgida no final da década
de 70 com Tom De Marco. Em seguida atualizadas com Chris
A técnica estruturada
se fundamenta em três
Gane, Trish Sarson e Edward Yourdon.
modelos: o Modelo de
Entidade Relacional, o Existem inúmeras ferramentas Case disponíveis no
Diagrama de Fluxo de mercado. Entre elas podemos citar: Rational Rose,
Dados e o Dicionário de ERwin, Oracle Designer, Genexus, Clarifu, Dr. Case,
Dados. Para saber mais, Paradigm, PowerDesigner, Arena, Visio, DB Designer,
pesquise a bibliografia: MySQL Workbench, Case Studio (que agora é Toad
GANE, Sarso. Análise Data Modeler etc.
estruturada. São
Paulo: LTC, 1996.
Podemos perceber que no mercado existem ferramentas com
diversos níveis de abrangência para o mapeamento dos dados,
bem como diversos níveis de detalhamento de um modelo de
dados. Para o estudo desta unidade, serão demonstradas três
delas: Case Studio (Toad Data Modeler), MySQL Workbench e
Erwin. A intenção é fornecer as características de cada uma para
que no futuro você possa optar pelo software mais adequado ao
138
Banco de Dados I
seu perfil. Desse ponto de vista, o estudo é mais uma análise do

que uma avaliação criteriosa.
Para a avaliação, foram escolhidos alguns pré-requisitos, que são:
Pré-requisito Avaliação
Quais os diagramas que a ferramenta gera e qual o nível de

Diagramas inteligência de cada um desses diagramas.
Qual o nível de geração de scripts e quais os bancos de dados

Scripts de banco de dados compatíveis.
Recursos extras Recursos que a ferramenta disponibiliza.
Documentação Quais os documentos gerados.
Quadro 6.1 – Pré-requisitos.

A seguir, você vai conhecer algumas telas dessas ferramentas.
Seção 2 – Ferramenta Case Studio - Toad Data Modeler

Essa ferramenta computacional desenvolvida por Charonware,
uma empresa da República Tcheca, possui como característica Na Midiateca da sala
principal o suporte a várias versões de banco de dados, como: virtual da disciplina, está
MySQL, PostGreSQL, FireBird, Oracle etc. disponível o instalador
desta ferramenta Case.
Outra alternativa para
instalar é acessar o site da
O Case Studio teve seu nome alterado recentemente
empresa Quest Software,
para Toad Data Modeler. Isso porque a empresa Quest
a qual disponibiliza uma
Software comprou a empresa Charonware. versão freeware.
O fato positivo destaca-se por ser uma ferramenta bastante

simples para ser utilizada, exigindo muito pouco recurso do
equipamento para a sua operação. O fato negativo, porém, fica
por conta da ferramenta não possuir uma versão em português.
Entre os principais recursos do Toad Data Modeler, temos:
Unidade 6 139
implementação dos principais relacionamentos de forma

automática;
controle de usuário e segurança, tornando possível o
controle das operações disponíveis em uma determinada
entidade.
A seguir, a tela inicial da ferramenta Toad Data Modeler:
Figura 6.1 - Tela inicial da ferramenta Toad Data Modeler

Fonte: Quest Software.
O Toad Data Modeler utiliza somente a Análise Estruturada

(AE), por meio dos diagramas de MER (Modelo de Entidade
Relacional) e o DFD (Diagrama de Fluxo de Dados), de forma
O Modelo de Entidade
Relacional representa as tabelas
interativa e visual.
e o relacionamento entre elas.
Veja, a seguir, uma imagem do ambiente Toad Data Modeler:
O Diagrama de Fluxo de
Dados representa os processos
que podem ser executados em
cada tabela.
Figura 6.2 - Iniciando no Toad Data Modeler

Fonte: Adaptado de Toad Data Modeler.
140
Banco de Dados I
Ao clicar no botão New Model, conforme seta na figura acima

será solicitada, para qual ferramenta de banco de dados deve ser
gerado o esquema das entidades. No caso da nossa disciplina, o
MySQL 5.1.
A definição da estrutura das entidades é realizada de forma

rápida e fácil.
Na interface de definição da entidade, o usuário

informa o nome da entidade, os nomes das colunas e
os seus respectivos tipos.
Veja na figura a seguir a definição da entidade Alunos:
Figura 6.3 - Interface de definição dos campos da tabela Alunos.

Fonte: Adaptado de MySQL Toad Data Modeler.
A representação gráfica da entidade Alunos apresenta o nome da

entidade, seus atributos e a sua chave primária. Observe a seguir:
Figura 6.4 - Representação da chave primária da tabela Alunos no Toad Data Modeler.
Unidade 6 141
Com relação à cardinalidade, a ferramenta só permitir a

cardinalidade N para N, que se transforma em uma entidade
associativa.
Figura 6.5 - Tipos de relacionamento do Toad Data Modeler.

Fonte: Adaptado de MySQL Toad Data Modeler.
Na figura a seguir, tem-se o nosso modelo criado na ferramenta

Toad Data Modeler.
Figura 6.6 - Representação do modelo na ferramenta Toad Data Modeler.

Fonte: MySQL Toad Data Modeler.
A criação das entidades e seus relacionamentos não

significa que o banco de dados tenha sido criado
fisicamente. O que se tem na tela é uma representação
que poderia ser desenhada em papel ou em qualquer
outro acessório de documentação, assim como temos
a planta de uma casa, de um prédio, feita por um
engenheiro civil.
A transferência das regras representadas no diagrama para um

banco de dados real é realizada pelos scripts de banco de dados,
que são, na verdade, os comandos de programação para esse
banco, sem a sintaxe do banco de dados escolhido.
142
Banco de Dados I
No caso do Toad Data Modeler, a ferramenta permite:
a criação de tabelas;
a definição dos nomes de campos e seus respectivos tipos;
a definição das chaves primárias e estrangeiras.
A seguir, tem-se a geração do script para criação das tabelas
Alunos, Cursos e Matriculas, representadas graficamente nas
figuras anteriores.
3
Figura 6.7 - Script SQL gerado pelo Toad Data Modeler.
Fonte: MySQL Toad Data Modeler.
Uma das grandes vantagens de se utilizar uma ferramenta Case

é a produtividade. Observe que através do diagrama é possível
gerar todos os comandos necessários para a criação do modelo no
banco de dados, num clicar de botão.
Unidade 6 143
Seção 3 – Ferramenta MySQL Workbench

O MySQL Workbench é uma ferramenta visual para design,
desenvolvimento e administração de base de dados MySQL .
Essa ferramenta é originária do DBDesigner .
Foi criada na Suécia por David Axmark, Allan Larsson e

Michael Monty Widenius na década de 1980. Em 2008, no Foi
incorporado aos produtos da Sun Microsystems, com a aquisição
por esta da MySQL AB, desenvolvedora do MySQL. E assim
como o banco de dados MySQL, a atual empresa é a Oracle.
Para acessar o instalador desta ferramenta Case, você

poderá utilizar o que disponibilizamos na Midiateca
do EVA. Você pode encontrar a última versão no
site específico do MySQL. Mas lembre-se, só inicie a
instalação, após ter o MySQL Server 5.1, ou superior,
instalado no seu computador.
Assim, como o MySQL, essa ferramenta é livre, suporta

praticamente qualquer plataforma, compatível com diversas
linguagens de programação, inclusive o Java, tem bom
desempenho e estabilidade, exige poucos recursos de hardware e
é de fácil utilização.
Principais características:
representação visual de tabelas, views, stored procedure /

funções e chaves estrangeiras;
engenharia reversa;
banco de dados de sincronização / modelo;
geração de scripts SQL;
arquitetura expansível;
exportação como SQL script CREATE;
possui suporte para MySQL 5 ou superior.
Veja, a seguir, a tela de abertura da ferramenta MySQL
Workbench:
144
Banco de Dados I
Figura 6.8 - Tela inicial da ferramenta MySQL Workbench.

Fonte: MySQL Workbench.
Ao começar a utilizar a ferramenta, temos a opção de utilizá-

la para acesso ao banco de dados – SQL Development
(configuração de conexão, execução de scripts etc.), Data
Modeling e Server Administration, para administração do banco
de dados.
Figura 6.9 - Tela de seleção de qual ferramenta utilizar no MySQL Workbench.

Selecionando a opção Create New EER Model, iniciamos

a criação do modelo. Como exemplo, utilizaremos o mesmo
modelo com as tabelas Alunos, Cursos e Matriculas.
A definição da estrutura das tabelas que compõem o esquema

de banco de dados é realizada por meio de uma interface
Unidade 6 145
muito amigável, na qual o usuário vai interagindo direto com

a propriedade da tabela a ser criada. Veja, na figura a seguir,
a representação da estrutura da tabela Alunos, modelada pelo
MySQL Workbench.
2 Dê um duplo clique
na entidade, para inserir
os atributos
1
Figura 6.10 - Interface de definição dos campos da tabela Alunos no MySQL Workbench.
Com relação à cardinalidade (relacionamentos), a ferramenta

trabalha com as opções da figura abaixo. Basta clicar no botão,
depois na entidade de origem e, em seguida, na de destino.
Pronto o MySQL Workbench, criará o relacionamento
automaticamente.
Figura 6.11 - Tipos de relacionamentos do MySQL Workbench.

146 Fonte: MySQL Workbench.
Banco de Dados I
O diagrama pode ser transformado em um banco de dados físico,

por meio da geração do script de banco de dados. A geração
de scripts no MySQL Workbench possui os recursos mais
comuns e esperados nessa operação, como scripts de tabelas,
chaves primárias, chaves estrangeiras, nomes das colunas e seus
respectivos tipos de dados.
Veja o script gerado pelo MySQL Workbench para criação do

modelo com as tabelas Alunos, Cursos e Matriculas:
Para gerar o script, utilize o
menu File, opção Export.
Figura 6.12 - Script SQL gerado no MySQL Workbench

Seção 4 – Ferramenta ERWin

Esta ferramenta Case ficou por muito tempo conhecida como
ERwin/ERX, uma ferramenta leve e de fácil utilização. Porém,
em 1998 a desenvolvedora do ERwin, a Logic Works, foi
comprada pela Platinum. Na época, era disponibilizada a versão
2.5, que foi transformada na versão Platinum ERwin ERX
3.52. Versão essa que existiu até 1999, quando a CA (Computer
Associates) adquiriu a Platinum.
Quando a CA adquiriu o ERwin, incluiu o software em um

pacote de ALM (Application Lyfe Cycle Management), chamado
AllFusion. O ERwin passou a se chamar AllFusion ERwin Data
Modeler. Com isso, ganhou uma interface mais arrojada e alguns
recursos muito interessantes.
Unidade 6 147
Como as outras duas ferramentas anteriores, o ERwin segue o

paradigma de modelagem voltada à entidade-relacionamento,
com visões lógica e física do modelo. O diagrama é feito com
recursos de arrastar e soltar, com todas as validações de chaves
estrangeiras e primárias.
Veja a seguir a interface de integração do usuário com o modelo a

ser criado:
Figura 6.13 - Interface geral do Erwin.

Fonte: MySQL ERWin.
A ferramenta suporta uma grande quantidade de

bancos de dados, como: DB2, Oracle, Ingres, SQL
Server, Sybase, PROGRESS, Clipper, dBaseIII, dBaseIV,
Access, FoxPro, Paradox.
A ferramenta ERwin disponibiliza uma série de recursos muito

interessantes como:
complete compare: uma ferramenta que simplesmente

compara a estrutura de banco de dados com o MER,
apontando as diferenças existentes;
o comando de impressão do DER disponibiliza o
redimensionamento da escala do diagrama, permitindo
controlar e prever em quantas páginas será impresso o
diagrama, sem alterar a posição das entidades;
148
Banco de Dados I
model sources: um modelo ou um projeto pode ser

constituído de vários outros modelos, ou seja, pode
ser criado um vínculo entre arquivos do ERwin e
depois sincronizá-los. Isso é útil em casos típicos de
compartilhamento de entidades entre vários projetos.
O ERwin possui um gerador de relatórios em vários formatos, de

fácil manipulação e interação pelo usuário. Na imagem a seguir
é apresentada a tela de interação com usuário do ERwin, para
criação dos relatórios de documentação:
Figura 6.14 - Interface de documentação do Erwin.

Fonte: MySQL ERWin
Está disponível na Midiateca da sala virtual da

disciplina, a versão Trial do software Erwin: CA Erwin
Data Modeler Community Edition.
Como apresentado, existem algumas ferramentas computacionais

que podem auxiliar você no processo de construção do projeto
de um banco de dados. Muitas outras ferramentas poderiam ser
abordadas também, porém, o objetivo principal deste estudo é
mostrar o quanto uma ferramenta Case pode ser útil para um
profissional de banco de dados.
Lembre-se de que a ferramenta é apenas um complemento às

suas atividades. Se o processo de modelar e analisar o problema
for realizado de forma errada, a ferramenta fará a representação
gráfica também de forma errada.
Unidade 6 149
Sendo assim, cabe a você analisar o problema com calma e

utilizar os recursos da ferramenta de forma adequada, gerando
um trabalho em equipe, você e o computador.
Síntese
Você estudou nesta unidade que a utilização de ferramentas

computacionais para facilitar o processo de criação dos modelos
de banco de dados pode ser de fundamental importância durante
o projeto de um banco de dados. Tamanha importância se
deve ao fato de que as ferramentas Case agregam a um projeto
algumas características, como:
maior produtividade na construção do modelo de

dados. Utilizando-se de ferramental específico para esta
finalidade, há elementos facilitadores para a construção
destes modelos;
mais comodidade na manutenção dos modelos
de dados. Os modelos de dados são alterados mais
facilmente e com mais precisão, uma vez que a
ferramenta não permite certas definições inadequadas
para uma determinada situação;
maior controle de todo o modelo de dados. A
partir do momento em que um projeto de banco de
dados passa a contar com mais de uma dezena de
tabelas inter-relacionadas, torna-se muito difícil dar
manutenção a esse modelo manualmente, ou até mesmo
complementá-lo. Com o uso de ferramentas Case o
trabalho fica mais fácil e seguro, uma vez que você pode
visualizar apenas parte do modelo de dados, não se
atendo a situações que não lhe interessem no momento;
Geração automática do código para a implementação
do projeto do banco de dados.
150
Banco de Dados I
A empresa Pare Aqui deseja implantar um sistema para controle dos seus
clientes. Ela possui vários pátios de estacionamento na cidade, porém, o
controle é realizado por meio de anotações em caderno, e isso tem gerado
uma perda muito grande de recursos financeiros e até mesmo de clientes.
A empresa adota as seguintes regras:
no caderno de clientes são cadastrados: o nome do cliente, a

sua data de nascimento e o seu CPF;
no caderno de veículos são cadastrados: a placa, a cor e o
modelo;
no caderno de estacionamento são cadastrados: a data de
entrada e saída, a hora de entrada e saída e a placa do veículo;
o mesmo cliente pode ter mais de um carro estacionado no
pátio.
Com base nessa descrição, construa o modelo de dados numa ferramenta

Case e perceba como fica mais fácil trabalhar com o apoio de uma
ferramenta especializada para essa finalidade.
Unidade 6 151
152
Banco de Dados I
Saiba mais

ABREU, Mauricio.MACHADO, Felipe Nery Rodrigues.

Projeto de Banco de Dados. São Paulo: Erica, 2009.


Erica, 2003.
Unidade 6 153
7
unidade 7
Acesso e manipulação de dados
n Identificar os comandos de manipulação de dados (DML).
n Inserir dados em uma tabela.
n Alterar e remover os dados cadastrados.
Seções de estudo
Seção 1 A estrutura dos comandos de manipulação
de dados
Seção 2 Inserção de dados em uma tabela
Seção 3 Alteração dos dados da tabela
Seção 4 Exclusão de dados da tabela


Você já utilizou uma ferramenta de banco de dados para criação
de um modelo de banco de dados, ou seja, já criou um conjunto
de tabelas que atendem a alguma necessidade específica. Porém,
você criou as tabelas, dentro das regras de chaves primárias e
estrangeiras, mas não utilizou o modelo criado. E, pensando
bem, de pouca valia seria você ter um modelo de banco de dados
vazio, sem a possibilidade de cadastrar e manipular os dados.
Por isso, nesta unidade você conhecerá um novo conjunto de

comandos, os comandos de manipulação de dados, chamados
abreviadamente de DML. Por meio desses comandos você
poderá cadastrar, alterar, remover e listar os dados de uma
determinada tabela, ou de várias tabelas ao mesmo tempo.
Sendo assim, nesta unidade você aprimorará seu conhecimento

sobre comandos de SQL, que normalmente você utiliza no seu
dia a dia, realizando relatórios, pesquisas e cadastramento de
dados.
Bons estudos!
Seção 1 – A estrutura dos comandos de manipulação

de dados
A linguagem de programação SQL é formada por dois grupos
de comandos. Nesta unidade, você estudará um desses grupos: o
grupo dos comandos DML ou Linguagem de Manipulação de
Dados.
A Linguagem de Manipulação de Dados (DML) é

uma linguagem de consulta e atualização do banco
de dados e compreende os comandos para inserir,
remover e modificar informações em um banco de
dados.
156
Banco de Dados I
São quatro comandos básicos na Linguagem de Manipulação de

Dados:
Select
Insert
Update
Delete
Basicamente, a função de cada comando é:

Select é o comando mais usado, pois permite ao usuário
especificar uma pesquisa com a descrição do resultado
desejado;
Insert é usado para cadastrar dados em uma tabela.Esta

inserção segue as regras definidas na criação da tabela,
como por exemplo: campos do tipo Chave Primária não
poderão ter valores repetidos;
Update altera os valores dos campos já cadastrados na

tabela;
Delete é o comando que permite remover registros

existentes em uma tabela.
Como você pode verificar, cada comando possui uma sintaxe

própria e é sobre isso que você vai estudar a partir de agora.
Quais as características de cada comando, como escrevê-los
e o que esperar como resposta do banco de dados após a sua
execução.
Seção 2 – Inserção de dados em uma tabela

Como você estudou na seção anterior, o comando Insert permite
a inclusão de novas linhas na tabela: uma linha de cada vez ou
várias linhas resultantes de uma consulta. Para isso, as colunas da
lista de inserção podem estar em qualquer ordem.
Caso o valor inserido não atenda o tipo de dado definido para

aquela coluna, a inserção não será realizada. Será apresentada
uma mensagem indicando qual ou quais campos não atendem
Unidade 7 157
a alguma regra de integridade. Os Campos do tipo not null são

obrigatórios e, dessa forma, a inserção só será realizada caso os
dados forem informados.
No caso de inserção de dados em
colunas do tipo Chave Primária, a
Acompanhe o exemplo a seguir:
inserção só será realizada se o valor
a ser inserido não existir para a
mesma coluna.
A estrutura da tabela para cadastramento de produtos é:
Caso 1. A inserção não precisa seguir a ordem das colunas.
Produto
Codigo_Produto Integer NN (PK)
Descricao_Produto Varchar(30) NN
Preco_Produto Float NN
Figura 7.1 – Estrutura da tabela.

A inserção não precisa ser na ordem das colunas da

tabela. Você pode inserir um dado informando primeiro
o Preço, a Descrição e, por último, o Código.
Caso 2. A inserção deve obedecer ao tipo de dado da

Coluna.
Na mesma tabela Produtos, se for inserido o código do
produto valendo “ABCD”, a inserção não será realizada,
pois a coluna é do tipo (INT) integer. Portanto, só
aceitará números como dados de cadastro.
Caso 3. A inserção de campos not null.
Na tabela de produtos, se você analisar, perceberá que

todos os campos são do tipo not null, pois há um NN
(not null) ao lado de cada campo da tabela. Isso significa
que todos os campos são obrigatórios. Se a inserção for
executada sem que todos os campos tenham seu valor
informado, a inserção será cancelada.
Caso 4. Campos do tipo Chave Primária.
O campo Codigo_Produto é do tipo chave primária, pois

o campo possui um “PK” ao lado da definição do tipo.
158
Banco de Dados I
Assim sendo, caso seja feita uma inserção com um valor

que essa coluna já possui, a inserção será cancelada.
Agora que você já sabe dos cuidados a serem tomados na inserção

de dados, é hora de aprender a sintaxe deste comando:
Insert into Nome_Da_tabela (Coluna1,Coluna2,...,ColunaN)

Values (Valor1,Valor2,...,ValorN);
Cadastrando os elementos na tabela Produtos apresentada

anteriormente, tem-se:
Codigo_Produto Descricao_Produto Preco_Produto

1 Banana 0.79
2 Uva 2.50
3 Maçã 1.80
4 Mamão 2.00
Quadro 7.1 – Dados da tabela produtos.
Os campos que não são do tipo numérico devem ficar entre

aspas ( ` ).
Insert into Produtos values (1, ’Banana’, 0.79);
Veja o que acontece ao se executar esse comando:

Figura 7.2 – Cadastramento de produtos na tabela.

Unidade 7 159
Continuando as inserções:
Insert into Produtos values (2,’Uva’,2.50);

Insert into Produtos values (3,’Maçã’,1.80);
Insert into Produtos values (4,’Mamão’,2.00);
Como a inserção dos dados é para todos os campos da tabela, não

há a necessidade de especificar as colunas do Insert. Você apenas
Adote a definição dos nomes das estaria escrevendo a mais.
colunas somente quando não for
inserir dados para todas as colunas Se você seguisse a regra geral do Insert, o comando ficaria assim:
da tabela.
Insert into Produtos (Codigo_Produto,Descricao_Produto,Preco_Produto) values (1,’Banana’,0.79);
Sempre que estiver construindo uma interface de um software

ou qualquer outro programa que necessite incluir um comando
de inserção, adote como padrão sempre definir os nomes das
colunas. Isto pode minimizar erros futuros devido a alterações na
base de dados como, por exemplo, a inclusão de uma nova coluna
não obrigatória (null), a qual o seu insert não está preparado.
Ao inserir dados informalmente nas tabelas, aí sim, para obter

maior produtividade e digitar um número mínimo de caracteres,
sugiro que omita a definição dos nomes das colunas nos
comandos de inserção. Adote a definição dos nomes das colunas
somente quando não for inserir dados para todas as colunas da
tabela.
Agora, vamos tentar cadastrar um novo produto, porém com o

código de produto valendo 1, que já foi cadastrado anteriormente:
Insert into Produtos (Descricao_Produto, Preco_Produto, Codigo_Produto) Values (’Banana’, 0.79,1);
Note que, ao inverter a ordem dos campos, foi necessário escrever

o nome de cada coluna que receberá os valores da inserção. Por
padrão, a inserção segue a ordem da criação da tabela, que pode
ser visualizada através do comando Describe.
160
Banco de Dados I
O resultado da execução do comando será:
Figura 7.3 – Execução do comando describe.

Dessa forma, a inserção não será realizada.
No caso a seguir, vou forçar a inserção de um campo literal

(varchar) na coluna de preços:
Insert into Produtos Values (10, ’Banana’, ’OLA’);
Figura 7.4 – Execução do comando describe – inserção campo literal.

Sendo assim, a inserção não será realizada.
Para finalizar, vamos tentar inserir alguns campos nulos:
Insert into Produtos (Codigo_Produto, Descricao_

Produto)
Values (100, ’Batata’);
Unidade 7 161
Figura 7.5 – Execução do comando describe – inserção campo nulo.

Sendo assim, a inserção não será realizada.
Agora que você já sabe como inserir dados em uma tabela, que
tal você aprender a alterar as informações cadastradas? Esse será
seu próximo aprendizado, está preparado?
Seção 3 – Alteração dos dados da tabela

O comando Update altera os valores das colunas especificadas em
todas as linhas que satisfaçam a uma determinada condição.
As colunas a serem alteradas devem ser declaradas no comando

Update e seguidas dos novos valores para cada coluna,
respectivamente. Somente as colunas a serem modificadas devem
aparecer na lista de colunas da declaração.
Os novos valores de cada coluna devem obedecer ao tipo de

dados da coluna, ou seja, campos do tipo numérico só podem
receber números e campos não numéricos devem ter o valor de
atualização entre aspas simples (‘), como no comando de inserção.
Caso não seja especificada uma condição, a alteração valerá para

todas as linhas da tabela.
Mas então, o que é uma condição?
162
Banco de Dados I
Uma condição é qualquer decisão que você inclua no seu

comando de SQL e que esteja associada a um operador lógico.
Se a condição retornar como verdadeira (true), a execução do
comando será realizada.
Conheça então, os operadores lógicos:
Operador Função
= Igual
<> Diferente
> Maior
< Menor
>= Maior ou Igual
<= Menor ou Igual
AND E lógico – Verdadeiro quando todas as condições são verdadeiras.
OR OU lógico – Verdadeiro quando pelo menos uma Condição é verdadeira.
Não – Inverte o valor. Se for verdadeiro, troca para falso, se é falso troca para
NOT verdadeiro.
Bem, agora que você já sabe dos cuidados a serem tomados na

alteração de dados, é hora de aprender a sintaxe desse comando:
Update Nome_Da_tabela set Coluna1= valor1,...,ColunaN = valor N

Where (Condição);
Para exercitar esse comando, serão alterados alguns dados da

tabela de produtos que foram inseridos por meio do comando
Insert. As alterações serão as seguintes:
Codigo_Produto Descricao_Produto Preco_produto

1 Banana 0.79
2 Uva 2.50
3 Maçã 1.80
4 Mamão 2.00
Trocar o código para 15 Trocar a descrição Trocar o preço para 2.10

para Melancia
Figura 7.6 – Comando insert.
Unidade 7 163
a) Trocando a descrição do produto “Banana” para “Melancia”

e o preço para 2.10:
Update Produtos set Descricao_Produto =

‘Melancia’, Preco _Produto = 2.10
Where Codigo_Produto = 1;
ou
Update Produtos set Descricao_Produto =

‘Melancia’, Preco _Produto= 2.10
Where Descricao_Produto = ‘Banana’;
b) Trocando o Código do produto “Uva” para 15:
Update Produtos set Codigo_Produto = 15

Where Codigo_Produto = 2;
ou
Update Produtos set Codigo_Produto = 15

Where Descricao_Produto = ‘Uva’;
c) Dar um aumento de 10% em todos os produtos cadastrados:
Update Produtos set Preco_Produto = Preco_Produto * 1.1
Como não foi apresentada uma condição Where, a

atualização será realizada em todas as linhas da tabela,
na coluna Preco_Produto.
Veja a tabela com os dados atualizados:
Codigo_Produto Descricao_Produto Preco_produto

1 Melancia 2.31
15 Uva 2.75
3 Maçã 1.98
4 Mamão 2.20
Quadro 7.2 – Dados da tabela produtos.
164
Banco de Dados I
Seção 4 – Exclusão de dados da tabela

O comando Delete exclui as linhas que satisfazem a uma
determinada condição na tabela especificada.
Se a condição estiver ausente, o efeito é a exclusão de todas

as linhas da tabela. O resultado vai ser uma tabela válida,
porém, vazia.
Caso a tabela possua alguma coluna que seja chave estrangeira

para outra tabela, e os valores dela estão sendo usados como
referência, a exclusão não poderá ser realizada, pois a exclusão
resultará em campos nulos na tabela referenciada.
Observe a representação a seguir:
Figura 7.7 – Exclusão de dados na tabela.

A tabela ItensDaNota é uma entidade associativa, pois para que

ela possua dados cadastrados é necessário que existam dados na de
produtos e na de nota_fiscal. Se for solicitado um comando para
excluir os dados da tabela nota_fiscal, a referência a ela, na tabela
ItensDaNota, ficará com qual valor?
Caso você tenha imaginado que a tabela ItensDaNota ficaria

inalterada, isso não pode ocorrer, pois ela estaria referenciando
um valor que não existe mais na tabela de origem.
Unidade 7 165
Por outro lado, a tabela não pode ficar com esses campos nulos
(vazios), pois são do tipo not null.
Assim sendo, o comando SQL que exclui os dados da tabela

Nota_Fiscal será cancelado, de forma que a exclusão não seja
realizada.
Com certeza, agora você deve estar se perguntando,

como excluir esses dados?
Bem, no caso de exclusão de dados em uma tabela que tem dados

compartilhados, deve-se primeiro excluir os que estão nas tabelas
que fazem a associação, para depois excluir na tabela principal.
Por exemplo, no caso descrito anteriormente, que utilizava

a tabela Nota_Fiscal e ItensDaNota, primeiro devem ser
excluídos os dados da tabela ItensDaNota, para depois excluí-los
na Nota_Fiscal.
À medida que você avançar nos exercícios de SQL, esses

cuidados ficarão mais claros, por enquanto, são apenas lembretes
para a parte prática dos comandos.
Bem, agora só falta você conhecer a sintaxe do comando de

exclusão de dados:
Delete from Nome_Da_Tabela where Condição;
Antes de você utilizar o comando, conheça quais são os dados a

serem excluídos:
Tarefa Comando em SQL

Remover os produtos que custam menos de Delete from Produtos where Preco_
dois (2) reais produto<2
Delete from Produtos where Descricao_

Remover o produto de descrição Melancia produto = ‘Melancia’
Delete from Produtos where Codigo_

Remover o produto de código 3 Produto=3
166
Banco de Dados I
Caso a intenção seja excluir todos os dados da tabela, basta

executar o comando:
Delete from Nome_Da_Tabela;
É importante que você atente para as condições que

envolvem tipos que não são numéricos.
Imagine que na tabela de produtos tenha-se um
produto com a descrição “PÊRA”. A palavra PERA é
diferente de Pera que é diferente de PÊRA. Ou seja,
os dados alfanuméricos são “case sensitive”, em
que maiúsculo é diferente de minúsculo, além da
acentuação.
Neste caso, ao usar o comando a seguir, esse não
excluíra o registro, pois PERA é diferente de PÊRA:
Delete from Produtos where Descricao_Produto = ‘PERA’
Para solucionar esse problema, você pode utilizar a função de

conversão para maiúscula, que se chama Upper, e possui a
seguinte sintaxe:
Upper (Coluna);
Essa função retorna o valor literal que está na coluna especificada

com todos os caracteres em maiúsculo.
Veja:
Nome Upper(Nome)
fulano FULANO
Fulano FULANO
FULANO FULANO
fulaNO FULANO
Unidade 7 167
Para transformar em minúsculo, utilize a função Lower,

que possui a mesma sintaxe:
Lower (coluna);
Aplicando essa função ao comando que exclui o produto PERA,

o comando ficaria assim:
Delete from Produtos where Upper(Descricao_Produto) = Upper(‘pêra’);
Síntese
É muito importante você se lembrar que esses comandos vistos

anteriormente podem ser executados em qualquer ferramenta de
banco de dados, pois seguem um padrão mundial chamado de
SQL ANSI.
Cada comando possui uma característica própria e à medida que

você for utilizando-os, mais fácil será a sua compreensão.
No comando de Insert, que é responsável pelo cadastramento

dos dados nas tabelas, você sempre deve tomar o cuidado de
respeitar as regras de criação da tabela, como:
campos obrigatórios – not null;
chaves primárias – não podem ter o valor repetido;
chaves estrangeiras – valores que existem em outra

tabela;
tipos de dados de cada coluna – tipos que não são

numéricos devem ter seu valor de cadastro entre aspas
simples. Campos numéricos só aceitam números.
168
Banco de Dados I
Lembre-se de que qualquer desrespeito a pelo menos uma destas

regras a inserção não será realizada.
No comando Insert, você só precisa especificar a ordem das

colunas de inserção quando não forem informados valores para
todos os campos da tabela.
INSERT em Todos os Campos INSERT em Alguns Campos
Insert into Tabela values (v1,v2,...,vn); Insert into Tabela (c1,c2,..cn) values (v1,v2,…,vn);
Para alteração dos dados da tabela, você deve usar o comando

Update. Esse deve estar associado a uma condição, caso
contrário, todas as linhas da tabela serão alteradas.
UPDATE com Condição UPDATE sem Condição

Altera somente as linhas da tabela que atendam à condição. altera todas as linhas da tabela. (CUIDADO !!!)
Update Tabela set Campo1 = Valor 1 where Condição; Update Tabela set Campo1 = Valor 1;
A exclusão de dados da tabela deve ser realizada por meio do

comando Delete. Esse comando também está associado a uma
condição, porém, quando se deseja excluir todos os dados da
tabela, a condição não precisa ser informada.
DELETE com Condição DELETE sem Condição

Remove somente as linhas da tabela que atendam à condição. Remove todas as linhas da tabela.
DELETE from Tabela where Condição; DELETE from Tabela;
Quando uma tabela é excluída, a estrutura da tabela contínua

existindo, porém, ela estará vazia, sem registros. Quando se
deseja remover uma tabela do banco de dados, usa-se o comando
Drop Table.
Excluir dados da Tabela Remover a Tabela
DELETE from Tabela ; DROP Table Tabela;
Unidade 7 169
Para encerrar esta síntese, você deve tomar o cuidado na hora

de excluir os dados de uma tabela, principalmente se ela possuir
campos que são chaves estrangeiras para outras tabelas, pois se
isso for verdadeiro, a exclusão não será realizada.
Com relação ao Delete, você estará removendo os dados

da tabela, e caso a exclusão tenha sido realizada de forma
equivocada, será necessário recadastrá-los um a um, por isso o
máximo de cuidado na hora de usar este comando.

1. Com base no modelo de banco de dados abaixo, escreva os comandos

em SQL que executem as seguintes tarefas:
Produto
A) Cadastre os seguintes produtos:
Questão Codigo_Produto Descricao_Produto Preco_produto

A1 100 Caneta Azul 1.00
A2 200 Borracha 0.80
A3 300 Caderno de Desenho 2.20
A4 500 Régua 0.25
A1.
170
Banco de Dados I
A2.
A3.
A4.
B) Altere os dados dos seguintes produtos:
B1. Altere o preço da “Caneta Azul” para 2.50.
B2. Altere o código da “Régua” para 400.
Unidade 7 171
B3. Altere a descrição do “Caderno de Desenho” para “Caderno de 12

Matérias”.
C) Exclua os seguintes produtos:

C1. Remova os produtos que possuem preço inferior a 1.00.
C2. Remova os produtos que possuem o codigo = 100.
C3. Exclua todos os produtos cadastrados na tabela de Produtos.
Saiba mais

HERNANDEZ, M. J. Aprenda a projetar seu próprio banco de

dados. São Paulo: Pearson Education do Brasil Ltda., 1999.


172 Erica, 2003.
8
unidade 8
Recuperação de informações do
banco de dados
n Selecionar dados em SQL usando a DML.
n Compreender as funções agregadas em SQL.
n Gerar consultas com agrupamento em SQL.
Seções de estudo
Seção 1 A Estrutura do Comando Select
Seção 2 Ordenando e agrupando os dados
Seção 3 As funções de agregação
Seção 4 Condições especiais


Para criar e trabalhar com tabelas de um banco de dados é
necessário utilizar um conjunto de comandos da linguagem de
definição de dados (create table) e de manipulação deles, que
permitia o cadastramento, a alteração e a exclusão dos dados
(respectivamente, Insert, Update e Delete).
Como podemos perceber, a criação do banco de dados é uma

tarefa complexa. Transformar os processos executados por
pessoas em um conjunto de dados por meio de tabelas, não é
tarefa uma simples, quanto possa parecer. Cada processo possui
um conjunto de possibilidades e todas elas devem ser amplamente
contempladas por meio da sua solução. Por isso, a criação do
banco de dados dever ser feita analisando-se todo o escopo do
problema.
Uma vez terminada a tarefa e atendidas as necessidades do

problema a ser solucionado, esse deixa de ser alterado e torna-se
um Modelo Estático, pronto para ser utilizado.
Deve-se, ao máximo, evitar alterações em um modelo de banco

de dados, pois isso pode impossibilitar a sua utilização. Mas caso
as alterações sejam necessárias, deverão ser realizadas para o
perfeito funcionamento do sistema criado.
Para exemplificar, imagine que você esteja projetando

um automóvel, o qual deve atender a um conjunto
de requisitos funcionais ou expectativas de seus
compradores. Depois de estudá-lo e ele contemplar
as necessidades de mercado, você o coloca em
produção. E na linha de produção, na qual são
colocados os bancos, vidros, acessórios etc., estão
todos trabalhando a pleno vapor.
Mas o que aconteceria se você chegasse a conclusão
que algumas peças do veículo devessem ser
reprojetadas? Com certeza, o caos, a produção pararia,
atrasos aconteceriam e com certeza o desagrado dos
clientes que aguardam o veículo.
174
Banco de Dados I
Um banco de dados possui os mesmos problemas. Após a sua

criação e validação, deve-se tomar o cuidado de não alterar a
sua estrutura, pois quem o utiliza pode ter sérios problemas em
consequência dessas modificações.
Após a criação do banco e o cadastramento dos dados começam

os processos de utilização dos dados, que são os processos de
consulta à base deles. O principal objetivo do sistema de banco
de dados é permitir ao usuário uma consulta rápida e eficiente.
Dessa forma, o processo de consulta é a tarefa que mais se repete
e aquela em que o usuário final mais interage, gerando a maior
expectativa junto ao usuário.
Quando você acessa sua conta bancária por meio da

internet, você não está preocupado em saber como
aquele banco de dados foi modelado. Mas sim se as
suas consultas são rápidas e se representam fielmente
a verdade dos dados. Essa consulta se repetirá para
outras tarefas que você venha a realizar junto ao
sistema.
E é com este escopo de um sistema de banco de dados que você

passará a interagir a partir desta unidade. Chegou a hora de você
começar a interagir com o comando que será, com certeza, o mais
executado nos seus projetos: o comando Select.
Seção 1 – A estrutura do comando Select

Selecionar os dados pode parecer uma tarefa complexa. Mas com
certeza é muito mais simples do que você possa imaginar.
Para facilitar sua compreensão sobre o que faz um comando de

seleção, será usado como recurso, a tabela.
Produto
Figura 8.1 – Tabela Produtos.
Unidade 8 175
Como a tabela é a junção entre linhas e colunas, é necessário

ter-se duas informações para se realizar uma consulta aos seus
dados: quais linhas e colunas mostrar e quais linhas devem ser
mostradas.
A definição das linhas a serem mostradas é resultado direto

de uma condição que especifica os dados que podem ser
apresentados.
Então, como definir quais as colunas que devem ser

mostradas de uma tabela?
É muito simples! Você deverá especificar o nome das colunas que

deseja listar. Se desejar listar todas as colunas, você não precisa
escrever o nome de todas, mas representá-las por um asterisco (*).
A seleção dos dados que serão mostrados é realizada pelo

comando Select, que retorna as linhas ou registros de uma ou
mais tabelas que atendam a uma determinada condição. Como
nos comandos Update e Delete, uma condição é representada
pela cláusula Where. Se essa cláusula for omitida, todas as linhas
da tabela serão listadas.
Veja a figura a seguir representando o que foi descrito

anteriormente:
Área de atuação do SELECT (colunas)
Coluna 1 Coluna 2 Coluna N
Área de atuação da cláusula

...
WHERE (linhas)
Figura 8.2 – Área de atuação dos comandos Select e Where.
A cláusula Select especifica quais as colunas que serão

apresentadas no resultado da seleção dos dados. Já a cláusula
Where especifica quais as linhas da tabela que serão apresentadas
no final da execução do comando.
176
Banco de Dados I
Um comando Select determina quais colunas e linhas

de uma tabela formam um subconjunto de dados
desejado.
A sintaxe do comando Select é:
Select Coluna1,Coluna2,...,ColunaN
From Nome_Tabela [ ou tabelas ]
Where condição
Group By expressão
Having condição
Order By expressão;
Como você pode ver, o comando Select é bem amplo. Algumas

cláusulas só serão usadas quando realmente necessário,
diminuindo sensivelmente o tamanho do comando a ser escrito.
Quais os termos básicos do comando Select?
Acompanhe, a seguir, o papel de cada termo existente nesta

estrutura.
Você vai começar a ter contato com a estrutura básica do

comando Select que é:
Select (Coluna1, Coluna2,...,

ColunaN)
From Nome_Tabela
a) Colunas do Select
A expressão coluna1,coluna2...colunaN representa as colunas
que devem ser listadas pelo comando Select. Caso você deseje
selecionar todos os campos, pode simplesmente colocar um
asterisco no lugar do nome das colunas.
Unidade 8 177
Com base na tabela Produtos, pode-se realizar algumas

consultas, tais com:

... ...
... ...
Select Preco_Produto, Codigo_

Listar os Preços, Códigos e Descrições Produto, Descricao_Produto
... ...
Quadro 8.1 – Tarefas e respectivos comandos

b) A cláusula From
Esta cláusula especifica uma ou mais tabelas de origem para o
Select. Se múltiplas tabelas de origem forem especificadas, o
resultado será, conceitualmente, o conjunto das linhas de todas as
tabelas envolvidas na seleção, que se chama produto cartesiano.
Por exemplo, com base na tabela Produtos, as mesmas consultas

anteriores seriam escritas especificando a tabela de origem da
consulta, dessa forma:
178
Banco de Dados I
Listar os códigos dos produtos. Select Codigo_Produto from Produtos
Listar os códigos e as descrições. Select Codigo_Produto,Descricao_Produto from Produtos
Select Preco_Produto, Codigo_Produto,Descricao_Produto from

Listar os preços, códigos e descrições. Produtos
Select Codigo_Produto,Descricao_Produto,Preco_Produto from
Listar todos os campos. Produtos
ou simplesmente Select * from Produtos
Quadro 8.2 - Tarefas e respectivos comandos acerca da tabela Produtos

A partir de agora, conheça como funciona a cláusula Where do

comando Select.
c) A cláusula Where
Esta cláusula é responsável por restringir quais as linhas das
tabelas serão apresentadas. A cláusula Where possui a forma
geral:
Where expressão_booleana;
A expressão booleana
pode ser qualquer
expressão que retorne um
Só para fixar, os operadores lógicos são: valor booleano (verdadeiro
ou falso).
Operadores Lógicos Significado

= Igual
> Maior
< Menor
<> Diferente
>= Maior ou Igual
<= Menor ou Igual
AND E Lógico
OR OU Lógico
Quadro 8.3 – Operadores lógicos

Unidade 8 179
Para exemplificar melhor a estrutura estudada, utilize a tabela de

Produtos com os seguintes dados:

1 Banana 1.00
2 Maçã 2.80
3 Uva 3.25
4 Pêra 1.00
5 Maracujá 2.00
6 Mamão 2.55
7 Goiaba 2.00
8 Laranja 3.25
9 Limão 0.85
10 Melancia 2.55
Quadro 8.4 – Tabela Produtos – dados

a) Para listar todos os Produtos, utilize o comando que

listará a tabela de modo idêntico à tabela anterior.
Select * from Produtos;
Resultado: esse comando listará a tabela de modo

idêntico à tabela anterior.
Lembre-se de que a cláusula Where atua nas linhas

da tabela, realizando um filtro. Como no comando
acima não foi especificada a cláusula Where, não haverá
restrição de linhas. A cláusula Select especifica quais
colunas serão apresentadas. No caso acima, o símbolo
asterisco (*) representa todas as colunas da tabela.
b) Para listar os produtos com preço inferior a 3.00:
Select * from Produtos where preco_produto < 3.00;
Resultado:
180
Banco de Dados I

1 Banana 1.00
2 Maçã 2.80
4 Pêra 1.00
5 Maracujá 2.00
6 Mamão 2.55
7 Goiaba 2.00
9 Limão 0.85
10 Melancia 2.55
Quadro 8.5 – Tabela Produtos – resultado

c) Para listar o Código e a Descrição dos produtos com

preço de 1.00:
Select Codigo_Produto, Descricao_Produto from Produtos where Preco_Produto = 1.00;
Resultado:
Codigo_Produto Descricao_Produto
1 Banana
4 Pêra
d) Para listar os dados do Produto de código 5:
Select * from Produtos where Codigo_Produto = 5;
Resultado:
Codigo_Produto Descricao_Produto Preco

5 Maracujá 2.00
Unidade 8 181
e) Para listar os dados de todos os Produtos com preço =

1.00 e Código = 10:
Select * from Produtos where Preco_Produto=1 AND Codigo_Produto=10;;
Resultado:
Observe que nenhuma linha da tabela atende a essa

condição.
f) Listar a descrição e os preços dos produtos:
Select Descricao_Produto, Preco_Produto from Produtos;
Resultado:
Descricao_Produto Preco_Produto
Banana 1.00
Maçã 2.80
Uva 3.25
Pêra 1.00
Maracujá 2.00
Mamão 2.55
Goiaba 2.00
Laranja 3.25
Limão 0.85
Melancia 2.55
Quadro 8.6 – Tabela Produtos – resultado

O comando Select possui várias atribuições e possibilita

inúmeras combinações. Assim, tem-se a possibilidade de
construir comandos que extraiam exatamente os dados
desejados, seguindo as suas necessidades.
182
Banco de Dados I
Seção 2 – Ordenando e agrupando os dados

Você aprendeu até agora sobre como acessar e listar os dados
da tabela. Nessa seção, você aprenderá como melhorar a
apresentação dos dados que são listados, ordenando-os e
agrupando-os.
Para isso, será necessário que você conheça mais duas cláusulas
do comando Select, as cláusulas Order By e Group By.
a) A cláusula Order By
A cláusula Order By serve para ordenar os dados que serão
listados. A ordem de apresentação pode ser crescente (ASC) ou
decrescente (DESC).
Se não for informada a ordem de apresentação, ela será

por padrão crescente (ASC).
A sintaxe do comando é:
Order By coluna1,coluna2,...,colunaN ASC ou DESC;
Um item do Order By pode ser o nome ou o número da coluna

na estrutura da tabela.
Observe a tabela, após a execução do comando:
Select * from Produtos;
Unidade 8 183

1 Banana 1.00
2 Maçã 2.80
3 Uva 3.25
4 Pêra 1.00
5 Maracujá 2.00
6 Mamão 2.55
7 Goiaba 2.00
8 Laranja 3.25
9 Limão 0.85
10 Melancia 2.55
Quadro 8.7 – Tabela Produtos

Usando o Order By, a tabela será listada em ordem decrescente

de Código:
Select * from Produtos Order By Codigo_Produto DESC;
Resultado:

10 Melancia 2.55
9 Limão 0.85
8 Laranja 3.25
7 Goiaba 2.00
6 Mamão 2.55
5 Maracujá 2.00
4 Pêra 1.00
3 Uva 3.25
2 Maçã 2.80
1 Banana 1.00
Quadro 8.8 – Tabela Produtos – resultado usando o Order By

Veja outros exemplos do uso do Order By para mesma tabela:
Listar Codigo e Descriçao dos produtos com preço

menor que 3.00, em ordem crescente de Descriçao:
184
Banco de Dados I
Select Codigo_Produto,Descricao_Produto from Produtos where Preco_

Produto < 3.00 Order By Descricao_Produto;
Resultado:
Codigo_Produto Descricao_Produto
1 Banana
7 Goiaba
9 Limão
2 Maçã
6 Mamão
5 Maracujá
10 Melancia
4 Pêra
Quadro 8.9 – Tabela Produtos.
Listar os Produtos com código inferior a 5 e ordenados
crescentemente por Preço:
Select * from Produtos where Codigo_Produto<5 Order By Preco_Produto;
Resultado:
1 Banana 1.00
4 Pêra 1.00
2 Maçã 2.80
3 Uva 3.25
Listar os produtos ordenados por preço e descrição:

Select * from Produtos Order By Preco_Produto,Descricao_Produto;
Unidade 8 185
Resultado:

9 Limão 0.85
1 Banana 1.00
4 Pêra 1.00
7 Goiaba 2.00
5 Maracujá 2.00
6 Mamão 2.55
10 Melancia 2.55
2 Maçã 2.80
8 Laranja 3.25
3 Uva 3.25
Observe que nas linhas em que os preços são os mesmos, a

ordenação foi feita também pela descrição do produto em ordem
crescente.
b) A cláusula Group By
A cláusula Group By condensa, em uma única linha, todas as
linhas selecionadas que compartilham os mesmos valores para as
colunas agrupadas.
Um item do Group By pode ser o nome de uma coluna ou o

número da coluna na estrutura da tabela.
A sintaxe do comando é:
Group By coluna1, coluna2, ..., colunaN;
Para exemplificar essa cláusula Group By, vamos utilizar o

seguinte modelo de banco de dados:
186
Banco de Dados I
Figura 8.3 – Modelo de banco de dados - cláusula Group By

Listando os dados de cada tabela, tem-se:
1. Select * from Regiao;
Resultado:
Codigo_Regiao Nome_Regiao
1 Sul
2 Norte
3 Centro-oeste
4 Nordeste
2. Select * from Produtor:
Resultado:
Codigo_Produtor Nome_Produtor
1 Produtor 001
2 Produtor 002
3 Produtor 003
3. Select * from Produtos;
Unidade 8 187
Resultado:
Codigo_Produto Codigo_Regiao Codigor_Produtor Preco_Produto Descricao_Produto

11 1 1 1.44 Produto A
12 2 2 1.55 Produto B
13 1 1 2.99 Produto C
14 3 3 1.45 Produto D
15 1 1 1.99 Produto E
16 4 2 1.59 Produto F
17 2 1 1.55 Produto G
Lembre-se de que a tabela de produtos faz referência à tabela

de produtor e à tabela de Regiao por meio das colunas Codigo_
Produtor e Codigo_Regiao, respectivamente. Dessa forma,
pode-se afirmar que o produto de Código 11, cuja descrição é
Produto A, é produzido pelo Produtor 001, da região Sul, ao
preço de 1.44.
Sendo assim, a tabela de produtos possui os seguintes dados, se

vista pelas chaves estrangeiras:
Codigo_Produto Codigo_Regiao Codigor_Produtor Preco_Produto Descricao_Produto

11 Sul Produtor 001 1.44 Produto A
12 Norte Produtor 002 1.55 Produto B
13 Sul Produtor 001 2.99 Produto C
14 Centro-oeste Produtor 003 1.45 Produto D
15 Sul Produtor 001 1.99 Produto E
16 Nordeste Produtor 002 1.59 Produto F
17 Norte Produtor 001 1.55 Produto G
Com base nessa tabela de Produtos, serão executados alguns

comandos, utilizando a cláusula Group By, veja:
Listar todos os produtores por região:
Select Codigo_Produtor, Codigo_Regiao from Produtos

Group By Codigo_Regiao;
Resultado:
188
Banco de Dados I
Codigo_Produtor Codigo_Regiao
1 1
2 2
3 3
2 4
Listar os produtos por produtor:
Select Descricao_Produto, Codigo_Produtor from Produtos

Group By Codigo_Produtor;
Resultado:
Descricao_Produto Codigo_Produtor
Produto A 1
Produto B 2
Produto D 3
Note que ao fazer o agrupamento, os itens que possuem o mesmo

valor não são reapresentados.
Seção 3 - As funções de agregação

Uma função de agregação retorna um único resultado para várias
linhas de entrada de uma tabela. Por exemplo: existem funções de
agregação para contar, somar, calcular a média, calcular o valor
máximo e o valor mínimo para um conjunto de linhas.
Uma função de agregação recebe os dados de várias

linhas de uma tabela, porém, um único valor de
retorno é apresentado.
As principais funções de agregação são:
Unidade 8 189
Função O que faz

Count Retorna o número de ocorrências da coluna da tabela;
Sum Retorna a soma dos valores da coluna da tabela;
Avg Retorna a média de valores da coluna da tabela;
Max Retorna o maior valor da coluna da tabela;
Min Retorna o menor valor da coluna da tabela;
Distinct Não permite que valores iguais de uma coluna sejam apresentados na consulta.
Quadro 8.18 – Principais funções de agregação
A função de agregação sempre está associada a uma coluna da

tabela, dessa forma a sintaxe do comando é:
Função_de_Agregação (Coluna)
Veja alguns exemplos de uso das funções de Agregação:
Selecionar o maior e, o menor preço, a média

deles, o total de preços e a quantidade de produtos
cadastrados.
select
max(preco_produto) as maior,
min(preco_produto) as menor,
avg(preco_produto) as media,
count(codigo_produto)as Qtde,
sum(preco_produto) as somatório
from produtos;
Resultado:
maior menor media Qtde somatório

2.99 1.44 1.7943 7 12.56
Note que acrescentamos ao lado de cada função um nome

para apresentação da coluna. Para essa substituição, usamos
o comando AS. Por exemplo: a função max(preço_produto)
será mostrada como sendo a coluna maior, mas em vez de sair
190
Banco de Dados I
no nome da coluna “max(preço_produto)”, será substituído

por “maior”. Essa notação foi utilizada para esclarecer o que
representa cada resultado da função executada.
Acompanhe, a seguir, outros exemplos!
1. Listar a quantidade de produtos com preço de 2,99:
Select count(codigo_produto) as Quantidade from

produtos where preco_produto = 2,99;
2. Listar a soma dos preços de produtos com código

maior que 13:
Select sum(preco_produto) as Soma from produtos where

codigo_produto = 13;
3. Listar todos os preços de produtos sem que os

preços iguais sejam repetidos:
Select distinct(preco_produto) as Preço from produtos;
Veja o resultado do comando acima:
Preço
1.44
1.45
1.55
1.59
1.99
2.99
Unidade 8 191
Seção 4 – Condições especiais

Para restringir as linhas de resultado Select, usa-se a cláusula
Where. Entretanto, há casos em que não poderá ser desta forma.
Como apresentado no exemplo anterior, para selecionar o maior
preço da tabela de Produtos foi usado o comando:
Select max(preco_produto) From produtos;
Mas se fosse solicitado a você para localizar o produto com maior

preço? Talvez, de início você imaginaria algo como:
Select descricao_produto
From produtos
Where preco_produto = max(preco_produto);
Porém, isso não pode ser feito porque a função de agregação

max não pode ser usada na cláusula Where. A cláusula Where
determina as linhas que vão passar para o estágio de agregação
e, portanto, precisa ser avaliada antes das funções de agregação
serem computadas.
A consulta pode ser reformulada para obter o resultado

pretendido, sendo feito por meio de uma subconsulta:
Select descricao_produto
From produtos
Where preco_produto = (Select max(preco_produto ) from produtos);
Veja a representação abaixo:
192
Banco de Dados I
Figura 8.4 – Subconsulta.

Isso está correto porque a subconsulta é uma ação independente

que calcula sua agregação isoladamente do que está acontecendo
na consulta externa. As agregações também são muito úteis
quando combinadas com a cláusula Group By.
Select Codigo_Regiao, max(Preco_Produto)

From Produtos
Group By Codigo_Regiao;
Para produzir uma linha de saída para cada região, significa que
cada resultado da agregação é calculado sobre as linhas da tabela,
correspondendo a uma região. Essas linhas agrupadas podem ser
filtradas utilizando a cláusula Having.
Select Codigo_Regiao, max(Preco_Produto)

From Produtos
Group By Codigo_Regiao
Having max(Preco_Produto) > 100;
É importante que você compreenda a interação entre as

agregações e as cláusulas Where e Having do SQL. A diferença
fundamental entre essas duas cláusulas é:
Unidade 8 193
Where seleciona as linhas de entrada antes de os grupos

e agregações serem computados, portanto, controla quais
linhas irão para o computo da agregação;
Having seleciona grupos de linhas após os grupos e
agregações serem computados. Portanto, a cláusula
Where não pode conter funções de agregação. Por
outro lado, a cláusula Having sempre possui função de
agregação.
Essa restrição entre as cláusulas Where e Having se dá em

função de como os SGBDs executam o comando Select. Por
mais estranho que possa parecer, o comando Select começa a ser
executado pela cláusula From, não pelo próprio Select. Vejamos a
ordem de execução das cláusulas do comando Select:
ORDEM CLÁUSULA
6 Select
1 From
2 Where
3 Group by
4 Having
5 Order By
Quadro 8.20 – Ordem de execução das cláusulas do Comando Select

Assim sendo, perceba que ao ser executado o Where, o banco de

dados ainda não tem conhecimento de como serão constituídos
os grupos de dados. Dessa forma, não podem processar as
funções de agregação.
Conforme o exposto, a projeção das colunas selecionadas é

sempre a última operação na execução do comando select, isso
explica, por exemplo, porque podemos ordenar as informações
a serem apresentadas por uma informação que não está sendo
selecionada.
Para concluir, se desejarmos somente produtos cuja descrição

comece pela letra “S”, podemos utilizar a função LIKE, por
exemplo:
194
Banco de Dados I
Select Descricao_Produto
From Produtos
Where Descricao_Produto LIKE ‘S%’;
Síntese
O comando Select é usado em SQL para todas as formas de

pesquisar informação. Este é um comando bastante poderoso
e versátil, tendo algumas variações. Informalmente, todos os
comandos Select podem ser estruturados na seguinte forma:
Select lista de colunas

From tabelas
Where restrições;
Para acessar dados da tabela sem que sejam apresentados valores

repetidos, deve-se utilizar a cláusula Distinct:
Select distinct (Coluna) from Tabela;
É possível combinar restrições de pesquisa, como:
Select Coluna1, Coluna2

From Tabela
Where Coluna2 <> ‘Valor1’ AND Coluna1 <> ‘Valor2’;
É possível ainda que o comando Select seja escrito dentro de

outros comandos:
Select Coluna2, Coluna3

From Tabela
Where Coluna = (Select
Coluna from Tabela);
Unidade 8 195
O comando Like permite fazer uma pesquisa na tabela sem

saber o valor exato que se procura. Usa-se o % para representar
qualquer sequência de caracteres que tenha um símbolo em
específico:
Select Coluna
from Tabela
where Coluna Like “n%”;
As funções de agregação são:
Função O que faz:

Count Retorna o número de ocorrências da coluna da tabela
Sum Retorna a soma dos valores da coluna da tabela;
Avg Retorna a média de valores da coluna da tabela
Max Retorna o maior valor da coluna da tabela
Min Retorna o menor valor da coluna da tabela
Quadro 8.21 – Funções de agregação
Apesar de parecerem idênticos, os comandos Where e Having

possuem características diferentes, como você pode verificar.
WHERE seleciona as linhas de entrada antes de os

grupos e agregações serem computados, portanto,
controla quais linhas irão para o computo da agregação;
HAVING seleciona grupos de linhas após os grupos

e agregações serem computados. Portanto, a cláusula
WHERE não pode conter funções de agregação. Por
outro lado, a cláusula HAVING sempre possui função
de agregação.
196
Banco de Dados I

1) Dada a tabela Alunos a seguir:
Codigo Nome Sexo Idade

1 Charles Medeiros M 35
2 Ana Paula Bertoldo F 25
3 Lucas Giaretta M 7
4 Sthefanie Caroline F 19
5 Djalma Medeiros M 65
6 Artur Paes M 5
7 Eduarda Duda F 8
Escreva os comandos em SQL que:
a) Liste todos os alunos do sexo Masculino:
b) Liste todos os alunos que possuem o sobrenome “Medeiros”,

ordenados crescentemente por idade.
c) Liste a média de idade dos alunos e escreva na coluna o nome Média:
Unidade 8 197
d) Liste a maior idade dos alunos:
e) Liste a quantidade de alunos com idade menor que 20 anos:
f) Liste o Nome e o Código do aluno chamado “Lucas Giaretta”:
g) Liste o aluno com a menor idade.
h) Liste a quantidade de alunos com idade entre 10 e 20 anos, e que sejam

do sexo masculino.
i)Liste a quantidade de mulheres cadastradas na tabela de Alunos.
A melhor forma de identificar se suas respostas estão

corretas é fazer o teste prático no MySQL. Faça isso e
potencializará seu aprendizado.
198
Banco de Dados I
Saiba mais

ABREU, Mauricio, MACHADO, Felipe Nery Rodrigues.

Projeto de Banco de Dados. Editora Érica , 2009.
HEUSER, CARLOS ALBERTO. Projeto de Banco de Dados.

São Paulo: Bookman, 2009.
Unidade 8 199
9
unidade 9
Recuperação de informações
por meio de tabelas
Selecionar dados em SQL usando mais de uma tabela
como referência.
Compreender os tipos de junções em SQL.
Gerar consultas em SQL mais eficientes.
Seções de estudo
Seção 1 O que é uma junção
Seção 2 Junções de produto cartesiano
Seção 3 Junções internas
Seção 4 Junções externas


O comando de manipulação de dados chamado Select será um
dos mais executados por qualquer aplicação de computador que
envolva um SGBD. A estrutura de um comando de seleção é
bem simples. Definem-se as colunas que serão apresentadas,
quais as tabelas relacionadas que fazem parte da seleção e qual a
condição de filtro para a definição das linhas que farão parte do
conjunto de dados recuperado.
Porém, na maioria das vezes, a seleção de dados que será

executada envolve mais de uma tabela ao mesmo tempo, pois
os dados estão distribuídos em várias tabelas relacionais ligadas
pelas chaves estrangeiras, os chamados relacionamentos.
Assim, durante a construção de consultas em SQL, é muito

comum surgir a necessidade de extrair informações de diferentes
tabelas para se gerar o resultado esperado.
Nesta unidade você terá uma integração maior com o comando

Select, criando consultas que envolvam mais de uma fonte de
dados.
Sendo assim, bem-vindo ao mundo do Select!
Seção 1 – O que é uma junção

Nos modelos de banco de dados, principalmente naqueles que
envolvem um número elevado de tabelas, é muito comum, na
elaboração das consultas, a necessidade da seleção de dados em
diferentes tabelas.
Essa operação necessita que o especialista em banco de dados

defina os critérios para o agrupamento dessas tabelas.
202
Banco de Dados I
Os critérios para o agrupamento são chamados de

condições de junção, ou apenas junção.
A junção de tabelas ocasiona uma tabela derivada de outras

duas, de acordo com as regras de junção elaborada. As regras
de junção são muito parecidas com as da teoria de conjunto da
matemática, como união, intersecção e diferença. Veja a figura
abaixo:

Figura 9.1 – Representação da junção entre tabelas

Na Figura 9.1 tem-se duas tabelas com dados quaisquer. A

junção executada resulta em uma terceira tabela que agrupa dados
em comum entre A e B, o que se pode chamar de intersecção
entre elas. Porém, uma nova junção entre essas tabelas poderia
ser realizada, de forma a retornar uma terceira com todos os
dados das duas anteriores, fazendo a união dos dados, conforme
a figura a seguir:
Unidade 9 203
Figura 9.2 – Junção com a união dos dados das duas tabelas
Veja na próxima figura um terceiro caso, em que a junção retorna

os dados que estão na Tabela A, mas não estão na Tabela B,
correspondendo à operação de conjunto A-B :
Figura 9.3 – Junção que retorna os dados que estão na tabela A, mas não estão na tabela B
204
Banco de Dados I
As formas de junção são definidas pela cláusula Where do

comando Select, como qualquer outra condição da consulta, e
possuem influência direta sobre a escolha do método de junção
que será realizado pelo especialista em banco de dados.
Essas condições de consulta são utilizadas para realizar a união

entre os dados contidos nas diferentes tabelas, combinando os
registros, formando um único registro que contém os campos
definidos na cláusula Select.
Conforme as condições de junção, é possível obter os seguintes

tipos de junção:
produtos cartesianos – retorna toda a combinação de

registros das duas tabelas de dados, uma vez que não
existe nenhuma restrição definida na cláusula where;
junções interna (inner-join) – a consulta retornará

apenas os registros que atendem às condições definidas
nas tabelas de dados;
junções externas (outer join) – semelhante à junção

simples, porém, retornará também os registros da fonte
de dados externa, que não estão presentes na tabela
interna.
Na definição da junção, o especialista em banco de dados deve

tomar alguns cuidados, como:
identificar as chaves primárias das tabelas;
identificar as chaves estrangeiras das tabelas;
identificar os relacionamentos entre as tabelas;
visualizar toda estrutura do modelo de dados que está

sendo utilizado, com nome dos campos e tipos de cada
campo;
ater-se aos dados que serão apresentados pelo
comando de seleção.
Unidade 9 205
De forma resumida, independentemente do tipo

de junção, a criação da junção deve levar em
consideração os dados que serão apresentados pela
seleção, qual o relacionamento existente entre as
tabelas que fazem parte da pesquisa a ser elaborada,
quais os campos únicos e quais os nomes e tipos de
cada campo.
Na próxima seção, você estudará a forma de representar cada um

dos tipos de junções vistos anteriormente, utilizando o comando
Select.
Seção 2 – Junções de produto cartesiano

Esse método de junção se baseia nas regras de relacionamento
entre as tabelas que fazem parte da seleção, sendo que as chaves
estrangeiras são referenciadas diretamente na formulação do
comando Select.
Esse método de junção deve ser utilizado quando as tabelas possuem

poucos registros e existe uma relação direta entre as tabelas.
Lembre-se de que a relação direta entre tabelas é

realizada pelas chaves estrangeiras.
Essa junção realiza uma pesquisa em todas as tabelas que fazem

parte do comando Select, de forma que o próprio SGBD define
uma tabela principal, que servirá de base para a busca dos
registros nas tabelas dependentes.
Para cada registro existente na tabela principal, o SGBD buscará

os registros relacionados na tabela dependente, desde que
atendam às condições da cláusula Where. Antes de apresentar
exemplos de comandos Select que implementam a junção com
produto cartesiano, você verá o modelo de dados que usaremos
como exemplo, bem como:
206
Banco de Dados I
os comandos de definição de dados que criam as tabelas

do modelo;
os comandos de inserção de dados de cada tabela do

modelo;
a representação gráfica de cada tabela com os dados já

cadastrados.
Veja todas as características do modelo de dados que será

utilizado, bem como relembre de alguns comandos que já foram
vistos nas unidades anteriores. A seguir, está a representação
gráfica do modelo que usaremos como exemplo:
Figura 9.4 – Modelo de dados para o exemplo de junção por produto cartesiano
Nesse modelo de dados, pode-se notar que a tabela Pais é a única

que não depende de dados das outras tabelas. Por outro lado, a
tabela de SubRegiao possui um campo que é a chave estrangeira
para a tabela Pais, representada pelo relacionamento número
1 da figura acima. Dessa forma, tem-se uma regra de chave
estrangeira na tabela SubRegiao da seguinte forma:
A coluna chamada Codigo_Pais da tabela SubRegiao

referencia a tabela Pais pelo campo Codigo_Pais.
Já a tabela Cidade possui a sua coluna Codigo_SubRegiao como
chave estrangeira para tabela SubRegiao, representada pelo
relacionamento número 2 da figura acima, da seguinte forma:
Unidade 9 207
A coluna Codigo_SubRegiao da tabela Cidade referencia

a tabela SubRegiao pelo campo Codigo_SubRegiao.
Para elucidar esse modelo de dados, representado na última
Figura, veja a seguir os comandos de definição de dados que
criaram esse modelo.
Create Table Pais (

Codigo_Pais Integer,
Nome_Pais Varchar(30),
Primary Key (Codigo_Pais)
);
Create Table SubRegiao (
Codigo_SubRegiao integer,
Nome_SubRegiao Varchar(30),
Codigo_Pais integer,
Primary Key (Codigo_SubRegiao),
Foreign Key (Codigo_Pais) references Pais (Codigo_Pais)
);
Create Table Cidade (
Codigo_Cidade integer,
Nome_Cidade Varchar(30),
Codigo_SubRegiao integer,
Primary Key (Codigo_Cidade),
Foreign Key (Codigo_SubRegiao) references SubRegiao (Codigo_SubRegiao)
);
Figura 9.5 - Comandos de definição de dados

A partir de agora, serão apresentados os comandos em SQL para

preenchimento das tabelas. Começaremos pela tabela Pais. Em
SQL, por meio do comando Insert, o preenchimento da tabela de
países foi feito assim:
208
Banco de Dados I
Cadastro na Tabela Pais
Insert Into Pais Values (1,’Brasil’);

Insert Into Pais Values (2,’Argentina’);
Insert Into Pais Values (3,’Estados Unidos’);
Insert Into Pais Values (4,’Canada’);
Quadro 9.1 – Comandos de insert na tabela Pais

Graficamente a tabela ficou desta forma:
Tabela 9.1 – Tabela Pais com os dados cadastrados.

Codigo_Pais Nome_Pais
1 Brasil
2 Argentina
3 Estados Unidos
4 Canadá
Agora, os comandos de inserção para montar a tabela SubRegiao:
Cadastro na Tabela Sub-Região

Insert Into SubRegiao Values (1,’Parana’,1);
Insert Into SubRegiao Values (2,’Sao Paulo’,1);
Insert Into SubRegiao Values (3,’Santa Catarina’,1);
Insert Into SubRegiao Values (4,’Buenos Aires’,2);
Insert Into SubRegiao Values (5,’Cordoba’,2);
Insert Into SubRegiao Values (6,’California’,3);
Insert Into SubRegiao Values (7,’Rio Grande do Sul’,1);
Quadro 9.2 – Comandos insert na tabela SubRegiao
Tabela 9.2 – Tabela de SubRegiao com os dados cadastrados.

Codigo_SubRegiao Nome_SubRegiao Codigo_Pais
1 Parana 1
2 Sao Paulo 1
3 Santa Catarina 1
4 Buenos Aires 2
5 Cordoba 2
6 California 3
7 Rio Grande do Sul 1
Unidade 9 209
Para finalizar, os comandos de inserção para montar a tabela

Cidade:
Cadastro na Tabela Cidade

Insert Into Cidade Values (1,’Sao Paulo’,2);
Insert Into Cidade Values (2,’Florianopolis’,3);
Insert Into Cidade Values (3,’Buenos Aires’,4);
Insert Into Cidade Values (4,’La Plata’,4);
Insert Into Cidade Values (5,’Los Angeles’,6);
Insert Into Cidade Values (6,’San Francisco’,6);
Quadro 9.3 – Comandos de insert na tabela Cidade
Tabela 9.3 – Tabela Cidade com os dados cadastrados
Codigo_Cidade Nome_cidade Codigo_Subregiao

1 Sao Paulo 2
2 Florianopolis 3
3 Buenos Aires 4
4 La Plata 4
5 Los Angeles 6
6 San Francisco 6
Bem, agora que está tudo preparado, veja alguns comandos em

SQL que fazem a seleção de dados pela junção por produto
cartesiano.
Selecionando todos os dados da tabela Cidade:
Select * from Cidade;
210
Banco de Dados I
O Resultado do Select será:
Codigo_Cidade Nome_cidade Codigo_SubRegiao

1 Sao Paulo 2
2 Florianopolis 3
3 Buenos Aires 4
4 La Plata 4
5 Los Angeles 6
6 San Francisco 6
Quadro 9.4 – Resultado do comando.

Até aqui não há nada de diferente dos demais processos.

Contudo, a tabela fica inconsistente quando se percebe que as
cidades pertencem a sub-regiões como: 2, 3, 4 e 6. Esses valores
correspondem aos códigos das sub-regiões cadastradas na tabela
SubRegiao, conforme a figura a seguir:
Codigo_ Nome_cidade Codigo_

Cidade SubRegiao
1 Sao Paulo 2
2 Florianopolis 3
3 Buenos Aires 4
4 La Plata 4
5 Los Angeles 6
6 San Francisco 6
Codigo_ Nome_ Codigo_

Cidade SubRegiao Pais
1 Parana 1
2 Sao Paulo 1
3 Santa Catarina 1
4 Buenos Aires 2
5 Cordoba 2
6 California 3
7 Rio Grande do Sul 1
Figura 9.6 – Relacionamento entre as tabelas Cidade e SubRegiao

Unidade 9 211
Sendo assim, o comando de seleção de todos os registros da

tabela de cidades pode ser escrito da seguinte forma:
Select Cidade.Codigo_Cidade,Cidade.Nome_Cidade,SubRegiao.Nome_SubRegiao
From Cidade,SubRegiao
Where Cidade.Codigo_SubRegiao = SubRegiao.Codigo_SubRegiao;
Nesse caso, há uma junção entre as tabelas de Cidade e

SubRegiao, por meio da chave estrangeira Codigo_SubRegiao da
tabela Cidade, que a relaciona com a tabela SubRegiao.
O resultado do comando será:
Codigo_Cidade Nome_Cidade Nome_SubRegiao

1 Sao Paulo Sao Paulo
2 Florianopolis Santa Catarina
3 Buenos Aires Buenos Aires
4 La Plata Buenos Aires
5 Los Angeles Califórnia
6 San Francisco Califórnia
Quadro 9.5 – Resulta da junção entre as tabelas Cidade e SubRegiao
Tem-se um produto cartesiano com dados das tabelas Cidade e

SubRegiao. Veja mais alguns comandos de seleção.
Selecionar a sub-região da cidade de Florianópolis:
Select SubRegiao.Nome_SubRegiao
From Cidade, SubRegiao
Where Upper(Cidade.Nome_Cidade) = ‘FLORIANOPOLIS’ AND
Cidade.Codigo_SubRegiao = SubRegiao.Codigo_SubRegiao;
212
Banco de Dados I
Figura 9.7 – Resultado do comando Select

Selecionar o código e o nome das cidades da sub-região de São

Paulo:
Select Cidade.Codigo_Cidade, Cidade.Nome_Cidade

From Cidade, SubRegiao
Where Upper(SubRegiao.Nome_SubRegiao) = ‘SAO PAULO’ AND
Cidade.Codigo_SubRegiao = SubRegiao.Codigo_SubRegiao;
Selecionar o nome das sub-regiões que pertencem ao país

chamado Brasil:

Selecionar o nome de todas as sub-regiões e seus respectivos

países:
Select SubRegiao.Nome_SubRegiao, Pais.Nome_Pais

From SubRegiao, Pais
Where Pais.Codigo_Pais = SubRegiao.Codigo_Pais;
O resultado do comando acima será:
Unidade 9 213

Selecionar o nome das sub-regiões que pertencem ao país

chamado Brasil:
Select SubRegiao.Nome_SubRegiao
From SubRegiao, Pais
Where Upper(Pais.Nome_Pais) = ‘BRASIL’ AND
Pais.Codigo_Pais = SubRegiao.Codigo_Pais;

Selecionar o nome da cidade, o nome da sua respectiva sub-

região e país:
Select Cidade.Nome_Cidade, SubRegiao.Nome_SubRegiao, Pais.Nome_Pais

From Cidade, SubRegiao, Pais
Where Cidade.Codigo_SubRegiao = SubRegiao.Codigo_SubRegiao AND
SubRegiao.Codigo_Pais = Pais.Codigo_Pais;
214
Banco de Dados I
Figura 9.11 – Resultado do comando Select.

Note que a condição Where sempre especifica as

chaves estrangeiras que interligam as tabelas da
seleção. Isso é uma característica da junção do tipo
produto cartesiano.
Na próxima seção, você verá como criar junções sem usar a chave
estrangeira diretamente.
Seção 3 – Junções internas

A utilização da cláusula Inner é o que caracteriza o comando
para uma junção interna, porém, ele não é obrigatório. Pode
parecer, à primeira vista, que as junções internas se equiparam
com as junções de produto cartesiano vistas anteriormente.
Mas nas junções internas é sempre obrigatória a especificação

de condição de junção, ou seja, quais linhas de uma tabela têm
alguma ligação com a linha de outra tabela. Para isso, deve-se
utilizar a cláusula On.
A cláusula On se assemelha em muito com a cláusula Where, ou

seja, um par com uma linha da Tabela A e uma linha da Tabela
B é correlacionado se a expressão da cláusula On for verdadeira.
Unidade 9 215
Por exemplo, a seleção de todos os registros da tabela Cidade

pode ser escrita da seguinte forma:
SELECT *
FROM Cidade
INNER JOIN SubRegiao
ON Cidade.Codigo_SubRegiao = SubRegiao.Codigo_SubRegiao;
Note que a cláusula On está sendo utilizada de forma

semelhante à cláusula Where das junções de produto
cartesiano.
Porém, o resultado do Select será diferente. Veja a saída realizada

pelo comando anterior:
Figura 9.12 – Resultado de uma junção interna entre as tabelas de Cidade e SubRegiao
Como ambas as tabelas possuem o campo Codigo_SubRegiao,

uma coluna se manteve como Codigo_SubRegiao e outra
foi renomeada para Codigo_SubRegiao_1, que representa
exatamente o relacionamento entre as tabelas e a condição da
cláusula On.
Veja um exemplo de Select com junção interna para selecionar o

nome de todas as sub-regiões e seus respectivos países:
Select SubRegiao.Nome_SubRegiao,Pais.Nome_Pais
From SubRegiao
INNER JOIN Pais
ON SubRegiao.Codigo_Pais = Pais.Codigo_Pais;
216
Banco de Dados I
O resultado desse comando será:
Figura 9.13 – Resultado de uma junção interna entre as tabelas de SubRegiao e Pais.
Bem, o que era importante a respeito do assunto junção interna

foi apresentado nesta seção. Na próxima você terá contato com as
junções externas.
Seção 4 – Junções externas

Para representar uma junção externa utiliza-se a cláusula Outer,
no entanto, ela não é obrigatória. O que caracteriza realmente as
junções externas são as cláusulas Left e Right.
Junção externa left outer join

Esse tipo de junção externa funciona da seguinte forma:
executa uma junção interna;
verifica quais linhas da primeira tabela não possuem

relacionamento com a segunda tabela da seleção;
para cada linha da segunda tabela que não possui

relacionamento é inserido um campo com valor null.
Veja o exemplo a seguir:
Unidade 9 217
SELECT *
FROM SubRegiao
LEFT OUTER JOIN Cidade
ON Cidade.Codigo_SubRegiao = SubRegiao.Codigo_SubRegiao;
O resultado do Select será:
Figura 9.14 – Resultado de um left outer joiner entre as tabelas SubRegiao e Cidade.
Repare nas linhas destacadas na figura acima que as sub-regiões

as quais não possuem cidade relacionada às colunas Codigo_
Cidade, Nome_Cidade e Codigo_SubRegiao_1 ficaram sem
valores, ou seja, foram preenchidas com null. Em uma seleção
normal essas linhas seriam ignoradas.
Com o uso de left outer joiner todas as linhas das tabelas da

esquerda que não possuem correspondentes na tabela da direita
são apresentadas no resultado da consulta.
Junção externa right outer join

Esse tipo de junção externa funciona da seguinte forma:
executa uma junção interna;
verifica quais linhas da segunda tabela não possuem

relacionamento com a primeira tabela da seleção;
para cada linha da primeira tabela que não possui

relacionamento é inserido um campo com valor null.
218
Banco de Dados I
Ou seja, a junção externa right outer join é o inverso da junção left

outer join. Veja o próximo exemplo, supondo que não há nenhuma
sub-região cadastrada para o país Canadá:
SELECT *
FROM SubRegiao
RIGHT OUTER JOIN Pais
ON Pais.Codigo_Pais = SubRegiao.Codigo_Pais;
O resultado do Select será:
Figura 9.15 – Resultado de um right outer joiner entre as tabelas SubRegiao e Pais
Basicamente, a diferença entre right e left está na escolha da

tabela em que os elementos que não possuem relacionamento
serão escolhidos para serem acrescidos com null.
Unidade 9 219
Síntese
Nesta unidade, você ficou sabendo que a maioria das seleções

criadas por especialistas em banco de dados envolve mais de uma
tabela relacional.
Essas seleções necessitam de regras específicas para o cruzamento

dos dados das tabelas referenciadas na cláusula Where. E essas
regras recebem o nome de junção.
Se as tabelas que fazem parte da seleção que será implementada

possuem poucos registros cadastrados e existe uma relação direta
entre as chaves estrangeiras, o ideal é a adoção da junção por
produto cartesiano.
Porém, se as tabelas possuem um número elevado de registros,

pode-se utilizar dois métodos: a junção interna e a junção
externa.
Quando o objetivo é listar os dados de todas as tabelas que fazem

parte da seleção e que possuem valores relacionados, o ideal é
a junção interna, ou simplesmente inner-join, representada pela
cláusula Inner.
Por outro lado, podem ser adotadas as junções externas, Left e

Right, quando se deseja listar todos os dados das tabelas, mesmo
que o relacionamento direto não exista.
As junções externas Left e Right especificam quais tabelas terão

seus campos preenchidos com null.
220
Banco de Dados I
Com o modelo de dados abaixo, escreva os comandos em SQL que
resultam na seleção solicitada.
1. Utilizando uma junção de produto cartesiano, selecione o nome dos

professores, a descrição dos seus respectivos cursos e os locais em que
esses são ministrados:
2. Utilizando uma junção de produto cartesiano, selecione a descrição dos

seus cursos ministrados em Santa Catarina.
Unidade 9 221
3. Utilizando uma junção de produto cartesiano, selecione o nome e a

titulação dos professores do curso de Banco de Dados I.
4. Utilizando uma junção de produto cartesiano, selecione o local, a

cidade e a unidade federativa de todos os cursos que ainda possuem
vagas.
5. Utilizando uma junção interna (inner join), selecione todos os cursos e

seus respectivos locais em que são lecionados.
6. Utilizando uma junção interna (inner join), selecione todos os

professores e seus respectivos cursos.
222
Banco de Dados I
7. Utilizando uma junção externa (outer join), selecione todos os

professores e seus respectivos cursos, de forma que os professores sem
curso tenham os seus campos preenchidos com null.
8. Utilizando uma junção externa (outer join), selecione todos os

professores e seus respectivos cursos, de forma que os cursos sem
professor tenham os seus campos preenchidos com null.
Saiba mais

ABREU, Mauricio, MACHADO, Felipe Nery Rodrigues.

Projeto de Banco de Dados. Editora Érica , 2009.
COSTA, R. L. de C. SQL: guia prático. São Paulo. Brasport,

2004.
FONSECA, L. C. Trabalhando com 10g Oracle Database.

Ciência Moderna, 2005.
HEUSER, CARLOS ALBERTO. Projeto de Banco de Dados.

São Paulo: Bookman, 2009.
Unidade 9 223
MECENAS, I.; OLIVEIRA, V. de. Banco de dados: do

modelo conceitual à implementação física. Alta Books, 2005.
OPEEL, A. Banco de dados desmistificado. Rio de Janeiro.

Alta Books, 2005.
RANGEL, A. MySQL: projeto, modelagem e desenvolvimento.

Rio de Janeiro. Alta Books, 2005.
224
Para concluir o estudo
Chegamos ao final de mais uma grande jornada.
Nesta disciplina, a intenção foi colocar você em contato

com o mundo dos sistemas de bancos de dados,
possibilitando a compreensão do seu papel como um
profissional que está envolvido com armazenamento
e gerenciamento de informações, identificando as
atividades que serão executadas e algumas ferramentas
que podem ser utilizadas. O mais importante é que a
tecnologia é um adicional a sua capacidade de solucionar
problemas.
Para muitos de vocês, os comandos e as tecnologias

aqui apresentadas talvez não tenham sido novidade, no
entanto, esperamos que a disciplina tenha contribuído
para um aprimoramento do seu conhecimento,
independente dos seus conhecimentos prévios acerca do
assunto.
Acreditamos que muitas perguntas ainda se formam em

sua mente, porém, esse é o nosso papel como autores,
fomentar a dúvida, a curiosidade e estimular a busca por
novos conhecimentos. Esperamos ter atingido isso ao
plantar a semente da busca pela informação.
Parabéns, você acaba de dar mais um grande passo rumo

ao objetivo maior que é se tornar um profissional que
domine a tecnologia da informação!
Se a caminhada parecia longa, você acaba de encurtá-la.
Desejamos que cada vez mais você esteja próximo do seu

objetivo maior, mesmo que em alguns momentos o final
da caminhada se apresente mais distante.
Levante a cabeça, tome fôlego e... rumo ao sucesso!

Referências
ABREU, Mauricio, MACHADO, Felipe Nery Rodrigues. Projeto de

Banco de Dados. Editora Érica , 2009.
CHU, S. Y. Banco de dados: organização, sistemas e
administração. São Paulo: Atlas, 1983.
1990.
COSTA, Rogério Luís de Carvalho. SQL: Guia prático. São Paulo.
Brasport, 2004.
DATE, C. J. Banco de dados: fundamentos. Rio de Janeiro:
Campus, 1985.
DATE, C. J. Introdução a Sistemas de Bancos de Dados. Rio de
Janeiro: Campus, 1991.
FONSECA, Luiz Claudio. Trabalhando com 10g Oracle database.
Ciência Moderna, 2005.
GUIMARÃES, Célio Cardoso. Fundamentos de bancos de dados.
Editora Unicamp, 2008.
HERNANDEZ, M. J. Aprenda a projetar seu próprio banco de
dados. São Paulo: Pearson Education do Brasil Ltda, 1999.
HEUSER, CARLOS ALBERTO. Projeto de Banco de Dados. São
Paulo: Bookman, 2009.
JESUS, J. B. de. Ansi SQL 89 92. Axcel Books do Brasil Ltda, 2004.
KORTH, H.F.; Silberschatz, A. Sistema de Banco de Dados. 3. ed.
São Paulo: Makron Books, 1999.COUGO, P. Modelagem conceitual
e projeto de banco de dados. 7. Reimp. Rio de Janeiro: Campus,
2001.
LIMA, A. da S. ERwin 4.0: modelagem de dados. 2. ed. São Paulo:
Érica, 2002.
MECENAS, Ivan. OLIVEIRA, Viviane de. Banco de dados: do
modelo conceitual à implementação física. Alta Books, 2005.
MEDEIROS, M. Oracle 8i: conceitos básicos. Florianópolis:
Advanced, 2000.
NASSU, E. A. Banco de dados orientado a objetos. Edgard Blucher, 1999.

OLIVEIRA, A. R de. Modelagem de dados. São Paulo: Senac, 2004.
OPEEL, Andy. Banco de dados desmistificado. Rio de Janeiro. Alta Books,
2005.
PRESTES, R. Mysql guia de consulta rápida. Novatec, 2000.
RANGEL, Alexandre. Mysql - Projeto, modelagem e desenvolvimento.
Rio de Janeiro. Alta Books, 2005.
SETZER, V. W.; SILVA, F. S. da. Banco de dados. São Paulo: Edgard Blucher,
2005.
SOARES, S. P. de M. Dominando o ERwin: modelagem de dados para
banco oracle. São Paulo: Ciência Moderna, 2004.
SOARES, W. MySQL conceitos e aplicações. Erica, 2003.
228
Sobre os professores conteudistas
Marcelo Medeiros é bacharel em Ciências da

Computação pela Universidade Regional de Blumenau
e professor da Unisul desde 1995, na qual leciona
as disciplinas de Banco de Dados, Programação e
Estrutura de Dados para os cursos de Engenharia,
Ciência da Computação e Sistemas de Informação.
Atualmente participa do projeto de Incubadora da
Unisul, desenvolvendo projetos de software na área de
automação e segurança via IP. Atua como consultor junto
a empresas no desenvolvimento de novos produtos de
informática.
Luciano José Sávio possui graduação em Ciência

da Computacão pela Universidade do Sul de Santa
Catarina (1995) , mestrado em Engenharia de Produção
pela Universidade Federal de Santa Catarina (2000)
e cursa doutorado em Engenharia de Produção pela
Universidade Federal de Santa Catarina (2004) .
Atualmente, é professor titular da Universidade do
Sul de Santa Catarina na área de banco de dados.
Tem experiência na área de Ciência da Computação,
com ênfase em Sistemas de Computação, atuando
principalmente, nos seguintes temas: Agentes,
Inteligência Artificial, Banco de Dados.
Tatiane dos Santos Leal é mestre em Engenharia

de Produção – ênfase em Inteligência Aplicada, pela
Universidade Federal de Santa Catarina – UFSC,
especialista em Gestão Universitária, Dom Cabral
(em parceria com a Unisul), e bacharel em Ciência da
Computação pela Universidade do Sul de Santa Catarina
– Unisul. É professora na graduação presencial da Unisul
desde 1999, ministrando as disciplinas de Engenharia de
Software e Banco de Dados, e na modalidade a distância
trabalha com Sistemas Integrados de Gestão, Gerência
de Projetos, Gestão da Informação, Planejamento
Estratégico de TI e Banco de Dados. É funcionária da Assessoria

de Tecnologia da Informação – ATI – UNISUL desde 1996,
como auxiliar de suporte (1996 a 1998), desenvolvimento de
sistemas (1999), administradora de banco de dados (2000 a
2003). Participou do projeto Visão – implantação do ERP –
SAP R/3 na Unisul, em 2000, como administradora do sistema.
Analista do sistema de indicadores de gestão (BSC – Balanced
Scorecard) e Business Intelligence - BI da Unisul, Painel do
Gestor, participa do grupo de trabalho de implantação do
Customer Relationship Manager – CRM. Gerente de migração
do projeto Guia – implantação do sistema Acadêmico – Oracle/
Peoplesoft – 2005; gerente de implantação do upgrade do SAP
R/3 em 2007, assim como da implantação de outros módulos;
gerente de implantação do Projeto MinhaUNISUL – portal
intranet da universidade, em 2008. Atualmente, coordena a área
de Sistemas, vinculada à Assessoria de Tecnologia da Informação
– da Unisul.
230
Respostas e comentários das
atividades de autoavaliação
Unidade 1
1) Os elementos formadores da área de infraestrutura fazem
parte das funções críticas. Dentre esses elementos estão
as áreas de redes de computadores, telecomunicações e
também a área de banco de dados, uma vez que o Sistema
Gerenciador de Banco de Dados (SGBD) é quem provê o
acesso às informações numa organização. Desta forma,
qualquer problema envolvendo algum elemento da área de
infraestrutura pode causar uma paralisação das atividades
de grande parte da empresa, inviabilizando o trabalho de
muitas pessoas.
2) As responsabilidades são:
Programador:
Promover a documentação dos projetos, segundo
metodologia estabelecida;
Monitorar a fase de testes das aplicações desenvolvidas;
Promover manutenção e desenvolvimento dos sistemas;
Analista de sistemas:
Tem a função de fazer o mapeamento das funcionalidades
do sistema;
A modelagem do modelo de dados que garanta o
atendimento dessas funcionalidades;
Participar do planejamento e projeto de sistemas;
Especificar as etapas de Estudo Preliminares e Análise de
Requisitos em conjunto com os clientes;
Elaborar o Projeto de Soluções;
Administrador de banco de dados

Segurança, por meio de backup, senhas e restrições;
Garantir disponibilidade e performance;
Garantir as atualizações tecnológicas;
Instalar e atualizar as ferramentas do sistema;

Dimensionar o montante de espaço de armazenamento das
informações;
Criar estrutura básica para a instalação de novas aplicações;
Administrar contas de usuários e concessão de privilégios;
Assegurar compatibilidade das aplicações com a base de dados
instalada;
Planejar e desenvolver os procedimentos de backup e recuperação
de dados;
Manter documentação atualizada das máquinas servidoras de banco
de dados, bem como das bases de dados;
Instalar e atualizar os bancos de dados;
Definir estrutura básica necessária para a implantação de bases de
dados (Hardware e Software);
Implantar e consolidar políticas de segurança;
Antecipar-se às mudanças necessárias com relação aos bancos e
bases de dados.
Projetista de banco de dados

Criar objetos das aplicações a serem armazenadas na base de dados;
Monitorar réplicas de objetos em bases de dados distribuídas;
Providenciar modificações na estrutura da base de dados das
aplicações;
Oferecer suporte e treinamento dos usuários da área de
desenvolvimento quanto às características do banco de dados;
Planejar a distribuição dos dados armazenados;
Padronizar a criação de objetos no banco de dados;
Usuário final
Cadastrar dados;
Atualizar dados;
Consultar dados;
Respeitar as regras de segurança de acesso aos dados imposta na
empresa.
232
Banco de Dados I
3) Os principais benefícios proporcionados pelo surgimento do SGBD para

as empresas são:
o SGBD assume a responsabilidade pela manutenção das
informações, retirando parte desta responsabilidade dos sistemas de
informação;
padronização na forma de acesso aos dados, por meio da linguagem
SQL;
compartilhamento mais eficiente das informações armazenadas;
diminuição ou controle da redundância dos dados armazenados.
Unidade 2
1) Independente de ser relacional ou orientado a objetos, a ferramenta
computacional deve ser avaliada com base no problema que será
solucionado. Nem sempre o menor preço significa custos menores.
É importante que a ferramenta possua um bom grupo de usuários
no mercado de trabalho, para que seja gerada uma boa base de
conhecimento, para troca de informações e soluções já implementadas.
Além disso, é importante que a ferramenta tenha suporte ao usuário
e referências bibliográficas de fácil acesso. Outra característica
fundamental é a atualização da ferramenta, que deve acompanhar
a evolução da área da informática, podendo apresentar novas
metodologias e tecnologias de gerenciamento da informação.
Tecnicamente, é essencial que a ferramenta garanta a integridade dos
dados e a fidelidade dos dados. Sem nunca esquecer que a melhor
solução não é aquela que a ferramenta disponibiliza, mas aquela que o
usuário deseja.
2) Não. A ferramenta computacional é um auxílio às atividades do
especialista em banco de dados. A tarefa de analisar e modelar uma
solução que atenda às necessidades do usuário final é do especialista.
Se a tarefa de análise e definição das tabelas for realizada de forma
equivocada, a ferramenta implementará a solução da forma proposta
pelo especialista, ou seja, também de forma equivocada.
A garantia de atendimento às necessidades do usuário está diretamente
relacionada ao processo de definição e criação do banco de dados, e
essa tarefa é realizada pelo estudo e conhecimento do especialista.
Cabe ao especialista saber utilizar de forma correta as funcionalidades
que a ferramenta computacional lhe disponibiliza.
233
Unidade 3
1)

2) CPF.
3) Placa.
4) Chaves primárias: CPF e Placa.
Chaves estrangeiras:
CPF fazendo referência ao CPF na tabela de Clientes.
Placa fazendo referência à Placa na tabela de Veículos.
Unidade 4
1) Um banco de dados relacional tem sua estrutura de funcionamento
baseada em tabelas relacionais, que implementam as regras por
meio de chaves primárias e chaves estrangeiras. Um banco de dados
orientado a objeto tem sua estrutura de funcionamento baseada nas
regras de definição da classe. As classes representam o esqueleto do
objeto, no qual se define as propriedades e formas de acesso ao objeto.
2) A escolha da ferramenta, se proprietária ou de uso livre, deve se
adequar à necessidade da empresa, ou do usuário final. A avaliação
apenas pelo requisito preço pode levar a escolhas precipitadas.
A ferramenta de uso livre deve ter, além da gratuidade, suporte,
manuais, garantia de funcionamento e acompanhamento das
atualizações de mercado. O mais importante é avaliar se a ferramenta,
independentemente de custo, atende às necessidades do usuário.
234
Banco de Dados I
Unidade 5
1)
Create Table Produto (
Codigo_Produto Integer,
Descricao_Produto Varchar(30) not null,
Preco_Produto float not null,
Primary key(Codigo_Produto)
);
2)
Create Table Nota_Fiscal(

Numero_NF Integer,
Data_NF Date not null,
Valor_NF Float not null,
Primary key(Numero_NF)
);
3)
Create Table Itens(

Cod_Prod Integer,
NumNF Integer,
Num_Item Integer not null,
Qde_Item Float not null,
PrimaryKey(Cod_Prod,NumNF),
Foreign Key(Cod_Prod) references Produto(Codigo_Produto),
Foreign Key(NumNF) references Nota_Fiscal(Numero_NF)
);
4)
Alter Table Produto Modify Descricao_Produto Varchar(50);
235
5)
Alter Table Nota_Fiscal Add ICMS float;
6)
Alter Table Produto Add Peso float;
7)
Alter Table Produto Add Data_Validade Date;
8)
Desc Produto;
ou
Describe Produto;
9)
Desc Nota_Fiscal;
ou
Describe Nota_Fiscal;
10)
Drop Table Itens;
236
Banco de Dados I
Unidade 6
1)
Unidade 7
1)
a1) Insert into Produto values (100, ’Caneta Azul’, 1.00);
a2) Insert into Produto values (200, ’Borracha’, 0.80);
a3) Insert into Produto values (300, ’Caderno de Desenho’, 2.20);
a4) Insert into Produto values (400,’Régua’,0.25);
b)
b1) Update Produto set Preco_Produto = 2.50
Where Descricao_Produto = “Caneta Azul”;
b2) Update Produto set Codigo_Produto = 400
Where Descricao_Produto=”Régua”;
b3) Update Produto set Descricao_Produto = “Caderno 12 Matérias”
Where Descricao_Produto = “Caderno de Desenho”;
c1) Delete from Produtos where Preco_Produto < 1.00;
c2) Delete from Produtos where Codigo_Produto = 100;
c3) Delete from Produtos;
237
Unidade 8
1)
a) Select * from Alunos where Upper(Sexo) = ‘M’;
b) Select * from Alunos where Upper(Nome) like ‘%MEDEIROS’
Order by Idade;
c) Select AVG (Idade) as Media from Alunos;
d) Select Max (Idade) from Alunos;
e) Select Count(Codigo) from Alunos
where Idade < 20;
f) Select Nome, Codigo from alunos
where Upper(Nome)=Upper(‘Lucas Giaretta’);
g) Select Nome from Alunos
where Idade = (Select Min(Idade) from Alunos);
h) Select Count(Codigo) from Alunos
where (Idade < 10 and Idade <=20) and (Upper(Sexo)=’M’);
i) Select Count(Codigo) from Alunos
where Upper(Sexo)=’F’);
Unidade 9
1)
Select Professor.Nome_Professor,Curso.Descricao_Curso,Local.Nome_
Local
From Professor,Curso,Local
Where Professor.Codigo_Curso = Curso.Codigo_Curso AND
Curso.Codigo_Local = Local.Codigo_Local;
2)
Select Curso.Descricao_Curso
From Curso, Local
238
Banco de Dados I
Where upper(Local.UF) = ‘SC ‘ AND

Local.Codigo_Local = Curso.Codigo_Local;
3)
Select Professor.Nome_Professor, Professor.Titulacao_Professor
From Professor, Curso
Where Upper(Curso.Descricao_Curso)=’BANCO DE DADOS I’ AND
Curso.Codigo_Curso = Professor.Codigo_Curso;
4)
Select Local.Nome_Local, Local.Cidade_Local, Local.UF_Local
From Curso, Local
Where Curso.Vagas_Curso > 0 AND
Curso.Codigo_Local = Local.Codigo_Local;
5)
Select *
From Curso
INNER JOIN Local
ON Curso.Codigo_Local = Local.Codigo_Local;
6)
Select *
From Professor
INNER JOIN Curso
ON Professor.Codigo_Curso = Curso.Codigo_Curso;
7)
Select *
From Curso
239
LEFT OUTER JOIN Professor

8)
Select *
From Professor
RIGHT OUTER JOIN Curso
240
Biblioteca Virtual
Veja a seguir os serviços oferecidos pela Biblioteca Virtual aos

alunos a distância:
Pesquisa a publicações online

www.unisul.br/textocompleto
Acesso a bases de dados assinadas
www. unisul.br/bdassinadas
Acesso a bases de dados gratuitas selecionadas
www.unisul.br/bdgratuitas
Acesso a jornais e revistas on-line
www. unisul.br/periodicos
Empréstimo de livros
www. unisul.br/emprestimos
Escaneamento de parte de obra*
Acesse a página da Biblioteca Virtual da Unisul, disponível no EVA

e explore seus recursos digitais.
Qualquer dúvida escreva para bv@unisul.br
* Se você optar por escaneamento de parte do livro, será lhe enviado o

sumário da obra para que você possa escolher quais capítulos deseja solicitar
a reprodução. Lembrando que para não ferir a Lei dos direitos autorais (Lei
9610/98) pode-se reproduzir até 10% do total de páginas do livro.

Banco Dados I

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Banco Dados I

Uploaded by

Copyright:

Available Formats

Universidade do Sul de Santa Catarina

Revisão e atualização de conteúdo

Edição – Livro Didático

Revisão e atualização de conteúdo

Projeto Gráfico e Capa

1. Banco de dados. 2. Engenharia de software. 3. Tecnologia da

Ficha catalográfica elaborada pela Biblioteca Universitária da Unisul

UNIDADE 1 - Banco de dados e a tecnologia da informação. . . . . . . . . . . . . 15

Para concluir o estudo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Este livro didático corresponde à disciplina Banco de Dados I.

O material foi elaborado visando a uma aprendizagem autônoma

Lembre-se que sua caminhada, nesta disciplina, será

Então, sempre que sentir necessidade entre em contato; você tem

Bom estudo e sucesso!

Olá, você está iniciando o estudo da disciplina Banco de

Se você parar um pouco para avaliar o seu dia a dia, notará

Ao fazer uma ligação telefônica, realizar uma compra ou

Nesta disciplina você conhecerá as formas de armazenamento

Enfim, você poderá entender melhor o funcionamento

Espero que você possa aproveitar ao máximo o conteúdo desta

Profs. Marcelo Medeiros e Luciano Sávio

O plano de estudos visa a orientá-lo no desenvolvimento da

O processo de ensino e aprendizagem na UnisulVirtual leva

São elementos desse processo:

 o Espaço UnisulVirtual de Aprendizagem (EVA);

 as atividades de avaliação (a distância, presenciais e de

Ferramentas computacionais para implementação de bancos de

 Apresentar as principais ferramentas de sistema de banco

 Apresentar os conceitos de banco de dados relacional e

 Conhecer como instalar e praticar em um sistema

 Conhecer a linguagem de programação para banco de

 Possibilitar a criação e manipulação de um modelo de

 Refletir sobre as tendências de ferramentas e profissionais

Unidade 1 - Banco de dados e a tecnologia da informação

Unidade 2 – Conceitos de bancos de dados

Unidade 3 – Modelagem de dados e projeto de banco de dados

Unidade 4 – Produtos de banco de dados

Unidade 5 – Implementação do projeto de banco de dados

Unidade 6 –Ferramentas Case para apoio ao projeto de banco de

Unidade 7 – Acesso e manipulação de dados

Unidade 8 – Recuperação de informações do banco de dados

Unidade 9 – Recuperação de informações por meio de tabelas

Agenda de atividades/ Cronograma

 Verifique com atenção o EVA, organize-se para acessar

 Não perca os prazos das atividades. Registre no espaço

 Use o quadro para agendar e programar as atividades relativas

Demais atividades (registro pessoal)

Banco de dados e a tecnologia

 Entender a evolução dos sistemas de armazenamento

 Compreender o papel dos profissionais de banco de

Seção 2 De sistemas de arquivos a sistemas

Seção 3 O mercado de trabalho e seus profissionais

Para início de estudo

Porém, para compreender melhor o mercado de informática

Mas o que significa analisar estes aspectos dos bancos

Quando uma empresa utiliza a informática como complemento

Um exemplo disso são os supermercados. Eles utilizam a

Há também no mercado as empresas que têm a informática como

Por exemplo, a MicroSoft é uma empresa que tem

Você deve estar se perguntando: “e daí”? Bem, como temos cenários

E é nesse escopo que esta unidade será inserida, de forma a

Além disso, você vai conhecer como ocorreu a evolução dos

Seção 1 – Banco de dados e a área de tecnologia da

Atualmente, banco de dados está posicionada nas áreas de TI das

o Espaço UnisulVirtual de Aprendizagem (EVA);

as atividades de avaliação (a distância, presenciais e de

Apresentar as principais ferramentas de sistema de banco

Apresentar os conceitos de banco de dados relacional e

Conhecer como instalar e praticar em um sistema

Conhecer a linguagem de programação para banco de

Possibilitar a criação e manipulação de um modelo de

Refletir sobre as tendências de ferramentas e profissionais

Verifique com atenção o EVA, organize-se para acessar

Não perca os prazos das atividades. Registre no espaço

Use o quadro para agendar e programar as atividades relativas

Entender a evolução dos sistemas de armazenamento

Compreender o papel dos profissionais de banco de

desenvolvimento de software - programadores;

quando o analista está modelando um sistema, ele está

População das tabelas dos bancos de dados –

Manutenção do banco de dados – garantir que ele não